Cisco Meeting Server 2.5.2. Cluster in Scalable and Resilient mode with video conferencing recording feature

In this issue, I will show and explain some nuances of configuring a CMS server in a fault-tolerant cluster mode.


TheoryThere are generally three types of CMS server deployments:

• Single Combined(Single Combined), i.e., it is one server where all necessary services are running. In most cases, this deployment type is applicable only for internal clients and in small environments where the scalability and redundancy limitations of a single server are not a critical issue, or in situations where the CMS performs only specific functions such as dedicated conferences on Cisco UCM.

  An approximate diagram of the operation:
  

• Single Split(Single Split) expands on the previous deployment type by adding a separate server for external access. In outdated deployments, this meant deploying the CMS server in a demilitarized network segment (DMZ), where external clients could access it, and one CMS server in the core network, where internal clients access the CMS. This particular deployment model is now being replaced by the so-called type Single Edge, which consists of servers Cisco Expressway, which either have or will have many of the capabilities to bypass the Firewall, so clients do not need to add a dedicated boundary CMS server.

  An approximate diagram of the operation:
  

• Scalable and Resilient(Scalable and Resilient) this type includes redundancy for each component, allowing the system to grow with your needs to maximum capacity while ensuring redundancy in case of failure. It also uses the Single Edge concept to provide secure external access. This is the type we will discuss in this issue. By understanding how to deploy a cluster of this type, we will not only grasp other deployment types but also understand how to create CMS server clusters with potential growth needs in mind.

Before moving on to the deployment, it is important to understand some basics, namely

The main software components of the CMS:

• Database: allows for the merging of certain configurations such as subscriber group, user spaces, and the users themselves. Supports clustering only for high availability (one master).
• Call Bridge: a service for audio and video conferences that provides full control over call management and multimedia processing. Supports clustering for high availability and scalability.
• XMPP server: is responsible for the registration and authentication of clients using the Cisco Meeting Application and/or WebRTC (real-time communication, or simply in the browser), as well as inter-component signaling. Can only be clustered for high availability.
• Web Bridge: provides access for clients in WebRTC.
• Loadbalancer: serves as a single point of connection for Cisco Meeting App applications in Single Split mode. Listens on an external interface and port for incoming connections. Similarly, the load balancer accepts incoming TLS connections from the XMPP server, through which it can switch TCP connections from external clients.
  It will not be needed in our scenario.
• TURN server: provides firewall bypass technology that allows
  to expose our CMS outside the firewall or NAT for connecting external clients using Cisco Meeting App or SIP devices. It will not be needed in our scenario.
• Web Admin: the administrative interface and access to the API, including for special conferences Unified CM.

Configuration modes

Unlike most other Cisco products, Cisco Meeting Server supports three configuration methods that allow deployment of any type of installation.

• Command Line (CLI): Command Line Interface, known as MMP, for initial configuration tasks and certificates.
• Web Administrator: primarily for configuration related to CallBridge, especially when configuring a single non-clustered server.
• REST API: used for the most complex configuration tasks and tasks related to clustered databases.

In addition to the above, the protocol SFTP is used for file transfer — typically licenses, certificates, or logs — to and from the CMS server.

In Cisco's deployment guides, it is clearly stated that a cluster must be deployed with at least three servers (nodes) in the context of databases. This is because only an odd number of nodes will enable the mechanism for selecting a new database Master, and generally, the Master database has a connection with the majority of the CMS server database.

As practice shows, two servers (nodes) are indeed not quite sufficient. The failover mechanism operates when the Master is restarted; the Slave server becomes the Master only after the rebooted server comes back online. However, if the Master server in a cluster of two suddenly goes down, the Slave server will not become the Master, and if the Slave goes down, then the remaining Master will also become a Slave.

In the context of XMPP, it's essential to create a cluster of three servers. For instance, if the XMPP service is disabled on one server where XMPP is in Leader status, the remaining server will remain in Follower status, and connections from CallBridge to XMPP will fail since CallBridge connects solely to XMPP in Leader status. This is critical because no calls will go through.

These deployment guides also demonstrate a cluster with one XMPP server.

Considering the above, it becomes clear why: it works because it operates in failover mode.

In our case, the XMPP server will be present on all three nodes.

It is assumed that all three of our servers are up.

DNS Records

Before proceeding to configure the servers, you need to set up DNS records. A and SRV types:

Note that our DNS records include two domains: example.com and .conf.example.com. Example.com is the domain that all users of the Cisco Unified Communication Manager can use for their URIs, which is likely present in your infrastructure or is very likely to be. Alternatively, the domain example.com corresponds to the same domain that users use for their email addresses. Or the Jabber client on your laptop may have the URI user@example.com. The domain .conf.example.com is the domain that will be configured for users of the Cisco Meeting Server. The domain of the Cisco Meeting Server will be .conf.example.com, so for the same Jabber user to log into the Cisco Meeting Server, the URI user@.conf.example.com will need to be used.

Basic Configuration

All settings described below are shown on one server, but they need to be performed on each server in the cluster.

QoS.

Since CMS generates real-time For traffic sensitive to latency and packet loss, it is generally recommended to configure Quality of Service (QoS). To do this, the CMS supports packet tagging with Differentiated Services Code Point (DSCP) values that it generates. Although traffic prioritization based on DSCP depends on how traffic is processed by the network components of your infrastructure, in our case, we will configure our CMS with a typical DSCP priority distribution based on QoS best practices.

On each server, we will enter the following commands

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

Thus, all video traffic is marked AF41 (DSCP 0x22), all voice traffic is marked EF (DSCP 0x2E), while other types of low-latency traffic, such as SIP and XMPP, use AF31 (DSCP 0x1A).

Checking:

NTP

The Network Time Protocol (NTP) is important not only for providing accurate timestamps for calls and conferences but also for certificate verification.

We add the NTP servers to your infrastructure with commands like

ntp server add

In our case, there are two such servers, so there will be two commands.
Checking:

And we set the time zone for our server.

DNS

We add DNS servers in the CMS with commands like:

dns add forwardzone

In our case, there are two such servers, so there will be two commands.
Checking:

Network Interface Configuration

We configure the interface with commands like:

ipv4  add 
/

Checking:

Hostname

We set the server name with commands like:

hostname

And then we restart.


This completes the basic configuration.

Certificates

TheoryCisco Meeting Server requires encrypted communication between various components, and as a result, X.509 certificates are required for all CMS deployments. They help establish trust among the services/servers with other servers/services.

Each service requires a certificate; however, creating separate certificates for each service can lead to confusion and unnecessary complexity. Fortunately, we can generate a pair of public and private key certificates and then reuse them for multiple services. In our case, the same certificate will be used for the Call Bridge, XMPP server, Web Bridge, and Web Admin. Thus, it is necessary to create a pair of public and private key certificates for each server in the cluster.

Database clustering, however, has specific certificate requirements and thus requires its own certificates, distinct from those of other services. The CMS uses a server certificate that is similar to certificates used by other servers, but there is also a client certificate utilized for connections to the database. Database certificates are used for both authentication and encryption. Instead of providing a username and password for the client to connect to the database, it presents a client certificate that the server trusts. Each server in the database cluster will use the same pair of public and private keys. This allows all servers in the cluster to encrypt data in such a way that it can only be decrypted by other servers that also use the same key pair.

For failover to work, database clusters must consist of at least 3 servers but no more than 5, with a maximum round-trip latency of 200 ms between any members of the cluster. This limit is more restrictive than for Call Bridge clustering, so it often becomes a limiting factor in geographically distributed deployments.

The database role for the CMS has a number of unique requirements. Unlike other roles, it requires a client and server certificate, where the client certificate has a specific CN field presented to the server.

The CMS uses a postgres database with one master and several fully identical replicas. At any given time, there is only one main database (the "database server"). The other members of the cluster are replicas or "database clients."

