国标gb28181在做内网穿透时遇到的一些问题

最新推荐文章于 2024-06-15 16:51:57 发布
最新推荐文章于 2024-06-15 16:51:57 发布
阅读量5.6k 收藏 8
点赞数 1
分类专栏： sip/gb28181 文章标签： p2p 网络 java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wwyyxx26/article/details/94381891
版权

同某个厂家的摄像头做国标gb28181的联调，遇到一些问题这里做一下记录

情况是这样子的，这次项目的特点是使用国标gb28181做为摄像机和平台之间的通信协议方式，并且平台是上级在公网上，有一个公网ip，摄像头是下级，在内网里，要经过网关同公网上的平台通信。在我司和对方的厂家的内网里都有测试用摄像头，都能通到外网去。环境搭建好后将两个地点的摄像头向公网上的平台注册。

首先发现的问题是对方网络里的摄像头无法注册成功，我方网络里的摄像头则可以成功。两边的配置信息都是对的，后来发现该厂商的摄像头在请求注册时没有在via里加上rport参数导致。

因为我们这个项目是内网到外网，再从外网到内网，有内网穿透的情况，内网映射到外网的端口会发生改变，所以要有一套机制来做穿透，因为国标是基于sip协议的，sip下做内网穿透的事rport机制，如果发送的请求不带rport标识就是不启用这套机制，所以在外网到内网时会出问题。因为内网的头在发送信息到公网上会经过一个网关，网关会使用nat协议转换内网的端口，这个映射到公网上的端口可能和内网的一致，也有可能不一致！而刚好在我方的网络里这个端口恰巧一致了！而对方的不一致。

公网上的平台在收到摄像头的注册信息里因为没有发现rport参数，在返回注册响应时，直接使用请求里的摄像头内网端口信息了，直接导致对方网络里的摄像头得不到注册成功信息，而我方因为刚好映射为了相同的端口，却能收到注册响应能注册上。

如下是osip里打印出的日志，反应出了这个问题，收到的端口是17961，发送时却到了内网的39512上

| INFO1 | 63978 <eXtl_udp.c: 452> Message received from: 113.118.241.57:17961
| INFO1 | 63978 <udp.c: 1408> Received message len=500 from 113.118.241.57:17961:
REGISTER sip:340200000020000000065@112.33.56.65:5066 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.200:39512;branch=z9hG4bKa5394e4c
From: <sip:34020000001320000205@340200>;tag=5f7b2db0
To: <sip:34020000001320000205@340200>
Contact: <sip:34020000001320000205@192.168.1.200:39512>
Call-ID: 023D9B1335824B31@192.168.1.200
CSeq: 548 REGISTER
Max-Forwards: 70
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: HTSIP AGENT 2.0
Content-Length: 0


| INFO3 | 63978 <udp.c: 1426> MESSAGE REC. CALLID:023D9B1335824B31
| INFO1 | 63978 <udp.c: 1473> no transaction for message
| INFO2 | 63978 <osip_transaction.c: 136> allocating transaction resource 45 023D9B1335824B31
| INFO2 | 63978 <nist.c: 31> allocating NIST context
| INFO4 | 63979 <osip_transaction.c: 349> sipevent tr->transactionid: 45
| INFO4 | 63979 <osip_transaction.c: 350> sipevent tr->state: 15
| INFO4 | 63979 <osip_transaction.c: 351> sipevent evt->type: 12
| INFO4 | 63979 <osip_transaction.c: 352> sipevent evt->sip: c4033050
| INFO3 | 63979 <jcallback.c: 358> cb_rcvregister (id=45)
| INFO4 | 63979 <osip_transaction.c: 373> sipevent evt: method called!
| INFO4 | 63980 <osip_transaction.c: 349> sipevent tr->transactionid: 45
| INFO4 | 63980 <osip_transaction.c: 350> sipevent tr->state: 16
| INFO4 | 63980 <osip_transaction.c: 351> sipevent evt->type: 20
| INFO4 | 63980 <osip_transaction.c: 352> sipevent evt->sip: bc005f00
| INFO2 | 63980 <eXutils.c: 755> DNS resolution with 113.118.241.57:39512
| INFO2 | 63980 <eXutils.c: 779> getaddrinfo returned: 113.118.241.57 port 39512
| INFO1 | 63980 <eXtl_udp.c: 779> Message sent: (to dest=113.118.241.57:39512)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.200:39512;branch=z9hG4bKa5394e4c;received=113.118.241.57
From: <sip:34020000001320000205@340200>;tag=5f7b2db0
To: <sip:34020000001320000205@340200>;tag=1082451661
Call-ID: 023D9B1335824B31@192.168.1.200
CSeq: 548 REGISTER
User-Agent: JUNTAI SIP UAS/1.0
Date: 2019-06-29T21:52:10.001
Expires: 3600
Content-Length: 0

