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