WebRTC 与信令
WebRTC 允许在两个设备之间进行实时的 P2P 媒体通讯。由于存在 NAT ，WebRTC 不能直接与对端建立连接，设备之间需要通过信令服务进行发现和协商以进行实时音视频交换。这涉及到两个设备连接到第三个共同商定的服务器，一般被称为信令服务器。信令服务器的作用是作为一个中间人帮助双方在尽可能少的暴露隐私的情况下建立连接。通过这个第三方服务器，这两台设备可以相互定位，并交换协商消息。
值得注意的是信令服务器不需要理解和解释信令数据内容。虽然信令消息使用 SDP 协议，但这并不重要：信令服务器实际上是一个黑盒，消息内容会直接被传送。当 WebRTC 的 ICE 子系统指示你将信令数据发送给对端时，信令服务器直接传递消息，而对端接收此信息并将其传递给自己的 ICE 子系统。信令服务器所要做的就是来回传递信息。内容对信令服务器一点都不重要。
信令
信令是在两个设备之间发送控制信息以确定通信协议、信道、媒体编解码器和格式以及数据传输方法以及任何所需的路由信息的过程。 关于 WebRTC 的信令流程最重要的一点是：信令在规范中并没有定义。所以开发者需要自己决定如何实现这个过程。开发者可以为应用程序引擎选择任意的信息协议（如SIP或XMPP），任意双向通信信道（如 WebSocket 或 XMLHttpRequest )与持久连接服务器的 API 一起工作。
为了交换信令信息，您可以选择通过WebSocket连接来回发送JSON对象，或者您可以在适当的通道（Channel）上使用 XMPP 或 SIP，或者您可以通过 HTTPS 使用 XMLHttpRequest 进行轮询或者其他任何你可以想出来的技术组合。你甚至可以使用电子邮件作为信号通道。
信令期间交换的信息
信令期间需要交换的信息有三种基本类型：
- 控制消息：用于设置、打开、关闭通信通道并处理错误。
- 为了建立连接所需的信息：设备间能够彼此交谈所需的IP寻址和端口信息。
- 媒体能力协商：交互双方可以理解哪些编解码器和媒体数据格式？ 这些都需要在WebRTC会议开始之前达成一致。
只有在信令成功完成之后，打开WebRTC对等连接的过程才真正开始。
信令过程
为了开启一个 WebRTC 会话，以下事件需要依次发生：
- 每个 Peer 创建一个 RTCPeerConnection 对象，用来表示其 WebRTC 会话端。
- 每个 Peer 建立一个 icecandidate 事件的响应程序，用来在监测到该事件时将这些 candidates 通过信令通道发送给另一个 Peer。
- 每个 Peer 建立一个 track 事件的响应程序，这个事件会在远程 Peer 添加一个 track 到其 stream 上时被触发。这个响应程序应将 tracks 和其消受者联系起来，例如 <video> 元素。
- 呼叫者创建并与接收者共享一个唯一的标识符或某种令牌，使得它们之间的呼叫可以由信令服务器上的代码来识别。此标识符的确切内容和形式取决于您。
- 每个 Peer 连接到一个约定的信令服务器，如 WebSocket 服务器，他们都知道如何与之交换消息。
- 每个 Peer 告知信令服务器他们想加入同一 WebRTC 会话（由步骤4中建立的令牌标识）。
- 描述，候选地址等
