Summary:ASTERISK-12248: Multiple incoming call to free agent
Reporter:Sergey G (sgenyuk)Labels:
Date Opened:2008-06-23 10:00:26Date Closed:2008-08-07 11:42:21
Versions:Frequency of
Environment:Attachments:( 0) app_queue.patch.txt
Description:when agent become available during hight call volume in the queue he might receive multiple calls. Like if agent has 6 lines on the phone it receive 6 different calls one per line.


Does not depend from version, able to replicate in all 1.4.XX.
Comments:By: Mark Michelson (mmichelson) 2008-06-23 10:18:19

I need to get a few things straight before I continue investigating this bug report.

1. Do your queues have ringinuse=no set?
2. If you do have ringinuse=no set and you are using SIP phones, do you have a call-limit set for each SIP peer in sip.conf?
3. What ring strategy are you using for your queue members?
4. When the agent receives six calls at once, are all the calls coming from different queues or do they come from the same queue?
5. Are you using autofill for your queues?

I think this information will be enough to paint a clearer picture of the situation for now.

By: David Woolley (davidw) 2008-06-23 10:18:32

Is this really an Agent, or just an ordinary member?  Are you using AgentLogin?

I think this may be related to ASTERISK-12125.  (Although this is currently closed, the patch that it is suggested will fix this is not stable enough for me to veryify this yet.)

By: David Woolley (davidw) 2008-06-23 10:33:55

To answer part of my own question, you can't be using AgentLogin, as that wouldn't result in multiple calls on the same phone.

By: Sergey G (sgenyuk) 2008-06-23 10:43:11

1. Do your queues have ringinuse=no set? Yes

2. If you do have ringinuse=no set and you are using SIP phones, do you have a call-limit set for each SIP peer in sip.conf?
2 lines per agent as they use second line for outbound test. And 6 lines per supervisor.

3. What ring strategy are you using for your queue members?

Tested with all types. Using round robin for now.

4. When the agent receives six calls at once, are all the calls coming from different queues or do they come from the same queue?

Really cannot answer this question as agent registered in 2 queues.

5. Are you using autofill for your queues?

autofill is off.

By: Sergey G (sgenyuk) 2008-06-23 10:50:17

Probably it not looks like 0012771. I do not have any messages in the queue, agent never will receive second call if agent is busy. It just send multiple calls when agent is available.

By: David Woolley (davidw) 2008-06-24 04:28:47

ASTERISK-12125 is a race condition that means that the agent isn't effectively marked busy immediately.  Its potential failure mode is to cause multiple calls to be accepted for an idle agent.  I don't understand your reference to messages, and the failure mode would be "multiple calls when agent is available".

What I don't know for certain is whether it generalises to AgentCallBackLogin or queue members that aren't really Agents, which is why I asked about the nature of your agents.  Also, that it will cause multiple calls to be accepted is speculation, based on their being a real delay between the agent being allocated the call and the queue considering the agent busy.

It would be instructive to know if you are getting the warning mentioned in that issue; putnopvut's second question is specifically about the issue that is mentioned in that warning message.  Note that, for a real Agent, or when you reach the call limit, it is conceivable that the status update would have been completed by the time the message would be generated, but not by the time that the system tried to offer the second and subsequent calls, so the absence of the warning is not proof that the issues to which it relates don't apply.

(I suspect, when putnopvut refers to having call limits set, he actually means having them set to one.)

The reason that I assume that you are not using AgentLogin, is that there is only one channel associated with AgentLogin, so any failure mode would result in incoming calls being lost, or overriding earlier ones.  Some people use Agent in a generic sense, rather than to mean Agent/xxxxx, which is why I was asking whether you really meant Agents.

By: Emmanuel BUU (neutrino88) 2008-06-30 03:47:40

We have reproduced the bug here using the SIPP simulator. There is indeed an issue.

Here is a proposal of fix. In the function ring_entry() it seems that the status of the member is updated just before the call is placed and not after. Of course the device status callback causes the status to be updated but there is a small amount of time between the call launch an the 'ringing' event when other call could be presented to the same agent.

Therefore, we propose the following patch:

[[[patch removed]]]

Note also that the call to update_status( ) done right after ast_request() could be removed.


By: David Woolley (davidw) 2008-06-30 05:00:33

You might want to note that patches submitted as comments get deleted.  To submit a patch, you need to agree the submission licence, and then attach the patch, and tick the "code or documentation" box.

By: David Brillert (aragon) 2008-07-02 15:03:37

sgenyuk have you tested your patch in production?
Is it working?

I have a customer with same problem and I have been monitoring bugs 12771 and 12773.
These bugs did not seem to relate to my problem since patch is written for chan_agent and I don't use chan_agent

By: Sergey G (sgenyuk) 2008-07-02 15:27:27

I am going to patch my Asterisk and do test. It will take a couple of days.

By: Sergey G (sgenyuk) 2008-07-14 13:08:06

This patch works. Tested during whole week under different calls loads did not get complanes from my agents anymore.

Thank you.

By: David Brillert (aragon) 2008-07-29 07:36:13

We have also tested this patch and no longer get complaints of multiple calls to same agent.

By: Joel Vandal (jvandal) 2008-07-29 07:40:02

Does someone need to repost a cleaned patch that pass the formatting review (i.e. remove useless comments, etc)

By: Digium Subversion (svnbot) 2008-08-07 11:42:15

Repository: asterisk
Revision: 136488

U   branches/1.4/apps/app_queue.c

r136488 | tilghman | 2008-08-07 11:42:14 -0500 (Thu, 07 Aug 2008) | 7 lines

Update persistent state on all exit conditions.
(closes issue ASTERISK-12248)
Reported by: sgenyuk
      app_queue.patch.txt uploaded by neutrino88 (license 297)
Tested by: sgenyuk, aragon