[Home]

Summary:ASTERISK-25666: chan_sip: Path header is ignored
Reporter:Peter Baines (pbaines)Labels:
Date Opened:2016-01-07 10:20:21.000-0600Date Closed:
Priority:MajorRegression?Yes
Status:Open/NewComponents:Channels/chan_sip/Interoperability
Versions:13.6.0 Frequency of
Occurrence		Constant
Related
Issues:
is duplicated byASTERISK-25856 chan_sip: Path header is ignored (re-opening)
is related toASTERISK-27963 res_pjsip: ignore Path header on INVITE
Environment:Debian JesseAttachments:
Description:I am adding a Path header before forwarding a REGISTER onto asterisk. The problem is when asterisk recieves an INVITE it does not use the value set in the Path header, instead it sends it directly to the device.

I can replicate this on asterisk 13.6.0 and 11.13.1, however in 1.8.32.3 it works as expected (i.e. the INVITE is sent to the value set in the Path header).


To replicate:

In sip.conf I have uncommented:
{noformat}
supportpath=yes
rtsavepath=yes
{noformat}
In users.conf I have got:
{noformat}
[6000]
secret =
host=dynamic
context = default

[6001]
secret =
host=dynamic
context = default

[6002]
secret =
host=dynamic
context = default
{noformat}

In extensions.conf I have made default look like:
{noformat}
[default]
;include => demo
exten => 6000,1,Dial(SIP/6000,18)
exten => 6000,n,Hangup()

exten => 6002,1,Dial(SIP/6002,18)
exten => 6002,n,Hangup()

exten => 6001,1,Dial(SIP/6001,18)
exten => 6001,n,Hangup()
{noformat}

Below is the 6000 user REGISTER going from opensips (10.15.20.137:5060) into asterisk (192.168.68.68:5070) with the Path header.
{noformat}
U 2016/01/06 10:04:23.399170 10.15.20.137:5060 -> 192.168.68.68:5070
REGISTER sip:10.15.20.137 SIP/2.0.
Via: SIP/2.0/UDP 10.15.20.137:5060;branch=z9hG4bKcc2c.b40fb511.0.
Via: SIP/2.0/UDP 10.15.20.53:52666;received=10.15.20.53;branch=z9hG4bK-d8754z-91422161f08a7943-1---d8754z-;rport=52666.
Max-Forwards: 69.
Contact: <sip:6000@10.15.20.53:52666;rinstance=d4284982f7c18786>.
To: <sip:6000@10.15.20.137>.
From: <sip:6000@10.15.20.137>;tag=9e95da50.
Call-ID: OTQ1ZTdmZmE3OTM1ZWVkYzMzYWZiMDMzMDgyODhmOTU.
CSeq: 2 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
User-Agent: Bria 3 release 3.5.5 stamp 71243.
Content-Length: 0.
Path: <sip:10.15.20.137;lr>.
{noformat}

Below is the INVITE going from opensips to asterisk for 6000
{noformat}
U 2016/01/06 10:11:13.668929 10.15.20.137:5060 -> 192.168.68.68:5070
INVITE sip:6000@10.15.20.137;transport=UDP SIP/2.0.
Record-Route: <sip:10.15.20.137;lr;nat=yes>.
Via: SIP/2.0/UDP 10.15.20.137:5060;branch=z9hG4bK8f77.9d6ef7e7.0.
Via: SIP/2.0/UDP 188.39.51.2:35631;rport=35631;received=10.15.20.53;branch=z9hG4bK-d8754z-d46f3a0333dc5d49-1---d8754z-.
Max-Forwards: 69.
Contact: <sip:6001@10.15.20.53:35631;transport=UDP>.
To: <sip:6000@10.15.20.137;transport=UDP>.
From: <sip:6001@10.15.20.137;transport=UDP>;tag=870fdf72.
Call-ID: YWVjN2VjMDZmYmZmNjg4MTE2MzJlZGU1ZDNjZGU2NDc..
CSeq: 2 INVITE.
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE.
Content-Type: application/sdp.
Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri.
User-Agent: Z 3.3.21933 r21903.
Allow-Events: presence, kpml.
Content-Length: 237.
.
v=0.
o=Z 0 0 IN IP4 188.39.51.2.
s=Z.
c=IN IP4 188.39.51.2.
t=0 0.
m=audio 8000 RTP/AVP 3 110 8 0 98 101.
a=rtpmap:110 speex/8000.
a=rtpmap:98 iLBC/8000.
a=fmtp:98 mode=20.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
{noformat}

