售前电话
135-3656-7657
售前电话 : 135-3656-7657
在VoIP的环境中,特别是基于SIP通信的环境中,我们经常会遇到一些非常常见的问题,例如,单通,30秒就断线,注册问题,回声等。这些问题事实上都有非常直接的排查方式和解决办法,用户可以按照一定的排查方式,工具非常高效地解决这些问题。但是,因为读者技术水平参差不齐,网络上的很多技术也不完整。笔者今天系统归纳了这些问题。根据一些用户的使用环境和用户经常遇到一些问题,我们列举了以下十个在SIP呼叫中经常遇到的问题,并且给出了相应的排查方式,用户可以按照这些方法来解决SIP通话中的这些问题。这十个经典的问题包括:
不能注册或呼叫到SIP服务器端
30秒挂断呼叫的黄金法则
咬线或摘机状态
单通或无语音
收到400 bad request
收到413,513 Request Entity Too Large或Message Too Large消息
收到408, 480或者487 消息
483 - Too Many Hops
488 – Not Acceptable Here
语音质量和思科语音文件示例分享
这里,读者一定要注意,我们这里仅讨论关于SIP环境中的常见问题,可能涉及网络环境或者硬件终端的问题,因为很多厂家和SIP服务器的配置不同,可能存在一定的差异,所以用户在我们的方法中特别需要根据厂家的不同,增加一些专门针对每个厂家或者SIP服务器的排查方式。我们仅讨论一般情况下的排查方式。
一、在一般的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的话,则可能是另外的原因,例如可能欠费,可能呼叫了服务器端禁止的号码码位等其他因素。
二、我们经常会遇到客户抱怨这样的问题,电话通话时,在大概30秒左右就断线。这样的问题最主要的原因是SIP终端没有收到ACK消息。SIP终端发送了 200 OK以后就开始了媒体的创建,RTP语音流开始启动,事实上,SIP终端可能还没有收到ACK消息,因此在30秒左右,没有收到消息的一方就发送了一个BYE消息。那么,为什么我们没有收到ACK消息呢?具体的场景如下两种示例,返回时因为NAT问题导致ACK没有办法返回到相应的终端: