什么是 WebRTC ？

WebRTC（Web Real-Time Communication）是 Google于2010以6829万美元从 Global IP Solutions 公司购买，并于2011年将其开源，旨在建立一个互联网浏览器间的实时通信的平台，让 WebRTC技术成为 H5标准之一。我们看官网（https://webrtc.org）的介绍

其中：

• Web Real-Time Communications (WEBRTC) W3C 组织：定义浏览器 API。
• Real-Time Communication in Web-browsers (RTCWEB) IETF 标准组织：定义其所需的协议，数据，安全性等手段。

• 

  简单来说，WebRTC 是一个可以在 Web 应用程序中实现音频，视频和数据的实时通信的开源项目。在实时通信中，音视频的采集和处理是一个很复杂的过程。比如音视频流的编解码、降噪和回声消除等，但是在 WebRTC 中，这一切都交由浏览器的底层封装来完成。我们可以直接拿到优化后的媒体流，然后将其输出到本地屏幕和扬声器，或者转发给其对等端。

  点对点音视频的难点

  抛开低延迟、流畅性、回声消除和海量并发这些难点不讲，单纯从功能来看，打通通讯双方的两端，让彼此能正常视频及通话，主要存在两个问题：

  （1）网络打通问题--无公网IP无法直接通信

  当今互联网到处存在着一些中间件(MIddleBoxes)，如NAT和防火墙，导致两个(不在同一内网)中的客户端无法直接通信。这些问题即便是到了IPV6时代也会存在，因为即使不需要NAT，但还有其他中间件如防火墙阻挡了链接的建立。

  当今部署的中间件大多都是在C/S架构上设计的，其中相对隐匿的客户机主动向周知的服务端(拥有静态IP地址和DNS名称)发起链接请求。大多数中间件实现了一种非对称的通讯模型，即内网中的主机可以初始化对外的链接，而外网的主机却不能初始化对内网的链接，除非经过中间件管理员特殊配置。在中间件为常见的NAPT的情况下，内网中的客户端没有单独的公网IP地址，而是通过NAPT转换，和其他同一内网用户共享一个公网IP。这种内网主机隐藏在中间件后的不可访问性对于一些客户端软件如浏览器来说并不是一个问题，因为其只需要初始化对外的链接，从某方面来看反而还对隐私保护有好处。然而在P2P应用中，内网主机（客户端）需要对另外的终端（Peer）直接建立链接，但是发起者和响应者可能在不同的中间件后面，两者都没有公网IP地址。而外部对NAT公网IP和端口主动的链接或数据都会因内网未请求被丢弃掉。对于WebRTC来说，首先要解决的是如果跨越NAT实现内网主机直接通讯的问题。

  

  （2）媒体格式编码问题--媒体格式编码多样不统一

  对于需要音视频通信的双方，彼此要了解对方支持的媒体格式才能正常地对流媒体编解码。比如，Peer­A端可支持VP8、H264多种编码格式，而Peer­B端支持VP9、H264，要保证二端都正确的编解码，最简单的办法就是取它们的交集H264。有一个专门的协议称为SDP（Session Description Protoco），可用于描述上述这类信息，在WebRTC中，参与视频通讯的双方必须先交换SDP信息，这样双方才能知根知底，而交换SDP的过程，也称为“媒体协商”

  SDP(Session Description Protocol) 是一种会话描述协议，基于文本，其本身并不属于传输协议，需要依赖其它的传输协议（比如 SIP 和 HTTP）来交换必要的媒体信息，用于两个会话实体之间的媒体协商。SDP(会话描述协议)定义了一个标准，用于定义两个（通常）端与端之间媒体（通常是流媒体）交换的参数。IETF已将其发布为RFC 4566。SDP通常嵌入或封装在另一个协议中，最广泛使用的应用程序位于大多数IP电话应用程序的SIP协议内部。简单地说，SDP协议是媒体端到端对其接收规范和能力的声明；典型的声明会告诉我们：

  （1）哪个IP地址准备好接收传入的媒体流

  （2）哪个端口号正在侦听传入的媒体流

  （3）端点希望接收的媒体类型（通常是音频）

  （4）端点希望在哪个协议中交换信息（通常为RTP）

  （5）端点能够解码的压缩编码（编解码器）

  在一个典型的会话设置过程中，我们会看到两个端点参与一个会话，其中每个端点发送一个SDP以通知另一个端点其规范和功能。SDP本身不提供任何媒体，但仅限于协商一组兼容的媒体交换参数；媒体流本身由不同的通道和协议处理。

  一个 SDP 的握手由一个 offer 和一个 answer 组成

  WebRTC通话原理

  点对点的双方为了实现实时音视频通信， WebRTC需要解决媒体协商和网络协商问题，这里要引入信令服务器(Signaling Server)和STUN server

