移动互联网SIP在线状态方案分析

        经过近10年的发展，SIP己发展成做音视频通信的首选标准协议。如今在移动互联网背景下，SIP得到广泛应用的同时也面临诸多挑战，我们今天要聊的在线状态就是其中之一。SIP是一个非常灵活的协议，可应用于音视频、IM等场景，基于其高扩展性，实际可用于任何数据的通信协商。在其主要应用场景音视频通信中，为保证用户体验，在线状态的准确显得尤为重要。

        SIP协议在定义之初，主要是基于UDP进行设计。在线和离线是靠SIP REGISTER 请求完成的，当UA执行REGISTER后，服务器端会在返回的200OK消息中expires参数告知客户端此次注册有效期，UA需要在expires到期之前进行续约，如果到期未续约，服务器即认为客户端离线，在互联网时候这看上去没有什么问题，因为用户的网络多数情况下不会异常中断。但加上移动两个字，这一切就变得很糟糕了：用户的网络会随时中断，从一个WIFI自动换到另一个WIFI，进电梯出电梯，在移动设备上，断网那是很正常的事，不断才不正常。如果用户刚发送REGISTER后就断网了，那此用户的假在线状态将持续到整个expires周期。下面分别就TCP和UDP探讨一种可行性方案。

         理想中的在线状态即服务端能以最短的时间探知客户端状态变化，基于UDP无连接的特点，一个看似简单有效的方法缩短续约周期，如将REGISTER周期改为60秒，同时客户端断线重连，这样用户状态有效期只有60秒，一但超过60秒未注册就将用户状态置为离线，这样至少存在三个严重问题：

1.流量高：SIP协议完成一次注册再加上www-authenticate鉴权，需要耗费2K左右的流量，一天就需要3M左右，这样的软件用户只能放弃。
2.状态变更频率：在3G网络下，某些基站会对UDP包进行缓存（完全是看运营商心情的），优先级没有TCP高，所以UDP延迟大是非常正常的事情，客户端在注册周期提前10秒进行注册，也不能保证服务器能在10秒内接收到，因此在客户端的好友端其在线状态将容易出现反复变化。
3.上面的周期假设了UDP NAT映射有效期至少大于60秒，但这个假设非常不靠谱。在实际应用环境中，国内某小运营商针对某些端口的有效期是8秒，难道我们要把续约周期改成8秒？

        针对以上问题，RFC 5626提出STUN keepalive方案，使用STUN来代替SIP的REGISTER保话NAT，因此可以将SIP REGISTER的周期加长。同时服务器需要做STUN保活检测，即多少时间内累计多少次未收到客户端STUN保活包即认为客户端离线，客户端也需要做同样检测，多少次未收到STUN 响应包就认为断线并重新注册，具体次数在RFC中有定义，也可以根据实际情况调整。这样对前面前两个问题能够比较好的改善，但第三个问题呢？ 这里就需要实现UDP NAT保活自适应了，可先使用默认间隔发次STUN包，收到响应包发现NAT地址变化那就说明保话时间过短，然后再尝试一个更短的间隔时间，当然具体算法可以再进行优化。服务器端支持STUN keepalive的有opensips、kamailio，SIP UA我知道pjsip支持，其他未考证。

        根据多个项目经验，基于中国网络的特点，移动互联网SIP使用TCP传输会更适合一些，对于前面同样的问题，RFC 5626也提出TCP sip keepalive方案。具体是客户端以‘\r\n\r\n’作发送PING给服务器，服务器以'\r\n'为PONG回复。并且TCP是面向连接的，本身也可以使用TCP 协议层的keepalive，但TCP协议层的keepalive缺点是只能检测单方向的连接是否正确，如果要检测两方那通信双方都需要开启keepalive功能。opensips/kamailio同样支持 TCP sip keepalive方案。在opensips/kamailio上实现这样一个功能，当客户端TCP连接断开时，自动将客户端的注册信息删除掉，这样实现了当服务器端TCP连接断开时将用户设置为离线，同时客户端也需要使用TCP sip keepalive检测到网络断线后自动进行重连，这样就可以将注册周期改到很长，且只要TCP不断那用户的注册信息就一直有效。这种方案相比UDP更节省流量，客户端和服务器都能更快/有效的判断网络是否断线。对于TCP NAT保活也只有使用自适应的方法，TCP可以同时建立N个连接，然后以不同的周期发送keepalive包，以能够成功保活的最长周期为应用值，此方法好像被某公司申请过专利了。

       也许4G网络的到来这一切就都迎刃而解，与之而来的是视频通信的春天，还是技术壁垒的恶梦？

参考资料：
http://tools.ietf.org/html/rfc5626

新浪微博：@安静的发狂者
邮箱：dennis.yu(@)live.cn
QQ:229675152
专注于移动互联网音视频通信，欢迎交流；本文为原创，转载请保留版权并联系作者

kamailio/opensips 技术交流QQ群：118791050