作者: 亢少军

信令服务

从上面我们知道了2个客户端协商媒体信息和网络信息,那怎么去交换?是不是需要一个中间商去做交换?所以我们需要一个信令服务器(Signal server)转发彼此的媒体信息和网络信息。
我们在基于WebRTC API开发应用(App)时,可以将彼此的App连接到信令服务器(Signal Server,一般搭建在公网,或者两端都可以访问到的局域网),借助信令服务器,就可以实现SDP媒体信息及Candidate网络信息交换。
信令服务器不只是交互媒体信息SDP和网络信息Candidate,比如: 房间管理,用户列表,用户进入,用户退出等IM功能。如图所示。

WebRTC通话原理-信令服务-连接建立_WebRTC

在WebRTC中用来描述网络信息的术语叫candidate,如下所示。

  1. 媒体协商:sdp
  2. 网络协商:candidate

连接建立

介绍完ICE框架中各个独立部分的含义之后,在让我们来看一看整个框架是如何工作的,流程如下所示。
1.连接双方(Peer)通过第三方服务器来交换(Signaling)各自的SessionDescription数据。

2.连接双方(Peer)通过STUN协议从STUN Server那里获取到自己的NAT结构、子网IP和公网IP、端口,这里的IP和端口对我们称之为ICE Candidate。

3.连接双方(Peer)通过第三方服务器来交换(Signalling)各自ICE Candidates,如果连接双方在同一个NAT下那他们仅通过内网Candidate就能建立起连接,反之如果他们处于非对称型NAT下,就需要STUN Server识别出的公网Candidate进行通讯。

4.如果仅通过STUN Server发现的公网Candidate仍然无法建立连接,换句话说就是连接双方(Peer)中至少有一方处于对称NAT下,这就需要处于对称NAT下的客户端(Peer)去寻求TURN Server提供的转发服务,然后将转发形式的Candidate共享(Signalling)给对方(Peer)。

5.连接双方(Peer)向目标IP端口发送报文,通过SessionDescription中涉及的密钥以及期望传输的内容,建立起加密长连接。

A(local)和B(remote)代表两个人, 初始化并分别创建PeerConnection , 并向PeerConnection 添加本地媒体流。处理流程如下所示。

  1. A创建Offer
  2. A保存Offer(设置本地描述)
  3. A发送Offer给B
  4. B保存Offer(设置远端描述)
  5. B创建Answer
  6. B保存Answer(设置本地描述)
  7. B发送Answer给A
  8. A保存Answer(设置远端描述)
  9. A发送Ice Candidates给B
  10. B发送Ice Candidates给A
  11. A,B收到对方的媒体流并播放

这里我们不介绍具体API的使用及代码编写,只需要理解连接建立并通话的原理及流程即可。