Aurus Blog

This blog is to share our expertise in Cisco UCM, UCCX/UCCE and Cisco Meeting Server

  • Archive

    «   September 2020   »
    M T W T F S S
      1 2 3 4 5 6
    7 8 9 10 11 12 13
    14 15 16 17 18 19 20
    21 22 23 24 25 26 27
    28 29 30        

Cisco Meeting Server Cluster: Scalability and Resilience deployment with meeting recording - PART 3

In the previous part of this article we’ve described the configuration of database, Call Bridge and XMPP clusters, as well as Web Admin service. We have also connected Call Bridge to XMPP and performed the Web Bridge configuration.

In this part of the article, we’ll finish discussing the details of CMS clustered deployment and configuration.

Call Bridge Groups

By default, CMS may use the available conferencing resources inefficiently.

For example, in a meeting with three participants, all participants may end up being on three different Call Bridges. For these participants to be able to communicate, Call Bridges will automatically create connections between all servers and clients using a single Space, so it will look as though all clients are using the same server. Unfortunately, such conference of 3 participants will take 9 media ports. This is inefficient resource usage. Besides that, when Call Bridge is really overloaded, the default procedure is to go on accepting calls and provide lower-quality service to all Call Bridge subscribers.

These problems can be solved with Call Bridge Group feature. This feature was introduced in Cisco Meeting Server 2.1 and extended to support load balancing for incoming and outgoing calls, Cisco Meeting App (CMA), including WebRTC participants.

There are three load limits to be configured for each Call Bridge:

  • LoadLimit — maximum load value for a Call Bridge. Each platform has a recommended load limit, e.g. 96000 for CMS1000 and 1.25 GHz per virtual CPU for a virtual machine. Different calls require different amount of resources depending on the participant’s resolution and frame rate.
  • NewConferenceLoadLimitBasisPoints (by default, 50% of loadLimit) — maximum server load above which new conferences will be rejected.
  • ExistingConferenceLoadLimitBasisPoints (by default, 80% of loadLimit) — server load value above which new participants trying to join an existing conference will be rejected.

This feature was created for load balancing and call distribution. Other groups, such as TURN servers, Web Bridge servers and recording devices, can also be assigned to Call Bridge Groups, so they can also be grouped correctly for optimal usage. If any of these objects is not assigned to a call group, it is considered available to all servers without any priority.

These parameters can be configured here: cms.example.com:445/api/v1/system/configuration/cluster

For each Call Bridge, set the Call Bridge Group it belongs to.

The first Call Bridge:

The second Call Bridge:

The third Call Bridge:

So, you have configured a Call Bridge Group for better usage of Cisco Meeting Server cluster resources.

Importing Active Directory Users

Web Admin Service has LDAP configuration section, but it doesn’t provide complex configuration parameters, and the information won’t be saved in the clustered database, so you’ll either have to perform the configuration manually on each server via Web interface, or do it through API. Let’s do it through API to save the time.

Use the URL: cms01.example.com:445/api/v1/ldapServers

Create a LDAP Server object with the following parameters:

  • server IP address
  • port number
  • username
  • password
  • secure

Set Secure to true or false depending on the port number: 389 — not secure, 636 — secure.

Map LDAP source parameters to attributes in Cisco Meeting Server:

  • jidMapping
  • nameMapping
  • coSpaceNameMapping
  • coSpaceUriMapping
  • coSpaceSecondaryUriMapping

Attribute description

JID is an identifier for CMS login. It will be mapped onto sAMAccountName in LDAP, which is user’s login identifier in Microsoft Active Directory. Note that you should take sAMAccountName and append the domain name conf.pod6.cms.lab. This is the login name for your CMS users.

nameMapping maps the contents of Active Directory displayName field onto CMS user’s name.

coSpaceNameMapping creates CMS Space name based on the displayName field. This attribute along with coSpaceUriMapping is required for each user’s Space creation.

coSpaceUriMapping defines the user’s part of URI, associated with user’s personal Space. Some domains can be configured for dialing into a space. If the user’s part matches this field for one of those domains, the call will be routed into this user’s Space.

coSpaceSecondaryUriMapping defines a second URI to reach the Space. You will use this to add a numeric alias to route calls into the imported user's Space as an alternative to the alphanumeric URI defined in the coSpaceUriMapping parameter.

LDAP server and mapping are configured. Now you should create a LDAP source to bind them together.

Use the URL: cms01.example.com:445/api/v1/ldapSource
Create a LDAP Source object with the following attributes:

  • server
  • mapping
  • baseDn
  • filter

Now the LDAP configuration is over, so you can perform manual synchronization. You can either do it in each server’s Web interface (Active Directory section > Sync now button) or through API using a POST command (URL: cms01.example.com:445/api/v1/ldapSyncs).

Ad Hoc Conferences

What’s that?

In traditional Unified CM telephony, ad-hoc conferencing is a call by which two participants are talking directly to one another when one party (using a device registered to the Unified CM) presses the Conference button, calls a different person, and after talking to that 3rd party, presses the Conference button again to join everyone into a 3-party conference.

What makes this feature different than a scheduled or permanent conference is that an adhoc conference is not simply a SIP call to the CMS. When the conference initiator presses the Conference button the second time to bring everyone into the same meeting, Unified CM must make an API call to CMS to create a conference on the fly, to which all the calls are then transferred. All this happens transparently to the participants.

This means that Unified CM needs to have the API credentials and Web Admin address/port configured, as well as a SIP trunk directly to the CMS server in order to extend the call.

