i recently introduced queues so i could glean some better reporting stats with the use of Asternic.
i have recently had a few reports of someone receiving a call and when they answered it they had actually answered 2 calls at the same time.
the queue structure we have is it calls support then fails over to a ring all queue, now this person is also in the ring all queue too.
it appears they went to answer the call initially but missed it the call then bounced through to everyone and when she went to answer answered another call coming into the queue along with the previous call so could hear 2 calls at once
we are using bria softphones, anyone ever come across this or have any ideas where i can start, i’ve checked the queue settings and nothing seems problematic here.
Sounds pretty “one-off”, so we’ll need to see some logs:
Logs - ./var/log/asterisk/full
Also, review https://wiki.freepbx.org/display/SUP/Providing+Great+Debug#ProvidingGreatDebug-AsteriskLogs
i was thinking it was a one off until it was reported again by the same user which made me feel it was more specific to their setup.
thanks for the documentation i’m trying to search the log as described here:
now when i locate the unique id and run this command i don’t see any output.
ok so i ran the following command
the incident happened at 13.47 but this doesn’t seem to show too much info extension in question was 161
ok i’ve found the log and there is a lot going on i’ll edit and see if i can remove any sensitive info, and re post unless i could pm it over?
Just for giggles (and because I’ve seen stranger), are you using the same extension number across a bunch of phones? Say, instead of a queue, all of the phones are just extension 161? If not, just ignore and press on with your current line of thought.
ha i wish it was that simple Dave no everyone has an individual extension we have around 4 queues then a catch all group. i’ve managed to grab all the logs from the time it was reported but i’ll be honest it doesn’t mean a whole bunch to me, would you mind casting a knowing eye over them see if anything jumps out
How long does a caller sit in the main queue before going to the “failover”?
the time out for the queue is 20 secs.
Why are you using a Queue like a Ring Group? That would be part of the problem right there. You shouldn’t be attempting to call the agents once and them roll them over. The point of a Queue is in its name, to queue your callers. You have basically given yourself a “call race” in which the same agent belongs to multiple queues and calls are “racing” between them to hit the agent.
You should keep your callers in the support queue and attempt your agents a few times before sending them over to another queue or failover. You should also have your queues setup so they won’t call an agent that is “shared” among them when said agent is already on a queue call.
This sounds like you need to re-work your queue logic.
Hey Tom, good question i wish you’d have been available to discuss this a few months ago
so we were previously using ring groups, our basic setup is ivr press 1 support 2 accounts etc with a failover to an everyone ring group if a call not answered. the reason for this is the company have a preference to all calls being answered by someone even if it isn’t that department.
now this worked well for a while but was a nightmare trying to get any useful reporting out of it i can grab the link to the previous post, but basically i couldn’t get an accurate read on calls missed by a certain team, if anyone can help with that i’m happy to revisit and go back to ring groups.
so that’s why i switched to queues to get better reporting - its a little messy but achieves the goal apart from this incident that was reported - i fully appreciate what you are saying re the “call race” but for now the business want calls to failover to everyone.
if anyone can solve my ring group stats query then i’d love to go back to it as it did work quite nicely
There isn’t. Ring Groups are not an actual thing, they are a concept. It just calls a bunch of devices at once (or how you wish to ring them). Nothing monitors a Ring Group, there are no hints or BLF’s for Ring Groups. There is nothing that makes it ‘trackable’ or anything.
Queues are a thing and they have their own rules and methods for how to hold and send calls to members in the Queue. If you’re going to try a mimic your Ring Group setup then you’re going to have your call race issue. Like I said you can tell the Queues not to call members that are busy on other calls in another Queue but still will have a bit of a call race as the queues won’t see the user busy until they are on an actual call.
What “useful reporting” are you trying to get out of this for these Ring Groups?
Thanks Tom that kind of answers what i have found out the long way round,
the basic stats i couldn’t achieve were received and missed. the scenario being if i was trying to track calls missed by ring group 1 because ring group 1 contained say 3 extensions 101,102,103
if extension 1 answered the call, because of the ring all strategy my report would show that i had received the call 3 times it was answered once but missed (or not answered) twice
then if i ran a report for calls received it would show i had received 3 calls.
all this on 1 call - while i agree visually it gives me a true representation on the call flow i couldn’t then generate a useful report to management on received answered missed etc.
would love a way to achieve that report.
happy to post an example.
From a practical perspective, you want to use a queue, but you want to use it the way it is intended to be used. Instead of timing out of the queue at 20 seconds, let the queue ring until it fails over to your voicemail/last ditch effort destination.
The situation you are describing in CDR is always going to be a problem with Ring Groups. Using a queue gives you a lot of management insight as well as a lot of control over how the calls ring. I think you can get where you are wanting to go without the effect you are seeing just by extending your queue options. Let your people know that the original problem will be solved by tuning the system over the next few weeks and work with your queue options until you get what works for you.
thanks for the sanity check here guys, it has confirmed we need to revisit the way our calls are handled,
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.