For the database cluster, a dedicated server certificate and a client certificate are required. They must be signed by certificates, usually from an internal private certificate authority. Since any member of the database cluster can become the master, pairs of database server and client certificates (containing public and private keys) must be copied to all servers so that they can assume the identity of the database client or server. Additionally, the root CA certificate must be uploaded to ensure that the client and server certificates can be verified.

So, we create a certificate request that will be used by all server services except for database (there will be a separate request for this) with a command like:

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

In CN, we write a generic name for our servers. For example, if the hostnames of our servers are server01, server02, server03, then CN will be server.example.com

We do the same on the other two servers with the difference that the commands will have the corresponding 'hostnames'.

We create two requests for the certificates that will be used by the database service with commands like:

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

where dbclusterserver and dbclusterclient the names of our requests and future certificates, hostname1(2)(3) the names of the corresponding servers.

This procedure is performed only on one server(!), and we will upload the certificates and corresponding .key files to the other servers.

Enabling client certificate mode in AD CS

We also need to merge the certificates for each server into one file.In *NIX:

cat server01.cer server02.cer server03.cer > server.cer

In Windows/DOS:

copy server01.cer + server02.cer + server03.cer server.cer

And upload to each server:
1. The ‘individual’ server certificate.
2. The root certificate (along with any intermediates if they exist).
3. Certificates for the database (‘server’ and ‘client’) and files with the .key extension, which were generated when creating the request for the ‘server’ and ‘client’ database certificates. These files must be the same across all servers.
4. A file of all three ‘individual’ certificates.

As a result, there should be a similar file structure on each server.

Database Cluster

Now that you have uploaded all the certificates to the CMS servers, you can set up and enable database clustering between the three nodes. The first step is to choose one server as the main node of the database cluster and fully configure it.

Master Database

The first step in setting up database replication is to specify the certificates that will be used for the database. This is done using a command like:

database cluster certs

Now we specify to the CMS what interface to use for database clustering with the command:

database cluster localnode a

Next, we initialize the cluster database on the main server with the command:

database cluster initialize

Client Database Nodes

We perform the same procedure, but instead of the command database cluster initialize we enter a command like:

database cluster join

where ip address existing master is the IP address of the CMS server where the cluster was initialized, simply the Master.

We check how our database cluster is working on all servers with the command:

database cluster status

We do the same on the remaining third server.

As a result, the first server is our Master, and the others are Slaves.

Web Admin Service

We enable the web admin service:

webadmin listen a 445

Port 445 is chosen because port 443 is used for user access to the web client

We configure the Web Admin service with the certificate files using a command like:

webadmin certs

And we enable Web Admin with the command:

webadmin enable

If everything is good, we will see SUCCESS lines indicating that Web Admin is correctly configured for the network and certificate. We check the service functionality using a web browser and enter the web administrator address, for example: cms.example.com:445

Call Bridge Cluster

Call Bridge is the only service present in every CMS deployment. Call Bridge is the main mechanism for conference communication. It also provides a SIP interface, so calls can be routed to or from it, for example, with Cisco Unified CM.

The commands described below need to be executed on each server with the corresponding certificates.
So:

We bind the certificates to the Call Bridge service using a command like:

callbridge certs  []

We bind the CallBridge services to the required interface with the command:

callbridge listen a

And we restart the service with the command:

callbridge restart

Now that we have configured Call Bridges, we can set up Call Bridge clustering. Call Bridge clustering differs from database or XMPP clustering. A Call Bridge Cluster can support between 2 to 8 nodes without any restrictions. It not only provides redundancy but also load distribution, allowing conferences to be actively distributed across Call Bridge servers using intelligent call distribution. The CMS has additional features, Call Bridge groups, and related functions that can be utilized for further management.

Call Bridge clustering is primarily configured through the web administrator interface.
The procedure described below must be performed on each server in the cluster.
So,

