國標gb28181在做內網穿透時遇到的一些問題

gouguofei發表於2020-09-24

同某個廠家的攝像頭做國標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

配置pycharm 編譯器時遇到的一些問題
2019-03-09
PyCharm編譯
Python操作SAP時候遇到的一些常見問題
2024-04-28
Python
小程式遇到的一些問題
2024-04-15
內網穿透的作用免費內網穿透有哪些？
2022-01-06
內網穿透
練習負載均衡時遇到的一些問題，求解答
2019-03-26
負載
Docker遇到的一些問題和感想
2022-03-03
Docker
VisualStudio遇到的一些初級問題
2018-08-09
面試中遇到的一些問題
2018-07-01
面試
遇到的編碼問題、時區問題整理
2021-08-10
資料標準化遇到的問題
2018-04-04
docker開荒hyperf遇到的一些問題
2020-08-18
Docker
vue工作中遇到的一些小問題
2018-08-13
Vue
C#操作時區轉換時遇到的一些問題和解決方法分享
2020-05-14
C#
vue 克隆物件時遇到的問題
2019-11-07
Vue物件
FRP 內網穿透
2019-08-23
FRP內網穿透
ngrok 內網穿透
2020-12-15
內網穿透
內網穿透指南
2018-06-20
內網穿透
專案中遇到的一些問題小結
2018-06-30
maven專案遇到的一些問題記錄
2018-04-22
Maven
atxserver2 部署遇到一些問題
2020-10-14
Server
什麼是內網穿透？為什麼使用內網穿透？
2023-02-08
內網穿透
內網穿透教程，簡單，便捷，極速穿透內網埠
2020-11-28
內網穿透
php部署到nginx時遇到的問題
2022-06-14
PHPNginx
配置MapReduce時遇到的問題記錄
2018-11-18
frp內網穿透，客戶端能訪問，服務端訪問報錯404，有兄弟遇到過嗎
2021-10-19
FRP內網穿透客戶端服務端
測試管理者常遇到的一些問題
2024-09-29
Laraval 配置微信服務端遇到的一些問題
2022-05-26
服務端
關於動態表單遇到的一些問題
2022-03-29
工作中遇到的一些問題和處理
2019-04-17
阿里面試中遇到的一些架構問題
2018-09-11
阿里面試架構
關於Java中分層中遇到的一些問題
2018-04-15
Java
內網穿透神器 Ngrok 的使用
2019-11-05
內網穿透
免費內網穿透方案實現外網訪問內網群暉/NAS
2020-12-07
內網穿透
natapp內網穿透工具
2024-07-20
APP內網穿透
內網穿透技術
2020-10-29
內網穿透
FRP搭建內網穿透
2019-01-16
FRP內網穿透
frp實現內網穿透--支援80埠訪問
2020-10-27
FRP內網穿透
使用ssh隧道穿透NAT訪問內網主機
2018-10-24
穿透內網

國標gb28181在做內網穿透時遇到的一些問題

相關文章