标准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的方案。
在线体验单端口直播与一对一视频通话: