[asterisk-bugs] [JIRA] (ASTERISK-17249) SIP registration message sequencing issue causes inability to register

[roman sidler (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-17249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207370#comment-207370 ] 

roman sidler commented on ASTERISK-17249:
-----------------------------------------

A little bit late, but the issue is still open. We've ecountered the same problem on 1.6.1.
The situation is re-producable when the expiration time of REGISTER is set < 64*T1 (typically 32s).
Then the lookup function for existing dialogs (find_call()) picks up the previous dialog.
A dialog is identified by its "Call-ID:" and in case of Registration it's always the same value (according RFC).
pedantic=yes doesn't work correctly on REGISTER-messages.
**
I modified the 1.6.1 code that always the "From:"-tag  AND the "Call-ID" is considered. 
it works but is a rather invasive code change, the 1.8. solution is much better.
                
> SIP registration message sequencing issue causes inability to register
> ----------------------------------------------------------------------
>
>                 Key: ASTERISK-17249
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17249
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/Registration
>            Reporter: Ed Brundage
>         Attachments: case1-success.txt, case2-failure.txt
>
>
> We have been having problems with our SIP trunks losing connectivity, so I rolled up my sleeves and did some debugging.
> At first glance, it looks as if Asterisk is ignoring SIP REGISTER OK messages from the provider.  But, after closer inspection (with all debugging and verbosity enabled), I realized it looks more like a problem with message sequencing in the SIP registration and/or registry routines.
> The problem occurs at the time of trunk registration expiry (during re-registration).  However, the issue must be explained via two separate scenarios.  The two scenarios differ based on whether or not Asterisk's saved re-auth token is accepted by the provider during registration.  In the first case, where re-auth information is still valid, system operation is not overly hindered by this issue (other than by unneeded bandwidth utilization).  In the second case, however, where the provider requests an authentication challenge/response prior to registration, the issue becomes very serious.  That said, in both cases, it still looks as though there is a logic error in message sequencing.
> The behavior is as follows:
> Case 1)  Asterisk sends a REGISTER message, and within a few milliseconds, the provider responds with the expected OK message.  However, then Asterisk reports that the message sequence number is + 1, and drops the packet (i.e. "Ignoring out of order response 128 (expecting 127)").  This cycle repeats a number of times -- Asterisk retransmits the same REGISTER message, the provider responds appropriately with the same OK, and each time, Asterisk drops the packet with the same "out of order" complaint.  Asterisk repeats the retransmit cycle five times, gives up on retransmitting the packet, then subsequently realizes there is a REGISTER OK message with the correct (later) sequence number and completes registration successfully.
> Case 2)  In the case that the provider has decided that our standing authorization tokens are no longer valid, it sends a "401 Unauthorized" challenge message in response to the REGISTER message, and again, this process repeats a number of times.  Because Asterisk thinks the message sequence is out of order, it does not reply with a response to the challenge -- it drops the message and sends another REGISTER.  Now, in the case of our provider, after sending four "401 Unauthorized" messages and not receiving a valid challenge response, it decides the UA attempting registration is fraudulent, and blocks incoming communication (i.e. via firewall) for approximately an hour.
> The logs clearly indicate the correct sequence numbers are being sent and received throughout the entire message flow, so this must be a variable increment issue or something of that nature.
> Of Interest:
> 1)  This issue only manifests on re-registration.  It does not occur on initial trunk creation (i.e. when Asterisk starts).
> 2)  Our provider, Broadvoice, recommends "pedantic=no" be set in sip.conf.  Setting "pedantic=yes" on our current production version of Asterisk (1.6.2.13) has no effect on this issue.  However, on our test PBX, running Asterisk 1.8.1.1, setting "pedantic=yes" resolves the issue perfectly. 

--
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