vicidial.org

Hi all,

I am currently dialling a small campaign on our company cluster.

Dialling method: Ratio
Auto Dial Level: 1
Available Only Tally: Y

This campaign is still dropping call with the call results as follows:


| CUSTOMER | 64 |
| AGENT | 381 |
| QUEUETIMEOUT | 1 |
| ABANDON | 1 |
| NO ANSWER | 117 |


Can i ask why we are getting queuetimeout and abandon dropped calls. Because while watching the real time screen i can see that the dialler doesnt starting ringing a lead until a advisor goes into ready so the advisor would be able to take the call.

also just to add that we have disabled the pause button on the agc interface so advisors cannot got into pause while waiting for call and also added a check to the logout javascript that check for pause state and waiting_on_dispo to make sure advisors cant logout until they have finished the call and gone into pause. (pause button is on the script)

this is also an outbound only campaign. ive read manual and it says queuetimeout is for inbound. but this has no inbound. does balance dialling class as inbound?

any help is much thanked




Cheers

anyone? i need to fix this because in the UK we have a 3% Drop margin and were going over it even on ratio 1

What is your campaign drop time set to?

How many agents do you have logged in?

admin.php version and build?

Thanks for your reply Matt.

Our Drop TimeOut is set to 2 seconds.

Its a cluster with one DB node 3 asterisk nodes 2 webservers with 47 agents logged into 4 different campaigns ( 1 x ADAPT <- works fine, 3 x RATIO <- getting QUETIMEOUT drops). None of the RATIO campaigns have inbound groups they are just pure outbound.

Also 30 of the 47 advisors are on the ADAPT campaign which is fine.

We have had no problems with load.
We have balance dialling set to yes on all 3 asterisk nodes

Versions:
VERSION: 2.4-362a
BUILD: 120316-1203

Do you have slow query logging enabled on your mysql server?

You would need to look at the agiout logfile output to see why the QUEUETIMEOUT happened. As for the ABANDON, that could have happened a hundredth of a second after the Answer signal was received, which would be before the call could be routed to an agent. This happens on any non-MANUAL-dial campaign, and it is unavoidable. Looking at your stats, both of these are less than 1% of your total calls.

sorry that was an example of the queuetimeout

yesterday on one campaign:

Code: Select all

| CUSTOMER             |        220 |
| AGENT                |        775 |
| QUEUETIMEOUT         |         19 |
| ABANDON              |          2 |
| NO ANSWER            |        392 |  < -- Obv this isnt part of the drop %
+----------------------+------------+
| TOTAL:               |       1408 |

Code: Select all

---------- DROPS
Total Outbound DROP Calls:                            21  1.49%
Percent of DROP Calls taken out of Answers:           21 / 679  3.09%
Percent of DROP/Answer Calls with Rollover:           21 / 679  3.09%
Average Length for DROP Calls in seconds:            2.9
Productivity Rating:                                0.41

Also slow log is enabled but we have less than 0.0001% on slow querys

what i could find in the cli at the time of one drop. number in question is 07831368955 (please delete the number off post when done looking)

Code: Select all

lbm-vicitel02*CLI>
[Jul 30 14:18:41]     -- Executing [07831368955@default:1] AGI("Local/07831368955@default-8af3,2", "agi://127.0.0.1:4577/call_log") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:18:41]     -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0--------------- completed, returning 0

lbm-vicitel02*CLI>
[Jul 30 14:18:41]     -- Accepting AUTHENTICATED call from 10.2.1.12:
       > requested format = ulaw,
       > requested prefs = (ulaw|gsm),
       > actual format = ulaw,
       > host prefs = (ulaw),
       > priority = mine

lbm-vicitel02*CLI>
[Jul 30 14:18:41]     -- Executing [8600065@default:1] MeetMe("IAX2/lbm-vicite-3093", "8600065|F") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:18:41]     -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0

lbm-vicitel02*CLI>
[Jul 30 14:18:41]     -- Executing [07831368955@default:2] Dial("Local/07831368955@default-8af3,2", "DAHDI/g1/07831368955||To") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:18:41]     -- Requested transfer capability: 0x00 - SPEECH

lbm-vicitel02*CLI>
[Jul 30 14:18:41]     -- Called g1/07831368955

lbm-vicitel02*CLI>
[Jul 30 14:18:42]     -- DAHDI/1-1 is proceeding passing it to Local/07831368955@default-8af3,2

