Cisco Meeting Server - Load Balancing

Thursday, August 31, 2017

The Cisco Meeting Server load balancing document referenced can be found here.

The section titled Example 3: Deployment without a SME to route calls, describes the configuration required to route calls to a dispersed set of CMS’s trunked locally to their respective CUCM clusters. Through the use of Route Groups, Route Lists, Route Patterns, and Transformations, the CMS deployment can be made more resilient, allowing calls to flow to alternate CMS servers in the cluster through a remote CUCM cluster with local CMS resources when the local CMS is unavailable or busy. It is this area of configuration detailed below (at a high level).

In this article, the referenced architecture is two separate CUCM clusters, each with a trunk to a local CMS. The CMS’s themselves are in a cluster and as a result replicating the coSpace/Space configuration. Spaces are in the range of 441XXX. As a result of this configuration, if a CMS trunk becomes unavailable in one cluster, a user dialling 441XXX will have their called number manipulated to include an additional 4 resulting in 4441XXX. This will be routed to the remote CUCM cluster where the leading 4 will be stripped and 441XXX routed to the local CMS trunk.

Create a SIP Trunk Security Profile for use with the CMS trunks that has Accept replaces header checked
Create SIP trunks to the CMS servers using the SIP Trunk Security Profile
Create SIP trunks to the remote CUCM clusters (assumed to be in place from this point onward)
Configured CMS such that it is clustered and will receive calls to spaces in the range 441XXX
Create two Route Groups - Each CUCM cluster will require a mirrored configuration
- Route Group 1 - in the context of this post is called RG-CMS-LOCAL and it contains the trunks to the local CMS servers using the Distribution method Circular
- Route Group 2 - called RG-CMS-REMOTE and it contains the trunks to the remote CUCM clusters
Create two Route Lists - Each CUCM cluster will require a mirrored configuration
- Route List 1 - in the context of this post is called RL-CMS-LOCAL and it contains the RG-CMS-LOCAL
- Route List 2 - called RL-CMS-LOCAL-WITH-FAILOVER and it contains RG-CMS-LOCAL (first in the list), and RG-CMS-REMOTE. RG-CMS-REMOTE has a Called Party Transformation Mask of 4XXXXXX
Create two Route Patterns - Each CUCM cluster will require a mirrored configuration
- Route Pattern 1 - routes pattern 441XXX, using route list RL-CMS-LOCAL-WITH-FAILOVER (towards the local CMS trunk/s, unless for instance the trunk/s are down, upon which it will route to the remote CUCM)
- Route Pattern 2 - routes pattern 4.441XXX, using route list RL-CMS-LOCAL (towards the local CMS trunk/s). It is configured with a Called Party Transformation - Discard Digits - PreDot