美文网首页
SipUA Invite UDP 重发

SipUA Invite UDP 重发

作者: Robin92 | 来源:发表于2022-10-20 13:53 被阅读0次

现象描述

在使用 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)

相关文章

网友评论

      本文标题:SipUA Invite UDP 重发

      本文链接:https://www.haomeiwen.com/subject/kwxmzrtx.html