[Home]

Summary:ASTERISK-07537: [patch] some logging enhancements to app_queue
Reporter:wes (whoiswes)Labels:
Date Opened:2006-08-15 10:19:51Date Closed:2007-07-03 14:40:53
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_queue_SVN041207.patch
( 1) queue_aqm_rqm.patch
( 2) queue_transfer.patch
Description:Hi all,

This is my first contribution, so please be kind.

I have created three VERY minor logging patches for app_queue that I think add greatly to the reporting capibilities of the system.  In no particular order, here they are:

1. + 47432 1.4 svn.
  Added logging of agents being added/removed from the queue via AddQueueMember and RemoveQueueMember.  We utilize this to determine when our agents are logging in and out and will eventually be comparing these against a pre-set schedule to determine adherence.

2.  Revamped the logging of TRANSFER calls, so that the format matches COMPLETECALLER and COMPLETEAGENT - since a tranfered call is in effect a completed call (for us, anyway) I wanted to have the log entry be in the same format as a COMPLETE'd call.


3. + r24564 trunk
  Added logging of call "offers" - this simply creates a log entry when the queue attempts to ring a member, so that we can determine how many call offers an agent is receiving, versus how many they are answering.

I have created three individual patches against the trunk.

I believe I have a disclaimer on file, if not, these are so trivial that I don't know why one would be needed....
Comments:By: wes (whoiswes) 2006-08-15 10:34:22

I just was playing with this and realized that trunk already has the call offer feature available - there is a new log entry being created called RINGNOANSWER that seems to do the same thing as what I'm trying.

I apologize for my oversight - these patches were developed in 1.2.4 and have only been lightly tested in trunk - I did not realize the RNA function had been introducted.
By: Serge Vecher (serge-v) 2006-08-15 11:14:29

yes, RINGNOANSWER was added in http://lists.digium.com/pipermail/asterisk-commits/2006-May/004096.html to trunk. Are there are any items here that are still up for consideration?
By: wes (whoiswes) 2006-08-15 11:17:28

Yes, the first and second bullet points are still valid, IMO.
By: BJ Weschke (bweschke) 2006-08-17 15:33:31

I like the concept behind the two remaining patches, but I'm a little concerned that we're starting to "blur" the lines between an "agent" and a "queue member" with the aqm_rqm patch.
By: wes (whoiswes) 2006-08-17 15:37:58

If you want to distinguish between AQM and AgentCallbackLogin, change the AGENTLOGIN string in my patch to ADDQUEUEMEMBER or something else...I only picked AGENTLOGIN because I figured if AgentCallbackLogin is being deprecated, something will need to take it's place.

For our call center (400 seats) AQM and RQM are perfect except for the amount of logging they do, which is why I created this meager patch - what course you guys take with it is entirely up to you - I won't pretend to be an expert, especially when it comes to the difference between and agent and a queue member, I just wanted to offer whatever I could to this project.

In any case, thanks for the input and please feel free to make changes as needed.
By: Jason Parker (jparker) 2006-09-26 20:03:07

I can't say I agree with patch #2.  You are removing functionality, so that it fits your app.
By: wes (whoiswes) 2006-09-27 09:32:44

I don't understand what functionality I'm removing - I'm simply logging different information.  Instead of the extension and context, I'm logging the holdtime, calltime, and the extension the caller was transferred to.  Having those two timer values is VERY important to us, and I would think anyone else that uses inbound queues extensively - having accurate stats is very important.

The reason the transfer patch exists is that we cannot get accurate call and hold time statistics if transferred calls are not logging this information.  Let's say I have 100 calls come in and 50 of those are transferred - if I want to konw the average time a caller spent on hold, I can only calculate that off of the 50 calls that weren't transferred.  To me, this seems flawed.
By: Caio Begotti (caio1982) 2006-10-11 12:33:17

