ESA ERRORS 2

[cscsupport]

Alright, here is one that may or may not be simple, we just upgraded an option 81c release 3.0 to 5.0, added a new core net 0 and a new network group, upgraded the signalling servers, the mc cards, etc, The only problem that we are experiencing is some esa 042 errors, Unfortunately the customer is still routing across there cama trunks for 911, because qwest is refusing to upgrade there dms so they can route calls out there pri. You can dial 911, but this doesnt appear to be when it spits the errors out, what we have found is that when you use *67 to block your number, the minute you hit * it spits out the errors. If anyone has any ideas it would be greatly appreciated.Please see enclosed errors.



ESA042 NIL ESDN PTR
% 00C004B6 00B20A4D 00B1E4B3 00B1D84C 13225E5D
% ESA42 + 00B1B991 01F5D8F2 01E97DD0 01E8A5DE 01EEF2B9
% ESA042 + 01EE8AF3 01EE2FE6 01D29AFE 01D29490 01D293E4
% ESA42 + 01D24E3F 01D1DD75 01C2884A 0122F56C

 

[cscsupport]

I have also attached to this case a capture file that prints out there esa, the route and the trunks, let me know if you need anything else.

REQ prt
TYPE esa
CUST 0

CUST 0

ENTR 0
ESDN 911
ESRT 91
DDGT 911
MISDIAL_PREVENTION NO
DFCL 5208686000
OSDN
VOLO_COUNT 0
MEM AVAIL: (U/P): 48512157 USED U P: 2871357 246563 TOT: 51630077
DISK SPACE NEEDED: 400 KBYTES
REQ ****
OVL000
>ld 21
PT1000

REQ: prt
TYPE: rdb
CUST 0
ROUT 91

TYPE RDB
CUST 00
ROUT 91
DES 911
TKTP CAM
NPID_TBL_NUM 0
ESN NO
SAT NO
VTRK NO
NODE
DTRK NO
PTYP ACO
SIGL BEL
FORM M1A
CAT
ID 0
STRK YES
ICOG OGT
SRCH LIN
STEP
ACOD 1091
TARG 01
CLEN 1
OABS
SPTO YES
ANKP NO
TIMR ICF 512
OGF 512
EOD 13952
DSI 34944
NRD 10112
DDL 70
ODT 4096
RGV 640
ATO 4992
FLH 510
GRD 896
SFB 3

IENB 5
SST 5 0
NEDC ETH
FEDC ETH
CPDC NO
ANDT NO
HOLD 02 02 40
SEIZ 02 02
SVFL 02 02
CDR YES
INC YES
LAST YES
QREC YES
OAL YES
AIA YES
OAN YES
OPD YES
CDRX NO
NATL YES
MUS NO
FRL 0 0
FRL 1 0
FRL 2 0
FRL 3 0


PAGE 002

FRL 4 0
FRL 5 0
FRL 6 0
FRL 7 0
OHQT 00
TTBL 0
OHTD NO
ALRM NO
ART 0
SGRP 0
ARDN NO
AACR NO

REQ: ltm
CUST 0
ROUT 91

TYPE TLST
TKTP CAM
ROUT 91
DES 911
TN 036 1 10 00 MBER 1 911
TN 036 1 10 01 MBER 2 911

REQ: ****
OVL000
>ld 20

PT0000
REQ: prt
TYPE: tnb
TN 36 1 10 00
DATE
PAGE
DES

DES 911
TN 036 1 10 00
TYPE CAM
CUST 0
XTRK XEM
EMTY TY2
CPAD COUT
TRK ANLG
RTMB 91 1
NITE
SIGL EM4
STRO WNK
SUPN YES
AST NO
IAPG 0
CLS UNR MFR CND ECD WTA LPR APN THFD SPCD
P10 NTC
TKID
AACR NO
DATE NO DATE

 

[tnphoneman]

Need more clarification. You are trying to block CLID to the 911 PSAP? CAMA trunks? Why are you not using ground start trunks? Are you using Pin point for 911? Print a DNB on * and see if there are any FFC?

