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

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

Cheers,
  Timo