Kurento环境下协商后WebRTC轨道启用/禁用/替换问题

Kurento支持媒体流的启用与禁用，但你的实现方式不符合Kurento的工作机制，导致了GStreamer层面的not-linked错误。以下是问题原因和修正方案：

问题根源 #

你当前的做法是在协商阶段就将禁用的Track添加到PeerConnection，或者在SDP中声明sendrecv但实际无Track输出。Kurento的WebRtcEndpoint依赖GStreamer管道处理媒体流，当你声明要发送媒体（sendrecv）但没有实际的媒体源输出时，GStreamer的nicesrc元素会因为没有可链接的媒体流而报错，进而导致连接断开。

另外，Kurento确实不支持WebRTC重协商，所以依赖negotiationNeeded事件的动态Track管理方式在这里不适用。

正确实现方案 #

方案1：初始协商仅声明接收，需发送时重建PeerConnection #

• 进入房间时，SDP协商将音频、视频都设置为recvonly，不添加本地Track到PeerConnection。
• 用户需要开启视频时，销毁原PeerConnection，创建新实例并设置sendrecv，添加启用的视频Track后重新完成SDP协商。

方案2：使用Kurento服务端API控制流开关 #

Kurento的WebRtcEndpoint提供了enableMedia方法，可在连接建立后动态控制媒体发送/接收：

1. 初始协商时正常添加启用的本地Track，SDP设置为sendrecv。
2. 进入房间后，立即调用服务端API禁用视频发送：

// Java服务端示例
webRtcEndpoint.enableMedia(MediaType.VIDEO, false);

3. 用户开启视频时，调用API重新启用：

webRtcEndpoint.enableMedia(MediaType.VIDEO, true);

这种方式完全由服务端控制媒体流状态，避免客户端Track禁用导致的GStreamer管道错误。

方案3：客户端用静音/黑屏模拟流禁用 #

若必须在客户端控制，保持Track始终enabled=true，通过以下方式模拟禁用效果：

• 音频：将本地音频源设置为静音，而非禁用Track。
• 视频：捕获Canvas生成的黑屏流替换原视频Track，确保始终有媒体流输出到Kurento。

这样既满足用户默认不发送媒体的需求，又不会触发not-linked错误。

关键注意事项 #

• Kurento对SDP声明的媒体流与实际传输流的一致性要求严格，声明sendrecv就必须有对应的媒体流持续输出。
• 禁止直接禁用客户端MediaStreamTrack，这会导致媒体流中断，触发GStreamer管道异常。

内容的提问来源于stack exchange，提问作者Matej Szabó