JASON NEUROHR

Cisco Meeting Server Load Balancing with Call Bridge Groups


Sunday, June 24, 2018

In a previous article here, I discussed Cisco Meeting Server Load Balancing with a focus on the Cisco Unified Communications Manager configuration and load balancing from its perspective. This article expands that discussion with the Call Bridge Group feature added in CMS version 2.1. Note this article does not cover all the requirements of implementation, please refer to the official Cisco documentation that I have referenced below. Also, note that Load Balancing Calls Across Cisco Meeting Servers omits configuration required to make the solution work. Specifically, it does not discuss the CMS trunk Rerouting Calling Search Space configuration which is necessary for Call Bridge Groups to work correctly.

Cisco Unified Communications Manager CMS Trunks

Within CUCM, the following configuration is required, noting the two bolded items are specifically needed to facilitate Call Bridge Group operations.

  • Create SIP Trunk Security Profiles - ensuring the Accept Replaces Header is enabled
  • Create SIP Trunks for each call bridge individually. Assuming a secure trunk is used
    • Device Name
    • Device Pool
    • Run On All Active Unified CM Nodes - Checked (if appropriate)
    • SRTP Allowed - Checked
    • Inbound Calls > Calling Search Space - Configured as appropriate
    • Outbound Calls > Calling Party Transformation CSS - Configured as appropriate
    • SIP Information > Destination address - The CMS call bridge listening interface FQDN
    • Rerouting Calling Search Space - Configured with a CSS containing partitions for all calling parties (devices calling the CMS)
    • SIP Profile - Configured with Standard SIP Profile For TelePresence Conferencing
    • Normalization Script - Configure with cisco-telepresence-conductor
  • Configure normal call routing logic, e.g. Route Groups & Lists, SIP and Route Patterns etc.

Cisco Meeting Server API Configuration

It is assumed the underlying CMS configuration is working, and the call bridges are successfully clustered already. Call Bridge Group configuration requires several steps:

  • Planning - plan your call bride group configuration. Planning includes deciding on which call bridges will form the call bridge groups and also the load limits that will be configured for each call bridge
  • Create the Call Bridge Group or Groups and assign call bridges
  • Configure the Load Limits on each call bridge
  • Test!

Create the Call Bridge Groups

To create the Call Bridge Group, issue a POST request on one of the Cisco Meeting Servers to /api/v1/callBridgeGroups with the desired name parameter name=xyz. The returned GUID will be used in the next step to add individual call bridges to the group.

The resulting Call Bridge Group object.

Add Call Bridges to the Call Bridge Group

To add call bridges to the call bridge group issue a GET request on one of the Cisco Meeting Servers to /api/v1/callBridges. Note the GUIDs for the call bridges that will be added to the call bridge group.

For each call bridge that will be added issue a PUT request on of the Cisco Meeting Servers for each of them to /api/v1/callBridges/<Call Bridge GUID> with the parameter callBridgeGroup=<Call Bridge Group GUID>. Repeat this for each call bridge that will be added to the group.

Configure the Call Bridge Load Balancing Settings

Specifically, configure the Load Limit value for each call bridge. Refer to the official Cisco documentation during planning to determine an appropriate load limit value for the type of call bridge in use, for example, at the time of writing a VM based Cisco Meeting Server uses x*1250 where ‘x’ refers to the number of vCPUs. Also, it is possible to fine-tune the load balancing through the newConferenceLoadLimitBasisPoints and existingConferenceLoadLimitBasisPoints parameters noted below, details sourced from the official Cisco documentation.

  • loadLimit - a numeric value for the maximum load on the call bridges
  • newConferenceLoadLimitBasisPoints – a numeric value for the basis points (1 in 10,000) of the load limit at which incoming calls to non-active conferences will be disfavored, ranges from 0 to 10000, defaults to 5000 (50% load). Value is scaled relative to LoadLimit.
  • existingConferenceLoadLimitBasisPoints – a numeric value for the basis points of the load limit at which incoming calls to this Call Bridge will be rejected, ranges from 0 to 10000, defaults to 8000 (80% load). Value is scaled relative to LoadLimit.

