[Home]

Summary:ASTERISK-26621: app_queue: Queue application does not ring members with Local interface
Reporter:Jonas Kellens (jonaskellens)Labels:
Date Opened:2016-11-23 08:35:22.000-0600Date Closed:2016-12-19 12:41:49.000-0600
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Applications/app_queue
Versions:13.12.2 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Linux 2.6.32-642.4.2.el6.x86_64Attachments:( 0) debug.log
( 1) debug.txt
( 2) dialplan_output.txt
Description:It seems that once a member of the queue can not be reached due to the fact that it is busy in another call, this queue member is never again being called by the queue application !

Important : I can reproduce this every time again and again.

I demonstrate this with 3 calls where everytime the incoming call is directed to the Queue() application.

Call 1 : both queue members are being called (normal behaviour, everything is fine)
Call 2 : only one member is being called, queue member mysip467 is busy in another conversation (still normal behaviour, everything is fine)
Call 3 : only one member is being called, queue member mysip467 is no longer in another conversation thus should also be called again (not normal behaviour, only mysip517 is being called)

I have attached the dialplan output on the CLI (dialplan_output.txt)


If a queue member (in my example mysip467) states to the Queue application that it is busy and can not take a call, it seems that the Queue application remembers this forever and never again sends a call to this queue member. Even if the member is available again.

The queue member mysip467 is not occupied with any call. But still it is never again being called by the queue application. Never again, until a restart of Asterisk off course.

Core debug output attached (debug.txt).
Comments:By: Asterisk Team (asteriskteam) 2016-11-23 08:35:24.219-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Rusty Newton (rnewton) 2016-11-23 16:11:15.875-0600

Thanks for the report! In order to maximize efficiently, there are project guidelines for how to report issues. Please read through the Asterisk Issue Guidelines [1]. After reading the guidelines, please clean up this issue so that bug marshals can more easily help you.

In particular:
1. Don't post extensive debug or logs inside the Description or Comment fields.
2. Use the Description field for a description of the issue, referencing *attached* debug with links or notes.
3. Use the Comment fields for discussion regarding the issue.
4. If you need to put a few lines of debug or logs into any field, surround the text with "noformat" tags to help us read it easily.
5. Attach files with a '.txt' extension where possible so that they can be analyzed futher by bug marshals.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines



By: Jonas Kellens (jonaskellens) 2016-11-24 05:34:29.763-0600

Guidelines respected now. Issue cleaned up.

By: Joshua C. Colp (jcolp) 2016-11-28 06:31:45.894-0600

I see that you are using realtime queue members, can you also provide an example queue and queue members? And when you mean busy in another conversation do you mean one from the queue or outside of the queue?

By: Johan Bernhardsson (smallone) 2016-12-01 06:01:37.629-0600

I have this problem as well. I have realtime queue members on local channels and a hint on each to reflect their device status.

It seems even if the member is marked as available in the queue that they still are busy somehow within the queue.

Example:
halsafranmig_HalsaFranMig has 1 calls (max unlimited) in 'ringall' strategy (5s holdtime, 36s talktime), W:0, C:3, A:14, SL:0.0% within 0s
  Members:
     5550 (Local/5550@halsafranmig from hint:5550@halsafranmig) (ringinuse disabled) (realtime) (Not in use) has taken 1 calls (last was 2472 secs ago)
  Callers:
     1. SIP/trunk-0002bd3c (wait: 0:08, prio: 0)


This caller here is not forwarded out on the local channel


By: Johan Bernhardsson (smallone) 2016-12-01 06:58:39.969-0600

[Dec  1 12:03:52] DEBUG[5069][C-0001a2d7] app_queue.c: There is 1 available member.
[Dec  1 12:03:52] DEBUG[5069][C-0001a2d7] app_queue.c: It's our turn (SIP/trunk-0002bada).
[Dec  1 12:03:52] DEBUG[5069][C-0001a2d7] app_queue.c: SIP/trunk-0002bada is trying to call a queue member.
[Dec  1 12:03:52] DEBUG[5069][C-0001a2d7] app_queue.c: (Parallel) Trying 'Local/5550@halsafranmig' with metric 0
[Dec  1 12:03:52] DEBUG[5069][C-0001a2d7] app_queue.c: Local/5550@halsafranmig has another call trying, can't receive call
[Dec  1 12:03:52] DEBUG[5069][C-0001a2d7] app_queue.c: Nobody left to try ringing in queue
[Dec  1 12:03:52] DEBUG[5069][C-0001a2d7] app_queue.c: Everyone is busy at this time