lbm-vicitel02*CLI>
[Jul 30 14:18:42]   == Parsing '/etc/asterisk/manager.conf': [Jul 30 14:18:42] Found

lbm-vicitel02*CLI>
[Jul 30 14:18:42]   == Manager 'sendcron' logged on from 127.0.0.1

lbm-vicitel02*CLI>
[Jul 30 14:18:42]     -- Executing [58600063@default:1] MeetMe("Local/58600063@default-f374,2", "8600063|Fmq") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:18:42]        > Channel Local/58600063@default-f374,1 was answered.

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Jul 30 14:19:00]     -- Executing [8368@default:3] AGI("DAHDI/23-1", "agi-VDAD_ALL_outbound.agi|NORMAL-----LB") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:19:00]   == Manager 'sendcron' logged off from 127.0.0.1

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- DAHDI/1-1 answered Local/07831368955@default-8af3,2

lbm-vicitel02*CLI>
[Jul 30 14:19:00]        > Channel Local/07831368955@default-8af3,1 was answered.

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- Executing [8368@default:1] Playback("Local/07831368955@default-8af3,1", "sip-silence") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- <Local/07831368955@default-8af3,1> Playing 'sip-silence' (language 'en')

lbm-vicitel02*CLI>
[Jul 30 14:19:00] WARNING[10990]: file.c:1297 waitstream_core: Unexpected control subclass '-1'

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- Executing [h@default:1] DeadAGI("Local/07831368955@default-8af3,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----19-----0") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- Executing [8368@default:2] AGI("DAHDI/1-1", "agi://127.0.0.1:4577/call_log") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Jul 30 14:19:00]     -- Executing [8368@default:3] AGI("DAHDI/1-1", "agi-VDAD_ALL_outbound.agi|NORMAL-----LB") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- AGI Script agi-VDAD_ALL_outbound.agi completed, returning 0

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- Executing [010*002*001*013*8600057@default:1] Goto("DAHDI/3-1", "default|8600057|1") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- Goto (default,8600057,1)

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- Executing [8600057@default:1] MeetMe("DAHDI/3-1", "8600057|F") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:19:00]     -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----13-----0 completed, returning 0

lbm-vicitel02*CLI>
[Jul 30 14:19:00]   == Spawn extension (default, 07708429566, 2) exited non-zero on 'Local/07708429566@default-b4bb,2'

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- AGI Script agi-VDAD_ALL_outbound.agi completed, returning 0

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- Executing [010*002*001*013*8600056@default:1] Goto("DAHDI/18-1", "default|8600056|1") in new stack
[Jul 30 14:19:01]     -- Goto (default,8600056,1)
[Jul 30 14:19:01]     -- Executing [8600056@default:1] MeetMe("DAHDI/18-1", "8600056|F") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:19:01]   == Manager 'sendcron' logged off from 127.0.0.1

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----28-----1 completed, returning 0
[Jul 30 14:19:01]   == Spawn extension (default, 07711631457, 2) exited non-zero on 'Local/07711631457@default-08eb,2'

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- AGI Script agi-VDAD_ALL_outbound.agi completed, returning 0

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- Executing [010*002*001*012*8600071@default:1] Dial("DAHDI/23-1", "IAX2/lbm-vicit1:Lb44jt6u7e80@10.2.1.12:4569/8600071|55|oT") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- Called lbm-vicit1:Lb44jt6u7e80@10.2.1.12:4569/8600071

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- Call accepted by 10.2.1.12 (format ulaw)

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- Format for call is ulaw

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- IAX2/lbm-vicite-2044 answered DAHDI/23-1

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----9-----0 completed, returning 0


lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- Executing [010*002*001*012*8600071@default:1] Dial("DAHDI/23-1", "IAX2/lbm-vicit1:Lb44jt6u7e80@10.2.1.12:4569/8600071|55|oT") in new stack

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- Called lbm-vicit1:Lb44jt6u7e80@10.2.1.12:4569/8600071

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- Call accepted by 10.2.1.12 (format ulaw)

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- Format for call is ulaw

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- IAX2/lbm-vicite-2044 answered DAHDI/23-1

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----9-----0 completed, returning 0

lbm-vicitel02*CLI>
[Jul 30 14:19:01]   == Spawn extension (default, 02380897185, 2) exited non-zero on 'Local/02380897185@default-7356,2'

lbm-vicitel02*CLI>
[Jul 30 14:19:01]     -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----19-----0 completed, returning 0

