使用JsSIP通话时Sender's packet count过高的含义及原因咨询

先搞懂：什么是"Sender's packet count"？ #

这个指标说直白点，就是你的JsSIP客户端在通话过程中，向对方终端发送的RTP数据包总数量。咱们语音/视频通话的媒体数据，都是靠RTP协议拆成一个个小数据包传输的，正常情况下这个数值会跟着通话时长平稳增长——比如用G.711编码的语音通话，每秒大概会发50个包，一分钟就是3000左右，这个范围是正常的。

数值异常偏高的常见原因 #

我做SIP客户端开发时碰到过不少这类问题，总结下来主要是这几个场景：

• 网络不稳定触发重传：如果你的网络有丢包、延迟抖动或者带宽波动，WebRTC底层的RTCP反馈机制会认为之前发的包没被对方收到，就会触发重传逻辑，把同一个包反复发送，直接拉高这个计数。尤其是在WiFi信号弱、移动网络切换，或者跨运营商网络的场景下，这种情况特别常见。
• 媒体编码配置出问题：比如错误开启了强制分片选项，哪怕很小的音频帧也被拆成多个RTP包发送；或者编码参数配置不合理，导致每帧数据被过度拆分。还有些编码库的bug，会不断生成无效的小帧，迫使客户端持续发送数据包。
• 重复创建媒体流：如果代码里不小心多次调用了call.start()却没正确清理旧的媒体流，或者媒体采集模块重复推送数据，客户端会同时发送多份完全相同的媒体内容，发送包数直接翻倍甚至更多。
• 远端RTCP反馈异常：如果对方的客户端或者中间的SIP服务器返回了错误的RTCP接收报告（比如误报丢包），你的客户端会被误导，以为之前的包都没送达，就会不断重传，导致发送包数疯涨。
• 测试环境的循环流：比如本地测试时用了音频环回设备，客户端采集到自己发送出去的音频，又重新编码发送，形成无限循环，这种情况下包数会呈指数级增长，一眼就能看出来异常。

内容的提问来源于stack exchange，提问作者Cherry