One of the major enhancements on Cisco’s Communications Manager 7.x (CCM7) is the concept of Local Route Groups. In order to make route configurations less cumbersome for deployments requiring numerous remote site deployments; Cisco started using device pools to decide which PSTN (public Phone Telephone Network) gateway phone devices will use when dialing PSTN numbers.
By using this mechanism, it drastically reduces the need to configure duplicate PSTN patterns which point to gateways, for each remote site that a communications manager cluster must support via call routing. So instead of creating seven to ten routes for each remote site (as an example, 299 remote sites plus HQ would equal 3000 patterns) now only one set of patterns need to be created or just 10 and then use the default device pool to select the outgoing gateway using the Local Route Group concept.
Now call routing is still configured as before where a pattern is added to a route list. However, instead of picking a route group containing the gateways, the administration would choose a “standard local route group” in which this route group is considered virtual route group as illustrated above. This standard local route group will be a place holder and is replaced dynamically by a route group configured in the IP Phone’s device pool as depicted below:
Now how does this configuration actually work? When a device makes a call and matches a pattern in that device’s calling search space, and if that route list has a “standard Local route group” in its configuration then:
- The standard route list algorithm will search through in a top down order through all route groups until a gateway is found.
- However if a ‘standard local route group’ place holder exits it:
- Consults the device’s device pool for a Local Route Group entry. If no entry exits is merely moves to the next route group configured.
- If the ‘standard local route group is configured, it will use the gateways listed in the device pool’s Local route group.
- If all route groups including the ‘standard local route group’ gateway entries are exhausted and no available gateway is found, then a re-order is presented to the device.
With this type of provisioning, gateways are now treated more as a simple service in regards to Communications Manager. Plus it frees up the Administrator from replicating the same PSTN Patterns, Calling Search spaces, and Partitions for each physical location and provisions the gateway from Device Pool membership.
There is a restriction in using Standard Local route groups in that you cannot insert SIP route groups and Q.SIG route groups into a route list at the same time. With the Local Route Group feature, this mixed route list rule cannot get enforced during provisioning because the binding between the Standard Local Route Group and a provisioned route group occurs dynamically during the call setup. Therefore, some Q.SIG related features may not be available. The binding from Standard Local Route Group to a Q.SIG route group should be avoided.
Local Route Groups (pdf file)
Author: Joe Parlas