[asterisk-bugs] [JIRA] (ASTERISK-23267) Expires In Contact Header Of 200 OK From Outbound Registration Response Is Ignored Due To Contact URI Parameters Being Added

Rusty Newton (JIRA) noreply at issues.asterisk.org
Tue Feb 18 18:20:05 CST 2014


     [ https://issues.asterisk.org/jira/browse/ASTERISK-23267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-23267:
------------------------------------

    Affects Version/s: 11.7.0
                       12.0.0
    
> Expires In Contact Header Of 200 OK From Outbound Registration Response Is Ignored Due To Contact URI Parameters Being Added
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-23267
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23267
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Channels/chan_sip/Interoperability
>    Affects Versions: SVN, 1.8.20.1, 1.8.25.0, 11.7.0, 12.0.0
>         Environment: AstLinux 1.1.0
>            Reporter: Adam Dugan
>            Assignee: Michael L. Young
>            Severity: Minor
>
> When Asterisk receives Contact header expires parameter it will update the expiry for the registration only if it exactly matches the contact used in the registration request.
> Asterisk sends register request with:
> {noformat}
> REGISTER
> From: <sip:2125551000 at 192.168.1.1:5060>;tag=xxxxxxxxxx
> {noformat}
> This 200 OK will cause Asterisk to update expiration to 125 seconds.
> {noformat}
> 200 OK
> Contact: <sip:2125551000 at 192.168.1.1:5060>;expires=125
> {noformat}
> This 200 OK will cause Asterisk to ignore the contact header and use it's default expiry instead of the one specified:
> {noformat}
> Contact: <sip:2125551000 at 192.168.1.1:5060;ep=192.168.1.1;fw=74.125.235.232>;expires=125
> {noformat}
> This issue has been discussed before and closed, but in the previous instance the URI in the contact header was not formatted correctly (see: ASTERISK-14870 ).
> Per the RFC:
> {quote}
> RFC 3261 10.3 Processing REGISTER Requests
>       8. The registrar returns a 200 (OK) response.  The response MUST
>          contain Contact header field values enumerating all current
>          bindings.  Each Contact value MUST feature an "expires"
>          parameter indicating its expiration interval chosen by the
>          registrar. The response SHOULD include a Date header field.
> RFC 3261 19.1.4 URI Comparison
> URI uri-parameter components are compared as follows:
>          -  Any uri-parameter appearing in both URIs must match.
>          -  A user, ttl, or method uri-parameter appearing in only one
>             URI never matches, even if it contains the default value.
>          -  A URI that includes an maddr parameter will not match a URI
>             that contains no maddr parameter.
>          -  All other uri-parameters appearing in only one URI are
>             ignored when comparing the URIs.
> {quote}
> I've been pouring over the RFC trying to figure out what is correct. Sections I've read could interpret to mean the Contact header returned in the 200 OK must exactly match that used in the register request, and that the URI parameters might be ok.
> I'm currently using a VoIP provider that is returning a Contact header in the 200 OK with endpoint and firewall (ep & fw) URI parameters. This is causing Asterisk not to respect the expires time and subsequently causing my registration to timeout on the carrier side before Asterisk re-registers. As the carrier requests an expiry less then the minimum allowed upon connect there is no way to successfully stay connected editing the Asterisk configuration files alone.
> The Oracle Session Border Controller seems to have the behavior of adding the fw firewall and ep endpoint URI parameters to the Contact field of SIP packets. See Using Private IPv4 Addresses, Page 282: http://docs.oracle.com/cd/E50377_01/doc/sbc_sc610_acliconfiguration.pdf
> Looking at the code it does appear there is a string compare. I haven't traced back to the parse yet to see if it's stripping out the URI parameters. Based on the behavior I've experienced it isn't.  
> http://svnview.digium.com/svn/asterisk/branches/1.8/channels/chan_sip.c?revision=406170&view=markup
> {code}
> 21558			if (!ast_strlen_zero(get_header(req, "Contact"))) {
> 21559				const char *contact = NULL;
> 21560				const char *tmptmp = NULL;
> 21561				int start = 0;
> 21562				for(;;) {
> 21563					contact = __get_header(req, "Contact", &start);
> 21564					/* this loop ensures we get a contact header about our register request */
> 21565					if(!ast_strlen_zero(contact)) {
> 21566						if( (tmptmp=strstr(contact, p->our_contact))) {
> 21567							contact=tmptmp;
> 21568							break;
> 21569						}
> 21570					} else
> 21571						break;
> 21572				}
> 21573				tmptmp = strcasestr(contact, "expires=");
> 21574				if (tmptmp) {
> 21575					if (sscanf(tmptmp + 8, "%30d", &expires) != 1) {
> 21576						expires = 0;
> 21577					}
> 21578				}
> 21579				
> 21580			}
> 21581			if (!expires)
> 21582				expires=atoi(get_header(req, "expires"));
> 21583			if (!expires)
> 21584				expires=default_expiry;
> {code}
> With debugging on:
> {noformat}
> REGISTER:
> [2014-02-07 21:45:18] DEBUG[1663]: chan_sip.c:8914 parse_request:  Header 10 [ 40]: Contact: <sip:2125551000 at 191.168.1.1:5060>
> 200 OK:
> [2014-02-07 21:45:18] DEBUG[1663]: chan_sip.c:8914 parse_request:  Header  6 [ 80]: Contact: <sip:2125551000 at 192.168.1.1:5060;ep=192.168.1.1;fw=74.125.235.232>;expires=155
> {noformat}
> I've tried to find someone in the forums & IRC channels to provide opinions on whether Asterisk or Oracle is following the standard and which one isn't. As Asterisk is intended to be interoperable with other SIP products, and Oracle is a major manufacturer there probably should be a solution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list