<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18702"></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=535470504-21052009><FONT color=#0000ff
size=2 face=Arial>Another idea, to prevent this cycling effect, due to a stale
event in the schedule list.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=535470504-21052009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=535470504-21052009><FONT color=#0000ff
size=2 face=Arial>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 </FONT></SPAN><SPAN
class=535470504-21052009><FONT color=#0000ff size=2 face=Arial>a console warning
that they don't match, so the buggy code can be
rectified.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=535470504-21052009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=535470504-21052009><FONT color=#0000ff
size=2 face=Arial>Anyone have other thoughts on this?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=535470504-21052009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=535470504-21052009><FONT color=#0000ff
size=2 face=Arial>Alec Davis</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=535470504-21052009> </SPAN></DIV>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left><FONT size=2
face=Tahoma><B>From:</B> asterisk-dev-bounces@lists.digium.com
[mailto:asterisk-dev-bounces@lists.digium.com] <B>On Behalf Of </B>Alec
Davis<BR><B>Sent:</B> Tuesday, 19 May 2009 10:29 p.m.<BR><B>To:</B> 'Asterisk
Developers Mailing List'<BR><B>Subject:</B> [asterisk-dev] 'sip unregister
devicename' device unavaiable 25/3600 seconds<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial>The 3600 in the
subject assumes a sip registration period of 60 minutes.</FONT></SPAN></DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial>refer <A
href="https://issues.asterisk.org/view.php?id=15118">https://issues.asterisk.org/view.php?id=15118</A></FONT></SPAN></DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial><SPAN
class=072295409-19052009><FONT size=2 face=Arial>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial>The testing and
reporting of the bug was done with a Grandstream BT100, but it is no way a
reflection on Grandstream.</FONT></SPAN></DIV>
<DIV><SPAN
class=072295409-19052009></SPAN> </DIV></FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial><SPAN
class=072295409-19052009><FONT size=2 face=Arial>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.</FONT></SPAN></DIV>
<DIV><SPAN class=072295409-19052009></SPAN> </DIV>
<DIV><SPAN class=072295409-19052009>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.</SPAN></DIV>
<DIV><SPAN class=072295409-19052009></SPAN> </DIV></FONT></SPAN>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial>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...</FONT></SPAN></DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial>If a device has a
re-register time of 3600 seconds, the phone is unavailable for 3575 seconds in
every 3600.!!!</FONT></SPAN></DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial>There are 2
patches:</FONT></SPAN></DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial>1st targets the
sip_unregister problem directly, its removes the current active expire_register
callback scheduled event.</FONT></SPAN></DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial>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.</FONT></SPAN></DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial>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.</FONT></SPAN></DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2 face=Arial>Alec
Davis.</FONT></SPAN></DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=072295409-19052009><FONT size=2
face=Arial></FONT></SPAN> </DIV></BODY></HTML>