How to Turn Off BARS? 1

[Gary7B]

We have an Option 11c with new PRIs from a VoIP provider who will accept any number of digits: 3, 7, 10, 11, 011+, and "do the right thing." Furthermore, we want to have new extensions in the 900's like 9xx. So we think it is time to turn off the "dial 9 to get an outside line" as well as eliminate the 2nd dial tone one hears when they dial 9. Just want to route everything over the two PRIs (except internal extensions which are 2xx and 5xx).

Should I do that with CDP/DSC? Will a DSC of 9 override the ac1 or conflict with it? Thanks for your help.

 

[GHTROUT]

If you turn off "9" to get an outside line, how do you plan to get users onto these PRIs to make calls outside your building?

If you want to have extensions in the 9's, like Extn 913 for example, how will you route a call to 913135551212? It will ring extension 913 after the 3rd digit is dialed.

In other words, your plan has a flaw. You need to have a digit that accesses the trunk group.

You could change the AC1 to a 3 digit number, one you will never use, then you can "free up 9" and make it the Trunk Route Access Code for the new PRI trunk route.

--
GHTROUT.com - Help for Nortel Meridian/CS1000 System Administrators
--

 

[Gary7B]

Yes, I see your point, that used to be true. But, as I tried to say, the VoIP provider will "do the right thing" based on how many digits he receives. So, since only 2xx and 5xx extensions are on-site, I want to pass everything else over the PRIs, e.g. 876, 915, 9151234, 9154371234, 19154371234, 01197224371234, etc. He will route a call to ext. 915 over his network and pass everything else over to the PSTN. So I want to remove the 9 altogether as being the digit that accesses an outside line. Basically, I'm trying to get the Nortel M3904 to behave, dialing-wise, like one of the VoIP phones. I realize that in dialing 8xx or 9xx, the call will not complete as quickly since the system will have to figure out when you're done dialing.

From your answer, it seems I cannot just "turn off" BARS but must "disguise" the ac1 so it is not accessed. I then plan to send all off-net dial strings (like the above) to the PRIs via DSCs in the CDP. Can you tell me where the ac1 is changed?

 

[GHTROUT]

Your PRIs are on a trunk route, therefore nothing is magical. You will not be able to route calls without a Route Access Code or Bars Access Code that points digit strings in the right direction.

The carrier may have magical routing - the limitation is that your PBX does not. It routes calls to trunks based on digits dialed.

You can OUT all of BARS and the AC1, but it is too much work when all you have to do is "change" the AC1



--
GHTROUT.com - Help for Nortel Meridian/CS1000 System Administrators
--

 

[GHTROUT]

AC1 is changed in LD86, FEAT ESN

--
GHTROUT.com - Help for Nortel Meridian/CS1000 System Administrators
--

 

[DocVic]

Use XLST to do all of your dialing.

DocVic
Dedicated to Nortel Products till the end.
Need help?

http://www.TSS-CO.com

 

[GHTROUT]

Then how do you dial internally.

--
GHTROUT.com - Help for Nortel Meridian/CS1000 System Administrators
--

 

[allenmac]

Aren't your users already accustomed to dialing '9' (or something else) for an outside line? Why retrain everyone, when the functionality is already built into the system.

As for your CDP codes, I would ditch that plan and just use Vacant Number Routing to point unmatched digits to your VoIP route, since they 'will do the right thing'...

 

[Gary7B]

Yes, you're right about everyone being accustomed to dialing the '9' to get out -- but I am being "forced" to now add 9xx (off-site) extensions. How else can I do that other than to eliminate the ac1? I know someone will suggest that this is the time to have gone to 4-digit extensions rather than adding 9xx. But we are not that large (150-200 users) and eventually, the Nortel will go away, they will all get VoIP phones, and will not have to dial 9 or even the 1 before the area code. So I'm trying to implement something equivalent to that on the Nortel in the meantime.

 

[allenmac]

So if I understand correctly, you would like your dialing plan to look like this (simplified - assuming no other internal DNs used for anything else):

0 - Unused (or attendant)
1 - Unused
200-299 Extensions (local)
3 - Unused
4 - Unused
500-599 Extensions (local)
6 - Unused
7 - Unused
8 - Unused
900-999 Extensions (Off-site)

