WebRTC网关服务器单端口方案实现

标准WebRTC链接创建流程

这里描述的是Trickle ICE过程，而且省略了通话发起与接受的信令部分。流程以下：
1） WebRTC A经过Signal Server转发SDP OFFER到WebRTC B。WebRTC B作完本地处理之后，经过 Signal Server转发SDP ANSWER到A。

2）A、B同时向STUN Server发送Binding request请求自身的外网地址，并从STUN Server回包的MAPPED-ADDRESS中获得各自的外网地址；

3）A、B收集完内外网ICE Candidate，并经过Signal Server发送给对方；

4）双方开始作NAT穿越，互相给对方的ICE Candidate发送STUN Binding Request；

5）NAT穿越成功，A、B之间的P2P链接创建，进入媒体互通阶段。在这个过程当中，咱们看到了有三个核心的部分，SDP协商、ICE Candidate交换、Stun Binding Req/Res的连通性检查。

WebRTC网关链接创建流程

在了解了标准WebRTC的建连流程之后，咱们来看看WebRTC客户端如何与网关建连。

首先，咱们网关的Media Server拥有公网IP，所以Server就不须要经过Stun Server收集自身的公网IP。WebRTC客户端先与网关Signal Server协商SDP，包括ICE Candidate，Media Server分配IP和端口做为网关的ice candidate发送给客户端。由于网关是公网IP，因此客户端向这个IP发送STUN Binding Request会被服务器收到， 并回复Response。接着客户端与网关媒体服务器进行DTLS握手与秘钥协商，在此基础上进一步进行SRTP的音视频通讯。至此，WebRTC客户端与网关服务器建连成功。

WebRTC网关服务器媒体架构
最简的服务器端端口方案是咱们能够为每一个客户端分配一个端口，服务器上使用这个端口区分每一个用户，就像图里描述的A、B、C、D四我的在WebRTC网关服务器上分别对应UDP端口10001~1004。这种方案逻辑上很简单，不少开源的服务器都采用这个方案，如janus。另一个缘由是使用了libnice库在服务器上来和客户端作ice建连，相似的作法都是采用多端口的架构。
那么多端口有什么不足呢？
1）不少的网络出口防火墙对可以经过的UDP端口是有限制的；

2）对于服务端来讲开辟这么多端口，安全性自己也有必定的问题，特别是运维同窗，更是拒绝；

3）开辟这么多的端口在Server端上，端口的开销和性能均有必定的影响。那可否用单端口？使用单端口前，核心要解决的一个问题是：如何区分每个RTP/RTCP包是属于哪个WebRTC客户端。

为了解决这个问题，咱们须要使用一些小技巧。首先，有几个基础知识点咱们先了解一下。以下图：

1）SDP offer和answer里配置的ice-ufrag字段里面内容，原来是用来做为stun数据包的鉴权的，所以STUN Binding Request里面的USERNAME字段就是由上Offer和answer的ice-ufrag内容拼接而成。

2）发送STUN Binding Request的客户端本地udp fd，与ice建连成功后发送媒体数据的udp fd是同一个，也就是说Server上看到的ip port是同一个。

有了上面的背景知识，你确定已经大体有一个方案了。咱们来看看实现细节是怎么样的：

1）在服务器给Web端的SDP Answer中设置ice-ufrag为roomid/userid，其中RoomID和UserID是通话业务层分配的内容，用于区分每对通话以及参与者。接着作Ice candidate协商，Web端开始作连通性检测，也就是stun binding request里的USERNAME为SDP local和remote的ice-ufrag指定内容。

2）服务器收到stun binding request的客户端ip和端口，并正常回stun binding response。

3）记录客户端地址与用户的信息的映射关系。

4）服务器收到一个rtp/rtcp媒体数据包，经过包的源ip和端口，查询映射表就能够识别这个包属于哪一个用户。

WebRTC客户端使用PeerConnection来表示不一样的媒体链接，接下来咱们将介绍如何选择PeerConnection的方案。

在线体验单端口直播与一对一视频通话：https://github.com/starrtc/an...