voip和rtc_企业级VoIP通信业务——SBC应用篇02 WebRTC的互通

WebRTC的商用已成趋势，自从微软宣布放弃Edge内核而使用Google的Chrome内核后，在浏览器这个领域，谷歌已经几乎可以被断定“利用WebRTC这个大杀器，完全可以垄断全球浏览器市场”，现在唯一还能与谷歌叫板的也就苹果了，不过有业内人士已经断言：苹果不是对手！主流浏览器对webrtc的支持能力测试对比图(出自：webrtc.org.cn 侵删)

好了，闲话少说！对于越来越多的WebRTC应用出现，最终WebRTC的归于何方呢？我们知道WebRTC本身是侧重于“可以使我们在浏览器或移动App中直接进行音频/视频交流的技术”，如同SIP协议中需要嵌套SDP协议“搭配使用”一样，WebRTC本身也必须嵌套信令协商协议(SIP或者Jingle等)才能真正通信协商。简单理解，可以作如下模型：

「udp「https「sip」」」：https封装sip，udp再封装https……(WebRTC是基于浏览器，因此在应用层使用https方式通信)。

WebRTC的信令使用SIP好处可谓多多，毕竟现在只要是非闭环的应用，尤其涉及到需要跟企业已有的VoIP通信系统对接，大多需要采用SIP来实现，也因此我上述模型中以SIP为例。

既然是SIP作为内嵌信令协议，就又回到之前几篇文章的老话题了，还是老三样：互通、NAT以及VoIP安全。WebRTC的应用场景是基于浏览器的，这导致有极大的可能性WebRTC客户端是处于最最让人头疼的互联网环境，而服务端往往藏于内网，可能中间需要打通多层DMZ，而来自互联网的SIP攻击也必须考虑，这几个方面的问题笔者简单提过，相信从业者都多少遇到过让人头疼不已的各种“现象”。虽然解决SIP带来的互通、NAT以及VoIP安全问题，不一定必须要使用SBC，但使用SBC却一定能解决。请琢磨笔者的这句话，毕竟SBC为此而生。

笔者所在的创业团队自研发的SBC已经在2019年初起的版本更新中就支持WebRTC，是目前全球最快支持WebRTC的产品级SBC，并且已经成功商用。在具体应用上，其基本的架构如下：

WebRTC客户端—|||—SBC——SIP SERVER/Web SERVER——SIP客户端(“|||”代表内外网边界，路由器/防火墙)

在上述架构中：

1、WebRTC客户端位于互联网，可置于企业的用户入口应用，比如官网Web、微信服务号、微信小程序、企业apps等，都是通过嵌入一个H5呼叫页面方式实现，实施非常快捷。

2、通过在网络边界部署支持WebRTC的SBC，可从应用层终结掉WebRTC，即剥离掉SIP外的https，完全“还原”成SIP后直接与企业现有的SIP SERVER(可能是呼叫中心，也可能是视频多媒体服务)进行交互，这有个大大的好处就是：对原有的VoIP系统几乎不产生任何影响即可兼容互通。

3、当然，SBC同时承担了来自WebRTC的安全威胁防护，VoIP跨网带来的NAT问题等。至于NAT为何有时候不能采用大家津津乐道的“ICE\STUN\TURN"方案来解决，等笔者整理完资料后再另起一篇，总之要记住，对于基于SIP的VoIP业务场景而言，ICE\STUN\TURN并不能100%解决SIP会话所遇到的NAT穿透问题。

PS: 有些功能强大的SBC本身也可以支持SIP SERVER的部分功能，在上述模型如果是点对点的音视频会话场景，还可以进一步简化为：WebRTC客户端—|||—SBC——SIP客户端，有兴趣的朋友私信了解。