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

最新推荐文章于 2025-09-10 23:33:27 发布
转载 最新推荐文章于 2025-09-10 23:33:27 发布 · 3.1k 阅读 · 5 ·
CC 4.0 BY-SA版权
原文链接：https://blog.youkuaiyun.com/wwyyxx26/article/details/94381891
文章标签：

#28181 #NAT

本文记录了在遵循国标GB28181进行内外网摄像头平台联调时遇到的问题，涉及跨网络rport参数缺失、内网穿透机制及注册响应错误。通过详细日志分析，揭示了厂商摄像头在注册过程中由于缺少rport导致的连接失败案例。

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

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

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

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

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

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


 

  1. | INFO1 | 63978 <eXtl_udp.c: 452> Message received from: 113.118.241.57:17961

  2. | INFO1 | 63978 <udp.c: 1408> Received message len=500 from 113.118.241.57:17961:

  3. REGISTER sip:340200000020000000065@112.33.56.65:5066 SIP/2.0

  4. Via: SIP/2.0/UDP 192.168.1.200:39512;branch=z9hG4bKa5394e4c

  5. From: <sip:34020000001320000205@340200>;tag=5f7b2db0

  6. To: <sip:34020000001320000205@340200>

  7. Contact: <sip:34020000001320000205@192.168.1.200:39512>

  8. Call-ID: 023D9B1335824B31@192.168.1.200

  9. CSeq: 548 REGISTER

  10. Max-Forwards: 70

  11. Expires: 3600

  12. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO

  13. User-Agent: HTSIP AGENT 2.0

  14. Content-Length: 0

  15.  
  16.  

  17. | INFO3 | 63978 <udp.c: 1426> MESSAGE REC. CALLID:023D9B1335824B31

  18. | INFO1 | 63978 <udp.c: 1473> no transaction for message

  19. | INFO2 | 63978 <osip_transaction.c: 136> allocating transaction resource 45 023D9B1335824B31

  20. | INFO2 | 63978 <nist.c: 31> allocating NIST context

  21. | INFO4 | 63979 <osip_transaction.c: 349> sipevent tr->transactionid: 45

  22. | INFO4 | 63979 <osip_transaction.c: 350> sipevent tr->state: 15

  23. | INFO4 | 63979 <osip_transaction.c: 351> sipevent evt->type: 12

  24. | INFO4 | 63979 <osip_transaction.c: 352> sipevent evt->sip: c4033050

  25. | INFO3 | 63979 <jcallback.c: 358> cb_rcvregister (id=45)

  26. | INFO4 | 63979 <osip_transaction.c: 373> sipevent evt: method called!

  27. | INFO4 | 63980 <osip_transaction.c: 349> sipevent tr->transactionid: 45

  28. | INFO4 | 63980 <osip_transaction.c: 350> sipevent tr->state: 16

  29. | INFO4 | 63980 <osip_transaction.c: 351> sipevent evt->type: 20

  30. | INFO4 | 63980 <osip_transaction.c: 352> sipevent evt->sip: bc005f00

  31. | INFO2 | 63980 <eXutils.c: 755> DNS resolution with 113.118.241.57:39512

  32. | INFO2 | 63980 <eXutils.c: 779> getaddrinfo returned: 113.118.241.57 port 39512

  33. | INFO1 | 63980 <eXtl_udp.c: 779> Message sent: (to dest=113.118.241.57:39512)

  34. SIP/2.0 200 OK

  35. Via: SIP/2.0/UDP 192.168.1.200:39512;branch=z9hG4bKa5394e4c;received=113.118.241.57

  36. From: <sip:34020000001320000205@340200>;tag=5f7b2db0

  37. To: <sip:34020000001320000205@340200>;tag=1082451661

  38. Call-ID: 023D9B1335824B31@192.168.1.200

  39. CSeq: 548 REGISTER

  40. User-Agent: JUNTAI SIP UAS/1.0

  41. Date: 2019-06-29T21:52:10.001

  42. Expires: 3600

  43. Content-Length: 0

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


 

  1. | INFO1 | 369109 <jcallback.c: 1528> cb_sndreq_retransmission (id=133)

  2. | INFO4 | 369109 <osip_transaction.c: 373> sipevent evt: method called!

  3. | INFO2 | 369522 <osip_transaction.c: 136> allocating transaction resource 134 385231458

  4. | INFO2 | 369522 <ict.c: 32> allocating ICT context

  5. | INFO4 | 369522 <osip.c: 1456> 1 Pending event already in transaction !

  6. | INFO4 | 369522 <osip_transaction.c: 349> sipevent tr->transactionid: 134

  7. | INFO4 | 369522 <osip_transaction.c: 350> sipevent tr->state: 0

  8. | INFO4 | 369522 <osip_transaction.c: 351> sipevent evt->type: 16

  9. | INFO4 | 369522 <osip_transaction.c: 352> sipevent evt->sip: 8038f730

  10. | INFO2 | 369522 <eXutils.c: 755> DNS resolution with 113.118.241.57:18669

  11. | INFO2 | 369522 <eXutils.c: 779> getaddrinfo returned: 113.118.241.57 port 18669

  12. | INFO1 | 369522 <eXtl_udp.c: 779> Message sent: (to dest=113.118.241.57:18669)

  13. INVITE sip:34020000001320000205@113.118.241.57:18669 SIP/2.0

  14. Via: SIP/2.0/UDP 192.168.200.2:5066;rport;branch=z9hG4bK1721778447

  15. From: <sip:34020000002000000065@112.33.56.65:5066>;tag=332179470

  16. To: <sip:34020000001320000205@113.118.241.57:18669>

  17. Call-ID: 385231458

  18. CSeq: 4 INVITE

  19. Contact: <sip:34020000002000000065@112.33.56.65:5066>

  20. Content-Type: application/sdp

  21. Max-Forwards: 70

  22. User-Agent: JUNTAI SIP UAS/1.0

  23. Subject: 34020000001320000205:1,34020000002000000065:1

  24. Content-Length: 165

  25.  

  26. v=0

  27. o=34020000002000000065 0 0 IN IP4 112.33.56.65

  28. s=Play

  29. c=IN IP4 112.33.56.65

  30. t=0 0

  31. m=video 33508 RTP/AVP 96

  32. a=recvonly

  33. a=rtpmap:96 PS/90000

  34. y=0200000681


 

  1. | INFO3 | 369535 <udp.c: 1426> MESSAGE REC. CALLID:385231458

  2. | INFO4 | 369535 <osip.c: 1456> 1 Pending event already in transaction !

  3. | INFO4 | 369535 <osip_transaction.c: 349> sipevent tr->transactionid: 134

  4. | INFO4 | 369535 <osip_transaction.c: 350> sipevent tr->state: 1

  5. | INFO4 | 369535 <osip_transaction.c: 351> sipevent evt->type: 13

  6. | INFO4 | 369535 <osip_transaction.c: 352> sipevent evt->sip: 90003ae0

  7. | INFO3 | 369535 <jcallback.c: 511> cb_rcv1xx (id=134)

  8. | INFO4 | 369535 <osip_transaction.c: 373> sipevent evt: method called!

  9. | INFO1 | 369536 <eXtl_udp.c: 452> Message received from: 113.118.241.57:18669

  10. | INFO1 | 369536 <udp.c: 1408> Received message len=664 from 113.118.241.57:18669:

  11. SIP/2.0 200 OK

  12. Via: SIP/2.0/UDP 192.168.200.2:5066;rport;branch=z9hG4bK1721778447

  13. From: <sip:34020000002000000065@112.33.56.65:5066>;tag=332179470

  14. To: <sip:34020000001320000205@340200>;tag=717142644a97aa49

  15. Contact: <sip:34020000001320000205@192.168.1.200:53922>

  16. Call-ID: 385231458

  17. CSeq: 4 INVITE

  18. Max-Forwards: 70

  19. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,UPDATE,INFO

  20. Supported: timer

  21. Session-Expires: 200;refresher=uac

  22. Server: WER Agent Ver 1.0

  23. Content-Type: application/sdp

  24. Content-Length: 153

  25.  

  26. v=0

  27. o=34020000001320000205 0 0 IN IP4 192.168.1.200

  28. s=Play

  29. c=IN IP4 192.168.1.200

  30. t=0 0

  31. m=video 19002 RTP/AVP 96

  32. a=rtpmap:96 PS/90000

  33. a=sendonly


 

  1. | INFO3 | 369536 <udp.c: 1426> MESSAGE REC. CALLID:385231458

  2. | INFO4 | 369536 <osip.c: 1456> 1 Pending event already in transaction !

  3. | INFO4 | 369536 <osip_transaction.c: 349> sipevent tr->transactionid: 134

  4. | INFO4 | 369536 <osip_transaction.c: 350> sipevent tr->state: 2

  5. | INFO4 | 369536 <osip_transaction.c: 351> sipevent evt->type: 14

  6. | INFO4 | 369536 <osip_transaction.c: 352> sipevent evt->sip: 900035d0

  7. | INFO3 | 369536 <jcallback.c: 930> cb_rcv2xx (id=134)

  8. | INFO2 | 369536 <eXosip.c: 1444> Allow header contains UPDATE

  9. | INFO1 | 369536 <jcallback.c: 217> cb_nict_kill_transaction (id=134)

  10. | INFO4 | 369536 <osip_transaction.c: 373> sipevent evt: method called!

  11. | 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.

  12. | INFO2 | 369538 <eXutils.c: 755> DNS resolution with 113.118.241.57:53922

  13. | INFO2 | 369538 <eXutils.c: 779> getaddrinfo returned: 113.118.241.57 port 53922

  14. | INFO1 | 369538 <eXtl_udp.c: 779> Message sent: (to dest=113.118.241.57:53922)

  15. ACK sip:34020000001320000205@192.168.1.200:53922 SIP/2.0

  16. Via: SIP/2.0/UDP 192.168.200.2:5066;rport;branch=z9hG4bK396241289

  17. From: <sip:34020000002000000065@112.33.56.65:5066>;tag=332179470

  18. To: <sip:34020000001320000205@340200>;tag=717142644a97aa49

  19. Call-ID: 385231458

  20. CSeq: 4 ACK

  21. Contact: <sip:34020000002000000065@112.33.56.65:5066>

  22. Max-Forwards: 70

  23. User-Agent: JUNTAI SIP UAS/1.0

  24. Content-Length: 0


 

  1. | INFO1 | 373733 <udp.c: 1264> ACK restransmission sent.

  2. | INFO4 | 374410 <osip_transaction.c: 349> sipevent tr->transactionid: 121

  3. | INFO4 | 374410 <osip_transaction.c: 350> sipevent tr->state: 18

  4. | INFO4 | 374411 <osip_transaction.c: 351> sipevent evt->type: 9

  5. | INFO4 | 374411 <osip_transaction.c: 352> sipevent evt->sip: 0

  6. | INFO1 | 374411 <jcallback.c: 217> cb_nict_kill_transaction (id=121)

  7. | INFO4 | 374411 <osip_transaction.c: 373> sipevent evt: method called!

  8. | INFO4 | 374411 <osip_transaction.c: 265> transaction already removed from list 121!

  9. | INFO2 | 374411 <osip_transaction.c: 281> free transaction resource 121 zxw34020000001320000244-191679322

  10. | INFO2 | 374411 <nist.c: 73> free nist resource

  11. | INFO2 | 374484 <osip_transaction.c: 136> allocating transaction resource 137 385231458

  12. | INFO2 | 374484 <nict.c: 32> allocating NICT context

  13. | INFO4 | 374484 <osip_transaction.c: 349> sipevent tr->transactionid: 137

  14. | INFO4 | 374484 <osip_transaction.c: 350> sipevent tr->state: 10

  15. | INFO4 | 374484 <osip_transaction.c: 351> sipevent evt->type: 18

  16. | INFO4 | 374484 <osip_transaction.c: 352> sipevent evt->sip: 801c7150

  17. | INFO2 | 374484 <eXutils.c: 755> DNS resolution with 192.168.1.200:53922

  18. | INFO2 | 374484 <eXutils.c: 779> getaddrinfo returned: 192.168.1.200 port 53922

  19. | INFO1 | 374484 <eXtl_udp.c: 779> Message sent: (to dest=192.168.1.200:53922)

  20. BYE sip:34020000001320000205@192.168.1.200:53922 SIP/2.0

  21. Via: SIP/2.0/UDP 192.168.200.2:5066;rport;branch=z9hG4bK1886964964

  22. From: <sip:34020000002000000065@112.33.56.65:5066>;tag=332179470

  23. To: <sip:34020000001320000205@340200>;tag=717142644a97aa49

  24. Call-ID: 385231458

  25. CSeq: 5 BYE

  26. Contact: <sip:34020000002000000065@192.168.200.2:5066>

  27. Max-Forwards: 70

  28. User-Agent: JUNTAI SIP UAS/1.0

  29. Content-Length: 0

