此页面正在建设中,部分内容会移至其他页面,因为WebRTC指导资料已经建成。

WebRTC允许您将任意数据,音频或视频(或其任何组合)的点对点通信构建到浏览器应用程序中。 在本文中,我们将介绍一个WebRTC会话的生命周期,从建立连接到不再需要时关闭连接。

创建连接

互联网很大 很大。 那么多年以前,聪明的人看到它有多大,增长速度有多快,32位IP寻址系统的局限性,并意识到有些事情要做,所以他们开始设计一个新的 64位寻址系统。 但是他们意识到,完成转换需要更长时间才能持续32位地址,所以其他智能人士想出了让多台计算机共享同一个32位IP地址的方法。 网络地址转换(NAT)是通过处理LAN上的数据的入站和出站数据的路由来支持这种地址共享的标准,所有这些都是共享单个WAN(全局)IP地址的设备。

用户的问题是互联网上的每台个人计算机不再一定具有唯一的IP地址,实际上,每个设备的IP地址不仅可以从一个网络移动到另一个网络,而且如果网络的地址发生变化 通过NAT和/或DHCP。 对于尝试进行点对点网络的开发人员,这引入了一个难题:没有每个用户设备的唯一标识符,不可能立即自动地知道如何连接到Internet上的特定设备。 即使你知道你想谈论的人,你不一定知道如何到达他们,甚至是他们的地址。

这就像尝试通过标签“Michelle”将您的朋友Michelle发送给您的朋友,而当您不知道她的地址时,将其放在邮箱中。 你需要查找她的地址并将其包装在包中,否则她会想起你为什么忘记她的生日了。

这就是信令的由来。

信令

信令是在两个设备之间发送控制信息以确定通信协议,信道,媒体编解码器和格式以及数据传输方法以及任何所需的路由信息的过程。 了解WebRTC的信令流程最重要的一点是:信令在规范中没有定义。

信令是一个节点以建立通信协议、信道和方法为目的,来发送控制信息给其他节点的一种机制。这些都不是WebRTC指定的标准。当然,开发者可以为应用程序引擎选择任意的信息协议(如SIP或XMPP),任意双向通信信道(如WebSocket或XMLHttpRequest)与持久连接服务器的API(如Google Channel API)一起工作。

为什么你可能会想,建立一个没有规范的WebRTC连接的过程是至关重要的? 答案很简单:由于两个设备无法直接相互联系,规范无法预测WebRTC的所有可能用例,因此让开发人员选择合适的网络技术和消息传递协议变得更有意义。

特别是,如果一个开发人员已经有了一个连接两个设备的方法,那么对于WebRTC来说,他们必须使用规范定义的另一个设备是没有意义的。 由于WebRTC没有生活在真空中,所以可能还有其他的连接,因此,如果可以使用现有的连接通道,避免不必添加额外的连接通道。

为了交换信令信息,您可以选择通过WebSocket连接来回发送JSON对象,或者您可以在适当的通道上使用XMPP或SIP,或者您可以通过HTTPS使用XMLHttpRequest进行轮询或任何其他技术组合 你可以想出来 甚至可以使用电子邮件作为信号通道。

还值得注意的是,用于执行信令的信道甚至不需要通过网络。 一个对等体可以输出可以打印输出的数据对象,物理地携带(步行或由信鸽)到进入该设备的另一个设备,然后由该设备输出的响应等待返回, 直到WebRTC对等连接打开。 这将是非常高的延迟,但可以做到。

信令期间交换的信息

信令期间需要交换的信息有三种基本类型:

  • 用于设置,打开和关闭通信通道的控制消息,并处理错误。
  • 为了建立连接所需的信息:对等体能够彼此交谈所需的IP寻址和端口信息。
  • 媒体能力协商:同行可以了解哪些编解码器和媒体数据格式? 在WebRTC会议开始之前,需要达成一致。

只有一旦信令已经成功完成,才能开始打开WebRTC对等连接的真正过程。

值得注意的是,在信令期间,信令服务器实际上不需要理解或做任何与数据在两个对等体之间交换的数据。 信令服务器本质上是一个中继:两端连接的公共点,以便知道它们的信令数据可以通过它传输。 服务器不需要以任何方式对此信息做出反应。

信令过程

为了有可能开始一个WebRTC会话,有一系列事情必须发生:

  1. 每个对等体创建一个表示其WebRTC会话结束的RTCPeerConnection对象。
  2. 每个对等体建立一个用于icecandidate事件的处理程序,它处理通过信令通道将这些候选者发送给另一个对等体。
  3. 每个对等体建立一个跟踪事件的处理程序,当远程对等体向流添加轨道时,该事件被接收。该代码应将轨道连接到其消费者,例如<video>元素。
  4. 呼叫者创建并与接收对等体共享某种唯一的标识符或令牌,使得它们之间的呼叫可以由信令服务器上的代码来识别。此标识符的确切内容和形式取决于您。
  5. 每个对等体连接到一个约定的信令服务器,如WebSocket服务器,他们都知道如何与之交换消息。
  6. 每个对等体告知信令服务器他们想加入同一WebRTC会话(由步骤4中建立的令牌标识)。
  7. 描述,候选地址等 - 

ICE 重连

有时,在WebRTC会话的整个生命周期内,网络条件发生变化。 其中一个用户可能会从蜂窝网络转移到WiFi网络,或者网络可能会变得拥塞。 当这种情况发生时,ICE代理可以选择执行ICE重连。 这是一个重新协商网络连接的过程,与执行初始ICE协商的方式完全相同,但有一个例外:媒体继续流过原始网络连接直到新的开始运行。 然后媒体转移到新的网络连接,旧的关闭。

不同的浏览器支持不同情况下的ICE重连。 例如,由于网络拥塞,并不是所有的浏览器都会执行ICE重连。

ICE重连有两个级别:全ICE重连会导致会话中的所有媒体流重新协商。 部分ICE重新连接允许ICE重新协商特定媒体流,而不是一次只对所有媒体流进行重新协商。 然而,有些浏览器还不支持部分ICE重启。 <<<你如何触发每一个?>>>

如果您需要以某种方式更改连接的配置(例如更改为不同的ICE服务器集),可以在重新启动ICE之前通过使用更新的RTCConfiguration字典调用RTCPeerConnection.setConfiguration()来重新启动ICE。

要明确触发ICE重新启动,只需通过调用RTCPeerConnection.createOffer()启动一个协商过程,指定一个值为true的iceRestart选项。 然后就像你通常那样处理连接过程。

发送

getUserMedia(获取用户媒体)

LocalMediaStream object

接收

WebRTC 在Firefox浏览器的偏好选择选项是隐藏的。可以到 about:config 这个页面设置 'media.navigator.enabled' 为 'true'。

在Source tree 中有一些测试文件可以提供给您关于WebRTC如何工作的一个想法。具体例子请查看: dom/media/tests/local_video_test.html。您也可以尝试 服务器demo ,源代码: server source

 

文档标签和贡献者

 此页面的贡献者: Move, acgeeker
 最后编辑者: Move,