For each call bridge issue a PUT request to /api/v1/system/configuration/cluster with the desired loadLimit=xyz parameter (and additional fine-tuning parameters if desired).

Enable Load Balancing for the Call Bridge Group

Once the load limits have been defined for the call bridge groups, issue a PUT request to /api/v1/callBridgeGroups/<Call Bridge Group GUID> with the parameter loadBalancingEnabled=true. Note there are additional parameters for load balancing of outgoing calls etc., I won’t go into their details in this article please refer to the official Cisco documentation.

Conclusion

At this point load balancing of calls within the call bridge groups should now be working.

When the call bridges receive a SIP INVITE, they decide between the nodes in the group if the call should be rerouted to an alternate call bridge. If outcome is to reroute the call, the chosen call bridge will send a SIP INVITE with the Replaces Header, example below.

INVITE sip:5555@10.1.1.66 SIP/2.0
Via: SIP/2.0/TLS 10.1.1.80:5061;branch=z9hG4bK642045860ab99aad89e6d2cc6842d253
Call-ID: 8fdf17ab-cb2a-4df7-801e-c9bc054881d0
CSeq: 150287361 INVITE
Max-Forwards: 70
Contact: <sip:1234@10.1.1.80;transport=tls>;isFocus
To: <sip:5555@10.1.1.66>
From: “Test VMR” <sip:1234@vmr.domain.com.au>;tag=2da4137fa74f7ba5
Replaces: 4f641b80-b2d19fdc-e88b3-420abb0a@10.1.1.66;to-tag=1820668~624ec092-42e6-428e-9a56-1fcac6d844d5-46865099;from-tag=5972d3732e18469e
Allow: INVITE,ACK,CANCEL,OPTIONS,INFO,BYE,UPDATE,REFER,SUBSCRIBE,NOTIFY,MESSAGE
Supported: timer,X-cisco-callinfo
Session-Expires: 1800
Min-SE: 90
User-Agent: Acano CallBridge
Content-Type: application/sdp
Content-Length: 3367

v=0
o=Acano 0 0 IN IP4 10.1.1.80
s=-
c=IN IP4 10.1.1.80

If the Rerouting Calling Search Space is not correctly configured on the CMS SIP Trunks then the following can be observed in the CUCM traces.