1. Access the web UI at Configuration > Cluster.
2. In the Call Bridge identity field, enter callbridge[01,02,03] corresponding to the name of the server. These names are arbitrary but must be unique within this cluster. They are descriptive, indicating that these are the identifiers of servers [01,02,03].
3. In the Clustered Call Bridges section, enter the web administrator URLs of our servers in the cluster, cms[01,02,03].example.com:445 in the Address field. Be sure to specify the port. You can leave the Peer link SIP domain empty.
4. Add the certificate of each server to the trust of Call Bridge, a file that contains all the certificates of our servers that we merged into this file at the very beginning, with a command like:

callbridge trust cluster

And we restart the service with the command:

callbridge restart

As a result, each server should look like this:

XMPP Cluster

The XMPP service in CMS is used for handling all registration and authentication for Cisco Meeting Apps (CMA), including the CMA WebRTC web client. The Call Bridge also acts as an XMPP client for authentication purposes and therefore must be configured like other clients. XMPP redundancy is a feature supported in production environments starting from version 2.1.

The commands described below need to be executed on each server with the corresponding certificates.
So:

We link the certificates to the XMPP service with a command like:

xmpp certs  []

Then define the listening interface with the command:

xmpp listen a

An XMPP service requires a unique domain. This is the login for users. In other words, when a user attempts to log in through the CMA application (or via a WebRTC client), they enter userID@logindomain. In our case, this will be userid@.conf.example.com. Why is it not just example.com? In our specific deployment, we chose our Unified CM domain, which Jabber users will use in Unified CM, as example.com, so we need a different domain for CMS users to route calls to and from CMS through SIP domains.

Configure the XMPP domain using a command like:

xmpp domain

And enable the XMPP service with the command:

xmpp enable

In the XMPP service, credentials must be created for each Call Bridge, which will be used for registration in the XMPP service. These names are arbitrary (and not linked to the unique names you set up for clustering Call Bridges). On one XMPP server, you need to add three call bridges, and then enter these credentials on the other XMPP servers in the cluster, as this configuration does not go into the cluster database. Later, we will configure each Call Bridge to use this name and secret for registration with the XMPP service.

Now we need to configure the XMPP service on the first server with three Call Bridges: callbridge01, callbridge02, and callbridge03. Each account will be assigned random passwords. These will be entered later on the other Call Bridge servers to log into this XMPP server. We enter the following commands:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

As a result, we check what we got with the command:

xmpp callbridge list

The same picture should appear on the other servers after performing the actions described below.

Next, we add exactly the same settings on the remaining two servers, just with the commands

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

Be very careful when adding the secret to avoid accidentally including extra spaces.


As a result, each server should have the same picture:

Next, on all servers in the cluster, we specify a trust file containing all three certificates, created earlier with a command like:

xmpp cluster trust

We enable XMPP cluster mode on all cluster servers with the command:

xmpp cluster enable

On the first server of the cluster, initiate the creation of the XMPP cluster with the command:

xmpp cluster initialize

On the other servers, add them to the XMPP cluster with the command:

xmpp cluster join

Check the success of the XMPP cluster creation on each server using the commands:

xmpp status
xmpp cluster status

First server:

Second server:

Third server:

Connecting Call Bridge to XMPP

Now that the XMPP cluster is running, you need to configure the Call Bridge services to connect to the XMPP cluster. This configuration is done through the web administrator.

On each server, go to Configuration > General and in the field Unique Call Bridge name enter the unique Call Bridge names corresponding to each server callbridge[01,02,03]. In the field Domain conf.example.ru and the corresponding passwords, which can be found out
on any server in the cluster with the command:

xmpp callbridge list

Leave the 'Server' field blank, Callbridge will perform a DNS SRV search for _xmpp-component._tcp.conf.example.com, to find an available XMPP server. The IP addresses for connecting call bridges to XMPP may vary on each server, depending on the values returned for the query on the record _xmpp-component._tcp.conf.example.com callbridge, which in turn depends on the priority settings for this DNS record.

Next, go to Status > General to ensure that the Call Bridge service is successfully connected to the XMPP service.

Web Bridge

On each server of the cluster, enable the Web Bridge service with the command:

webbridge listen a:443

