研讨会期间，各企业一致同意继续在相关标准化论坛上公开合作，而不是专门为此形成一个联盟。
2011年3月，WHATWG方案经过全面修订。设备元素被丢弃，转而采用纯JavaScript API。这一版本的API内容详细全面，达到了实施水平。信令经过更新到与SDP offer/answer兼容，包括点对点之间实际SDPs的带外传输，由应用开发人员决定如何通过服务器将信令消息传输给远端对等方。如何传输与媒体平面无直接关系的所有高层信号也完全由应用开发人员决定。
2011年8月，万维网联盟工作小组决定对WHATWG规范进行深入调查，之后在Web实时通信（WebRTC）工作小组的现有工作基础上对调查结果进行了一系列修订，但原始规范的基本结构和原则保持不变。
API有两个基本概念：MediaStream和PeerConnection。MediaStream是实际媒体流的抽象表现。它是管理流内容展示、录音或发送给远端对等方等媒体流行为的抓手。LocalMediaStream代表来自本地摄像机、耳机或其他媒体采集设备的媒体流。为获取本地流，Web应用必须要求用户访问（通过“getUserMedia”功能）。该应用确定它要求访问的媒体类型：音频或是视频。浏览器接口的设备选择器作为同意或拒绝访问的机制。PeerConnection代表与远端对等方的联系，通常是指另一个在远端运行相同Web应用的实例。一旦对等连接建立后，MediaStream对象可以发送给远端对等方。对等连接机制使用ICE穿越NAT和防火墙。使用ICE提供安全手段，它可以防止非信任的网页和应用向主机随意发送数据。媒体平面的信令在点对点之间带外发送。API将发送将被大多数应用视为不透明二进制对象的信令消息，但它们必须由Web应用安全有效地传输到其他对等方。每个信令消息到达后将立即被输入到负责接收的对等连接，同时RTP携带着媒体数据。对等连接概念包含一个功能，即Web应用可以向远端对等方发送通用数据。
只开发媒体控制平面API的主要动机是许多可能受益于这一技术的现有服务已经有了用户相互寻找的成熟管理机制。在一些情况下，双向、低延时通道可用于在端点之间传送信令消息。以社交网络服务为例，用户是服务的基本组成部分。用户相互寻找途径和互动交流是主要服务。根据人们对朋友、同事和校友的分类，自然地形成不同的用户群。视频聊天等服务是服务的延伸。这种情况下就需要找到妥善向现有平台增添更多服务的解决方案。该API就是这样一种解决方案，它仅负责在端点之间建立起媒体流，而不关心这些端点如何、何时和为什么决定进行通信。
社交平台上当用户群在轻松会议环境中进行通信时，点对点模式可能需要补充网络基础设施才能连接多于2个或3个以上的参与者。一般用户可用的上行带宽可能不足以与多人同时并行通信，但是这一模式可以得到演进，以便使端点成为会议混音器。
应用开发人员和Web服务提供商决定如何发现和连接Web应用的对等实例（Peer）。API要求浏览器内核具有建立所需音频和视频通道的功能。正在进行的标准化工作尚未就那些编码（Codec）做出定论。目前假定所有媒体和数据流始终是加密。
未来通信服务
WebRTC API工作重点是提供Web应用基本功能（媒体处理、建立连接和NAT穿越），使开发人员自由设计用户体验，与网络服务相结合，提供发现和连接机制（即呼叫控制机制）。这种方法与Web浏览器的固有能力结合起来，使云和网络服务满足使用不同终端设备的客户需求，从而为开发创新Web应用提供强有效的工具箱。
过去20年来，移动电话服务主导了实时、同步通信的发展。现在情况正在发生变化。未来通信服务的发展方向受到多种因素的影响，其中一个就是功能强大的智能电话、平板电脑和笔记本电脑价格正越来越有吸引力，数十亿用户将能使用支持WebRTC的应用设备：固定和移动宽带的功能与可用性正在增加 - 尽管不能期待普遍实现Mbps级的广域覆盖，但人口稠密区域的传输需要将触发实时通信RTC的业务演进（特别是视频）；日益城镇化在全球和地区带来挑战的同时也创造了需要创新解决方案和服务的商业机遇；在对高效、减排的会议替代系统需求的推动下，企业通信日益数字化；借助高效通信工具，创新一片兴旺，显示出生生不息的特性。
