SimpleSMDR with 5000

[Dogbreath]

Anyone using SimpleSMDR [http://simplesmdr.sf.net] with 5000? Failing that, what are the options for a reasonably priced, basic bit of software that will keep a log of CDRs for more than one week [ie what the built-in reporting does]. Or if anyone knows how to extend the period of the built-in call logs in SAD?

[johnp]

I just started looking at simplesmdr, from what I see, it won't currently connect to a 5000 due to not having a script that can logon and capture the smdr stream.

[acejavelin]

Yeah, the SMDR stream on the 5000 is implemented rather... ummm... let's just say "oddly", it requires handshaking to start the stream to be captured.

Remember that in the Mitel System Administration and Diagnostics, you can log SMDR to a file... but this only gives you raw CDR records, it will not provide any reporting.

[Dogbreath]

I did a bit of JFGI after posting, there are Perl, PHP and Powershell scripts floating about that will send the required magic string, apparently based on a packet capture from some "official" software. Not sure if that's *all* that's required but it's a start. Whether or not I can pursue this depends on approval from above.

[johnp]

I've had time to take a decent look at Simplesmdr, and from what I see it may not be that difficult to make a 5000 script.

The connection is handled by the zconnect script, that calls the recording to mysql script. I've managed to modifiy the default 3300 to be a 3300 extended data with (caller id). which I have placed into the leading digit position.

There were a few files that I had to modifiy before the user update and zone update functioned.

Also the default smdr.sql is in latin swedish which contains some bad looking stuff. I have this fixed and I am looking at the international number dialing.

If I have the chance, I'll see what I can come up with for the 5000.

I have Procomm in the office set to pass the login when I connect, think that putty might do it also and make a log file. I guess it depends on how one likes to store such data.

[johnp]

Have moved forward a bit on this, not for 5000 but for operation

[johnp]

I'll be looking into the changes necessary for connecting to a 5000 in the next couple of days. I don't have a test system to connect to here though for real tests.

[sarond]

Thanks John,

Looking forward to see how you progress.

[johnp]

I'm in the process of determining what files aren't actually being used. I did see that I have one more file to modify the location lookup. I rewrote it in another piece and it should be just a cut a paste operation.

I've added some additional functionality to be able to download some pages into a spreadsheet and a few other things.

[Tech Electronics]

JohnP,

This should be interesting and I can't wait to see what you come up with.

Thanks,

TE

[johnp]

Made some headway, script connects and gets data. The 3300 and 200 provide the date, I'm using current capture date as it can be pulled from the string. Initial test had date correct but my other parameters weren't what I expected from adjusting the postiion to look. Don't know if I'll get more data over the weekend.

[johnp]

I did a little more, the documentation about position is in error. I still am looking to derive the date from the initial connect first Q string. Also need to discard both Q strings from the sql store, while still retaining the date.

Also looking at storing incoming caller id. Without having a local system, this may take some time to verify my code. I'll see what I can do to get a test system. I do have the capability to send caller id via PRI here at home on my bench.

[619Tech]

As an option, you can still connect Diagnostics Monitor to the 5000 system to collect SMDR and/or MSG Print. Diagnostic Monitor is a component (DiagMon.exe) of Inter-Tel Axxess software (all releases) and Pre-Mitel 5000 software. The program can connect to multiple system simultaneously, and can log those connections to file.

[johnp]

Thanks for the suggestions. I have a test 5000 and this evening programmed my adtran atlas. I'll likely have it figured out over the weekend. The original software is primarily set up for North American calls and zone pricing. I'm also thinking of adding a flat rate variable so that instead of zone rate times duration, one could make the call cost the zone price. I also wonder if I can get the Prairiefyre database info and add that to the database. Currently the NA location is only by State...international is better. Adding the 3 digit exchange would be easy enough to do the lookup. Much easier than international where it varies. From what I see, international exchanges are between 1 and 4 digits, have made it search 4,3,2,1 for the match then unknown and country.

[johnp]

Since I don't know perl so well, it took most of the weekend to get a running config. Spent a whole day trying to figure out why when I defaulted, I didn't see any data. Came to find that my default was missing a commented out line that worked for the 3300. My test bench reports both incoming and outgoing calls, records incoming caller id and takes the date from the connect line.

I did add the possibility for flat rate, limited it to use zone 1 only and match local exchange. Didn't test account codes, but they should work. I need to clear up some data before packaging but should take too long. And need to write a readme telling what to modify.