|
Joined: Aug 2005
Posts: 908
Member
|
OP
Member
Joined: Aug 2005
Posts: 908 |
I am running a 5600 and three 5200s. I need to capture the SMDR information. The three 5200 can use the 5600 as their output, but I'm having difficulty understanding how to get the information off of the 5600. The V5 documentation has much more information regarding the capture of SMDR information, but it is still of no help to me. I am unable to make a connection via port 4000. SMDR is enabled in both Maintenance and Sockets.
|
|
|
Visit Atcom to get started with your new business VoIP phone system ASAP
Turn up is quick, painless, and can often be done same day.
Let us show you how to do VoIP right, resulting in crystal clear call quality and easy-to-use features that make everyone happy!
Proudly serving Canada from coast to coast.
|
|
|
Joined: Aug 2005
Posts: 908
Member
|
OP
Member
Joined: Aug 2005
Posts: 908 |
I may have found the answer. Please confirm for me. The Mitel 5000 CP v3.2 Installation Manual states "SMDR/Error message output is provided over an IP connection. You can retrieve it through an external voice processing system using a specific IP address and port number. This feature is not available in Enterprise Messaging or through Basic Voice Mail. SMDR can be buffered to System Manager, if enable or connected."
Guess what? We use Enterprise Messenger and we do not have System Manager. Is there any other method of retrieving SMDR information?
|
|
|
|
Joined: Sep 2010
Posts: 21
Member
|
Member
Joined: Sep 2010
Posts: 21 |
Diagnostics monitor will allow you to get the basic SMDR data..
|
|
|
|
Joined: Aug 2005
Posts: 908
Member
|
OP
Member
Joined: Aug 2005
Posts: 908 |
Cool, but how can I know use this information. It is being displayed on the screen. I need to get it into an SQL query.
|
|
|
|
Joined: Jun 2005
Posts: 91
Member
|
Member
Joined: Jun 2005
Posts: 91 |
You'd write your own daemon/service that also connected to the SMDR TCP/IP port on the 5000, that would request the SMDR data. As the 5000 generates it, it gets sent down the socket out to the listening daemon.
Your program then takes the data and feeds it into the database, or whatever else that is required. I do have some basic perl scripting code I wrote if you want to see some of it. Somebody else passed me their code after my first attempts, but I'm afraid I never really tried to merge the two scripts together or use their code after I asked for it..
Originally, I reverse engineered what Diag monitor did over TCP/IP, since it is a simple protocol.
|
|
|
|
Joined: May 2005
Posts: 526
Member
|
Member
Joined: May 2005
Posts: 526 |
V5.0 has an awesome report with all SMDR captured for a 7 day period. To do what dpmcintyre suggests I think you would need Third party OAI enabled. With that Callviewer works well. The maintenance agreement cost really sucks but it has some really powerful tools to filter the calls. Xarios does do cradle to grave better Randy
|
|
|
|
Joined: Jun 2005
Posts: 91
Member
|
Member
Joined: Jun 2005
Posts: 91 |
FWIW: There's three levels of logging/control.
SMDR is free and built into every license. You only get final station that handled the call logged at the end of the call.
System OAI is licensed (but its not very expensive). You get just about every event happening in the system pumped out for logging then. The expensive part is usually the call suites like Xarios or the Mitel solution to handle these data streams and present reports.
3rd party call control OAI is another licensed, but not too bad. It lets the external call monitor divert calls around (ie. queue depth too deep, divert call to this other queue, or divert it to an offsite forward).
But really, almost nobody wants to make their own software, and instead buy solutions based on these logging/control items..
|
|
|
Forums84
Topics93,970
Posts637,433
Members49,704
|
Most Online5,661 May 23rd, 2018
|
|
0 members (),
154
guests, and
34
robots. |
Key:
Admin,
Global Mod,
Mod
|
|
|
|