作者: 亢少军
信令服务
从上面我们知道了2个客户端协商媒体信息和网络信息,那怎么去交换?是不是需要一个中间商去做交换?所以我们需要一个信令服务器(Signal server)转发彼此的媒体信息和网络信息。
我们在基于WebRTC API开发应用(App)时,可以将彼此的App连接到信令服务器(Signal Server,一般搭建在公网,或者两端都可以访问到的局域网),借助信令服务器,就可以实现SDP媒体信息及Candidate网络信息交换。
信令服务器不只是交互媒体信息SDP和网络信息Candidate,比如: 房间管理,用户列表,用户进入,用户退出等IM功能。如图所示。
在WebRTC中用来描述网络信息的术语叫candidate,如下所示。
- 媒体协商:sdp
- 网络协商: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 添加本地媒体流。处理流程如下所示。
- A创建Offer
- A保存Offer(设置本地描述)
- A发送Offer给B
- B保存Offer(设置远端描述)
- B创建Answer
- B保存Answer(设置本地描述)
- B发送Answer给A
- A保存Answer(设置远端描述)
- A发送Ice Candidates给B
- B发送Ice Candidates给A
- A,B收到对方的媒体流并播放
这里我们不介绍具体API的使用及代码编写,只需要理解连接建立并通话的原理及流程即可。