草案
本页尚未完工.
现在我们已经单独介绍了协议，我们可以将它们放在一起。 本文介绍了 WebRTC各种相关协议如何相互交互，以便在对等体之间创建连接和传输数据和/或媒体。
This page needs heavy rewriting for structural integrity and content completeness. Lots of info here is good but the organization is a mess since this is sort of a dumping ground right now.
什么是提议/应答和信号通道？
不幸的是，WebRTC中间无法创建没有某种服务器的连接。 我们称之为信号通道。 无论是通过电子邮件，明信片还是一只信鸽...，都可以通过任何通信方式交换信息，这取决于你。
我们需要交换的信息是提议和应答，其中仅包含下面提到的SDP。
将作为连接发起者的同伴A将创建一个提议。 然后他们将使用所选择的信号通道将此提议发送给对等体B. 对等体B将从信号通道接收提议并创建应答。 然后，它们将沿着信号通道发送回对等体A。
会话描述
WebRTC连接上的端点配置称为会话描述。 该描述包括关于要发送的媒体类型，其格式，正在使用的传输协议，端点的IP地址和端口以及描述媒体传输端点所需的其他信息的信息。 使用会话描述协议(SDP)来交换和存储该信息; 如果您想要有关SDP数据格式的详细信息，可以在RFC 2327中找到。
当用户对另一个用户启动WebRTC调用时，将创建一个称为提议的特定描述。 该描述包括有关呼叫者建议的呼叫配置的所有信息。 接收者然后用应答进行响应，这是他们对呼叫结束的描述。 以这种方式，两个设备彼此共享以便交换媒体数据所需的信息。 该交换是使用交互式连接建立(ICE处理的，这是一种协议，即使两个设备通过网络地址转换(NAT)。
然后，每个对等端保持两个描述：描述本身的本地描述和描述呼叫的远端的远程描述。
在首次建立呼叫时，还可以在呼叫格式或其他配置需要更改的任何时候执行提议/应答过程。 无论是新呼叫还是重新配置现有的呼叫，这些都是交换提议和回答所必需的基本步骤，暂时忽略了ICE层：
- The caller calls ("RTCPeerConnection.createOffer()")to create an offer.
- The caller calls ("RTCPeerConnection.setLocalDescription()") to set that offer as the local description (that is, the description of the local end of the connection).
- The caller uses the signaling server to transmit the offer to the intended receiver of the call.
- The recipient receives the offer and calls ("RTCPeerConnection.setRemoteDescription()") to record it as the remote description (the description of the other end of the connection).
- The recipient does any setup it needs to do for its end of the call, including adding outgoing streams to the connection.
- The recipient then creates an answer by calling("RTCPeerConnection.createAnswer()").
- The recipient calls ("RTCPeerConnection.setLocalDescription()") to set the answer as its local description. The recipient now knows the configuration of both ends of the connection.
- The recipient uses the signaling server to send the answer to the caller.
- The caller receives the answer.
- The caller calls ("RTCPeerConnection.setRemoteDescription()") to set the answer as the remote description for its end of the call. It now knows the configuration of both peers. Media begins to flow as configured.
待定的和当前描述
进一步了解该过程，我们发现localDescription和remoteDescription(返回这两个描述的属性 )并不像外观那样简单。 因为在重新协商期间，提议可能会被拒绝，因为它提出了不兼容的格式，每个端点都有能力提出一种新的格式，但是实际上不会切换到另一个对等体，直到它被其他对等体接受为止。 因此，WebRTC使用待定和当前的描述。
当前描述(由 ("RTCPeerConnection.currentLocalDescription") 和 ("RTCPeerConnection.currentRemoteDescription") 属性返回 )表示连接实际使用的描述。 这是双方已经完全同意使用的最新连接。
待定的描述(由 ("RTCPeerConnection.pendingLocalDescription" ) 和 ("RTCPeerConnection.pendingRemoteDescription") 返回 )表示当 分别调用setLocalDescription( )或setRemoteDescription( )。
当读取描述( ("RTCPeerConnection.localDescription" ) 和 ("RTCPeerConnection.remoteDescription" ) )返回时，返回的值是pendingLocalDescription / pendingRemoteDescription的值，如果有待处理的描述( 也就是说，待处理描述不为null ); 否则，返回当前描述(currentLocalDescription / currentRemoteDescription )。
通过调用setLocalDescription( )或setRemoteDescription( )更改描述时，将指定的描述设置为待定描述，WebRTC层开始评估是否可以接受。 一旦建议的描述已经达成一致，currentLocalDescription或currentRemoteDescription的值将更改为待处理描述，并且待处理的描述再次设置为null，表示没有待处理的描述。
pendingLocalDescription不仅包含正在考虑的提议或答案，而且自从提议或应答以来已经收集到的任何本地ICE候选人都被创建。 类似地，pendingRemoteDescription包括通过调用 ("RTCPeerConnection.addIceCandidate( )" ) 提供的任何远程ICE候选。
有关这些属性和方法的更多细节，请参阅各个文章。
什么是ICE候选地址？
除了交换关于媒体的信息(上面提到的Offer / Answer和SDP )中，对等体必须交换关于网络连接的信息。 这被称为ICE候选者，并详细说明了对等体能够直接或通过TURN服务器进行通信的可用方法。 通常，每个同伴将首先提出最佳候选人，让他们走向更糟糕的候选人。 理想情况下，候选地址是UDP(因为速度更快，媒体流能够相对容易地从中断恢复 )，但ICE标准也允许TCP候选。
一般来说，使用TCP的ICE候选者只有当UDP不可用或被限制使其不适用于媒体流时才会被使用。 不是所有的浏览器都支持ICE over TCP。