• 

  Signaling Server

  需要通信的双方之间建立WebRTC连接需要一个信令服务器来实现双方通过网络进行连接。信令服务器的作用是作为一个中间人帮助双方在尽可能少的暴露隐私的情况下建立连接。WebRTC并没有提供信令传递机制，信令的传递和交换需要服务器参与，这个角色就是信令服务器。WebRTC信令指建立、控制和终止通信会话的过程以及业务本身的需求来看，需要交换几个信息：媒体信息，网络信息，具体业务。

  • 一、媒体信息

  需要媒体数据来确定呼叫者和被呼叫者共有的编解码器和媒体类型。如果尝试启动通信会话的端具有不同的分辨率和编解码器配置，则会话不太可能成功。通过使用会话描述协议（SDP）格式的提供和应答在对等方之间交换媒体配置信息的信令，这些信息是通过SDP协议描述出来，通过信令服务器中转的。

  • 二、网络信息

  两个WebRTC客户端如何发现对方的？通过信令服务器交互双方在Internet上的位置（IP地址和端口），以便呼叫者可以找到被呼叫者。

  • 三、具体业务

  会话控制信息确定何时初始化、关闭和修改通信会话，比如加入房间，离开房间，禁言，媒体流订阅发布等功能，需要信令服务器来控制。

• 

• **STUN server **

  STUN （Session Traversal Utilities for NAT ，NAT会话穿越应用程序）是一种 网络协议，它允许位于 NAT**（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间建立UDP通信。该协议由RFC 5389定义。****STUN 是 C/S 模式的协议，可以简单理解为：由客户端发送 STUN 请求；STUN 服务响应，告知由 NAT 分配给主机的 IP 地址和端口号。一旦拥有了ip和端口，点对点通信的双方就能直连通信了。（注：以上的响应同时还使得STUN客户端能够确定正在使用的 NAT类型——因为不同的NAT类型处理传入的UDP分组的方式是不同的。四种主要类型中有三种是可以使用的： 完全圆锥型NAT 、 受限圆锥型NAT和 端口受限圆锥型NAT ——但大型公司网络中经常采用的对称型NAT（又称为双向NAT）则不能使用，这时TURN就要登场了，本文暂且不讲）

• 

  专有名词介绍

  Signaling Server ：信令服务器，负责处理通信双方的信息交互，包括媒体信息，网络信息，业务信息。

  STUN server：STUN的全称是Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)， 即穿越NAT的简单UDP传输，是一个轻量级的协议。可以简单理解为：由客户端发送 STUN 请求；STUN 服务响应，告知由 NAT 分配给主机的 IP 地址和端口号。

  SDP：Session Description Protocol 为了连接到对端用户，我们必须要对其他用户的设备情况有所了解，比如音频视频的编码解码器、使用何种编码格式、使用何种网络、设备的数据处理能力，，而 SDP 为我们提供了这些功能

  ICE：Interactive Connectivity Establishment 通信的两侧可能会处于不同的网络环境中，有时会存在好几层的访问控制、防火墙、路由跳转，所以我们需要一种方法在复杂的网络环境中找到对方，并且连接到相应的目标。WebRTC 使用了集成了 STUN、TURN 的 ICE 来进行双方的数据通信。

  offer、answer：一个 SDP 的握手由一个 offer 和一个 answer 组成，一方发送offer，另一方接收到offer后，发送answer。

  **WebRTC音视频通信流程

  

  **

  在同一房间的双方通过WebRTC建立音视频通信，主要分为四个阶段：

  （一）加入房间、呼叫对方，对方应答

  ** **（1）ClientA登录后连接信令服务器，选择进入某个房间；

  ** **（1）ClientB登录后连接信令服务器，选择进入某个房间；（1）（2）不分先后

  ** **（3）ClientA 在此房间中看到ClientB在线，选择呼叫ClientB；

  ** **（4）ClientB选择同意接听； （3）（4）中的ClientA和ClientB可以互换；

  （二）交换SDP，发送/接收offer，发送/接收answer

  ** **（1）ClientA 执行getUserMedia() ->new RTCPeerConnection->Peer.addStream->createOffer

  ** **（2）ClientB 执行getUserMedia() ->new RTCPeerConnection->Peer.addStream；（1）（2）并行执行；

  ** **（3）ClientA通过信令服务器中转offer给ClientB；

  ** **（4）ClientB收到offer后，setRemoteDescription->createAnswer；并通过信令服务器中转answer给ClientA；

  ** **（5）ClientA收到answer后，setRemoteDescription；

  （三）交换ICE candidate

  ** ****（1）ClientA 向STUN Server请求ICE（请求可能在之前某个时候已经发出），STUN Server返回ICE candidate **

  ** ****（2）ClientB 向STUN Server请求ICE（请求可能在之前某个时候已经发出），STUN Server返回ICE candidate **

  ** **（3）ClientA通过信令服务器中转ICE candidate到达ClientB；ClientB通过信令服务器中转ICE candidate到达ClientA；

  ** **（4）ClientA收到B的ICE canditate，addIceCandidate

  ** **（5）ClientB收到A的ICE canditate，addIceCandidate

  （四）开始音视频通信

  ** **（1）ClientA addStream 展示对方远程音视频流；

  ** **（2）ClientA addStream 展示对方远程音视频流；