Configure the Web Bridge service with certificate files using the command:

webbridge certs

Web Bridge supports HTTPS. It will redirect HTTP to HTTPS if configured to use 'http-redirect'.
To enable HTTP redirection, use the following command:

webbridge http-redirect enable

To indicate to the Web Bridge that it can trust connections from the Call Bridge, use the command:

webbridge trust

where this is the file containing all three certificates from each server in the cluster.

This setup should be the same on each server of the cluster.


Now we need to create a user with the 'appadmin' role; we need this so that we can configure our cluster(!), and not each server in the cluster individually, thus the settings will apply uniformly across each server while only being implemented once.


For further configuration, we will use Postman.

For authorization, select Basic in the Authorization section.

To properly send commands to the CMS servers, the correct encoding must be set.

We specify the Webbridges with the command. POST with the parameter url and value cms.example.com



In the Webbridge itself, we specify necessary parameters: guest access, secure access, and more.

Call Bridge Groups

By default, the CMS does not always utilize its available conference resources as efficiently as possible.

For example, in a meeting with three participants, each participant may end up on three different Call Bridges. In order for these three participants to communicate with each other, the Call Bridges will automatically establish connections among all servers and clients in the same Space, making it appear as though all clients are on the same server. Unfortunately, the downside is that a conference of 3 people will now consume 9 media ports. This is obviously an inefficient use of resources. Additionally, when a Call Bridge is indeed overloaded, the default mechanism is to continue accepting calls and provide services with reduced quality to all subscribers of that Call Bridge.

These issues are resolved using the Call Bridge Group feature. This feature was introduced in version 2.1 of the Cisco Meeting Server software and was expanded to support load balancing for both incoming and outgoing calls, including participants using the Cisco Meeting App (CMA) and WebRTC.

To address the reconnection issue, three configurable load limits were introduced for each Call Bridge:

LoadLimit is the maximum numerical load for a specific Call Bridge. Each platform has a recommended limit, such as 96000 for CMS1000 and 1.25 GHz per virtual processor for the virtual machine. Different calls consume a specific amount of resources depending on the resolution and frame rate of the participant.
NewConferenceLoadLimitBasisPoints (default 50% of loadLimit) sets the server load limit after which new conferences are rejected.
ExistingConferenceLoadLimitBasisPoints (default 80% of loadLimit) is the server load value after which participants joining an existing conference will be rejected.

While this feature was developed for distributing calls and load balancing, other groups, such as TURN servers, Web Bridge servers, and recording devices, can also be assigned to Call Bridge Groups, allowing them to be properly grouped for optimal use. If any of these objects are not assigned to a call group, they are assumed to be accessible to all servers without a specific priority.

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

Next, we specify which callbridge belongs to which callbridge group:

First callbridge

Second callbridge

Third callbridge


Thus, we have configured the Call Bridge group for more efficient resource utilization of the Cisco Meeting Server cluster.

Import users from Active Directory

The Web Admin service has an LDAP configuration section, but it does not provide complex configuration options, and the information is not saved in the cluster database. Therefore, the configuration must be performed either manually on each server through the Web interface or via the API, and to avoid repeating this process, we will still use the API to input the data.

Using the URL to access cms01.example.com:445/api/v1/ldapServers creates an LDAP Server object, specifying parameters such as:

• Server IP address
• the port number
• username
• Password
• Secure

Secure – choose true or false depending on the port, 389 is unsecured, 636 is secured.


Mapping LDAP source parameters to attributes in the Cisco Meeting Server.
LDAP mapping correlates attributes in the LDAP directory with attributes in CMS. The actual attributes are:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Description of attributesJID represents the user's login identifier in CMS. Since this is a Microsoft Active Directory LDAP server, the CMS JID maps to sAMAccountName in LDAP, which essentially is the user's Active Directory login identifier. Also, note that you take the sAMAccountName and append the domain conf.pod6.cms.lab to its end, as this is the login users will use to enter CMS.

nameMapping maps what is contained in the Active Directory displayName field to the CMS user's name field.

