调试排错

SIP 问题排查

If something can go wrong, it will. - Murphy's Law

“如果一件事情有可能出错,则它一定会出错。” —— 莫菲法则

虽然我们很小心地开发及测试 XSwitch,但很遗憾,我们有时候还是无法绕开莫菲法则。不管你遇到什么问题,强烈建议先阅读一些我们的调试与排错首页描述的一般问题排查的方法和原则。

如果你安装了 XSwitch 但遇到 SIP 相关的问题,可以参考这里的步骤进行排查。

搞清楚拓扑图

按照橡皮鸭解题法所描述的,其实你只要把你的问题描述清楚了,问题就迎刃而解了。很多时候我们无法帮助你是因为我们不知道你的问题是什么,你的网络环境是什么,你是怎么安装的,你用的什么版本,看到了什么现象……

比如,你的拓扑图是这样的:

问题可能出在任何地方。假设你用了一个软电话(比如装在 Windows 上的 SIP 终端),那么你的软电话可能有问题,你的操作系统也可能有问题,当然 XSwitch 可能有问题,数据库也可能有问题。

检查网络

检查网络的连通性。如果你走到(看到)这里,说明网是通的,至少你认为网是通的。

检查 SIP 服务器

确保你能登录 Web 界面,能从 Web 界面上查看日志,能进入命令行控制台,通过fs_cli查看日志等。这样,你在遇到问题的时候也可以方便收集信息,进而方便获取帮助。

注册

用你的 SIP 终端向 XSwitch 注册。

如果无法注册,可能是参数填错了,也可能是服务器有问题。怎么查?两头查。哪两头?你的 SIP 终端和 XSwitch。

SIP Trace

进入 FreeSWITCH 控制台,在fs_cli上执行以下命令打开 SIP 跟踪:

sofia global siptrace on

如果你注册时收不到 SIP 消息,那就检查网络,检查你 SIP 终端的参数,检查你的终端有没有将 SIP 包发过来。

在你的 Windows 上使用 Wireshark 抓包,看将包发到哪里去了。在 XSwitch 所在的服务器上抓到,但它有没有收到。这就是两头查。

在 Linux 具体的抓包可以使用 Wireshark、tcpdump、ngrep 等工具。如,在 Linux 上可以使用:

ngrep -d any -p -q -Wbyline port 5060

如果 SIP 消息没有发出,检查你的 SIP 终端,参数是否填错,等等。

如果 SIP 包发出来了,那就检查 XSwitch 侧有没有收到。如果收到了,好说,如果没收到,包去哪里了?那就需要检查你的 SIP 终端和 XSwitch 服务器中间所有的网络设备。

两端都能收到包是处理一切问题的第一步。

常见问题

注册不上

如果 SIP 消息能通,但是注册不上,可能是密码不对。比如收到403消息,就是典型的密码不对。检查分机对应的密码,也可能是数据库出错等。总之,可以通过在fs_cli上查看相关的日志获取更多线索。

如果你在微信群或通过邮件请求帮助,请一定要提供相关的日志信息,否则很难帮你解决问题,因为每个人遇到的问题可能都不一样。

能注册但打不通电话

还是要看日志,如果打不通电话,大概率是路由问题。比如著名的404错误码表示找不到路由。

能注册,能打电话,但是对方听不到我说的话

也可能是单通,也可能是根本没有媒体,这时候可以使用如下命令:

获取通话的 UUID:

show channels

打开媒体跟踪日志:

uuid_debug_media 你获取到的uuid all on

如果能看到相关的日志,日志中会有RW相关的行,分别表示接收和发送,如果没有,那就是没有媒体。如果只有R没有W,那就是单通。接下来怎么查?

如果没有媒体,就检查 SIP 中的 SDP,因为 SDP 是管媒体的。不管你懂不懂 SIP,如果你看到里面的一大堆 IP 地址明显感觉到不对,那就可能是不对。读懂 SIP 和 SDP 需要专业的知识,但这里描述的步骤可以让你快速定位到问题。如果你把这里收集到的日志拿给别人看,别人大概率也能帮你解决问题。但如果你只是说“我打不通电话”,那我只能给你看这篇文章。

能打通电话,双方都能听到,30 秒左右自动断

这个问题很典型,一般是一侧的 ACK 没有收到。在《FreeSWITCH Wireshark》这本书里详细的描述了问题原因及排查方法。

有时能打通,有时打不通

这个问题也难也简单。难是因为不容易重现,其实问题只要重现了就简单。无论如何,你要重现问题,对比通和不通的日志以及 SIP 消息,就是解决问题的关键。

奇怪,有些 SIP 包对方却收不到

这在发“大”包时经常出现。因为 IP 网络有个最大传输单元,一般的网络是1500字节,如果你使用 UDP 协议,但是你的 SIP 包超过了这个大小,可能会被分片,但被分片的 UDP 不能有效重组,所以在这种情况下对方可能收不到,也可能会收到“一半”的消息。

跟视频或 WebRTC 相关的 SIP 呼叫包通常会比较大。

488

一般跟媒体协商有关,可能双方没有共同的媒体编码,也可能是在 ICE 协商中找不到相关的 Candidate。

常见解题方法

笨办法往往是最有效的方法。

橡皮鸭解题法就是一种笨办法。

另一个笨办法就是“换”。换什么?

  • 换终端:用个其它的 SIP 终端试
  • 换服务器:你的 SIP 终端注册其他 SIP 服务器有没有问题?
  • 换网络
  • 换操作系统
  • 换网线:有时候网线也真会有问题
  • 换 IP 地址
  • 拨打另一个号码
  • 用另一个号码注册
  • 换用 UDP 或 TCP 或 TLS 等不同方式注册
  • DTMF 换 2833 或 Inband 方式,还有可能是 Info 等
  • 换其它的语音编码
  • 其他你想到的任何办法:要举一反三

小结

我上面说了很多,貌似很多,但又貌似没什么用。如果你感觉到有用,并按里面的步骤做了,相信你会很快查到问题所在。如果你感觉到没有用,可以找我们商业的技术支持,因为我们免费的技术支持可能对你没有太大帮助。记住:不管是免费还是商业支持,我们还是会问你上述那些问题,我们的工程师也是使用这些排查步骤。当然,我们的工程师也可能比较有经验,能快一点定位到问题。

最后,一点小 Tips:你所认为的 SIP 可能并不是 SIP。SIP 有很多概念和“坑”,也有很多认知误区,这个我们到后面再专门讲。

思考题

上面说的主要是一路电话的排查方法,比如从终端注册到 XSwitch 并拨打 9196。如果你两个分机互拨,或者通过网关出局,你就又多了故障点和排查对象。但只要掌握了上述方法,一段一段地查,就总能查出问题。读到这里,如果你还是不能解决问题,你知道怎么把你遇到的问题描述清楚了吗?

安装完毕后无法登录的排查方法