Salvatore Loreto, Simon Pietro Romano
信令
自从WebRTC出现以来，就有一个在WebRTC设计的中心思想就得到了充分的指定，如何在尽可能保持信令平面留在应用层的前提下控制媒体平面。基本原理是不同的应用会倾向使用不同的标准信令协议（比如SIP或者XMPP）或者甚至使用一些定制的东西。在这种方法中，浏览器间必须交换的重要信息是多媒体会话描述，其指定了传输（以及交互式连通性建立[ICE]）信息和媒体种类，格式，以及建立媒体通道需要的所有相关媒体配置参数。
以会话描述协议（SDP）“大物件”的形式交换会话描述信息的这种最初想法有着很多缺点，其中一些会很难寻址。因此，IETF任务组正在进行JavaScript会话建立协议的标准化工作。JSEP提供了一个应用所需要的接口来处理的协商本地与远端会话描述，与应用和ICE状态机互动的标准化方法一起。JSEP把驱动信令状态机的任务完全交给了应用。不是简单的转发浏览器发射给远端的信息，应用必须在正确的时间调用正确的API，并且转换会话描述和相关的ICE信息到它选择的信令协议中的已定义信息中去。
API
W3C WebRTC 1.0 API让JavaScript应用能开发新浏览器的实时功能。它要求浏览器内核提供建立所需音频，视频，以及数据通道的功能。但是，正在进行的归一化工作在浏览器内核会用到音频（G.711，opus，vorbis等等）和视频（H.264，VP8等等）编解码器方面并没有做出决策。目前的设想是所有的媒体流和视频流都会被编码。
API是基于这三个主要概念所设计的：对等连接（PeerConnection），媒体流（MediaStreams），以及数据通道（DataChannel）。
PeerConnection
PeerConnection对等连接使两个用户能够直接的进行通信，从浏览器到浏览器。然后其展现了与远端对等体的关联，通常都是在远端同一个JavaScript应用运行的另一个实体。通信通过网页服务器页面的脚本代码所提供的信令通道来被调节—比如，使用XMLHttpRequest或者WebSocket。一旦呼叫浏览器建立了一个对等连接，它就能发送媒体流对象直接给远端浏览器。
对等连接的机理使用了ICE协议，与STUN和TURN服务器一起，使基于UDP的媒体流能够穿过NAT框和防火墙。ICE让浏览器能在它们被部署去找到最佳开发通信通道的网络上发现关于网络拓扑结构足够多的信息。使用ICE还能够提供安全措施，因为它能在向主机发送数据的过程中阻挡那些不想接收到的不可信的网页和应用。
远端主机把这些信令信息提供到对等连接中。API发送绝大多数应用会将其视为不透明块的信令信息，但是这些信息必须由网页应用既安全又高效地通过网页服务器传递给其他对等端。
MediaStream
MediaStream媒体流是音视频实际数据流的一种抽象的表现。其就像在媒体流上管理动作的一个手柄—例如显示这个流的内容，记录它，或者是将它发送给远端对等体。一个媒体流可以被延伸表现一个要么从远端节点传入（远端流）或者发送到远端节点（本地流）。一个本地媒体流体现的是一个从本地媒体捕捉设备（比如网络摄像头或者麦克风）传来的媒体流。
为了产生并使用本地媒体流，网页应用必须通过getUserMedia()函数来从用户处请求。应用要指定媒体的类型—音频还是视频—哪些是需要接入的。浏览器接口中的设备选择器允许或者拒绝接入。一旦应用的工作完成，其就能通过调用本地媒体流内的stop()函数来撤回权限。
媒体流平面信令在对等端带外传递。图2显示了媒体传输所需的协议信令。安全实时传输协议（SRTP）携带媒体数据和RTP控制协议（RTCP）信息常常联合数据流来监控传输状态。数据包传输层安全（DTLS）被用来当做SRTP秘钥以及联合管理。IETF任务组仍然在讨论使用SDP安全描述媒体流（SDES）作为替代秘钥且联合管理的观点。
在多媒体会话中，每个媒介都在独立的RTP会话中和其自身的RTCP包被承载。但是，为了克服给每个使用的流打开新的“孔洞”这个问题，IETF任务组正在通过合并多媒体通道为一个单一的RTP通话的方法，进行减少基于RTP实时应用消耗的传输层端口数量的工作。
