ARS and Trunks in Clustered Environment

[jburggraf]

Hello all,

I am an end-user in public school district in the US. We have 14 buildings. 2 buildings have SX2000's that have been migrated to 3300 MXe controllers and have a mix of IP and digital phones; 3 others have 3300 MXe controllers and IP phones only, the remaining 5 are 3300 CX controllers. All are running software version 5.0

We have 3 ISDN PRI's. One is located at one of the SX2000/3300 migrated sites, and the other two are at two different sites both of which are "straight-up" 3300 MXe controllers. Each site also has a few (between 3 and 10) Centrex lines used as copper back-up in case of network/PRI loss. No Centrex functions are used - in this State, Centrex lines are the cheapest form of "dial tone". This is a clustered network with IP connectivity between all buildings. Enterprise Manager is present and NuPoint is our voicemail server.

These systems were installed over an 8 year period by three different installers. The last installer spent considerable time and effort in getting many items consistent throughout before the upgrade to 5.0.

I have been modifying the ARS in each system to change terminations from Routes to Lists in order to allow us to use a PRI as 1st choice and a Centrex as a 2nd choice. a List has always been programmed for 911, but I want it for other non-emergency calls too. Given the limited number of Centrex lines, I'm limiting the phones with COR of 4 or greater to route on Centrex as the 2nd choice route.

I have run into some issues with this as I have found that the ARS settings in the systems that have the PRI's physically connected to them actually have an impact on how calls are routed out of those systems, even though the call originated at one of the other systems that does not have the PRI physically attached. For example, System A (non-PRI) has a Digits Dialed entry of 77125555 with no digits to follow, terminates on route 24 with a digit modification plan 24, which deletes one digit and adds a 9. However, until I also place this same entry into the Digits Dialed form on System B (system hosting the PRI), and with a digit modification plan too, the call fails. Also, I ran into some issues with the proper trunk being used (Trunk 24 on System A or Trunk 24 on System B can be used depending on how I assign COR values, etc.).

Do clustered systems require that all routes, ARS, etc. be identical in order to predict how routes are going to work? Should any of the ARS forms be shared using SDS? Currently, only ARS Progress Tone Detection and ARS Day and Time zones are shared - both of which we do not use.

Thank you.

 

[LoopyLou]

I would not share ARS via SDS unless you are positive everything is an exact match. I in your example systems without PRI trunks will on dialing 9 be sending that call over IP trunks to another system where systems with PRI's will be sending dial 9 our a route of PRI channels. You could probably match up everything by why bother.

You need to duplicate the ARS in each switch because each switch needs to know what to do with the digits dialed. In your example you dial 77125555 and you need ARS to look at this and send it to another sytems with outside access. You add 9 to the 77125555 and send it to the other system. The other system receives 977125555 and it needs to know what to do with it so you also need ARS setup to deal with it, so yes you need ARS in each system.

Do I take it from your example that system A doesn't dail 9 for an outside line but system b does ( and that is why you add the 9 )?

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[Lundah]

Seconding the recommendation to not share ARS data, this can cause more problems than it will fix. If you have a Mitel On-Line account, there is documentation available there that can help you diagram this sort of thing out. It's the "Mitel Voice Cluster Design & Implementation" guide on the Product Documentation page (

http://edocs.mitel.com).

 

[jburggraf]

LoopyLou: Thank you for the response. After some additional testing, I believe I found that I was not understanding IP/XNET Trunk Groups vs. TDM Trunk Groups. It appears that if there are physical analog and digital trunks on a system, calls are always routed using a TDM Trunk Group with either digital or analog trunks. But for my example, if System A has no digital (i.e. PRI) trunks, but does have some analog (i.e. Centrex) trunks, I use a list and have the list's 1st Choice route be over the IP/XNET Trunk Group to System B that has a PRI, and make certain that the Digits Dialed form in System B routes the call out on one of System B's TDM Trunk Groups that contains the PRI trunks. The list's 2nd Choice route routes the call on a System A TDM Trunk Group that contains the analog trunks in the local System A, provided that the Digits Dialed form in System A and the associated Digits Modification plan is correct.

