queue log problem

Looks like its happening on all queues..

1233491317|1233491268.170|AnyOtherQueue|NONE|ABANDON|1|1|12

1233494405|1233494364.205|AnyOtherQueue|NONE|ABANDON|1|1|4

1233503721|1233503698.272|SalesQueue|NONE|ABANDON|1|1|5

1233503728|1233503728.279|Outbound|NONE|ABANDON|1|1|0

1233510461|1233510452.356|TechnicalFaultQueue|NONE|ABANDON|1|1|5

1233510463|1233510462.362|Outbound|NONE|ABANDON|1|1|1

1233559856|1233559852.190|Outbound|NONE|ABANDON|1|1|4

1233566285|1233566255.877|Outbound|NONE|ABANDON|1|1|30

1233567513|1233567437.950|ReceptionQueueGR|NONE|ABANDON|1|1|64

1233568600|1233568595.1100|Outbound|NONE|ABANDON|1|1|5

1233569074|1233569062.1204|Outbound|NONE|ABANDON|1|1|12

1233570132|1233570117.1376|ReceptionQueueGR|NONE|ABANDON|1|1|2

1233577164|1233577150.2163|ReceptionQueueGR|NONE|ABANDON|1|1|1

1233580447|1233580432.2463|ReceptionQueueGR|NONE|ABANDON|1|1|2

1233581413|1233581400.2630|ReceptionQueueGR|NONE|ABANDON|1|1|1

1233591431|1233591376.3556|AnyOtherQueue|NONE|ABANDON|1|1|28

1233594939|1233594902.3634|Outbound|NONE|ABANDON|1|1|37

1233602366|1233602317.3719|AccountingQueue|NONE|ABANDON|1|1|11

1233643245|1233643214.94|TechnicalFaultQueue|NONE|ABANDON|1|1|5

1233648693|1233648618.615|AnyOtherQueue|NONE|ABANDON|1|2|55

1233648847|1233648846.681|Outbound|NONE|ABANDON|1|1|1

1233650460|1233650440.848|Outbound|NONE|ABANDON|1|1|20

1233656842|1233656782.1596|Outbound|NONE|ABANDON|1|1|60

1233658091|1233658070.1781|Outbound|NONE|ABANDON|1|1|20

1233661292|1233661287.2076|Outbound|NONE|ABANDON|1|1|5

1233664356|1233664341.2362|ReceptionQueueGR|NONE|ABANDON|1|1|2

1233670320|1233670306.3147|Outbound|NONE|ABANDON|1|1|14

1233673392|1233673376.3432|ReceptionQueueGR|NONE|ABANDON|1|1|4

1233674927|1233674878.3521|AnyOtherQueue|NONE|ABANDON|1|1|30

1233677502|1233677502.3638|Reception333|NONE|ABANDON|1|1|0

1233683209|1233683208.3720|Outbound|NONE|ABANDON|1|1|1

1233685335|1233685226.3757|AccountingQueue|NONE|ABANDON|1|1|75

1233689858|1233689855.3789|Outbound|NONE|ABANDON|1|1|3

1233689867|1233689865.3791|Outbound|NONE|ABANDON|1|1|2

1233732502|1233732478.469|ReceptionQueueGR|NONE|ABANDON|1|1|12

1233738380|1233738328.1312|SalesQueue|NONE|ABANDON|1|1|8

1233738858|1233738676.1390|TechnicalFaultQueue|NONE|ABANDON|1|1|135

1233739994|1233739993.1562|Outbound|NONE|ABANDON|1|1|1

1233740003|1233740002.1564|Outbound|NONE|ABANDON|1|1|1

1233745112|1233745095.2137|ReceptionQueueGR|NONE|ABANDON|1|1|5

1233746901|1233746893.2269|Reception333|NONE|ABANDON|1|1|8

Any ideas why this would be happening?

thanks

Abandon just means the caller hung up while waiting in the queue. By the metrics provided, its as early as just a few seconds into the call. Make sure you aren't experiencing a high volume of dropped calls. Are you using some dialer script to call people and dump them into a queue?

Hi Erik,