其次，在摄像头取到流，关闭流发送BYE时也存在问题，如下，在返回ack和bye时，找到的地址不对了，是内网的ip或地址去了

| INFO1 | 369109 <jcallback.c: 1528> cb_sndreq_retransmission (id=133)
| INFO4 | 369109 <osip_transaction.c: 373> sipevent evt: method called!
| INFO2 | 369522 <osip_transaction.c: 136> allocating transaction resource 134 385231458
| INFO2 | 369522 <ict.c: 32> allocating ICT context
| INFO4 | 369522 <osip.c: 1456> 1 Pending event already in transaction !
| INFO4 | 369522 <osip_transaction.c: 349> sipevent tr->transactionid: 134
| INFO4 | 369522 <osip_transaction.c: 350> sipevent tr->state: 0
| INFO4 | 369522 <osip_transaction.c: 351> sipevent evt->type: 16
| INFO4 | 369522 <osip_transaction.c: 352> sipevent evt->sip: 8038f730
| INFO2 | 369522 <eXutils.c: 755> DNS resolution with 113.118.241.57:18669
| INFO2 | 369522 <eXutils.c: 779> getaddrinfo returned: 113.118.241.57 port 18669
| INFO1 | 369522 <eXtl_udp.c: 779> Message sent: (to dest=113.118.241.57:18669)
INVITE sip:34020000001320000205@113.118.241.57:18669 SIP/2.0
Via: SIP/2.0/UDP 192.168.200.2:5066;rport;branch=z9hG4bK1721778447
From: <sip:34020000002000000065@112.33.56.65:5066>;tag=332179470
To: <sip:34020000001320000205@113.118.241.57:18669>
Call-ID: 385231458
CSeq: 4 INVITE
Contact: <sip:34020000002000000065@112.33.56.65:5066>
Content-Type: application/sdp
Max-Forwards: 70
User-Agent: JUNTAI SIP UAS/1.0
Subject: 34020000001320000205:1,34020000002000000065:1
Content-Length:   165

v=0
o=34020000002000000065 0 0 IN IP4 112.33.56.65
s=Play
c=IN IP4 112.33.56.65
t=0 0
m=video 33508 RTP/AVP 96
a=recvonly
a=rtpmap:96 PS/90000
y=0200000681
| INFO3 | 369535 <udp.c: 1426> MESSAGE REC. CALLID:385231458
| INFO4 | 369535 <osip.c: 1456> 1 Pending event already in transaction !
| INFO4 | 369535 <osip_transaction.c: 349> sipevent tr->transactionid: 134
| INFO4 | 369535 <osip_transaction.c: 350> sipevent tr->state: 1
| INFO4 | 369535 <osip_transaction.c: 351> sipevent evt->type: 13
| INFO4 | 369535 <osip_transaction.c: 352> sipevent evt->sip: 90003ae0
| INFO3 | 369535 <jcallback.c: 511> cb_rcv1xx (id=134)
| INFO4 | 369535 <osip_transaction.c: 373> sipevent evt: method called!
| INFO1 | 369536 <eXtl_udp.c: 452> Message received from: 113.118.241.57:18669
| INFO1 | 369536 <udp.c: 1408> Received message len=664 from 113.118.241.57:18669:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.200.2:5066;rport;branch=z9hG4bK1721778447
From: <sip:34020000002000000065@112.33.56.65:5066>;tag=332179470
To: <sip:34020000001320000205@340200>;tag=717142644a97aa49
Contact: <sip:34020000001320000205@192.168.1.200:53922>
Call-ID: 385231458
CSeq: 4 INVITE
Max-Forwards: 70
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,UPDATE,INFO
Supported: timer
Session-Expires: 200;refresher=uac
Server: WER Agent Ver 1.0
Content-Type: application/sdp
Content-Length: 153