This is how it looks like in the debug log. The local channel has no calls trying and the hint says available in both the queue and the hint.  So some call is stuck somewhere

By: Filip Jenicek (phill) 2016-12-01 07:05:42.438-0600

Hi,

it happens to me as well. The problem is in function update_status which doesn't remove a member from pending_members, because m->status=status=AST_DEVICE_NOT_INUSE.

I am able to reproduce it with a call queue with one static member, which is a local channel routed out over a sip interface. If the destination number is busy, the member will never be deleted from pending_members.

I am attaching a detailed debug.log with some additional logging (grep "pending_memebers").

To work around it, one can replace the
{code}if (m->status != status) { {code}
by {code} if (1) { {code}



By: Marek Cervenka (cervajs) 2016-12-05 07:05:21.492-0600

replicated on ast 13.13.0

By: Johan Bernhardsson (smallone) 2016-12-06 06:13:50.496-0600

The work around doesnt seem to work for me. I still have quite a lot of queues with stuck members. I can work it by removing and adding the member again.

As i went from asterisk 11 to asterisk 13.12.2 has anyone had the time to check in witch asterisk version the bug appeared ?

I have replicated it in 13.12.0, 13.12.1, 13.12.2 and 13.13.0 so far

By: Marek Cervenka (cervajs) 2016-12-06 08:27:22.313-0600

the last working version is 13.9

By: Marek Cervenka (cervajs) 2016-12-06 08:30:25.361-0600

bad fix went into asterisk in this issue ASTERISK-26299

By: Marian Piater (maikyp) 2016-12-06 09:56:29.044-0600

Thanks for this thread. Few months ago I saw probably same problem with stuck member in 13.10. I used the ringall strategy and as I read from a log, a one member stuck when two ringing members answered call at the same time. Members was added to a queue with local interface.

By: Martin Tomec (matesstar) 2016-12-12 10:44:56.699-0600

There is small patch in code review, if somebody wants to test it (or need quick workaround):
https://gerrit.asterisk.org/#/c/4613/

By: Johan Bernhardsson (smallone) 2016-12-12 13:37:45.978-0600

I'll see if i can try it tomorrow.

Seems like 13.09 was not working either. And it might be the fix for ASTERISK-19820 that is the commit that broke stuff. (Correct me if I'm wrong in guessing this)




By: Friendly Automation (friendly-automation) 2016-12-19 12:41:51.558-0600

Change 4611 merged by zuul:
app_queue: Ensure member is removed from pending when hanging up.

[https://gerrit.asterisk.org/4611|https://gerrit.asterisk.org/4611]

By: Friendly Automation (friendly-automation) 2016-12-19 12:44:00.020-0600

Change 4612 merged by Joshua Colp:
app_queue: Ensure member is removed from pending when hanging up.

[https://gerrit.asterisk.org/4612|https://gerrit.asterisk.org/4612]

By: Friendly Automation (friendly-automation) 2016-12-19 13:33:09.340-0600

Change 4613 merged by Joshua Colp:
app_queue: Ensure member is removed from pending when hanging up.

[https://gerrit.asterisk.org/4613|https://gerrit.asterisk.org/4613]

By: Friendly Automation (friendly-automation) 2017-01-26 16:03:10.602-0600

Change 4813 merged by George Joseph:
app_queue: Ensure member is removed from pending when hanging up.

[https://gerrit.asterisk.org/4813|https://gerrit.asterisk.org/4813]

By: Friendly Automation (friendly-automation) 2017-01-27 15:51:45.244-0600

Change 4816 merged by George Joseph:
app_queue: Ensure member is removed from pending when hanging up.

[https://gerrit.asterisk.org/4816|https://gerrit.asterisk.org/4816]