GB28181的NAT穿透
machh的专栏
05-18 4079
国标gb28181内网穿透 因为我们这个项目是内网到外网，再从外网到内网，有内网穿透的情况，内网映射到外网的端口会发生改变，所以要有一套机制来做穿透，因为国标是基于sip协议的，sip下做内网穿透的事rport机制，如果发送的请求不带rport标识就是不启用这套机制，所以在外网到内网时会出问题。因为内网的头在发送信息到公网上会经过一个网关，网关会使用nat协议转换内网的端口，这个映射到公网上的端口可能和内网的一致，也有可能不一致！而刚好在我方的网络里这个端口恰巧一致了！而对方的不一致。 https://bl
SRS加FRP内网穿透搭建支持GB28181的视频服务器
Bayern233的博客
06-09 2934
文章目录一、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
wvp-GB28181:WEB视频平台是一个基于GB28181-2016标准实现的网络视频平台，负责实现核心信令与设备管理后台部分，支持NAT穿透，支持海康，大华，宇视等品牌的IPC，NVR，DVR接入。流媒体服务基于ZLMediaKit-https
03-19
wvp Web视频平台是一个基于GB28181-2016标准实现的网络视频平台，负责实现核心信令与设备管理后台部分，支持NAT穿透，支持海康，大华，宇视等品牌的IPC，NVR，DVR接入。流媒体服务基于ZLMediaKit- 前端展示基于MediaServerUI- 应用场景： 主要应用在IPC等设备没有固定IP地址，但需要在互联网中观看的场景。要求IPC设备可以访问互联网，有云服务器用于部署本服务。预计7个月可以达到商用级别的文档性 支持特性： 1，视频预览2，云台控制（方向，缩放控制） 3，视频设备信息同步4，离在线监控5，录像查询和回放（基于NVR \ DVR，暂不支持快进，seek操作） 6，无人观看自动断流 2020路线图： 5月中旬-视频快照（基于NVR \ DVR），设备认证（基于密码） 5月下旬-设备报警6月上旬-流媒体认证（ZLM推流，取流） 6月下旬-语音对​
WVP-GB28181-Pro项目端口映射配置指南
最新发布
gitblog_01001的博客
09-10 509
WVP-GB28181-Pro是一个基于GB/T28181标准的视频监控平台开源项目，主要用于实现视频监控设备的接入、管理和流媒体服务。该项目通常与ZLM(流媒体服务器)配合使用，构建完整的视频监控解决方案。 ## 内网部署与公网映射 在实际部署中，很多用户会选择在内网环境部署WVP-GB28181-Pro系统，然后通过端口映射的方式将服务暴露到公网。这种部署方式需要考虑网络架构和端口安全配置...
GB28181出内网
weixin_30718391的博客
09-15 1195
最近关注GB28181的朋友很多，昨天有位朋友问到GB28181出内网的问题，希望我花5分钟的时间 讲讲如何通过GB28181协议将内网的摄像机视频推送到公网。要说清楚这个问题，5分钟的时间应该不 够，还是写篇文章跟大家分享下。 说这个问题之前，我想先聊聊GB28181协议，首先我们需要了解的是GB28181是应用层协议，而 不是传输层协议。所谓应用层协议说简单点就是...
实现摄像头在内网、外网、gb28181 实现 “视频监控/直播” 的常用几种方式
qq_16005627的博客
09-23 1万+
gb28181+sip+流媒体 nvr、摄像机+本地nginx/ffmpeg+流媒体
将国标GB28181视频平台LiteCVR通过frp服务映射到公网进行访问和运维的方法
LiteMedia/cn
08-15 318
将国标GB28181视频平台LiteCVR通过frp服务映射到公网进行访问和运维的方法
国标Gb28181里Contact和Route的使用
wwyyxx26的专栏
12-07 5206
国标Gb28181是基于Sip协议的，因此对Contact和Route的使用，也可以说是Sip里Contact和Route的使用。Contact和Route则是sip协议里的头字段。 现在，在使用国标Gb28181来做项目时，经常会遇到这种情况，国标的下级是在内网里，上级在公网上。如果不做处理，下级到上级会经过nat协议的转换从而导致上级向下级发送请求时(比如获取目录请求)不能到达
GB28181转RTSP、RTMP和HLS
08-22
GB28181是中国国家规定的音视频监控系统联网标准，它定义了设备注册、视频监控数据传输等规范，主要用于实现不同厂家的监控设备在统一平台下的互联互通。本项目涉及的技术核心是将遵循GB28181协议的监控视频流转换为...
海康存在内网穿透时的国标取流样本
wwyyxx26的专栏
07-01 1768
这是一个海康存在内网穿透时的国标取流样本，其中有个小细节 | INFO3 | 150951346 <jcallback.c: 1490> cb_snd123456xx (id=76086) | INFO4 | 150951346 <osip_transaction.c: 373> sipevent evt: method called! | INFO2 | 150951...
GB28181平台测试程序对接（上下级）下载
04-20
GB28181平台测试程序，可以作为GB28181 上级 和 下级 支持对接海康、科达、大华、雄迈等各种市面热销平台，对于政府部门GB28181对接成功案例很多
高性能GB28181国标流媒体服务几种流传输模式- UDP、TCP被动、TCP主动模式
青柿视频流媒体的博客
07-16 4046
国标流传输模式 - UDP 服务端监听UDP端口，通过信令服务告知设备端口，设备主动向服务端发起流传输 - TCP 被动 服务端监听TCP端口，通过信令服务告知设备端口，设备主动向服务端发起流传输 - TCP 主动 设备端告知服务端监听的TCP端口情况，服务端主动向设备拉流，此种场景较少，且设备所在网络可以被服务所在网络访问。
如何将穿透NAT打洞程序嵌入至国标GB28181协议视频结构化平台EasyGBS程序内部？
EasyGBS的博客
04-26 310
近期我们在研发国标平台EasyGBS添加WebRTC播放协议的功能，为了实现WebRTC双向通信的功能，运用了打洞程序。其实打洞程序是比较通俗的说法，准确的叫法应该是“穿透NAT”。一个端点发一个UDP消息出去之后，就把自己的墙打了一个洞；另外一个端点也把它的墙打了一个洞，通过这样的程序，当平台和播放端不在一个网段的时候，双方仍可以向对方的洞发数据，进行通信。 在上一个版本中，打洞程序是在EasyGBS程序外启动，这就导致启用非常不便，所以我们要将此程序添加到EasyGBS的内部代码中。 在Easy
通过LiveGBS国标GB/T28181协议视频平台将内外网设备统一集中管理
青柿视频流媒体的博客
10-27 1127
GB/T28181协议视频平台将内外网设备统一集中管理1、关于内外网设备如何接入2、内网|外网设备接入3、告知设备服务端的收流IP3.1、默认收流IP配置3.2、自定义收流IP4、搭建GB28181视频直播平台 1、关于内外网设备如何接入 在通过GB28181协议，接入一些设备如海康、大华、宇视的摄像头，或是海康大华的国标平台共享的设备的时候。我们往往会遇到这样的问提。我们在内网中有一些摄像头，在公网环境中也有一些摄像头。而内网中的摄像头只能通过内网地址，访问到部署国标服务的服务器上面。外网的摄像头只能通过
WVP+ZLMediaKit实现NAT穿透推流播放录制，支持IPC、NVR、DVR等设备接入，支持GB28181国标级联
热门推荐
挨T工作室的博客
05-13 1万+
前言        好久没有更新了，一个是没有时间，二个写东西可能更多讲究的是一个时机，半熟不熟的领域怕写错，太熟的领域又不敢写，只有刚接触的东西才敢乱写。        也罢，正应了那句初生牛犊不畏虎。言归正传，该篇内容主要记录WVP+ZLMediaKit的初次使用过程和期间遇到的一些问题 。 一、WVP     &nbsp
DZ先生怪谈国标28181之监控系统防火墙控制和NAT
DZ先生怪谈GB28181
02-14 2726
1. 自述 关于监控，可能我们用到防火墙的案例并不多，甚至少之又少，在公安网中有网闸，在政府网中可能会有单独的防火墙或者网闸，但在这里DZ先生建议，只要厂家的平台是基于linux系统，我建议您还是了解下，因为当遇到问题的时候，至少您知道从哪里下手，或者自己就能解决，就不必要等待二线或者别人的帮助，也可以获得客户对你的认可。了解知道的越多，就越能更加快速的处理问题，提高效率。 2. 防火墙规则 ...
国标GB/T28181-2022：安防监控中P2P穿透方法解析
OpenSkeye的博客
03-18 892
在安防监控系统中，设备通常部署在不同的网络环境中，可能受到NAT（网络地址转换）或防火墙的限制，导致设备之间无法直接通信。P2P穿透技术通过建立设备之间的直接连接，绕过NAT和防火墙的限制，实现高效、低延迟的数据传输。Skeyevss平台结合GB/T28181-2022标准和P2P穿透技术，为安防监控系统提供了高效、安全的设备互联解决方案。通过NAT类型检测、穿透策略选择和安全性保障，Skeyevss平台能够有效解决复杂网络环境下的设备直连问题，提升监控系统的实时性和可靠性。
安卓GB28181跨网段语音对讲
lsheevyfg的专栏
12-05 943
安卓GB28181语音对讲跨网段，安卓GB28181跨网段语音对讲, 安卓国标语音对讲跨网段，安卓国标跨网段语音对讲，安卓GB28181跨网段语音对讲方案探讨实现, 安卓GB28181语音对讲跨网段方案探讨实现.
gb28181协议 内外网穿透
12-17
GB28181协议是中国国家标准化管理委员会发布的视频监控领域的通信协议标准。其目的是建立一种统一的视频监控传输协议，实现不同品牌、不同系统的视频设备之间的互联互通。 内外网穿透是指在网络环境中通过一定的技术手段，使得内网中的设备可以和外网进行通信。在视频监控系统中，内外网穿透技术可以用于实现远程监控，即用户可以通过外网访问和控制内网中的视频设备。 在GB28181协议中，内外网穿透是一个重要的功能要求。它通过设备的注册与保活机制，在设备侧与监控平台之间建立起一条可靠的通信链路。这条链路可以穿越设备所处的内网环境和外网环境，实现远程访问和控制。 为了实现内外网穿透，GB28181协议使用了一些技术手段。首先，设备需要向监控平台注册，告知自己的IP地址和端口号。监控平台可以根据这些信息建立与设备的连接。其次，设备在内网中会定时发送保活信号给监控平台，以维持连接的稳定性。这样，即使设备的IP地址是动态分配的，也可以保持通信的正常进行。 通过GB28181协议实现的内外网穿透技术，为视频监控系统的远程访问和控制提供了便利。用户可以通过互联网任意地点，随时随地地监控和管理视频设备，增强了视频监控系统的实际应用价值。同时，内外网穿透技术也为视频监控系统的安全性提供了保障，确保了设备与监控平台之间的安全通信。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值