完整webRtc技术及应用概要

Web Real-Time Communication(WebRTC)是最近几年非常热门的一项新的基于浏览器的技术，很多VoIP的厂家和应用集成厂家的解决方案中都逐渐支持了WebRTC技术。WebRTC技术通过对浏览器或者移动终端应用，结合API接口，实现了视频，语音功能。当然，WebRTC受到如此多重视，当然也离不开主要的推动者Google，微软，Mozilla等大牌厂家的鼎力支持，以及几个著名的协议组织，例如，W3C和IETF的协助。

虽然，网络上有很多关于WebRTC的文章，这些文章通过不同的角度对WebRTC做了非常详细的介绍，WebRTC官方网站也发布了有很多的文档。但是，很多网上的文章比较零散，讨论的角度都不一样。另外，很多权威的文档和纸质书基本上都是以英文出版，一些读者的英文阅读能力没有那么高的话，可能影响对技术的消化吸收。为了给中国读者提供一个比较全面的完整的关于WebRTC的技术以及应用概要，笔者希望通过一个完整的篇幅，对WebRTC技术做一个比较系统，完整地描述介绍，其内容包括从WebRTC背景知识，媒体流，相关的协议栈，NAT处理，安全以及隐身设置，WebRTC当前的问题以及未来的提升，WebRTC用户使用场景，和开源WebRTC媒体服务器以及视频会议，WebRTC测试工具等知识点，让普通读者能够通过一篇文章就对WebRTC技术有一个非常清晰的思路，为进一步学习WebRTC技术做一个有效铺垫，读者可以快速进入到真正的WebRTC技术应用开发中。在十一个章节中，笔者会根据WebRTC技术的架构以及相关的应用做一个完整的介绍。

1.WebRTC的技术背景介绍

首先让我们简单了解一下基本的通信背景知识。如果从实时通信和语音协议的发展来看，最早的语音通信协议应该发生在1977年，人们把实时通信技术通过Network Voice Protocol（NVP-rfc741）在网络上应用，并且演示了其技术的可用性。在语音发展过程中，实时通信开始也经历了多个历史阶段，并且结合其他的技术逐渐实现了突破。以下是一个关于语音技术的部分阶段的发展进程。

如下图示例所示，最初的工作模型也相对比较简单，随着技术的不断完善和协议的修改，今天的语音技术已经出现了很大的突破。具体关于NVP的规范，读者可以查阅rfc741获得详情。

在提到实时通信技术或者WebRTC技术，我们还要简单介绍一下实时传输协议RTP，此技术最早在1992年左右开始使用，1996年作为一个标准发布。目前RTP是VoIP，SIP或者WebRTC的其中一个部分。

除了RTP协议以外，H323和SIP协议也是我们进入讨论WebRTC之前需要介绍的背景知识。H323在1996年有ITU发布，SIP在1999年由IETF发布。在最近几十年的语音视频领域，这两种协议在语音和视频技术扮演者非常重要的角色。当然，现在被用户和市场认可的是SIP协议，H323用户逐渐变少。

WebRTC受到青睐原因很多，我们会在下面的章节中加以介绍。其主要原因是它的易用性，并且可以借用当前用户浏览器的其他媒体设备，例如麦克风和摄像头，通过浏览器的API接口直接访问这些网络资源，用户无需再安装下载其他的插件来获得对网络资源的支持。WebRTC也可以实现点对点的网络互动，可以避免远程服务器的网络访问问题。特别是VoLTE网络环境中，语音可以通过数据通道来实现，这样就会极大方便终端用户的语音视频通信。另外，现在很多的在线游戏也可以通过浏览器的形式展现游戏场景，用户实现了和同学，朋友通过语音，数据和视频同时进行互动交流。

现在，我们简单介绍一下WebRTC的功能实现。WebRTC的功能包括以上几个核心的模块和API接口。用户浏览器通过和HTML，其他的脚本语言和客户端的接口进行调用。特别注意，在浏览器的RTC功能中，特别包括了传输的编码，回声处理等功能。其他的媒体数据可以通过RTC功能和WebRTC实现通信。

WebRTC受到市场的认可有很多原因。它主要包括以下几个方面的原因：

• 平台和设备的独立。开发人员可以通过支持WebRTC的浏览器开发基于WebRTC的各种应用，无需担心终端和操作系统层面的兼容性问题。另外，WebRTC也提供了标准的API（W3C）和其标准的协议支持（IETF）避免了平台兼容性的问题。

