[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 595
  • Last Modified:

CUCM call routing

I have two different versions of CUCM at two different offices. Let’s call them Office A and Office B.

Office A - (USA, Version 8.6, MGCP Gateway, 2 x PRIs)
Office B - (UK, Version 8.0, H323 Gateway, 2 x PRIs)

Inter-cluster trunk is configured on both CUCM meaning we can call local extensions at both offices. The long term goal is to upgrade CUCM at Office B to match Office A version then add Office B to CUCM group at Office A. The issue we currently have is that when the 2 PRIs at office B are down, external calls are not possible until the provider rectifies the ISDN issue.

The question is during the PRI outage - how do we route calls originating from Office B out of the CUCM/MGCP gateway in office A (tail end hop off)? What would be ideal is to apply CSS to each line which then routes the calls out of Office A.

At the moment, users are having to dial a different prefix i.e. 8 + number i.e. 8 + 001 646 xxx xxxx for tail end hop off which works. 9 + 001 646 xxx xxxx would be best utilizing a CSS which points to the CUCM/MGCP at office A.

Any help/ideals would be helpful.
0
EKITA
Asked:
EKITA
  • 4
  • 3
2 Solutions
 
Bryant SchaperCommented:
Let me understand, you are not concerned about inbound calls to B when the pris are down correct?

You could have Office A provide a SIP trunk to Office B, then add that another route.  Similar to how you would handle PRI 1 and 2 and each site,
0
 
EKITAAuthor Commented:
Correct. 99% of calls at office B are outbound.
0
 
José MéndezCommented:
What you need is to configure a route group with the PRIs in office B inside, then you assign this RG to a route list. Finally, you add another RG that contains the ICT to office A. When the PRIs go down, then Callmanager will know that the next route is through the ICT. You will have to configure the ICT in office A to have the intelligence to receive the called number as it was meant for office B, and route it out. For example if you dial a local number which is local to office B, youĺl have to manipulate it so that it can be routed as long distance in office A.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
EKITAAuthor Commented:
This is already in place:
What you need is to configure a route group with the PRIs in office B inside, then you assign this RG to a route list.

When I create the RG, don't see the ICT listed as an available device...I tried searching for it but it doesn't come up. Does that mean I need to create a new ICT as well...assuming the existing ICT is already in use (dependency records show the existing ICT is in use by 12 route patterns)
0
 
José MéndezCommented:
The problem is that if you assign a device (call it a PRI or a trunk or whatever) directly to a Route Pattern, then you won't be able to see it available in a Route Group. My recommendation would be to dissociate it from the 12 Route Patterns, then create one or more Route Groups with the trunk inside, and put the RG back on those 12 patterns. This model allows more flexibility.
0
 
EKITAAuthor Commented:
feedback next week
0
 
EKITAAuthor Commented:
Worked like a charm...there were digits manipulation needed at both ends but the suggestions by willlywilburwonka was very helpful as usual. Thanks.
0
 
José MéndezCommented:
Welcome
0

Featured Post

What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now