| Summary: | ASTERISK-25064: Members (ringinuse disabled) of multiple queues ringing with other queue calls. | ||||
| Reporter: | Chet Stevens (cwstevens) | Labels: | |||
| Date Opened: | 2015-05-05 17:37:56 | Date Closed: | 2016-04-26 10:31:45 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Applications/app_queue | ||
| Versions: | 13.1.0 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Asterisk 13.1-cert2 Ubuntu Server 14.04.1 LTS (GNU/Linux 3.13.0-37-generic x86_64) HP ProLiant DL380p Gen8 with 16 GB memory Wildcard AEX2400: wctdm24xxp+ Wildcard TE420 (5th Gen): wct4xxp+ | Attachments: | ( 0) debug_ASTERISK-25064.txt | ||
| Description: | After upgrading from Asterisk 11.6-cert9 to Asterisk 13.1-cert2, queue members with "ringinuse disabled" that belong to multiple queues are ringing with calls from other queues while already in use. "queue show queue1", "queue show queue2", etc does accurately show the members as "ringinuse disabled" and "In use". For example:
local/6103@agents (ringinuse disabled) (dynamic) (Not in use) has taken 37 calls (last was 76 secs ago) We use Local channels so additional dialplan can be executed before ringing members (play agent greeting etc) so members are added to the queues in the following manner: AddQueueMember(technical,local/6103@agents,,,,SIP/6103_line) I will attach a debug log. If you search on "Executing [6103@agents:1]" you will see three separate calls all being routed to the same member. Any additional information can be provided (configuration, dialplan, etc). | ||||
| Comments: | By: Chet Stevens (cwstevens) 2015-05-05 17:42:28.798-0500 This is one second of debug log. If you search on "Executing [6103@agents:1]" you can see three different calls from queues being sent to the queue member. Much more debug log is available if needed. By: Richard Mudgett (rmudgett) 2015-05-05 18:38:06.695-0500 I'm fairly certain that this is the same issue as ASTERISK-16115. By: Chet Stevens (cwstevens) 2015-05-06 10:00:29.292-0500 I added in some NoOps in the {{agents}} context just prior to ringing the member to see what state we think the member to be in: {noformat} NoOp(AGENT IS IN STATE ${DEVICE_STATE(SIP/${EXTEN}_line)} and we are sending ${caller_number} to them.) {noformat} Surprisingly DEVICE_STATE always states the member as NOT_INUSE even though they are actually in use and we continue to get complaints with members ringing with 2 or 3 simultaneous calls. For example: {noformat} [May 6 07:48:42] -- Executing [6102@agents:6] NoOp("Local/6102@agents-00001469;2", "AGENT IS IN STATE NOT_INUSE and we are sending 7027996300 to them.") in new stack [May 6 07:49:27] -- Executing [6102@agents:6] NoOp("Local/6102@agents-0000146a;2", "AGENT IS IN STATE NOT_INUSE and we are sending 7027996300 to them.") in new stack [May 6 07:49:50] -- Executing [6102@agents:6] NoOp("Local/6102@agents-0000146b;2", "AGENT IS IN STATE NOT_INUSE and we are sending 7027997904 to them.") in new stack {noformat} Is it possible the problem is in Chan_SIP? I was hoping to put a work around in to throw the call back into the queue at position 1 if we see them as INUSE. Thank you. Should I continue to add comments here or in ASTERISK-16115? By: Richard Mudgett (rmudgett) 2015-05-06 12:25:20.744-0500 The problem is when a queue in {{app_queue}} sends a call to an agent the state of the agent does not change immediately. Until the agent state posted by the channel driver propagates back to {{app_queue}}, any other queues (including the same queue) the agent is a member of can pick the agent for their calls. Once the agent state propagates back to {{app_queue}} then the queues know the agent is no longer available. However, as you have experienced, the agent can receive several calls in the mean time. By: Chet Stevens (cwstevens) 2015-05-07 09:36:46.122-0500 Yes, I was under the impression from the users that calls were ringing to agents that were on a call. The problem is, as you described, that multiple calls are ringing to the same agent at the same time. My earlier NoOp copy/paste isn't a good example. With more investigation I find that the problem calls look more like this: {noformat} [May 6 07:48:00] -- Executing [6102@agents:6] NoOp("Local/6102@agents-00001469;2", "AGENT IS IN STATE NOT_INUSE and we are sending 7027991234 to them.") in new stack [May 6 07:48:01] -- Executing [6102@agents:6] NoOp("Local/6102@agents-0000146a;2", "AGENT IS IN STATE RINGING and we are sending 18885551234 to them.") in new stack [May 6 07:48:01] -- Executing [6102@agents:6] NoOp("Local/6102@agents-0000146b;2", "AGENT IS IN STATE RINGING and we are sending 7025551111 to them.") in new stack {noformat} As a workaround I have added a check in the dialplan to see if the device is already ringing: {noformat} same => n,GotoIf($[${DEVICE_STATE(SIP/${EXTEN}_line)} = RINGING]?:dial) same => n,Queue(${queue},,,,,,,,,1) same => n(dial),Dial(SIP/${EXTEN}_line,,A(${queue_file})) {noformat} If it is ringing then we put the caller back into the queue the call is coming from at position 1, otherwise, we dial the member. This isn't a very good solution as we can't account for which caller was waiting longer (the caller waiting 5 minutes might have their call taken before the caller that was waiting an hour) and I assume when the caller is put back into the queue they will hear any "estimated wait time", etc that has been configured. I know we had this problem in the past and, if I remember correctly, we downgraded from 11.6 to 11.2 and the reports of it stopped. Thank you. | ||||