[asterisk-bugs] [Asterisk 0018623]: SIP registration message sequencing issue causes inability to register

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18623 
====================================================================== 
Reported By:                foxnetradio
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18623
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.2.14 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-01-14 11:06 CST
Last Modified:              2011-01-17 09:08 CST
====================================================================== 
Summary:                    SIP registration message sequencing issue causes
inability to register
Description: 
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. 
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-17 09:08 lmadsen        Description Updated                          
======================================================================