第三章 流式流转时序图

整体时序介绍

流程如下所示。 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收到对方的媒体流并播放

时序图

从通讯角色角度的示意图

注意事项

这里针对时序图中的一些情况做具体说明：

1. 上图不完全是 API 的调用流程，读者在编程时仍需参考 WebRTC 的文档或源码注释。
2. 先进入房间的用户是发起方（Indicator），后进入房间的用户是参与者（Participant）。如果参与者进房时信令服务器已经有 offerSdp 甚至（发起方的）ICE candidate 信息了，则信令服务器可以将它们与 ICE server addr 一起返回给参与者。
3. add audio & video tracks 不是连接流程中的关键步骤，也可以在 ICE 流程之后再执行。
4. 在 SetLocalDescription 执行成功后，协商 SDP 和 ICE candidate 的流程便会同时开始。
5. 通话双方均与选定的 ICE 服务器连接成功后，即可开始相互推流。
6. 在 多人会议服务端架构 中，一般由 SFU 服务器同时充当 ICE 服务器的角色。