Summary:	ASTERISK-28211: chan_pjsip: Path header is not used with PJSIP_DIAL_CONTACTS
Reporter:	Sebastian Denz (denz)	Labels:	pjsip
Date Opened:	2018-12-17 06:09:58.000-0600	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Channels/chan_pjsip Resources/res_pjsip
Versions:	16.0.0	Frequency of Occurrence	Constant
Related Issues:	is duplicated by ASTERISK-28291 res_pjsip_path: Not applied on OPTIONS requests is duplicated by ASTERISK-28876 Wrong next hop for INVITEs with PJSIP and PATH
Environment:	Asterisk 16.0.1 on Debian 9	Attachments:	( 0) asterisk_path_issue_cli_log.txt ( 1) siptrace.txt
Description:	I am using Kamailio as Edgeproxy between my phones and Asterisk. In this scenario Kamailio terminates a TLS Connections, checks the client certificate and sets a custom Header to help Asterisk to identify the corresponding endpoint. Which is working fine so far. As Asterisk is not able to reach the phones directly, the Path Header is set by Kamailio. The AORs for the phones have support_path set to true. A few days before, the whole setup was running fine, but in the meantime the Handling of the Path-Header stopped working. I am not aware of any relevant changes in the setup and i tried to rollback to a version which was known to work. But when calling from one phone to another, Asterisk does not evaluate the Path-Header for the target endpoint anymore... This is the case for INVITE Routing using Dial(), sending OPTIONS is working fine and the Path leads to a set Route-Header in the outgoing OPTIONS packet... For debugging purposes i added some more logging in res_pjsip_path.c to see when the functions are called in the CLI. Due to that i can tell, that the contact Parameter for path_outgoing_request() is NULL in that case... Unfortunately i am not able to dig deeper to find the reason for that. Seems to be the same like https://community.asterisk.org/t/wrong-d-uri-for-invites-with-pjsip-and-path/74079 But at least at the moment the problem is reproducable.. So i would appreciate any hints for further debugging or fixes of course! ;)
Comments:	By: Asterisk Team (asteriskteam) 2018-12-17 06:10:00.694-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: Sebastian Denz (denz) 2018-12-17 06:16:07.376-0600 regarding asterisk_path_issue_cli_log.txt * added more debug output to res_pjsip_path.c * extended cli_contact_print_body() to print the path as last column By: Joshua C. Colp (jcolp) 2018-12-17 06:41:50.414-0600 What is the dialplan? Are you using PJSIP_DIAL_CONTACTS? I don't believe that function currently has a mechanism for returning/using the Path information. By: Sebastian Denz (denz) 2018-12-17 06:55:52.663-0600 You are right! My Dialplan is as simple as this at the moment: {noformat} exten => 123,1,Dial(${PJSIP_DIAL_CONTACTS(denzs)}) same => n,Hangup() {noformat} Removing PJSIP_DIAL_CONTACTS does the trick... :-/ What a pity, is was looking forward to be able to have multiple contacts and use the edge proxy without calling various dedicated endpoints so much :-/ But anyhow thank you very much! By: Sebastian Denz (denz) 2018-12-17 07:18:46.647-0600 Do you see any change that this gets implemented in Asterisk 16 or would that be to big of a change for the LTS version? Dont get me wrong, i am not saying "please implement it fast and for free..." I am willing to pay a developer which is more familiar with the internals of asterisk to implement it, but it would be interesting if it would be possible to get that change merged in the branch of version 16... By: Joshua C. Colp (jcolp) 2018-12-17 08:01:32.635-0600 I don't see why it wouldn't be placed into 13 and 16. By: Sebastian Denz (denz) 2020-03-26 03:24:41.347-0500 As the developer i was thinking of, is not available for the next time i am open to any suggestions or offers on how to get this fixed/implemented... :-/ By: Serge (zeusca) 2020-05-07 11:54:09.485-0500 attaching sip trace example, with hopes that it helps in solving this problem, which is a deal breaker for any install of Asterisk running PJSIP with a front-facing proxy @Sebastian willing to chip in to have someone fix this major bug, lol By: Serge (zeusca) 2021-03-16 19:49:55.553-0500 It's been 2+ yrs now. I get that it's been tagged as "minor" severity but is there a timeline to fix this? Thanks in advance. By: Joshua C. Colp (jcolp) 2021-03-17 03:49:32.644-0500 There is no timeline. By: Vinicius Ruoso (vkruoso) 2021-03-24 16:19:15.471-0500 This is also the case for calls not started with the Dial application, like a queue extension. https://community.asterisk.org/t/pjsip-path-module-issues/88046/12 By: Serge (zeusca) 2022-06-14 10:06:36.149-0500 3+ yrs and counting By: Serge (zeusca) 2023-03-02 16:34:58.617-0600 Looks like this years long issue has been resolved within another just recently opened MAJOR severity case: https://issues.asterisk.org/jira/browse/ASTERISK-30100 Do you think that now the fix can be backported to at least Asterisk 16? Thanks. By: Joshua C. Colp (jcolp) 2023-03-02 17:45:19.992-0600 Asterisk 16 is in security fix only status. It does not receive bug fixes.