[asterisk-bugs] [Asterisk 0012680]: Extension state change random delay

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12680 
====================================================================== 
Reported By:                corruptor
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12680
Category:                   Channels/chan_sip/Subscriptions
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.20 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-19-2008 05:04 CDT
Last Modified:              07-10-2008 12:34 CDT
====================================================================== 
Summary:                    Extension state change random delay
Description: 
asterisk-1.4.20-rc3
Grandstream GXP-2000 is registered as 1100 and subscribed to receive
changes about extensions states. 
SIP/1101 is Linksys 942
SIP/1102 is SjPhone.
I've also set notifyringing=yes.

1102 calls 1101. 1101 sends RINGING but asterisk sends NOTIFY to
Grandstream with 3 sec delay. You can see (log is attached) that RINGING
was at 19:11:27 and NOTIFY is sent at 19:11:30.
Later when 1101 answers you can see that device state is changed 9 seconds
after call have been established (19:11:50] DEBUG[24559] devicestate.c:
Changing state for SIP/1102-09551818 - state 4 (Invalid))
When call is over asterisk changes state for one of the extensions almost
instantly but there is 20 seconds delay for 1102 (19:12:20).
Please help to debug this problem.
====================================================================== 

---------------------------------------------------------------------- 
 davidw - 07-10-08 12:34  
---------------------------------------------------------------------- 
The race condition exists because the state change is queued.  It could
only be removed if all queue member states, referencing the same device,
were locked until the update completes, in which case you might as well
update the state directly and synchronously!  DNS failures could increase
the size of the failure window, but http://bugs.digium.com/view.php?id=12771
only needs a very small time
window.  The resulting symptom is harmless, but it indicates an exposure
that could catch actual calls.

DNS failures may well account for this case, however, we have also had
reports that the disk controller is broken.  They are not relevant to
http://bugs.digium.com/view.php?id=12771.  Basically the race condition is not
ficticious. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-10-08 12:34  davidw         Note Added: 0090030                          
======================================================================