[asterisk-dev] 'sip unregister devicename' device unavaiable 25/3600 seconds

[Russell Bryant]

> From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com 
> ] On Behalf Of Alec Davis
> Sent: Tuesday, 19 May 2009 10:29 p.m.

> There are 2 patches:
> 1st targets the sip_unregister problem directly, its removes the  
> current active expire_register callback scheduled event.

I think this patch sounds perfect.

>
> The 2nd is more general and may be over kill, it removes if present  
> the event that called expire_register, most of the time it's already  
> gone.

This certainly seems like overkill.

> A last thought, sure the cause was buggy sip_unregister, but what  
> about the concept of instead of using ast_sched_add when the phone  
> registers, use ast_sched_replace, where it would replace an existing  
> expire_register id, or if not found, would add a new event.
>

My reading of the code (in Asterisk trunk, anyway) is that this is  
effectively already being done.  In parse_register_contact(), it looks  
like it's just ast_sched_add(), but ast_sched_del() is done about 10  
lines above.

On May 20, 2009, at 11:14 PM, Alec Davis wrote:

> Another idea, to prevent this cycling effect, due to a stale event  
> in the schedule list.
>
> Is to sanity check the event ID within expire-register against the  
> expected peer->expire event ID, if they don't match then it's stale  
> and ignore, post a console warning that they don't match, so the  
> buggy code can be rectified.
>
> Anyone have other thoughts on this?

I'm not sure how this would be implemented with the current scheduler  
API.  Within a scheduler callback, you do not have access to the  
scheduler event ID currently being executed.

Thanks for the excellent detective work.

--
Russell Bryant
Digium, Inc. | Senior Software Engineer, Open Source Team Lead
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org