• 语音和视频的安全处理, WebRTC通过SRTP对语音和视频进行加密处理。用户使用浏览器登录访问语音和视频需要比较安全的设置要求，满足了用户场景的安全要求（例如，在无安全保障的wifi环境下的语音和视频），其他人不能对其进行监听。

• 支持高级语言和视频处理，WebRTC支持了最新的编码，语音支持了Opus，视频支持了VP8。内置的编码排除了其他第三方下载的安全隐患，同时能够支持网络环境的调整，实现了比较好的语音或视频质量。

• 支持可靠性传输创建，WebRTC提供了可靠性传输方式，包括了在NAT环境下仍然可以实现传输的稳定性。

• 支持多媒体流处理，WebRTC提供了多媒体和多资源的聚和，提供了RTP和SDP的拓展。

• 支持不同网络环境调节，因为WebRTC在网络平台执行，所以对网络环境和带宽非常敏感。它可以自己检测，调整网络环境和带宽需求，避免网络拥塞。它通过RTCP和SAVPF来保障此功能。

• 和VoIP语音视频有比较好的兼容性，WebRTC实现了和其他媒体的兼容性操作，包括了SIP，Jingle和XMPP对接。同时，如果需要和传统的其他协议对接的话，可以通过WebRTC 网关来实现兼容性的流畅性，保证和传统协议的兼容性。

使用WebRTC对开发人员和用户有以下几个方面的好处：

• 开发人员可以无需担心平台的兼容性，实现无缝集成。

• 开发人员可以使用简单的API接口就可以实现应用开发。

• 开发人员无需担心NAT带来的问题。

• 开发人员可以使用比较高级的编码资源，无需承担商业许可证费用。

• 用户无需安装即可使用。

• 用户所有通信都是加密的。

• 用户可以实现可靠性传输。

• 用户可以使用高清语音和视频。

• 用户可以选择更多的实时通信手段。

接下来，我们简单介绍一下WebRTC的著名三角形拓扑示例：

以上示例是一个非常普遍的应用流程示意图，用户可以到官方网站获得其流程的其他说明。特别指出的是，在语音通信环境中，可能很多用户关心的是如何实现和SIP，PSTN的网络聚合。我们再列举几个和语音环境相关的集成方案示例。

如果WebRTC实现对PSTN呼叫的话，事实上还是经过SIP/PSTN网关的转换，可以支持FXO/FXS或者E1接入方式。

如果一些IPPBX（旧版本的IPPBX）没有支持WebRTC的话，或者为了避免WebRTC对接带来的问题，也可以通过WebRTC网关来对接传统的SIP/IPPBX，然后实现IPPBX+WebRTC网关+浏览器WebRTC应用的应用场景。笔者在两年前使用FreePBX-2.5 结合portSIP WebRTC 网关实现的一个案例。

在以上示例中，IPPBX使用的是FreePBX开源的企业IPPBX，PSTN接入可以使用语音板卡或者PSTN语音网关或者无线网关来实现，通过portsip WebRTC网关实现和浏览器终端的对接。因为客户端要求，接入方使用了鼎信通达的无线网关实现，使用了SIM卡直接呼叫。

2.WebRTC 媒体流处理

在WebRTC环境中，每个终端都不同，它们具有各自的访问方式。以下示例说明了各种终端进行WebRTC媒体流处理的流程。有的终端可能在家庭网络环境，有的终端可能在公司内网环境，有的终端可能在咖啡馆使用wifi上网。应用服务器则在公网环境中。

如果在网络一般正常的网络环境中，如果没有WebRTC的话，两个终端之间的通信只能通过页面服务器来做一个路由处理和交换。但是，如果服务器和终端之间存在网络稳定性问题或者距离比较远的话，那终端之间的实时通信就很难得到保证。

如果浏览器支持了WebRTC的话，两个终端之间可以不通过服务器端进行路由，同时可以解决NAT问题，终端之间可以直接实现点对点通信，这样就保证了实时通信的稳定性。

在上面的介绍中，我们讨论了WebRTC中的NAT问题。关于NAT问题，我们在前面的很多章节中已经多次提及，这里不再过多对NAT做说明。今天，我们重点讨论WebRTC中的NAT问题。WebRTC内置的策略机制（Interactive Connectivity Establishment ）用来解决NAT问题。在点对点的通信中，ICE通