开启成长之旅!这是我参与「日新计划 12 月更文应战」的第24天,点击查看活动概况
经过前面几部分的衬托,你应该对P2P音视频互动的进程有了一个大约的了解,有或许你会觉得进程比较繁琐,甚至触及到了网络底层。但是,不要忧虑,WebRTC现已帮咱们做了许多的事情,让咱们在音视频开发时变得轻而易举。那么WebRTC究竟是什么呢?
WebRTC (Web Real-Time Communications) 是一项实时通讯技术,它答应网络运用或许站点,在不借助中心媒介的情况下,树立浏览器之间点对点(Peer-to-Peer)的衔接,实现视频流和(或)音频流或许其他任意数据的传输。WebRTC包含的这些规范运用户在无需装置任何插件或许第三方的软件的情况下,创立点对点(Peer-to-Peer)的数据分享和电话会议成为或许。
WebRTC并不是Google本来自己的技术。在2010年,Google以大约6820万美元收买了VoIP软件开发商Global IP Solutions公司,并因此获得了该公司具有的WebRTC技术。现在,互联网的音频、视频通讯服务技术一般都是私有技术,如Skype, 需求经过装置插件或许桌面客户端来实现通讯功用。Google期望Web开发人员能够直接在浏览器中创立视频或语音聊天运用,Global IP Solutions公司之前现已针对Android、Windows Mobile、iPhone制作了根据WebRTC的移动客户端。Google此次将WebRTC开源出来,便是期望浏览器厂商能够将该技术直接内嵌到浏 览器中,然后便利Web开发人员。
概念弥补
除了之前提到的概念之外,再来弥补几个相关的概念
交互式衔接设备
交互式衔接设备(Interactive Connectivity Establishment, ICE):答应你的浏览器和对端浏览器树立衔接的协议结构。在实践的网络当中,有许多原因能导致简略的从A端到B端直连不能如愿完结。这需求绕过阻挠树立衔接的防火墙,给你的设备分配一个仅有可见的地址(通常情况下咱们的大部分设备没有一个固定的公网地址),假如路由器不答应主机直连,还得经过一台服务器转发数据。你或许现已发现这个ICE便是咱们之前STUN、TURN等衔接方式的汇总,正式由于ICE结构,大大简化了咱们的开发作业,ICE会依照优先级主动选择衔接方式;
信令服务器
信令服务器(signal server):交流Peer之间的可通讯地址,经过STUN获取到自己的通讯地址之后,注册在信令服务器上就能够交流设备之间的通讯地址,然后完结P2P衔接;
会话描绘协议
会话描绘协议(Session Description Protocol, SDP):描绘多媒体衔接内容的协议,例如分辨率,格局,编码,加密算法等。在开始P2P衔接之前需求先洽谈两边一起支持的会话协议。当用户对另一个用户启动WebRTC调用时,将创立一个称为提议(offer)的特定描绘。 该描绘包括有关呼叫者主张的呼叫配置的所有信息。 接收者然后用应对(answer)进行呼应,这是他们对呼叫完毕的描绘。 以这种方式,两个设备互相同享以便交流媒体数据所需的信息;一个SDP描绘的内容是这样的(“=”两边不能有空格)
v=0
o=- 212360934117607227 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
a=rtpmap:111 opus/48000/2
......
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116
a=rtpmap:96 VP8/90000
......
一个SDP描绘由一个会话和多个媒体描绘组成,会话描绘是v=开始到第一段媒体描绘(1-4行),媒体描绘是从m=到下一个媒体描绘之前(5-6行——音频、8-9行——视频)。
会话级描绘
会话描绘字段比较多,最主要的有4个字段
-
v=:UDP的版本号,不包含次版本
-
o=:是一个会话发起者的描绘
o=
-
<username>
:用户名,当不关心用户名时,能够用 “-” 代替 ; -
<session id>
:数字串,在整个会话中,必须是仅有的,主张运用 NTP 时刻戳; -
<version>
:版本号,每次会话数据修改后,该版本值会递加; -
<network type>
:网络类型,一般为“IN”,表明“internet”; -
<address type>
:地址类型,一般为 IP4; -
<address>
:IP 地址
-
-
Session Name:表明一个会话
-
t=:开始时刻和完毕时刻的描绘,
t=<start time> <stop time>
,两个事件均为0时表明耐久会话
WebRTC中的SDP
WebRTC下对SDP做了一些修改,在原有的基础上添加了一些其他描绘
// 音频运用9端口收发;
// UDP / TLS / RTP / SAVPF 表明运用 dtls / srtp 协议对数据加密传输;
m = audio 9 UDP / TLS / RTP / SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
// 网络描绘, webRTC不运用
c = IN IP4 0.0.0.0
// 设置rtcp地址和端口, webRTC不运用
a = rtcp: 9 IN IP4 0.0.0.0
// 安全验证信息
a=ice-ufrag:duP8
a=ice-pwd:/7pIrSvgESATKPZUVzHhLQ0E
a=ice-options:trickle
// 音频流媒体描绘
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
媒体描绘
- m=:表明一个会话,
m=<media> <port> <transport> <fmt list>
-
<media>
:媒体类型,比方 audio/video 等; -
<port>
:端口; -
<transport>
:传输协议,有两种——RTP/AVP 和 UDP; -
<fmt list>
:媒体格局,即数据负载类型 (Payload Type) 列表。
-
- a=*:
a=<type>
或许a=<type>:<value>
,type有两种类型rtpmap和fmap
现在咱们来完善一下之前网关那里的示意图,添加上这里的几个概念
搜集候选地址
所谓的搜集候选地址,便是经过之前说到的STUN服务器来获取本身的可通讯地址。
类型 | 别名 | 怎么传给对端 | 用法 |
---|---|---|---|
主机候选项 | host | 信令服务器 | 从网卡中获取的本地传输地址,假如此地址坐落NAT之后,则为内网地址 |
服务器反射候选项 | srflx | 信令服务器 | 从发送给Stun服务器的Binding查看中获取的传输地址。假如此地址坐落NAT之后,则为最外层NAT的公网地址 |
对端反射候选项 | prflx | Stun Binding恳求 | 从对端发送的Stun Binding恳求获取的传输地址。这是一种在衔接查看期间新发生的候选项 |
中继候选项 | relay | 信令服务器 | 媒体中继服务器的传输地址。经过运用TURN Allocate恳求获取 |
交流候选地址
A经过信令服务器把第一步搜集到的候选地址发送给B,B也将搜集到的候选地址发送给A,A在接收到B的所有候选地址之后会将本身候选地址与对端候选地址进行全摆放,存储到状况表中。比方A此刻的host是192.168.0.100:60000、srflx是11.102.30.3:30110,B的host是192.168.0.15:10001、srflx是1.10.108.25:30110,状况表如下
本地网卡地址 | 对端地址 | 状况 |
---|---|---|
192.168.1.105:60001 | 192.168.0.204:40001 | 未进行过Stun查看 |
172.16.40.6:60003 | 192.168.0.204:40001 | 未进行过Stun查看 |
192.168.1.105:60001 | 11.92.14.8:50002 | 未进行过Stun查看 |
172.16.40.6:60003 | 11.92.14.8:50002 | 未进行过Stun查看 |
192.168.1.105:60001 | 192.168.0.181:40003 | 未进行过Stun查看 |
172.16.40.6:60003 | 192.168.0.181:40003 | 未进行过Stun查看 |
此刻所有的记载状况都是未进行STUN查看,下一步就会进行每条记载的STUN查看。
STUN查看
STUN查看的进程咱们之前有过介绍,如有遗忘能够再温习一下p2p打洞
衔接,启动媒体
STUN查看完毕之后开始准备衔接,此刻P2PTransportChannel中的状况表现已记载了每条记载所需求花费的本钱(触及到许多要素,比方宣布Stun恳求到收到应对经过了的时刻……)。
**当有视频Rtp数据要发送时,查看状况表的第一条记载,假如判断出它的状况是发送就绪,就会用此Connection进行发送。否则直接抛弃这个发送使命。**也便是说,媒体模块的使命不会受衔接状况的影响,只是在要发送是查看状况,假如未衔接则抛弃发送。
为保证NAT映射和过滤规则不在媒体会话期间超时,ICE会不断经过运用中的候选项对发送Stun衔接查看。浅显来说也便是“轮询”,假如STUN的呼应超时,则会在添加本钱,体现在状况表中便是优先级下降,即P2PTransportChannel状况表是实时的。