no these are rare maybe 10-20 calls per day. The problem is not the ABANDON line but the fact that for each call with ABANDON there is a duplicate line for the same call (without the information of the agent ). So basically in my call center statistics i have double the amount of abandoned calls, which is not right!

I dont see any duplicates in that big list of calls.

these are 2 different calls

1233739994|1233739993.1562|Outbound|NONE|ABANDON|1|1|1

1233740003|1233740002.1564|Outbound|NONE|ABANDON|1|1|1

thse are 4 different calls

1233570132|1233570117.1376|ReceptionQueueGR|NONE|ABANDON|1|1|2

1233577164|1233577150.2163|ReceptionQueueGR|NONE|ABANDON|1|1|1

1233580447|1233580432.2463|ReceptionQueueGR|NONE|ABANDON|1|1|2

1233581413|1233581400.2630|ReceptionQueueGR|NONE|ABANDON|1|1|1

these are 5 different calls

1233648847|1233648846.681|Outbound|NONE|ABANDON|1|1|1

1233650460|1233650440.848|Outbound|NONE|ABANDON|1|1|20

1233656842|1233656782.1596|Outbound|NONE|ABANDON|1|1|60

1233658091|1233658070.1781|Outbound|NONE|ABANDON|1|1|20

1233661292|1233661287.2076|Outbound|NONE|ABANDON|1|1|5

each of these calls have a different cdr uniqueID which means a different call. As far as your first example, if the call abandons while the call is being offered to an Agent, its going to record both legs of that uniqueID. Most analysis software is smart enough to only count 1 abandoned call per uniqueID.

Now if you have evidence that a single call is generating more than one uniqueID, please include those CDR records and details as to how the call flows through your dialplan before arriving in a queue.

Hi Erik,

in the second list i only included the lines without the agent id.

Here is another list with double lines:

1233491317|1233491268.170|AnyOtherQueue|Agent/1005|ABANDON|1|1|12

1233491317|1233491268.170|AnyOtherQueue|NONE|ABANDON|1|1|12

1233602366|1233602317.3719|AccountingQueue|Agent/1005|ABANDON|1|1|11

1233602366|1233602317.3719|AccountingQueue|NONE|ABANDON|1|1|11

1233738380|1233738328.1312|SalesQueue|Agent/1009|ABANDON|1|1|8

1233738380|1233738328.1312|SalesQueue|NONE|ABANDON|1|1|8

1233832155|1233832110.2044|TechSupportQueue|Agent/1009|ABANDON|1|1|9

1233832155|1233832110.2044|TechSupportQueue|NONE|ABANDON|1|1|9

1233843632|1233843585.3162|TechSupportQueue|Agent/1010|ABANDON|1|1|13

1233843632|1233843585.3162|TechSupportQueue|NONE|ABANDON|1|1|13

It seems that i only get double lines for same CDRid for calls which include an Agent id.

I did not find any double lines with both lines having NONE as value before ABANDON.

Here is the cdr for the last call in the list:

"","22372345","4","131_voice_menu_GR","""22372345"" <22372345>","SIP/5060-aad1b4d0","","Queue","TechSupportQueue|tT","2009-02-05 16:19:45","2009-02-05 16:19:47","2009-02-05 16:20:32",47,45,"ANSWERED","DOCUMENTATION","1233843585.3162",""

(CDR ids are not included in the cdr even though i have

[csv]

;usegmtime=yes ;log date/time in GMT

loguniqueid=yes ;log uniqueid

loguserfield=yes ;log user field)

in my cdr.conf)

Calls are coming in matching on an inbound SIP route, going through some voice menus and then sent into the appropriate queue.

I can provide more info if required including config files.

Thanks,

Kyriakos

your uniqueid's are stored in cdr.. the uniqueid is 1233843585.3162 (partly based on epoch time)

ok, from the information provided everything looks good. Looks like the call hit your IVR and the user selected 4, which immediately launched the application Queue(TechSupportQueue,tT), the caller was listening to musiconhold for 13 seconds while the call was being offered to Agent/1010. Unfortunately the caller hung up before Agent/1010 could pick up the phone, which is why you have 2 log entries for abandoned. However, both those log entries record the exact same uniqueid 1233843585.3162, so your analysis software just needs to record 1 abandoned call.

Running the statistics needs to assemble a table of call records (based on uniqueid) and then report the status based on the log entry. Once said table is assembled, then totals can be extrapolated from the table. Simply doing a count of the word ABANDON or any other status will yield erroneous data, like when a caller waits, agent 1 doesnt answer, caller remains in queue, agent 2 doesnt answer, caller remains in queue even longer, and then agent 3 answers. All those offers to agents will log on that uniqueID but the final status of the call itself will be COMPLETEAGENT or COMPLETECALLER or maybe even TRANSFER, even with all the RINGNOANSWER entries.

I think your biggest worry is determining why callers are going into a queue and immediately hanging up when there obviously isn't a hold time. 13 seconds isn't too much to ask a caller to stick around for, thats only 2 rings to a phone.

This is the reply i got from the analysis software guys:

the agent has been in conversation for 13 seconds, so it's not a matter of events that are out of sync. The problem here is that QM closes the first call and then finds the second and considers it to be a degenerate call (missing all other events) so double-reports it.

If the agent was in conversation the status would have been COMPLETEAGENT or COMPLETECALLER one in which the agent was connected to the caller and then a hangup occurred. ABANDON only gets recorded when the caller hangs up while still in Queue, not after a call is connected. Whoever told you that the agent was in conversation for 13 seconds seems to be giving you lip service. ARG3 of ABANDON is hold time not call duration.

ABANDON(position|origposition|waittime)

The caller abandoned their position in the queue. The position is the

caller's position in the queue when they hungup, the origposition is

the original position the caller was when they first entered the

queue, and the waittime is how long the call had been waiting in the

queue at the time of disconnect.

I am really curious though. Why is it that you have callers, whom call into your IVR, select an option to enter a queue, there's no one else in the queue, the call goes out to an agent immediately, the caller abandons the call withing just a couple of seconds, and your primary concern is log entries, not whats causing a vast rash of abandoned calls? Who in the human race calls in to speak with someone, opts for a queue from an IVR and hangs up after hearing 1 to 2 rings?

My suspicion is that you're leaving something out, perhaps you are calling the customer and dumping them into a queue like bill collectors or telemarketers are doing lately. What else would explain why someone would hang up after 8 seconds of trying to reach someone unless they really didn't want to talk to someone and were forcibly dumped into the queue.

As long as your callers abandon their place in the queue before the agent can answer, the queue_log is going to correctly log 2 entries because there were 2 legs of that call in play. This is not a thirdlane problem, this is by nature how app_queue works. You would have to petition the asterisk developer community to have that changed. I also see no evidence that QM is counting 2 abandoned calls when this happens. Just because it's in queue_log twice doesn't give evidence that the analysis software is counting it twice, since they both contain the exact same uniqueid.

Hi Erik,

they are normal calls originating from customers to our company's hotline, not part of a dialout campaign or something in order to dump them into the queue.

I see your point on ABANDON parameters and i will pass them on to QM guys.

HI,

this is the reply i got from them:

"No it won't appear. In fact this is not logged at all in the standard log. there will be a RINGNOANSWER record only when the call is lost by the agent. "

they are wrong, RINGNOANSWER only happens if the call TIMES OUT ringing the agent and it returns to the queue. If your agent has a 30 second timeout and the caller ABANDONS the call in 5 seconds it will log an ABANDON not a RINGNOANSWER.

This is the only time ast_queue_log is executed with RINGNOANSWER. The subsequent code of this function goes on to autopause the agent/member if autopause is enabled. Not something that happens when callers hang up when ringing the agents.

/*! \brief RNA == Ring No Answer. Common code that is executed when we try a queue member and they don't answer. */

static void rna(int rnatime, struct queue_ent *qe, char *interface, char *membername)

{

if (option_verbose > 2)

ast_verbose( VERBOSE_PREFIX_3 "Nobody picked up in %d ms\n", rnatime);

ast_queue_log(qe->parent->name, qe->chan->uniqueid, membername, "RINGNOANSWER", "%d", rnatime);