R6.0 and ESA / ESDN Dialing Conflict

[NortelGuy1979]

All,

We are currently going round and round w/ an Avaya / NES ETAS engineer (two, actually) regarding ESA dialing.

We have a site that, due to routing requirements, has their 1-800 SPN's broken down further than just 1-800. We wanted to use SDRR / ARRN, but, due to the level they needed broken down, we ran into the SDRR table limit. So, we have an SPN of 1 800 99 as such:

SPN 1 800 99

SPN 180099
FLEN 0
CLTP NONE
RLI 1
DENY 00079
DENY 06969
DENY 1661
DENY 17733
DENY 41800
DENY 42625
DENY 53825
DENY 59938
DENY 72833
DENY 78325
DENY 83977
DENY 86749
DENY 91061
DENY 91616
DENY 92223
DENY 92625
DENY 92867
DENY 93825
DENY 94553
DENY 94624
DENY 94676
DENY 95477
DENY 95683
DENY 96117
DENY 96666
DENY 96749
DENY 97399

Our ESA setup is as such:
REQ prt
TYPE esa
CUST 0
CUST 0
ENTR 0
ESDN 911
ESRT 0
DDGT 911
MISDIAL_PREVENTION NO
DFCL
OSDN
VOLO_COUNT 0

What happens is that when we dial a number AC1+1-800-999-1118 then we get re-order. If we watch the TN in LD 80, the call trace shows:

.14:52:29 30/07/2010
TN 020 0 05 00
KEY 0 SCR MARP ACTIVE TN 020 0 05 00

ORIG TN 020 0 05 00 KEY 0 SCR MARP CUST 0 DN 73993 TYPE 3903
SIGNALLING ENCRYPTION: INSEC
TERM NONE
TDTN 0 SLOT 11 PTY SLOT 11
DIAL DN 9180099911
MAIN_PM REOR
TALKSLOT NONE
EES_DATA:
NONE
QUEU DIAL
CALL ID 0 755

So now, two engineers are trying to tell us this:

=========================
I would try to explain with the example used at the site:

The Number Being Dialled 918009991118.

Lets divide the number into AC + SPN + internal DN.

So the Digits are interpreted as 9+ 180099+91118
In this case all the leading digits of that internal DN match the ESDN digits. which means internal DN 91118 has leading digits 911 which conflict with ESDN 911.

Now let us consider another example with the changed SPN 1800999.
Now the dialled number is divided as
9+18009999+1118
Here the leading digits of internal DN 1118 do not conflict with ESDN 911.Hence this SPN configuration is a working.


Hope i have cleared your doubt, let me know if you have any other queries.
=========================

I call BS on this - because the 91118 portion of that dial string is NOT an internal DN or CDP code. They then tried to quote the NTP to back up the theory by saying:

Do not configure a BARS/NARS dialing plan, (that is, Access Code (AC) + Location Code (LOC)/North American Planning Area Code (NPA)/Central Office Code (NXX)/Special Number (SPN)), that is the same length or longer than the ESDN, to have the same leading digits as the ESDN.

If there is a BARS/NARS dialing plan, equal to or longer than the ESDN, and all the leading digits of that internal DN match the ESDN digits, then calls will not terminate on that dialing plan, because ESA calls receive priority. For example, if the ESDN is 911, and there is a BARS/NARS
dialing plan having an access Code of 9 and a Special Number of 114, then whenever someone tries to dial 9114, they are automatically routed to the PSAP as an ESA call.

¿ Do not configure a BARS/NARS dialing plan (that is, Access Code (AC)+ Location Code (LOC) / North American Planning Area Code (NPA) / Central Office Code (NXX) / Special Number (SPN), that is shorter than the ESDN, to have the same leading digits as the ESDN.
If there is BARS/NARS dialing plan, shorter in length than the ESDN, and all the leading digits of that internal DN match the ESDN digits, then callers may be prevented from making ESA calls. For example, if the ESDN is 911, and there is a BARS/NARS dialing plan having an access Code of 9 and a Special Number of 1, then whenever someone tries to dial 911, they are automatically routed out as a BARS/NARS Special Number.

We don't match any of those scenarios.

1) No DN or CDP w/ leading digits 911
2) No AC1/AC2 + LOC/NPA/NXX/SPN w/ leading digits 911 EXCEPT SPN 911 w/ RLI LTER = YES (per ESA programming requirements).