Hello, any update on the first bullet, about new log entries for queue members?
By: jmls (jmls) 2006-11-01 13:05:20.000-0600

whoiswes: any comments on the comments ?
By: wes (whoiswes) 2006-11-02 08:16:30.000-0600

Well, as far as the transfer logging patch, we have gone so far as to pay Digium to add it to a custom build of BusinessEdition for us, because having exact call time and hold time statistics is vital for any inbound call center.  

The transfer patch doesn't remove any information other than the context the caller was transferred to, which isn't good for much, IMHO.  But it does add the holdtime and calltime of that call, which I think are VERY important.  I stand by my last comment in saying that I think this patch is vital for any inbound call center using queues.

As for the AQM/RQM patch, since AgentCallBackLogin is being deprecated and AQM/RQM is taking it's place (or so it's been said), knowing when your agents are signing in and out is pretty important, so having this information logged is vital, if you're using queues and tracking your agents in any way.  If my using AGENTLOGIN as the event is a bad idea, change it to something else, just as long as the AQM and RQM events have SOMETHING logged for them.


By: Jared Smith (jsmith) 2006-11-10 10:43:31.000-0600

The first part (logging to the queue_log when a member is added or removed to/from a queue with AddQueueMember / RemoveQueueMember) has been committed by kpfleming today (SVN revision 47432).  

I'd still like to see the rest of these things done as well.
By: Serge Vecher (serge-v) 2006-11-15 11:01:43.000-0600

qwell: do you have any further thoughts on item 2 patch?
By: wes (whoiswes) 2007-01-11 08:57:34.000-0600

ping
By: Caio Begotti (caio1982) 2007-03-26 09:39:34

What's the current status of this ticket?
By: Serge Vecher (serge-v) 2007-03-26 10:46:37

I know the patch is small, but need some test results here anyway.
By: wes (whoiswes) 2007-04-09 13:45:12

Sorry I didn't comment sooner....

I have had this patch in production since August without issue....
By: Serge Vecher (serge-v) 2007-04-09 14:12:43

alright, can you please make a new patch, leaving qe->chan->context in there?
By: wes (whoiswes) 2007-04-12 11:46:47

Current way of logging transfers (from SVN code)
TRANSFER(extension|context|holdtime|calltime)

My way of logging transfers currently:
TRANSFER(holdtime|calltime|extension)

Adding contexts back in (I have no idea why that would be considered important, but...)
TRANSFER(holdtime|calltime|extension|context)

I guess the only thing my patch is doing now is rearranging the order in which things are being added - at some point, somebody has added the holdtime and calltime to the log files.  

The only reason for my patch is to comply with the field order for COMPLETECALLER and COMPLETEAGENT so that my SQL join can include all three "completed" call types in one swing versus having to grab transfers in a separate query and then average those numbers in as well.  In fact, here is that query:

"select count(uniqueid) as total_calls,
 avg(cast(arg1 as signed)) as avg_holdtime,
 max(cast(arg1 as signed)) as max_holdtime,
 avg(cast(arg2 as signed)) as avg_calltime,
 max(cast(arg2 as signed)) as max_calltime,
 avg(cast(arg3 as signed)) as avg_entryposition,
 max(cast(arg3 as signed)) as max_entryposition
 from queue_log
 where event in ('COMPLETECALLER', 'COMPLETEAGENT', 'TRANSFER')
 and queuename = '$queuename'
 and epoch between '$startepoch' and '$endepoch'";

I guess at this point it's just a formatting issue...in any case, attached is the new patch to rearrange the order of the fields.  Again, I don't know who added the holdtime and calltime to TRANSFER logging inside app_queue, but it is already there in SVN, just in the wrong place, IMHO.

Wes


By: Jason Parker (jparker) 2007-07-03 14:40:52

Patches 1 and 3 have been committed in some form or another already.

The functionality of patch 2 has also already been committed.  I don't see any valid reason for changing the position of the fields.

Closing.