v=0
o=34020000001320000205 0 0 IN IP4 192.168.1.200
s=Play
c=IN IP4 192.168.1.200
t=0 0
m=video 19002 RTP/AVP 96
a=rtpmap:96 PS/90000
a=sendonly
| INFO3 | 369536 <udp.c: 1426> MESSAGE REC. CALLID:385231458
| INFO4 | 369536 <osip.c: 1456> 1 Pending event already in transaction !
| INFO4 | 369536 <osip_transaction.c: 349> sipevent tr->transactionid: 134
| INFO4 | 369536 <osip_transaction.c: 350> sipevent tr->state: 2
| INFO4 | 369536 <osip_transaction.c: 351> sipevent evt->type: 14
| INFO4 | 369536 <osip_transaction.c: 352> sipevent evt->sip: 900035d0
| INFO3 | 369536 <jcallback.c: 930> cb_rcv2xx (id=134)
| INFO2 | 369536 <eXosip.c: 1444> Allow header contains UPDATE
| INFO1 | 369536 <jcallback.c: 217> cb_nict_kill_transaction (id=134)
| INFO4 | 369536 <osip_transaction.c: 373> sipevent evt: method called!
| INFO4 | 369537 <sdp_message.c: 1481> The rfc2327 says there should be at least an email or a phone header!- anyway, we don't mind about it.
| INFO2 | 369538 <eXutils.c: 755> DNS resolution with 113.118.241.57:53922
| INFO2 | 369538 <eXutils.c: 779> getaddrinfo returned: 113.118.241.57 port 53922
| INFO1 | 369538 <eXtl_udp.c: 779> Message sent: (to dest=113.118.241.57:53922)
ACK sip:34020000001320000205@192.168.1.200:53922 SIP/2.0
Via: SIP/2.0/UDP 192.168.200.2:5066;rport;branch=z9hG4bK396241289
From: <sip:34020000002000000065@112.33.56.65:5066>;tag=332179470
To: <sip:34020000001320000205@340200>;tag=717142644a97aa49
Call-ID: 385231458
CSeq: 4 ACK
Contact: <sip:34020000002000000065@112.33.56.65:5066>
Max-Forwards: 70
User-Agent: JUNTAI SIP UAS/1.0
Content-Length: 0
| INFO1 | 373733 <udp.c: 1264> ACK restransmission sent.
| INFO4 | 374410 <osip_transaction.c: 349> sipevent tr->transactionid: 121
| INFO4 | 374410 <osip_transaction.c: 350> sipevent tr->state: 18
| INFO4 | 374411 <osip_transaction.c: 351> sipevent evt->type: 9
| INFO4 | 374411 <osip_transaction.c: 352> sipevent evt->sip: 0
| INFO1 | 374411 <jcallback.c: 217> cb_nict_kill_transaction (id=121)
| INFO4 | 374411 <osip_transaction.c: 373> sipevent evt: method called!
| INFO4 | 374411 <osip_transaction.c: 265> transaction already removed from list 121!
| INFO2 | 374411 <osip_transaction.c: 281> free transaction resource 121 zxw34020000001320000244-191679322
| INFO2 | 374411 <nist.c: 73> free nist resource
| INFO2 | 374484 <osip_transaction.c: 136> allocating transaction resource 137 385231458
| INFO2 | 374484 <nict.c: 32> allocating NICT context
| INFO4 | 374484 <osip_transaction.c: 349> sipevent tr->transactionid: 137
| INFO4 | 374484 <osip_transaction.c: 350> sipevent tr->state: 10
| INFO4 | 374484 <osip_transaction.c: 351> sipevent evt->type: 18
| INFO4 | 374484 <osip_transaction.c: 352> sipevent evt->sip: 801c7150
| INFO2 | 374484 <eXutils.c: 755> DNS resolution with 192.168.1.200:53922
| INFO2 | 374484 <eXutils.c: 779> getaddrinfo returned: 192.168.1.200 port 53922
| INFO1 | 374484 <eXtl_udp.c: 779> Message sent: (to dest=192.168.1.200:53922)
BYE sip:34020000001320000205@192.168.1.200:53922 SIP/2.0
Via: SIP/2.0/UDP 192.168.200.2:5066;rport;branch=z9hG4bK1886964964
From: <sip:34020000002000000065@112.33.56.65:5066>;tag=332179470
To: <sip:34020000001320000205@340200>;tag=717142644a97aa49
Call-ID: 385231458
CSeq: 5 BYE
Contact: <sip:34020000002000000065@192.168.200.2:5066>
Max-Forwards: 70
User-Agent: JUNTAI SIP UAS/1.0
Content-Length: 0

