SipUA Invite UDP 重发

现象描述

在使用 pjsua2 makeCall 的时候发现我的 SipUA 可以完成注册和返回 407 授权失败的 INVITE 事务，但 携带授权信息 的 INVITE 消息达不到对端（对端抓不到包），经查是本地一直在重发。

经查，两次的 INVITE 包的差别只有符合预期的三个地方：branch 标签变化、CSeq 加一和携带了 Proxy-Authorization 头。

image.png

反思：这个现象经过很长事件的调查才调查到，这是第一个 不该：一开始只想到是程序本身某配置问题，而未想到用抓包确认。

问题猜想

错误的猜想：昨日猜想是网络问题，我本地是在 Windows 内的 WSL 运行的，公司还有一个网关，然后才到测试环境的一个 FS。但这无法解释 Register 消息和没带授权信息的 INVITE 是可以正常收发的。

今日忽然想到：可能是 UDP 消息太大了，导致到某个位置被扔掉了。

问题验证（含知识点）

知识点一：学会看 WireShark 工具抓包信息

证明 IP 分包：通过将 sngrep 保存下来，看到 Reassembled in #N 应该就是 IP 重组的包。（用 WireShark 抓包结果和 sngrep 一样。）

image.png

在 WireShark 中可通过配置关闭 IPv4 数据报的重组（一般打开便于阅读）。

image.png

信息二：确定是因为 SIP 包过大导致丢包的！

首先 SIP 包过大并不是大问题，从网上查来看，UDP 包最大能支持 65507 字节，但由于包太大分组再重组后发生校验错误的概率增大，所以丢包的可能性会大很多。

我找到了 pjsua2 中设置 codec 的代码，将不需要的 codec 都禁用了，然后再次禁用 TCP 传输，呼叫就可以正常进行了。因此，可以确定是因为本地 SIP 包过大导致丢包的问题。

信息三：谁丢了 UDP 包

如果是网络上的某些网元会将此 UDP 包丢弃的话，那确实没办法查了。但好在我尝试了下在 Windows 测试，用 MicroSip 设置开启了支持所有的媒体编码类型，结果抓包发现整个带授权头的 INVITE 消息有 2500 多的字符，同样在 IP 层有分包发送，但呼叫状态正常。（同样看网上解释，UDP 最大可支持 65507 字节的）

所以问题就在我本地 WSL 的网络环境，与其他无关。

TODO： 自己写个程序，在客户端控制发送 UDP 报文的大小，在服务端验证接收报文的大小，测试在 WSL 和 Windows 下是否现象不一致。

TODO： WHY？

知识点四：UDP 分片相关

UDP 分片会增大丢包的风险，因为 IP 重组如果重组后校验不对，就会丢弃包。

参考

问题解决

用 TCP 方式解决

用 TCP，在 pjsua 中设置 UDP 和 TCP 都开启的状态下呼叫电话，底层会自动切换到用 TCP 传输 带授权状态的 INVITE 消息（TODO：底层实现，是否是一种普遍方法）。

减小包体

禁用掉许多 codec 减小 SDP 信息大小，同时关闭 TCP 传输的使用，可正常呼叫了。

        # ep 是 pj.Endpoint 的实例
        ep.codecSetPriority("speex/16000", 0)
        ep.codecSetPriority("speex/8000", 0)
        ep.codecSetPriority("speex/32000", 0)
        ep.codecSetPriority("iLBC/8000", 0)
        ep.codecSetPriority("GSM/8000", 0)
        ep.codecSetPriority("G722/16000", 0)