WebRTC通话原理

原理"/>

WebRTC通话原理

作者: 亢少军

信令服务

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

在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的使用及代码编写，只需要理解连接建立并通话的原理及流程即可。

WebRTC交流群: 425778886
开源地址:
学习地址：