Summary:	ASTERISK-24615: When Multiple Transports Exist in pjsip.conf, Incorrect External Addresses is Used in SIP Packets When Responding to INVITE
Reporter:	David Justl (djustl)	Labels:	patch pjsip
Date Opened:	2014-12-12 18:03:39.000-0600	Date Closed:	2015-01-19 07:19:52.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_pjsip
Versions:	13.0.1	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) ASTERISK-24615.diff ( 1) pjsip-multihomed-skip-new-transport.diff
Description:	Say pjsip.conf is configured with two transports, one bound to port 5060 and one bound to port 5061, each with completely different external_signaling_address and external_media_address values. Then say each is mapped to a different VoIP provider's endpoint. When Asterisk receives an INVITE from the provider that is configured to use the transport bound to port 5061, it is using the external_signaling_address and external_media_address values from the transport bound to port 5060 in the Header Contact and in the Message Body Session Description Protocol portions of the OK response. There is nothing in pjsip.conf tying the given endpoint to the port 5060 transport. This causes the provider to send RTP and other signaling packets to the wrong IP.
Comments:	By: Matt Jordan (mjordan) 2014-12-16 09:09:59.575-0600 We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Please make sure 'pjsip set logger on' is enabled. Also provide your pjsip.conf that reproduces this problem. Note that all of this information is in the issue reporting guidelines [1]. Please follow those instructions when filing an issue. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: David Justl (djustl) 2014-12-16 10:38:10.907-0600 I have a log and the config file ready to upload. Since those contain some details that we prefer not to make public, would it be possible to limit who can see this report? By: Rusty Newton (rnewton) 2014-12-16 18:33:19.350-0600 It would be, but then others wouldn't be able to find the issue. We typically only lock it down for security issues. Can you remove or obscure any private information in the files? Passwords or sensitive IP addresses? If that is impossible then we can lock it down temporarily. Press Send Back or Enter Feedback when replying. Thanks! By: David Justl (djustl) 2014-12-17 12:33:16.186-0600 I have attached the log and pjsip.conf By: David Justl (djustl) 2014-12-29 10:31:28.501-0600 Would it be possible to limit the visibility of the log/config that I uploaded or to remove them once you have grabbed them? By: David Justl (djustl) 2015-01-12 16:00:42.646-0600 After performing some additional testing, it appears this is affected by at least two factors: 1. If both transports are bound to different ports on the same IP address (Or to 0.0.0.0), the order they appear in pjsip.conf matters...the information in the transport that is listed second is used. 2. If each transport is bound to a different IP address, the lower address is used (e.g. 1.1.1.1 vs. 1.1.1.2), regardless of the order they appear in pjsip.conf. By: Joshua C. Colp (jcolp) 2015-01-12 20:07:58.124-0600 I've confirmed this issue. The reason being that until the message gets to the transaction layer it has the wrong transport associated with it. The transport is a lie. By: Joshua C. Colp (jcolp) 2015-01-13 06:26:13.909-0600 Attached is a patch which should resolve this issue. I'm going to continue testing it but feedback is appreciated. By: Joshua C. Colp (jcolp) 2015-01-13 11:37:09.794-0600 An updated patch is now up for review at https://reviewboard.asterisk.org/r/4331/ By: David Justl (djustl) 2015-01-14 15:22:07.620-0600 Thanks Joshua! The patch does seem to partially fix the original problem, allowing us to establish a call when we have two transports bound to two different ports. However, I did find that some signaling (e.g. the 'BYE' message) seems to be sent incorrectly depending on the order the transports appear in the file. I have attached configurations and logs showing each case. There is also still a problem if two different IP addresses are assigned to the two transports. In that case, the transport bound to the 'lower' IP address (1.1.1.1 vs. 1.1.1.2) is always used, no matter which receives the initial INVITE and no matter which order they appear in the config file. On a side note, it appears that the overall concept is to respond using the transport bound to the IP/port on which the INVITE is received. Once the INVITE finds a matching endpoint, wouldn't it be better/simpler to use the transport specified in that endpoint to determine which external addresses to specify in the response? By: Joshua C. Colp (jcolp) 2015-01-14 15:39:42.182-0600 It's much easier said than done when it comes to PJSIP. I'll see what I can come up with. By: Joshua C. Colp (jcolp) 2015-01-16 06:59:22.722-0600 This is a new patch which locks the UAS dialog to the configured transport. It also ensures the Contact header is of this transport. The multihomed module has also been reworked so it won't try to squash the addresses in the message unless it can. By: Joshua C. Colp (jcolp) 2015-01-16 06:59:53.555-0600 Can you give this one a try? I'll hold off on code review for a day or two. By: David Justl (djustl) 2015-01-16 10:52:09.931-0600 This one seems to fix it. The proper external IP is used for all signaling, including the 'BYE' message, no matter which order the transports appear in the file. I also tested using different IPs instead of different ports and that is also now working properly. Thanks much! By: Joshua C. Colp (jcolp) 2015-01-16 13:52:29.491-0600 I've got this up for review now. Thanks!