Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
3300 Trunking Gateway
- Thread starter gmcnair
- Start date
Best scenario would have the 2 controllers clustered together with Maximum IP trunks.
Design the ARS on the Non-Gateway system exactly as you would if it was connected to the PSTN but set up your routes to send the digits to the gateway.
The COR restrictions MUST be applied before handing off the digits to the gateway.(i.e. Create a route for each COR required). The Gateway sees the COR of the calling IP trunk NOT the COR of the station on the originating system.
e.g. (assuming North America)
Typically need separate routes for:
011
1+ / 0+
411
1800
Local
911
All of the calls would pass over the same IP trunk group to the gateway. Typically without modification (Send 9+)
*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
Design the ARS on the Non-Gateway system exactly as you would if it was connected to the PSTN but set up your routes to send the digits to the gateway.
The COR restrictions MUST be applied before handing off the digits to the gateway.(i.e. Create a route for each COR required). The Gateway sees the COR of the calling IP trunk NOT the COR of the station on the originating system.
e.g. (assuming North America)
Typically need separate routes for:
011
1+ / 0+
411
1800
Local
911
All of the calls would pass over the same IP trunk group to the gateway. Typically without modification (Send 9+)
*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
MitelInMyBlood
Technical User
Depends on the size of the system. In the design we're about to move forward with we have 3 trunking gateways in a ring configuration. As kwbMitel suggests, the ars for the non-gateway machine is simple. Route it all to the gateways in a route list.
Our decision to use 3 gateways instead of 2 is so we can take one down at a time for upgrades, or in the event we lose one it doesn't create a crisis (or TDM trunk blocking). Triple redundancy is there for a reason and if you ever need it you'll better understand why we're doing it. The cost of the 3rd controller is really incremental and only a very few more licenses. You'll absolutely want to use SDS.
And now instead of crowding all of our TDM trunks into 2 controllers and potentially losing 50% of external call capacity, the risk is reduced to 33%. In such a configuration we could lose 1 gateway and in all but the most busiest peak time of the business day our users wouldn't even know it's down. If you crowd a busy system into just 2 gateways and lose 1, your users will feel the pain.
Unless you're one of those IP Purists and have deep pockets, your gateways are also a good place to connect your Analogs, perhaps even use a dual fim and an old 2K per node or two since that way you don't need to buy any analog device licenses or buy any SIP analog terminal adapters & SIP licenses. Just IMO licensing analog devices (modems, faxes, Polycoms, etc) when I've already felt the pain of buying 1400 IP licenses is borderline ludicrous. The old 2K PER nodes are plentiful, will practically run forever and MC320 ONS cards are dirt cheap on the secondary market. Keeping a PER node alive also gives you some very unique opportunities for non-Kosher tricks with trunking and paging when the client comes to you with a bizarre request.
Our decision to use 3 gateways instead of 2 is so we can take one down at a time for upgrades, or in the event we lose one it doesn't create a crisis (or TDM trunk blocking). Triple redundancy is there for a reason and if you ever need it you'll better understand why we're doing it. The cost of the 3rd controller is really incremental and only a very few more licenses. You'll absolutely want to use SDS.
And now instead of crowding all of our TDM trunks into 2 controllers and potentially losing 50% of external call capacity, the risk is reduced to 33%. In such a configuration we could lose 1 gateway and in all but the most busiest peak time of the business day our users wouldn't even know it's down. If you crowd a busy system into just 2 gateways and lose 1, your users will feel the pain.
Unless you're one of those IP Purists and have deep pockets, your gateways are also a good place to connect your Analogs, perhaps even use a dual fim and an old 2K per node or two since that way you don't need to buy any analog device licenses or buy any SIP analog terminal adapters & SIP licenses. Just IMO licensing analog devices (modems, faxes, Polycoms, etc) when I've already felt the pain of buying 1400 IP licenses is borderline ludicrous. The old 2K PER nodes are plentiful, will practically run forever and MC320 ONS cards are dirt cheap on the secondary market. Keeping a PER node alive also gives you some very unique opportunities for non-Kosher tricks with trunking and paging when the client comes to you with a bizarre request.
What do you think about using CX controllers as trunking gateways with PRI modiles?
Plus what would be the best practice for ACD failover besides described in the manual?
I'm looking for routing tricks how to route the same DID to redundant ACD queues with and without trunking gateways.
Plus what would be the best practice for ACD failover besides described in the manual?
I'm looking for routing tricks how to route the same DID to redundant ACD queues with and without trunking gateways.
We have used trunking gateways a couple of times and they work fine. There purpose really is to keep a call up if the 3300 supporting the phones fails. You need them if you have a MXe server becuase it supports no TDM.
Slapin: I assume your redundant ACD queues are on two seperate systems? If you do a resilient hunt group on the two systems with each always routed to its local path, you can direct a DID to two paths. The DID is the hunt group pilot. The path DN's can be different thus not violating cluster rules, you just need to make the reporting number the same in each path if you use PF for CCM.
Slapin: I assume your redundant ACD queues are on two seperate systems? If you do a resilient hunt group on the two systems with each always routed to its local path, you can direct a DID to two paths. The DID is the hunt group pilot. The path DN's can be different thus not violating cluster rules, you just need to make the reporting number the same in each path if you use PF for CCM.
Slapin, I am making a few assumptions here in this reply so forgive me if I'm off target. This is with respect to your request for routing tricks.
Assuming you have a controller failure and the PRI is now either routed to or physically connected to a different controller. Assuming a redundant(Duplicate) ACD queue is set up on the secondary box but not with the same DN's (as you said, Besides what is described in the manual).
Each system, original and secondary can have similar speedcalls with the same DN's but different termination points. Calls routed to system A will terminate to ACD queue A and Calls routed to system B (with the same DN) can terminate to ACD queue B.
*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
Assuming you have a controller failure and the PRI is now either routed to or physically connected to a different controller. Assuming a redundant(Duplicate) ACD queue is set up on the secondary box but not with the same DN's (as you said, Besides what is described in the manual).
Each system, original and secondary can have similar speedcalls with the same DN's but different termination points. Calls routed to system A will terminate to ACD queue A and Calls routed to system B (with the same DN) can terminate to ACD queue B.
*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
- Status