1. GB28181点播流程中的INVITE消息解析
在GB28181视频监控系统的点播流程中，SIP协议的INVITE消息扮演着关键角色。作为信令交互的起点，这条消息的质量直接决定了后续媒体流传输的成败。我在实际项目对接中发现，许多开发者容易在INVITE消息构造环节出现细节性失误，导致设备与平台对接失败。
1.1 INVITE消息的核心作用
INVITE消息本质上是一个会话建立请求，它通过SDP（会话描述协议）携带媒体协商参数。在GB28181标准中，这条消息需要完成三个关键任务：
- 指定传输协议（通常为RTP over UDP）
- 声明媒体接收端口（媒体服务器开放的UDP端口）
- 确定负载类型（如PS封装格式）
典型的问题场景包括：NVR设备拒绝响应点播请求、媒体流端口无法连通、视频编码格式不匹配等，这些问题80%都可以追溯到INVITE消息构造不当。
2. INVITE消息的关键构造要点
2.1 SDP媒体描述规范
SDP部分必须严格遵循GB/T 28181-2016附录B的要求。以下是必须包含的字段示例：
code复制v=0
o=34020000002000000001 0 0 IN IP4 192.168.1.100
s=Play
c=IN IP4 192.168.1.100
t=0 0
m=video 6000 RTP/AVP 96
a=recvonly
a=rtpmap:96 PS/90000
a=setup:passive
特别注意：
o=字段中的用户名必须使用20位国标ID（如34020000002000000001）m=行必须明确媒体类型（video/audio）、端口号和传输协议- PS封装必须标注为96负载类型（GB28181强制要求）
2.2 100rel扩展支持
GB28181-2016明确要求支持RFC3262定义的可靠临时响应（100rel）。这意味着：
- INVITE消息头必须包含：
code复制Require: 100rel Supported: 100rel - 对于初始INVITE，设备应当返回183 Session Progress响应
- 平台需处理PRACK消息以确认临时响应
实际对接宇视NVR时，如果缺失100rel扩展声明，设备可能直接返回488 Not Acceptable错误。
3. 典型问题排查指南
3.1 端口协商失败
当Wireshark抓包显示INVITE的200 OK响应正常但无媒体流时，检查：
- SDP中的
c=和m=行IP地址是否可达 - 防火墙是否放行指定UDP端口（建议6000-8000范围）
- 媒体服务器是否真正监听该端口（netstat -anu验证）
3.2 编码格式不匹配
设备返回488错误时，通常因为：
- SDP中声明的负载类型非96（PS封装）
- 缺失
a=rtpmap:96 PS/90000属性 - 错误使用H.264等非标封装格式
3.3 级联场景特殊处理
在跨平台级联时需注意：
- 主平台INVITE的
o=字段需保持原始设备ID - 媒体端口需要做NAT穿透或端口映射
- 级联平台需在Via头中添加自有路由信息
4. 实战优化建议
-
调试工具链配置：
- 使用SIPp工具模拟INVITE流程
- Wireshark过滤器：
sip.Method == "INVITE" || sdp
-
容错机制设计：
python复制# Python示例：构造带重试机制的INVITE def send_invite(target, max_retry=3): for i in range(max_retry): response = sip_send(invite_msg) if response.status_code == 100: return handle_183(response) elif response.status_code == 488: adjust_sdp_format() # 自动调整编码格式 raise Exception("INVITE failed after retries") -
性能优化点：
- 预生成SDP模板减少构造耗时
- UDP端口池化管理避免频繁开关
- 开启TCP备用通道（需设备支持）
在ZLMediaKit等开源媒体服务器实践中，我们发现合理设置a=setup:passive属性可以显著提升NAT穿透成功率。同时建议在首次INVITE失败后，间隔2秒再发起第二次尝试，避免被设备误判为攻击。