SRS项目中WebRTC播放失败问题分析与解决方案

问题背景

在使用SRS(Simple RTMP Server)5.0版本进行WebRTC流媒体传输时，开发者遇到了一个典型的兼容性问题：当推流端仅包含视频轨道(m=video)而没有音频轨道(m=audio)时，虽然推流成功，但播放端却无法正常播放。这个问题源于WebRTC协议中SDP协商的严格性要求。

问题现象分析

从技术细节来看，当播放端发起WebRTC连接时，会发送一个包含音频和视频轨道的SDP offer。然而，由于源流仅包含视频轨道，SRS服务器返回的SDP answer中只包含视频轨道。这种m-line顺序不匹配的情况触发了WebRTC协议的严格检查机制，导致播放失败。

具体表现为：

1. 播放请求的SDP offer中包含m=audio和m=video
2. 服务器响应的SDP answer中仅包含m=video
3. 浏览器控制台报错："Failed to set remote answer sdp: The order of m-lines in answer does not match order in offer. Rejecting answer"

技术原理

WebRTC协议要求SDP offer和answer中的m-line顺序必须严格一致。这是协议设计中的一项重要约束，目的是确保双方对媒体流的理解一致。当offer中包含音频和视频轨道，而answer中只包含视频轨道时，这种顺序不匹配会导致协商失败。

解决方案

针对这一问题，最合理的解决方案是在播放端创建offer时明确指定只需要接收视频轨道。通过RTCPeerConnection的createOffer方法的options参数可以精确控制：

const pc = new RTCPeerConnection();

const options: RTCOfferOptions = {
  offerToReceiveAudio: false,
  offerToReceiveVideo: true
}

const rtcSessionDescriptionInit = await pc.createOffer(options)

这种方法有以下优势：

1. 从源头避免了不必要的音频轨道请求
2. 生成的SDP offer只包含视频轨道，与服务器响应完全匹配
3. 符合WebRTC协议规范，确保协商成功

最佳实践建议

在实际开发WebRTC应用时，建议开发者：

1. 明确媒体需求：在创建offer前，应清楚知道需要接收哪些媒体类型
2. 动态适配：可以根据流媒体源的实际情况动态调整offer选项
3. 错误处理：对协商失败的情况做好错误处理和回退机制
4. 日志记录：详细记录SDP交换过程，便于问题排查

总结

WebRTC协议中的SDP协商是一个严格的过程，任何不匹配都可能导致连接失败。通过精确控制offer的生成参数，可以避免这类问题的发生。这一解决方案不仅适用于SRS项目，对于所有WebRTC应用开发都具有参考价值。理解WebRTC协议的底层机制，有助于开发者构建更稳定可靠的实时通信系统。