The biggest problem you are facing is the fact that you want to be able to dial numbers without using access code(s) to differentiate between call types, but this is not really practical with a PBX.

For instance, there is no way to dial PSTN numbers that conflict with your internal extensions (2xx, 5xx), the system will route the call to the DN as soon as there is a match.

Also, for calls beginning with '9' you will need to collect digits and then wait for the 'end of dial' timer expires, then send those calls to your VoIP route where your provider will translate the digits, and deliver the call to the proper destination. The delay on these calls will be annoying.

International and Operator assisted calls will be impossible if you use 0 for an internal attendant, as the system will route the call as soon as 0 is dialed.

Unfortunately, Traditional telephone systems are not designed to operate in the manner you desire, so although you could probably find a way to work around some of the issues, the amount of system programming required would be prohibitive.

 

[GHTROUT]

I think you will find whomever told you you did not have to dial 9 or 1 for any outside calls was incorrect.

The worlds dial plan just does not work like that. Example

425-882-8080 is Microsoft in Redmond

425-8828 is someone else, local to you

425 is one of your extensions.

Your sources for the info on the magical trunks are incorrect.

--
GHTROUT.com - Help for Nortel Meridian/CS1000 System Administrators
--

 

[Gary7B]

Yes, that dialing plan is about right -- there are also 1xx and 8xx off-site extensions. As you point out, I can't yet relieve them of the 1+ dialing they do now for PSTN calls as that is how they will be able to reach 2xx and 5xx area codes. But I think I can eliminate the '9' and then just send all digit strings except 2xx and 5xx to the PRIs. In fact, if bandwidth is not a problem, I can send EVERYTHING out and let the external VoIP switch send my 2xx & 5xx calls back in! That way, I can turn off Mermail and have everyone in that office start using the new voicemail with all of its fancy features, e.g. message notification, voicemail-to-email, etc. You're right, though, about having to deal with the end-of-dialing timeout in that case.

 

[bhassell2000]

so you could change Ac1 to a 3?

Thanks,

Buddy

Linked in Profile

http://www.linkedin.com/pub/buddy-hassell/7/5a5/b8b

 

[allenmac]

Any DN that exists in your switch and is 3 digits, will prevent you from being able to dial longer numbers that conflict with your 3-digit extensions, for example, if you have an internal extension 202, you will not be able to dial (if it were a local call) anything in Washington DC (NPA 202), or any local number within NXX 202 (202-xxxx).

The same applies to your 5xx local extensions.

You cannot have a DN programmed on the system, and then dial a longer number that conflicts with the shorter DN, the system will ignore (by design) everything you dial after the DN is matched, and route the call to the local DN.

 

[janaya]

