Live call indicator versus ringing

[myaddressis]

Hi folks,

Has anyone come up against this "feature"? Basically the amount of time between when a call is setup and passed to the router, and the actual call coming through to the agent seems a little confusing for some of our agents, especially when there is no ring being heard by them, if you look in the asterisk logs you see something similar to the following:

[Feb 27 15:04:07] -- Executing [8600051@default:1] MeetMe("Local/8600051@default-60ee,2", "8600051|F") in new stack
[Feb 27 15:04:07] > Channel Local/8600051@default-60ee,1 was answered.
[Feb 27 15:04:07] -- Executing [0849999999@default:1] AGI("Local/8600051@default-60ee,1", "agi://127.0.0.1:4577/call_log") in new stack
[Feb 27 15:04:08] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Feb 27 15:04:08] -- Executing [0849999999@default:2] Set("Local/8600051@default-60ee,1", "CALLFILENAME="M2271504070000134389" <0849999999>-0849999999-20120227-150408") in new stack
[Feb 27 15:04:08] -- Executing [0845802813@default:3] Monitor("Local/8600051@default-60ee,1", "wav|M2271504070000134389 <0849999999>-0849999999-20120227-150408|m") in new stack
[Feb 27 15:04:08] -- Executing [0849999999@default:4] Dial("Local/8600051@default-60ee,1", "SIP/acom/0849999999||tTorR") in new stack
[Feb 27 15:04:08] -- Called acom/0849999999
[Feb 27 15:04:09] -- SIP/racom-00000045 is making progress passing it to Local/8600051@default-60ee,1
[Feb 27 15:04:11] -- Executing [58600051@default:1] MeetMe("Local/58600051@default-9c09,2", "8600051|Fmq") in new stack
[Feb 27 15:04:11] > Channel Local/58600051@default-9c09,1 was answered. At this point the agent sees the "Live Call" being displayed
[Feb 27 15:04:11] -- Executing [8309@default:1] Answer("Local/58600051@default-9c09,1", "") in new stack
[Feb 27 15:04:11] -- Executing [8309@default:2] Monitor("Local/58600051@default-9c09,1", "wav|20120227-150410_0849999999_4052") in new stack
[Feb 27 15:04:11] -- Executing [8309@default:3] Wait("Local/58600051@default-9c09,1", "3600") in new stack
[Feb 27 15:04:12] -- SIP/acom-00000045 is ringing
[Feb 27 15:04:42] -- SIP/acom-00000045 is making progress passing it to Local/8600051@default-60ee,1 Only at this point are we speaking to the client
[Feb 27 15:04:44] -- SIP/acom-00000045 answered Local/8600051@default-60ee,1

What I'd like to know is, which files should I be looking at to change the behaviour of when the "Live Call" image is displayed? Do we have to rather look at the 180 and 183 status codes from our provider and try to drop that? Some of the agents are obviously confused when they see "Live Call" on their browser, but there's actually no voice.

We're currently on

Asterisk - 1.4.38-vici : DB Schema Version : 1311 : Vicibox Redux 3.1.14 x86_64 from iso : Version : 2.4b0.5 : 3 box Cluster setup : No Digium/Sangoma : No extra software : Linux 2.6.34.10-0.6-default #1 SMP

[williamconley]

Thanks for posting your specs with installer version and vicidial version ... but please post the entire vicidial version WITH BUILD.

Also please post the precise method with which these agents are making these calls. I also note that you appear to have a non-standard dialplan, so also post your dialplan (not the entire thing, just the dialplan entry from the carrier in question).

It may also be helpful if you mention whether this happens with a single agent or only under heavy load. Posting your actual load from "uptime" if it happens only under heavy load would be useful as well.

I note that according to the log above, there is only a one-second delay between "Live!" and "Sound!". I'm not sure if you are concerned about a 1 second delay or if you are experiencing more than a second regardless of what the log says.

Do your agents hear the "bing" when the call actually goes Live with Sound?

[myaddressis]

Hi William, thanks for replying. We are now on Version 2.4-351a, build 111223-0043. (3.1.14 iso iirc)

Agents are doing manual/preview dialling when making calls. The dialplan looks like this:

exten => _XXXXXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _XXXXXXXXXX,2,DIAL(SIP/provider/${EXTEN},,tTor)
exten => _XXXXXXXXXX,3,Hangup
exten => _XXXXXXXXXX,4,Congestion

All agents experience this, at all times, so I'm steered away from the heavy load idea.

The agent doesn't hear any indication of the live call actual sound, except for a "Hello" from the called party.. I've done the 99998 trick to emulate a ring for the agents in the meanwhile, but it would be nice to actually have the "Live call" displayed when we have a live call.

