PJSIP Path module issues

Hi!

I have an issue with an Asterisk behind Kamailio when using the res_pjsip_path module. My intention is that Asterisk stores the Path information on the Contact from the REGISTER message, and when a call is created to that contact, it will also send that Path information so the proxy can route the message accordingly.

The issue is that Asterisk is not sending that back on an INVITE to the contact.

Below the messages:

The REGISTER that is okayed:

2021/03/24 15:18:00.974575 10.158.15.239:5080 -> 10.34.0.130:5080
REGISTER sip:asterisk-pabx-0002:5080 SIP/2.0
Via: SIP/2.0/UDP 10.158.15.239:5080;branch=z9hG4bK055b.ec45c9bc1bb8be0754621cd87c4f2c6f.0
Via: SIP/2.0/WSS 14r83na1gc83.invalid;rport=51717;received=177.xxx.xxx.xx;branch=z9hG4bK4344189
To: <sip:1003@pabx-0002.xxx.com>
From: <sip:1003@pabx-0002.xxx.com>;tag=ntj9v5cevo
CSeq: 3 REGISTER
Call-ID: 8dbf08msdlji3ad9ai4n
Max-Forwards: 69
Authorization: Digest algorithm=MD5, .........
iiff6d", nc=00000001
Contact: <sip:0835h32r@14r83na1gc83.invalid;transport=ws>;expires=600
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound, path, gruu
User-Agent: SIP.js/0.17.1
Content-Length: 0
Path: <sip:10.158.15.239:5080;lr;r2=on>
Path: <sip:34.xxx.xxx.230:443;transport=ws;lr;r2=on>

INVITE:

2021/03/24 15:19:09.720938 10.34.0.130:5080 -> 10.158.15.239:5080
INVITE sip:0835h32r@10.158.15.239:5080 SIP/2.0
Via: SIP/2.0/UDP 10.158.0.36:5080;rport;branch=z9hG4bKPj63efe1d9-93c9-4b7d-8535-4f9010f5b971
From: "User" <sip:1002@10.34.0.130>;tag=5422bfc8-e1d8-49fe-bc04-6ce153d4b754
To: <sip:0835h32r@10.158.15.239>
Contact: <sip:asterisk@10.158.0.36:5080>
Call-ID: 7ad68fe2-4006-43a9-9f93-13d78550b725
CSeq: 7968 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 17.6.0
Content-Type: application/sdp
Content-Length:   901

v=0
o=- 129955850 129955850 IN IP4 10.34.0.130
s=Asterisk
c=IN IP4 10.34.0.130
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE audio-0
m=audio 26240 UDP/TLS/RTP/SAVPF 107 8 0 9 101
a=connection:new
a=setup:actpass
a=fingerprint:SHA-256 2F:94:09:A9:71:30:05:04:5C:50:56:CA:C1:51:44:4B:A6:28:9B:69:29:87:8D:7B:52:6E:56:37:CD:45:37:32
a=ice-ufrag:4e126cfa1816a77c445dae9d6fadc1ae
a=ice-pwd:54aac5346a24c5d21cedb0b536f8ec5d
a=candidate:Ha220082 1 UDP 2130706431 10.34.0.130 26240 typ host
a=rtpmap:107 opus/48000/2
a=fmtp:107 useinbandfec=1
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:20
a=sendrecv
a=rtcp-mux
a=ssrc:484386811 cname:71933c1a-d697-4080-8cba-123971794c8e
a=msid:7e90bf6f-08dd-4fb9-8162-81855b03bfb7 52535d77-c7ac-47b4-87c5-52d702ae316a
a=rtcp-fb:* transport-cc
a=mid:audio-0

Any ideas?

Thanks,
Vinicius

How are you dialing the endpoint in the dialplan? I ask because there is an open issue[1].

[1] [ASTERISK-28211] chan_pjsip: Path header is not used with PJSIP_DIAL_CONTACTS - Digium/Asterisk JIRA

Hi @jcolp , thanks for the fast answer. I’m not calling using the Dial application. There is an external INVITE from another extension calling to a queue, where that other extension is a part of. It seems that bug is only related to a call start via the dialplan application, correct?

Yes, but you’d need to state how the agent is called from the queue.

You’re also running a security fix only version of Asterisk, so things may have changed since too.

Hello,

Asterisk need knows Kamailio support Path Protocol. My Kamailio configuration:

append_hf(“Supported: path\r\n”);

add_path();

rewritehostport(“IPAsterisk:5060”);

forward();

Regards

Awesome! Thanks for the feedback. Will try that header and will also try to update Asterisk to 18. Will share the findings.

This added the Header in the request, but Asterisk is still not sending that back on the INVITE. Is there any way to see in Asterisk if the path was stored?

It is stored with the Contact, by default that is in the Asterisk database and can be viewed in its entirety using “database show”.

Cool. Did not know that command! Thanks!

Looks like Asterisk is saving it:

/registrar/contact/1002;@d43974c7dc9f6364db26b717614d6cb9: {"via_addr":"ftopddmia60r.invalid","qualify_timeout":"3.000000","call_id":"pfsenii6fer2kcb2sc6d","reg_server":"","prune_on_boot":"no","path":"<sip:10.158.15.239:5080;lr;r2=on>,<sip:34.xxx.xxx.230:443;transport=ws;lr;r2=on>","endpoint":"1002","via_port":"0","authenticate_qualify":"no","uri":"sip:5ttva8f9@10.158.15.239:5080;x-ast-orig-host=ftopddmia60r.invalid:0","qualify_frequency":"0","user_agent":"SIP.js/0.17.1","expiration_time":"1616605504","outbound_proxy":""}
/registrar/contact/1003;@140ff2098e288e1f639a25828798e7dd: {"via_addr":"isg9fis99pro.invalid","qualify_timeout":"3.000000","call_id":"jpi8kmorsi7q5t3nr4p2","reg_server":"","prune_on_boot":"no","path":"<sip:10.158.15.239:5080;lr;r2=on>,<sip:34.xxx.xxx.230:443;transport=ws;lr;r2=on>","endpoint":"1003","via_port":"0","authenticate_qualify":"no","uri":"sip:3ss93ud5@10.158.15.239:5080;x-ast-orig-host=isg9fis99pro.invalid:0","qualify_frequency":"0","user_agent":"SIP.js/0.17.1","expiration_time":"1616605503","outbound_proxy":""}

Maybe it is something in the contact that is not matching?

The queue I’m dialing to test this is configured like:

[queue_template](!)
musicclass=default
strategy=ringall
joinempty=yes 
leavewhenempty=no
ringinuse=no

[allext](queue_template)
member => PJSIP/1002,0
member => PJSIP/1003,0

I would expect it to be present in the INVITE given that configuration. I do not know why it is not.

Will give Asterisk 18 a try then.

Yeah, still no luck.

/registrar/contact/1002;@214255fb8445fda2645c4b5e6b91b674: {"via_addr":"0m94g079fhku.invalid","qualify_timeout":"3.000000","call_id":"2hhoim6056qlpqdlu2vh","reg_server":"","prune_on_boot":"no","path":"<sip:10.158.15.239:5080;lr;r2=on>,<sip:34.xxx.xxx.230:443;transport=ws;lr;r2=on>","endpoint":"1002","via_port":"0","authenticate_qualify":"no","uri":"sip:90649b8u@10.158.15.239:5080;x-ast-orig-host=0m94g079fhku.invalid:0","qualify_frequency":"0","user_agent":"SIP.js/0.17.1","expiration_time":"1616609239","outbound_proxy":""}
/registrar/contact/1003;@6770394fb62cd6bc3cc371964f1ec08d: {"via_addr":"eqsogrosf596.invalid","qualify_timeout":"3.000000","call_id":"d6326pdipsf62n13et88","reg_server":"","prune_on_boot":"no","path":"<sip:10.158.15.239:5080;lr;r2=on>,<sip:34.xxx.xxx.230:443;transport=ws;lr;r2=on>","endpoint":"1003","via_port":"0","authenticate_qualify":"no","uri":"sip:7qq3ks6p@10.158.15.239:5080;x-ast-orig-host=eqsogrosf596.invalid:0","qualify_frequency":"0","user_agent":"SIP.js/0.17.1","expiration_time":"1616609240","outbound_proxy":""}

Sample INVITE:

2021/03/24 17:57:42.366496 10.34.0.138:5080 -> 10.158.15.239:5080
INVITE sip:7qq3ks6p@10.158.15.239:5080 SIP/2.0
Via: SIP/2.0/UDP 10.158.0.36:5080;rport;branch=z9hG4bKPj31e6f105-3a82-4a6d-878b-3699ab9f1a46
From: "User" <sip:1002@10.34.0.138>;tag=53227101-ffbd-4294-ae6b-a6a53d105ed5
To: <sip:7qq3ks6p@10.158.15.239>
Contact: <sip:asterisk@10.158.0.36:5080>
Call-ID: a8f44c03-81fa-4454-8e9f-70f2c776da87
CSeq: 23603 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 18.2.2
Content-Type: application/sdp
Content-Length:   900

v=0
o=- 177713256 177713256 IN IP4 10.34.0.138
s=Asterisk
c=IN IP4 10.34.0.138
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE audio-0
m=audio 7606 UDP/TLS/RTP/SAVPF 107 8 0 9 101
a=connection:new
a=setup:actpass
a=fingerprint:SHA-256 0B:5E:CE:BC:E1:01:31:1C:BC:75:40:23:F8:75:21:EE:4D:92:BB:3C:18:D3:75:EB:55:4E:F9:6F:2A:7D:FA:40
a=ice-ufrag:2c37982c0766a11709a3687f0fe0a65e
a=ice-pwd:40ee708b733930981d0fe4961fa17d8f
a=candidate:Ha22008a 1 UDP 2130706431 10.34.0.138 7606 typ host
a=rtpmap:107 opus/48000/2
a=fmtp:107 useinbandfec=1
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:20
a=sendrecv
a=rtcp-mux
a=ssrc:1987502107 cname:77da8471-abd1-4108-abcd-e02bb73ea120
a=msid:598e0811-f7c4-447d-8b2c-3050fd8006d5 a946c269-fd7b-42b1-8e18-73d0332caafe
a=rtcp-fb:* transport-cc
a=mid:audio-0

Dunno then! You can file an issue[1] but there is no time frame on when it would get looked into.

[1] https://issues.asterisk.org/jira

Thanks @jcolp for your fast responses and help. I’m really intrigued by this situation.

@annusfictus do you have a working setup that you cloud share details about on this matter?

Hello,

I tested on Asterisk 13 but not on 16 or 18.

To be sure this is not a bug, call directly PJSIP extension from another PJSIP extensión and look if situation change.

Regards

Calling directly to the extension yields the same results. Going back to an unsupported version is really not an option tough.