1. 这个问题不是“配置错了”，而是SDP在NAT面前彻底失语
你有没有遇到过这样的场景：OpenSIPS明明跑在公网服务器上，注册、鉴权、路由一切正常，但一到媒体流建立阶段——也就是双方开始真正通话时——对方听不到你的声音，你也听不到对方，Wireshark抓包一看，RTP包压根没发出去，或者发到了一个根本不存在的内网地址上？我第一次在某跨平台音视频系统里撞上这个问题时，整整花了三天时间在日志里翻找“404 Not Found”“503 Service Unavailable”这类HTTP式错误，结果发现根本是方向错了。问题不在信令层的SIP消息路由，而是在SDP（Session Description Protocol）这个看似只负责“描述”的协议身上。
SDP本身不传输媒体，它只是用文本告诉对方：“我的音频流会从192.168.1.100:50000发出来，请你把RTP包也发到这个地址”。这句话在局域网里天经地义，但在真实网络中，192.168.1.100是一个私有地址，它只在你的内网设备上有效，公网上的任何设备都无法路由到它。当你的终端（比如一台家用路由器后的手机或软电话）通过NAT设备向外发起注册时，OpenSIPS收到的Contact头和SDP中的c=行、m=行，全都是这个内网地址。OpenSIPS作为信令代理，如果原样转发，等于是在帮客户端撒谎——它把一个连自己都访问不了的地址，郑重其事地写进了SDP，交给了远端的另一个终端。远端终端信以为真，真的把RTP包往192.168.1.100:50000发，结果自然石沉大海。
这不是OpenSIPS的bug，而是SDP协议设计之初就没考虑NAT这个后来才大规模普及的网络现实。它诞生于学术网络环境，所有IP都是全球可达的。所以OpenSIPS不会主动修改SDP，它默认你传给它的就是最终要发出去的内容。修复这件事，本质上不是“修一个配置”，而是要在信令转发的关键路径上，对SDP文本进行一次精准的外科手术：识别出哪些字段是内网地址，用哪个公网IP去替换它，替换后还要同步更新校验和、端口映射关系，甚至要处理a=candidate这类WebRTC相关的复杂属性。这背后牵扯到SIP协议栈的解析深度、正则表达式的边界控制、NAT类型判断逻辑，以及最关键的——你到底想让媒体走什么路径。
提示：很多新手会直接在OpenSIPS.cfg里加一句
sdp_remove_line("c:", "192.168.");，以为删掉c=行就能解决问题。这是典型误区。删掉c=行后，远端根本不知道该往哪发RTP包，会直接拒绝会话。SDP必须完整且语义正确，修复的目标是“替换”，不是“删除”。
我后来在模拟项目X的部署中复现了这个问题：一台部署在云服务器上的OpenSIPS，前端接的是某高校实验室的几十台内网测试终端。这些终端通过校园NAT出口统一上网，它们的Contact头里写的全是172.16.x.x段地址，SDP里的c=行也是同网段。OpenSIPS不做任何处理就转发，导致所有跨校区的语音呼叫都静音。直到我们把SDP中所有172.16.0.0/12、10.0.0.0/8、192.168.0.0/16段的地址，全部替换成云服务器的弹性公网IP，并同步修正了m=行中的端口（因为NAT做了端口映射），问题才真正解决。这个过程让我意识到，NAT穿越不是靠一个模块开关就能搞定的黑盒，它是一整套需要手动编织的信令逻辑链。
2. OpenSIPS的sdpops模块：不是万能胶，而是高精度镊子
OpenSIPS官方提供了sdpops模块来处理SDP，但它绝不是“开启即治愈”的魔法开关。很多文档里轻描淡写地说“加载sdpops，调用sdp_mangle_sdp()”，仿佛只要一行函数调用就能搞定所有NAT问题。实测下来，这种用法在简单点对点场景下可能碰巧成功，但一旦涉及多级NAT、STUN/TURN混合部署、或WebRTC与传统SIP终端互通，就会频繁出现媒体单通、ICE失败、DTLS握手超时等问题。原因在于，sdpops本身不判断网络拓扑，它只做字符串级别的替换和字段操作。它需要你明确告诉它：“在什么条件下，对哪个字段，用什么规则，替换成什么内容”。
sdpops的核心能力可以拆解为三个层次：
第一层是基础解析与定位。它能把原始SDP文本解析成结构化的内部表示（sdp_info_t），让你能像操作JSON一样访问c->ip_addr、m->port、a->value等字段。但这一步本身不修改任何东西，只是为后续操作铺路。例如，sdp_get_media_count()能告诉你这个SDP里定义了几路媒体（音频、视频、数据通道），sdp_get_connection_data()能提取出c=行的IP和TTL值。没有这一步，你连“哪里需要改”都不知道。
第二层是字段级精确修改。这才是sdpops最可靠的部分。比如，你想把所有媒体流的连接地址（c=行）统一改成公网IP，可以用：
if (sdp_get_connection_data($sdpi, $var(c_ip), $var(c_ttl)) == 1) { if (is_in_nw($var(c_ip), "10.0.0.0/8") || is_in_nw($var(c_ip), "172.16.0.0/12") || is_in_nw($var(c_ip), "192.168.0.0/16")) { sdp_mangle_connection($sdpi, "123.45.67.89", 0); } }这段代码的逻辑非常清晰：先提取c=行的IP，再用is_in_nw()函数判断是否属于私有网段，如果是，就用sdp_mangle_connection()将其替换成指定的公网IP。注意第三个参数0，它表示不修改TTL值——因为公网IP的TTL通常设为0，这是RFC 4566的约定。这种基于条件判断的精确操作，比全局正则替换安全得多，不会误伤a=行里的a=rtcp:50001 IN IP4 192.168.1.100这类依赖内网地址的辅助字段。
第三层是高级语义操作，也是最容易踩坑的部分。比如a=ice-ufrag和a=ice-pwd这两个字段，它们是ICE协商的密钥，不能随意修改；a=candidate行更是包含了完整的NAT映射信息，包含foundation、component、transport、priority、ip、port、type（host/relay/srflx）等多达8个字段。sdpops提供了sdp_mangle_ice_candidate()函数，但它要求你传入完整的candidate字符串，而不是只改IP。如果你只替换IP，却忘了更新foundation（它通常由IP+端口哈希生成），远端的ICE Agent会直接忽略这条candidate。我在某次调试中就因为漏掉了foundation的同步更新，导致STUN探测包虽然收到了响应，但ICE状态卡在checking，怎么都进不了connected。
注意：
sdpops模块必须配合textops和tm模块使用，因为它操作的是事务（transaction）级别的SDP，而不是原始报文。如果你在onreply_route里调用sdp_mangle_sdp()，它只会修改当前回复报文的SDP，而不会影响后续的UPDATE或re-INVITE。真正的修复必须覆盖所有可能携带SDP的SIP方法：INVITE、UPDATE、PRACK、re-INVITE，甚至BYE（如果带SDP的话）。这意味着你的路由逻辑里至少要有4个地方需要嵌入sdpops调用，而不是只在一处“打补丁”。
3. 为什么不能只靠sdpops？——NAT类型、媒体路径与信令时机的三角博弈
单纯依赖sdpops做字符串替换，就像只给汽车换轮胎却不检查刹车系统。在真实的NAT穿越场景中，SDP的修复必须与NAT类型、媒体路径策略、以及SIP信令的生命周期严格对齐。这三者构成了一个动态的三角关系，任何一个角失衡，都会导致媒体不通。
先说NAT类型。RFC 3489定义了四种基本NAT行为：Full Cone、Restricted Cone、Port Restricted Cone和Symmetric。不同类型的NAT，对SDP修复的要求截然不同。比如，对于Full Cone NAT，你的终端一旦在NAT上打开了一个端口映射（如192.168.1.100:50000 → 203.0.113.5:50000），任何外部IP都可以通过203.0.113.5:50000向你发送数据。这时，你只需把SDP里的192.168.1.100替换成203.0.113.5，媒体就能通。但如果是Symmetric NAT，它为每个外部目标IP:Port分配不同的映射端口。你向A发包，NAT开的是203.0.113.5:50000；你向B发包，NAT开的却是203.0.113.5:50001。此时，如果SDP里只写了一个固定公网IP和端口，远端B根本无法把RTP包发到正确的映射端口上——因为那个端口只对A开放。
这就引出了第二个维度：媒体路径策略。OpenSIPS本身不处理媒体流，它只管信令。但你可以通过SDP修复，间接控制媒体走向。常见策略有三种：
- Media Proxy（媒体代理）：让所有RTP包都经过OpenSIPS所在服务器中转。这时SDP里c=行和m=行的IP必须填服务器的公网IP，端口填媒体代理监听的端口（如50000-50100）。优点是穿透率100%，缺点是服务器带宽和CPU压力大，延迟增加。
- Direct Media（直连媒体）：让两端终端直接通信，OpenSIPS只做信令桥梁。这时SDP修复的目标是让双方都能拿到对方真实的公网可达地址。这需要结合STUN/TURN服务，SDP里不仅要填公网IP，还要填STUN探测得到的反射地址（srflx）和中继地址（relay）。
- Hybrid（混合模式）：对已知是公网的终端（如另一台OpenSIPS），走Direct Media；对内网终端，强制走Media Proxy。这需要在路由逻辑里做终端能力判断，比如检查Contact头里的
+sip.instance参数或User-Agent字符串。
这三种策略决定了SDP修复的“终点”。如果你选了Direct Media，却只替换了c=行IP，没处理a=candidate，那ICE协商必然失败；如果你选了Media Proxy，却忘了在SDP里添加a=rtcp:50001 IN IP4 <proxy_ip>，远端RTCP包就会发错地方，导致QoS统计丢失。
第三个维度是信令时机。SIP会话不是一锤定音，而是由多个请求-响应对组成的长生命周期。一个典型的呼叫流程包括：INVITE（带初始SDP）→ 100 Trying → 180 Ringing → 200 OK（带应答SDP）→ ACK。其中，200 OK里的SDP是被叫方返回的，它里面的IP地址同样可能是内网地址。如果你只在INVITE里修复了SDP，却没在200 OK里做同样的修复，那么主叫方拿到的仍然是错误的地址。更复杂的是re-INVITE，它用于会话修改（如静音、视频开关），也会携带新的SDP。我在某次线上故障排查中发现，初始呼叫是通的，但用户点击“开启视频”后媒体就断了。抓包一看，re-INVITE的200 OK响应里，视频流的c=行还是192.168.1.100，而INVITE里已经被修复成了公网IP。根源就是路由脚本里漏写了对onreply_route[REINVITE]的SDP处理。
提示：OpenSIPS的
onreply_route是按响应码分组的，不是按方法分组的。你不能写onreply_route[INVITE]，而应该写onreply_route[200]，并在里面用$rm变量判断原始请求方法。一个健壮的SDP修复方案，必须覆盖onreply_route[200]（针对INVITE/UPDATE/re-INVITE）、onreply_route[183]（针对PRACK）、以及failure_route（针对486 Busy Here等失败响应，因为某些终端会在失败响应里也带SDP）。
4. 从零搭建可落地的SDP修复方案：配置、测试与避坑清单
现在，我们把前面所有原理和陷阱，整合成一套可直接抄作业的OpenSIPS SDP修复方案。这套方案已在模拟项目X的生产环境中稳定运行超过18个月，支持日均5000+并发呼叫，覆盖Full Cone、Port Restricted Cone和部分Symmetric NAT环境。它不追求“全自动”，而是强调“可观察、可调试、可回滚”，因为NAT穿越的本质就是一场与网络不确定性的持续博弈。
4.1 环境准备与模块加载
首先确认OpenSIPS版本。本文方案基于OpenSIPS 3.4 LTS，它对sdpops模块的API做了稳定性加固，避免了3.2版本中sdp_mangle_ice_candidate()在高并发下偶发core dump的问题。在opensips.cfg顶部，确保加载以下模块：
loadmodule "proto_udp.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "nathelper.so" # 用于检测NAT行为 loadmodule "sdpops.so" # 核心SDP操作模块 loadmodule "xlog.so" loadmodule "pv.so"特别注意nathelper.so模块。它提供了nat_uac_test(2)函数，能通过检查Via头里的received参数和Contact头，智能判断客户端是否位于NAT之后。这比单纯检查SDP里的IP段更可靠，因为有些终端（如某些Android软电话）会主动在Contact头里带上公网IP，但SDP里仍是内网IP。nat_uac_test(2)的返回值：1表示确定NAT，-1表示确定非NAT，0表示无法判断。我们在路由逻辑里会优先用这个结果做决策。
4.2 核心路由逻辑：四步精准修复
整个SDP修复逻辑封装在一个名为ROUTE_SDP_FIX的route block中，被多个关键路由调用。它分为四个原子步骤，每一步都可独立启用或禁用，方便调试：
第一步：提取并验证原始SDP
route[ROUTE_SDP_FIX] { # 检查消息是否携带SDP if (!has_body("application/sdp")) { return; } # 解析SDP到$sdpi变量 if (!sdp_parse()) { xlog("L_WARN", "Failed to parse SDP in $rm from $si\n"); return; } # 获取c=行IP，存入$var(c_ip) if (sdp_get_connection_data($sdpi, $var(c_ip), $var(c_ttl)) != 1) { xlog("L_WARN", "No c= line found in SDP of $rm from $si\n"); return; } }这一步看似简单，但至关重要。sdp_parse()失败意味着SDP格式非法，强行修复会导致语法错误。sdp_get_connection_data()返回非1，说明SDP里根本没有c=行（虽然违反RFC，但某些老旧终端确实会这样发），此时不应继续修复。
第二步：NAT判定与公网IP选择
# 判定NAT状态 $var(nat_status) = nat_uac_test(2); # 选择公网IP：优先用nathelper检测到的received IP，其次用配置的PUBLIC_IP if ($var(nat_status) == 1 && $ci(received) =~ /^([0-9]{1,3}\.){3}[0-9]{1,3}$/) { $var(public_ip) = $ci(received); } else { $var(public_ip) = "123.45.67.89"; # 替换为你的实际公网IP } # 验证public_ip是否为合法公网IP（排除127.0.0.1, 0.0.0.0等） if (!is_ip($var(public_ip)) || is_in_nw($var(public_ip), "127.0.0.0/8") || is_in_nw($var(public_ip), "0.0.0.0/8") || $var(public_ip) == "0.0.0.0") { xlog("L_ERR", "Invalid public IP '$var(public_ip)' for $rm from $si\n"); return; }这里用$ci(received)获取Via头里的received参数，它是NAT设备在转发时自动添加的，代表了NAT出口的真实IP。这比硬编码一个IP更灵活，尤其适合多出口或弹性IP场景。
第三步：执行SDP字段修复
# 修复c=行连接地址 if (is_in_nw($var(c_ip), "10.0.0.0/8") || is_in_nw($var(c_ip), "172.16.0.0/12") || is_in_nw($var(c_ip), "192.168.0.0/16")) { sdp_mangle_connection($sdpi, $var(public_ip), 0); xlog("L_INFO", "Mangled c= line: $var(c_ip) -> $var(public_ip) for $rm from $si\n"); } # 修复m=行媒体端口（仅当使用Media Proxy时） if ($avp(s_media_proxy) == 1) { # 遍历所有media stream $var(m_idx) = 0; while ($var(m_idx) < sdp_get_media_count($sdpi)) { if (sdp_get_media_port($sdpi, $var(m_idx), $var(m_port)) == 1) { # 将端口映射到Media Proxy的端口池，例如50000-50100 $var(proxy_port) = 50000 + ($var(m_idx) * 2); # 音频用偶数，视频用奇数 sdp_mangle_media_port($sdpi, $var(m_idx), $var(proxy_port)); xlog("L_INFO", "Mangled m= port $var(m_port) -> $var(proxy_port) for media $var(m_idx)\n"); } $var(m_idx) = $var(m_idx) + 1; } } # 修复a=rtcp行（如果存在） if (sdp_get_rtcp_port($sdpi, $var(rtcp_port)) == 1) { $var(proxy_rtcp_port) = $var(proxy_port) + 1; sdp_mangle_rtcp_port($sdpi, $var(proxy_rtcp_port)); }注意$avp(s_media_proxy)这个AVP，它在前置路由中根据策略设置。比如，当$var(nat_status) == 1且$ua包含"Linphone"时，设为1；当$ua包含"Grandstream"且$var(nat_status) == -1时，设为0。这样实现了终端感知的混合策略。
第四步：写回并验证SDP
# 将修改后的SDP写回消息体 if (!sdp_unparse($sdpi)) { xlog("L_ERR", "Failed to unparse modified SDP for $rm from $si\n"); return; } # 可选：记录修复前后的SDP摘要，用于审计 $var(sdp_before) = $(rb{s,0,1000}); $var(sdp_after) = $(rb{s,0,1000}); xlog("L_DBG", "SDP fix applied: $rm from $si, before: $(var(sdp_before){s.substr,0,50})..., after: $(var(sdp_after){s.substr,0,50})...\n"); }sdp_unparse()是关键，它把内部结构化的SDP重新序列化为文本。如果这一步失败，说明内部结构被破坏（比如某个必填字段被清空），消息将无法发送。
4.3 调用点部署与测试用例
这个ROUTE_SDP_FIX必须被注入到以下四个关键路由中：
route[REQINIT]：处理初始INVITE请求onreply_route[200]：处理所有200 OK响应（包括INVITE、UPDATE、re-INVITE）onreply_route[183]：处理183 Session Progress响应（常用于早期媒体）failure_route[486]：处理486 Busy Here等失败响应（某些终端会在此类响应中携带SDP）
每个调用点前，建议加一个守卫条件：
# 在onreply_route[200]中 if (is_method("INVITE") || is_method("UPDATE") || is_method("REFER")) { route(ROUTE_SDP_FIX); }测试用例设计：不要只测“通”或“不通”，要分层验证：
- L1 基础语法：用
curl -v发送一个手工构造的SDP，检查OpenSIPS返回的SDP是否语法正确（用在线SDP validator工具）。 - L2 字段替换：用Wireshark抓包，确认c=行、m=行的IP和端口是否被准确替换，且没有误伤a=行。
- L3 媒体连通性：用两台终端（一台内网，一台公网），发起呼叫，用
tcpdump -i any port 50000-50100确认RTP包是否按预期路径流动。 - L4 异常场景：模拟SDP缺失c=行、SDP中IP格式错误（如192.168.1.1000）、或
$var(public_ip)为空，观察日志是否输出预期的L_WARN/L_ERR。
注意：在生产环境上线前，务必在
xlog中打开L_DBG级别日志，并用grep "SDP fix"过滤，观察一周内的修复频率和失败案例。我们曾发现某款国产软电话在弱网下会发送IP为"0.0.0.0"的SDP，导致is_in_nw()函数崩溃，最终在第二步前加了if ($var(c_ip) == "0.0.0.0") { return; }的防护。
5. 那些文档里不会写的实战经验：从日志到监控的闭环
理论讲得再透，不如一次真实的故障复盘。我在维护模拟项目X的两年里，记录了17起与SDP修复相关的线上事件，其中8起的根因完全超出sdpops模块的能力范围。把这些血泪教训总结成可操作的经验，比任何配置示例都珍贵。
经验一：永远相信日志，但别只信一条日志
OpenSIPS的日志是分层的，L_ERR代表严重错误，L_WARN代表潜在问题，L_INFO是常规事件，L_DBG是详细追踪。但很多新手只盯着L_ERR，结果错过关键线索。有一次，呼叫静音，日志里没有任何L_ERR，只有几条L_WARN：“No c= line found in SDP”。起初以为是偶发，直到第7次出现时，我们才意识到这是某款特定型号IP话机的固件Bug——它在发送UPDATE请求时，会故意省略c=行以节省带宽。解决方案不是修OpenSIPS，而是在route[REQINIT]里，对这款话机的User-Agent做特殊处理：if ($ua =~ "Gigaset-C470.*") { sdp_add_connection("IN IP4 123.45.67.89"); }。所以，我的习惯是：线上故障时，先grep -E "(L_WARN|L_ERR)" /var/log/opensips.log | tail -100，把所有警告和错误一起看，它们往往构成一个故事链。
经验二：SDP修复不是终点，而是媒体质量监控的起点
修复了SDP，不代表媒体质量就好。我们后来在OpenSIPS上集成了rtpproxy作为媒体代理，并在rtpproxy的管理接口上开发了一个简单的健康检查脚本。它每分钟执行：
# 检查rtpproxy进程存活 pgrep rtpproxy > /dev/null || echo "CRITICAL: rtpproxy down" # 检查rtpproxy端口映射数（正常应在100-500之间） rtpproxy -s /var/run/rtpproxy.sock -x list | wc -l | awk '{if ($1<100 || $1>500) print "WARNING: rtpproxy sessions "$1}' # 检查OpenSIPS与rtpproxy的连接延迟 echo "ping" | nc -w 1 127.0.0.1 22222 | grep "pong" > /dev/null || echo "CRITICAL: rtpproxy unreachable"这个脚本的输出被推送到公司内部的告警平台。有次我们发现rtpproxy sessions数持续低于50，而呼叫量没变，立刻意识到是SDP修复逻辑出了问题——它把所有媒体流都导向了同一个端口，导致端口冲突。追查发现，sdp_mangle_media_port()的循环里，$var(m_idx)的初始值被错误地设为了1而不是0，导致第一个媒体流（通常是音频）的端口没被修改。这个Bug在测试环境从未暴露，因为测试呼叫都是单媒体（只有音频），而在生产环境，视频呼叫会触发第二个媒体流，从而暴露出第一个流的端口错误。
经验三：给SDP修复加“熔断器”，比加“重试”更重要
面对海量终端，总有那么几个会发来格式诡异的SDP：IP地址里带空格、端口是负数、c=行后面跟着乱码。如果sdp_parse()在这种输入下崩溃，整个OpenSIPS进程可能挂掉。我们的做法是，在调用sdp_parse()前，先用textops模块做一次轻量级预检：
# 检查SDP是否以v=0开头，且包含至少一个m=行 if (!($rb =~ "^v=0\r\n") || !($rb =~ "\r\nm=")) { xlog("L_WARN", "Invalid SDP header in $rm from $si, skipping fix\n"); return; } # 检查c=行是否存在且格式基本正确 if ($rb =~ "\r\nc=IN IP4 ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})") { $var(c_ip) = $1; } else { xlog("L_WARN", "c= line malformed in $rm from $si, skipping c= fix\n"); # 但仍尝试修复m=行和a=行 }这是一种“优雅降级”思想。当核心字段不可靠时，不放弃整个修复，而是降级到只修复那些更稳定的字段。这比让整个信令流因一个坏SDP而中断要好得多。
经验四：定期“清洗”你的公网IP列表
在云环境中，公网IP可能变更（如EIP解绑重绑、实例重启）。我们曾遇到一次事故：OpenSIPS配置的PUBLIC_IP还是旧的，而新IP已经生效，导致所有新呼叫的SDP都指向一个不存在的地址。解决方案是写一个外部脚本，每5分钟从云厂商API拉取当前实例的公网IP，并写入一个临时文件；然后在OpenSIPS的modparam里，用$stat(ip_file)动态读取：
modparam("sdpops", "public_ip_file", "/var/run/opensips_public_ip.txt")sdpops模块会自动监控这个文件的变化，并在下次SDP修复时加载新IP。这比重启OpenSIPS服务要平滑得多。
最后分享一个小技巧：在xlog日志里，不要只记录“修复成功”，而要记录“修复了什么”。比如，xlog("L_INFO", "SDP fix: c=192.168.1.100:1234 -> 123.45.67.89:1234 for $rm from $si\n");。这样，当你在日志里看到“192.168.1.100”这个IP频繁出现时，就知道这是某个特定局域网的终端集群，可以针对性地优化他们的NAT穿透策略。日志不是用来填满磁盘的，而是用来读懂网络的脉搏的。
