赞
踩
相关协议:SIP(RFC3261),Jabber(RFC6120),Jingle(XEP-0166),实时传输协议RTP,安全RTP(SRTP),多路复用RTP控制协议(RTCP)。
相关概念:可扩展消息现场协议(XMPP [RFC6120] 也就是Jabber)服务器,Jingle客户端,公告电话交换网PSTN。
注:这里就碰到第一个问题:如何掌握这些通信协议的问题了
下面是WebRTC的一个总览图
总之,WebRTC支持多中设备,多方会话。这个时候多方会话有两种方案:集中式和全网状对等连接。其中全网状的连接把混合数据的操作落在了端上,一旦与会端加多就会带来问题,不适合增加规模。集中式是把数据的混合放在服务端,这样缺点是延迟较大,但是服务器扩容比较容易,所以适合大规模人员参会。
建立WebRTC会话有四步:
WebRTC中的媒体基本单元叫MediaStreamTrack(媒体流轨道,表示一种源返回的单一类型媒体,这个源可能是设备或者是录制内容),而一个MediaStream(媒体流)中可以有若干MediaStreamTrack。
一个媒体流轨道可以是单个立体声源,或者多声道环绕音频信号。
媒体流轨道 MediaStreamTrack的暂停有两种方式:静音(muted)和禁用(enabled)。在WebRTC中使用了不同的参数控制。
创建一个MediaStream有两种方式:请求和访问本地媒体getUserMedia();通过MediaStream构造函数将现有的对象复制过来,或者通过现有的流对象添加/删除轨道而来。
媒体的选择和控制是通过参数约束来实现的。 约束大体上分为强制约束和可选约束,而具体的约束属性值有两种,一种是枚举类型的,一类是范围的(就是有最小值和最大值限定)。
在源设备获取到媒体流之后通过处理,打包成不同的MediaStream,交给传输管道发往接收端。接收端通过解析不同的MediaStream,根据不同的ID解析到全部MediaStreamTrack,然后选择性地交由不同的播放/渲染设备。
信令的标准没有确定下来,但是实践中有多个方案。
信令的作用?
信令为什么没有确立标准?
因为不同的浏览器是可以通过向同一个Web服务器请求下载同一份JS代码来使用相同的信令,这样客观上就让信令变成了一种Web服务器相关的标准,无关乎浏览器。既然没有必要,也就没有这样做的必然性了。
信令的传输方法
信令协议
标准的信令协议有SIP,Jingle等。
具体的方案:
一个可运行的信令通道代码
WebRTC使用对等媒体流,语音、视频、数据的连接都在两个浏览器之间建立。但是由于NAT和防火墙的存在增加了这一方案的复杂性。
下面这种方案由于需要源浏览器发送信息到Web服务器,然后由服务器发往目标浏览器,所以对服务器压力较大。
采用WebRTC架构的媒体流,使用了RTCPeerConnection API,可以建立点对点的连接。这种架构对于浏览器和服务器之间的距离要求也较低。
WebRTC和网络地址转换(NAT)
NAT通常内置于Internet路由器或者集线器中。一个WebRTC要处理的情况如下图:
通过打洞技术可以有下面两种方式实现两个浏览器互联:
STUN服务器
这个是被称作NAT会话遍历使用工具的服务器(Session Traversal Utilities for NAT)。这种服务器有一个公网的IP地址,可以帮助遍历NAT。浏览器通过发送STUN数据包给STUN服务器获取待连接的浏览器的IP地址。
TURN服务器
这个是被称作中继型NAT遍历服务器(Traversal Using Relay around NAT)。这种服务器也有一个公网的IP地址,用来转发来自浏览器的数据包,或者向浏览器转发来自服务器的数据包。
要建立连接的双方需要先通过协商沟通好支持哪些类型的媒体流,因为浏览器所在设备的支持能力不尽相同。具体过程如下描述:
首先,发起者针对要建立的媒体会话创建描述,以此来发起会话,此即“提议”;通过信令通道发往另一方。对方收到后予以回应,此即“应答”;应答中包含了提议的会话功能特性中,另一方能够和愿意支持的功能;并通过信令通道返回。
WebRTC使用RTCSessionDescription对象来表示提议和应答。
WebRTC中的数据通道不是媒体交互通道,是用来绕过服务器直接交换数据的通道。相比WebSocket和HTTP传输来说,这两者只是传输一些少量的数据,数据通道可以传输流量大,时延低的数据。
创建了对等连接之后才会创建数据通道,而且只需要发起者创建一个数据通道,对端并不需要创建,这个时候就是要给单向通道,对端只是被动接收数据。
pc = new RTCPeerConnection();
dc = pc.createDataChannel("dcl");
数据通道建立之后,可以做一些配置。比如失败重传次数,重试操作最大时长,此二者互斥;还有数据送达之后顺序问题。当然也可以由原来的接收方创建第二个数据通道形成双向通道,但是有点浪费,WebRTC提供了一种方法可以将两个通道关联起来。
// 下面的代码通过设置两个id都为1,将二者绑定在一起
// 本地对等端:创建数据通道的前半部分
properties = {negotionation: true, id: 1, maxRetransmits: 3};
dc = pc.createDataChannel("", properties);
// 远程对等端:创建数据通道的后半部分
properties = {negotionation: true, id: 1, maxRetransmits: 6};
dc = pc.createDataChannel("", properties);
主要介绍了一些标准API。
浏览器之间实时通信用到的API,比如核心RTCPeerConnection接口,数据API,DTMF API,统计数据API,身份API。具体可以参考 WebRTC 1.0: Real-time Communication Between Browsers。
媒体捕获和流,比如getUserMedia方法,MediaStream接口,MediaStreamTrack接口。具体可以参考Media Capture and Streams。
流的录制API,参考MediaStream Recording。
图像捕获 MediaStream Capture Scenarios,
交互式连接建立(Interactive Connectivity Establishment ICE)是一种标准穿透协议。它利用STUN和TURN服务器来帮助端点建立连接。
分述:
收集候选传输地址 一旦A用户要发起与B用户的连接请求,ICE代理A会收集候选地址。而ICE代理B在信令通道中,一旦收到来自A的对等连接请求的时候,也开始收集候选地址。这个候选地址有4种:
交换候选地址 通过信令通道进行,按照上表的顺序从上往下,优先级由高到低。
STUN连接检查 当代理A从代理B收到SDP应答的时候开始检查,代理B在向代理A发送了SDP应答的时候开始检查。检查会剔除一些不可能的连接对,比如IPv4和IPv6地址对。一个目的是减少执行的连接检查数量。同时,为了确保NAT映射和过滤规则不会在会话期间超时,ICE会每隔15秒通过使用中的候选项对发送连接检查。
ICE重新启动 当基地址发生变化的时候,会导致ICE重新开始第一步来收集候选项。这个技术点还在优化中……
与WebRTC相关的重要协议有:
这些协议内容都可以在IETF Document中搜索。
WebRTC协议
实时传输协议:
会话描述协议
NAT遍历协议
编解码器
【略】
目前主流的浏览器中只有Safari,Chrome,Opera支持。
另外,附加一条公司的招聘链接,考虑的小伙伴可以私信我:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。