[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:03 CST 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-23267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rusty Newton updated ASTERISK-23267:
------------------------------------
Component/s: Channels/chan_sip/Interoperability
Channels/chan_sip/General
> 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: 1.8.20.1
> 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