Writing my own call accounting

[VeeDubb65]

I've been working on writing my own call account program for the mitel 3300 for a while now. This started back in 2016 when I was getting requests for phone records from various departments that were for too long ago to pull from live SMDR data. I wrote a service in python that would listed for SMDR broadcasts (from three different PBX's we have here), parses out  the various fields, and dumps the records in a database.

Then I wrote a small program in C# to do a records search without needing to get into SQL. So far, that's all I've needed.

The new twist is that we have a small call center (8 consoles) that has been using TrunkTraffic reports to monitor employee performance and call volume. The built in trunk traffic reports are terrible, and require a huge amount of manual manipulation to turn into something useful. Meanwhile, I've got this lovely SQL database with about 20 months of call data. I can reproduce everything they've been doing, except one part. They want stats broken down per-console, but the SMDR records list the consoles as ATT1-ATT16 (which is interesting since there are only 8 consoles)

Is there any way from those ATT numbers in the SMDR records to get to console extensions or names?

[VeeDubb65]

One small correction, our 8 consoles appear to be named ATT1-ATT9 with no ATT6.

ATT10-ATT16 are only on records from before we upgraded to MVB 8.0SP1 last July.

[acejavelin]

Yeah, I ran across something similar once... I have literally seen the attendant number change after a delete and re-add as was evident by seeing the attendant hold remote retrieve code change (you must enter the console hardware number as part of the dial string), I will apply that knowledge here.

My guess is there maybe one or more things going on here. It is not uncommon in Mitel systems for a device to get an ID that never changes, and doesn't get reused, which maybe why there is no ATT6. Perhaps consoles were 1-8, but before the system was placed in service they noticed they messed up something on one of the consoles so they had to delete and recreate it (or even build a new one, then delete the old one after using it as a template), or 6 may still be a database "phantom" tying up a software ID under the hood of the software in the database. No an uncommon scenario and would explain why there is no records for ATT6.

Extending that concept a little and adding a tidbit of 8.0 knowledge, it is quite possible that ATT10-ATT16 were the numbers up until the upgrade... when upgrading to 8.0 there was a frequent bug that caused Users and Device to be blank after the upgrade even though all devices worked fine. The only solution was to backup and restore the database, causing the corrupt data to not be restored and everything to be right with the world again in the ESM console. This process can also have some unusual side effects, like the hardware ID's of IP devices being renumbered to the restore order, which usually has no effect on most things, but may in this case.

Not sure if I am right or not, but it is plausible... But it also means it may not be feasible to get reports from before and after the upgrade and combine them. Or I could be way off base too.

[ralph]

Is there any way from those ATT numbers in the SMDR records to get to console extensions or names?

No.  That's how consoles are reported in SMDR. 
Here's the thing with the console count, if you delete one and recreate it, it will change it to the next ATT number.
If you do a data save and restore, it will start with the lowest extension number as ATT1, the next lowest extension number as ATT2, etc, and your skipped one will no longer be skipped.

I believe you're going to have to modify your code to parse ATTX differently and change it to whatever number you need it to be.

Ralph

[VeeDubb65]

Thank you both for the replies.

It was fairly easy to figure out which ATT# was which console based on comparing my call stats to employee schedules.  I talked to our call center supervisor, and she's fine with just putting the ATT numbers on the reports we send to them, with the understanding that any time we swap around consoles (we have two spares in a closet because life happens) some of the numbers may change, and they'll all change if we have any 'major PBX events' like a restore or upgrade.