PP

FAC AND AUTH CODES NORMALLY RISE THE NCOS HIGH ENOUGH TO MAKE THE CALL PLUS RECORD THE CODE.
LOWER THERE NCOS SO THEY HAVE TO ENTER ONE

Rachelle

I just finished reading FAC and that doesn't really apply. I was looking for something that would force the agent to enter the Charge Code before allowing a dial-tone of any kind. We have so many different codes that this has become a full-time job to make these corrections. Since it is dependent on the agent to remember to press the Charge key I was looking for a systemic solution.



rlc

PP

NOTHING LIKE THAT IN SWITCH, YOU CAN EITHER ENTER BEFORE OR AFTER DIALING THE NUMBER

Rachelle

To 4 of you, this post is going to look VERY familiar. To the rest of you I am in dire need of understanding and corrective action. We are leaning toward a buffer issue within the MDR2000. Let me know what you think.


I hope that this is up your alley. It appears that our Charge Codes are getting lost. We ran some tests this evening and we are dumbfounded. I placed 25 calls. Of those 25 calls only 13 show in MAT6.7 as having been dialed from my extension. The other 12 are totally unaccounted for. Of the 13, 2 were pegged to phones that aren't in the call center and certainly not the extension that I was sitting at and placing calls. Each call was placed by pressing the DN key, the CHarGe key, entering the 4 digit code and immediately receiving dial tone, then dialing the number as required to complete the call. All calls were sent to my cellphone.

All calls that are pushed out of the system prior to 5pm seem to charge correctly. The Telephone Center that uses this feature has less than 100 people here during the day but, the rest of the facility is pumping calls like crazy. After 5pm the rest of the facility goes home and the Telephone Center's staffing goes up to 200+ people. Only the telephone center uses the Charge Feature but, I would think that CDR would be tabing disspite the use of this key.

Why would this feature work perfectly during dayshift hours but go crazy after 5pm? Yes, the volumn of use on this feature grows but why would the CDR peg incorrectly.

We have an 81C on release 25.3 and connect to an MDR2000 using MAT 6.7. If you are available, it would be great to hear your thoughts.


Rachelle

Rachelle

To add to the confusion.

When we run a collection from the MDR2000, some 15 minutes after the last call was processed, not all calls are coming out. If we run the collection again we actually get a few more calls. At one point we were actually missing 11 minutes worth of calls.

Why would the PBX not send the calls to the buffer box?
Why would the buffer box not release the records to MAT?
Is there a baud rate issue, buffer size issue, or something in the CDB that needs to be adjusted?

With entire call records missing and call records being merged together in to one call record this is really messing things up. What is the best course of action when moving to OTM is not an option?


rachelle

Rachelle

This morning we found that a setting within the MDR was changed and it was reading the PBX speed as 1200 instead of 9600. We also noticed that the PTY (Admin) should have MTC but doesn't and the TTY (CDR) has MTC when it shouldn't. We changed the MDR setting and I will be verifying the DIPs on the paddleboard in just a bit. There is no call collection with the MDR setting having been changed so, the DIPs will be vital to fault clearing. We will need to reprogram the PTY and TTY so that the correct location for MTC messages and TRF messages is found. I am still leaning toward the MDR buffer as our culprit. I will keep you posted. If you have any other ideas feel free to toss them out.


Rachelle

jack

R,

See PM

Do you know how to log into the MDR box and monitor the data stream real time?

Rachelle

I just got back from the switch room and the paddleboard is set at 1200. That speed is all well and good until we really get cranking apparently. Regular calls, ACD calls, and the charge codes are all screwed up so it is definately a buffer/baud issue.

So, to verify my next steps, I will be disabling the two ports, flipping the enable/disable switch on the card, pulling the card out, change the DIPs and then reverse to restore. I will then go to LD 17 and change the USR data for both the ADMIN and the CDR TTYs. All of this will have to take place after midnight so, I will have all day to get my game plan together.

Anyone see any major flaws????



rlc

Ok... I don't know what happened to it but I had an ancient post that asked "Does anyone else have problems with MDR buffer boxes?" I have searched high and low on both the Nortel portel and the original PBXINFO site. Nobody claimed to have any problems with their recording of CDR info but of course virtually no one used MDR boxes.

Here is what I expereience to this day. MAT downloads CDR data from the MDR box. I look at raw data file that MAT downloads and find things like month '00' or '33'. Similar errors are found in the digits dialed and other fields. Ninety-nine percent of the glitches are repeated digits (e.g. 1123 instead of 1234). Please note these errors are somewhat rare, say one in every 2000 CDR records but then again we record about 14000 CDR records a day.

The technician has repeatedly checked the CDR output and the data is alway fine so somehow either the MDR box or the communication between the MRD box and MAT is the cause of the problem.

You might be experiencing something similar. If so then the problem is not human or M1 related. My solution to this problem is twofold. Number one, I am going to OTM. Number two, I am replacing the MDR 2000 with an Omnitronix Datalink. I have been running the datalink in parallell to the MDR for several month and FTPs from the Datalink indicate that all the records are without any errors!


SD