Lundah: Also, thank you for the response. I have no access to Mitel Online, but have requested it through Mitel. We are a government account with our own AMC access, so I believe we can get access as well as some technical training. My original training was in 2002 for the SX2000 system, so when we moved to the 3300 family, I was pleased with the interface. Sure does beat the old "terminal" screens! But, I never got involved in trunking or routing, so this is quite new territory for me.

This forum is a great resource! Thanks again.

Oh, and I had to read up on UDP vs TCP to understand just how funny your signature line really is! -

 

[danramirez]

jburggraf,

ARS with the 3300 is almost the same as with the 2K. My advise is that you get your SX2000 course manual and fully understand ARS and DPNSS. If your manual is similar to mine there should include a section where you had to link all the SX2000s in the classroom using DS1 Formatter Cards, did it not?and of course there was a complete section on ARS. Once you really understand ARS nobody will stop you... trust me.

Then, with the 3300 you will substitute the T1 links by IP Trunking but it will be exactly the same as before. Make sure you UNDERSTAND how digits are handled (insert, absorb, etc) and also understand how DID (Direct Inward Dialing) works.

Pay special attention to avoid ARS loops (calls going from one PBX to the other endlessly)

Good luck! get your books and go through them over the weekend. We all will give you a hand

Regards,

Daniel

http://www.hatkana.com

http://www.wtelecom.com

 

[jburggraf]

I've been working with this now for quite a while and have come upon something of interest and concern based on what I've found programmed in our ARS and also by doing some experimentation.

Is it possible, through digit substitution or other means, to prevent a 911 call from going out of an analog trunk other than one that resides in the system from where the 911 call was placed? Here are the details:

First, assume the same entries exist in the Digits Dialed forms in all systems (with the Route Lists being slightly different depending upon if the system has a PRI or not).

Also, as added information: We are using CESID entries and AT&T's E911 "lite" package to accurately identify calls over a PRI to the correct address. While we are not drilling all the way down to each extension as a very small percentage of extensions have a DID, we do have the phones in our larger buildings programmed with CESID entries that property identify them as belonging to a specific quadrant of the building. This has been tested and has been found to be accurate.

Assuming an ARS Route List in System X with the following:

1st choice: IP/XNET to System A 3300 with PRI A
2nd choice: IP/XNET to System B 3300 with PRI B
3rd choice: IP/XNET to System C 3300 with PRI C
4th choice: TDM on local (System A) analog trunks

The above scenario exists in our system for emergency calls only. All non-emergency calls route 1st choice to a system with a PRI and 2nd choice to the local analog trunk. Through experimentation using non-emergency digits, but the same route programming as above, I've discovered that if a call is placed and successfully routes on System X's ARS Route List 1st choice over the IP/XNET to System A, but is unable to route over System A's PRI, the call remains in System A and is handled by however System A's Digits Dialed form is programmed for this string. It would appear that the only event in which the call will reach System X's 2nd, 3rd or 4th choice routes in the ARS Route List is if the call is unable to leave System X (i.e. the IP/XNET connected between the 3300's is down). While this is not all that problematic, it can become so if the call happens to be an emergency 911 call; if the call reaches System A or any of the other systems and eventually ends up going out of a non-System X analog trunk, the wrong address will be displayed at the PSAP (our Centrex lines display the physical address of the Dmarc and the billing telephone number of the account).

 

[jburggraf]

Sorry... I thought I kept my System Identifiers consistent in the above scenario, but discovered an error: The 4th choice should read:

1st choice...
2nd choice...
3rd choice...
4th choice: TDM on local (System X) analog trunks.

 

[LoopyLou]

Is it possible, through digit substitution or other means, to prevent a 911 call from going out of an analog trunk other than one that resides in the system from where the 911 call was placed?

Answer is yes it is possible. I would always create ARS to send 911 out the controller the phone is conected to. The issue becomes for hotdesk users who could be at one of your other sites when they dial 911. In that case the 911 will go out whatever ARS is setup in its primary controller. You can do a lot of ARS to fix this but happily in MCD 6 Mitel has added a means of addressing the hotdesk/911 issue.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.