Salvatore Loreto, Simon Pietro Romano
DataChannel
DataChannel数据通道提供了一个通用传输服务，可以使网页浏览器进行双向P2P的通用数据交换。在IETF任务组中，标准化工作已经在使用封装在DTLS中的流控制传输协议（SCTP）来处理非媒体数据类型这一方面达到了共识。“UDP中套ICE套DTLS套SCTP”这种封装提供了一个NAT穿透办法，集机密性，来源验证，以及保证完整性的传输为一体。此外，这个办法使数据传输与平行媒体传输相互联合地更流畅，并且二者都能够共享一个传输层端口号。IETF任务组选择SCTP是因为它本地支持可靠的，不可靠的，以及部分可靠的多流传输模式。其允许应用靠着SCTP与对等的SCTP端点的联合，打开一些独立的流（每个方向最多65536个）。每个流事实上表现为单向逻辑通道，提供了顺序传递。
应用既可以有序地，也可以无序地发送一个信息序列。信息传输顺序被保存下来只是为了在同一流上发送的都是有序地信息。但是，数据通道API是双向的，这意味着每个数据通道能够捆绑一个流入和一个流出的SCTP流。
应用在实体化对等连接对象中第一次调用CreateDataChannel()函数的时候，设定数据通道（也就是，产生SCTP联合）。每个分布的调用CreateDataChannel()函数都会在现存的SCTP联合中产生一个全新的数据通道。
一个简单的例子
Alice和Bob使用一款普通的呼叫服务。为了进行通话，他们必须同时地连入网页服务器来使用这项服务。确实，当Bob（或者Alice）点击他的浏览器来调用服务网页的时候，他就会下载HTML页和JavaScript来通过安全HTTP或者WebSocket保持浏览器的连接状态。
图中表示了一个典型的呼叫流与设定一个实时、基于浏览器的通信通道相联合。当Alice点击网页上的按键来启动与Bob的通话时，JavaScript把对等连接对象实体化。一旦对等连接生成了，呼叫服务端上的JavaScript代码就必须通过MediaStream函数设定媒体。Alice也必须同意对话请求来使呼叫服务能够连接她的摄像头和麦克风。
在目前的W3C API中，一旦应用中已经加入了某些流，Alice的浏览器，充满了JavaScript代码，产生了信令信息。IETF任务组还没有定义这种信息的准确格式。其必须包含媒体通道信息和ICE候选，以及绑定Alice公共秘钥的通信指纹。Alice的浏览器随即发送这个信息到信令服务器（例如，通过XMLHttpRequest或者WebSocket）。信令服务器从Alice的浏览器内处理信息，判断出这是一个打给Bob的电话，然后发送信令信息给Bob的浏览器。Bob的浏览器上的JavaScript处理输入的信息，并且提醒Bob。Bob决定是否要接听这个电话，在他浏览器内运行的JavaScript之后实体化一个与从Alice那边传来的信息相关的对等连接。Bob的浏览器验证这个呼叫服务已经被确认并且媒体流已经产生；之后，其产生一个包含媒体信息和ICE候选的信令信息，以及通过信令服务发回一个指纹给Alice。
拥塞控制
拥塞控制机理的讨论特别设想了交互式的媒体和主句的传输处在一个非常初始的阶段—IETF任务组甚至还没有决定是否开始进行此项工作。此理论严谨地将流的拥塞控制翻倍，完美地给所有WebRTC传输只用了一个拥塞控制实例（也就是，音频，视频，或者数据）。在同一时刻，WebRTC传输束的不同部分的优先化也应该成为可能。
