[asterisk-bugs] [Asterisk 0016733]: Setvar DEVICE_STATE manager action occasionally ignored.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16733 
====================================================================== 
Reported By:                kebl0155
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16733
Category:                   Functions/func_devstate
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.2.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-01-29 11:07 CST
Last Modified:              2010-02-05 06:06 CST
====================================================================== 
Summary:                    Setvar DEVICE_STATE manager action occasionally
ignored.
Description: 
We use Manager to control DEVICE_STATE information to support ringinuse=no
for local channels.

Though acknowledged by asterisk, commands to set to NOT_INUSE are
sometimes ignored, which then stops further calls being routed to the
agent.

This is an intermittent fault, affecting perhaps one in 

We have seen this in Asterisk 1.6.1.9 and 1.6.2.1
====================================================================== 

---------------------------------------------------------------------- 
 (0117777) kebl0155 (reporter) - 2010-02-05 06:06
 https://issues.asterisk.org/view.php?id=16733#c117777 
---------------------------------------------------------------------- 
OK the patch from 0016607 does seem to have fixed it in 1.6.1.9.  I am
trying 1.6.2.0 today, which is the most recent version we can run.

I have noticed that it is sometimes sending two dial attempts at once
though:

<previous dial times out>
    -- Nobody picked up in 10000 ms
    -- Hungup 'DAHDI/11-1'
  == Spawn extension (agentdial, 0007, 2) exited non-zero on
'Local/0007 at agentdial-3870;2'

<new dial launched>
    -- Called Local/0007 at agentdial
    -- Executing [0007 at agentdial:1] Set("Local/0007 at agentdial-e3a2;2",
"__TRANSFER_CONTEXT=transfer") in new stack
    -- Executing [0007 at agentdial:2] Dial("Local/0007 at agentdial-e3a2;2",
"DAHDI/r2/0007,,tTro") in new stack
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called r2/0007
    -- Local/0007 at agentdial-e3a2;1 is ringing

<then this happens straight away - it doesn't actually time out>
    -- Nobody picked up in 10000 ms
    -- Hungup 'DAHDI/12-1'
  == Spawn extension (agentdial, 0007, 2) exited non-zero on
'Local/0007 at agentdial-7f1d;2'

<again this is happening straight away - it doesn't actually time out>
    -- Nobody picked up in 10000 ms
    -- Hungup 'DAHDI/13-1'
  == Spawn extension (agentdial, 0007, 2) exited non-zero on
'Local/0007 at agentdial-5412;2'
    -- DAHDI/14-1 is proceeding passing it to Local/0007 at agentdial-e3a2;2
    -- DAHDI/14-1 is ringing
    -- Local/0007 at agentdial-e3a2;1 is ringing
    -- Executing [0007 at agentdial:1] Set("Local/0007 at agentdial-181a;2",
"__TRANSFER_CONTEXT=transfer") in new stack
    -- Executing [0007 at agentdial:2] Dial("Local/0007 at agentdial-181a;2",
"DAHDI/r2/0007,,tTro") in new stack
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called Local/0007 at agentdial
    -- Called r2/0007
    -- Local/0007 at agentdial-181a;1 is ringing
    -- Executing [0007 at agentdial:1] Set("Local/0007 at agentdial-bf0a;2",
"__TRANSFER_CONTEXT=transfer") in new stack
    -- Called Local/0007 at agentdial
    -- Executing [0007 at agentdial:2] Dial("Local/0007 at agentdial-bf0a;2",
"DAHDI/r2/0007,,tTro") in new stack

It looks like there's something broken with the timeout parameter. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-02-05 06:06 kebl0155       Note Added: 0117777                          
======================================================================