day7 – Symmetric RTP 对称RTP – Lasvas

引言

在前面的章节中，我们学习了RTP媒体传输的基本原理，了解到媒体服务器应该根据SDP信令中的c字段来确定媒体流的发送地址。但在实际的生产环境中，特别是涉及NAT穿越的场景下，我们会发现一个有趣的现象：媒体服务器并不总是严格按照SDP中的地址发送媒体流。

今天我们来深入学习一个重要的概念：Symmetric RTP（对称RTP）。

1. 什么是Symmetric RTP

Symmetric RTP是一种智能的媒体传输策略。与传统RTP严格遵循SDP信令不同，Symmetric RTP会”学习”实际收到的RTP包的源地址，并将该地址作为回送媒体流的目标地址。

简单来说：我从哪里收到你的媒体，就往哪里给你发媒体。

2. 实际案例观察

让我们通过一个真实的呼叫流程来理解这个概念。

2.1 完整信令分析

以下是一个实际的INVITE消息：

CALLFLOW|2025-07-28 11:26:22.720|EP1->SERVER|223.244.80.64:5080|INVITE|47.93.160.101:5060

INVITE sip:13856917046@47.93.160.101:5060 SIP/2.0
Via: SIP/2.0/UDP 10.216.109.110:5080;rport;branch=z9hG4bKUU44c7Q8Q5v7g
Max-Forwards: 70
From: "" <sip:72613@10.216.109.110>;tag=KetZBUH98X28a
To: <sip:13856917046@47.93.160.101:5060>
Call-ID: 79f2115b-e605-123e-2da9-f0d4e2eb0884
CSeq: 102282799 INVITE
Contact: <sip:mod_sofia@10.216.109.110:5080>
User-Agent: FreeSWITCH-mod_sofia/1.4.26~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 251
X-FS-Support: update_display,send_info
Remote-Party-ID: <sip:72613@10.216.109.110>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1753645828 1753645829 IN IP4 10.216.109.110
s=FreeSWITCH
c=IN IP4 10.216.109.110
t=0 0
m=audio 27354 RTP/AVP 8 0 101 13
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

2.2 关键信息提取

从这个INVITE消息中，我们可以提取到以下关键信息：

1. 信令层面的地址信息：

Via头中的地址：10.216.109.110:5080
Contact头中的地址：10.216.109.110:5080
SDP中的媒体地址：c=IN IP4 10.216.109.110
媒体端口：m=audio 27354

2. 网络层面的实际地址：

CALLFLOW显示的实际源地址：223.244.80.64:5080

3. 媒体流的实际情况：

SDP指定的媒体接收地址：10.216.109.110:27354
实际媒体流发送地址：223.244.80.64:27354

3. 传统RTP vs Symmetric RTP

3.1 传统RTP的行为

按照RFC规范，媒体服务器应该严格按照SDP中的c字段发送媒体：

接收到SDP: c=IN IP4 10.216.109.110
媒体端口: m=audio 27354
发送目标: 10.216.109.110:27354  ← 严格按照SDP

3.2 Symmetric RTP的行为

而在Symmetric RTP模式下：

1. 接收第一个RTP包，源地址为: 223.244.80.64:27354
2. 学习并记录真实地址: 223.244.80.64:27354
3. 向学习到的地址发送媒体: 223.244.80.64:27354  ← 忽略SDP

4. 为什么会出现地址不一致

4.1 NAT环境分析

从我们的案例可以看出典型的NAT场景：

[客户端] --NAT--> [互联网] ---> [服务器]
内网IP:          公网IP:       服务器IP:
10.216.109.110   223.244.80.64  47.93.160.101

地址转换过程：

客户端在内网，真实IP为10.216.109.110
经过NAT设备，外网看到的IP变为223.244.80.64
SDP中仍然携带内网IP10.216.109.110
但实际的UDP包源地址是223.244.80.64

4.2 信令与媒体的分离

这里涉及到一个重要概念：信令路径与媒体路径可能不同

信令路径: 可能经过SIP ALG（应用层网关）处理
媒体路径: 通常是点对点的UDP传输，更容易受NAT影响

5. Symmetric RTP的工作机制

5.1 学习过程

步骤1: A服务器发送INVITE给B服务器
       SDP: c=IN IP4 10.216.109.110
            m=audio 27354

步骤2: B服务器收到INVITE，解析SDP
       初始目标: 10.216.109.110:27354