Anyone run into this before? My local engineers are telling me they saw this on 5.5 also, but didn't report it as the site was upgrading to R6.0.

If what the ETAS engineer was saying was true, then anything dialed after ANY NXX or SPN could possibly conflict.

Assume NXX 503, dialed number AC1+503+9112 (503-9112 could be a valid public number) - if ETAS was right, we wouldn't be able to dial that call.

Thanks in advance,
Matthew

Matthew - Technical Support Engineer

 

[Triton101]

what happens when you dial the SPN without the AC1 (9)

180099+Rest of number

__________________________________________________________
Find a job you love and you'll never work a day in your life. - Confucius

 

[NortelGuy1979]

Triton101 - we get re-order, as expected, because 1800 isn't programmed in the PBX as a dialable number. 1 800 99 is an SPN sitting behind AC1.

Matthew - Technical Support Engineer

 

[Triton101]

FLEN 0

you might want to adjust this as well, so that the digits are sent out as a whole number.

set it to 16 for testing and when making a test callpress # at the end of you Dial string to send.

__________________________________________________________
Find a job you love and you'll never work a day in your life. - Confucius

 

[Eticas]

You are correct in calling BS to ESA being the cause. What the NTPs refer to are the leading digits conflicting with the ESDN. In your example, AC1+1-800-999-1118 (assuming AC1 is 9), the leading digits are 918 and your ESDN is 911. No conflict. Subsequent digits do not come into play. If the first digits dialed do not match the ESDN exactly then the call does not get treated as an ESA call.

The concept behind what you are doing with the supplemental digit restrictions is also valid. We do the same thing at one of the schools we maintain. We block AOL dial up numbers that way.

So, we need to determine what is blocking the call. I would begin by identifying how the call is routed out of the system. Based on the programming listed, the toll free call is being placed using Route List Index 1. I would print out the RLI and identify what the routes are that are being used to process the call. I would then attempt to use the maintenance set to direct select trunks in the routes listed in the RLI, bypassing BARS altogether. Access the trunk via a set with MTA class of service. (SPRE + 91, 53#36##, 875# + TN using # as the space between the digits for the loop/shelf/card/unit or, for a T1, loop/unit + ##). Assuming the trunk is not busy, you should hear dial tone and be able to place a test call to 1-800-999-1118. You will also see the commands displayed on the TTY as well. For example, if your SPRE is ‘1’ and the TN of a trunk you are testing is 4 0 1 7 then the dialing string would be: 19153#36##875#4#0#1#7## <hear dial tone> 18009991118.

You can also force the calls out subsequent entries in the RLI by turning off a given entry using TOD (I have seen carriers that will restrict toll free numbers to certain calling areas – mostly in the same state from where the call is being placed). i.e.
> LD 86
REQ CHG <return>
CUST 0 <return>
FEAT RLB <return>
RLB 1 <return>
ENTR 0 <return> <assuming zero is the first entry used in the RLI>
LTR <return>
ROUT <return>
TOD X0 X1 X2 X3 X4 X5 X6 X7 <return>
CNV <return>all the way thru to REQ

Same procedure to enable the entry after testing except :
TOD 1 2 3 4 5 6 7 <return>

Post the results of your testing. I am curious to see how it goes.

Regards

 

[NortelGuy1979]

The PLM team for ESA called BS too, and re-opened the case.

The documentation is 100% correct (which I didn't doubt) but the original engineer's interpretation of digit conflicts was wrong.

$20 on a patch.

-M

Matthew - Technical Support Engineer