同时，请看这篇文章国标Gb28181里Contact和Route的使用_wwyyxx26的专栏-CSDN博客

wwyyxx26
关注
  • 1
    点赞
  • 踩
  • 8
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
GB28181的NAT穿透
machh的专栏
05-18 3338
国标gb28181内网穿透 因为我们这个项目是内网到外网，再从外网到内网，有内网穿透的情况，内网映射到外网的端口会发生改变，所以要有一套机制来做穿透，因为国标是基于sip协议的，sip下做内网穿透的事rport机制，如果发送的请求不带rport标识就是不启用这套机制，所以在外网到内网时会出问题。因为内网的头在发送信息到公网上会经过一个网关，网关会使用nat协议转换内网的端口，这个映射到公网上的端口可能和内网的一致，也有可能不一致！而刚好在我方的网络里这个端口恰巧一致了！而对方的不一致。 https://bl
将国标GB28181视频平台LiteCVR通过frp服务映射到公网进行访问和运维的方法
LiteMedia/cn
08-15 141
将国标GB28181视频平台LiteCVR通过frp服务映射到公网进行访问和运维的方法
Android平台GB28181设备接入端如何支持跨网段语音对讲
乐学吧
12-13 1083
实际上，GB28181平台语音广播和语音对讲，特别是语音对讲，不光要解决传输跨网段问题，还可能要处理回音，噪音，增益控制等，这块，我们之前有了非常好的技术积累，处理起来轻车熟路，有需要测试的开发者，也可以私信联系我。两种技术方案虽然都可以实现语音对讲，方案1相对实现起来简单，但缺点明显，方案2技术优势有目共睹，更适合相对复杂的网络环境。遗憾的是，大多公司都没有实现，或者说市面上真正实现跨网段语音对讲的尚在少数，感兴趣的开发者可以酌情参考。
C#批量设置海康和大华录像机NVR,GB28181的通道编码.
最新发布
threadroc的专栏
06-15 513
我经常要把小区海康或者大华的硬盘录像机推送到自己搭建的gb28181监控平台,每次几百个摄像头编码,有点头大,就用了1个多周写了个批量设置海康和大华硬盘录像机的通道编码的程序,海康和大华的SDK简直不是人看的. 太乱了.大华读取通道编码的代码。
国标Gb28181里Contact和Route的使用
wwyyxx26的专栏
12-07 3423
国标Gb28181是基于Sip协议的，因此对Contact和Route的使用，也可以说是Sip里Contact和Route的使用。Contact和Route则是sip协议里的头字段。 现在，在使用国标Gb28181来做项目时，经常会遇到这种情况，国标的下级是在内网里，上级在公网上。如果不做处理，下级到上级会经过nat协议的转换从而导致上级向下级发送请求时(比如获取目录请求)不能到达
WVP+ZLMediaKit实现NAT穿透推流播放录制，支持IPC、NVR、DVR等设备接入，支持GB28181国标级联
热门推荐
挨T工作室的博客
05-13 1万+
前言        好久没有更新了，一个是没有时间，二个写东西可能更多讲究的是一个时机，半熟不熟的领域怕写错，太熟的领域又不敢写，只有刚接触的东西才敢乱写。        也罢，正应了那句初生牛犊不畏虎。言归正传，该篇内容主要记录WVP+ZLMediaKit的初次使用过程和期间遇到的一些问题 。 一、WVP     &nbsp
转发同事搞GB28181协议的经历
Car_eye的博客
07-05 1097
2017年刚参加工作，项目中就用到了摄像头。内网用rtsp拉流可以通，外网行不通，当时一直研究怎么穿透网络，最后根据客户的情况，选择了比较麻烦的一种方案：   客户门店使用电信宽带拨号上网，路由器绑定在锐捷平台。在路由器上做好端口映射(映射NVR的web访问端口)。 需要观看的时候，登陆锐捷的平台得到路由器的外网地址，再访问NVR。 当然这样做弊端很多： 穿透率低，拨号上网不一定能分配到公网ip，很有可能还是内网的ip。即使分配到了公网ip，很多宽带都屏蔽了端口(NAT限制)。即使用花生壳等穿透工具，宽
GB28181国标测试工具
09-26
GB28181国标测试工具是一款针对中国国家标准GB28181-2011进行系统兼容性和功能验证的专业软件。该标准主要应用于我国的公共安全视频监控网络系统，旨在统一不同设备和平台之间的通信协议，实现跨区域、跨部门的视频...
GB28181国标，2011和2016两个版本下载
12-05
GB28181国家标准，全称为《信息技术 视频监控系统联网系统信息传输、交换、控制技术要求》，是中国在视频监控领域的一项重要标准。该标准的制定旨在规范国内视频监控系统的互联互通，提升安防行业的技术水平和服务...
GB28181协议测试工具，模拟批量IPC对NVR进行压测
12-20
GB28181协议，全称为《信息技术 安全技术 视频监控系统联网系统信息传输、交换、控制技术要求》，是中国国家标准，主要用于规范视频监控系统的联网与互通。该协议旨在解决不同厂家设备间的互操作性问题，实现跨区域...
国标GB28181介绍_GB28181_
10-03
GB28181，全称为《信息技术 视频监控系统联网系统信息传输、交换、控制技术要求》，是中国国家强制性标准，旨在规范视频监控系统的互联互通，提升安防行业的信息化水平。这个标准的制定与实施，对于推动中国视频监控...
海康GB28181接入SRS服务器,实现低延迟直播
Alan_ran的博客
09-07 7303
海康设备GB28181接入SRS，实现低延迟直播
GB28181开源项目WVP部署详细流程
qq_42191775的博客
01-28 7053
基于GB/T28181-2016标准信令实现，兼容GB/T28181-2011。 自带完整前端页面，开箱即用。 完全开源，且使用MIT许可协议。可以在保留版权信息的基础上商用
GB28181平台本质与应用概述
wangjie_jack的专栏
06-02 2775
随着GB28181应用的深入，以及对各用户的行业应用和使用场景的广泛接触与了解，其实我觉得有必要结合GB28181协议的本质，来谈论一下其应用和扩展。 总所周知，GB28181协议全称叫《安全防范视频监控联网系统信息传输、交换、控制技术要求》，是一个定义视频联网传输和设备控制标准的白皮书，主要解决了视频间互联互通，数据共享，以及设备控制的问题，这个问题从顶层解决了视频信息各自为战的问题，打通了视频联网的信息孤岛。 对于完整的GB28181解决方案，由前端视音频设备ap...
Android平台GB28181设备接入端语音广播技术探究和填坑指南
乐学吧
07-18 299
Android平台GB28181设备接入侧为什么没有公司愿意做？真的是坑太多，GB28181厂商太多，好多厂商包括大厂商并没有严格按照规范来，简单来说，50%的精力写代码，50%的精力查问题和各种兼容处理。
视频监控安防平台-国标28181平台对接之和海康国标28181平台对接出现的不合理现象
视频监控安防平台-国标28181
04-23 9270
                  视频监控安防平台-国标28181平台对接之和海康国标28181平台对接出现的不合理现象    最近在项目上面和海康平台对接的时候遇到的问题：1、请求视频过30s视频就会断开. 2、点播或则下载的时候未查询回复488的错误。    首先来说一下请求视频30秒就会断开的问题：由于前几年和海康对接的时候遇到这种问题，直接让海康把rtcp关闭就没问题，现在又遇到，一直以...