lbm-vicitel02*CLI>
[Jul 30 14:19:01]   == Spawn extension (default, 07831368955, 2) exited non-zero on 'Local/07831368955@default-8af3,2'

^^ Might be some dup lines in there. its hard to find the exact lines when so many calls are dialling

Cheers
[quick edit for legibility = williamconley]

It's the agiout logfile output for that specific call that would help most.

where do i find that

/var/log/astguiclient/agiout.2012-08-01

And you are sure none of your agents are transferring calls that could land in this campaign ... there are no Menus that may have an option to send a call to this campaign in an unusual fashion ...?

I don't think calls transferring OUT of the campaign would cause a queue timeout, but then again ... do you have transfer-outs?

mflorell wrote:/var/log/astguiclient/agiout.2012-08-01

I have used a different example number while getting the fastagi output. Sorry there is loads of lines but i did a search on the number and just copied from the first instance of the number to the last.

ive put the output here http://pastebin.ca/2176804 Please search for number 01740657930

Many Thanks

williamconley wrote:And you are sure none of your agents are transferring calls that could land in this campaign ... there are no Menus that may have an option to send a call to this campaign in an unusual fashion ...?

I don't think calls transferring OUT of the campaign would cause a queue timeout, but then again ... do you have transfer-outs?

Hi William,

No there are no inbound DID's pointing to this campaign, No inGroups on this campaign, No CallMenus on this whole server. And Transfers are disabled for advisors.

Cheers

That's the fastagi output, where is the AGI output?

Is your server set to allow logging to FILE or BOTH?

mflorell wrote:That's the fastagi output, where is the AGI output?

Is your server set to allow logging to FILE or BOTH?

it is set to FILE


also slighty off topic but how do i set the CALLERID of a blind transfer to customer? Im not using 3 way just blind

Cheers

Blind transfer TO customer? I would think you were blind transfering the customer to a 3rd party. And in case you didn't know it, that's still a 3-way call. The agent is "booted" from the conference room (and gets a new one, with a fresh notice of being the only person in the conference), but the customer stays in the original conference room and a new call is generated from that conference to the 3rd party. So: Customer/Vicidial/3rd party = 3 way call.

To set callerid for a call "not covered" in the Vicidial system, you can try using a different dialplan in your carrier to pass the call through with an explicit dialplan entry to set the callerid. But have you tried the 3-way setting first?

williamconley wrote:Blind transfer TO customer? I would think you were blind transfering the customer to a 3rd party. And in case you didn't know it, that's still a 3-way call. The agent is "booted" from the conference room (and gets a new one, with a fresh notice of being the only person in the conference), but the customer stays in the original conference room and a new call is generated from that conference to the 3rd party. So: Customer/Vicidial/3rd party = 3 way call.

To set callerid for a call "not covered" in the Vicidial system, you can try using a different dialplan in your carrier to pass the call through with an explicit dialplan entry to set the callerid. But have you tried the 3-way setting first?

What we use is:

Vicidial calls customer > Agent then wants to transfer to a DID/INGROUP (Blind Transfer) - We see the campaign caller id on ingroup agent screen so CIDLOOKUPL fails.

Also we wanted to use 3way (warm transfer) but when we click leave 3 way the customer gets release from hold and can talk to ingroup but the first agents stays in the conference and when they hangup(the first agent) or logs out it also hangs up on the customer.

Matt - any further news on queuetimeout?

Cheers for your help so far guys

Mark

P.S William can I contact you for a consult as to why 3way doesnt work on our Vicidial.php file (It does with untouched php version but we have made changes and ive somehow messed it up and dont want to have to reinstall and re do all the changes etc,)

Cheers

Look up consultative transfer in the Vicidial Managers Manual. 3-Way is for external transfers, consultative is for transfer to another agent.

If your callerid is being lost during the transfers, you may have an old version with a bug. Consider upgrading. (Upgrading is a good skill to have, anyway, as Matt adds cool toys all the time and Upgrading is how you take advantage of them easily!).

Also: Post each and every button you pressed to make these transfers happen (detailed description) and the configuration of your Campaign(s) and Ingroup(s).

williamconley wrote:Look up consultative transfer in the Vicidial Managers Manual. 3-Way is for external transfers, consultative is for transfer to another agent.

If your callerid is being lost during the transfers, you may have an old version with a bug. Consider upgrading. (Upgrading is a good skill to have, anyway, as Matt adds cool toys all the time and Upgrading is how you take advantage of them easily!).

