[Home]

Summary:ASTERISK-26491: pjsip: PJSIP is confused by erroneous Contact header. chan_sip handles it fine.
Reporter:Daniel Heckl (DanielYK)Labels:
Date Opened:2016-10-21 06:13:07Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:pjproject/pjsip
Versions:13.11.2 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Attachments:( 0) log.txt
( 1) pjsip-debug-log2.txt
Description:Our Asterisk is behind an NAT and has an public ip. Sometimes our public ip address changes. Asterisk sends an REGISTER all 480 seconds.

If our public ip address changes and Asterisk sends an re-REGISTER, our provider sends an OK. But asterisk does not realize it. Instead asterisk sends multiple times a new REGISTER and gets always an OK. After some time it logs "res_pjsip_outbound_registration.c:761 schedule_retry: No response received". Why!? Asterisk received multiple times an OK!

After some wait time it retries again, gets an 403 Forbidden from our provider and permanently stops outbound registration.

Chan_sip handle properly this situation.

Attached a log from the communication between asterisk and tel.t-online.de.

I think the problem is that the OK from the provider contains following lines:
Contact: <sip:0123456789@192.168.0.10:45060>;expires=480
Contact: <sip:0123456789@192.168.0.10:45060>;expires=10
Asterisk see the 10 seconds expiring Contact and schedules a new registration. But in reality the first Contact is "the new" one, this one is expiring in 480 seconds.
Asterisk re-REGISTER till the second Contact is expired.
Comments:By: Asterisk Team (asteriskteam) 2016-10-21 06:13:09.261-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].

By: Rusty Newton (rnewton) 2016-10-21 09:04:52.229-0500

Please capture another log and enable the following log channel types:

WARNING,NOTICE,ERROR,VERBOSE,DEBUG

Please turn verbose and debug up to 5 and have the SIP trace integrated as well.

By: Daniel Heckl (DanielYK) 2016-10-21 15:27:04.125-0500

Attached you find the new debug log file.

I think the problem is that the OK from the provider contains following lines:
Contact: <sip:0123456789@192.168.0.10:45060>;expires=480
Contact: <sip:0123456789@192.168.0.10:45060>;expires=10

Asterisk see the 10 seconds expiring Contact and schedules a new registration. But in reality the first Contact is "the new" one, this one is expiring in 480 seconds.

Asterisk re-REGISTER till the second Contact is expired.

By: Rusty Newton (rnewton) 2016-10-24 14:33:29.339-0500

Well, the provider shouldn't be sending the other Contact header. So, we can't do anything about that. You should contact your provider.

However, we could probably handle this better since chan_sip did. Since this is such an uncommon scenario and isn't affecting many people it is unlikely that this will get worked on soon due to priorities. Just wanted to give you a heads up.

The issue is open and in queue now. Thanks!

By: Daniel Heckl (DanielYK) 2016-11-01 05:54:54.115-0500

Thanks for the heads-up. I think there are more effected users than thought. All users which want to migrate to pjsip and have no static public ip.
They cannot set external_signaling_address and external_media_address (because of only external_signaling_address supports domains), so they use there private ip and asterisk goes crazy if there are two contact-headers with the same URI.

I am in contact with our provider. I think that does not help. The SIP messages and SDP messages uses private IPs, which is unusual.

I hope the problem is fixed as soon as possible. PJSIP is great and I want to use it for all our phone numbers.

By: Rusty Newton (rnewton) 2016-11-01 09:33:26.734-0500

Did the ITSP provide a reason or point to an RFC regarding why they are using two Contact headers?

I was told by a SIP developer that using two Contact headers was invalid and that the provider was in error.

By: Alexei Gradinari (alexei gradinari) 2016-11-17 08:50:53.664-0600

May be asterisk should add  "x-uid" extension parameter to determine the correct Contact header.

http://www.pjsip.org/pjsip/docs/html/group__PJSIP__CONFIG.htm

{noformat}
#define PJSIP_REGISTER_CLIENT_ADD_XUID_PARAM   0
Specify whether client registration should add "x-uid" extension parameter in all Contact URIs that it registers to assist the matching of Contact URIs in the 200/OK REGISTER response, in case the registrar is unable to return exact Contact URI in the 200/OK response.

This setting can be changed in run-time by setting regc.add_xuid_param field of pjsip_cfg().

Default is 0.
{noformat}

By: Daniel Heckl (DanielYK) 2016-11-17 11:12:09.315-0600

Rusty, I have figured out the problem. On our router runs an SIP ALG (what was not known to me so far), which changes the private IP to the public IP. This affects only pjsip, because chan_sip uses our public ip. That means, our provider sends an OK with one Contact Header for the old public IP and another one with the new public IP. The SIP ALG changes both IP addresses to the same private IP, which causes the chaos.

So our provider and also asterisk does their jobs fine.

I cannot disable the SIP ALG in our provider. If I set external_signaling_address and external_media_address to a private IP outside of our private subnet, the SIP ALG does not change IPs any more. This is my personal, not very pretty workaround.

Alexei, I think an implementation of x-uid could be interesting for some people. Nevertheless, I would prefer a domain support for external_media_address (external_signaling_address has it already), so users behind an dynamic public IP could migrate from chan_sip to pjsip...

By: Rusty Newton (rnewton) 2016-11-18 14:09:54.166-0600

Thanks for following up with the additional information.