Perform joint debugging with a camera of a certain manufacturer for the national standard gb28181. If you encounter some problems, please record it here
The situation is like this. The feature of this project is to use the national standard gb28181 as the communication protocol between the camera and the platform, and the platform is the superior on the public network, there is a public network ip, the camera is the subordinate, in the internal network, To communicate with the platform on the public network through the gateway. There are test cameras in the internal network of our company and the other's manufacturer, and both can be connected to the external network. After the environment is set up, the cameras at the two locations are registered with the platform on the public website.
The first problem I found was that the camera on the other party's network could not register successfully, but the camera on our network could be successful. The configuration information on both sides was correct. Later, it was found that the manufacturer’s camera did not add the rport parameter to the via when requesting registration.
Because our project is from the internal network to the external network, and then from the external network to the internal network, there is a case of internal network penetration, and the port mapped from the internal network to the external network will change, so there must be a set of mechanisms for penetration, because The national standard is based on the sip protocol. The rport mechanism is used for intranet penetration under sip. If the request is sent without the rport logo, this mechanism is not enabled, so problems will occur when the external network is connected to the internal network. Because the head of the internal network will pass through a gateway when sending information to the public network, the gateway will use the nat protocol to convert the port of the internal network. The port mapped to the public network may be the same or inconsistent with the internal network! And this port happens to be the same in our network! And the other party's inconsistency.
Since the platform on the public network did not find the rport parameter in the registration information of the camera, when returning the registration response, it directly used the camera intranet port information in the request, which directly caused the camera in the other party’s network to not get the registration success information. However, because our side was mapped to the same port, we were able to register after receiving the registration response.
The following is the log printed in osip, which reflects this problem. The received port is 17961, but it is sent to 39512 on the intranet.
-
| 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:[email protected]: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:[email protected]:39512> -
Call-ID: [email protected] -
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: [email protected] -
CSeq: 548 REGISTER -
User-Agent: JUNTAI SIP UAS/1.0 -
Date: 2019-06-29T21:52:10.001 -
Expires: 3600 -
Content-Length: 0
Secondly, there are also problems when the camera gets the stream and closes the stream to send BYE. As follows, when returning ack and bye, the address found is wrong, it is the IP or address of the intranet.
-
| 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:[email protected]:18669 SIP/2.0 -
Via: SIP/2.0/UDP 192.168.200.2:5066;rport;branch=z9hG4bK1721778447 -
From: <sip:[email protected]:5066>;tag=332179470 -
To: <sip:[email protected]:18669> -
Call-ID: 385231458 -
CSeq: 4 INVITE -
Contact: <sip:[email protected]: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:[email protected]:5066>;tag=332179470 -
To: <sip:34020000001320000205@340200>;tag=717142644a97aa49 -
Contact: <sip:[email protected]: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:[email protected]:53922 SIP/2.0 -
Via: SIP/2.0/UDP 192.168.200.2:5066;rport;branch=z9hG4bK396241289 -
From: <sip:[email protected]:5066>;tag=332179470 -
To: <sip:34020000001320000205@340200>;tag=717142644a97aa49 -
Call-ID: 385231458 -
CSeq: 4 ACK -
Contact: <sip:[email protected]: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:[email protected]:53922 SIP/2.0 -
Via: SIP/2.0/UDP 192.168.200.2:5066;rport;branch=z9hG4bK1886964964 -
From: <sip:[email protected]:5066>;tag=332179470 -
To: <sip:34020000001320000205@340200>;tag=717142644a97aa49 -
Call-ID: 385231458 -
CSeq: 5 BYE -
Contact: <sip:[email protected]:5066> -
Max-Forwards: 70 -
User-Agent: JUNTAI SIP UAS/1.0 -
Content-Length: 0