SMDR data missing

[jvazquez]

We have a custom solution in place to record and review calls that come in to our call center. While this solution has worked for the most part, there is one aspect of it that has never worked properly.  We have given up on the developer, we can't even get him to call us back anymore.   So we are on our own trying to figure what the problem is.  Basically, we just need to figure out why SMDR data is not available for Saturdays and Sundays. 

The Mitel uploads a text file to our FTP server on a nightly basis.  It works every weekday, but on Saturdays and Sundays the contents of the file look like this: https://skitch.com/jorge_vazquez/82dmd/vtlogger  I am hoping someone here can help me by telling me what it is I need to change in order for weekend calls to be logged.  Thanks in advance.

[ralph]

That doesn't look like SMDR to me.   That looks like an ACD stream monitor telling you it hasn't gotten any data for a while.
Are you using ACD agents?
Next question, I don't think the 3300 can schedule an FTP upload of SMDR to a server.  You must be pulling it from somewhere. 
What is the server you using to connect to the 3300?

Ralph

[jvazquez]

Please forgive my ignorance, I am trying to provide the best information for you to be able to help me.  I am limited in my understanding of this Mitel box, and the lack of documentation for me to refer to makes it all that much harder.

The server that gets the SMDR data is a generic PC running Ubuntu and some application called VTLogger.  The VTLogger application has been heavily customized for our purposes.   This server has a VoiceTronix board installed with a couple of T1 interfaces.  I believe that the board is some sort of a Sangoma WanPipe variant.  On one of the T1 interfaces, there is a cable that is split from the line that feeds into the Mitel.  The VTLogger box also has a connection to the network, and the usual connections to a keyboard, mouse, monitor, and power are all there as well.  The VTLogger box does not 'pull' the SMDR data, that much I know for sure.  The SMDR data is delivered to it via FTP shortly before midnight every night.  I simply assumed that these text files were being put there by the MItel box, but you seem to think otherwise and I trust you know what you are talking about. 

There is another piece to this puzzle that is called Prairie Fyre.  We are not certain if this is relevant.

Normally, the text files that contain all of the SMDR data are FTPd to the VTLogger shortly before midnight.  At exactly midnight, a process runs on the VTLogger that imports all of the SMDR data to a MySQL table and then moves the text file to a different directory in case it is ever needed again.  This database import process fails when it tries to process the files that are generated for Saturday and Sunday because the files don't contain any SMDR data and instead look very much like the image what is shown on the image I linked to in my original post above.  We just want to figure out why the SMDR is not being captured and it is a bit of a challenge with our limited knowledge of the system.

We do use queues and I think that is what our agents 'plug into' - I am not sure if they are ACD agents.

[bluewhite4]

I think the mention of PrairieFyre will answer a lot of Ralph's questions. Sounds like you have and ACD queue with Agents, and the PrairieFyre box is setup to do ACD reports on those queues.

From a quick Google search, combined with the fact that T1's are plugged into your VTLogger computer, I'm going to say that that computer is acting as a call recording server.

Since you say that the SMDR data is being delivered to the VTLogger, I'm going to guess that there's something on your PrairieFyre server facilitating that. I'm also not sure you're getting SMDR data, but queue information like Ralph said.

The problem maybe that your PrairieFyre server isn't setup for 24x7 operations, and instead is set for 8x5, so isn't collecting logs on the weekends. If you open the ip address of your PrairieFyre server in a webpage (ie http://192.168.1.1/ccmweb) you should be able to login and either run reports to verify this, or go to the help->about section and give us some information on your PrairieFyre system.

[ralph]

The 3300 "prints" logs to the PrairieFyre via an IP port in real time.  (You can find the port numbers in the 3300 help files and telnet to it if you want to see the actual real time logs.)  PrairieFyre will collect all your smdr data from the PBX via the IP port constantly.  If anything is doing an FTP PUT to your VTlogger it would have to be the PrairieFyre.
It makes more sense to me now.   On weekends you would not be generating any calls so there is no smdr or ACD logs generated.   When this happen the PF will generate it's own log showing that it isn't getting any records.   You can adjust the amount of time the PF waits for a record before it generates the log you show in your screen show.  (I'm not a PF tech so I can't tell you how).



What ever scripts are being used on your VTlogger my have to be modified so it doesn't crash on this error.

Ralph

[jvazquez]

You are correct, the VTLogger is used to record our calls so that supervisors and managers can later use this information for quality and training purposes. This box came with its own software that was not very useful to us and so we had to get something custom developed.  I am finally starting to get at least a general understanding of what is going on - thanks in no small part to the help you have so kindly provided here. 

I think the problem may be that - like bluewhite4 suggests - that the PF box is set to collect data on an 8x5 schedule.  This is probably because the office itself is closed on weekends. The call center is operational on Saturdays, however.  So what I am guessing now is that the 'collector service' is bound to the business hours specified for the organization instead of being bound to the business hours of the call center itself, if that makes sense.

If it helps, the data in the files typically looks something like this https://skitch.com/jorge_vazquez/858kg/javazquez-root-pritap-var-www-vtlogger-ssh-218x61
We call it SMDR data because that is what we were told it was.

I will gather the information bluewhite4 has asked for from the HELP/ABOUT section of the PF system and will report back on Tuesday.

Thank you ralph and bluewhite4 for sharing your knowledge and expertise in this matter - it has made a tremendous difference thus far.   

[ralph]

The screen shot is SMDR so what you were told is correct.
Since I'm not a PF tech I may be flap'n a bit but I think that PF will collect all data 24x7 no matter what the hours are.

Ralph

[Mattmayn]

Could PF simply not be set up to run the report on the weekend and that is why the recorder is missing the info? Hate to over simplify this but sometimes that is the answer!