Summary:	ASTERISK-28406: PJSIP compose invalid request-URI in ACK for re-INVITE
Reporter:	Dang Thanh Loi (loi.dangthanh@gmail.com)	Labels:	pjsip
Date Opened:	2019-05-07 05:13:23	Date Closed:	2019-05-16 08:16:56
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	pjproject/pjsip
Versions:	15.7.2	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) pjsip.conf ( 1) verbose.0
Description:	I'm working with `moh_passthrough = yes` for asterisk lies between an UA and a Proxy loose routing. The call flow UA1 (linphone) <-> Asterisk <-> Proxy (kamailio) <-> UA2 and things go wrong for the call between Asterisk and UA2 (via Proxy) when receive re-INVITE hold from UA1 Asterisk supposes to place the UA2's Contact in the R-URI header for subsequent in-dialog requests sent to the proxy. Asterisk does well for the ACK corresponding to the initial INVITE, but for subsequent re-INVITEs (and their ACKs), Asterisk placed the Proxy's Contact into the R-URI which make them not routable. Edit: I have this simple dialplan for briding call from my client linphone to my UA2 server via Asterisk PJSIP and kamailio Proxy in between [outgoing] exten => _X.,1,Dial(PJSIP/950@kamailio,,m(ringing)S(86400)) UA1 (linphone) <-> Asterisk <-> Proxy (kamailio) <-> UA2 192.168.1.50:6004 <-> 192.168.1.235:5060 <-> 192.168.1.229:5060 <-> 192.168.1.231:5070 The R-URI for re-INVITE from Asterisk to kamailio Proxy (when proxy the re-INVITE hold from the client with the effect of moh_passthrough option) supposes to contain the UA2's Contact, i.e: 192.168.1.231:5070, but asterisk pjsip filled it with the proxy's contact instead (192.168.1.229:5060). [May 13 10:47:00] VERBOSE[172904] res_pjsip_logger.c: <--- Transmitting SIP request (487 bytes) to UDP:192.168.1.229:5060 ---> ACK sip:950@192.168.1.229:5060 SIP/2.0 Route: <sip:192.168.1.229:5060;lr;ftag=5343c5e5-141a-4e3c-85c3-5785ac2c2509;did=a88.ddf1> A note that the ACK for the initial INVITE and the very first re-INVITE from asterisk were still valid with the UA2's Contact as the R-URI, the later re-INVITE and ACK are invalid, please check my  attached SIP log
Comments:	By: Asterisk Team (asteriskteam) 2019-05-07 05:13:24.168-0500 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]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Joshua C. Colp (jcolp) 2019-05-07 05:22:27.397-0500 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. The specific steps or actions you took that caused you to encounter the problem. 2. The behavior you expected and the location of documentation that led you to that expectation. 3. The behavior you actually encountered. To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines [2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information As well Asterisk 15 is no longer supported, so any fixes or changes as a result of this will only go into supported branches. We will also need the configuration as there are options which can change the behavior. By: Dang Thanh Loi (loi.dangthanh@gmail.com) 2019-05-12 23:02:22.609-0500 I attached the log and edited the description, hope you'll be able to reproduce it Many thanks, Joshua By: George Joseph (gjoseph) 2019-05-15 09:26:06.505-0500 I'm going to try to reproduce this.  Can you provide the full configuration for the UA1 and kamailio endpoints? By: Dang Thanh Loi (loi.dangthanh@gmail.com) 2019-05-16 02:22:06.954-0500 @George Joseph, i attached my PJSIP.conf for my UA1 (local_linphone) and kamailio endpoint. Thanks By: Joshua C. Colp (jcolp) 2019-05-16 04:31:53.151-0500 You have set "rewrite_contact" to "yes" for kamailio which is incorrect. This must be set to "no", otherwise the contact URI and the stored request URI will be modified and be incorrect. If you set it to "no" does the behavior change? By: Dang Thanh Loi (loi.dangthanh@gmail.com) 2019-05-16 05:55:18.451-0500 I re-tested with `rewrite_contact = no` and see that subsequent re-INVITEs and there ACKs were all fine. Many thanks for pointing me the way but i'm still a bit lost on my first ACK, BYE and even the very first re-INVITE for hold were valid even with the setting of `rewrite_contact = no` Also found this card saying not to rewrite the R-URI when there's Record-Route header which is available at my version 15.7.2 (Target Release Version/s: 13.5.0, 14.0.0). ASTERISK-25196 Any ideas, Joshua? By: Joshua C. Colp (jcolp) 2019-05-16 06:19:47.064-0500 Not particularly, the code may be broken or is triggering in a particular case. Generally though you shouldn't need or use rewrite_contact when a proxy is involved. By: Dang Thanh Loi (loi.dangthanh@gmail.com) 2019-05-16 22:22:04.121-0500 okay, actually i didn't dive deep enough into the asterisk's pjsip, the configuration was converted from sip.conf by asterisk's script. Again, many thanks for the support. By: Asterisk Team (asteriskteam) 2019-05-16 22:22:04.762-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.