Call log statistics

[bpb]

I'm looking for some type of program, script, etc. that can generate simple reports on the call logs on my UC Server at C:\Program Files (x86)\ADTRAN\NetVanta UC Server\SIPPBX\ipdr\*.xml

They're .xml files and are therefore importable into various programs.  It must be these log files specifically, as the call log options in the GUI aren't complete and don't show for ring groups, etc.

What I'm wondering is whether anyone has a simple way to compile these logs and answer simple management questions like "How many calls does the office get in a day?" or "How many times did [receptionist] answer the phone this week?" and so forth.

I'm sure this has to have been done before, so I'm asking before I pull something together and reinvent the wheel.

I also don't see the need to go with a big budget software package to do this, since the data is there and the information I need is not at all detailed; just general call volumes (not to be confused with VoIP call quality - not the subject of this question).

[bpb]

Well...ok, how about a big budget software package then?  Has anyone used anything to get basic management type statistics from AdTran gear; specifically UC Server ECS?  The UC Client software doesn't keep up with calls to ring groups, for example, so I'd need to know about those calls as well.

Anybody?

[bpb]

For example, the Syslog files of the  Netvanta 7100 just so happened to contain all of the call data I needed; they had the incoming number, time, called number, all neatly on one syslog line.  With the addition of the UC Server, the Netvanta 7100 logs just show calls going to the UC Server's IP and that's the last the Netvanta 7100 knows of them, as far as the syslog messages go.

So syslog messages were a quick and effective method for basic call statistics.  Since that isn't an option, is there any other way?

[Anonymous]

I would like to know how to get better call logging as well. Per day stats would be good and to go above the 100 limit on vvx phones would be sweet for a real busy day. We have cold calling sales reps and a manager who would like to see this information. Trying to make it as easy as possible on him.

[bpb]

Sadly we never got anything going satisfactorily.  RSI, Inc. tried to set up ShadowCMS call software to log our cradle to grave calls.  But, the way the UC Server logs call segments (every answer, transfer, pick up, voice mail, etc. is a unique call segment not directly connected to any other segment) it's seemingly impossible.

Since phone banks aren't (thankfully) the core of our business, we're able to get by with what I can piece together from syslog files from individual phones and any info I can get from the otherwise excellent logging of the Netvanta 7100.  (Back when we only had the Netvanta 7100 handling our VoIP, its syslog files would tell me everything I needed to know about call flow/volume.  It was beautiful.)

Anyway, here's hoping you have better luck than I.

[Anonymous]

Thanks bpb for the reply! We do not use a 7100 today but I will look at the syslog option.

[bpb]

When we only had the Netvanta 7100 it managed all phases of what we humans call a phone call.  I set up its syslog files to feed to LogAnalyzer and it was a beautiful thing.  UC Server ECS just doesn't log like humans think (or anyone, for that matter).  Plus, running Windows, I didn't bother too much with automating collection of those log files.

Our situation was only about personnel workload, in terms of evening out phone calls fielded.  So, I don't know if what log files there are with the UC Server will be sufficient for you.

This isn't to say I'm not still looking for a solution.  It's just taken a far backseat to other more pressing issues.  If you come up with anything that can reliably pair all the steps in a call - hitting the main automated menu, hand off to an operator, transfer to another user, conversation, disconnect; I'd be interested in hearing about it!

[bpb]

I've used Syslog records from the UC Server & Netvanta 7100 and a MySQL server to crunch the numbers and I've gotten all the data I need, except for one key piece: which member of a ring group answered a call to that ring group?

Here's an example with some actual data.

We have a ring group for the receptionists.  Let's say it's extension 1099.

When calls come in from the main line, they are programmed to go to extension 1099, which is a ring group consisting of two actual users' extensions (we'll say users 1011 and 1022).

Our call logs look like this, with my comments at the end after the "v2 -":

540254 02/05/2018 11:37:10 00:00 00:00:00 0:00:00:02 0 E T03 01/01 Some User 1234567890 00/01 T02 5991 N 5991 N v2  - Some User has called the main line at ###-5991.

540254 02/05/2018 11:37:11 00:05 00:00:00 0:00:00:18 0 I T03 01/01 Some User 1234567890 00/01 T02 1099 N 1099 F v2  -  A receptionist ring group member of 1099 picked up.  But, was it physical phone at 1011 or physical phone at 1022 who actually answered for the ring group?

540254 02/05/2018 11:37:53 00:24 00:00:00 0:00:00:00 0 I T03 01/01 Some User 1234567890 00/00 T02 1033 N 1033 F v2  -  The call was transferred to another user at 1033.

540254 02/05/2018 11:37:52 00:00 00:00:00 0:00:00:12 0 I T03 01/01 Some User 1234567890 00/01 T02 vm-1033 Y 1033 F v2  -  A voice mail was left for the user at extension 1033.

Since I can group the calls by the Unique Identifier (first 6 digits at the beginning of the Syslog entry) I can piece together where a call goes in the system - with one exception: which human in a ring group actually answered the phone?!

If I search the Syslogs for our fictional ring group members in this example, I'd get zero results for 1011 and for 1022.  Their extensions don't show up at all in the log files as participating in calls to the ring group.  It only logs the ring group extension.

So to sum up, the problem is: which members of a ring group are answering the bulk of the calls?

It seems like a pretty basic thing to cover with call logging, especially since every other possible transaction creates a distinct Syslog entry, but I haven't found a way to get this data.  It's the last piece of data I need to complete the call logging!