Charge Account Codes showing in MAT on non-acd, non-charging sets

[rachelle]

I have a situation where I am doubting the data I am given from MAT. It is not clear what is causing this issue. We have non-ACD phone that do not have Charge Keys showing in MAT as having charged random calls to random valid account codes. If the phone does not have a key then, how could the phone charge a call? Where would this corruption be coming from? Would it be something in MAT? Would it be something coming from the PBX? I have found this in 81Cs, 61Cs,and in 11Cs. These switches all use a MDR buffer to a central MAT console. All switches are on release 25.3. So far, this is only happening to DID numbers.

EX: Non-ACD, DID extension 1234 places a call to California. In MAT this call will show the call being placed and that it was charged to account code 2468. The next call will charge to account code 9876. The next 20 calls could go through just fine.

Account codes are set up in the Customer Directory of MAT. This is the only place that these are listed. We know that the database will accept any number for an account code reguardless of what is in the directory.

Any MAT/Switch guru out there feeling generous? This is rather urgent. It could be a legal issue if we are not extremely careful. You guys may want to read this a few times. I will thank you in advance for walking me through this.

rlc

no matter where you go, there you are.

 

[phonedoc]

does it show in the raw data? example if you connect a laptop to cdr port does it show there? if it doesnt then you probably need to change the string in the mdr-2000 box. contact me if you need further help

 

[rachelle]

These systems are spread out over several different states. I don't have access to the actual cdr ports. Even the onsite folks are bauking at the thought of interupting the data flow for the off chance of catching one of these random events. I am banging my head. What would be the issue with the MDR box? What string would need to be changed and how do I do that without MDR being involved. This needs to be an in-house fix due to lack of funding. I am sure you understand that issue. Would the string change hurt things if we changed it without seeing the raw data first? Feel free to email me directly.

rlc

no matter where you go, there you are.

 

[rachelle]

I stand corrected:

Apparently, we have a procedure for changing the string we just need to know what string your recommend. According to our paper records, we are currently using MDR-2000 customization string number 1. Does this reflect your option?

rlc

no matter where you go, there you are.

 

[rachelle]

I stand corrected:

Apparently, we have a procedure for changing the string we just need to know what string your recommend. According to our paper records, we are currently using MDR-2000 customization string number 1. Does this reflect your option?

rlc


no matter where you go, there you are.

 

[rachelle]

We have an autodialer. All calls that went out the other day were charged to various account codes. This is impossible without human interaction. These are all analog lines that only dial out using AC1+area code+NXX+xxxx. We don't know how these very real and valid account codes are getting posted to regular outbound calls.

Any help?


no matter where you go, there you are.

 

[mbendo]

Rachelle,

This is probably what is happening. When you place a call a 'C' charge record is outputted in CDR. This record is sent to the MDR-2000 and stored in a Call in Progress table (CIP TAB)and has the information for the account code time, date etc of the call. When the call is completed an 'N' or 'E' record is outputted with the digits dialed, duration etc of the call. The MDR-2000 merges these 2 records together to form one call. If you have answer supervised trunks and the call is not connected for some reason, i.e. busy, no answer, there is no 'E' or 'N' record produced. The 'C' record is still stored in the CIP TAB. The next time someone uses that trunk their called will be tagged with the account code, causing it to look like that person used the account code. This also happens when using Auth codes.

 

[rachelle]

mbendo:

That is the clearest explanation I have heard in a long time. I have a few cursory follow-up questions.
1) How do I determine if my trunks are Answer Supervision YES? I believe that they are but, I want to verify that point.
2) Is there a keystroke or a method that callers can use to send an 'N' or 'E' record if they reach a busy or are not connected for some reason?
3) Is there a practical work-around for this issue? With our high call volumn this is causing quite a problem for our billing folks.

I am looking in to what routes and members are involved in these eroneous charges. I am hoping to see a correlation. Thank you for your insights. You have given me a nudge toward better fact finding.

