[asterisk-dev] SIP Registration with short Expire fails systematically

Olle E. Johansson oej at edvina.net
Tue Oct 12 03:22:27 CDT 2010


12 okt 2010 kl. 09.35 skrev Timo Teräs:

> Hi,
> 
> I'm still analyzing further the SIP registration issues I emailed
> earlier. It seems that there's one another problem that makes the issue
> harder to debug.
> 
> What happens is when the link is down for a while, is that STUN fails
> discover the device's public IP. This makes the box I'm registering to
> (a public ISP / SIP provider server) to discover that my server is
> NATted and it starts to hand out very short Expire times for
> registrations going as low as 20 seconds.
> 
> Now what happens at this point is that Asterisk fails to re-register
> after the first 20 second Expire has been received. I have debug logs
> from it.
> 
> My guess is that the following happens:
> 1. Asterisk register succesfully, 20s Expiry -> reregister in 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 #1
> 3. Server replies
> 4. Asterisk rejects registration reply because:
>    - the sip_pvt from #1 has not been yet destroyed
>    - and asterisk routes the reply to sip_pvt from #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
> 
> 
> So my questions are:
> - why do registrations get created with same call-id? authdata reuse?
> - why do we create new sip_pvt's instead of using just one?
> - and most importantly how to fix the issue?
> 
Please file a bug report in the issue tracker :-)

I think it clearly has to do with the t1 timer for #1. It propaply hangs around for more than 20 secs. We should set max
T1 for registry transactions to be the expiry time minus some small unit.

Cheers,
/Olle




More information about the asterisk-dev mailing list