WebRTC测试的几个要点
WebRTC越来越多的进入到了实际的语音视频应用场景中。根据Gartner的预测,到2019年,we...
WebRTC 越来越多的进入到了实际的语音视频应用场景中。根据Gartner 的预测,到2019年,webrtc将占据语音和视频15%的市场份额。去年,也就是2015年,大约有850 个厂家或者项目在使用webrtc技术,过去两年则取得了100%的增长。则说明了webrtc 技术正在爆发。我们现在已经看到了webrtc技应用在了网页,app,呼叫中心,客服中心,和其他的商业用途。
但是因为此技术相对比较新,存在一些兼容性的问题和和传统语音网络的兼容性问题。通过市场调研和和语音通信方面的厂家实施发现,目前最核心的,也是用户最担心的问题或者兼容性的问题包括以下5个方面:
信令兼容性问题:关于信令问题,这也是老生常谈。到现在为止仍然存在信令不互通,不能兼容的问题,完全对牛弹琴。
呼叫控制问题。 呼叫控制更多是体现在企业通信中的一些业务流程,包括语音等待,电话转接,电话驻留等等功能。如果在webrtc 端进行设置发起呼叫以后,PBX热键是否支持,带宽占用增加等等因素都需要考虑。编码转换问题。语音编码转换是一直需要面对的问题。简单来说就是无解。最终的解决办法就是通过硬件DSP处理,但是增加成本;通过软件DSP处理,增加CPU负载,降低了系统的稳定性。webRTC 现在使用VP8和VP9来处理视频编码,传统的设备可能使用H264 编码,所以需要一个服务器进行编码处理。另外,语音编码也是类似的问题,Opus 是webRTC的主要编码格式,一般传统的PBX 或者软交换目前仍然没有支持Opus,开源的Asterisk和freeSWITCH已经支持了这样的编码。终端话机厂家也有少部分支持了Opus编码,这样就会导致很多兼容性的问题。当然还有很多app等等手机终端的编码也需要进行兼容性的测试。以下例子就是一个简单的编码转换的适用场景(Sangoma SBC),如果双方编码不一致,不能聊。需要转码。如果是会议视频的场景,可能需要服务器进行混屏等等各种,需要更多方面的技术考量。身份验证问题。网络上没有人知道你是是谁。你是一个动物还是一个someone 没有人知道。如果用户通过浏览器注册登录到企业内部通信的系统,或者作为一个内部分机电话来使用的话,需要身份验证包括用户名称,密码等等安全限制。如果没有非常安全的认证方式,可能出现企业通信系统的电话盗打或者接听通话等等安全事件发生。
- Kamailio/OpenSIP:大并发的软交换来测试。
- JSSIP :支持完整的javascript 终端开发包,可嵌入到网页中。
- Asterisk/FreeSWITCH:目前比较流行的媒体软交换系统。
- reSIProcate:支持完整的SIP协议栈,包括了多个模块。
- webrtc2sip:一个开源的webrtc gateway,通过界面浏览器可以实现对内部系统或者通信系统的PSTN呼出。目前测试效果非常一般。
- libnice:ICE 和STUN协商工具
- PJSIP:非常着名的SIP开源协议栈,不仅仅支持了标准的SIP协议,对SDP, RTP, STUN, TURN, 和 ICE 也有非常好的支持。
关注 CTI论坛
微信扫一扫关注公众号