WebRTC：如何在提前未知轨道数量的场景下完成轨道协商

WebRTC原生的SDP协商机制，没有自带不需要外部交互就能自动对齐双方可用轨道数量的能力，你遇到的收发器数量不匹配就抛错的问题，是协议设计时定好的规则导致的，不是哪个浏览器的实现bug。 #

为什么原生机制没法自动适配双方的收发器数量差 #

• SDP的offer/answer交互是严格基于mid标识的媒体段做一一绑定的：你在生成offer时调用addTransceiver()添加了几个媒体收发器，就会在SDP里生成几个对应媒体行，每个行绑定一个固定的mid编号，后续收到的answer必须和本地维护的收发器列表一一对应，不管是媒体行多了还是少了，浏览器在执行setRemoteDescription()的时候都会直接校验失败抛出错误。
• 协议本身没有内置类似“能力探测”的预协商流程：在第一次完成SDP交换之前，你完全无法从本地API层面获知远端设备的可用轨道总数，所有关于远端媒体能力的信息，只能通过SDP本身或者基于该连接的自定义信令交互获取。
• 不存在靠SDP隐式预留通道的可能性：SDP的媒体行是完全明示的，你在offer里写了几个媒体通道，answer最多只能回传对应数量的通道，没有可以动态填充的隐式位置。

WebRTC原生支持的动态协商边界 #

你不需要为了动态适配轨道数重建RTCPeerConnection，靠标准内置的重新协商（renegotiation）机制就可以覆盖大部分动态场景：

1. 第一轮协商时，不要一开始就把所有预期的视频轨道都通过addTransceiver()加上，只添加1个基础的双向视频收发器完成初始连接建立即可。
2. 完成第一轮协商、拿到对方设备的基础连接能力之后，你可以在任意时机调用addTransceiver()新增需要的视频收发器，这个操作会自动触发浏览器内置的重新协商流程，生成带有新增媒体行的新offer，走和第一次协商一样的信令交换流程即可。
3. 只要每次触发协商前，确保本地和远端的收发器数量、方向配置完全对齐，就不会出现校验报错。

很多开发者会尝试在第一轮协商时提前加足够多的占位收发器来预留通道，但这本质上还是需要你提前预知最大可能的轨道数量，并没有实现真正的动态适配——一旦实际需要的轨道数超过预留值，还是要触发重新协商流程。

两种落地选型对比 #

• 无需额外外部API的纯原生方案：直接复用原本传输SDP、ICE候选的现有信令通道，在连接建立后和对方同步“我需要新增第N路视频”的交互信息，确认对方准备好对应收发器后再触发重新协商。这个方案灵活性最高，哪怕中途设备的可用摄像头数量动态变化（比如插拔外接摄像头），也能随时调整通道数量。
• 轻量外部上报的优化方案：如果你的场景中所有设备的最大可用轨道数是固定不变的，完全可以在SDP协商前，通过简单的接口把双方的最大可用视频轨道数同步给对方，两边一次性配置对应数量的收发器，走单次协商完成所有通道建立。这个方案的优势是减少多轮重新协商的信令开销，降低整体连接建立的延迟。

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