When required, CUCM can then dynamically create a Space on CMS, so that each call can be extended directly to CMS and match an Incoming call rule that targets Spaces.

Integration with CUCM is similar to the described in an earlier article, but this time you must create three CMS trunks and three Conference Bridges, enter three Subject Names in SIP Security Profile, configure Route Group, Route List, Media Resource Group and Media Resource Group List correspondingly, and add some routing rules on Cisco Meeting Server.

SIP Security Profile:

Trunks:

Each trunk looks similarly:

Conference Bridge

Each Conference Bridge looks similarly:

Route Group

Route List

Media Resource Group

Media Resource Group List

Call Routing Rules

Unlike more advanced call management systems (Unified CM or Expressway), CMS only looks at the domain in the SIP Request-URI field. So if the SIP INVITE is destined to sip:user@domain.com, CMS only cares about the domain.com. CMS follows these rules for determining where to route a call:

  • 1. CMS tries to match the SIP domain to those configured on the Incoming call matching rules. Those calls can then be routed to any configured Spaces, logged-in users, internal IVRs, or to look up a conference on a Microsoft Lync / Skype for Business (S4B) integration.
  • 2. If there is no match on the Incoming call matching rules, CMS will try to match a domain configured in the Call forwarding table. If a match is made, the rule can explicitly reject a call or forward a call. At that time, CMS can re-write the domain, which is sometimes useful for calls to Lync domains. You can also choose to pass through the call, meaning that none of the fields will be further modified, or to use the internal CMS dial plan. If there is no match in the Call forwarding rules, the default behavior is to reject the call. Keep in mind that forwarding will still anchor the call at CMS, so you're essentially placing CMS in the middle of the call flow.
  • 3. Only forwarded calls are then subject to the Outbound call rules. These settings define the destinations where to send the calls, the trunk type (whether or not the new call will be Lync or standard SIP), and any transformations that may be performed, if pass-through is not selected in the call forwarding rule.

Here is a log of what’s happening during an Ad Hoc conference:

The Ad Hoc conference itself:

Incoming Call Rules

Configuring Incoming Call Settings is required to be able to receive a call on CMS. As you saw in the LDAP setup, all the users were imported with the domain conf.pod6.cms.lab. So at minimum, you want calls to that domain to target the Spaces. You will also need to set up rules for anything destined to the fully qualified domain name (and potentially even the IP address) of each of the CMS servers. Our external call control, Unified CM, will be configured with SIP trunks targeting each of the CMS servers individually. Depending on whether or not the destination of those SIP trunks is an IP address or the FQDN of the server will determine whether or not the CMS needs to be configured to accept calls destined to its IP address or FQDN.

The domain that has the highest priority Inbound rule is used as the domain for any user's Spaces. When users are synchronized via LDAP, CMS automatically creates Spaces, but only the user part of the URI (the coSpaceUriMapping), say user.space. The @domain part of the full URI is constructed based on this rule. In fact, if you were to log into Web Bridge at this point, you would see the Space URI has no domain. By setting this rule as the highest priority, you are setting the domain for the generated Spaces to conf.example.com.

Outbound Call Rules

To allow for users to make outbound calls to the Unified CM cluster you must configure an Outbound rule. The domain of your Unified CM-registered endpoints, such as Jabber, is example.com. Calls to this domain should be routed as standards-based SIP calls to the Unified CM's call processing nodes. These are cucm-01.example.com as the primary, and cucm-02.example.com as the secondary.

The first rule sets simple call routing between the cluster nodes.

The Local from domain field contains the domain part of a caller’s SIP-URI (the part after the “@” symbol) to be displayed at receiving side. If you leave it empty, then it will be substituted with an IP address of CUCM the call has passed through. This field is required to make callback possible, as it will be impossible to call the SIP-URI name@ip-address.

Calling with a Local from domain set:

Calling without a Local from domain:

Make sure to set the incoming calls to be Encrypted or Unencrypted, because it won’t work with Auto value.

Recording

The CMS Recorder provides the capability to record meetings. It appears to be just another Cisco Meeting Server. Recorder license is needed and must be applied on the CallBridge component, and not on the Recorder server.
The Recorder behaves like an Extensible Messaging and Presence Protocol (XMPP) client, so the XMPP server must be enabled on the server that hosts the Call Bridge.

We have a cluster, so a license must be distributed to all three clustered servers. In your personal area, proceed to licenses and associate (add) MAC addresses for A-interfaces of all CMS nodes.

It should look like this on each server in a cluster.

There are several scenarios of Recorder deployment. We’ll stick to the following:

Before you set Recorder up, make sure you have enough space for the recordings. Here’s a link to a thorough guide to Recording configuration. I’ll make a few important notes for you:

  • It’s best to use the first cluster node’s certificate.
  • The “Recorder unavailable” error may occur if you have specified a wrong certificate in the recorder trust.
  • The recording may fail if the directory you have set for recordings is not a root directory.

Sometimes there’s a need to record a single user’s or Space’s conferences automatically. This requires two Call Profiles:

With disabled recording feature:

And with automatic recording:

Assign the Call Profile with automatic recording to the chosen Space:

If a call profile is explicitly assigned to some Space or Spaces, then this call profile will only be applied to these specific Spaces. However, if it is not assigned to any spaces, it will be applied to the spaces that do not have any call profiles assigned.

Sources:

Read also:

This article is a translation of a guide originally created by S. Dubinin, Telecommunications Specialist - https://habr.com/ru/post/434240/