WebRTC能否在createOffer后调用getUserMedia添加音视频流

完全支持延后调用navigator.getUserMedia动态添加媒体流，这是WebRTC标准原生支持的能力，没有任何架构层面或者浏览器兼容性的障碍，你现在已经搭好的纯文本WebRTC通道完全可以平滑扩展支持按需开启音视频。

你现在搭建的纯文本WebRTC通道，本身就是只依赖RTCDataChannel完成信令交互、ICE连通性检查，从建连开始就没有携带任何音视频轨道，这个状态完全符合WebRTC规范——从来没有强制要求建连阶段必须挂载媒体流。
当用户点击按钮触发音视频需求时，按下面的步骤操作就行：

• 这个节点才调用navigator.getUserMedia请求麦克风、摄像头权限，浏览器只会在用户主动触发操作后才弹出权限申请，完全避免了“用户没主动开音视频就提前索要设备权限”的问题
• 拿到合法的媒体流后，遍历流里的所有轨道，直接在已经存在的RTCPeerConnection实例上调用addTrack()，把轨道挂到连接上
• 轨道挂载完不需要重建整个PeerConnection，只要按照你已经跑通的原有信令逻辑，触发一次SDP重协商就行：重新生成本地Offer、和对端交换Answer、完成新一轮ICE连通性检查即可，整个过程不会中断已经稳定运行的文本聊天通道

很多开发者形成“必须在createOffer前拿到媒体流再挂载”的固化印象，基本都是受了早期过时教程的影响：

• 早期WebRTC版本用的是已经废弃的addStream()API，当时的教程大多引导开发者在PeerConnection初始化阶段就把整个媒体流塞进去再走建连流程，才形成了“流程必须前置”的刻板印象
• 现代WebRTC基于RTP Sender/Receiver的动态轨道管理模型，天生就支持协商完成后动态增删媒体轨道，根本不需要为了加流重建整个连接
• 进阶优化思路：如果想进一步减少重协商的信令开销，可以在初始化纯文本连接的时候，就通过addTransceiver()提前创建对应方向的媒体收发器，把初始收发方向设为inactive，等需要开音视频时，直接把拿到的媒体轨道绑定到对应的RTP Sender上就行，甚至可以省掉一次完整的SDP重协商流程

• 重协商阶段一定要加信令状态锁，等上一轮SDP交换完成、PeerConnection回到stable状态后再触发新的Offer生成，不然很容易出现状态错误导致的协商失败（常见报错就是Failed to set remote offer sdp: Called in wrong state: kStable）
• 对端需要提前绑定ontrack事件监听，等到真的收到新增的媒体轨道时，再动态创建对应的<audio>/<video>播放节点，不要提前初始化空的播放容器
• 一定要做好设备权限拒绝、无可用音视频设备的异常兜底，不要因为媒体流获取失败，把已经正常工作的文本聊天连接搞崩
• 媒体轨道的动态增减和RTCDataChannel的文本传输是完全独立的，媒体轨道的协商过程不会中断已经在传输的文本数据

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