GB28181实战（三）——语音对讲与广播的SDP协商与RTP流处理

1. GB28181语音对讲与广播的核心技术解析

GB28181标准作为视频监控领域的通用协议，其语音对讲和广播功能在实际项目中应用广泛。很多刚接触这个协议的开发者容易把两者混淆，其实从技术实现角度来看，它们最核心的区别就在于媒体流方向的控制。对讲是双向通信，就像两个人打电话；而广播是单向传输，更像电台播音。

我经历过一个智慧园区项目，需要同时实现监控中心的语音喊话和对讲功能。当时团队花了三天时间排查一个音频卡顿问题，最后发现是SDP协商时弄混了sendrecv和sendonly参数。这个教训让我深刻理解到，吃透协议细节才能避免踩坑。

先看对讲功能的本质：它需要建立双向RTP流通道。设备端和客户端都能同时发送和接收音频数据，这种模式在SDP中表现为a=sendrecv属性。而广播功能则是典型的单向流传输，设备端作为接收方时用a=recvonly，作为发送方时用a=sendonly。这种设计差异直接影响后续的RTP包处理逻辑。

2. SDP协商的关键字段解剖

2.1 媒体类型与传输参数

在抓包分析中，SDP的m=行藏着不少玄机。以典型对讲请求为例：

sdp复制m=audio 38000 RTP/AVP 8
a=sendrecv
a=rtpmap:8 PCMA/8000

这段配置透露了三个重要信息：

1. 媒体类型：audio表示音频流，区别于video视频流
2. 传输端口：38000是RTP接收端口，实际项目中发现某些NAT环境需要特殊处理这个端口
3. 负载类型：数字8对应PCMA编码，这是GB28181规定的强制支持的编码格式

我曾遇到海康设备返回m=audio 9712 RTP/AVP 8 96的情况，其中96表示PS封装。这时候客户端需要明确自己是否支持多负载类型，否则可能引发兼容性问题。

2.2 方向控制属性实战

广播场景下的SDP差异非常典型。设备发起广播请求时：

sdp复制m=audio 9712 RTP/AVP 8
a=recvonly

而客户端响应时：

sdp复制m=audio 40000 RTP/AVP 8 
a=sendonly

这种镜像对称的参数设计确保了流方向的正确性。在代码实现时，我建议用枚举值明确这三种状态：

cpp复制enum StreamDirection {
    SENDONLY,
    RECVONLY,
    SENDRECV
};

3. RTP流处理的技术细节

3.1 封包与解包实战

PCMA音频的RTP打包有讲究。每个RTP包的payload部分就是原始的PCMA帧，不需要额外封装头。但要注意时间戳的计算：

python复制# 示例：8000Hz采样率下，每20ms一包的时间戳增量
timestamp_increment = 8000 * 0.02  # 等于160

在接收端处理时，我曾踩过一个坑：某些设备会发送带Mark位的包（RTP头中M标志位为1），这通常表示语音段的开始。如果不正确处理，会导致播放器出现"咔嗒"声。

3.2 抖动缓冲区的实现

实时语音对讲最怕的就是抖动。我的经验是采用动态缓冲区：

1. 初始缓冲设为100ms
2. 根据网络状况动态调整（50-200ms范围）
3. 使用线性预测算法补偿丢包

这里有个实用技巧：通过RTP序列号的连续性检测网络状况。连续丢包超过3个就该触发补偿机制了。

4. 典型问题排查指南

4.1 无声问题定位步骤

当遇到语音不通时，建议按这个顺序排查：

1. 信令层面：确认INVITE的SDP是否正确交互

   • 检查200 OK响应中的媒体端口是否与INVITE一致
   • 验证SDP中的编解码类型是否匹配

2. 传输层面：

   • 用Wireshark过滤RTP流，确认是否有数据包到达
   • 检查防火墙是否放行了协商的端口

3. 解码层面：

   • 抓取RTP payload数据用ffplay测试

   bash复制ffplay -f alaw -ar 8000 -ac 1 rtp_payload.pcm
   

4.2 延迟优化方案

在某个银行项目中，我们通过以下措施将端到端延迟从500ms降到200ms内：

• 启用RTP头扩展中的传输时间戳
• 采用TMMBR/TMMBN进行带宽自适应
• 优化jitter buffer算法

特别提醒：GB28181-2016版新增的TCP传输模式对语音业务反而不利，除非网络环境特别差，否则建议坚持用UDP。

5. 代码实现关键点

5.1 SDP构造示例

这是我在实际项目中使用的SDP生成函数改良版：

cpp复制std::string generateSDP(const std::string& ip, uint16_t port, 
                       StreamDirection dir, bool isBroadcast) {
    std::ostringstream oss;
    oss << "v=0\r\n"
        << "o=- 0 0 IN IP4 " << ip << "\r\n"
        << "s=" << (isBroadcast ? "Broadcast" : "Talk") << "\r\n"
        << "c=IN IP4 " << ip << "\r\n"
        << "t=0 0\r\n"
        << "m=audio " << port << " RTP/AVP 8\r\n"
        << "a=";
    
    switch(dir) {
        case SENDONLY: oss << "sendonly"; break;
        case RECVONLY: oss << "recvonly"; break;
        case SENDRECV: oss << "sendrecv"; break;
    }
    
    oss << "\r\n"
        << "a=rtpmap:8 PCMA/8000\r\n"
        << "y=" << generateSSRC() << "\r\n";
    
    return oss.str();
}

5.2 RTP会话管理

建议采用状态机模式管理会话生命周期：

mermaid复制stateDiagram
    [*] --> IDLE
    IDLE --> INVITE_SENT: 发送INVITE
    INVITE_SENT --> ESTABLISHED: 收到200 OK
    ESTABLISHED --> TEARDOWN: 收到BYE
    TEARDOWN --> [*]

实际编码时要注意：收到BYE请求后必须立即停止RTP收发，但要继续处理可能滞留在网络中的包。