One major improvement UCM 7.x offers over CCM 4.x is the ability to route local calls in a far more efficient manner. If you are familiar with CCM 4.x you will know about the duplicate configuration that is required to route a local call to a local gateway. Take for example a two site environment- San Jose and Boston. Each site will no doubt be expected to dial Emergency Services and Local calls as well as a whole host of other types of calls which we are not interested in at this moment. The configuration required to achieve this is as follows:
(1) Add a gateway into the CallManager database for each site. Let’s call them SJC-GW and BOS-GW.
(2) Add a Route Group at each site containing the appropriate local gateway. Let’s call them SJC-RG and BOS-RG
(3) Add a Route List at each site containing the appropriate Route Group. Let’s call them SJC-RL and BOS-RL.
(4) Add a partition for each site called PT-SJC and PT-BOS.
(5) Add a CSS for each site called CSS-SJC and CSS-BOS each containing the appropriate partition created in step (4). Devices in San Jose and Boston would be assigned the appropriate CSS.
(6) In the case of routing 911 calls, create two Route Patterns 911/PT-SJC and 911/PT-BOS. Each Route Pattern would point to the appropriate Route List.
So you get the picture- for site specific routing in CCM 4.x we duplicate all the configuration specific for call routing and use the Calling Search Space of the calling devices to determine which RP > RL > RG > GW to use. Now that is for two sites, imagine the inefficiency in the configuration with a much larger installation!
Now this brings me onto how UCM 7.x provides a smarter way to route calls. It’s called the “Local Route Group” feature that has been added and the benefit of it can really be felt by building on the example we have used above. The new configuration that has been added can be seen when you come to step (3) above. Rather that create two Route Lists each containing Route Groups that consist of the respective site’s gateways, we create a single Route List (called RL-LOCAL-GW) which contains a virtual Route Group (called Standard Route Group). The virtual Route Group consists of the Calling Device’s LOCAL gateway determined from the Calling side Device Pool. Take a look at the two new fields which allow the local gateway to be determined on a per call basis:
The screenshot above shows a new Route List being created. Rather than adding a user defined Route Group (there are two shown in the screenshot above- RG-BR1 and RG-HQ) we use the Standard Local Route Group.
The screenshot shown above shows the Device Pool settings for site called BR1- and the Local Route Group being set as RG-BR1. Obviously each and every Device Pool would contain it’s own specific Route Group that is local for that particular site.
Let’s now compare the configuration necessary to achieve the same thing (routing 911 calls at both San Jose and Boston) as we detailed above:
(1) Add a gateway into the CallManager database for each site. Let’s call them SJC-GW and BOS-GW.
(2) Add a Route Group at each site containing the appropriate local gateway. Let’s call them SJC-RG and BOS-RG
(3) Add a single Route List containing the Standard Local Route Group. Let’s call this RL-LOCAL-GW.
(4) Add a partition called PT-911 (we could use the default <None> partition to simplify even more).
(5) Add a CSS called CSS-911 containing the partition created in step (4). Devices in San Jose and Boston would be assigned this CSS.
(6) Create a single Route Pattern 911/PT-911. Each Route Pattern would point to the Route List created earlier (RL-LOCAL-GW).
Hopefully you see the benefit of the Local Route Group feature- we have far less duplication taking place and the increased efficiency is even more obvious as the number of sites increase.
Tags: CCIE, local route group, standard route group, version 3, virtual route group, Voice
Cart