rachelle

no matter where you go, there you are.

 

[coniglio]

i may be way off here, but if you're asking how they are charging without having a charge key, could they be using SPRE 5? if so, can you just set that phone/ext/TN to FCAR YES and restrict it from using charge codes? did you even post your email address? you said we could email you directly. Good luck and I hope i didn't waste your time!

 

[rachelle]

rachelle.l.cassetta@census.gov

The SPRE is not known outside of two members of the Telephony Operations Staff. These charge codes are showing on modem lines, autodialer lines, and other non-human interactive equipment. I think that MBENDO is probably on to something. You see, none of the erroneaous codes are random number strings. They have all been valid, working Charge Account Feature Codes. Therefore, it does appear that a valid call is placed but, the MDR2000 is not seeing or is not receiving a call termination message. Thus the follow-up questions.

Any other thoughts are definately welcome.

rlc

no matter where you go, there you are.

 

[rachelle]

Where is the 'E' and the 'N' record generated? Is this a PBX issue or a telco or both? It would seem that at this call volumn we would have people complaining that their calls are not completing. Maybe not. This happens so much, sporatically, that it would be easier to trace if I knew where these codes originate from.

Anyone?

rachelle

no matter where you go, there you are.

 

[phonejack99]

R,

The E, N, and all the other record types are generated by the pbx itself.

 

[rachelle]

So, if the 'E' and the 'N' come from the PBX is there a way to generate this terminating character when you reach a busy or a no answer situation? We are going to have a tremendous amount of busy and no answer type calls. That is just the nature of our work. Why does the PBX not generate a terminating character when we disconnect the call?

Really need an answer to this thanks for all of your support in getting to the bottom of this issue.

rachelle

no matter where you go, there you are.

 

[rachelle]

Okay, the theory that a call goes out Rt. 2 member 4 and doesn't get the E or N so that the next call to go out Rt. 2 member 4 ends up with the charge code tagged to it... this just isn't proving out in all cases.

We ran a report for the 23rd on one route memeber and crossed referenced that with a bank of numbers that we know to be unable to charge. When looking at the report the erroneaous calls should have been directly below the call that did not complete properly. This isn't what I am seeing. In some cases the code would have been entered on this route member hours earlier and several other calls would have processed on this member without this code posting.

Is it possible that these calls are being manipulated at the MDR2000? What can be changed?

rachelle

no matter where you go, there you are.

 

[coniglio]

rachelle, I just read the entire post and I don't think you ever determined whether your outbound trunks had answer supervision set to YES. Did you check this yet? what about your NEDC/FEDC prompts? here is what I have set up for my CDR:

CDR YES
INC YES
LAST YES
QREC YES
OAL YES
AIA YES
OAN YES
OPD YES
NATL YES

good luck!

 

[rachelle]

All of my circuits are ISDN. I don't get the prompt for Near End Disconnect or Far End Disconnect. I have not determined the ASUP question either. I don't think with ISDN that is a prompt either... I'm not really sure. I don't recognize the prompts from your CDR data block. Mine read as follows:

CDR YES
IMPH NO
OMPH NO
AXID YES
TRCR YES
CDPR NO
ECDR YES
PORT xx
BCAP NO
CHLN 06
FCAF NO

The above was found be LD 22 PRT CDR. Where did yours come from?

rlc

no matter where you go, there you are.

 

[rachelle]

I replied too quickly. I look at my route and found the prompts that you posted. I have all set to YES except for AIA and NATL. What is the benefit or danger of setting these to YES? What changes will I see?

rlc

no matter where you go, there you are.

 

[coniglio]

AIA means Answered Call Identification Allowed
NATL means North American Toll Scheme (NO means not used). I am not sure if you will be in any danger if you change these but i don't think you will. Especially the AIA one. That sounds like if you set it to YES it will help (although the default is NO). If you post your fax number I can email you some info that may help.