VONR排查指导分享

1. 不能注册或呼叫到SIP服务器端
2. 30秒挂断呼叫的黄金法则
3. 咬线或摘机状态
4. 单通或无语音
5. 收到400 bad request
6. 收到413，513 Request Entity Too Large或Message Too Large消息
7. 收到408， 480或者487 消息
8. 483 - Too Many Hops
9. 488 – Not Acceptable Here
10. 语音质量和思科语音文件示例分享

　　这里，读者一定要注意，我们这里仅讨论关于SIP环境中的常见问题，可能涉及网络环境或者硬件终端的问题，因为很多厂家和SIP服务器的配置不同，可能存在一定的差异，所以用户在我们的方法中特别需要根据厂家的不同，增加一些专门针对每个厂家或者SIP服务器的排查方式。我们仅讨论一般情况下的排查方式。

　　1、在一般的SIP 环境中，通常来说，SIP 终端需要注册到SIP服务器端来实现认证，服务器端获得SIP终端的位置，然后才能进行正常的呼叫流程。注册问题可能有以下几种呈现方式：

• 不能注册，完全没有和SIP服务器连接。如果终端发送注册消息给服务器端时，双方完全可能完全没有实现通讯。用户需要在服务器端通过日志排查方式，检查SIP终端是否有注册消息进入到服务器端，或者SIP终端通过网络工具对服务器端进行排查，例如使用Ping 命令。如果连Ping命令都检测不到服务器地址，基本上可以断定SIP终端根本没有和服务器端连接。关于服务器端排查方式很多，最典型的就是使用的Asterisk，FreeSWITCH，OpenSIPS或者Kamailio等开源的软交换平台。每个平台都有各自的排查命令，用户可以参考官方手册来判断。当然，用户也可以使用linux排查工具对5060端口抓包排查（例如，sngrep）。本人非常推荐这个工具，非常好用，可以实时检查SIP消息。

 

 

• SIP终端发出了注册消息，但是SIP服务器端没有返回的消息。如果SIP终端对SIP服务器端发送了注册消息，但是服务器端没有返回响应消息，则可能是服务器端的问题。用户需要排查服务器端为什么没有返回消息，或者在返回路径上的节点是否出现了问题。
• 客户端收到错误消息，收到太多401/407 Unauthorized。SIP终端在注册时，如果用户的安全设置出现了错误，可能导致服务器端发送多个 401 错误。服务器端第一次发送到是正常的401验证信息，如果连续多次发送401/407 错误的话，可能是SIP终端输入了错误的用户账号信息，SIP终端侧需要配合服务器端进行排查，也可能服务器端的SIP账号消息保存错误，或者没有重新加载服务器相应模块，用户最好通过服务器端的CLI命令来检查内存中的SIP终端的真实数据信息。
• 

• 客户端收到403 Forbidden 消息。如果用户帐户信息没有问题的话，SIP终端可能没有输入正确的From domain或者R-URI。有时，服务器端禁止同时注册几个SIP终端账号，或者注册过于频繁，服务器端可能过滤了此地址。需要用户配合服务器端地址进行进一步检查。这里，笔者仅讨论注册阶段出现的403 问题，当然也可能是系统防火墙或者其他的配置禁止了注册消息。如果是呼叫时出现403的话，则可能是另外的原因，例如可能欠费，可能呼叫了服务器端禁止的号码码位等其他因素。
• 

　2、我们经常会遇到客户抱怨这样的问题，电话通话时，在大概30秒左右就断线。这样的问题最主要的原因是SIP终端没有收到ACK消息。SIP终端发送了 200 OK以后就开始了媒体的创建，RTP语音流开始启动，事实上，SIP终端可能还没有收到ACK消息，因此在30秒左右，没有收到消息的一方就发送了一个BYE消息。那么，为什么我们没有收到ACK消息呢？

 　具体的场景如下两种示例，返回时因为NAT问题导致ACK没有办法返回到相应的终端：

 

 

 

在很多应用场景中，用户可能遇到更为复杂的NAT环境，如果其中一个代理出现了NAT处理无效的结果，就可能导致整个SIP信令路径出现ACK丢失的问题。

 

　　一般情况下，缺少ACK消息的原因主要来自于以下几个方面：

• Contact header 错误
• 客户端没有支持router header
• 网关在NAT后
• Contact header 的地址在NAT后

　　以上几种情况都需要用户排查网络环境和NAT设置。因为NAT问题，ACK返回的路径地址发生了改变，所以SIP终端没有收到ACK消息。

　　一些厂家的设备或者媒体服务器也有类似的设置，例如Lync 服务器，它支持了RTCP 呼叫活动检测功能，如果超过30秒的检测周期没有收到RTCP数据包，则会挂机。在开源Asterisk平台上，RTP的默认设置时间为30秒，一些SIP运营商可能会忽略UPDTAE消息，在SIP的设置中可以对其进行设置调整disallowed_methods=UPDATE 或SIP的会话定时器设置。

　　3、SIP终端不能挂机或者处于摘机状态是第三个经常遇到的问题。在SIP终端中的表现形式为终端没有发送BYE消息或者发送了错误的BYE消息内容。

没有发送BYE的状态：

 

　　其原因主要表现在：

• 没有发送BYE消息
• 发送到BYE消息携带了错误的to-tag
• 发送了格式不规范的BYE消息，例如格式错误，sequences错误或者时间戳错误。
• 发送的BYE消息中携带的是错误的路由信息

　　对于出现的这些问题，用户需要根据SIP消息来进行排查，对比哪些路径节点出现了问题。当然，这些问题带来的结果大家可能都非常清楚。首先，计费的准确性出现了问题，用户的计费不能完整准确地监控。另外，如果媒体服务器对呼叫有限制的话，因为其中一个SIP终端没有真正挂机，其他用户可能不能呼出的问题。如果是一台模拟网关的话，可能出现FXO或者FXS不能正常工作的问题。

　　出现以上这些问题，读者还是要从终端的配置来解决问题，是否出现了终端的配置问题，终端的质量问题。如果是FXO或者FXS的话，是否出现了制式不匹配的问题导致咬线或者摘机的问题。

　　从服务器端处理的话，可以通过两种办法来通过服务器端对其进行强制挂机处理。这四种服务器端的检测方式是：

• 开启RTP超时检测来检测终端的RTP流是否仍然活动
• 开启SIP的KeepAlive 检测SIP 会话状态
• 使用Proxy中的dialog中的OPTION来检测SIP终端响应状态，SIP终端发送 200 OK到proxy来检测终端的状态。
• 使用SIP session timer 定时器来进行周期检测，SIP终端一直在周期内刷新自己的状态。如果SIP终端来定时器的时间范围内，则表示终端参与活动状态；否则，则对其发送BYE消息，强行挂机。