vicidial.org

Method: ingroup with 5 agents
Next Agent Call: ring_all
Phones: on hook softphones

Problem: When a call comes in and you answer the call and then while you are in dead time the next caller comes into the queue and you go to the dispo and are ready again the on hook phone does not ring immediately. There is a delay of about 10 seconds before it starts ringing.

This does not happen with other Next agent call methods like oldest_call_finish that i have tested.

Does anyone know how to fix this?

Ingroup call handling can allow for a "line" of calls awaiting the next caller to ring through. In the case of "ring-all" this can be a problem since that "i got it" must register properly before the next caller can proceed to any agent and all ringing lines must be killed. Otherwise, of course, everyone's phone would have multiple inbound simultaneous calls.

Consider that while YOU answered and then killed your inbound ring, others may in fact still be ringing. The code for that could be problematic.

However: Look at the "block" options available on the Ingroup Modify page. Turning off all possible "block" options (and anything else that may sound similar) may recover some of that time. Alternately, stepping away from "ring all" may be a good idea as well. That could allow different inbound lines to ring on different agent phones at the same time.

If you are actually looking for Speed, you should not be using OnHook agents at all. Really.

I understand your point Bill but then why does this work just fine on any other regular PBX?

I also proposed to use oldest_call_finish and off-hook phones but in this care there are valid arguments why this setup is used.

I checked the no block options. The only one that would be relevant in my case is :

The help text i find rather confusing:
Setting this option to Y will allow calls in line behind a call where the on hold prompt is playing to go to an agent if one becomes available while the message is playing. While the On Hold Prompt Filename message is playing to a customer they cannot be sent to an agent. Default is N.

'calls in line behind a call'? Why would you want that. It could theoretically mean a caller is waiting and other callers keep skipping ahead in front of the first caller endlessly?

I always have this setting disabled. I've always wondered why the on hold prompt needs to finish playing. This results in agents getting a call and then they have to wait for the customer to be done listening to the prompt before they can talk, resulting in the delayed alert sound. Would be better if the playing of the prompt could be interrupted halfway. But i don't think that setting this feature to Y does that? If it does, the help text should be changed.

dspaan wrote:I understand your point Bill but then why does this work just fine on any other regular PBX?

You say "this" as if other PBX's are using the same code/method for ACD/RingGroups/Ingroup/Queues and that they would operate the same but not have the same limitations. I assure you that they are not the same. Queues do not manage each call with an individualized script designed to find the first available agent as quickly as possible and (as such) rely on an "available!" signal to make that happen. In most of those cases they are using a passive queing system with an entirely different approach. However: I'm also not in any way saying that the behavior you are experiencing is in fact normal. I've never had this complaint from a client as nobody who wants fast call processing uses OnHook agents so we've never broached the topic at all.

dspaan wrote:I also proposed to use oldest_call_finish and off-hook phones but in this care there are valid arguments why this setup is used.

I'd love to hear those. Often these restrictions lead to other issues/solutions ...

dspaan wrote:I checked the no block options. The only one that would be relevant in my case is :

The help text i find rather confusing:
Setting this option to Y will allow calls in line behind a call where the on hold prompt is playing to go to an agent if one becomes available while the message is playing. While the On Hold Prompt Filename message is playing to a customer they cannot be sent to an agent. Default is N.

I'm a firm believer in sledgehammers. Change all the "diable block" options to Y so they will disable blocking.

dspaan wrote:'calls in line behind a call'? Why would you want that. It could theoretically mean a caller is waiting and other callers keep skipping ahead in front of the first caller endlessly?

The feature was added as a patch to resolve annoying behavior, but the original behavior is still the default and activating the "don't block" feature likely causes calisthenics within the code, perhaps even ugliness in the system that overuses CPU. But I'm guessing, as I was not there and haven't viewed the code. I just remember these popping up over time in response to requests (and likely payments).

dspaan wrote:I always have this setting disabled. I've always wondered why the on hold prompt needs to finish playing. This results in agents getting a call and then they have to wait for the customer to be done listening to the prompt before they can talk, resulting in the delayed alert sound. Would be better if the playing of the prompt could be interrupted halfway. But i don't think that setting this feature to Y does that? If it does, the help text should be changed.

There are often legal reasons and/or marketing reasons to NOT interrupt specific statements, that's why the feature exists and is presented as such. It's also likely that the code to allow interruption breaks some rules that annoy an engineer somewhere and/or cause heavy load to track instead of "let it go 'til it's done" which may not require nearly as much code/cpu power to manage. Toss it in blind is usually a much less intenstive process.

Just to be funny: Is this behavior specific to one server and not in other servers? Or at certain times but not others? Is this new behavior you're finding different than it was in the past? Or is this an "always been this way, always bothered me" scenario? Sorta looking to see if someone else already has a solution and you're just hoping someone will share?

And please tell me the server's not virtual ... lol

williamconley wrote:You say "this" as if other PBX's are using the same code/method for ACD/RingGroups/Ingroup/Queues and that they would operate the same but not have the same limitations. I assure you that they are not the same. Queues do not manage each call with an individualized script designed to find the first available agent as quickly as possible and (as such) rely on an "available!" signal to make that happen. In most of those cases they are using a passive queing system with an entirely different approach. However: I'm also not in any way saying that the behavior you are experiencing is in fact normal. I've never had this complaint from a client as nobody who wants fast call processing uses OnHook agents so we've never broached the topic at all.

