blob: 7a9950be14274bb729c5cc33294750294945e701 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
---
title: WebRTC connectivity
slug: Web/API/WebRTC_API/Connectivity
tags:
- API
- Advanced
- WebRTC
- 媒体
- 指南
- 草案
- 视频
- 音频
translation_of: Web/API/WebRTC_API/Connectivity
---
<p>{{WebRTCSidebar}}{{draft}}</p>
<p>现在我们已经单独介绍了协议，我们可以将它们放在一起。 本文介绍了 WebRTC各种相关协议如何相互交互，以便在对等体之间创建连接和传输数据和/或媒体。</p>
<div class="note">
<p>这个页面需要对结构完整性和内容完整性进行大量重写。这里有很多信息，但是组织混乱，现在这里跟个垃圾场一样。</p>
</div>
<h2 id="什么是提议应答和信号通道？">什么是提议/应答和信号通道？</h2>
<p>不幸的是，WebRTC中间无法创建没有某种服务器的连接。 我们称之为信号通道。 无论是通过电子邮件，明信片还是一只信鸽...，都可以通过任何通信方式交换信息，这取决于你。</p>
<p>我们需要交换的信息是提议和应答，其中仅包含下面提到的SDP。</p>
<p>将作为连接发起者的同伴A将创建一个提议。 然后他们将使用所选择的信号通道将此提议发送给对等体B. 对等体B将从信号通道接收提议并创建应答。 然后，它们将沿着信号通道发送回对等体A。</p>
<h3 id="会话描述">会话描述</h3>
<p>WebRTC连接上的端点配置称为<strong>会话描述</strong>。 该描述包括关于要发送的媒体类型，其格式，正在使用的传输协议，端点的IP地址和端口以及描述媒体传输端点所需的其他信息的信息。 使用<strong>会话描述协议</strong>({{Glossary("SDP")}})来交换和存储该信息; 如果您想要有关SDP数据格式的详细信息，可以在{{RFC(2327)}}中找到。</p>
<p>当用户对另一个用户启动WebRTC调用时，将创建一个称为<strong>提议</strong>(offer)的特定描述。 该描述包括有关呼叫者建议的呼叫配置的所有信息。 接收者然后用<strong>应答</strong>(answer)进行响应，这是他们对呼叫结束的描述。 以这种方式，两个设备彼此共享以便交换媒体数据所需的信息。 该交换是使用交互式连接建立(ICE)({{Glossary("ICE")}}处理的，这是一种协议，即使两个设备通过网络地址转换({{Glossary( "NAT")}})。</p>
<p>然后，每个对等端保持两个描述：描述本身的<strong>本地描述</strong>和描述呼叫的远端的<strong>远程描述</strong>。</p>
<p>在首次建立呼叫时，还可以在呼叫格式或其他配置需要更改的任何时候执行提议/应答过程。 无论是新呼叫还是重新配置现有的呼叫，这些都是交换提议和回答所必需的基本步骤，暂时忽略了ICE层：</p>
<ol>
<li>呼叫者通过 {{domxref("navigator.mediaDevices.getUserMedia()")}} 捕捉本地媒体。</li>
<li>呼叫者创建一个<code>RTCPeerConnection</code> 并调用 {{domxref("RTCPeerConnection.addTrack()")}} (注： <code>addStream</code> 已经过时。)</li>
<li>呼叫者调用 {{domxref("RTCPeerConnection.createOffer()")}} 来创建一个提议(offer).</li>
<li>呼叫者调用 {{domxref("RTCPeerConnection.setLocalDescription()")}} 将提议(Offer)<em> </em>设置为本地描述 (即，连接的本地描述).</li>
<li>setLocalDescription()之后, 呼叫者请求 STUN 服务创建ice候选(ice candidates)</li>
<li>呼叫者通过信令服务器将提议(offer)传递至 本次呼叫的预期的接受者.</li>
<li>接受者收到了提议(offer) 并调用 {{domxref("RTCPeerConnection.setRemoteDescription()")}} 将其记录为远程描述 (也就是连接的另一端的描述).</li>
<li>接受者做一些可能需要的步骤结束本次呼叫：捕获本地媒体，然后通过{{domxref("RTCPeerConnection.addTrack()")}}添加到连接中。</li>
<li>接受者通过 {{domxref("RTCPeerConnection.createAnswer()")}} 创建一个应答。</li>
<li>接受者调用 {{domxref("RTCPeerConnection.setLocalDescription()")}} 将应答(answer)<em> </em>设置为本地描述. 此时，接受者已经获知连接双方的配置了.</li>
<li>接受者通过信令服务器将应答传递到呼叫者.</li>
<li>呼叫者接受到应答.</li>
<li>呼叫者调用 {{domxref("RTCPeerConnection.setRemoteDescription()")}} 将应答设定为远程描述. 如此，呼叫者已经获知连接双方的配置了.</li>
</ol>
<h3 id="待定的和当前描述"><strong>待定的和当前描述</strong></h3>
<p>进一步了解该过程，我们发现localDescription和remoteDescription(返回这两个描述的属性 )并不像外观那样简单。 因为在重新协商期间，提议可能会被拒绝，因为它提出了不兼容的格式，每个端点都有能力提出一种新的格式，但是实际上不会切换到另一个对等体，直到它被其他对等体接受为止。 因此，WebRTC使用待定和当前的描述。</p>
<p><strong>当前描述</strong>(由 {{domxref("RTCPeerConnection.currentLocalDescription")}} 和 {{domxref("RTCPeerConnection.currentRemoteDescription")}} 属性返回 )表示连接实际使用的描述。 这是双方已经完全同意使用的最新连接。</p>
<p><strong>待定的描述</strong>(由 {{domxref("RTCPeerConnection.pendingLocalDescription")}} 和 {{domxref("RTCPeerConnection.pendingRemoteDescription")}} 返回 )表示当 分别调用setLocalDescription( )或setRemoteDescription( )。</p>
<p>当读取描述( {{domxref("RTCPeerConnection.localDescription")}} 和 {{domxref("RTCPeerConnection.remoteDescription")}} )返回时，返回的值是pendingLocalDescription / pendingRemoteDescription的值，如果有待处理的描述( 也就是说，待处理描述不为null ); 否则，返回当前描述(currentLocalDescription / currentRemoteDescription )。</p>
<p>通过调用setLocalDescription( )或setRemoteDescription( )更改描述时，将指定的描述设置为待定描述，WebRTC层开始评估是否可以接受。 一旦建议的描述已经达成一致，currentLocalDescription或currentRemoteDescription的值将更改为待处理描述，并且待处理的描述再次设置为null，表示没有待处理的描述。</p>
<div class="note">
<p>pendingLocalDescription不仅包含正在考虑的提议或答案，而且自从提议或应答以来已经收集到的任何本地ICE候选人都被创建。 类似地，pendingRemoteDescription包括通过调用 {{domxref("RTCPeerConnection.addIceCandidate()")}} 提供的任何远程ICE候选。</p>
</div>
<p>有关这些属性和方法的更多细节，请参阅各个文章。</p>
<h2 id="什么是ICE候选地址？">什么是ICE候选地址？</h2>
<p>除了交换关于媒体的信息(上面提到的Offer / Answer和SDP )中，对等体必须交换关于网络连接的信息。 这被称为ICE候选者，并详细说明了对等体能够直接或通过TURN服务器进行通信的可用方法。 通常，每个对点将优先提出最佳的ICE候选，逐次尝试到不佳的候选中。 理想情况下，候选地址是UDP(因为速度更快，媒体流能够相对容易地从中断恢复 )，但ICE标准也允许TCP候选。</p>
<div class="note">
<p>一般来说，使用TCP的ICE候选者只有当UDP不可用或被限制使其不适用于媒体流时才会被使用。 不是所有的浏览器都支持ICE over TCP。</p>
</div>
<h2 id="The_entire_exchange_in_a_complicated_diagram">The entire exchange in a complicated diagram</h2>
<p><a href="https://hacks.mozilla.org/wp-content/uploads/2013/07/webrtc-complete-diagram.png"><img alt="A complete architectural diagram showing the whole WebRTC process." src="https://mdn.mozillademos.org/files/6119/webrtc-complete-diagram.png" style="display: block; height: 559px; margin: 0px auto; width: 641px;"></a></p>
|
