初探WebRTC - 推酷
初探WebRTC
什么是WebRTC？
众所周知，浏览器本身不支持相互之间直接建立信道进行通信，都是通过服务器进行中转。比如现在有两个客户端，甲和乙，他们俩想要通信，首先需要甲和服务器、乙和服务器之间建立信道。甲给乙发送消息时，甲先将消息发送到服务器上，服务器对甲的消息进行中转，发送到乙处，反过来也是一样。这样甲与乙之间的一次消息要通过两段信道，通信的效率同时受制于这两段信道的带宽。同时这样的信道并不适合数据流的传输，如何建立浏览器之间的点对点传输，一直困扰着开发者。WebRTC应运而生
WebRTC是一个开源项目，旨在使得浏览器能为实时通信（RTC）提供简单的JavaScript接口。说的简单明了一点就是让浏览器提供JS的即时通信接口。这个接口所创立的信道并不是像WebSocket一样，打通一个浏览器与WebSocket服务器之间的通信，而是通过一系列的信令，建立一个浏览器与浏览器之间（peer-to-peer）的信道，这个信道可以发送任何数据，而不需要经过服务器。并且WebRTC通过实现MediaStream，通过浏览器调用设备的摄像头、话筒，使得浏览器之间可以传递音频和视频
WebRTC已经在我们的浏览器中
这么好的功能，各大浏览器厂商自然不会置之不理。现在WebRTC已经可以在较新版的Chrome、Opera和Firefox中使用了，著名的浏览器兼容性查询网站caniuse上给出了一份详尽的浏览器兼容情况
另外根据35Kr前段时间的新闻
，Android也开始支持WebRTC
WebRTC实现了三个API，分别是:
* MediaStream：通过MediaStream的API能够通过设备的摄像头及话筒获得视频、音频的同步流
* RTCPeerConnection：RTCPeerConnection是WebRTC用于构建点对点之间稳定、高效的流传输的组件
* RTCDataChannel：RTCDataChannel使得浏览器之间（点对点）建立一个高吞吐量、低延时的信道，用于传输任意数据
这里大致上介绍一下这三个API
MediaStream（getUserMedia）
MediaStream API为WebRTC提供了从设备的摄像头、话筒获取视频、音频流数据的功能
同门可以通过调用navigator.getUserMedia()，这个方法接受三个参数：
1. 一个约束对象（constraints object），这个后面会单独讲
2. 一个调用成功的回调函数，如果调用成功，传递给它一个流对象
3. 一个调用失败的回调函数，如果调用失败，传递给它一个错误对象
浏览器兼容性
由于浏览器实现不同，他们经常会在实现标准版本之前，在方法前面加上前缀，所以一个兼容版本就像这样
var getUserMedia = (navigator.getUserMedia ||
navigator.webkitGetUserMedia ||
navigator.mozGetUserMedia ||
navigator.msGetUserMedia);
一个超级简单的例子
这里写一个超级简单的例子，用来展现getUserMedia的效果：
&!doctype html&
&html lang=&zh-CN&&
&meta charset=&UTF-8&&
&title&GetUserMedia实例&/title&
&video id=&video& autoplay&&/video&
&script type=&text/javascript&&
var getUserMedia = (navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia || navigator.msGetUserMedia);
getUserMedia.call(navigator, {
video: true,
audio: true
}, function(localMediaStream) {
var video = document.getElementById('video');
video.src = window.URL.createObjectURL(localMediaStream);
video.onloadedmetadata = function(e) {
console.log(&Label: & + localMediaStream.label);
console.log(&AudioTracks& , localMediaStream.getAudioTracks());
console.log(&VideoTracks& , localMediaStream.getVideoTracks());
}, function(e) {
console.log('Reeeejected!', e);
将这段内容保存在一个HTML文件中，放在服务器上。用教新版本的Opera、Firefox、Chrome打开，在浏览器弹出询问是否允许访问摄像头和话筒，选同意，浏览器上就会出现摄像头所拍摄到的画面了
注意，HTML文件要放在服务器上，否则会得到一个NavigatorUserMediaError的错误，显示PermissionDeniedError，最简单方法就是cd到HTML文件所在目录下，然后
python -m SimpleHTTPServer
（装了python的话），然后在浏览器中输入
http://localhost:8000/{文件名称}.html
getUserMedia
获得流之后，需要将其输出，一般是绑定到
标签上输出，需要使用
window.URL.createObjectURL(localMediaStream)
来创造能在
属性播放的Blob URL，注意在
属性，否则只能捕获到一张图片
流创建完毕后可以通过
属性来获得其唯一的标识，还可以通过
getAudioTracks()
getVideoTracks()
方法来获得流的追踪对象数组（如果没有开启某种流，它的追踪对象数组将是一个空数组）
约束对象（Constraints）
约束对象可以被设置在
getUserMedia()
和RTCPeerConnection的
方法中，这个约束对象是WebRTC用来指定接受什么样的流的，其中可以定义如下属性：
* video: 是否接受视频流
* audio：时候接受音频流
* MinWidth: 视频流的最小宽度
* MaxWidth：视频流的最大宽度
* MinHeight：视频流的最小高度
* MaxHiehgt：视频流的最大高度
* MinAspectRatio：视频流的最小宽高比
* MaxAspectRatio：视频流的最大宽高比
* MinFramerate：视频流的最小帧速率
* MaxFramerate：视频流的最大帧速率
RTCPeerConnection
WebRTC使用RTCPeerConnection来在浏览器之间传递流数据，这个流数据通道是点对点的，不需要经过服务器进行中转。但是这并不意味只我们能抛弃服务器，我们仍然需要它来为我们传递信令（signaling）来建立这个信道。WebRTC没有定义用于建立信道的信令的协议：信令并不是RTCPeerConnection API的一部分
既然没有定义具体的信令的协议，我们就可以选择任意方式（AJAX、WebSocket），采用任意的协议（SIP、XMPP）来传递信令，建立信道，比如我写的
，就是用的node的ws模块，在WebSocket上传递信令
需要信令来交换的信息有三种：
* session的信息：用来初始化通信还有报错
* 网络配置：比如IP地址和端口啥的
* 媒体适配：发送方和接收方的浏览器能够接受什么样的编码器和分辨率
这些信息的交换应该在点对点的流传输之前就全部完成，一个大致的架构图如下：
通过服务器建立信道
这里再次重申，就算WebRTC提供浏览器之间的点对点信道进行数据传输，但是建立这个信道，必须有服务器的参与。WebRTC需要服务器对其进行四方面的功能支持：
1. 用户发现以及通信
2. 信令传输
3. NAT/防火墙穿越
4. 如果点对点通信建立失败，可以作为中转服务器
NAT/防火墙穿越技术
建立点对点信道的一个常见问题，就是NAT穿越技术。在处于使用了NAT设备的私有TCP/IP网络中的主机之间需要建立连接时需要使用NAT穿越技术。以往在VoIP领域经常会遇到这个问题。目前已经有很多NAT穿越技术，但没有一项是完美的，因为NAT的行为是非标准化的。这些技术中大多使用了一个公共服务器，这个服务使用了一个从全球任何地方都能访问得到的IP地址。在RTCPeeConnection中，使用ICE框架来保证RTCPeerConnection能实现NAT穿越
ICE，全名叫交互式连接建立（Interactive Connectivity Establishment）,一种综合性的NAT穿越技术，它是一种框架，可以整合各种NAT穿越技术如STUN、TURN（Traversal Using Relay NAT 中继NAT实现的穿透）。ICE会先使用STUN，尝试建立一个基于UDP的连接，如果失败了，就会去TCP（先尝试HTTP，然后尝试HTTPS），如果依旧失败ICE就会使用一个中继的TURN服务器。
我们可以使用Google的STUN服务器：
stun:stun.:19302
，于是乎，一个整合了ICE框架的架构应该长这个样子
浏览器兼容
还是前缀不同的问题，采用和上面类似的方法：
var PeerConnection = (window.PeerConnection ||
window.webkitPeerConnection00 ||
window.webkitRTCPeerConnection ||
window.mozRTCPeerConnection);
创建和使用
//使用Google的stun服务器
var iceServer = {
&iceServers&: [{
&url&: &stun:stun.:19302&
//兼容浏览器的getUserMedia写法
var getUserMedia = (navigator.getUserMedia ||
navigator.webkitGetUserMedia ||
navigator.mozGetUserMedia ||
navigator.msGetUserMedia);
//兼容浏览器的PeerConnection写法
var PeerConnection = (window.PeerConnection ||
window.webkitPeerConnection00 ||
window.webkitRTCPeerConnection ||
window.mozRTCPeerConnection);
//与后台服务器的WebSocket连接
var socket = __createWebSocketChannel();
//创建PeerConnection实例
var pc = new PeerConnection(iceServer);
//发送ICE候选到其他客户端
pc.onicecandidate = function(event){
socket.send(JSON.stringify({
&event&: &__ice_candidate&,
&candidate&: event.candidate
//如果检测到媒体流连接到本地，将其绑定到一个video标签上输出
pc.onaddstream = function(event){
someVideoElement.src = URL.createObjectURL(event.stream);
//获取本地的媒体流，并绑定到一个video标签上输出，并且发送这个媒体流给其他客户端
getUserMedia.call(navigator, {
&audio&: true,
&video&: true
}, function(stream){
//发送offer和answer的函数，发送本地session描述
var sendOfferFn = function(desc){
pc.setLocalDescription(desc);
socket.send(JSON.stringify({
&event&: &__offer&,
&sdp&: desc
sendAnswerFn = function(desc){
pc.setLocalDescription(desc);
socket.send(JSON.stringify({
&event&: &__answer&,
&sdp&: desc
//绑定本地媒体流到video标签用于输出
myselfVideoElement.src = URL.createObjectURL(stream);
//向PeerConnection中加入需要发送的流
pc.addStream(stream);
//如果是发送方则发送一个offer信令，否则发送一个answer信令
if(isCaller){
pc.createOffer(sendOfferFn);
pc.createAnswer(sendAnswerFn);
}, function(error){
//处理媒体流创建失败错误
//处理到来的信令
socket.onmessage = function(event){
var json = JSON.parse(event.data);
//如果是一个ICE的候选，则将其加入到PeerConnection中，否则设定对方的session描述为传递过来的描述
if( json.event === &__ice_candidate& ){
pc.addIceCandidate(new RTCIceCandidate(json.data.candidate));
pc.setRemoteDescription(new RTCSessionDescription(json.data.sdp));
由于涉及较为复杂灵活的信令传输，故这里不做简短的实例，可以直接移步到最后
RTCDataChannel
既然能建立点对点的信道来传递实时的视频、音频数据流，为什么不能用这个信道传一点其他数据呢？RTCDataChannel API就是用来干这个的，基于它我们可以在浏览器之间传输任意数据。DataChannel是建立在PeerConnection上的，不能单独使用
使用DataChannel
我们可以使用
channel = pc.createDataCHannel(&someLabel&);
来在PeerConnection的实例上创建Data Channel，并给与它一个标签
DataChannel使用方式几乎和WebSocket一样，有几个事件：
* onmessage
同时它有几个状态，可以通过
readyState
* connecting: 浏览器之间正在试图建立channel
* open：建立成功，可以使用
方法发送数据了
* closing：浏览器正在关闭channel
* closed：channel已经被关闭了
两个暴露的方法:
* close(): 用于关闭channel
* send()：用于通过channel向对方发送数据
通过Data Channel发送文件大致思路
JavaScript已经提供了File API从
input[type='file']
的元素中提取文件，并通过FileReader来将文件的转换成DataURL，这也意味着我们可以将DataURL分成多个碎片来通过Channel来进行文件传输
一个综合的Demo
，这是我写的一个Demo。建立一个视频聊天室，并能够广播文件，当然也支持单对单文件传输，写得还很粗糙，后期会继续完善
下载解压并cd到目录下
npm install
安装依赖的库（express, ws, node-uuid）
node server.js
localhost:3000
，允许摄像头访问
打开另一台电脑，在浏览器（Chrome和Opera，还未兼容Firefox）打开
{server所在IP}:3000
，允许摄像头和话筒访问
广播文件：在左下角选定一个文件，点击“发送文件”按钮
广播信息：左下角input框输入信息，点击发送
可能会出错，注意F12对话框，一般F5能解决
视频音频聊天（连接了摄像头和话筒，至少要有摄像头），广播文件（可单独传播，提供API，广播就是基于单独传播实现的，可同时传播多个，小文件还好说，大文件坐等内存吃光），广播聊天信息
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致一种基于SIP和WebRTC的实时可视对讲方案设计--《西南交通大学》2013年硕士论文
一种基于SIP和WebRTC的实时可视对讲方案设计
【摘要】：随着移动设备的广泛应用,无线带宽的增长,以及IP多媒体子系统(IMS)技术的发展,使音视频通信的需求越来越大,而且对应用程序的跨平台特性要求越来越高。尽管采用浏览器作为移动设备应用平台已经成为跨平台应用的主要趋势,但是浏览器如果想要成为真正的音视频实时通信平台还需要在浏览器中集成包括信号处理技术、媒体采集、音视频编解码、实时传输控制等功能。WebRTC的出现填补了这些空白,使浏览器摆脱了对插件的依赖,使浏览器成为一个实时通信应用的平台。
HTML5和WebRTC的出现使开发者可以使用简单的浏览器提供的javascript接口和HTML页面以及CSS构建功能强大的web音视频通信应用。
WebRTC实现了媒体控制层,信令控制层需要开发者来选择。目前主流的开放的信令控制层协议有XMPP/jingle和SIP,本文在比较XMPP/jingle和SIP的基础上选择了SIP作为WebRTC的信令控制层。在分析JSEP和SIP信令以及WebRTC和SIP协议栈的基础上设计了WebRTC到SIP网关,实现了JSEP到SIP的信令转换以及WebRTC客户端到SIP客户端的互通。本文把网关做为WebRTC服务器模块,在此基础上设计实现了一个功能完整的实时可视对讲系统,实现了WebRTC客户端之间的通信以及WebRTC客户端到SIP客户端的通信。
媒体通信总体设计包括WebRTC客户端,WebRTC服务器和JSEP-to-SIP网关以及SIP代理服务器和SIP客户端,其中WebRTC客户端,WebRTC服务器和JSEP-to-SIP网关是本文的设计实现目标。
WebRTC客户端主要实现用户登录,拨号,视频界面显示的功能。WebRTC的核心是peerconnect对象的建立。peerconnection是一个会话,包含了本地的媒体信息和对端的媒体信息,传输通道以及会话状态和ICE代理的状态。
WebRTC服务器实现WebRTC客户端客户端的下载和转发网关和客户端之间的信令。网关服务器实现了ROAP/JSEP到SIP的信令转换,以及WebRTC和SIP客户端之间的SDP转换。
【关键词】：
【学位授予单位】：西南交通大学【学位级别】：硕士【学位授予年份】：2013【分类号】：TN949.28【目录】：
摘要6-7Abstract7-11第1章 绪论11-17 1.1 课题研究背景及意义11-14 1.2 课题研究内容和应用场景14-16
1.2.1 课题研究内容14-15
1.2.2 HTML5和WebRTC应用情景分析和应用模型15-16 1.3 论文的主要工作及章节安排16-17第2章 HTML5的在音视频领域中的应用17-19 2.1 基于HTML5的web应用程序解决方案17-18 2.2 使用video/audio/canvas标签进行音视频播放18 2.3 使用websocket建立连接18-19第3章 WebRTC音视频应用研究和关键技术分析19-35 3.1 WebRTC的构架19-21 3.2 WebRTC音视频流的处理流程和媒体通信的协议栈的设计21-23 3.3 WebRTC中的SDP23-25 3.4 WebRTC的P2P穿透技术25-27 3.5 WebRTC的信令控制ROAP/JSEP27-30
3.5.1 ROAP28
3.5.2 JSEP28-30 3.6 RTP协议在WebRTC中的应用30-32
3.6.1 RTP会话和PeerConnection的关系30-31
3.6.2 WebRTC的MediaStream和RTP的SSRC的关系31-32
3.6.3 WebRTC的传输和拥塞控制32 3.7 WebRTC接口的应用32-34
3.7.1 获得音视频媒体流32-33
3.7.2 创建Peerconnection33-34 3.8 Vp8和WebRTC34-35第4章 WebRTC音视频通信总体设计35-41 4.1 系统需求和功能35-37 4.2 系统总体设计37-41
4.2.1 WebRTC和信令控制服务器应用模型37-38
4.2.2 JSEP/ROAP和SIP/SDP以及xmp/jingle的协议转换和比较38-39
4.2.3 基于SIP的WebRTC音视频通信总体设计39-41第5章 JSEP-to-SIP网关的设计41-49 5.1 WebRTC的JSEP和SIP之间的信令转换41-45
5.1.1 SIP为WebRTC提供的服务41-42
5.1.2 SIP的信令模型和路由机制42-43
5.1.3 生成invite请求以及应答43-44
5.1.4 JSEP和SIP信令之间的交互44-45
5.1.5 JSEP和SIP信令之间的映射关系45 5.2 网关解决SIP和WebRTC的互通45-49
5.2.1 WebRTC和SIP的协议栈设计的比较45-46
5.2.2 WebRTC和SIP互通的解决方案46-49第6章 融合SIP的媒体通信设计实现49-76 6.1 系统实现模块分析49-51
6.1.1 WebRTC服务器模块分析50-51
6.1.2 JSEP-to-SIP网关模块分析51
6.1.3 客户端模块分析51 6.2 服务器端开发51-62
6.2.1 服务器软件开发平台模块选择51-54
6.2.2 WebRTC服务器和JSEP-to-SIP网关的路由控制54
6.2.3 WebRTC服务器和网关服务器的会话管理54-56
6.2.4 候选地址发送和接收56-57
6.2.5 网关服务器SDP的转化模块的实现57-58
6.2.6 网关服务器生成请求以及响应请求以及响应应答58-62 6.3 客户端开发62-64
6.3.1 WebRTC客户端页面的生成62
6.3.2 WebRTC创建peerconnection和HTML5的video标签的使用62-64
6.3.3 Websocket在客户端和WebRTC服务器通信中的应用64 6.4 WebRTC客户端登陆和呼叫流程64-68
6.4.1 WebRTC客户端登陆和请求的digest验证机制64-66
6.4.2 WebRTC作为主叫端的呼叫流程66-67
6.4.3 WebRTC客户端作为被叫端的呼叫流程67-68 6.5 系统运行效果68-76
6.5.1 系统开发环境和配置68-69
6.5.2 系统运行效果图和分析69-73
6.5.3 网关服务器运行状态分析73-76结论76-77致谢77-78参考文献78-80
欢迎：、、)
支持CAJ、PDF文件格式
【相似文献】
中国期刊全文数据库
李振军;曾凌云;郑善贤;;[J];通信技术;2009年08期
金纯;汤芳剑;赵喜;叶怿;杨帆;;[J];通信技术;2008年12期
王锋;;[J];智能建筑电气技术;2007年05期
黄渊;张思发;黄永峰;;[J];数据通信;2010年01期
彭焕峰;;[J];微型机与应用;2011年06期
张文华,刘忠信,陈增强,袁著祉;[J];计算机工程与应用;2004年13期
高雷;薛琳;;[J];电脑知识与技术(学术交流);2006年32期
李志超;孟相如;;[J];电子技术应用;2008年03期
林霞;董魁松;;[J];计算机工程与科学;2006年04期
杜襄南;傅华明;;[J];信息技术;2008年03期
中国重要会议论文全文数据库
刘磊;;[A];2008通信理论与技术新进展——第十三届全国青年通信学术会议论文集（上）[C];2008年
侯宾;吕玉琴;叶德信;;[A];第四届中国软件工程大会论文集[C];2007年
张兆心;方滨兴;胡铭曾;张宏莉;;[A];全国网络与信息安全技术研讨会'2005论文集（上册）[C];2005年
赵元;勾学荣;;[A];第一届中国高校通信类院系学术研讨会论文集[C];2007年
张兆心;方滨兴;张宏莉;姜春祥;;[A];全国网络与信息安全技术研讨会论文集（上册）[C];2007年
王波;毛勇刚;;[A];2006北京地区高校研究生学术交流会——通信与信息技术会议论文集（下）[C];2006年
黎澍;黄玮;范文庆;;[A];2011年通信与信息技术新进展——第八届中国通信学会学术年会论文集[C];2011年
赵会群;赵洁;王恩雷;;[A];第五届中国测试学术会议论文集[C];2008年
张伟燕;席传裕;;[A];’2004计算机应用技术交流会议论文集[C];2004年
尤雪娇;徐玉滨;王弘飞;;[A];2008'中国信息技术与应用学术论坛论文集（二）[C];2008年
中国重要报纸全文数据库
北京邮电大学国际学院
肖嘉隆;[N];计算机世界;2009年
龚文菲;[N];人民邮电;2001年
陈聪;[N];中国计算机报;2001年
沈仕卫;[N];贵州日报;2009年
王翌;[N];计算机世界;2005年
白 玲 胡宝国;[N];中国测绘报;2006年
边歆;[N];网络世界;2006年
陈雷;[N];电脑报;2002年
;[N];中国电脑教育报;2004年
;[N];电脑报;2006年
中国博士学位论文全文数据库
张秀武;[D];中国科学技术大学;2010年
李鸿彬;[D];中国科学院研究生院（沈阳计算技术研究所）;2012年
杨鹏;[D];兰州理工大学;2009年
王永利;[D];华北电力大学;2010年
曾锋;[D];中南大学;2010年
宋琦;[D];北京邮电大学;2006年
罗仕漳;[D];北京邮电大学;2006年
卢正新;[D];华中科技大学;2009年
曹予飞;[D];北京邮电大学;2008年
钱迎进;[D];国防科学技术大学;2011年
中国硕士学位论文全文数据库
竹洪涛;[D];西南交通大学;2013年
姜继锁;[D];武汉理工大学;2010年
俸学文;[D];中南民族大学;2010年
田增明;[D];北京邮电大学;2010年
邢璐;[D];北京邮电大学;2010年
周育博;[D];北京邮电大学;2010年
闫铁娟;[D];北京邮电大学;2010年
史华;[D];西华大学;2010年
李佳;[D];北京邮电大学;2011年
龚剑;[D];北京邮电大学;2010年
&快捷付款方式
&订购知网充值卡
400-819-9993
《中国学术期刊（光盘版）》电子杂志社有限公司
同方知网数字出版技术股份有限公司
地址：北京清华大学 84-48信箱 大众知识服务
出版物经营许可证 新出发京批字第直0595号
订购热线：400-819-82499
服务热线：010--
在线咨询：
传真：010-
京公网安备75号电信网技术
var nPos = vPos.indexOf(' → ');
if(nPos>0)
vPos = "您现在的位置：" + vPos.substring(nPos);
document.write(vPos);
→ 显示内容
WebRTC对OTT的影响分析
&来源&[电信网技术]&作者&陈
摘要　　随着互联网技术的迅速发展，电信运营商正受到OTT企业猛烈的冲击，基于Web浏览器的实时通信技术（WebRTC）给电信运营商带来了新的挑战和机遇。本文介绍了WebRTC技术的发展和关键技术，并分析了WebRTC对OTT产生的影响。　
OTT（Over The Top）意味着服务提供商（如Skype和WhatsApp等）可以利用电信运营商的基础网络，直接向用户提供在线视频和音频业务，使得电信运营商的短信、话音、甚至包括国际电话业务都受到了很大挑战。电信运营商的业务收入也因OTT的分流而锐减，据市场咨询机构Ovum的报告，2011年OTT服务提供商抢夺了运营商139亿美元的收入，占运营商全部信息业务收入的9%。在OTT服务提供商的压力不断增加和传统电话使用持续下降的影响下，预计在未来的3年，欧洲核心电信运营商的收入将以每年1.8%的速度下降。
基于Web浏览器的实时通信技术简称为WebRTC（Web Real Time Communication），是一个基于浏览器的标准框架，它定义了如何在Web用户之间实现实时的交互和通信。和传统的基于本地客户端或浏览器插件的多媒体通信方式不同，WebRTC通过将多媒体通信所必须的音视频处理（采集、编码、增强）、网络传输、会话控制等核心模块集成到浏览器内部，从而使第三方应用开发者仅需通过简单的JavaScript API调用即可获得实时的音视频通信和文件共享能力。WebRTC技术不仅对OTT厂商构成威胁，也给电信运营商带来新的挑战和机遇，因此从2011年WebRTC技术刚刚问世，它就得到了互联网企业和电信运营商的广泛关注。
2&&& WebRTC概述
在WebRTC技术之前，互联网的实时通信技术主要需通过安装插件或者桌面客户端来实现，如微软花费85亿美金收购的Skype和苹果公司重金打造的FaceTime和iMessage平台。这些软件通常采用私有标准，并且受到专利权的保护。在2010年，Google以大约6820万美元收购了VoIP软件开发商Global IP Solutions（GIPS）公司，并因此获得了该公司拥有的WebRTC技术。Global IP
Solutions公司之前已经针对Android，Windows Mobile，iPhone制作了基于WebRTC的移动客户端。2011年6月Google以GIPS公司的专利为基础建立了WebRTC开源项目，并以BSD授权形式公开其源代码，希望浏览器厂商能够将该技术直接内嵌到浏览器中，从而在浏览器中创建高质量的实时视频或语音聊天应用。
WebRTC属于新一代Web技术HTML5标准的一部分。HTML5是超文本标记语言（HTML）协议的一个升级版本，将会取代HTML4、XHTML1、DOM2 HTML，并提供满足Web富媒体应用程序所必须的新功能，同时也会将许多用于Web平台上的技术进行标准化。但严格地就规范而言，HTML5和WebRTC在W3C中对应不同的规范。HTML5给出了HTML新的标记，如&video&、&audio&和&canvas&等，支持在网页中直接播放多媒体或绘制图像，这些工作为使用Web浏览器进行实时通讯奠定了基础。WebRTC、Audio等规范定义了具体的实现API。WebRTC支持HTML5的语义格式和API，同时HTML5中也引入了部分WebRTC的定制。例如在HTML5当中定义的Device API中有一个getUserMedia，里面LocalMediaStream采用了WebRTC中定义的结构。
3&&&WebRTC的标准化进展
RTCWeb的标准化工作由Google公司发起，目前在IETF和W3C进行标准研究。IETF在2011年3月成立RTCWeb工作组，重点定义浏览器之间的实时通信协议和格式，关注编解码、传输、安全加密和NAT穿越等领域，已提交多份草案。
2011年5月W3C成立WebRTC工作组，与IETF密切合作，重点定义能够控制浏览器实时通信的API，使得Web应用不需要插件仅通过浏览器就可以实现点对点实时通信。2012年6月媒体捕获任务组（Media Capture Task Force）发布本地媒体设备访问API（getUserMedia API）。2012年8月W3C发布了WebRTC 1.0：浏览器之间的实时通信规范，该文档定义了一组重要的JavaScript API如Network Stream API、RTCPeerConnection和Peer-to-peer Data API。2012年9月IETF发布音频编码标准Opus（RFC 6716）。目前，WebRTC技术标准尚处在草案阶段，预计相关文稿的内容还会有较大的变动。
4&& WebRTC的关键技术与应用
4.1& WebRTC的关键技术
WebRTC的软件架构由两套应用程序调用接口组成：Web API与Native API。Web API是WebRTC项目提供给第三方多媒体通信应用开发者的一套由JavaScript实现的API，该模块的主要功能是实现视频会议系统向下接口的兼容和向上采用HTML5完成界面的布局和开发。WebRTC
Native C++API主要是浏览器厂商用于实现Web
API的函数集。WebRTC Native APIs拥有两个全局线程：信令线程（Signaling Thread）和工作者线程（Worker Thread），根据PeerConnection factory被创建的方式，应用程序可以提供这两个线程或者直接使用内部创建好的线程。Session Management是一个抽象的会话层，它支持调用构建和提供会话建立及管理功能。
从具体实现来看，WebRTC向浏览器加入了视频引擎、音频引擎、网络传输及会话控制等新功能模块。其中，音视频引擎模块提供了从音视频采集设备，如麦克风、摄像头，到网络侧音视频处理链的总体框架。为了避免专利纠纷，音视频编码都采用了开源的编码格式，如iLBC、iSAC、VP8等，同时提供相应的抖动缓冲及音视频增强等功能。在网络传输方面，WebRTC使用RTP/SPRT进行媒体流传输，使用ICE（Interactive Connectivity
Establishment）技术进行媒体流的私网穿透。WebRTC客户端使用JSEP（Javascript Session Establishment
Protocol）协议草案规范WebRTC通信双方应如何交换SDP信息，并进行媒体流协商和控制。JSEP的设计思路将媒体层的控制交由浏览器，而将信令层的控制交由Web应用开发者，从而使得信令状态机可与浏览器彻底分离，保持了协议的灵活性。WebRTC软件架构如图1所示。
&&&&&&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&& 图软件架构图
4.2& WebRTC在互联网中的应用
WebRTC技术使用了HTML5和简单的Javascript API，开发者可以很轻松地创建RTC应用，只要浏览器支持就可在不安装任何扩展和插件的前提下进行实时音频和视频聊天。除谷歌Chrome外，其它主流浏览器Opera、Mozilla Firefox和Microsoft也纷纷将WebRTC 整合进自己的产品中。2012年11月Ericsson Labs发布了全世界第一个可以支持WebRTC的手机Browser。
应用厂商如美国最大的Viop提供商Voxeo Labs借助WebRTC技术推出了一项无需安装插件便可在浏览器内进行实时视频和音频通信的技术。利用自己的Phono SDK同样可提供实时在线和聊天功能，开发者可轻松开发出和Google Talk、Skype等类似的服务。雷格?沃克，谷歌语音和拨号盘的发明者，在他最新的公司UberConference中应用WebRTC技术实现了丰富的可视化界面的电话会议。该电话会议简单、直观，提供免费使用，不仅解决了不愿透露姓名的问题，也使得电话会议充满乐趣。
随着HTML5的兴起，Flash已开始逐渐走向落幕，免插件的实时视频和音频通信技术势必会成为未来的主流趋势。
4.3& WebRTC在IMS网络中的应用
IP多媒体子系统（IMS）是将电话网同计算机网、固定网和移动网结合起来的网络。IMS是无线移动网络演进中的一个重要阶段，IMS能够帮助电信运营商升级电话网络以提供移动计算服务，创造出许多新的服务和应用。从2004年开始，IMS在电信运营商中得到了广泛的部署，如Vodafone、BT、AT&T和FT等。但是在IMS新业务的推广中，受到OTT厂商的很大冲击，一方面IMS新业务缺乏亮点；另一方面是在收费模式上难以抵挡免费的OTT应用。因此，如何利用WebRTC具有快速部署、维护成本低等优势，将其转化为推进IMS业务开展的重要动力，为IMS用户提供更加丰富的新应用，促使传统用户向IMS网络迁移，成为电信运营商关注的热点。基于WebRTC的IMS网络架构如图2所示。WebRTC客户端是运行在浏览器中的Web应用程序，采用JavaScript脚本语言编写。其核心部分可以是一个SIP协议栈，用于发送、接收、解析SIP信令，以及维护SIP信令状态机。WebRTC客户端通过WebSocket接口与WebRTC应用网关相互连接。WebRTC客户端将SIP消息作为净载荷封装在WebSocket消息中进行传送。业务平台需要架设WebRTC应用网关，SIP服务器则基于IMS核心网的原有配置，不做任何改动。图中的WebRTC客户端皆位于NAT或防火墙之后。在通信过程中，信令流与媒体流分两路进行传输。
&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &图基于的网络架构图
（1）WebRTC客户端
WebRTC客户端是运行在浏览器中的Web应用程序，采用JavaScript脚本语言编写。其核心部分是一个SIP协议栈，用于发送、接收、解析SIP信令，以及维护SIP信令状态机。WebRTC客户端将SIP消息作为净载荷封装在WebSocket消息中进行传送。WebSocket协议也属于HTML5标准的一部分，用于实现浏览器间双向通信的协议。WebSocket协议兼容于现有HTTP 1.1协议，并通过Upgrade：Websocket将协议升级为WebSocket协议。
（2）WebRTC应用网关
RTCWeb应用网关主要完成协议适配、信令映射和流媒体的防火墙穿越。RTCWeb应用网关应支持HTTP、HTTPS、WebSocket、SIP、JSON、XMPP等控制面相关协议，及HTTP、RTP等媒体面相关协议。提供SIP协议与基于HTTP协议的Web服务的映射，RTP/RTCP媒体流与RTP over HTTP的媒体流映射。应用网关支持将HTTP隧道协议承载的媒体流映射到RTP协议承载，从而实现防火墙穿越。
（3）IMS核心网
可以将IMS核心网简单抽象成为一台SIP服务器，实际上包含了P-CSCF、I-CSCF、S-CSCF、HSS和应用服务器等多个网元构成。IMS核心网的主要功能是进行用户认证以及通话过程控制，但不一定负责媒体流的传输。通话双方必须事先在IMS核心网上注册，并周期性发送心跳包，保持在线状态。
目前，在IMS网络中部署基于WebRTC的音视频实时通信应用的方式也存在许多不完善之处，如没有考虑视频会议等多方通话场景，没有考虑与第三方WebRTC服务商的互通问题等。但相信随着相关标准和技术的不断完善，将WebRTC技术与IMS结合将焕发更强大的生命力，电信运营商如果能够把握未来互联网技术的发展方向，妥善利用WebRTC这一重要机遇，对于推进IMS业务开展、开拓新的业务领域将起到十分积极的作用。
5&& WebRTC对OTT的影响
5.1& 削弱OTT厂商的垄断地位
WebRTC包含了Web浏览器内整个实时通信的全部技术，作为开源技术开放给广大的Web开发者，降低了富媒体应用的开发门槛，极大地增强了Web和Web浏览器的实时通信能力，无论在桌面还是移动领域，都能够减少与原生应用之间的能力差距。使得Web开发者能够很容易地进入语音和视频服务的新领域，开发出大量的通信业务和应用，摆脱对少数垄断厂商的依赖。例如能够削弱微软收购Skype的影响，并危及Apple的FaceTime服务。
5.2& 打破壁垒，建立新的通信方式
目前的OTT业务建立实时通信必须安装特定的软件，如QQ或Skype，而且也不允许和竞争OTT的对手服务互通，例如不能从QQ打到Skype。原因是OTT厂商要通过提供免费服务吸引用户并尽可能锁定用户，再通过广告与PSTN互通，使增值服务实现货币化。由于需要通过系统被用户大量使用来获取收入，因此要求用户必须在他们服务边界内使用。
随着WebRTC成为HTML5标准的一部分，将能够在任何浏览器中使用VoIP应用。由于没有特定信令，每个厂商都可以决定是否使用User ID。用户不再需要交换User ID或者电话号码，只需要通过在社交网站上按键，就可以直接联系。已经有不少创业公司使用WebRTC提供服务，包括Bistri、Cloudeo、FrisB、TenHands和TokBox。目前签订新服务的Web范式是使用现有社交媒体帐号，很多采用WebRTC技术的厂商也将遵循这一模式，不再需要唯一的服务ID。
WebRTC技术允许开发者在网页建立实时通信，这将不仅仅影响运营商，OTT厂商现在也面临真正的威胁，因为WebRTC打破了不同OTT厂家间的订购壁垒。
&&& 对于电信运营商而言，技术既有挑战，也有机遇。一方面，开源无插件的技术能够打破厂商形成的壁垒，对运营商的多媒体实时通信业务产生更加强烈的冲击。另一方面，运营商如果能够积极加入开发者社区，发挥自身在网络接入和服务质量保证上的优势，形成富有生机的生态系统，电信运营商也有可能成为创新的主体。
《电信网技术》版权与免责声明：
①凡本网注明“来源：《电信网技术》”的所有作品，版权均属于《电信网技术》，未经本网授权不得转载、摘编或利用其它方式使用上述作品。已经本网授权使用作品的，应在授权范围内使用，并注明“来源：《电信网技术》”。违反上述声明者，本网将追究其相关法律责任。
②如因作品版权和其它问题需要同本网联系的，请在30日内进行。 联系信箱：wangyana@.cn}