coSpaceNameMapping creates the CMS space name based on the displayName field. This attribute, along with the coSpaceUriMapping attribute, is required to create a space for each user.

coSpaceUriMapping Defines the user-specific part of the URI associated with the user's space. Some domains may be configured to set this in the space. If the user-specific part matches this field for one of those domains, the call will be directed to that user's space.

coSpaceSecondaryUriMapping Defines a second URI to reach the space. This can be used to add a numerical alias for routing calls to the imported user's space as an alternative to the alphanumeric URI specified in the coSpaceUriMapping parameter.

LDAP server and LDAP mapping are configured. Now it is required to link them by creating an LDAP source.

Using the URL to access cms01.example.com:445/api/v1/ldapSource we create an LDAP Source object, specifying parameters such as:

• server
• In the server response, I've added the field values of the indexed document in comments:
• baseDn
• filter

Now that the LDAP setup is complete, a manual synchronization operation can be performed.

We do this either in the web interface of each server by clicking Sync now in the section Active Directory


or via API with the command POST using the URL to access cms01.example.com:445/api/v1/ldapSyncs

Ad-Hoc conferences

What is this?In the traditional sense, a conference is when two participants talk to each other, and one of the participants (using a device registered on Unified CM) presses the 'Conference' button, calls another person, and after talking with that third party, presses the 'Conference' button again to join all parties in a three-way conference.

An Ad-Hoc conference differs from a scheduled conference in CMS in that an Ad-Hoc conference is not just a SIP call to CMS. When the conference initiator presses the 'Conference' button a second time to invite everyone to the same meeting, Unified CM must make an API call to CMS to create the conference 'on the fly', to which all calls are then transferred. All of this happens seamlessly for the participants.

This means that Unified CM must configure API credentials and the address/port of the WebAdmin service as well as the SIP trunk directly to the CMS server to continue the call.

If necessary, CUCM can dynamically create a space in CMS so that each call can reach CMS and match the inbound call rule intended for spaces.

Integration with CUCM is configured as described in the article. earlier Except for the requirement to create three trunks for CMS, three Conference Bridges, specify three Subject Names in the SIP Security Profile, and set up Route Groups, Route Lists, Media Resource Groups, and Media Resource Group Lists in Cisco UCM, with some additional routing rules in Cisco Meeting Server.

SIP Security Profile:


Trunks:


Each trunk looks the same:




Conference Bridge


Each Conference Bridge looks the same:


Route Group


Route List


Media Resource Group


Media Resource Group List

Call Rules

Unlike more sophisticated call management systems such as Unified CM or Expressway, for new calls, CMS only looks at the domain field in the SIP Request-URI. So if a SIP INVITE is intended for sip:user@domain.com, CMS only cares about domain.com. CMS follows these rules to determine where to route the call:

