青柠视频云——记一次大华摄像头公网语音对讲失败的问题分析

今天有客户反馈,使用大华摄像头接入青柠视频云,在公网环境下无法进行语音对讲,用户的设备是支持语音对讲的。

这是用户提供的注册截图,看起来也没什么问题,而且用户摄像头带有拾音功能和外放喇叭。

于是我们联系客户开始进行现场的抓包分析,因为语音对讲是分两个阶段走,一个是信令服务器和摄像头进行SIP信令交互,另一个是通信成功后,流媒体就开始给设备发RTP包,因此我们两边都进行抓包处理。

先来看信令服务器端的抓包内容,以下信令服务器IP部分做了处理。

复制代码
INVITE sip:34020000001370000001@1.204.105.252:21052 SIP/2.0
Call-ID: 53b587a7746e3af62a4792409145055b@0.0.0.0
CSeq: 15 INVITE
From: <sip:52000010102330000001@5200001010>;tag=1726656234184
To: <sip:34020000001370000001@1.204.105.252:21052>
Via: SIP/2.0/UDP xx.xxx.xxx.x:15060;rport
Max-Forwards: 70
Contact: <sip:52000010102330000001@xx.xxx.xxx.x:15060>
Subject: 34020000001370000001:0000109373,52000010102330000001:0
Content-Type: APPLICATION/SDP
User-Agent: LimeGBS v11111
Content-Length: 181

v=0
o=34020000001370000001 0 0 IN IP4 xx.xxx.xxx.x
s=Talk
c=IN IP4 xx.xxx.xxx.x
t=0 0
m=audio 30857 RTP/AVP 8
a=sendrecv
a=rtpmap:8 PCMA/8000
y=0000109373
f=v/a/1/8/1

SIP/2.0 100 Trying
Via: SIP/2.0/UDP xx.xxx.xxx.x:15060;rport=15060;branch=z9hG4bK-323833-f7c57fec761a4b9b5340a856dfddb41a
From: <sip:52000010102330000001@5200001010>;tag=1726656234184
To: <sip:34020000001370000001@1.204.105.252:21052>
Call-ID: 53b587a7746e3af62a4792409145055b@0.0.0.0
CSeq: 15 INVITE
User-Agent: SIP UAS V2.1.4.500306
Content-Length: 0

SIP/2.0 101 Dialog Establishement
Via: SIP/2.0/UDP xx.xxx.xxx.x:15060;rport=15060;branch=z9hG4bK-323833-f7c57fec761a4b9b5340a856dfddb41a
From: <sip:52000010102330000001@5200001010>;tag=1726656234184
To: <sip:34020000001370000001@1.204.105.252:21052>;tag=1097555858
Call-ID: 53b587a7746e3af62a4792409145055b@0.0.0.0
CSeq: 15 INVITE
Contact: <sip:34020000001370000001@1.204.105.252:21052>
User-Agent: SIP UAS V2.1.4.500306
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP xx.xxx.xx.x:15060;rport=15060;branch=z9hG4bK-323833-f7c57fec761a4b9b5340a856dfddb41a
From: <sip:52000010102330000001@5200001010>;tag=1726656234184
To: <sip:34020000001370000001@1.204.105.252:21052>;tag=1097555858
Call-ID: 53b587a7746e3af62a4792409145055b@0.0.0.0
CSeq: 15 INVITE
Contact: <sip:34020000001370000001@1.204.105.252:21052>
User-Agent: SIP UAS V2.1.4.500306
Content-Type: application/sdp
Content-Length: 266

v=0
o=52000010101320100006 0 0 IN IP4 192.168.1.7
s=Talk
i=VCam Talk Session
c=IN IP4 192.168.1.7
t=0 0
m=audio 9712 RTP/AVP 8
a=recvonly
a=rtpmap:8 PCMA/8000/1
m=audio 9712 RTP/AVP 8
a=sendonly
a=rtpmap:8 PCMA/8000/1
y=0000109373
f=v/0/0/0/0/0a/0/0/0

ACK sip:34020000001370000001@1.204.105.252:21052 SIP/2.0
Call-ID: 53b587a7746e3af62a4792409145055b@0.0.0.0
CSeq: 6 ACK
From: <sip:52000010102330000001@5200001010>;tag=1726656234184
To: <sip:34020000001370000001@1.204.105.252:21052>;tag=1097555858
Via: SIP/2.0/UDP xx.xxx.xxx.x:15060;rport=15060;branch=z9hG4bK-323833-f7c57fec761a4b9b5340a856dfddb41a
Max-Forwards: 70
Contact: <sip:52000010102330000001@8.137.51.116:15060>
User-Agent: LimeGBS v11111
Content-Length: 0

从信令服务器抓取的报文内容来看,没什么问题,都是按照国标标准协议走的。

接下来我们看流媒体端抓取的报文内容,我们将抓到的UDP包转换成RTP包,如下图。

接下来我们开始分析RTP包

从报文反馈的内容来看,平台往设备发送了136个包,设备接收了136个包,丢包率为0,持续时间是13.5秒,这里看下来也没有什么问题。平台正常发包,设备正常接收,不存在丢包的情况。

这里我们怀疑是不是RTP包有问题,是否因为没有声音,所以设备端接收了,但是放出来没有声音?于是接下来我们准备将RTP包回放一下,看是否有声音。

点击下方的Play Streams,这里我们可以看到一些信息反馈。如音频模式是g711a,采样率为8000HZ,而且从上面的图片中也看到了是音频格式是PCMA的。这里看下来也没什么问题,这也是大华设备支持的音频格式。

点击播放之后,如下

RTP流播放的时候,是正常且有声音的,到这里我们就几乎得到定论了,问题出在设备上,可能是格式不对或者设备配置的问题,接下来我们会对设备重新检查一下,看是否和配置以及音频支持程度有关。

相关推荐
饭饭大王66639 分钟前
CANN 生态深度整合:使用 `pipeline-runner` 构建高吞吐视频分析流水线
人工智能·音视频
晚霞的不甘2 小时前
CANN 编译器深度解析:TBE 自定义算子开发实战
人工智能·架构·开源·音视频
愚公搬代码2 小时前
【愚公系列】《AI短视频创作一本通》016-AI短视频的生成(AI短视频运镜方法)
人工智能·音视频
那个村的李富贵3 小时前
CANN赋能AIGC“数字人”革命:实时视频换脸与表情驱动实战
aigc·音视频
晚霞的不甘3 小时前
CANN 支持强化学习:从 Isaac Gym 仿真到机械臂真机控制
人工智能·神经网络·架构·开源·音视频
晚霞的不甘8 小时前
CANN 支持多模态大模型:Qwen-VL 与 LLaVA 的端侧部署实战
人工智能·神经网络·架构·开源·音视频
好家伙VCC15 小时前
### WebRTC技术:实时通信的革新与实现####webRTC(Web Real-TimeComm
java·前端·python·webrtc
拾荒的小海螺16 小时前
开源项目:LTX2 高效可控的开源视频生成模型
开源·音视频
EasyGBS1 天前
视频画面模糊、卡顿、丢失?EasyGBS新增“视频质量诊断”功能,告别人工盯屏
视觉检测·音视频·gb28181·花屏·视频质量诊断·蓝屏检测
zhuweisky1 天前
ArkTS实现鸿蒙手机视频聊天、屏幕分享(HarmonyOS)
音视频·harmonyos·鸿蒙开发