[asterisk-bugs] [JIRA] (ASTERISK-23267) URI parameters passed in 200 OK response to register prevent Asterisk from matching contact field and updating expire time.
Adam Dugan (JIRA)
noreply at issues.asterisk.org
Wed Feb 12 11:39:07 CST 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-23267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215171#comment-215171 ]
Adam Dugan commented on ASTERISK-23267:
---------------------------------------
Fresh install of Debian 7.4.0 i386 & Asterisk 1.8.25 compiled from source.
It seems with an expires=250 (shown below) or expires=190 (not shown) returned in the contact header Asterisk is parsing it as 120 and scheduling in 105.
REGISTER:
{noformat}
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 0 [ 39]: REGISTER sip:sip.provider.net SIP/2.0
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 1 [ 62]: Via: SIP/2.0/UDP 192.168.1.1:5060;branch=UHGNqF5g9xD2XRB;rport
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 2 [ 16]: Max-Forwards: 70
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 3 [ 56]: From: <sip:2125551000 at sip.provider.net>;tag=xd56e9cf77
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 4 [ 39]: To: <sip:2125551000 at sip.provider.net>
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 5 [ 51]: Call-ID: baQEzBAsfKNAhBrJSbH8APbTEnrVZMmx at 127.0.1.1
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 6 [ 18]: CSeq: 108 REGISTER
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 7 [ 33]: User-Agent: Asterisk PBX 1.8.25.0
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 8 [225]: Authorization: Digest username="2125551000", realm="sip.provider.net", algorithm=MD5, uri="sip:sip.provider.net", nonce="6s3wAWLmXG6Z", response="rqcRcKzvVERd9yfgZjrgYk8EYm4tdFZV", qop=auth, cnonce="671de2386", nc=00000000
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 9 [ 13]: Expires: 3600
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 10 [ 42]: Contact: <sip:2125551000 at 192.168.1.1:5060>
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 11 [ 17]: Content-Length: 0
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 12 [ 0]:
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:4143 __sip_reliable_xmit: *** SIP TIMER: Initializing retransmit timer on packet: Id #30
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:3688 __sip_xmit: Trying to put 'REGISTER si' onto UDP socket destined for 74.125.235.232:5060
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:3318 registry_unref: SIP Registry sip.provider.net: refcount now 3
{noformat}
200 OK:
{noformat}
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 0 [ 14]: SIP/2.0 200 OK
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 1 [ 95]: Via: SIP/2.0/UDP 192.168.1.1:5060;received=74.125.235.232;branch= EY5M7xgLFfM4Jg4;rport=57802;alias
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 2 [ 56]: From: <sip:2125551000 at sip.provider.net>;tag=xd56e9cf77
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 3 [ 69]: To: <sip:2125551000 at sip.provider.net>;tag= rN9EKnbF9hQbFCFHrestdBhk6
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 4 [ 51]: Call-ID: baQEzBAsfKNAhBrJSbH8APbTEnrVZMmx at 127.0.1.1
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 5 [ 18]: CSeq: 108 REGISTER
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8962 parse_request: Header 6 [ 84]: Contact: <sip:2125551000 at 192.168.1.1:5060;ep=192.168.1.1;fw=74.125.235.232>;expires=250
--- (8 headers 0 lines) ---
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:8553 find_call: = Looking for Call ID: baQEzBAsfKNAhBrJSbH8APbTEnrVZMmx at 127.0.1.1 (Checking To) --From tag xd56e9cf77 --To-tag rN9EKnbF9hQbFCFHrestdBhk6
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:4339 __sip_ack: ** SIP TIMER: Cancelling retransmit of packet (reply received) Retransid #30
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:4372 __sip_ack: Stopping retransmission on 'baQEzBAsfKNAhBrJSbH8APbTEnrVZMmx at 127.0.1.1' of Request 108: Match Found
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:21495 handle_response_register: Registration successful
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:21497 handle_response_register: Cancelling timeout 29
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:3318 registry_unref: SIP Registry sip.provider.net: refcount now 1
Scheduling destruction of SIP dialog 'baQEzBAsfKNAhBrJSbH8APbTEnrVZMmx at 127.0.1.1' in 32000 ms (Method: REGISTER)
[Feb 10 18:55:35] NOTICE[22982]: chan_sip.c:21548 handle_response_register: Outbound Registration: Expiry for sip.provider.net is 120 sec (Scheduling reregistration in 105 s)
[Feb 10 18:55:35] DEBUG[22982]: chan_sip.c:3326 registry_addref: SIP Registry sip.provider.net: refcount now 1
[Feb 10 18:56:07] DEBUG[22982]: chan_sip.c:4228 __sip_autodestruct: Auto destroying SIP dialog 'baQEzBAsfKNAhBrJSbH8APbTEnrVZMmx at 127.0.1.1'
[Feb 10 18:56:07] DEBUG[22982]: chan_sip.c:6449 sip_destroy: Destroying SIP dialog baQEzBAsfKNAhBrJSbH8APbTEnrVZMmx at 127.0.1.1
Really destroying SIP dialog 'baQEzBAsfKNAhBrJSbH8APbTEnrVZMmx at 127.0.1.1' Method: REGISTER
[Feb 10 18:56:07] DEBUG[22982]: chan_sip.c:19450 sip_dump_history:
---------- SIP HISTORY for 'baQEzBAsfKNAhBrJSbH8APbTEnrVZMmx at 127.0.1.1'
{noformat}
> URI parameters passed in 200 OK response to register prevent Asterisk from matching contact field and updating expire time.
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: ASTERISK-23267
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-23267
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Affects Versions: 1.8.20.1
> Environment: AstLinux 1.1.0
> Reporter: Adam Dugan
> 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