32206214.026 |11:18:20.540 |AppInfo |SIPCdpc(223) - getDefCcSetupInd: Replaces is present the Dialog is FromTag 5972d3732e18469e, ToTag 1820668~624ec092-42e6-428e-9a56-1fcac6d844d5-46865099, CallId 4f641b80-b2d19fdc-e88b3-420abb0a@10.1.1.66, EarlyOnly 0
32206214.027 |11:18:20.540 |AppInfo |CMSIPUtility::decodeRPHdr - no RP Header received, so namespace & priority string unknown, defaulting to precDmn of 0 and normalized priority of 5
32206214.032 |11:18:20.540 |AppInfo |SIPCdpc(223) - processSIPSetupInd: Replaces is present use the ReRouteCallingSearchSpace to route the call
32206222.001 |11:18:20.540 |AppInfo |Digit Analysis: star_DaReq: daReq.partitionSearchSpace(), filteredPartitionSearchSpaceString(), partitionSearchSpaceString()
32206222.002 |11:18:20.540 |AppInfo |Digit Analysis: Host Address=10.1.1.66 MATCHES this node’s IPv4 address.
32206222.003 |11:18:20.540 |AppInfo |Digit Analysis: star_DaReq: Matching SIP URL, Numeric User, user=74023
32206222.004 |11:18:20.540 |AppInfo |Digit Analysis: Host Address=10.1.1.66 DOES NOT MATCH top level org domain.
32206222.005 |11:18:20.540 |AppInfo |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0]
32206222.006 |11:18:20.540 |AppInfo |Digit Analysis: getDaRes - Remote Destination [] isURI[1]
32206222.007 |11:18:20.540 |AppInfo |Digit analysis: patternUsage=2
32206222.008 |11:18:20.540 |AppInfo |Digit analysis: match(pi=“2”,fqcn="", cn=“1234”, plv=“5”, pss="", TodFilteredPss="", dd=“74023”,dac=“0”)
32206222.009 |11:18:20.540 |AppInfo |Digit analysis: potentialMatches=NoPotentialMatchesExist
32206232.001 |11:18:20.541 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.1.1.80 on port 53578 index 108772
SIP/2.0 404 Not Found
Via: SIP/2.0/TLS 10.1.1.80:5061;branch=z9hG4bK642045860ab99aad89e6d2cc6842d253
From: “Test VMR” <sip:1234@vmr.domain.com.au>;tag=2da4137fa74f7ba5
To: <sip:5555@10.1.1.66>;tag=1820669~624ec092-42e6-428e-9a56-1fcac6d844d5-46865100
Date: Sat, 23 Jun 2018 01:18:20 GMT
Call-ID: 8fdf17ab-cb2a-4df7-801e-c9bc054881d0
CSeq: 150287361 INVITE
Allow-Events: presence
Reason: Q.850;cause=1
Server: Cisco-CUCM10.5
Content-Length: 0

From the Cisco Meeting Server logs you can observe the following on the CMS that has been selected to take the call from the original CMS (note these logs do not correlate with the above):

Jun 25 13:54:32 user.info xms01 host:server: INFO : replacing call ‘75c4bb00-b3016777-f07fd-420abb0a@10.1.1.66’ from server ‘UMS02’ into conference 7d1e3878-b221-4ba0-8d50-d54847d14394
Jun 25 13:54:32 user.info xms01 host:server: INFO : call 52: outgoing SIP call to “5555@vc.domain.com.au” from space “Test VMR”
Jun 25 13:54:32 user.info xms01 host:server: INFO : call 52: setting up UDT RTP session for DTLS (combined media and control)
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: connection 78: outgoing SIP TLS data to 10.1.1.66:5061 from 10.1.1.80:46082, size 4112:
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: INVITE sip:5555@vc.domain.com.au SIP/2.0
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: Via: SIP/2.0/TLS 10.1.1.80:5061;branch=z9hG4bKd00fb20d3f71fb1e445b263d9a440c79
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: Call-ID: 83fe7210-4643-4a4a-9fd6-497f42b1d59f
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: CSeq: 515610386 INVITE
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: Max-Forwards: 70
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: Contact: <sip:1234@10.1.1.80;transport=tls>;isFocus
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: To: <sip:5555@vc.domain.com.au>
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: From: “Test VMR” <sip:1234@vmr.domain.com.au>;tag=c45f0169f89f0d53
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: Replaces: 75c4bb00-b3016777-f07fd-420abb0a@10.1.1.66;to-tag=1879174~624ec092-42e6-428e-9a56-1fcac6d844d5-46865252;from-tag=0e03de56a208a921
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: Allow: INVITE,ACK,CANCEL,OPTIONS,INFO,BYE,UPDATE,REFER,SUBSCRIBE,NOTIFY,MESSAGE
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: Supported: timer,X-cisco-callinfo
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: Session-Expires: 1800
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: Min-SE: 90
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: User-Agent: Acano CallBridge
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: Content-Type: application/sdp
Jun 25 13:54:32 user.info xms01 host:server: INFO : SIP trace: Content-Length: 3368

References

Cisco Meeting Server 2.3, Load Balancing Calls Across Cisco Meeting Servers

Cisco Meeting Server 2.3 with Cisco Unified Communications Manager Deployment Guide