I would now expect asterisk to send the INVITE to the value of the Path header in the registration (10.15.20.137:5060) however it is sending the INVITE directly to the device (10.15.20.53:52666):
{noformat}
U 2016/01/06 10:11:13.671345 192.168.68.68:5070 -> 10.15.20.53:52666
INVITE sip:6000@10.15.20.53:52666;rinstance=d4284982f7c18786 SIP/2.0.
Via: SIP/2.0/UDP 192.168.68.68:5070;branch=z9hG4bK308a4ef5;rport.
Max-Forwards: 70.
Route: <sip:10.15.20.137;lr>.
From: "New User" <sip:6001@192.168.68.68:5070>;tag=as3daea415.
To: <sip:6000@10.15.20.53:52666;rinstance=d4284982f7c18786>.
Contact: <sip:6001@192.168.68.68:5070>.
Call-ID: 55202bc71f9e684d0b82c7cb2e8684ab@192.168.68.68:5070.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX 13.6.0.
Date: Wed, 06 Jan 2016 10:11:13 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
Supported: replaces, timer, path.
Content-Type: application/sdp.
Content-Length: 286.
.
v=0.
o=root 887525354 887525354 IN IP4 192.168.68.68.
s=Asterisk PBX 13.6.0.
c=IN IP4 192.168.68.68.
t=0 0.
m=audio 12356 RTP/AVP 0 8 3 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=maxptime:150.
a=sendrecv.
{noformat}
Let me know if you require any further information / traces.

Regards,
Peter
Comments:By: Asterisk Team (asteriskteam) 2016-01-07 10:20:22.496-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Rusty Newton (rnewton) 2016-01-07 21:42:15.845-0600

We require additional debug to continue with triage of your issue. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Rusty Newton (rnewton) 2016-01-07 21:43:44.990-0600

Peter please see my comment previous to this one - the debug log requested should help out. You should verify the log actually contains the "DEBUG" and "VERBOSE" messages before attaching it to the issue. ( More > Attach Files).

Attach the files as .txt for accessibility. Thanks!
By: Asterisk Team (asteriskteam) 2016-01-22 12:00:22.957-0600

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines
By: Taylor Hawkes (antiochIst) 2016-03-18 14:54:30.513-0500

I had same issue - created: ASTERISK-25856
By: james.zhu (james.zhu) 2016-08-18 03:40:02.119-0500

we test with freepbx version: Asterisk 13.9.1 built by mockbuild @ jenkins2.schmoozecom.net on a x86_64 running Linux on 2016--
-----it works with portsip webRTC gateway.
By: Daniel Pocock (daniel.pocock) 2016-12-14 07:08:03.568-0600

Peter, did you see the Path support working as expected in a previous Asterisk version?  In other words, is this issue a regression, or has it always been broken since it was introduced in v12.1.0 (ASTERISK-21084 and ASTERISK-16884)?


By: Peter Baines (pbaines) 2017-01-03 02:38:17.002-0600

Hi Daniel

I could replicate this on asterisk 13.6.0 and 11.13.1, however in 1.8.32.3 it was working as expected.

Regards,
Peter
By: Slava Bendersky (volga629) 2018-07-14 21:21:18.945-0500

Same issue is happening for PJSIP stack where INVITE not honoring Path header and adding Route header to it. That cause send call to wrong directions. That quite critical  issue
Tested on asterisk version 15.3.

