Hello.
When migrated extensions from chan_sip to pjsip I noticed the different behavior when endpoints and Asterisk is behind NAT. When used chan_sip I didn’t need to create port-forwarding rtp ports range for asterisk on NAT device it behind is - everything worked without it. Using debug, I discovered that incoming traffic from clients to asterisk was provided by nat - translation created by outgoing traffic from asterisk to client.
But, it seems, the pjsip behavior when media session is created is different and it needs creation of port-forwarding on NAT device.
Can someone explain this difference between these sip - channels?
You need to be more specific about the settings. It would also help to have pcap traces of chan_sip and pjsip SIP sessions.
Here is debug of two sip - channels.
CHAN_SIP
<— SIP read from TLS:XXX.XXX.XXX.XXX:40555 —>
INVITE sip:564594@YYY.YYY.YYY.YYY SIP/2.0
Via: SIP/2.0/TLS 10.50.112.157:4915;branch=z9hG4bKC4FnaTrkbh9Vf1eU;rport
Contact: sip:101005@XXX.XXX.XXX.XXX:40555;transport=tls
Max-Forwards: 70
From: sip:101005@YYY.YYY.YYY.YYY;tag=36DCA8080C78F0F62B067CD843DD5E85
Allow: OPTIONS, INVITE, ACK, REFER, CANCEL, BYE, NOTIFY, MESSAGE
Supported: replaces, path
To: sip:564594@YYY.YYY.YYY.YYY
Content-Type: application/sdp
Call-ID: 8E347714EC7A8C08B8BF5567F7DBD79A3C6C9A91
CSeq: 2 INVITE
Authorization: Digest username=“101005”,realm=“asterisk”,algorithm=MD5,uri=“sip:564594@YYY.YYY.YYY.YYY”,nonce=“63118c1a”,response=“e020a57cab9e31b463a00719a7683e3d”
User-Agent: Groundwire/5.2.11 (build 1209152; Android 7.0; armeabi-v7a)
Content-Length: 546v=0
o=- 9853439349 49999 IN IP4 172.26.170.170
s=fhynyvb
c=IN IP4 XXX.XXX.XXX.XXX
t=0 0
m=audio 40436 RTP/SAVP 103 102 3 0 8 9 101
a=rtcp:40481
a=rtpmap:101 telephone-event/8000
a=rtpmap:102 ILBC/8000
a=rtpmap:103 opus/48000/2
a=fmtp:101 0-15
a=fmtp:102 mode=30
a=fmtp:103 maxplaybackrate=8000;maxaveragebitrate=15500;useinbandfec=1;usedtx=1
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:xj9LI00p4Hf8M+HpNtJVzoznDOdMYo9zsqACwi55
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:x6yUahOWZHKEfZE+cEjKUNbaVtqXKCP9MqvRb42q
a=ptime:30
a=sendrecv<------------->
— (14 headers 17 lines) —
Sending to XXX.XXX.XXX.XXX:40555 (NAT)
Using INVITE request as basis request - 8E347714EC7A8C08B8BF5567F7DBD79A3C6C9A91
Found peer ‘101005’ for ‘101005’ from XXX.XXX.XXX.XXX:40555
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
Found RTP audio format 103
Found RTP audio format 102
Found RTP audio format 3
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 9
Found RTP audio format 101
Found audio description format telephone-event for ID 101
Found audio description format ILBC for ID 102
Found audio description format opus for ID 103
Capabilities: us - (opus), peer - audio=(ulaw|gsm|alaw|g722|ilbc|opus)/video=(nothing)/text=(nothing), combined - (opus)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port XXX.XXX.XXX.XXX:40436
Looking for 564594 in from-internal (domain YYY.YYY.YYY.YYY)
sip_route_dump: route/path hop: sip:101005@XXX.XXX.XXX.XXX:40555;transport=tls<— Transmitting (NAT) to XXX.XXX.XXX.XXX:40555 —>
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 10.50.112.157:4915;branch=z9hG4bKC4FnaTrkbh9Vf1eU;received=XXX.XXX.XXX.XXX;rport=40555
From: sip:101005@YYY.YYY.YYY.YYY;tag=36DCA8080C78F0F62B067CD843DD5E85
To: sip:564594@YYY.YYY.YYY.YYY
Call-ID: 8E347714EC7A8C08B8BF5567F7DBD79A3C6C9A91
CSeq: 2 INVITE
Server: FPBX-14.0.5.25(13.22.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: sip:564594@YYY.YYY.YYY.YYY:5061;transport=tls
Content-Length: 0<------------>
== Spawn extension (vip, 564594, 1) exited non-zero on ‘PJSIP/564594-00000138’
== Using SIP RTP Audio TOS bits 184
== Using SIP RTP Audio CoS mark 5<— Transmitting (NAT) to XXX.XXX.XXX.XXX:40555 —>
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 10.50.112.157:4915;branch=z9hG4bKC4FnaTrkbh9Vf1eU;received=XXX.XXX.XXX.XXX;rport=40555
From: sip:101005@YYY.YYY.YYY.YYY;tag=36DCA8080C78F0F62B067CD843DD5E85
To: sip:564594@YYY.YYY.YYY.YYY;tag=as77e43a57
Call-ID: 8E347714EC7A8C08B8BF5567F7DBD79A3C6C9A91
CSeq: 2 INVITE
Server: FPBX-14.0.5.25(13.22.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: sip:564594@YYY.YYY.YYY.YYY:5061;transport=tls
P-Asserted-Identity: “564594” sip:564594@YYY.YYY.YYY.YYY
Content-Length: 0<------------>
Audio is at 12844
Adding codec opus to SDP
Adding non-codec 0x1 (telephone-event) to SDP<— Transmitting (NAT) to XXX.XXX.XXX.XXX:40555 —>
SIP/2.0 183 Session Progress
Via: SIP/2.0/TLS 10.50.112.157:4915;branch=z9hG4bKC4FnaTrkbh9Vf1eU;received=XXX.XXX.XXX.XXX;rport=40555
From: sip:101005@YYY.YYY.YYY.YYY;tag=36DCA8080C78F0F62B067CD843DD5E85
To: sip:564594@YYY.YYY.YYY.YYY;tag=as77e43a57
Call-ID: 8E347714EC7A8C08B8BF5567F7DBD79A3C6C9A91
CSeq: 2 INVITE
Server: FPBX-14.0.5.25(13.22.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: sip:564594@YYY.YYY.YYY.YYY:5061;transport=tls
Content-Type: application/sdp
Content-Length: 412v=0
o=root 88171188 88171188 IN IP4 YYY.YYY.YYY.YYY
s=Asterisk PBX 13.22.0
c=IN IP4 YYY.YYY.YYY.YYY
t=0 0
m=audio 12844 RTP/SAVP 103 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:dx2zyMH+ljqdvRdVgJBnfH+jOsgANjj3dCdhOhZv
a=rtpmap:103 opus/48000/2
a=fmtp:103 maxplaybackrate=8000;maxaveragebitrate=15500;useinbandfec=1;usedtx=1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:20
a=sendrecv<------------>
Sent RTP packet to XXX.XXX.XXX.XXX:40436 (type 103, seq 012162, ts 000960, len 000041)
Sent RTP packet to XXX.XXX.XXX.XXX:40436 (type 103, seq 012163, ts 001920, len 000036)
Sent RTP packet to XXX.XXX.XXX.XXX:40436 (type 103, seq 012164, ts 002880, len 000033)
Sent RTP packet to XXX.XXX.XXX.XXX:40436 (type 103, seq 012165, ts 003840, len 000033)
Sent RTP packet to XXX.XXX.XXX.XXX:40436 (type 103, seq 012166, ts 004800, len 000036)
Sent RTP packet to XXX.XXX.XXX.XXX:40436 (type 103, seq 012167, ts 005760, len 000034)
Sent RTP packet to XXX.XXX.XXX.XXX:40436 (type 103, seq 012168, ts 006720, len 000031)
Sent RTP packet to XXX.XXX.XXX.XXX:40436 (type 103, seq 012169, ts 007680, len 000034)
Sent RTP packet to XXX.XXX.XXX.XXX:40436 (type 103, seq 012170, ts 008640, len 000036)
Sent RTP packet to XXX.XXX.XXX.XXX:40436 (type 103, seq 012171, ts 009600, len 000030)
Sent RTP packet to XXX.XXX.XXX.XXX:40436 (type 103, seq 012172, ts 010560, len 000029)
Got RTP packet from XXX.XXX.XXX.XXX:40436 (type 103, seq 009519, ts 3387734925, len 000007)
PJSIP
<— Received SIP request (1459 bytes) from TLS:XXX.XXX.XXX.XXX:40525 —>
INVITE sip:564594@YYY.YYY.YYY.YYY:5161 SIP/2.0
Via: SIP/2.0/TLS 10.50.112.157:6297;branch=z9hG4bKFfRq63CbzpuyZUzA;rport
Contact: sip:504596@XXX.XXX.XXX.XXX:40525;transport=tls
Max-Forwards: 70
From: sip:504596@YYY.YYY.YYY.YYY:5161;tag=5E1C1197C091A88B4550F6C4962C5FBD
Allow: OPTIONS, INVITE, ACK, REFER, CANCEL, BYE, NOTIFY, MESSAGE
Supported: replaces, path
To: sip:564594@YYY.YYY.YYY.YYY:5161
Content-Type: application/sdp
Call-ID: B7430025F4C729CEC29E081344BFA1743D5323ED
CSeq: 2 INVITE
Authorization: Digest username=“504596”,realm=“asterisk”,algorithm=md5,uri=“sip:564594@YYY.YYY.YYY.YYY:5161”,nonce=“1555404945/1717eedad6801809afb45c187b3ae997”,opaque=“7085e1204e678ceb”,qop=auth,cnonce=“XLWYkBEVUTpcp4APaKhRvpL6”,nc=00000001,response=“7478d9430a475bc859ef982c49813842”
User-Agent: Groundwire/5.2.11 (build 1209152; Android 7.0; armeabi-v7a)
Content-Length: 546v=0
o=- 7569862783 36168 IN IP4 172.26.170.170
s=ttfryph
c=IN IP4 XXX.XXX.XXX.XXX
t=0 0
m=audio 40458 RTP/SAVP 0 8 103 102 3 9 101
a=rtcp:40433
a=rtpmap:101 telephone-event/8000
a=rtpmap:102 ILBC/8000
a=rtpmap:103 opus/48000/2
a=fmtp:101 0-15
a=fmtp:102 mode=30
a=fmtp:103 maxplaybackrate=8000;maxaveragebitrate=15500;useinbandfec=1;usedtx=1
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:jGt7ytu5mmTVxttM3+jbQq7OLs6psqCyFBpYBVZM
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:oysOw1d72O3JSM0WhBkUla3rLeuPAKneJW4JwACx
a=ptime:30
a=sendrecv== Setting global variable ‘SIPDOMAIN’ to ‘YYY.YYY.YYY.YYY’
<— Transmitting SIP response (365 bytes) to TLS:XXX.XXX.XXX.XXX:40525 —>
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 10.50.112.157:6297;rport=40525;received=XXX.XXX.XXX.XXX;branch=z9hG4bKFfRq63CbzpuyZUzA
Call-ID: B7430025F4C729CEC29E081344BFA1743D5323ED
From: sip:504596@YYY.YYY.YYY.YYY;tag=5E1C1197C091A88B4550F6C4962C5FBD
To: sip:564594@YYY.YYY.YYY.YYY
CSeq: 2 INVITE
Server: FPBX-14.0.5.25(13.22.0)
Content-Length: 0== Using SIP RTP Audio TOS bits 184
== Using SIP RTP Audio CoS mark 5
== Spawn extension (vip, 564594, 1) exited non-zero on ‘PJSIP/564594-0000013a’
== Using SIP RTP Audio TOS bits 184
== Using SIP RTP Audio CoS mark 5
<— Transmitting SIP response (634 bytes) to TLS:XXX.XXX.XXX.XXX:40525 —>
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 10.50.112.157:6297;rport=40525;received=XXX.XXX.XXX.XXX;branch=z9hG4bKFfRq63CbzpuyZUzA
Call-ID: B7430025F4C729CEC29E081344BFA1743D5323ED
From: sip:504596@YYY.YYY.YYY.YYY;tag=5E1C1197C091A88B4550F6C4962C5FBD
To: sip:564594@YYY.YYY.YYY.YYY;tag=a4caf575-0039-4c3e-a865-a9d1a1c93929
CSeq: 2 INVITE
Server: FPBX-14.0.5.25(13.22.0)
Contact: sip:YYY.YYY.YYY.YYY:5161;transport=TLS
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
P-Asserted-Identity: “564594” sip:564594@YYY.YYY.YYY.YYY
Content-Length: 0== SRTCP unprotect failed because of unable to perform desired validation
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
== Channel ‘SIP/Berofix-00008907’ jumping out of macro ‘prefix-Berofix’
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
== Spawn extension (branch-568XXX, 568021, 1) exited non-zero on ‘SIP/KAMIANSKE-00008908’
[2019-04-16 11:55:48] WARNING[13307]: chan_sip.c:3781 __sip_xmit: sip_xmit of 0x7f099540a0e0 (len 619) to 91.202.133.30:52836 returned -2: Broken pipe
[2019-04-16 11:55:48] ERROR[13307]: chan_sip.c:4270 __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data
<— Transmitting SIP response (1167 bytes) to TLS:XXX.XXX.XXX.XXX:40525 —>
SIP/2.0 200 OK
Via: SIP/2.0/TLS 10.50.112.157:6297;rport=40525;received=XXX.XXX.XXX.XXX;branch=z9hG4bKFfRq63CbzpuyZUzA
Call-ID: B7430025F4C729CEC29E081344BFA1743D5323ED
From: sip:504596@YYY.YYY.YYY.YYY;tag=5E1C1197C091A88B4550F6C4962C5FBD
To: sip:564594@YYY.YYY.YYY.YYY;tag=a4caf575-0039-4c3e-a865-a9d1a1c93929
CSeq: 2 INVITE
Server: FPBX-14.0.5.25(13.22.0)
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Contact: sip:YYY.YYY.YYY.YYY:5161;transport=TLS
Supported: 100rel, timer, replaces, norefersub
P-Asserted-Identity: “564594” sip:564594@YYY.YYY.YYY.YYY
Content-Type: application/sdp
Content-Length: 456v=0
o=- 3274895487 36170 IN IP4 YYY.YYY.YYY.YYY
s=Asterisk
c=IN IP4 YYY.YYY.YYY.YYY
t=0 0
m=audio 19214 RTP/SAVP 103 0 8 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:6kLqNe4WtcSUKIPRhsVWFyMuwCuqOMI8RGGtzCEw
a=rtpmap:103 opus/48000/2
a=fmtp:103 maxplaybackrate=8000;maxaveragebitrate=15500;useinbandfec=1;usedtx=1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:20
a=sendrecvGot RTP packet from XXX.XXX.XXX.XXX:40458 (type 00, seq 025709, ts 224297534, len 000160)
Got RTP packet from XXX.XXX.XXX.XXX:40458 (type 00, seq 025710, ts 224297694, len 000160)
Got RTP packet from XXX.XXX.XXX.XXX:40458 (type 00, seq 025711, ts 224297854, len 000160)
Got RTP packet from XXX.XXX.XXX.XXX:40458 (type 00, seq 025712, ts 224298014, len 000160)
Got RTP packet from XXX.XXX.XXX.XXX:40458 (type 00, seq 025713, ts 224298174, len 000160)
Got RTP packet from XXX.XXX.XXX.XXX:40458 (type 00, seq 025714, ts 224298334, len 000160)
Sent RTP packet to XXX.XXX.XXX.XXX:40458 (type 00, seq 025205, ts 000032, len 000170)
It’s already clear the difference of behavior each of them.
As we can see, “chan_sip” begins to send RTP to client first at the “Session Progress” stage. Exactly at this time NAT - translation is created and client RTP is accessed to the Asterisk. No port-forwarding needs.
At the same time, “pjsip” expects RTP from client first before sending toward it. No client’s NAT-rules to be accessed to the Asterisk. Need a port-forwarding.
There is a question about that. Pjsip without “Session progress” is its standart behavior?
You are not guaranteed to receive a 183 Session Progress in SIP. There are also configuration options in chan_sip which can alter/cause this, resulting in it happening. They may not exist in chan_pjsip.
As for forwarding media - PJSIP uses the same media stack as SIP and behaves the same in that regard. The only difference is that chan_sip may be generating media locally during that 183, while chan_pjsip doesn’t and just acts as a forwarder once answered.
1 Like
Thanks a lot for your reply. This
The only difference is that chan_sip may be generating media locally during that 183, while chan_pjsip doesn’t and just acts as a forwarder once answered
confirmed my assumptions and I’ve got answer I expected.
It looks as if you are using FreePBX. Does that mean that you let the system convert the settings from chan_sip to pjsip automatically? If yes, did you check what the Berofix macro is actually doing? With my setups I usually get 180 and 183 (and ringback works most of the time with pjsip), so I wonder why there is no session progress here.
Assuming that you are probably using a BeroNET device and based on your typos, I guess you are sitting in Germany. In case you are using a German Telekom product, would you be so kind and capture a pcap trace on the WAN side and evaluate the re-REGISTER attempts? You need to capture for 2-6 hours to find what I am looking for. In short, I have a couple of German Telekom ALL-IP connections that are now and then unable to register, though neither the IP nor the credentials change, or the same IP works a little bit later. I think that German Telekom has a problem here (or I made a major and/or stupid mistake).
“Berofix” turned out ocassionaly in that dump and belongs to a different dialog.
I use sip-gateway Berofix, but I’m not from Germany, so unfortunately, I won’t be able to help you, sorry.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.