实时音视频 rtc 的媒体协商失败排查：一次说透
作为一个开发者，你有没有遇到过这种情况：信心满满地把音视频功能集成到产品里，测试时却发现双方永远在"握手"阶段卡着不动，黑屏、没有声音、连接超时轮番上阵，让人头大如斗。
说实话，媒体协商失败这个问题，我自己也折腾过无数回。有时候一个小配置就能让你debug一整天，有时候又可能是网络层面的问题防不胜防。今天这篇文章，我想把媒体协商这件事掰开揉碎了讲，不讲那些晦涩的RFC文档，就用大白话把我踩过的坑、总结的经验分享出来。文章会比较长，但相信我看完之后，你对这类问题的排查会有一个系统性的认识。
一、先搞清楚：什么是媒体协商？
在说排查方法之前，我们先来理解一下媒体协商到底是怎么回事。你可以把媒体协商理解为两个人打电话之前的"对频"过程。
比如你想和朋友打视频电话，首先你得告诉对方："我能开摄像头也能开麦克风，支持高清画质，用的是Opus编码器"，然后对方也要告诉你："我这里网络不太好，只能开标清，编码器用VP8就行"。双方把这些能力信息交换清楚之后，才能真正开始通话。这个交换能力信息的过程，就是媒体协商。
在webrtc或者类似的RTC技术栈里，媒体协商主要是通过SDP（Session Description Protocol）协议来完成的。SDP本身就是一个文本格式的描述文件，里面包含了 codec、port、IP 地址、媒体类型等信息。双方通过信令服务器交换SDP，然后各自根据对方的SDP来调整自己的媒体配置。
这个过程听起来简单，但实际跑起来可能会遇到各种问题。任何一个环节出错，都会导致协商失败。下面我会逐个拆解可能的原因。
二、媒体协商失败的几大常见原因
根据我多年的实践经验，媒体协商失败的原因大体可以分成几类。我整理了一个表格，方便你快速对照：
| 问题分类 | 具体表现 | 排查难度 |
| SDP配置问题 | 双方codec不兼容、端口配置错误、媒体属性不匹配 | ⭐⭐ |
| 网络问题 | 防火墙拦截、端口不通、NAT穿透失败 | ⭐⭐⭐⭐ |
| ICE过程问题 | ICE候选收集不完整、STUN/TURN配置错误 | ⭐⭐⭐⭐ |
| SDP丢失或篡改、消息顺序混乱 | td>⭐⭐
接下来我们逐个详细说。
1. SDP配置问题：最容易发现也最好解决
SDP配置问题是最常见的协商失败原因，但好消息是，这类问题通常也比较容易定位。
codec不匹配是最典型的情况。比如A端说"我支持VP8和H264"，但B端说"我只支持VP9"，这时候协商就有可能出问题。当然，大多数现代RTC实现都会包含一个默认的codec作为兜底，但如果你手动配置时漏掉了某些codec，或者配置优先级写错了，就会出现播放端收不到流的情况。
排查建议：打开浏览器的webrtc-internals页面（如果你用的是WebRTC的话），或者打印双方生成的SDP日志，仔细对比codec列表。一般协商成功后，最终生效的codec会出现在remote description里，如果这块是空的或者不对劲，问题就在这儿。
端口配置错误 тоже是个坑。有时候开发环境下localhost测试一切正常，一上生产环境就跪了，很可能就是端口配置没跟着变。我见过有人把监听端口写成127.0.0.1然后放到服务器上跑的，这种低级错误新手容易犯。
2. 网络问题：这个最磨人
网络问题是我觉得最麻烦的一类，因为它的表现有时候很隐蔽。你可能看到SDP交换成功了，ICE过程也在进行，但就是卡在某个状态动不了。
首先是防火墙。现在的云服务器，安全组配置稍微严一点，就会把RTC需要的端口给拦住。RTC一般会用到UDP的端口范围比较大，如果你用的是声网这类专业服务商，他们会有详细的端口说明文档，对照着开放就行。但有些企业内网环境可能更复杂，需要和运维同事多沟通。
然后是NAT穿透。现在的网络环境下，大多数设备都在NAT后面，直接用公网IP是连不上的。ICE协议就是来解决这个问题的，它会收集各种候选地址（Candidate），然后尝试穿透。但如果你没有配置STUN服务器，或者STUN服务器不可用，那NAT穿透可能就无从谈起。
这里有个小技巧：如果你用声网的SDK，他们内置的全球智能路由和节点调度能力，其实已经帮你处理了很多网络层面的问题。我之前自己搭STUN服务器的时候经常翻车，后来换成声网的方案之后，连接成功率和延迟都有明显提升。当然如果你有特殊需求要自建，这块需要多花些心思调试。
3. ICE过程问题：细节决定成败
ICE（Interactive Connectivity Establishment）是WebRTC里用来建立P2P连接的一套机制。它会收集候选地址（Candidates），然后通过STUN和TURN服务器进行连通性检查，最终确定使用哪条路径传输媒体。
ICE失败的原因有很多。最常见的是候选收集不完整。有些设备的网络环境比较复杂，比如同时连着WiFi和有线网卡，或者开了VPN，ICE候选可能会收集到一些无效的地址。如果你的代码没有正确处理这些候选，或者过滤逻辑写错了，ICE过程就会卡住。
还有就是TURN中继的问题。当P2P直连失败时，ICE会尝试通过TURN服务器中继流量。如果你的TURN服务器配置有误，或者带宽不够，媒体流就过不去。这里有个点要注意，TURN服务器需要同时支持UDP和TCP两种协议，有些环境可能只开放了TCP，这时候就需要在SDP里正确配置。
4. 信令传输问题：别让中间人使坏
信令是承载SDP信息传递的通道，如果信令本身出了问题，SDP都交换不了，协商自然无从谈起。
常见的信令问题包括：消息丢失、消息顺序错乱、SDP在传输过程中被篡改。如果你用第三方的信令服务，记得检查一下重连机制和消息确认逻辑。有些实现里SDP比较大，可能需要分片传输，这时候要确保接收端能正确重组。
另外，时间窗口也是一个容易被忽视的点。SDP是有时效性的，如果你收到SDP后处理太久，对方可能已经超时断开连接了。正常情况下，SDP交换应该在秒级完成，如果你的业务逻辑比较复杂，建议先把SDP缓存起来，处理完了再走协商流程。
三、系统化的排查思路
说了这么多问题类型，可能你会有点懵：实际遇到问题到底该怎么下手？我自己总结了一套排查流程，供你参考。
第一步：确认基础连接
先别急着看SDP，先确认信令通道是否正常。双方能否成功交换信令消息？WebSocket是否保持连接？有没有频繁断线重连？如果信令都不通，后面的步骤都免谈。
第二步：检查SDP内容
把双方的SDP打印出来对照着看。codec是否匹配？IP地址和端口是否正确？media line是否完整？有没有缺少必要的属性？这一步可以排除大部分SDP层面的配置问题。
第三步：查看ICE状态
在浏览器或日志里查看ICE候选收集是否完成，连通性检查进行到哪一步了。ICE有几种状态：Checking、Failed、Success，如果一直停在Checking不动，那很可能是有候选地址不通。如果直接跳到Failed，说明所有候选都尝试过了但没一个能通。
第四步：抓包分析
如果以上步骤都没发现问题，那就得上终极武器——抓包分析。用Wireshark抓包，看SDP交换是否正常，STUN/TURN的交互是否成功，媒体流有没有发出去。抓包虽然麻烦，但能让你看到最真实的数据流向，是定位疑难杂症的最有效手段。
第五步：环境对比
有时候在某个特定网络环境下会出问题，换个网络就好了。这时候可以用不同的网络环境做对比测试，比如手机开热点、换不同的WiFi、或者使用VPN看看能不能复现问题。这样可以帮助你判断是本地网络的问题还是远端的问题。
四、一些避坑经验和心得
说到这儿，我想分享几点自己踩坑后总结的经验。
- 日志一定要打全。SDP、ICE候选、连接状态变化这些关键节点，建议都加上日志。很多问题都是后知后觉，日志全的话回溯起来方便很多。
- 善用官方工具。声网这些专业服务商的开发者控制台一般都有诊断工具，能帮你快速看到连接各阶段的状态和耗时，比自己盲目排查高效得多。
- 先做减法。去掉所有非必要的配置和逻辑，用最简化的Demo复现问题，然后再逐步加功能。这样定位问题的速度更快。
- 保持客户端和服务端版本一致。SDK版本差异有时候也会导致协商不兼容，尤其是大版本升级的时候，记得两边一起升。
媒体协商这个问题，说难不难，但确实需要耐心。它涉及网络、协议、业务逻辑等多个层面，初学者可能会觉得无从下手，但只要掌握了正确的方法论，排查起来还是有章可循的。
我个人觉得，遇到问题不要慌，一步步来。该看日志看日志，该抓包抓包，把大链条拆成小环节，逐一验证，总能找到根因。如果你正在使用类似声网这种专业平台的服务，他们的技术支持团队也完全可以借助平台的诊断能力帮你快速定位问题，没必要一个人死磕。
好了，关于媒体协商失败的排查，今天就聊到这儿。如果你有具体的案例或问题，欢迎在开发者社区里交流讨论。