````
<--- Transmitting SIP request (560 bytes) to UDP:10.30.100.41:5060 --->
OPTIONS sip:101-1033@192.168.1.150:54642;transport=tls;rinstance=13DAEF9D SIP/2.0
Via: SIP/2.0/UDP 10.30.100.27:5080;rport;branch=z9hG4bKPj99e2c53c-e091-46b1-80bc-894e989cf727
From: <sip:101-1033@10.30.100.27>;tag=31e196f7-7997-4bc1-ab3b-1013c5f33811
To: <sip:101-1033@192.168.1.150;rinstance=13DAEF9D>
Contact: <sip:101-1033@10.30.100.27:5080>
Call-ID: 4d4146b5-a0ce-4057-9d52-dc3ef3d4a526
CSeq: 1826 OPTIONS
Supported: path
Route: <sip:101-1033@10.30.100.41;transport=udp;lr>                  ---> Follow PATH header ( correct )
Max-Forwards: 70
User-Agent: Asterisk PBX 15.3.0
Content-Length:  0


<--- Transmitting SIP request (967 bytes) to UDP:192.168.1.150:55089 --->
INVITE sip:101-1033@192.168.1.150:55089;transport=tls;rinstance=13DAEF9D SIP/2.0
Via: SIP/2.0/UDP 10.30.100.27:5080;rport;branch=z9hG4bKPj90c1d0eb-a580-407d-add1-fe167790b687
From: "4039143" <sip:4039143@10.30.100.27>;tag=da646822-7ac1-48de-88a9-8efb44ab5a60
To: <sip:101-1033@192.168.1.150;rinstance=13DAEF9D>
Contact: <sip:asterisk@10.30.100.27:5080>
Call-ID: f1be92ad-f51d-43ec-ada3-7064cb1bf513
CSeq: 30947 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, path
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 15.3.0
Content-Type: application/sdp
Content-Length:   235

v=0
o=- 779031891 779031891 IN IP4 10.30.100.27
s=Asterisk
c=IN IP4 10.30.100.27
t=0 0
m=audio 14202 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

````
By: Richard Mudgett (rmudgett) 2018-07-15 09:47:43.705-0500

[~volga629] Please open a *new* issue and follow the issue reporting guidelines \[1] with appropriate debug logs attached to the issue.  The cause of your issue with the PJSIP stack cannot possibly be the same since the two channel drivers use *entirely* different SIP stacks.  Also chan_sip is community supported while chan_pjsip receives active development.

