WebRTC客户端与SFU信令交互：多端点连接发起及ICE工作机制咨询

一、告知SFU连接B、C的信令流程 #

SFU的核心逻辑是所有媒体流通过服务端中转，所以A不需要直接和B、C做信令交互，所有请求都发给SFU对应的信令服务即可，完整流程如下：

• 加入房间：A首先向信令服务发送join请求，携带目标房间ID、自身用户标识，请求加入B、C所在的房间。请求成功后，信令服务会返回当前房间内的在线用户列表，A可以拿到B、C的用户ID、对应发布的流ID等信息。
• 发布本地流：A向SFU发送publish信令，携带本地音视频流的元数据、用于上行推流的SDP Offer。SFU收到后回复SDP Answer，双方完成上行媒体通道的PeerConnection初始化，A后续会把本地流推送到SFU，由SFU转发给房间内其他订阅的用户。
• 订阅B、C的流：A向SFU发送subscribe信令，在请求参数中明确指定需要订阅的流ID列表（也就是B、C发布到SFU的流ID），明确告知SFU自己需要拉取B、C的媒体流。
• 建立下行通道：SFU收到订阅请求后，会针对每个被订阅的流，分别向A返回对应流的SDP Offer，A收到后回复SDP Answer，为每个下行流完成PeerConnection初始化。如果是单PeerConnection多路复用的SFU实现，只会生成一个SDP Offer携带所有订阅流的信息，不需要为每个流单独建连接。

如果B、C在A加入房间后才进入，信令服务会主动向A推送user-joined通知，A收到后再执行subscribe流程即可。

二、该部署场景下的ICE工作流程 #

SFU架构下ICE协商只发生在端点和SFU之间，A不需要和B、C直接交换ICE信息，每个PeerConnection（上行推流、下行拉流的每个连接）都会独立走一次ICE流程：

• 候选收集：A和SFU在初始化对应PeerConnection时，会分别收集三类ICE候选：主机候选（本地网卡的IP+端口）、服务器反射候选（STUN服务器返回的公网出口IP+端口）、中继候选（TURN服务器分配的中转IP+端口）。
• 候选交换：A和SFU会把自己收集到的所有ICE候选，通过SDP信令或者单独的ice-candidate信令，经由信令通道发送给对方。
• 连通性检查：A和SFU会将收到的对方候选和自身候选生成候选对，按照优先级从高到低依次发起连通性检测，优先级顺序为 主机候选对 > 服务器反射候选对 > 中继候选对，优先选择时延最低的可用路径。
• 协商完成：找到可用的连通路径后，ICE协商完成，媒体流就可以通过该路径在A和SFU之间传输。SFU后续会负责将A的上行流转发给B、C，同时将B、C的流转发给A。

内容的提问来源于stack exchange，提问作者durgesh