While a Cisco Meeting Server Call Bridge cluster provides a scalable, redundant conferencing service, by default, CMS does not always make the most efficient use of the conferencing resources available to it and, at the same time, may simply allow a particular server to become over-subscribed.
For example, for a meeting with three participants, each participant may end up on three different Call Bridges. In order for those three participants to be able to participate in the same Space, the Call Bridges will automatically set up connections between all the servers to make the user experience seem like they are all on the same server. The unfortunate downside of this is that a single 3-person conference now consumes 6 media ports of capacity. This is obviously an inefficient use of resources, albeit a worst-case scenario. Additionally, when a Call Bridge is truly overloaded, the default mechanism is to continue accepting calls and provide service at a reduced quality to all callers on that Call Bridge
The Call Bridge Group feature is to make sure that all participants within a Call Bridge Group accessing a particular Space will all be connected to the same server, thereby eliminating excessive distribution of calls between Call Bridge nodes. To make this happen, when a call is extended to a CMS to join a Space, the server will communicate with the other Call Bridge servers to determine which server is currently hosting the meeting. If it determines that a Space is being hosted by another server within the Group, then the destination serer will send a SIP INVITE with a Replaces header, essentially telling the Unified CM to transfer the call to it.
At the same time, if a meeting is hosted by a Call Bridge in one Call Bridge Group and someone wants to join from a different region and therefore dials in via a second Call Bridge Group, those calls will always be distributed between the servers in the different regions. The goal is to aggregate the calls for a Space on a single server within a given Call Bridge Group.
This feature imposes requirements on the call control. For a CMS integration to Unified CM, this means Accept replaces header must be enabled in the SIP Trunk Security Profiles and each SIP trunk to CMS must have a Rerouting Calling Search Space configured to allow the call be be transferred between CMS SIP trunks.
Call Bridge clustering allows multiple Call Bridges to operate as a single entity and scale beyond the capacity of any single Call Bridge.
Call routing without Call Bridge Group
1. User-1 Dials ccnp@collab.lab.local
2. CUCM checks SIP Route Pattern
3. CUCM checks Route List RL-CMS
4. CUCM checks Route Group RG-CMS
5. Route Group RG-CMS is configured with 3 SIP Trunks to the 3 CMS CMS-1, CMS-2 and CMS-3 in Circular Distribution Algorithm
6. CUCM Routes call to CMS-1
7. User-2 Dials ccnp@collab.lab.local
8. CUCM Routes call to CMS-2
9. User-3 Dials ccnp@collab.lab.local
10. CUCM Routes call to CMS-3
What’s the ISSUE?
3 ports used on CMS-1, CMS-2 and CMS-3.
Total of 9 ports used for 3 party conference.
Disadvantages of Call Bridge Clustering: Inefficient port utilization
Call routing with Call Bridge Groups and Intelligent Load balancing
Introduced in CMS 2.1
To group Call Bridges in one Group. Enables Load Balancing of Calls on CallBridge within same CallBridge Groups.
Within each Call Bridge group, the aim is to have calls for the same conference placed on the same server whenever possible.
To do that Call Bridge Groups require Cisco Call Manager SIP Trunk Security Profie Requires “ACCEPT with Replaces” to accept “INVITE with Replaces” header.
1. User-1 Dials ccnp@collab.lab.local
2. CUCM checks SIP Route Pattern
3. CUCM checks Route List RL-CMS
4. CUCM checks Route Group RG-CMS
5. Route Group RG-CMS is configured with 3 SIP Trunks to the 3 CMS CMS-1, CMS-2 and CMS-3 in Circular Distribution Algorithm
6. CUCM Routes call to CMS-1
7. User-2 Dials ccnp@collab.lab.local
8. CUCM Routes call to CMS-2
9. CMS-1 sends a SIP INVITE with replaces to CUCM to re-route the call to CMS-1
10. CUCM routes call to CMS-1
11. User-3 Dials ccnp@collab.lab.local
12. CUCM Routes call to CMS-3
13. CMS-1 sends a SIP INVITE with replaces to CUCM to re-route the call to CMS-1
14. CUCM routes call to CMS-1
Benefits: Total of only 3 ports used for 3 party conference rather than 9.
How the Accept Replaces Header works?
The idea behind the Accept Replaces Header option is to make sure that all participants within a Call Bridge Group participating in the same space or meeting, they will all be connected to the same server, to eliminate the distribution of calls between Call Bridge nodes causing Ports consumption. To make this happen, when a call is sent to a CMS-B to join a Space, the node CMS-B 10.1.5.51 will communicate with the other Call Bridge servers to determine which server is currently hosting the meeting. If it determines that a Space is being hosted by another server within the Group, then the server hosting the conference or the meeting (let’s say CMS-A 10.1.5.50) will send a SIP INVITE with a Replaces header, which means: hey Mr CUCM can you transfer the call to CMS-A . This is exactly the purpose of checking the Accept Replaces Header option when you integrate Cisco Unity Connection with Cisco Unified Communication Manager. Cisco Unity Connection can also transfer a call using the transfer rules under the user or call handler configuration page.
3 Comments
