[Home]

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-0600Date Closed:2015-01-19 07:19:52.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents: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!