作者: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过程中需要注意的几个点，包括了从信令，呼叫控制，编码，安全，双方验证等等问题。当然根据网络环境的不同，业务大小的不同，和部署方式的不同用户需要针对性地做一些特别的关注。
