Review Board 1.7.16

app_queue: Fix for queue members receiving calls when in call and with ringinuse=no

Review Request #3409 - Created March 30, 2014 and updated

Shlomi Gutman
In some cases when member in talk (IN_USE) and you run "sip reload" or peer has connectivity problems (reachable->unreachable/lagged->reachable) the status of peer is set to NOT_INUSE, while he is still talking.
The patch adds function that would check if member has any active channel. And would consider him IN_USE if does and if not, would do nothing, as you can't detect what is the state of member if he has no channel.

Originally patch was used on (can apply it to reviewboard as well) and 11.6-cert1. As well as in my case all peers, queues, memebrs are realtime. But as David Brillert reported in bug, he is not using realtime peers, so it's used for all peers.

The patch works, the question is if it's the best solution and it would not introduce any regressions.
Used in production on 1.8 and 11 and customers having problems approved that problem was resolved.
Review request changed
Updated (April 2, 2014, 7:48 a.m.)
Tried to follow Guidelines and deleted all the extra white spaces.

This patch is important that it double checks the status of member if and it is based on if he has open channel, and if he does he is in call 100%.
Before patch i tried to use the previous functions but it always returned false results.
I'll repeat that in my case i use realtime configuration both for queue members and for peers(sip devices) so it might be related. In my case as well i do run my function only if it's realtime config (call->member->realtime). I deleted it so people with not realtime config can approve if it fixes or not their issues.
Posted (April 26, 2014, 6:10 a.m.)
After talking on Twitter I believe I understand what is going on here.

When you do a "sip reload" any realtime peers in chan_sip are pruned and removed. This is probably causing the device state to change to an incorrect value which app_queue is then using. The change probably works around this by re-checking using any channels that exist.
  1. If that's the case, this solution still isn't the correct solution to the problem. The fact that the device state isn't being persisted correctly across the reload would point to a problem in chan_sip.
    While I appreciate the attempt to fix this problem, adding complexity to an already complex module that doesn't address the root cause of this problem is not an appropriate solution. If you'd like to dig into the reload code in chan_sip to try and find why the realtime peers are getting the wrong device state, that'd be appreciated - I think everyone would be happy to discuss the situation more in #asterisk-dev or on the asterisk-dev mailing list. If you're interested in providing a patch that solves the problem where it is occurring, I'll keep this review open for that patch - otherwise, barring any objections, I'll close this out in a few days.
  2. So I have to wonder - is this problem solved by the approach on runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to