步骤3: B服务器开启媒体转发，等待A的RTP包

情况A - A服务器发送了RTP包：
步骤4a: A发送RTP包，源地址: 223.244.80.64:27354
步骤5a: B学习到真实地址: 223.244.80.64:27354
步骤6a: B向A发送媒体: 223.244.80.64:27354 ← 使用学习地址

情况B - A服务器没有发送RTP包：
步骤4b: A没有发送RTP包
步骤5b: B没有学习到地址
步骤6b: B向A发送媒体: 10.216.109.110:27354 ← 使用SDP地址

5.2 状态转换图

B服务器的媒体发送状态：

[初始状态] ──收到INVITE──> [SDP解析完成]
     │                           │
     │                           │使用SDP地址发送
     │                           ↓
     │                    [等待RTP包状态]
     │                           │
     │                           │收到A的RTP包
     │                           ↓
     └────────────────────> [地址学习完成]
                                 │
                                 │使用学习地址发送
                                 ↓
                           [Symmetric模式]

6. 深入理解

6.1 端口不一致的场景

假设我们遇到这样的情况：

SDP中指定的媒体端口: m=audio 12345 RTP/AVP 8 0 101
实际发送RTP的端口: 223.244.80.64:1245

这种情况在实际环境中确实可能发生，特别是在复杂的NAT环境或某些特殊的网络设备配置下。

此时，Symmetric RTP会如何处理

答案是：Symmetric RTP依然会生效，媒体流会回发到实际的RTP源地址

让我们看看具体的处理过程：

初始状态：
- SDP指定地址: 10.216.109.110:12345
- 服务器准备发送到: 10.216.109.110:12345

实际RTP包到达：
- 源地址: 223.244.80.64:1245  ← 注意端口是1245，不是12345
- Symmetric RTP学习: 223.244.80.64:1245

最终发送目标：
- 媒体流发送到: 223.244.80.64:1245  ← 完全按照实际源地址

6.2 主叫没有发送rtp

假设我们遇到这样的情况：

SDP中指定的媒体端口: m=audio 12345 RTP/AVP 8 0 101
SDP中IP为内网IP: c=IN IP4 192.168.10.1

此时，Symmetric RTP是会给c字段的内网IP发包，还是给sip信令的源地址，公网地址发包

答案是：Symmetric RTP会发送到sdp中的c字段地址

7. Symmetric RTP的优势

7.1 自动NAT穿越

无需配置: 自动适应各种NAT环境
高成功率: 大大提高媒体连通率
透明处理: 对应用层透明

7.2 网络兼容性

企业网络: 适应复杂的企业防火墙环境
家庭网络: 兼容各种家用路由器
移动网络: 适应运营商的NAT策略

8. 注意事项与最佳实践

8.1 安全考虑

潜在风险：

RTP劫持：恶意发送RTP包可能劫持媒体流
地址欺骗：需要结合其他安全机制

防护措施：

启用SRTP加密
结合SIP认证
限制RTP端口范围

8.2 网络环境要求

单向NAT: Symmetric RTP能很好解决
双向NAT: 可能需要STUN/TURN辅助
对称NAT: 需要特殊处理

9. 调试与排错

9.1 常见问题

问题1: 单向语音

现象：只能听到对方声音，对方听不到
原因：没有启用Symmetric RTP
解决：检查配置，启用对称RTP

问题2: 媒体延迟

现象：第一句话听不到
原因：等待第一个RTP包学习地址
解决：优化学习算法，快速切换

9.2 调试命令

1. FreeSWITCH调试
fs_cli -x "sofia status profile internal"
fs_cli -x "show channels"

1. 抓包分析
tcpdump -i any -n port 27354

10. 总结

Symmetric RTP是现代VoIP系统中的重要技术，它通过智能学习真实的媒体源地址，解决了NAT环境下的媒体传输问题。

核心要点：

不依赖SDP: 根据实际RTP包学习地址
自动适应: 无需手动配置NAT穿越
广泛应用: 现代SIP服务器的标准功能
注意安全: 需要结合其他安全机制

通过我们分析的实际案例，你可以看到即使SDP中指定的是内网地址10.216.109.110:27354，服务器最终还是会向公网地址223.244.80.64:27354发送媒体流。这正是Symmetric RTP在发挥作用，确保媒体能够正确到达真实的网络地址。

参照文档：https://rfc2cn.com/rfc4961.html

引言