[asterisk-bugs] [Asterisk 0014359]: The status of a local channel in state_interface of a queue is wrong the first time is added and lost after a reload

Asterisk Bug Tracker noreply at bugs.digium.com
Fri Jan 30 13:09:02 CST 2009


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14359 
====================================================================== 
Reported By:                francesco_r
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   14359
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.0.5 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-01-29 04:20 CST
Last Modified:              2009-01-30 13:09 CST
====================================================================== 
Summary:                    The status of a local channel in state_interface of
a queue is wrong the first time is added and lost after a reload
Description: 
I use the new feature of stateinterface parameter to monitor the status of
a real device when used with local channel as member. So for example if i
add to queues.conf a static member:
member=Local/2503 at from-internal/n,0,,SIP/2503
whit queue show i have:
Local/2503 at from-internal/n (Not in use) has taken no calls yet

But this is wrong because this member is not registered and unavailable.
Infact if i convert the member to SIP/2503 the status become correctly:
SIP/2503 (Unavailable) has taken no calls yet

Other problem: if 2503 use the phone with queue show i have correctly:
Local/2503 at from-internal/n (In use) has taken no calls yet
But if in this exact moment i do a reload the status become newly:
Local/2503 at from-internal/n (Not in use) has taken no calls yet

====================================================================== 

---------------------------------------------------------------------- 
 (0099142) putnopvut (administrator) - 2009-01-30 13:09
 http://bugs.digium.com/view.php?id=14359#c99142 
---------------------------------------------------------------------- 
Bad news. I could not reproduce either of these problems using 1.6.0.5 or
the latest svn checkout of the 1.6.0 branch.

Regarding the first issue you reported, using a SIP channel directly or as
the state interface for a local channel produced the same results for me. I
looked in chan_sip.c and found that the condition under which it will
report "unavailable" is if you have qualify set in sip.conf and the peer is
determined to be unreachable through this means. In all my testing, it made
no difference which method I used for specifying queue members. I'll
describe the state changes I saw.

I set this test up by setting qualify=yes on one of my SIP peers and then
unplugging the phone from the network and starting Asterisk. When Asterisk
started up, I issued a queue show command and saw that my queue member was
"not in use." Very soon after, I saw a notice that the SIP peer was
unreachable. After that, issuing a queue show command showed the interface
as "unavailable." Keep in mind what I said above. No matter whether I used
a local channel with a SIP state interface or used a SIP channel directly,
the results were the same.

Regarding the second issue you reported, I just plain could not reproduce
it at all. All attempts at reloading while a queue member was "in use" did
not change his status.

I'd like to fix these issues one-at-a-time, so let's concentrate first on
the issue where the local channel with a state interface behaves
differently than a SIP channel regarding the "not in use" and "unavailable"
states. Since you listed the reproducibility as "always" I'm assuming that
this occurs consistently. Does the problem "correct" itself after a period
of time? I'm a bit at a loss here since I thought this would be easy to
reproduce. Right now, I think it may help if you could upload the CLI
output from when Asterisk starts up with debug and verbose levels set to at
least 3. That way, I may be able to see where the device state errors are. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-30 13:09 putnopvut      Note Added: 0099142                          
======================================================================




More information about the asterisk-bugs mailing list