Mitel Prairiefyre 6110 Real Time SMDR

[ehfrancisco]

Hi All,

I have an unusual question. I have 2 Mitel 3300’s connecting to a Prairiefyre 6110. We use the 6110 primarily to monitor Agent activity and as a central point to accumulate raw SMDR data. This has worked well for a number of years but now we are trying to expand the use of the 6110 by reading the internal database directly. Specifically, there are two tables, tbldata_Inbound and tbldata_outbound where the SMDR call records are stored. We would like to use those tables as a live call data source.

Every day at 2AM a maintenance routine that summarizes the call data from the day before and stuffs it into the two above mentioned tables. I can update the tables manually by running the Summarize Data function found under Maintenance in the CCC. When the Summarize Data function is run manually the current days data is stuffed into the two tables. In addition, call activity continues to be stuffed into the tables for the remainder of the day, making these tables a very good way to access a real time call data source. The problem is, at midnight the real time stuffing stops. I have to run Summarize Data to start up the real time stuffing of these tables again.

Like I said, this is an unusual question, but does anyone know if this is normal? The stopping of the insertion of the call data into these tables that is. The data is still being captured it’s just not showing up in these tables in real time unless I perform a Summarize Data first.
Anyone know anything about this?

Thanks

 

[Mitelpassion]

in this instance I would imagine collecting the raw data fro the source.

TCP port 1752 for the SMDR and port 15something (check this one) for the ACD real time events.

no need to look at the db tables then.how excately are you expanding the use of 6110 by reading the data, unless you want to manipulate it into something else?

Remember the SMDR string is only created after the call has completed. only the ACD real time would show events as they've happend. i.e call on hold, agent state etc.

again depending on what you want to be the end result, one would have to look at if what you are doing is the best way of achieving this.

 

[bobcheese]

Does it not just start writing to a new file for the new day at midnight?

 

[ehfrancisco]

Mitelpassion,

Yes, reading the data directly would be one option, but I am dealing with database geeks. They would like to be able to read from an existing database and not have to parse the raw SMDR output. There is a lot more information in other tables that they would like to access. Being able to see the calls in real time is key to their project. They are trying to provide a dashboard that shows an agents real time statistics and want to use the 6110 database as their source.

And yes, we do know about the call record not appearing until the call is complete. When it’s working that’s exactly what happens.

Thanks,

 

[ehfrancisco]

Bobcheese,

I believe you are thinking of the raw SMDR data files that are created every day. In this case I am talking about the 6110 database the raw data is stuffed into. This database is useed buy the 6110 reporting module.

Thanks

 

[Mitelpassion]

Prairie Fyre have a CTI app tool that will do all of this for you then.

you could 'write' your own dashboard and use their tool to populate it with data.

apart from that I personally don't know the answer to your question

 

[slapin]

There is a separate data stream from ICP with real time ACD information. Look for data interfaces manual on MOL. Plus PF database is not intended to be a data source for a third party applications, so they can change layout and procedures at any time without any notifications in any upcoming versions.

All you need is a simple TCP client with some errors handling procedures and a parser for very well formatted and documented data stream. A good programmer can complete entire project in one day.

 

[Mitelpassion]

slapin, I agree - this would be the best option, get the data straight from the source

 

[ehfrancisco]

Okay,

Can I get you guys to come over and tell my web developers what I have been trying to tell them for months now? You folks have just confirmed what I already knew.

We tried this a few years ago but found the data source very unreliable. We have a new bunch of programmers who think they are smarter than the old bunch.

But, I am just the lowly IT guy who must be dumber than a rock because I am not a programmer.

Anyway, thanks all for the input.

 

[slapin]

So, new bunch could be more flexible and can blame everything to the old bunch. As a result you can get something working. What platform they are working on? Windows, Linux, something else? Which framework they prefer? Usually when you are working on the product, you will not build entire infrastructure from the ground up, so they got to use some sort of framework such as .NET, Boost, etc.

 

[ehfrancisco]

They are working on .Net.

Unfortunately the new bunch is less flexible than the old. The old bunch tried very hard to get this working. The new bunch won’t even try. If it doesn’t work the way they think it should it must be broken, and of course my job to fix. If they can’t pull the data from the 6110 then the 6110 must be a bad product or just not working correctly.

 

[slapin]

The first thing that 6110 does not provide data feeds to any third party applications. That means you break your license agreement by connecting directly to the database. And it is enforcable by law. So, they cannot demand anything from you. If they want to mess with the stuff, then it is their responsibility to figure out how to use available resources. PF has some sort of .NET API. I don't know what functionality is provided through it, but this is the only proper way for integration of 6110 with other applications. Yes, you have to buy it.

 

[ehfrancisco]

sapin, that's exactly what I told the database guys. They are actually thinking of adding additional tables to the 6110 database. I am about 3 versions behind in upgrades. I am thinking about doing an upgrade after they get everything working just to see what happens.

 

[slapin]

I'm pretty sure that stuff will stop working or will do unexpected things. If it is a contractor or freelancer don't allow any modifications to 6110, because they may refuse to support it later and PF will not help you ether.

 

[JimHilton]

I'll toss my 2 cents in. We run PF as well, but I have no idea what what the database format is.

However, if your programmers are using .NET then this is a no brainer. I am fairly sure you can set one of the ports on the controller to send out SMDR via TCP.

All output could be captured by Microsoft Internet Control (called that in VB6 not sure in .NET).

Once an event "fires" they can grab the string and do whatever the heck they want with it.

I'm allllllowly working on a dedicated program to capture the IP SMDR.

Tell the crew they are over thinking this, the data you want is free and constant right from the controller! And its very possible that PF may not keep some of the stuff you/they want. And as mentioned if PF adds/removes a table that gonna bork what ever program is written.

Hope that helps!