sip - 奇怪的网络问题

Question

我们正面临网络技术问题，我无法理解。

我们使用 Linphone 客户端通过 x.x.x.101 连接到 x.x.x.125(Freeswitch 盒)，即 .101 是 SIP 代理 Flexisip。

SIP 流程如下所示。

   [ Linphone box ]  <-> [ `.101` box ]  <-> [ `.125` box ]

现在，当我们通过 .101 注册即 SIP REGISTER 请求(未连接 VPN)到 .125 时，它可以正常工作，即注册成功，之所以这样说，是因为我在 .101 和 Linphone 客户端盒上使用 TCP 转储嗅探流量(两者都有 200 OK Response for Register 请求)。

现在这就是交易，当我们调用电话时，即在没有连接 VPN 的情况下发送 SIP INVITE 请求。我们在 .101 盒子上没有看到任何流量，但在 Linphone 盒子上可以找到相同的流量，暗示请求被定向到 .101。(但同时我可以不断看到从 .101 到 Linphone Machine 的 OPTIONS 请求以及一个 200K 响应得到从 Linphone 机器发送用于 OPTIONS 请求。)

现在，我们越快连接到 VPN，我们就会看到来自 Linphone 盒子的请求出现在 .101 盒子上

现在，如果这种行为保持不变，我会怀疑防火墙规则，但它会在 SIP REGISTER 期间工作并且不使用常规 INVITE 邀请是我在这里能够理解的。

当我们连接到 VPN 时，它就可以工作了。

NOTE: If I assume this is a packet loss as a part of UDP even the retransmission too does not go through and this happen in multiple run..

It's only the INVITE packet would not be sent always does not happen with REGISTER request.

这里是 sip 流的样子

Answer 1

鉴于 REGISTER 请求正在通过，这排除了 IP 路由和防火墙问题(假设它没有对 SIP 数据包进行深度检查)。

剩下两个最有可能的罪魁祸首是客户端软件(在本例中为 Linphone)使用了错误的网络接口(interface)，

尝试使用类似 sipp 的工具运行测试您可以在其中明确设置要使用的本地地址和要发送的 SIP 请求的类型。

# To test the user agent client scenario (which sends INVITE requests) use:
sipp -bind_local 10.1.10.1 -sn uac -m 1 x.x.x.125

更新:

检查数据包捕获的一些观察结果:

在没有 VPN 的情况下:

• 软电话和代理之间有一个 NAPT，将 10.1.10.1 转换为 49.36.13.47，例如10.1.10.1:39248 映射到 49.36.13.47:44150。
根据 Flexisip... 的用户代理字符串，
• REGISTER 响应似乎来自 63.211.239.125 的 FreeSWITCH 服务器在响应上。
• 与原始帖子一致，在捕获中根本没有对 INVITE 请求的响应。
• 没有捕获到分片的 UDP 数据包。

在 VPN 案例中:

• 软电话和代理之间没有 NAPT。软电话流量源自 172.17.8.37。
• 软电话在其 SDP 提供中使用的 IP 地址为 192.168.29.134，这意味着该设备可能具有多个网络接口(interface)。
• 当软电话向 Proxy 发送 INVITE 请求时，记录了一个碎片化的 UDP 数据包，但这似乎不是问题，因为 Proxy 很乐意将请求转发到 FreeSWITCH 服务器。

缺失数据:

no VPN 捕获不包含代理和 FreeSWITCH 服务器之间的流量。这是分析中最关键的部分，因为它可以显示代理是否正在转发 INVITE 请求。

直接在代理上运行 tcpdump 将能够提供此丢失的信息。

更新的猜测:

根据仍然不完整的信息，我现在的最佳猜测是 Proxy 错误配置(或者可能是故意的)SIP 设置，并且正在静默丢弃在公共(public)接口(interface)上收到的 INVITE 请求。

当软件电话连接到 VPN 时，INVITE 请求被转发，因为它们被认为来自内部网络。

对于 REGISTER 请求，Proxy 可以有一条规则，无论 Proxy 在哪个接口(interface)上接收请求，都始终转发它们，因为它们不像 INVITES 那样有风险。