Also: Post each and every button you pressed to make these transfers happen (detailed description) and the configuration of your Campaign(s) and Ingroup(s).

Hi William I have got the 3-Way transfer to work fine now i hidden the wrong thing in the agentinterface but now face a different issue.

When i manual dial a lead and trasnfer the call through to the 3-way advisor the CIDLOOKUPL works fine cause it searches the 0777XXXXXXX number in the DB and finds it. But when a customer dials in using the DID setup the 0 from the begining on the number is stripped off so the CIDLOOKUPL doesnt work is there any setting which can add a 0 to the begining of the CID's when its an inbound?

Cheers

Let me get this straight: You are dialing in a country where everyone believes that their phone number is 11 digits and starts with "0" (even though anyone dialing their number from another country will NOT dial the "0", which means that the phone number is actually 10 digits and the "0" is a code that is dialed before the number to denote "within this country"). You have, as a result, added this "0" to the beginning of every phone number in your system and modified your dialplan based on "0" first digit ...

And now it turns out that your carrier/voip provider is not passing the number to you with the "0" (in other words, they are passing the true phone number, LOL) and it does not match up with everything else. Instead of removing the zeros from the phone numbers to allow them to match (and then modifying your DNC list and dialplans and everything else you've set up with this erroneous "0" preceded phone number), you want me to figure out for you how to further break the system so you may continue in this "0" as the first digit fantasy of yours? LOL

Yep. You can modify the extensions.conf file and find the trunkinbound "_X." extension to have a line before the did agi call that adds a single "0" to the callerid of the inbound call. Use asterisk-guru or someone similar for your dialplan entry. If you need help, show your example and we'll help you tweak it. Remember that "NoOp" is a Great way to get the real value of things to show in the command line so you can see how you're doing. (NoOp can make invisible things visible on the CLI ).

williamconley wrote:Let me get this straight: You are dialing in a country where everyone believes that their phone number is 11 digits and starts with "0" (even though anyone dialing their number from another country will NOT dial the "0", which means that the phone number is actually 10 digits and the "0" is a code that is dialed before the number to denote "within this country"). You have, as a result, added this "0" to the beginning of every phone number in your system and modified your dialplan based on "0" first digit ...

And now it turns out that your carrier/voip provider is not passing the number to you with the "0" (in other words, they are passing the true phone number, LOL) and it does not match up with everything else. Instead of removing the zeros from the phone numbers to allow them to match (and then modifying your DNC list and dialplans and everything else you've set up with this erroneous "0" preceded phone number), you want me to figure out for you how to further break the system so you may continue in this "0" as the first digit fantasy of yours? LOL

Yep. You can modify the extensions.conf file and find the trunkinbound "_X." extension to have a line before the did agi call that adds a single "0" to the callerid of the inbound call. Use asterisk-guru or someone similar for your dialplan entry. If you need help, show your example and we'll help you tweak it. Remember that "NoOp" is a Great way to get the real value of things to show in the command line so you can see how you're doing. (NoOp can make invisible things visible on the CLI ).

Thanks William, (even tho i feel abit stupid now with the whole 0 thing )

Here is my current inbound extensions.cnf entry:

Code: Select all

; DID call routing process
exten => _X.,1,AGI(agi-DID_route.agi)

Would adding this solve my issue?

Code: Select all

exten => _X.,1,Set(CALLERID(num)=0${CALLERID(num)})
exten => _X.,2,AGI(agi-DID_route.agi)

Many Thanks

Mark

I love pickin' on people. It's what I live for. LOL

so ... you didn't mention if this worked?

williamconley wrote:I love pickin' on people. It's what I live for. LOL

so ... you didn't mention if this worked?

Sorry I forgot to reply

Im at home now but I pretty sure what I added was:

Code: Select all

exten => _X.,1,GotoIf($[${LEN(${CALLERID(num)})} != 10]?not10digits)
exten => _X.,n,Set(CALLERID(num)=0${CALLERID(num)})
exten => _X.,n(not10digits),AGI(agi-DID_route.agi)

Thanks For Your Help All

I'm gonna pick on you again. LOL

You posted your "add" before. You neglected to say whether it worked either time. Does this mean ... it worked?

Dude, it's only Monday. I don't think you're gonna make it to Friday.

williamconley wrote:I'm gonna pick on you again. LOL

You posted your "add" before. You neglected to say whether it worked either time. Does this mean ... it worked?

Dude, it's only Monday. I don't think you're gonna make it to Friday.

Yes it worked