We don't have many clients either who use on on-hook and none of them they have ever reported this. But i did test this myself on the client system and understand what they mean. If you disposition your current call and are in a ready state and you see the red text that a caller is in the queue then why does it still take 10 seconds in some cases before the on-hook phone starts ringing? I know vicidial is way different then regular PBX's but i can't imagine this is normal.

williamconley wrote:I'd love to hear those. Often these restrictions lead to other issues/solutions ...

The reasons are:
Low volume callcenter with a few agents logged in but 24x7
Lots of other work in between like e-mail and administrative tasks

williamconley wrote:I'm a firm believer in sledgehammers. Change all the "diable block" options to Y so they will disable blocking.

There are only 4 block options, the first is for on hold prompt, then you have estimated hold time minimum, wait time, hold time. But we rarely use the last 3.

williamconley wrote:There are often legal reasons and/or marketing reasons to NOT interrupt specific statements, that's why the feature exists and is presented as such. It's also likely that the code to allow interruption breaks some rules that annoy an engineer somewhere and/or cause heavy load to track instead of "let it go 'til it's done" which may not require nearly as much code/cpu power to manage. Toss it in blind is usually a much less intenstive process.

But i don't think this feature works like you and i hope it would. I tested it and it will keep playing the entire prompt before connecting it with the agent. This feature is intended for other callers in line to pass the caller who is listening to the on hold prompt, but i don't understand that feature if it works the way as it described.

williamconley wrote:Just to be funny: Is this behavior specific to one server and not in other servers? Or at certain times but not others? Is this new behavior you're finding different than it was in the past? Or is this an "always been this way, always bothered me" scenario? Sorta looking to see if someone else already has a solution and you're just hoping someone will share?

I also tested this on a development server and it behaves the same. I don't think it's new behavior. This is in fact the only server we have where ring_all is used that is why i've never noticed it. That also probably explains why i couldn't find anything in the forum about it. I was hoping there is another setting i could tweak to resolve this.

williamconley wrote:And please tell me the server's not virtual ... lol

Of course it's virtual, we only do virtual servers for years now. You don't think i'm going to buy hardware for a team with 5 agents?

Lots of other work in between like e-mail and administrative tasks

That's all computer work. No reason they can't be logged in to Vicidial while sitting at their workstation betting paid.

Low volume callcenter with a few agents logged in but 24x7

This I get, though. If they won't be getting a call for the next hour or so (possibly), Having the headset on is not viable.

But together these two items tend to make it more likely that the calls shouldn't be ring all, perhaps. Especially if one-at-a-time would result in different calls ringing on different workstations perhaps even simultaneously. Plus, the "longest wait time" option would more evenly distribute calls rather than "bob always answers" and "Mary just lets everyone else answer" scenario.

There are only 4 block options, the first is for on hold prompt, then you have estimated hold time minimum, wait time, hold time. But we rarely use the last 3.

You skipped over the sledgehammer comment. This isn't about what you use. This is about "try everything at once, if that fixes it, now you can try to narrow down WHY, if it doesn't ... then none of those are relevant". Note that this is linux-world, just because it *shouldn't* be relevant in no way means it isn't, lol. Welcome to the Matrix: Some rules can be bent, other broken.

But i don't think this feature works like you and i hope it would. I tested it and it will keep playing the entire prompt before connecting it with the agent. This feature is intended for other callers in line to pass the caller who is listening to the on hold prompt, but i don't understand that feature if it works the way as it described.

Sledgehammer. I've found dozens of cases where it wasn't the setting I thought it was. That's why I try *all* of them. Sometimes it's an understanding issue, sometimes it's coding error, sometimes it's a difference of opinion between myself and some nameless engineer (who should be slapped) who wrote this code snippet a decade ago regarding semantics.

But i did test this myself on the client system...

I also tested this on a development server and it behaves the same.

Of course it's virtual ...

I would strongly suggest you test this in a physical server before the verdict. Hi-Res perl timing required for the scripts managing inbound calls is labor intensive. If you can, of course.

Another approach (which we've used a few times) is a hybrid: Put an Asterisk Queue in that ingroup. You'll have to play a game with the agent screen to get the client-data (perhaps a fake carrier and call the prospect with auto-answer on the fake carrier and "nophone" on the login, based on the CID on the agent's phone would get the client data on-screen without an actual extra call and only a slight delay?). But if the behavior is what you NEED ...

Alternately, actually checking the code to see how much effort will be needed to auto-release the next call immediately when anyone answers the "ring-all" and initiate ring on any agents who "tried but failed" and then hung up so they are now available.

An interesting statistic would be to check exactly how long it takes for Vici to generate that next ring-all to the agents after the previous caller is answered. If it's precisely the same amount of time each time, there may actually be a "built-in" purposeful delay that could either be altered OR overridden under specific circumstances.

Also: Why don't you just allow the agents to use the "grab call" feature?