[asterisk-bugs] [Asterisk 0018119]: Reregistration with small (20 sec) Expiry fails

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18119 
====================================================================== 
Reported By:                fabled
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18119
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.13 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-10-12 03:36 CDT
Last Modified:              2010-10-12 04:15 CDT
====================================================================== 
Summary:                    Reregistration with small (20 sec) Expiry fails
Description: 
Apparently the following happens:

1. Asterisk register succesfully, 20s Expiry -> reregister in 15s
   - destruction of sip_pvt scheduled with timeout > 15s
2. When reregister triggers:
   - sip_registry->call is NULL, because of successful registration
   - transmit_register builds new sip_pvt with same call ID as
https://issues.asterisk.org/view.php?id=1
3. Server replies
4. Asterisk rejects registration reply because:
   - the sip_pvt from https://issues.asterisk.org/view.php?id=1 has not been yet
destroyed
   - and asterisk routes the reply to sip_pvt from
https://issues.asterisk.org/view.php?id=1 due to call-id
conflict
   - this is indicated by log messages such as:
[Oct 11 21:34:26] DEBUG[16751] chan_sip.c: Ignoring out of order
response 476 (expecting 475)
   - until we get timer_t1*64 ms later the message
[Oct 11 21:34:42] DEBUG[16751] chan_sip.c: Auto destroying SIP dialog
'768de833447ed7e558ee6dcc44f94821 at ...'
   - immediately after which the registration succeeds again

Olle suggested on mailing list:
I think it clearly has to do with the t1 timer for
https://issues.asterisk.org/view.php?id=1. It propably hangs
around for more than 20 secs. We should set max
T1 for registry transactions to be the expiry time minus some small unit.

And yes, with default global_t1 the timeout would be around 30 seconds.
====================================================================== 

---------------------------------------------------------------------- 
 (0127855) schmidts (manager) - 2010-10-12 04:15
 https://issues.asterisk.org/view.php?id=18119#c127855 
---------------------------------------------------------------------- 
i have looked into the rfc to see if something is in there to make sure we
will do the right thing.
part 10.3.7 says: 
If the Call-ID value in the existing binding differs from the
Call-ID value in the request, the binding MUST be removed if
the expiration time is zero and updated otherwise.  If they are
the same, the registrar compares the CSeq value.  If the value
is higher than that of the existing binding, it MUST update or
remove the binding as above.  If not, the update MUST be
aborted and the request fails.

could you please add a sip trace for this issue so we can ensure asterisk
does it right.

IMHO asterisk should reply with an 423 Interval too short message if
someone tries to register with an expiry value lower than T1 * 64 to
prevent such behavior cause i think there is no need to reregister every 15
seconds but i may be wrong on this ;)

thank you! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-10-12 04:15 schmidts       Note Added: 0127855                          
======================================================================