1. First, CMS tries to match the SIP domain with the domains configured in the inbound call handling rules. Calls can then be routed to ('target') spaces or specific users, internal IVRs, or directly integrated recipients such as Microsoft Lync/Skype for Business (S4B).
2. If there are no matches in the inbound call handling rules, CMS attempts to match the domain configured in the call redirect table. If a match is found, the rule may explicitly reject the call or redirect it. At this time, CMS may rewrite the domain, which can be useful for calls to Lync domains. You may also choose pass-through, which means that none of the fields will be modified further, or use the internal subscriber group of CMS. If there are no matches in the call redirect rules, calls are by default rejected. Note that in CMS, even while a call is 'redirected', the media still gets tied to the CMS, meaning it will be involved in the signaling and media traffic.
Only redirected calls are subject to outgoing call rules. These parameters determine the recipients to send calls to, the type of connection line (whether it's a new Lync call or standard SIP), and any transformations that may be performed if no transfer is selected in the call redirect rule.

Here is the actual log of what happens during an Ad-Hoc conference.

The screenshot shows poorly (I don't know how to make it better), so I will write the log like this:

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44  Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba  Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66  Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:672@172.x.x.x" to local URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "672@172.x.x.x" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:690@172.x.x.x" to local URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:673@172.x.x.x" to local URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "690@172.x.x.x" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "673@172.x.x.x" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "672@x.x.x" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

The Ad-Hoc Conference:


Incoming Call Rules
Configuring incoming call parameters is necessary to enable call reception in the CMS. As you saw in the LDAP settings, all users were imported with the domain conf.pod6.cms.lab. Therefore, at a minimum, you want calls to this domain to be designated for spaces. You will also need to establish rules for anything directed at the fully qualified domain name (and possibly even for the IP address) of each CMS server. In our external call control, Unified CM, SIP trunks will be configured, aimed at each CMS server individually. Depending on whether the assignment of these SIP trunks is an IP address or a fully qualified domain name will determine whether CMS needs to be configured to accept calls directed to its IP address or fully qualified domain name.

The domain with the highest priority incoming traffic rule is used as the domain for any user spaces. When users synchronize via LDAP, CMS automatically creates spaces, but only the user portion of the URI (coSpaceUriMapping), for example, user.space. The portion domain, of the full URI is created based on this rule. In fact, if you logged into the Web Bridge at this stage, you would see that the Space URI has no domain. By setting this rule as the highest priority, you designate the domain for the generated spaces as conf.example.com.


Outgoing Call Rules

To allow users to make outgoing calls to the Unified CM cluster, outgoing connection rules need to be configured. The domain of endpoints registered in Unified CM, such as Jabber, is example.com. Calls to this domain should be directed as standard SIP calls to the Unified CM call processing nodes. The primary is the cucm-01.example.com server, with the secondary being cucm-02.example.com.

The first rule describes the simplest call routing between servers in the cluster.

Field Local from domain is responsible for what will be displayed in the SIP-URI of the caller on the recipient's side after the "@" symbol. If we leave it empty, the IP address of the CUCM through which the call is passing will appear after the "@" symbol. However, if we specify a domain, that domain will appear after the "@" symbol. This is necessary to allow the possibility of calling back; otherwise, dialing back via SIP-URI name@ip-address will be impossible.

Call when specified Local from domain


Call when DID NOT it is stated Local from domain


You must explicitly state whether the outgoing calls will be Encrypted or Unencrypted; with the Auto parameter, nothing works.

Recording

The recording of video conferences is done by the Record server. The Recorder is essentially the same as the Cisco Meeting Server. No licenses need to be installed on the Recorder. Recording licenses are required for the servers running CallBridge services, that is, the Recording license is necessary and should be applied to the CallBridge component, not to the server where the Recorder is running. The Recorder acts as a client of the Extensible Messaging and Presence Protocol (XMPP), so the XMPP server must be enabled on the server hosting CallBridge.

Since we have a cluster and the license needs to be "stretched" across all three servers in the cluster, we simply associate (add) the MAC addresses of the a-interfaces of all CMS servers included in the cluster in the personal account under licenses.

And this is what the setup should look like on each server in the cluster

There are several scenarios for placing the Recorder, but we will adhere to the following one:


Before setting up the Recorder, it is necessary to prepare a place where the video conferences will be recorded. This is what link, how to set up the entire Recording. I will focus on important moments and details:

1. It is better to use the certificate from the first server in the cluster.
2. The "Recorder unavailable" error may occur because an incorrect certificate is specified in the Recorder Trust.
3. Recording may not occur if a non-root directory is specified for recording in NFS.

Sometimes there is a need to automatically record the conference of a specific user or space.

For this, two CallProfiles are created:
With the recording function disabled


And with the automatic recording function


Next, we "attach" the CallProfile with the automatic recording function to the desired space.


In CMS, it is established that if a CallProfile is explicitly tied to any spaces, then that CallProfile only works concerning those specific spaces. If a CallProfile is not linked to any spaces, it defaults to apply to those spaces to which no CallProfile is explicitly tied.

Next time, I will try to describe the ways to access the CMS outside the organization's internal network.

Sources:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later.pdf

Source: habr.com