WebRTC的突然火爆，实际上暗藏了不少问题。Gartner给出预测，到2019年，WebRTC有望占据15%的音视频市场份额。仅仅在两年前，只有850个项目敢试用这个技术，而现在这个数量翻了一番。网页、App、呼叫中心还有客服系统，但凡有音视频需求的地方，都在往WebRTC靠拢。技术虽然新颖，但兼容性问题依旧是大麻烦。经过调研，用户遇到的五个主要问题集中在以下领域。信令系统往往出现障碍，SIP和WebSocket之间的互操作成了难题。有些老设备只懂传统协议，导致WebRTC在实际使用中经常遇到信令不通的情况。呼叫控制过程也可能出现偏差。企业原来的流程在WebRTC中可能被简化或者错位处理。电话等待音乐、转接还有驻留等业务流，在WebRTC里可能只是被当作普通呼叫处理。这导致PBX热键失效、带宽突增还有话务员手忙脚乱等问题。编码格式的转换也是个大问题。终端可能用VP8或VP9编码格式，而会议服务器习惯使用H.264或者Opus格式。这种转换需要服务器扮演翻译官的角色，导致CPU负荷过高、延迟增加还有丢包率上升。身份验证也容易出现漏洞。仅靠用户名和密码进行认证非常脆弱，容易被盗打或产生垃圾通话。这就像把通信系统敞开大门一样容易遭受攻击。安全方面同样存在隐患。传统PBX通常不加密通信内容，而WebRTC却必须使用SRTP或者TDLS-SRTP进行加密。这给网关带来了额外的负担。 传统语音通信常常躲在防火墙后面，NAT还有ACL把大门锁得死死的。WebRTC使用ICE（交互式连接建立）来解决这个问题。ICE需要进行三次握手：先尝试直接P2P连接，然后再使用STUN和TURN进行中转。然而这三个过程都面临不少挑战：ICE候选耗时较长、TURN占用带宽资源、STUN应答不稳定等等。“几秒接通”成为用户体验最关键的指标之一，同时也是测试中最棘手的问题之一。 社区已经为开发者准备了许多工具来应对这些挑战。比如Kamailio/OpenSIP提供强大的软交换能力，JSSIP是纯JavaScript开发的终端SDK，Asterisk/FreeSWITCH是成熟的媒体服务器等等。开发者可以利用这些工具先让系统跑起来再进行优化。未来还有很多新技术值得关注，比如VP9、H.265还有E-SBC（带SIP防火墙的Session Border Controller）。部署前需要特别注意信令协议互通性、呼叫流程符合企业要求以及安全认证与加密覆盖端到端。网络环境、业务规模和部署方式不同，“因地制宜”比一刀切更重要。只有把这五大问题逐个击破，WebRTC才能真正从“火爆”走向“靠谱”。