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

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Oct 12 07:27:13 CDT 2010


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 07:27 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0127860) fabled (reporter) - 2010-10-12 07:27
 https://issues.asterisk.org/view.php?id=18119#c127860 
---------------------------------------------------------------------- 
Yes, I kinda figured 2 & 3 are not too good. Probably 2 is hard to
implement as it would imply that we need to keep weak reference. Or maybe
it just needs a new scheduler function to clear the sip_registry stuff when
the dialogue is destroyed. But it would need more care to make sure we
don't hit strange race conditions.

So yes, fix no 1 is seems simplest.

And yes, it really smells like a NAT keepalive. The server does that only
when it detects NAT. If externip is set correctly, the Expires it sends is
several minutes. This is done by Finnish service provider Saunalahti on
their Nettipuhelin service. It is a consumer targeted POTS to SIP gateway
service. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-10-12 07:27 fabled         Note Added: 0127860                          
======================================================================




More information about the asterisk-bugs mailing list