[williamconley]

In a manual call, the "live call" is generated by the fact that the channel has already been attached to the agent's meetme room. This has nothing to do with "Answer" and merely indicates that there is a channel other than the Agent attached to the agent's meetme conference.

This is by design as Vicidial is not tracking the progress of this manual dial call, it is not under control of a perl script. It is under control of the agent (for instance, the agent CAN terminate the call before it is answered ...).

IF you want to modify the system to detect "call command issued" and wait for "answered" and instead of "Live" immediately have the system show "ringing" or "waiting" or some such until "answer" is officially received, that would certainly be a valid feature request. The Vicidial Group may be interested in this project if you are prepared to pay the fee ... if you want to tackle it yourself it will be a bit of a challenge.

The agent screen uses AJAX to issue a call command to the php page that manages calls. This page modifies a sql entry. This sql entry is picked up by a perl page to actually generate the call. During this process the agent's AJAX page continually checks the sql table and when the call is generated, the agent AJAX screen "sees" the extra channel and displays the LIVE CALL. It is possible that you could intercept this and have the "STATE" of the call cause a different reaction.

BUT: MY Advice would be to change to AutoDial and stop wasting valuable agent time. Seriously: This feature has not been added yet because anyone with enough $$ to pay for it (or who can afford an IT person capable of writing it ...) changes to auto-dial mode and makes more money while removing the need for this feature. Consider it. The agents may not "like" the new system because it will keep them working hard, but it will also make them (and you) more money if they are on commission. Suddenly everyone is making more money, wasting less time, and this feature becomes a moot point. (My opinion, of course ... ).

[areon]

Anybody it has a solution this problem at the moment?

[williamconley]

Anybody it has a solution this problem at the moment?

There is no "solution" to this as it's not a "problem".

It could one day be a feature request. But presently, when you make a manual call ... it's Live immediately upon acceptance of the carrier, not when the callee answers.

[areon]

>>>when you make a manual call

William, i make call up on the list (dial next number), but
>>>Live immediately upon acceptance of the carrier, not when the callee answers

Why?! =(((
On some projects, everything works as it should and I do not understand why.

[williamconley]

Concept:

In an autodialed call, the call is generated by (and controlled by) the Campaign scripts up until the moment it is turned over to an agent. The decision to turn the call over to an agent requires several things to be true, to avoid wasting agent time. Some factors, depending on the settings in the campaign, depend on AMD results, callee pressing 1, etc.

The first stage of an autodialed call requires ONLY that the call be answered. The second stage is controlled by "Campaign Routing Extension" and can require other things, such as AMD result NOT being an answering machine or the callee pressing "1". But at some point, the script for the Campaign will decide that it's time to pass the call to an agent ... and in ALL these autodialed calls, there has already been an Answer before the call is passed to an agent. This is because the entire purpose of auto-dial is to Avoid Wasting the Agent's Time. No "ringing" or "disconnected" or other "incomplete" calls are transferred to an agent.

Thus, in autodial, when an agent gets the call it has already been answered and the "Live Call" indicator in this situation also indicates "Human or equivalent".

But in Manual Dialed calls, the "wasted agent time" is already a given. The agent has manually made a decision to dial this number NOW by pushing a button. The agent is personally interacting with this callee, regardless of the outcome (ie: Even if there's no answer, the agent is in a manually dialed call and the AGENT will need to determine that there was "no answer" instead of a script ...: This is the definition of "manual call"). There is no script active to interpret the channel and determine AMD, wait for press 1, or even "wait for answer" to send the call to an agent ... the call is already in an agent screen. The agent already has control of the call, and can press "hangup customer".

To date, no one has paid for there to be an "Answer" listener to tell the agent the difference between "ringing" and "answered", because (to date) all agents have been expected to have ears and manage this on their own. If YOU want to have this feature added, while you may not be alone in the desire, you may certainly be expected to be alone in the payment. I've not personally heard anyone else prepared to pay for this feature.

Note that the ONLY difference in functionality would be that the "LIVE CALL" image/indicator would be updated more often. It would show "Waiting for Ring", then "Ringing", then "LIVE CALL" as the stages are detected.

If you envision an autodialer where each agent would sit there as the system showed them the next lead, gave them 15 seconds to "peruse" and possibly push skip (as an option in some cases), then observe/listen as the system "manually dialed" for them, and then listen as the system detected ring/disconnect/busy and the system recorded the outcome (if it was anything other than "Answer") and then watched as the system dialed the next call ... that would be an autodialer from 1995. It involves 1:1 dialing per agent and is a huge waste of time.

However: It could be done. Probably with an "outside of Vicidial" script using the agent api.