\[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines
By: Peter Baines (pbaines) 2018-07-15 09:49:42.766-0500

Richard, the issue still stands and you can see the debug logs from the original post.
By: Richard Mudgett (rmudgett) 2018-07-15 10:22:40.286-0500

[~pbaines] *Your* issue is against *chan_sip* and yes it has not been resolved.  I saw the reporter for the duplicate issue (ASTERISK-25856) attached a patch to fix it but has not followed through to get it into the code base.  Remember, chan_sip is entirely community supported.  [~volga629] is reporting a similar problem but against the *PJSIP* stack which receives active development and will have a different fix.
By: Slava Bendersky (volga629) 2018-07-15 21:28:56.277-0500

I opened separate issue as suggested.

ASTERISK-27963
By: Daniel Pocock (daniel.pocock) 2018-07-16 13:47:41.244-0500

Just out of interest, would JIRA sub-tasks be useful for issues like this, e.g. one sub-task for chan_sip and another sub-task for chan_pjsip?

How you use the sub-task feature depends a little bit on the workflow you want as developers but it also impacts the experience for users.
By: Joshua C. Colp (jcolp) 2018-07-16 14:37:28.618-0500

We have never ever had good results with sub-tasks and we don't use them on here. Separate issues that are linked are what we do.
By: Yury Kirsanov (lt_flash) 2022-06-08 03:50:23.314-0500

Hi,
Same issue with Asterisk 18.7.0 and 18.12.1, when dialing to SIP trunk Asterisk ignores PATH header and sends INVITE directly to the contact. I'm not using PJSIP_DIAL_CONTACTS, I was doing:

exten => n,1,Dial(PJSIP/1008@T273842,30)

No Route: headers were added and request went straight to Contact's R-URI.

[Jun 8 18:31:43] – Executing [s@sip-trunk-844-151:7] Dial("PJSIP/792543-00000045", "PJSIP/1008@T273842,30") in new stack
[Jun 8 18:31:43] – Called PJSIP/1008@T273842
[Jun 8 18:31:43] == Using SIP RTP Audio TOS bits 184
[Jun 8 18:31:43] == Using SIP RTP Audio TOS bits 184 in TCLASS field.
[Jun 8 18:31:43] == Using SIP RTP Audio CoS mark 5
[Jun 8 18:31:43] <--- Transmitting SIP request (1061 bytes) to TCP:185.97.201.93:3766 --->
[Jun 8 18:31:43] INVITE sip:1008@185.97.201.93:3766;transport=TCP;rinstance=97f9c0e29d88ed2e SIP/2.0
[Jun 8 18:31:43] Via: SIP/2.0/TCP 103.242.182.172:7060;rport;branch=z9hG4bKPja75858f5-3c01-4270-a281-6d321d12af76;alias
[Jun 8 18:31:43] From: "3" <sip:1006@103.242.182.172>;tag=caca7af2-f20b-4a67-a929-c0cb56dd5cbc
[Jun 8 18:31:43] To: <sip:1008@185.97.201.93;rinstance=97f9c0e29d88ed2e>
[Jun 8 18:31:43] Contact: <sip:asterisk@103.242.182.172:7060;transport=TCP>
[Jun 8 18:31:43] Call-ID: 2acded7f-d758-4149-9f90-8cae79a5fec8
[Jun 8 18:31:43] CSeq: 5950 INVITE
[Jun 8 18:31:43] Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
[Jun 8 18:31:43] Supported: 100rel, replaces, norefersub, histinfo
[Jun 8 18:31:43] Max-Forwards: 70
[Jun 8 18:31:43] User-Agent: mPBX/1.9.21
[Jun 8 18:31:43] Content-Type: application/sdp
[Jun 8 18:31:43] Content-Length: 349
[Jun 8 18:31:43]
[Jun 8 18:31:43] v=0
[Jun 8 18:31:43] o=mPBX/1.9.21 259858751 259858751 IN IP4 103.242.182.172
[Jun 8 18:31:43] s=mPBX/1.9.21
[Jun 8 18:31:43] c=IN IP4 103.242.182.172
[Jun 8 18:31:43] t=0 0
[Jun 8 18:31:43] m=audio 16734 RTP/AVP 0 8 9 18 101
[Jun 8 18:31:43] a=rtpmap:0 PCMU/8000
[Jun 8 18:31:43] a=rtpmap:8 PCMA/8000
[Jun 8 18:31:43] a=rtpmap:9 G722/8000
[Jun 8 18:31:43] a=rtpmap:18 G729/8000
[Jun 8 18:31:43] a=fmtp:18 annexb=no
[Jun 8 18:31:43] a=rtpmap:101 telephone-event/8000
[Jun 8 18:31:43] a=fmtp:101 0-16
[Jun 8 18:31:43] a=ptime:20
[Jun 8 18:31:43] a=maxptime:150
[Jun 8 18:31:43] a=sendrecv

Database contains correct contact:

/registrar/contact/T273842;@a1886a275e520d115781af8c62e6a7db:

{"via_addr":"192.168.1.107","qualify_timeout":"3.000000","call_id":"ulFj_sEMIZ3ASt4t2M7udA..","reg_server":"au-mpbx-dev-cluster2","prune_on_boot":"no","path":"<sip:10.22.23.160;r2=on;lr>,<sip:103.242.182.180:7060;transport=tcp;r2=on;lr>","endpoint":"T273842","via_port":"63450","authenticate_qualify":"yes","uri":"sip:T273842@185.97.201.93:3766;transport=TCP;rinstance=97f9c0e29d88ed2e","qualify_frequency":"15","user_agent":"Zoiper rv2.10.8.2","expiration_time":"1654678226","outbound_proxy":""}

Contact is available:

 Contact:  T273842/sip:T273842@185.97.201.93:3766;transpo a1886a275e Avail       291.874