Routing calls over cluster 1

[UCXaus]

We have just installed a Mitel 3300 (MCD 5.0) at one of our remote offices and clustered it over VPN to our head office's 3300 (MCD 5.0). I used the Direct IP route when programming the ARS (which made things a LOT easier!) and it's working fine.

Because the remote office is in a different geographic region, I've been asked to look into routing calls made from head office to the remote office's region (not to the remote office itself) through the remote office's PBX to save call costs. This would obviously have to work both ways - they would call through the head offices system for local calls that way, too.

My question is this: if I create a Route list, with the Direct IP route as first choice and the current trunks at the head office (ISDN) as second choice, if all the trunks are busy at the remote office, will my call then go out on the second choice route at the head office, or will the call get blocked at the remote office's end as busy?

I was planning on actually setting it up this way and trying it, but as this has only just been connected, the managers are excitedly calling people at the remote office via the VPN and I don't want to break it inadvertedly.

:code.poet:

 

[kwbMitel]

Yes the route list will work as you've described but I think you might be over complicating things.

When faced with your scenario, I typically create an ARS digit string to dial the remote site and access it via DISA over IP. Then I program a key on everyone's phone labeled for the remote site. if a user wants to dial thru the remote site, they press the key and dial out.

Programming ARS to achieve this automatically is ok but can be problematic to support as new exchanges get added. Also if they are not in the same toll zone then you have to consider modifying the digits depending on the system that is being dialed from.

There are numerous ways to achieve your goals, the way I see it, your starting with the hardest.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[UCXaus]

Fair enough, I hadn't thought of doing it that way before. I just thought 'Routing calls = ARS' and went from there.

Thanks for the info, I'll give it a whirl

:code.poet:

 

[LoopyLou]

You can still do what you want. The complexity comes in what the area codes are are local to each site. In my area we have "split" area codes where depending on where your are within the city and area code code be local or it could be long distance.

I believe if all trunks are busy at the remote end it will second choice to the local trunks.

You just program up the system that when someone dials 91 and the area code that is local to the other 3300, that you strip off the 1 and send the entire number across for the other site to deal with. Remeber unless you setup traveling COS/COR that the COR of the IP trunks at the far end will determine where you can/can't dial.


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.

 

[fissure]

can someone explain what programming steps the new "Direct IP route" function in MCD5 makes un-necessary, I still haven't got my head round it!

and on a related note, if you had say 4 sites/controllers
and
full IP connectivity between each site (eg a phone at any site could ping a phone at any other)
is it necessary to setup IP trunks between all 4 controllers (fully meshed)
or
if you were willing to accept the 'main' controller needed to be operational at all times, could you setup IP trunks from the 3 spokes to the hub, and setup ARS to route calls for each hub's extensions ranges to the hub, would that work? (eg a call from spoke A to spoke B would be routed to the hub, which knows how to get to spoke B, and it would directly put the phone at spoke A in contact with the phone at spoke B, as it is only the signalling/call setup, and not the actual audio that goes via the controller anyway....)

thanks

 

[UCXaus]

From the Help section on MCD 5.0:

One way uses traditional IP/XNET trunk groups and profiles; the other uses a special ARS route (Direct IP Route) that bypasses the need for such groups and profiles. Using the traditional way, you have to set up the COS, COR, and Interconnect Restrictions that define the service levels, signaling, and other attributes of the IP trunks. The Direct IP Route requires none of this setup. Instead, it uses factory-set attributes which allow for more rapid trunk provisioning, especially in a greenfield (new) installation of MCD 5.0 systems.

And for your second question, you can have one controller as the 'hub' as long as it knows how to route to the other controllers. This is how we have our offices set up with the remote offices connecting soley to our main office via VPN.

:code.poet: