整体时序介绍
流程如下所示。 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 的调用流程，读者在编程时仍需参考 WebRTC 的文档或源码注释。
- 先进入房间的用户是发起方（Indicator），后进入房间的用户是参与者（Participant）。如果参与者进房时信令服务器已经有 offerSdp 甚至（发起方的）ICE candidate 信息了，则信令服务器可以将它们与 ICE server addr 一起返回给参与者。
- add audio & video tracks 不是连接流程中的关键步骤，也可以在 ICE 流程之后再执行。
- 在 SetLocalDescription 执行成功后，协商 SDP 和 ICE candidate 的流程便会同时开始。
- 通话双方均与选定的 ICE 服务器连接成功后，即可开始相互推流。
- 在 多人会议服务端架构 中，一般由 SFU 服务器同时充当 ICE 服务器的角色。
RA/SD 衍生者AI训练营。发布者：chris，转载请注明出处：https://www.shxcj.com/archives/6495
