奇怪的网络问题

Question

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

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

SIP 流程如下所示。

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

现在，当我们通过 .101 向 .125 注册即 SIP REGISTER 请求（未连接 VPN）时，它可以工作，即注册成功，说这是因为我在 .101 和 Linphone 客户端框上使用 TCP 转储来嗅探流量（对于注册请求都有 200 OK 响应）。

现在这是交易，当我们拨打电话时，即在没有连接 VPN 的情况下发送 SIP INVITE 请求。我们在 .101 盒子上没有看到流量，但在 Linphone 盒子上可以找到相同的流量，暗示请求被定向到 .101。（但同时我可以不断看到 OPTIONS 请求从 .101 出现到 Linphone 机器，并且还有 200K 响应从 Linphone 机器发送的 OPTIONS 请求。）

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

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

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

注意：如果我认为这是作为 UDP 的一部分的数据包丢失，即使重新传输也不会通过，并且这会在多次运行中发生..

只有 INVITE 数据包不会被发送总是不会发生在 REGISTER 请求中。

sip 流程如下所示

Answer 1

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

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

尝试使用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，这意味着该设备可能具有多个网络接口。
• 当软件电话向代理发送INVITE 请求时记录了一个分段的 UDP 数据包，但这似乎不是问题，因为代理很乐意将请求转发到 FreeSWITCH 服务器。

缺少数据：

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

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

更新猜测：

基于仍然不完整的信息，我现在最好的猜测是代理错误配置（或者可能是故意的）SIP 设置，并且默默地丢弃在公共接口上收到的 INVITE 请求。

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

对于REGISTER 请求，代理可能有一条规则，即无论代理在哪个接口上接收它们，始终转发它们，因为它们不像INVITES 那样危险。

Answer 2

如果路径不同，INVITE 将通过不同的网络，它们的行为可能不一样。

我可以看到 VPN 未激活时使用的网络可能存在 2 个问题：

• 一个 NAT 有一个 ALG，如果它被破坏，会丢弃 INVITE 并让其他的通过。这不太可能，因为您尝试过的几个 User-Agent 都会发生这种情况。
• 网络配置为丢弃大于特定大小的数据包。这很可能是因为带有所有 User-Agent 的 INVITE 始终是发送的最大 SIP 消息。

我会建议你：

• 尝试 TCP：这应该可以确认它只是 UDP 问题。
• 尝试删除所有编解码器并仅保留 PCMA，使用 UDP：如果可行，则可能是 UDP/MTU/SIZE 问题。

编辑：

明确地说，您肯定遇到了 MTU 问题。

因此，我建议您在使用和不使用 VPN 的情况下测试您的 UDP 网络和 MTU 大小限制。您不必使用您的android，但您需要使用相同的网络。

在 sip 服务器上，启动：

$> nc -u -l -p 2399

在 LAN 端，任何具有相同网络的 PC 使用 netcat 工具...

$> cat invite1000.example | nc -u sip.antisip.com 2399
$> cat invite1200.example | nc -u sip.antisip.com 2399
$> cat invite1500.example | nc -u sip.antisip.com 2399
$> cat invite2000.example | nc -u sip.antisip.com 2399
$> cat invite8000.example | nc -u sip.antisip.com 2399

制作几个包含任何数据的invitexxx.example文件，但其中包含特定数量的字符。

理论上，服务器上的 nc/netcat 在经过 MTU 时会停止接收数据包（或数据包不完整）。

然后，这将确认这是一个 MTU 问题。