Confused on this one, but then the carrier is Qwest. Where are you in the middle of N Dakota?

 

[cscsupport]

We are not trying to block clid to 911 calls, and they seem to be working fine. And as far as the CAMA trunks that is the same question I asked, not sure why they are not using ground start, I believe it had something to do with ani and alli with qwest there are ffc's containing *, this is how we can generate the errors. The attorneys like to block there calls when they dial out so before they dial the hit *67 flexible feature code and then dial there number, so that there clid doesnt show up on clients phones. I wish this was in the middle on North Dakota it would explain alot, however this is in the middle of Arizona, which is just about as bad. I hope this answers your questions, also they have alot of feature codes with *.

Thanks for your response.

 

[911guru]

You may have a valid bug. I'd get a Nortel ticket open on this one. I can try to recreate this in my lab i na day or so, just tied up on another big project right now.

911Guru

http://pbx-e911.com

 

[cscsupport]

Thanks pbx-e911 for your response, I appreciate all the help I can get if you get the chance to recreate please let me know, also I posted this in your website as well, was wondering if you got it.

cscsupport

2thumbsup]

 

[acewarlock]

If it happens when you hit * , that doesn't have anything to do with 911. Print your DNB using * to see if anything is there.




This is a Signature and not part of the answer, it appears on every reply.

This is an Analogy so don't take it personally as some have.

Why change the engine if all you need is to change the spark plugs.

 

[911guru]

True, but it is throwing an ESA error based on report above, so there is a hook to the ESA code someplace.

911Guru

http://pbx-e911.com

 

[acewarlock]

It must be something in the programming that has the * in it.




This is a Signature and not part of the answer, it appears on every reply.

This is an Analogy so don't take it personally as some have.

Why change the engine if all you need is to change the spark plugs.

 

[tnphoneman]

FFC or something like that.

 

[cscsupport]

tnphone, yeah they are using a ffc of *67 when they dial out to block there number, these are attorneys, and they dont want people to see there number. And it appears that this is happening when they hit the star and then dial there number, this customer has plenty of ffc's that are using the star in front of them, thanks for the input though every bit helps.

cscsupporty

 

[acewarlock]

In your post you said it happens when the hit the *

"what we have found is that when you use *67 to block your number, the minute you hit * it spits out the errors."

Can you continue dialing 67 and block the CLID? or does that not work?




This is a Signature and not part of the answer, it appears on every reply.

This is an Analogy so don't take it personally as some have.

Why change the engine if all you need is to change the spark plugs.

 

[cscsupport]

Thanks ace I dont see why they couldnt try that and see if it works, it is mostly the *67 they use, so maybe as long as it doesnt conflict with there dialing plan. Good advice just the same sometimes it is the simple solutions that just bog us down.

Thanks,
cscsupport

 

[911guru]

So I configured *67 as my CPP FFC, and placed both network and E.164 calls with and without the FFC. Not one peep from the system as far as messages go. It was completely happy with the configuration.

So here is what I would test to figure this one out:

Program another FFC for CPP that uses the *
Does the condition exist?

Program another FFC for CPP that doesn't use the */
Does the condition exist?

You seem to have a very simple LD 24 ESA block, so remove it and EDD. (MAINTENANCE WINDOW!!)

Test the 2 scenarios above as well as the *67

Rebuild the ESA datablock and test all of the scenarios. If you still see the issue, then you have some corruption someplace else in the switch. NETS may need to dig into this one.

Here is where I think the hook is that is affecting ESA:

When you make a call, any call, internal or external, and ESA is turned on, the DN_TRANS state is watching for the ESDN, so ESA is in play, momentarily at least, on EVERY CALL. Obviously the ESDN is not being dialed, so ESA goes back to sleep. The * is being picked up by the ESA detect module and causing a partial match on an errant pointer in the ESA datablock, probably og there when ESA was built.

My money is on the fix being a rebuild of the ESA datablock, but I'm not gonna 'bet the farm' ;-))

911Guru

http://pbx-e911.com

 

[cscsupport]

911, I will try that out this week and let you know how it turns out thank you so much for looking into it, it is very much appreciated

cscsupport

 

