The testing and reporting of the bug was done with a Grandstream BT100, but it is no way a reflection on Grandstream.
The reported 25 seconds of available time is a combination of the 10 seconds chan_sip adds to the requested expiry period, and the 15 seconds that Grandstream re-Registers before the expire time.
For testing, I used a register expire period of 60 seconds. Configured either in sip.conf as maxexpiry=60 in the [general] section or set the phone's parameter.
The fault is that a stale expire_register schedule is left in the scheduler, and expires 25 seconds after the device adds a new fresh expire schedule, due to expire in 70 seconds...
If a device has a re-register time of 3600 seconds, the phone is unavailable for 3575 seconds in every 3600.!!!
There are 2 patches:
1st targets the sip_unregister problem directly, its removes the current active expire_register callback scheduled event.
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.
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.
Posted: Thu May 21, 2009 3:26 am Post subject: [asterisk-dev] 'sip unregister devicename' device unavaiable
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?
Alec Davis
From:asterisk-dev-bounces@lists.digium.com [mailto:asterisk-dev-bounces@lists.digium.com] On Behalf Of Alec Davis
Sent: Tuesday, 19 May 2009 10:29 p.m.
To: 'Asterisk Developers Mailing List'
Subject: [asterisk-dev] 'sip unregister devicename' device unavaiable 25/3600 seconds
The 3600 in the subject assumes a sip registration period of 60 minutes.
The testing and reporting of the bug was done with a Grandstream BT100, but it is no way a reflection on Grandstream.
The reported 25 seconds of available time is a combination of the 10 seconds chan_sip adds to the requested expiry period, and the 15 seconds that Grandstream re-Registers before the expire time.
For testing, I used a register expire period of 60 seconds. Configured either in sip.conf as maxexpiry=60 in the [general] section or set the phone's parameter.
The fault is that a stale expire_register schedule is left in the scheduler, and expires 25 seconds after the device adds a new fresh expire schedule, due to expire in 70 seconds...
If a device has a re-register time of 3600 seconds, the phone is unavailable for 3575 seconds in every 3600.!!!
There are 2 patches:
1st targets the sip_unregister problem directly, its removes the current active expire_register callback scheduled event.
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.
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.
Posted: Fri May 22, 2009 12:50 pm Post subject: [asterisk-dev] 'sip unregister devicename' device unavaiable
Quote:
From: asterisk-dev-bounces@lists.digium.com [mailto:asterisk-dev-bounces@lists.digium.com
] On Behalf Of Alec Davis
Sent: Tuesday, 19 May 2009 10:29 p.m.
Quote:
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.
Quote:
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.
Quote:
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:
Quote:
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
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum