WebRTC架构和协议栈-zz

为了便于理解，咱们来看一个最基本的三角形WebRTC架构（图4）。在这个架构中，移动电话用“浏览器M”表示，笔记本电脑用“浏览器L”表示，经过Web服务器将它们链接起来。要创建一个实时媒体通信，两台设备须要了解彼此的媒体功能，经过交换呼叫信令控制协议实现。诸如这样的信令协议在WebRTC标准中并不是事先规定，而是由开发者自行制定。在浏览器RTC会话的步骤以下:

首先，两个浏览器都从Web服务器下载了WebRTC程序（HTML5/JavaScript）；

其次，两个浏览器经过Web服务器交换控制信令信息（使用嵌入式信令服务器），创建媒体功能功能互通；

最后，两个浏览器直接创建RTC媒体的音频、视频和数据通道。

WebRTC使用P2P媒体流，音频、视频和数据的链接直接经过浏览器实现。可是，浏览器却隐藏在NAT（网络地址翻译）和防火墙的后面，这增长了创建P2P媒体会话的难度。这些流程和协议，如ICE或Trickle ICE，STUN和TURN，在创建P2P媒体流都是必不可少的。

如何使用STUN协议创建一个P2P RTC媒体（如图5所示），简化版的ICE流程以下：

1.两个浏览器经过本身的公网IP地址，使用STUN协议信息和STUN服务器创建联系；

2.两个浏览器经过SDP提供/应答机制，使用呼叫控制信令消息交换它们已发现的公共IP地址（ICE候选）；

3.两个浏览器执行链接检查（ICE冲孔），确保P2P能够链接；

4.创建链接后，RTC媒体会话和媒体交换就能够实现了。

可是，假如在一个高度限制的NAT或防火墙，这种直接的路径将没法创建，只能到达TURN服务器。结果是媒体经过TURN服务器分程传递（如图6所示）。

由互联网工程任务组（IETF）基于标准的可互操做的通讯模型和协议栈详细地定义了WebRTC技术（参见图7），以下：

›如前所述的信令栈，并不是由WebRTC实现规定，而是由开发者自行决定。在这个例子中，咱们将使用SIP-over-WebSocket（SIPoWS）做为信令栈。HTTP协议用于浏览器下载HTML5/JavaScript程序内容；

›NAT栈解决P2P链接问题；

›媒体栈用于发送和接收RTC的音频和视频。LETF标准规定G.711和Opus做为音频/视频解码器。视频解码器还没有受权，可是H.248和VP8已经得到受权。媒体栈也用于交换RTC数据。本例中，实时信息采用消息会话中继协议（MSRP），实时会议采用二层控制协议（BFCP），实时文本服务采用T.140。