WVP-GB28181平台设备注册成功但无法推流，常见原因有哪些？

Question

WVP-GB28181平台设备注册成功但无法推流，常见原因包括：① **网络NAT/防火墙阻断**——设备虽能向平台发送REGISTER（走UDP 5060），但平台无法反向通过28181协议建立媒体通道（需UDP 9000–65535端口双向开放）；② **设备配置错误**——未启用“主动推流”或SIP信令中Contact头携带的IP/端口为私网地址，导致WVP无法正确构造INVITE的SDP媒体地址；③ **WVP媒体代理配置缺失**——未启用`media_server`或`rtp_proxy`，且设备不支持直连时，RTP流无法中继；④ **时间不同步或认证失败**——虽注册成功，但后续INFO/MESSAGE保活或流请求因时间戳超差被WVP拒绝；⑤ **设备固件兼容性问题**——部分厂商对RFC3261扩展支持不全，导致SDP协商失败。建议优先抓包分析INVITE/200 OK/ACK全流程及RTP是否发出。

Answer 1

```html

一、现象层诊断：注册成功但无媒体流（表象归因）

设备在WVP平台显示“在线”且SIP状态为REGISTER 200 OK，但流列表为空、预览黑屏、无RTP包到达。此阶段仅确认信令通路建立，不反映媒体面连通性。需区分“信令可达”与“媒体可达”两个正交维度。

二、网络层根因分析：NAT/防火墙双向阻断（关键瓶颈）

• REGISTER走UDP 5060单向可达（设备→平台），但平台发起INVITE后，设备需从SDP a=connection:local或Contact头中解析目标IP:Port（常为WVP公网IP+随机端口）回传RTP
• 若设备位于多级NAT后（如企业内网→运营商CGNAT），其Contact头携带192.168.1.100:5060，WVP将错误地向该私网地址发INVITE，导致媒体协商失败
• 验证方法：tcpdump -i any udp portrange 9000-65535 -w nat_debug.pcap 在WVP服务器抓包，观察是否有来自设备的UDP包进入；同时检查iptables/nftables是否DROP了非5060端口的UDP入向流量

三、设备侧配置深挖：主动推流开关与SIP头污染

配置项	合规值	典型错误	影响
GB28181推流模式	启用“主动注册后自动推流”	仅支持“平台点播触发”且未手动发起INVITE	设备静默，无RTP发送
Contact头IP	公网IP或经STUN获取的映射地址	硬编码为10.x.x.x/172.16.x.x/192.168.x.x	WVP构造INVITE时填入无效SDP c=行，媒体地址不可达

四、WVP服务架构级缺陷：媒体代理未就绪

当设备不支持被动打洞（如无RFC5766 TURN能力）且无法直连WVP时，必须启用中继：

# application.yml 关键配置
media-server:
  enable: true
  rtp-proxy:
    enable: true
    port-range: "9000-9100"  # 严格限制端口池，避免防火墙全开风险

若rtp-proxy.enable=false且设备NAT类型为Symmetric，WVP虽收INVITE但无法向设备RTP端口发包，RTP流必然丢失。

五、协议栈兼容性攻坚：RFC3261扩展与SDP协商陷阱

graph LR
  A[设备发送INVITE] --> B{WVP解析SDP}
  B --> C[检查a=rtcp-mux, a=setup:actpass]
  C --> D[若设备缺失a=fingerprint或证书不匹配]
  D --> E[拒绝200 OK，日志报“DTLS setup failed”]
  C --> F[若a=rtpmap未声明payload type 96-127]
  F --> G[忽略video track，仅建立audio通道]

六、时间域隐性故障：NTP漂移引发的鉴权熔断

• GB/T 28181-2016要求SIP消息Timestamp头与服务端时钟偏差≤3s，否则WVP拒绝INFO保活及流控制请求
• 执行ntpq -p确认WVP服务器NTP同步状态；设备端需校准至同一NTP源（如cn.pool.ntp.org），误差＞5s将导致401 Unauthorized响应
• 抓包过滤：sip.Timestamp and sip.Response.code == 401

七、全链路抓包诊断法：INVITE→200 OK→ACK→RTP四段式验证

1. 在WVP服务器执行：tcpdump -i eth0 -s 0 -w gb28181_full.pcap port 5060 or portrange 9000-65535
2. 过滤关键事件：filter: sip.Method == "INVITE" || sip.Status-Line contains "200 OK" || sip.Method == "ACK" || udp.dstport >= 9000
3. Wireshark中使用Telephony → SIP → Flow Graph查看信令时序完整性
4. 右键RTP流 → Decode As → RTP → 检查SSRC、Packet loss、Jitter Buffer

八、厂商固件适配清单（实战经验沉淀）

以下设备需特殊配置方可稳定推流：

• 海康DS-2CD3T47G2-LU：需关闭“SIP over TCP”，强制UDP；开启“NAT穿越→STUN”并填写WVP公网IP
• 大华IPC-HFW5849T-ZE：固件v3.820以上才支持a=rtcp-rsize，旧版需在WVP中media_server.sdp_modification = false
• 宇视UIV-IPC632ER3-IZS：必须在设备Web界面禁用“SIP ALG”，否则路由器篡改Contact头

九、自动化巡检脚本（Shell+Python混合）

#!/bin/bash
# 检查WVP媒体端口监听状态
ss -tuln | grep ':9000\|:9001' &>/dev/null || echo "[ERROR] rtp-proxy not listening"
# 验证NTP偏移
ntpdate -q cn.pool.ntp.org | awk '{print $NF}' | grep -E '^[0-9.]+sec$' | awk '{if($1>3) print "[ALERT] NTP skew >3s"}'
# 调用Python解析WVP日志中的SDP异常
python3 -c "
import re
with open('/opt/wvp/logs/wvp.log') as f:
  for line in f:
    if re.search(r'SDP.*invalid|no video track', line):
      print('[CRITICAL]', line.strip())
"

十、生产环境黄金配置模板（兼顾安全与兼容）

在application.yml中强制约定：

sip:
  transport: udp
  auto-answer: true
  nat-type: stun  # 强制设备通过STUN发现公网地址
media-server:
  enable: true
  rtp-proxy:
    enable: true
    port-range: "9000-9099"
    timeout: 60000
  sdp-modification: true  # 自动修正私网c=行和a=connection
time:
  ntp-server: "cn.pool.ntp.org"
  max-skew-ms: 2500  # 严格限制时间偏差阈值

```