说完基础知识之后,我们聊一些协议方面的东西,目前VOIP常用的主要有H233和SIP两种会话协议,音视频、远遥、双流、会话信息等由会话协议协商出关键参数,建立各自的协议通道,再在通道中按照各自的格式交互。有些厂家也会制定一些自己的的协议格式来满足功能需要,自定义的协议可以提升产品亮点,如可以提供更为丰富的会议控制功能,增加会议并发等;当然,他们也会提供公有协议的接入方式。
在对接协议过程中,会遇到一些问题,就其中典型的问题来聊一下:
1. VOIP限制
有些地方的网络会限制voip的使用,过滤掉voip协议。我们可以从网络监测来入手解决问题,在这种网络中,就不能再用tcp或udp来传输数据,可以用tls或者dtls来传输协议,必要的时候改变协议两端传输端口,基本可以解决问题。视频也要用加密的方式,如srtp来传输。如果依然不能突破限制,那么可以从数据传输层面入手,建立vpn来传输协议。
2. 协议标准
虽然SIP和H323协议涵盖的范围广泛,但VOIP所使用的也就几条协议和几个用法,有些设备对协议的支持非常有限,要想做好设备接入,要把握好几条:
① 降低消息依赖 这个原则类似于设计模式中的迪米特法则,你需要的对方信息尽量不要让对方来提供,因为消息实现是开放的,有些对方可能并没有实现,rfc文档里对很多消息都是should这种建议实现语气,而非must。Sip中invite/reinvite、register、ack这几条就足够了。尽量不要再发其它sip消息,消息越少越好。cisco、polycom、华为这些,也是这么做的。
② 兼容多种消息 一定要注意,我们说降低消息依赖,并不是说我们只要实现这几条消息就足够,程序或产品中,需要识别或响应尽可能多的消息,只是我们主动请求的最好保持在上述几条。
3. 扩展消息
像bfcp、h224、avp等是在sdp中协商的,是对sip能力本身的扩展。但是sdp本身也是开放的,只有格式的规定,并没有内容的具体规定。这些消息也有很大的灵活性。拿bfcp来说,可以协商tcp/udp两种传输格式,有些厂家会在bfcp的sdp中加上版本描述,有些厂家的回复信息中不会包含confid,uid等。这些灵活性也要求我们尽量做好兼容性。
4. 协议时序
Voip时多类协议协同作用的,当我们用分布式来部署服务或者rpc来调用接口的时候,很可能碰到时序问题,比如在会议连接刚建立时,如果会议中有人发送演示,bfcp消息有可能在演示流发送的rtp channel之前,也可能在rtp channel之后,如果我们不注意这种时序问题,没有及时准备好rtp通道,就会丢掉关键帧,演示流有时会黑屏。这种问题一般可以用异步的方式来解决。
还有一类时序问题,是在我们频繁切换状态的时候。比如我们极短的时间内频繁做演示流的发起和关闭操作。有些厂家产品由于设置了触发间隔,在无状态的会话中,两端的协议状态很可能不一致。
5. 云平台接入
云平台对外提供的登录地址一般是域名,有时会出现DNS解析无法定位到真正的sip服务器上,这个问题出现,要检查一下本地服务所使用的DNS解析是AAA方式还是SVR方式。有些平台的服务器部署会指定专属的sip或h323服务,DNS使用SVR请求才能解析到对应的服务器。