[PhonemanSam]

Why not program the attorneys phones lwith CLS = DDGD.
Then make a code to unblock there numbers when they want it unblocked.

 

[cscsupport]

911 tried using no star then a different code still had same issue, so then the customer set aside a time to out and rebuild the esa, which we all thought would fix the problem and much to everyones surprise it did not. We are going to open a ticket with Nortel and see if they can find something, if you have any other suggestions please feel free.

Thanks
CSCSupport

 

[Johnthephoneguy]

Why make this harder than it is if the only issue is outbound clid?

Build a clid table and give them all a key with an outbound clid that is acceptable, ie billing number or made up number.



JohnThePhoneGuy

"If I can't fix it, it's not broke!

 

[cscsupport]

I agree, unfortunately the customer wants it to work, as it worked before the upgrade, researching this a little farther we found that if you take out the esa totally, the errors quit, but then they dont get there proper clid etc. So this problem has to be associated with esa which is quite simple, I was also looking at the advanced clid option, kind of similiar to what you are talking about with using a key to change there number. However that would be a good idea also but we had already discussed that and they dont want to change it.

Thanks
John

 

[cscsupport]

Ok so here is the solution to the problem encountered, Nortel put out a patch on 2/19/08, patch number is mplr25293, this patch is for all versions of core, if you look it up on there espl website, you can pull it down from there and load it, I have copied the information from Nortel and pasted it here, please read below.

Thanks to all for your help
cscsupport


PEP ID MPLR25293
ISSUE 2
Old PEP Name N/A
Type PATCH
Machine CPP4 (.pp4)
Generic And Release X21 05.00W
Status RELEASED
Category GEN
Included In Deplist(s) (PRODUCTION)
Core

Included In Deplist(s) (TRIAL)

Site Dependent No
Fixed In Release N/A
Superceded By



PEP History



Event


Date/Time


Engineer


Public Access Approved 18-FEB-2008 11:02 Danny Cummings
Public View Access Approved 29-JAN-2008 16:01 Wesley Ranson
VO Status Approved 29-JAN-2008 16:01 Wesley Ranson
PEP Up-Issued 25-JAN-2008 18:01 Wesley Ranson
PEP Created 11-JAN-2008 19:01 Wesley Ranson



Title


ESA_DNTRANS problem with leading digit * causes ESA042 or real 911 call.



Problem Description


Problem Text:
New 5.00W feature for multiple ESA DNs introduced a new procedure
CHECK_ESDN_3DIGS and a new structure that it examines. There is a flaw in
this procedure / structure that can cause a * as any digit, but especially as
the first digit, to trigger either a ESA042 error, or to trigger an actual 911 call.

IMPACT:
Customer trying to dial a Flexible feature code is sent instead to the 911 operator.

Configuration changes made prior to CR submission
Out the ESA datablock, EDD, SYSload, rebuild the ESA Datablock. Problem cleared for about 1 week.

Hardware Replacement or reconfigurations made
Although the problem does not duplicate in the lab, it can be clearly seen
with diagnostics that the procedure CHECK_ESDN_3DIGS reads outside the
boundries of the structure when the leading digit is *, thus hardware is ruled out.

SETUP and ACTIONS performed to cause the problem:
HARDWARE and DATA SETUP:
5.00W CS1K with ESA configured.

ACTIONS:
1. Any set dials * or * anything for example *67 the default Flexible Feature Code (FFC) for Calling Party Privacy (CPP) feature.

EXPECTED RESULTS:
1. No 911 call.
No ESA042.
Correct Flexible Feature Code (FFC) is accessed.
CHECK_ESDN_3DIGS stays within the bounds of the structure it is supposed to read.

ACTUAL RESULTS:
1. If you are real lucky your Flexible Feature Code (FFC) works.
If you are lucky, ESA042.
If you are not lucky, a real call is generated to 911 complete with the OSDN notification.
CHECK_ESDN_3DIGS reads from beyond the bounds of the structure it is supposed to read.
Dependent on what bits are set in what it reads, you get ESA042, a 911 call, or a Flexible Feature Code (FFC) that works.