Or you can change AC1 to somethig you will never use (999 - and tell them not to use this as an off premise location.

Then build a huge TSC table and route the calls ou this way based on area codes 1NPA5551212 and then add your NXX's NXX1212 and then your off premise extensions.

But you have limitations:

Max number of steering codes in the CDP is 5000. You are going to push that but you could build short codes

1NPA
NXX
Extensions.

It's just building the switch like the LEC, eliminating an access code to get out. This way you can still implement the NCOS restrictions based in your RLB settings.

But you will have conflicts with NXX listings in your Extension ranges, unless you provide them with a full 7 digit DN. Then you just tell everyone "Dial like you do from home."

Then you have to touch each mailbox to put in a second DN for the new 7 digit extension.

But you have to have the DNXP package for DN Expansion.

You can do it, but it takes a while. You will have to cross reference all Trunk Access Codes, all FFC codes, any DN in the system that will have to be changed to accomodate the dial plan.

Hope this helps.

 

[Avaya911PLM]

Interesting thread for sure. So let me put another wrench in the works.

What about 911 calls? You'll have some conflict with your 9xx range for sure.
There are ways to get around having to actualy dial the AC1 code, such as building pretranslation to insert one for you so you have all of the features in NARS/BARS.
But if you build ESA properly, then you will have issues with 911 calls potentially.



--
Fletch
Avaya E9-1-1 Product Manager

 

[GHTROUT]

I believe these trunks "sense the danger" and dial for help before the user knows they need help.

--
GHTROUT.com - Help for Nortel Meridian/CS1000 System Administrators
--

 

[Gary7B]

Janaya, nothing that complicated is required as the SIP trunks know where to send the calls based on how many digits I send them.

Allenmac, the way to get around the DN matching is, as has been noted by some, to use XLST pretranslation -- thereby inserting the '9' to pass any digits dialed to the PRIs.

GHTROUT, indeed, the magical SIP trunks do a very good job of distinguishing 425 (stays on-net) from 425-8828 (inserts 212 NPA) from 425-882-8080. My SIP provider (and hosted VoIP provider) is Stage2 Networks using Level3 backbone.

Fletch, indeed, the SIP trunks are programmed for E911. However, since I still have my copper COT backup lines, I am still routing 911 over POTS. And the way I do that is with an SPN of 11 and also one for 911 in case someone is not sure whether to dial 911 or 9-911. I also prevent erroneous calls to 911 by using FLEN 3 on the former and FLEN 4 on the latter, and then DENYing any digit dialed after the second '1'.

 

[johnpoole]

i did not read all the replies.. you can change ac1 from 9 to any vacant number up to a four digit number... but that said your voip provider is an idiot. but i'm sure anyone that would program a switch in that manner will not have any trouble finding a job

john poole
bellsouth business
columbia,sc

 

[Avaya911PLM]

Fletch, indeed, the SIP trunks are programmed for E911. However, since I still have my copper COT backup lines, I am still routing 911 over POTS. And the way I do that is with an SPN of 11 and also one for 911 in case someone is not sure whether to dial 911 or 9-911. I also prevent erroneous calls to 911 by using FLEN 3 on the former and FLEN 4 on the latter, and then DENYing any digit dialed after the second '1'.

Gary, here are a few points you may want to consider:

1.) By sending 911 over the POTS, you will not be able to send any specific location other than the front door address. Since the CLID is fixed to the POTS number. This may be OK for you, but maybe not. You need a PRI to send a specific CLID out that may match up with a PS-ALI record to give the first responders more accurate location information.

2.) The way you are preventing erroneous calls will work, but not if you want ESA programmed properly in the system. Calls to SPN 11 will not be treated as ESA calls unless that RLI does and LTERM to 911 programmed as the ESDN in LD 24. The better way to block calls is to enable the Misdial Prevention feature introduced in the 5.00 software stream, or apply a special patch that was written for previous releases. The patch is MPLR20340, and is available at no charge form Avaya support. Your vendor may charge for patch installation though based on your maintenance contract with them.

There are some videos I did on Release 5.0 that are still on the old Nortel YouTube Channel that have helped a lot of folks understand E911 and how it can be programmed effectively to solve most everyones E911 problems.

YouTube Misdial Prevention Video -

http://www.youtube.com/watch?v=EvPMDdB_koY

YouTube How E911 Works Video -

http://www.youtube.com/watch?v=GU8s79conXE

YouTube CS 1000 ERLs Video -

http://www.youtube.com/watch?v=8hEPFif0IaY

YouTube CS 1000 Dynamic ELIN Callback Video -

http://www.youtube.com/watch?v=DPSD8Gl9_wg

YouTube Location Accuracy vs. Location Resolution Video -

http://www.youtube.com/watch?v=3S4extSN5z0

YouTube CS 1000 ESA Implementation (Part 1) -

http://www.youtube.com/watch?v=KTWDBfnkcZQ

YouTube CS 1000 ESA Implementation (Part 2) -

http://www.youtube.com/watch?v=c5rHw0GYsQ4

YouTube Advanced Caller ID Configuration -

http://www.youtube.com/watch?v=bN1iy5-buhE

Some Google KNOL Articles I wrote can be found at:
Google KNOL Article E911 Liability -

http://knol.google.com/k/-/-/1558rwj796sda/2#

Google KNOL Article Location Technology -

http://knol.google.com/k/-/-/1558rwj796sda/8#

Google KNOL Article How E911 Works -

http://knol.google.com/k/-/-/1558rwj796sda/6#

Google KNOL Article Location Accuracy v. Location Resolution -

http://knol.google.com/k/mark-fletcher/e911-location-accuracy-vs-location/1558rwj796sda/12#

And finally I will be the guest on this weeks Telecom Junkies (

http://telecomjunkies.com)

where I will be taliking about the new California Public Utilities Commission initiative on MLTS (PBX) E911 compliance.



--
Fletch
Avaya E9-1-1 Product Manager