从抓包到配置：手把手教你读懂Wireshark里的RTP负载类型（Payload Type）
当你第一次在Wireshark中看到SIP/RTP流量时，那些十六进制报文中的PT字段（比如0x60）可能会让你感到困惑。这篇文章将带你从实际抓包文件出发，一步步理解这些数字背后的含义，并学会如何在实际网络环境中应用这些知识。
1. 初识RTP负载类型：从抓包开始
打开Wireshark捕获的SIP呼叫数据包，你会发现RTP报文头部有一个关键的PT（Payload Type）字段。这个7位的字段决定了媒体流的编码格式，是理解VoIP通话质量的关键。
典型抓包场景分析：
rtp.payload_type == 96这个简单的过滤条件就能帮你找到所有使用96作为负载类型的RTP流。但为什么是96？这个数字代表什么？
在真实环境中，你可能会看到这样的SDP声明：
a=rtpmap:96 H264/90000这行代码揭示了96与H.264视频编码的关联。理解这种关联是排查媒体协商问题的第一步。
2. 负载类型的分类与识别
RTP负载类型分为两大类：
| 类型范围 | 特点 | 常见示例 |
|---|---|---|
| 0-95 | RFC3551定义的静态类型 | 0(PCMU), 8(PCMA), 9(G722) |
| 96-127 | 动态分配类型 | 96(H264), 101(telephone-event) |
静态类型的特点：
- 无需SDP中的rtpmap属性
- 编码参数固定（如PCMU固定为8kHz采样率）
- 跨设备兼容性好
动态类型的注意事项：
- 必须通过SDP的rtpmap明确声明编码格式
- 同一会话中不同编码不能重用相同PT值
- 终端实现可能存在差异（如H264可能用96或98）
3. 实战：从抓包到配置
让我们通过一个实际案例，看看如何将这些知识应用到网络配置中。
场景：两个使用不同PT值的H.264终端无法建立视频通话。
排查步骤：
- 使用Wireshark过滤SDP报文：
sdp contains "H264"- 比较双方的rtpmap声明：
a=rtpmap:96 H264/90000 # 主叫方 a=rtpmap:98 H264/90000 # 被叫方- 在FreeSWITCH的vars.xml中添加映射：
<X-PRE-PROCESS cmd="set" data="global_codec_prefs=H264@96"/>注意：修改PT值可能影响已有设备的兼容性，建议在变更前进行充分测试。
4. 高级技巧与常见问题
动态类型的最佳实践：
- 避免随意使用101（通常保留给telephone-event）
- 为不同分辨率的H.264分配不同PT值（如96=720p，97=480p）
- 在SIP trunk配置中明确声明支持的PT范围
常见问题排查表：
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 单向媒体流 | PT值不匹配 | 统一两端PT值 |
| 视频花屏 | PT值与实际编码不符 | 检查rtpmap声明 |
| 呼叫建立但无媒体 | 防火墙阻止了动态PT范围 | 开放96-127端口范围 |
Wireshark高级过滤技巧：
rtp && rtp.payload_type >= 96 # 只显示动态类型 sdp and sdp.media.attribute contains "rtpmap" # 查找所有编码声明5. 性能优化与监控
理解PT值还能帮助你优化媒体流质量。例如，通过分析不同PT值的RTP流统计信息，可以识别网络中的瓶颈：
# 使用tshark统计各PT值的丢包率 tshark -r capture.pcap -q -z rtp,streams关键指标监控建议：
- 动态类型(96-127)的重新协商频率
- 各PT值的平均端到端延迟
- 特定PT值的抖动变化趋势
在实际运维中，我们经常遇到终端厂商对PT值实现不一致的情况。有一次，某品牌IP电话默认使用97表示G.722，而另一品牌则用97表示iLBC，导致跨品牌呼叫出现媒体协商失败。通过抓包分析PT值差异，最终通过在SBC上配置PT重映射解决了这个问题。