支持国标GB28181的平台及视频监控设备接入的配置方法
hzhouhangkeji的博客
10-31 947
LiveMedia视频中间件是支持部署到本地服务器或者云服务器的纯软件服务，也提供服务器、GPU一体机全包服务，提供视频设备管理、无插件、跨平台的实时视频、历史回放、语音对讲、设备控制等基础功能，支持视频协议有海康、大华私有协议、GB28181、ISUP(EHOME)、ONVIF、RTSP等。提供分布式、高并发部署方案，适用于楼宇监控、校园安防、旅游景区等场景。
GB28181服务器的搭建
m0_58530510的博客
05-29 6580
Ubuntu20+阿里云服务器公网，搭建GB28181服务器，详细全过程整理，做个记录。
SRS加FRP内网穿透搭建支持GB28181的视频服务器
Bayern233的博客
06-09 2257
文章目录一、SRS国标GB28181搭建二、FRP内网穿透1.配置文件2.FRP配置文件3.连接摄像头总结 一、SRS国标GB28181搭建 下面两篇文章写的很详细，这里就不作赘述了。 国产开源流媒体SRS4.0对视频监控GB28181的支持 支持对接GB28181吗？监控，智能摄像头，国标推流，RTSP 二、FRP内网穿透 1.配置文件 # push gb28181 stream to SRS. listen 7009; max_connections
gb28181协议 内外网穿透
12-17
GB28181协议是中国国家标准化管理委员会发布的视频监控领域的通信协议标准。其目的是建立一种统一的视频监控传输协议，实现不同品牌、不同系统的视频设备之间的互联互通。 内外网穿透是指在网络环境中通过一定的技术手段，使得内网中的设备可以和外网进行通信。在视频监控系统中，内外网穿透技术可以用于实现远程监控，即用户可以通过外网访问和控制内网中的视频设备。 在GB28181协议中，内外网穿透是一个重要的功能要求。它通过设备的注册与保活机制，在设备侧与监控平台之间建立起一条可靠的通信链路。这条链路可以穿越设备所处的内网环境和外网环境，实现远程访问和控制。 为了实现内外网穿透，GB28181协议使用了一些技术手段。首先，设备需要向监控平台注册，告知自己的IP地址和端口号。监控平台可以根据这些信息建立与设备的连接。其次，设备在内网中会定时发送保活信号给监控平台，以维持连接的稳定性。这样，即使设备的IP地址是动态分配的，也可以保持通信的正常进行。 通过GB28181协议实现的内外网穿透技术，为视频监控系统的远程访问和控制提供了便利。用户可以通过互联网任意地点，随时随地地监控和管理视频设备，增强了视频监控系统的实际应用价值。同时，内外网穿透技术也为视频监控系统的安全性提供了保障，确保了设备与监控平台之间的安全通信。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值