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

In this issue, I will show and explain some of the subtleties of setting up a CMS server in failover cluster mode.


TheoryIn general, there are three types of CMS server deployment:

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

  Approximate scheme of work:
  

• single split(Single Shared) extends the previous deployment type by adding a separate server for external access. In legacy deployments, this meant deploying a CMS server in a demilitarized network segment (DMZ) where external clients could access it, and a single CMS server in the network core where internal clients accessed the CMS. This particular deployment model is now superseded by the so-called type single edge, which consists of servers Cisco Expressway, which either have or will have many of the same Firewall bypass capabilities, so customers don't need to add a dedicated CMS edge server.

  Approximate scheme of work:
  

• Scalable and Resilient(Scalable and Fault Tolerant) This type includes redundancy for each component, allowing the system to grow with your needs to its maximum capacity while providing redundancy in the event of a failure. It also uses the Single Edge concept to provide secure external access. This is the type we'll cover in this episode. If we understand how to deploy this type of cluster, we will not only understand other types of deployment, but we can also understand how to create clusters of CMS servers, taking into account the potential growth of needs.

Before moving on to deployment, you need to understand some basic things, namely

Main software components of CMS:

• Database: allows you to combine some configurations such as dial plan, user spaces, and users themselves. Supports clustering for high availability (single master) only.
• call bridge: a service for audio and video conferencing, bringing full control over the management and processing of calls and multimedia processes. Supports clustering for high availability and scalability.
• XMPP server: responsible for registering and authenticating clients using the Cisco Meeting Application and/or WebRTC(real-time communication, or simply in the browser), as well as intercomponent signaling. Can only be clustered for high availability.
• web bridge: Provides client access to WebRTC.
• Loadbalancer: Provides a single connection point for Cisco Meeting Apps in Single Split mode. Listens on the external interface and port for incoming connections. Equally, the load balancer accepts incoming TLS connections from the XMPP server, through which it can switch TCP connections from external clients.
  In our scenario, it will not be needed.
• TURN server: Provides Firewall bypass technology that allows
  hang our CMS behind a Firewall or NAT to connect external clients using the Cisco Meeting App or SIP devices. In our scenario, it will not be needed.
• Web Admin: Administrative interface and API access, including for ad hoc Unified CM conferences.

Configuration Modes

Unlike most other Cisco products, Cisco Meeting Server supports three configuration methods to enable any kind of deployment.

• Command Line (CLI): Command line interface, known as MMP, for initial configuration tasks and certificates.
• Web Administrator: Primarily for CallBridge related configuration, especially when configuring a single non-clustered server.
• REST API: Used for the most complex configuration and cluster database tasks.

In addition to the above, the protocol SFTP to transfer files—usually licenses, certificates, or logs—to and from the CMS.

In deployment guides from Cisco, it is written in English and white that the cluster needs to be deployed at least three servers (nodes) in the context of databases. Because only with an odd number of nodes will the mechanism for selecting a new Database Master work, and in general the Database Master has a connection to most of the database of the CMS server.

And as practice shows, two servers (nodes) are really not quite enough. The selection mechanism works when the Master is rebooted, the Slave server becomes the Master only after the rebooted server is raised. However, if in a cluster of two servers the Master server suddenly “goes out”, then the Slave server will not become the Master, and if the Slave “goes out”, then the remaining Master server will become the Slave.

But in the context of XMPP, it would really be necessary to assemble a cluster of three servers, because if, for example, you disable the XMPP service on one of the servers in which XMMP is in the Leader status, then on the remaining XMPP server it will remain in the Follower status and CallBridge's connections to XMPP will fall off, because CallBridge connects exclusively to XMPP with Leader status. And this is critical, because. no call will go through.

Also in the same deployment guides, a cluster with one XMPP server is demonstrated.

And taking into account the above, it becomes clear why: it works because it is 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 you start configuring servers, you need to create DNS records А и SRV types:

Note that our DNS records have two domains example.com and conf.example.com. Example.com is a domain that all subscribers of the Cisco Unified Communication Manager can use for their URIs, which is likely to be present in your infrastructure or likely to be present. Or the example.com domain matches the same domain users use for their email addresses. Or the Jabber client on your laptop might have a URI [email protected]. Domain conf.example.com is the domain that will be configured for Cisco Meeting Server users. Cisco Meeting Server domain will be conf.example.com, so the same Jabber user would need to use the URI user@ to log in to Cisco Meeting Serverconf.example.com.

Basic configuration

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

QoS

Since the CMS generates real-time traffic that is sensitive to delays and packet loss, in most cases it is recommended to configure the quality of service (QoS). To do this, the CMS supports marking packets with differentiated service codes (DSCPs) that it generates. While DSCP-based traffic prioritization depends on how traffic is handled by the network components of your infrastructure, in our case we will configure our CMS with typical DSCP prioritization based on QoS best practices.

On each server, enter these commands

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

So all video traffic was tagged AF41 (DSCP 0x22), all voice traffic was tagged EF (DSCP 0x2E), other low latency traffic like SIP and XMPP use AF31 (DSCP 0x1A).

We check:

NTP

Network Time Protocol (NTP) is important not only for providing accurate time stamps for calls and conferences, but also for verifying certificates.

Add an NTP server to your infrastructure with a command like

ntp server add <server>

In our case, there are two such servers, so there will be two teams.
We check:

And set the time zone for our server

DNS

DNS servers are added to the CMS with a command like:

dns add forwardzone <domain-name> <server ip>

In our case, there are two such servers, so there will be two teams.
We check:

Network interface configuration

We configure the interface with a command of the form:

ipv4 <interface> add <address>/<prefix length> <gateway>

We check:

Server name(Hostname)

The server name is set with a command of the form:

hostname <name>

And we reboot.


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 ensure that a service/server is trusted by other servers/services.

Each service requires a certificate, but creating separate certificates for each service can be confusing and overcomplicated. Luckily, we can generate a certificate public/private key pair and then reuse it across multiple services. In our case, the same certificate will be used for Call Bridge, XMPP Server, Web Bridge and Web Admin. Thus, you need to create a certificate public and private key pair for each server in the cluster.

Database clustering, however, has some special certificate requirements and therefore requires its own certificates, which are different from those of other services. The CMS uses a server certificate, which is similar to the certificates used by other servers, but there is also a client certificate used for database connections. 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 public/private key pair. This allows all servers in the cluster to encrypt data so that it can only be decrypted by other servers that also use the same key pair.

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

The database role for a 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 that is presented to the server.

The CMS uses a postgres database with one master and several identical replicas. There is only one master database at any given time (the "database server"). The rest of the cluster members are replicas or "database clients".

The database cluster requires a dedicated server certificate and a client certificate. They must be signed with certificates, usually an internal private CA. Since any member of the database cluster can become the master, the database server and client certificate pairs (containing the public and private keys) must be copied to all servers so that they can assume the identity of the client or database server. In addition, the root CA certificate must be loaded to ensure that the client and server certificates can be verified.

So, we form a request for a certificate that will be used by all server services with the exception of 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 the generalized name of our servers. For example, if the hostnames of our servers server01, server02, server03, then CN will be server.example.com

We do the same on the remaining two servers with the difference that the commands will contain the corresponding "hostnames"

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

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

pki csr dbclusterclient CN:postgres

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

We perform this procedure only on one server (!), and we will upload the certificates and the corresponding .key-files to other servers.

Enable client certificate mode in AD CS

You also need to merge certificates for each server into one fileOn *NIX:

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

On Windows/DOS:

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

And upload to each server:
1. "Individual" server certificate.
2. Root certificate (together with intermediate certificates, if any).
3. Certificates for the database ("server" and "client") and files with the .key extension, which were generated when creating a request for the "server" and "client" certificate of the database. These files must be the same on all servers.
4. The file of all three "individual" certificates.

As a result, approximately the same file picture should be obtained on each server.

Database Cluster

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

Master Database

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

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Now let's tell CMS which interface to use for database clustering with the command:

database cluster localnode a

Then we initialize the cluster database on the main server with the command:

database cluster initialize

Client Database Nodes

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

database cluster join <ip address existing master>

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

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

database cluster status

We do the same on the remaining third server.

As a result, it turns out that our first server is the Master, the rest are Slaves.

Web Admin Service

Enable the web administrator service:

webadmin listen a 445

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

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

webadmin certs <keyfile> <certificatefile> <ca bundle>

And enable Web Admin with the command:

webadmin enable

If all is well, we will get SUCCESS lines indicating that Web Admin is configured correctly for the network and certificate. We check the health of the service using a web browser and enter the address of the web administrator, 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 conferencing mechanism. It also provides a SIP interface so that calls can be routed to or from it, such as by Cisco Unified CM.

The commands described below must be run on each server with the appropriate certificates.
So:

Associate certificates with the Call Bridge service with a command like:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

We bind the CallBridge services to the interface we need with the command:

callbridge listen a

And restart the service with the command:

callbridge restart

Now that we have our Call Bridges configured, we can set up Call Bridge clustering. Call Bridge clustering is different from database or XMPP clustering. Call Bridge Cluster can support 2 to 8 nodes without any limitation. It provides not only redundancy, but also load balancing, so that conferences can be actively distributed between Call Bridge servers using intelligent call distribution. The CMS has additional features, Call Bridge groups and related features that can be used for further management.

Call bridge clustering is configured primarily through the web admin interface
The following procedure must be carried out on each cluster server.
So,

1. We go through the web in Configuration> Cluster.
2. In call bridge identity as a unique name, enter callbridge[01,02,03] corresponding to the server name. These names are arbitrary, but must be unique for this cluster. They are descriptive in that they indicate that they are server IDs [01,02,03].
3.V Clustered Call Bridges enter the web admin 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 Peer link SIP domain empty.
4. We add a certificate to the trust of CallBridge for each server, the file of which contains all the certificates of our servers that we merged into this file at the very beginning, with a command like:

callbridge trust cluster <trusted cluster certificate bundle>

And restart the service with the command:

callbridge restart

As a result, on each server you should get the following picture:

XMPP Cluster

The XMPP service in the CMS is used to handle all registration and authentication for Cisco Meeting Apps (CMA), including the CMA WebRTC Web Client. The Call Bridge itself also acts as an XMPP client for authentication purposes and therefore must be configured like other clients. XMPP failover is a feature that has been supported in production environments since version 2.1

The commands described below must be run on each server with the appropriate certificates.
So:

Associate certificates with the XMPP service with a command like:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

Then define the listening interface with the command:

xmpp listen a

The XMPP service requires a unique domain. This is the login for users. In other words, when a user tries to login using the CMA application (or via a WebRTC client), they enter userID@logindomain. In our case, this will be userid@conf.example.com. Why isn't it just example.com? In our particular deployment, we chose our Unified CM domain that 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 the SIP domains.

Set up an XMPP domain with a command like:

xmpp domain <domain>

And enable the XMPP service with the command:

xmpp enable

In the XMPP service, you must create a credential for each Call Bridge that will be used when registering with the XMPP service. These names are arbitrary (and not related to the unique names you configured for call bridge clustering). You must add three call bridges on one XMPP server and then enter these credentials on other XMPP servers in the cluster because this configuration does not fit into the cluster database. Later, we will configure each Call Bridge to use this name and secret to register with the XMPP service.

Now we need to set up the XMPP service on the first server with three Call Bridges callbridge01, callbridge02 and callbridge03. Each account will be assigned random passwords. Later, they will be entered on other Call Bridge servers to log into this XMPP server. Enter the following commands:

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

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

xmpp callbridge list

Exactly the same picture should be on the other servers after the steps described below.

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

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

We add Secret very carefully so that extra spaces do not accidentally get into it, for example.


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

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

xmpp cluster trust <trust bundle>

Enable cluster xmpp mode on all cluster servers with the command:

xmpp cluster enable

On the first server of the cluster, we initiate the creation of an xmpp cluster with the command:

xmpp cluster initialize

On other servers, we add a cluster to xmpp with a command like:

xmpp cluster join <ip address head xmpp server>

On each server, we check the success of creating an XMPP cluster on each server with 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, we need to configure the Call Bridge services to connect to the XMPP cluster. This configuration is done through the web administrator.

We go on each server in Configuration> General and in the field Unique Call Bridge name we write the unique names of the Call Bridge corresponding to the server callbridge[01,02,03]... In field Domain conf.example.com and the corresponding passwords, you can spy on them
on any cluster server with the command:

xmpp callbridge list

Leave the "Server" field blank. callbridge will perform a DNS SRV lookup for _xmpp-component._tcp.conf.example.comto find an available XMPP server. IP addresses for connecting callbridges to XMPP may differ on each server, it depends on what values ​​are returned to the write request _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 see if the Call Bride service successfully connected to the XMPP service.

web bridge

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

webbridge listen a:443

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

webbridge  certs <keyfile> <certificatefile> <ca bundle>

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 tell Call Bridge that Web Bridge can be trusted for connections from Call Bridge, use the command:

webbridge trust <certfile>

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

Such a picture should be on each server of the cluster.


Now we need to create a user with the “appadmin” role, we need it so that we can configure our cluster (!), And not each server of the cluster separately, so the settings will be applied equally to each server, even though they will be made once.


For further customization, we will use Postman.

For authorization, select Basic in the Authorization section

To correctly send commands to the CMS servers, you need to set the desired encoding

Specify Webbridge with the command POST with parameter url and the value cms.example.com



In the webbridge itself, we specify the parameters we need: guest access, secure access, and so on.

Call Bridge Groups

By default, the CMS does not always make the most of the conferencing resources available to it.

For example, for a meeting with three participants, each participant may be on three different Call Bridge'ax. In order for these three participants to communicate with each other, Call Bridges will automatically establish connections between all servers and clients in the same Space, so that it all looks like all clients are on the same server. Unfortunately, the downside to this is that one 3-person conference will now consume 9 media ports. This is obviously an inefficient use of resources. Also, when a Call Bridge is really congested, the default mechanism is to continue to receive calls and provide reduced quality service to all subscribers of that Call Bridge.

These problems are solved using the Call Bridge Group feature. This feature was introduced in version 2.1 of the Cisco Meeting Server Software and has been extended to support load balancing for both incoming and outgoing calls, the Cisco Meeting App (CMA), including WebRTC participants.

To solve the reconnection problem, three configurable load limits were introduced for each Call Bridge:

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

While this feature was designed for call distribution and load balancing, other groups such as TURN servers, Web Bridge servers, and recorders can also be assigned to Call Bridge Groups so that they can also be correctly grouped for optimal use. If any of these objects are not assigned to a call group, they are assumed to be available to all servers without any particular priority.

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

Next, we indicate to each callbridge which callbridge group it belongs to:

First callbridge

Second callbridge

Third callbridge


Thus, we configured the Call Brdige group to use the resources of the Cisco Meeting Server cluster more efficiently.

Importing users from Active Directory

The Web Admin service has an LDAP configuration section, but it doesn't provide complex configuration options, and the information is not stored in the cluster database, so the configuration will have to be done, either manually on each server through the Web interface, or through the API, and so that we "three times do not get up ”we will still set the data through the API.

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

• Server IP
• port number
• Username
• password
• ax

Secure - true or false depending on the port, 389 - not secure, 636 - secure.


Mapping LDAP Source Options to Attributes in Cisco Meeting Server.
The LDAP mapping maps the attributes in the LDAP directory to the attributes in the CMS. Actually attributes:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Description of attributesIADB represents the login ID of the user in the CMS. Since this is a Microsoft Active Directory LDAP server, the CMS JID maps to sAMAccountName in LDAP, which is essentially the user's Active Directory login ID. Also note that you are taking the sAMAccountName and adding the conf.pod6.cms.lab domain to the end of it because that is the login your users will use to log into the CMS.

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

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

coSpaceUriMapping defines the user part of the URI associated with the user's personal space. Some domains can be configured to be set to space. If the user part matches this field for one of these domains, the call will be directed to that user's space.

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

The LDAP server and LDAP mapping are configured. Now we need to link them together by creating an LDAP source.

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

• server
• mapping
• baseDn
• filter

Now that the LDAP setup is complete, you can perform the manual synchronization operation.

We do this either in the Web interface of each server by clicking Sync now In chapter Active Directory


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

Ad hoc conferences

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

The difference between an Ad-Hoc conference and a scheduled CMS conference is that an Ad-Hoc conference is not just a SIP call to the CMS. When the conference initiator clicks the Conference button a second time to invite everyone to the same meeting, the Unified CM must make an API call to the CMS to create an on-the-fly conference, to which all calls are then transferred. All this happens invisibly to the participants.

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

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

Integration with CUCM configured in the same way as described in the article earlier except that on Cisco UCM you need to create three trunks for CMS, three Conference Bridges, specify three Subject Names in the SIP Security Profile, Route Group, Route List, Media Resourse Group and Media Resourse Group List, and add some routing rules to 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 advanced call control systems such as Unified CM or Expressway, for new calls, the CMS only looks up the domain in the SIP Request-URI field. So if SIP INVITE is for sip: [email protected], the CMS only cares about domain.com. The CMS follows these rules to determine where to route a call:

1. First, the CMS tries to map the SIP domain to the domains configured in the incoming call handling rules. These calls can then be routed to ("target") spaces or specific users, internal IVRs, or directly integrated Microsoft Lync/Skype for Business (S4B) destinations.
2. If there is no match in the incoming call handling rules, CMS will try to match the domain configured in the call forwarding table. If a match is established, the rule can explicitly reject the call or redirect the call. During this time, the CMS may rewrite the domain, which is sometimes useful for calling Lync domains. You can also choose to pass throw, which means that none of the fields will be further changed, or use an internal CMS dial plan. If there is no match in the call forwarding rules, call rejection is used by default. Be aware that in the CMS, although the call is "forwarded", the media is still bound to the CMS, which means it will be in the signaling and media traffic path.
Then only forwarded calls are subject to outgoing call rules. These settings determine the destinations where calls are sent, the type of trunk (whether a new Lync call or standard SIP), and any translations that can be performed if transfer is not selected in a call forwarding rule.

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

The screenshot shows poorly (I don’t know how to do it better), so I’ll 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:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

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 "[email protected]"

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

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

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 "[email protected]"

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

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

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 "[email protected]"

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 "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (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 "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (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 "[email protected]" 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 itself:


Incoming call rules
Configuring incoming call settings is required to be able to receive a call in the CMS. As you saw in the LDAP setup, all users were imported with the conf.pod6.cms.lab domain. So at a minimum, you want calls to this domain to target spaces. You will also need to set up rules for anything that is for the FQDN (and possibly even IP address) of each of the CMS servers. Our external call control, Unified CM, will set up SIP trunks dedicated to each of the CMS servers individually. Whether the destination of these SIP trunks is an IP address or the server's FQDN will determine whether the CMS needs to be configured to accept calls directed to its IP address or FQDN.

The domain that has the highest priority inbound rule is used as the domain for any user spaces. When users sync via LDAP, the CMS automatically creates spaces, but only the user part of the URI (coSpaceUriMapping), such as user.space. Part domain the full URI is generated based on this rule. In fact, if you were to log into Web Bridge at this point, you would see that the Space URI does not have a domain. By setting this rule as the highest priority, you set the domain for generated spaces to be conf.example.com.


Outgoing call rules

To allow users to make outbound calls to the Unified CM cluster, you must configure outbound rules. The domain of endpoints registered with Unified CM, such as Jabber, is example.com. Calls to this domain should be routed as standard SIP calls to Unified CM call processing nodes. The main server is cucm-01.example.com, and the secondary server is cucm-02.example.com.

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

Field Local from domain is responsible for what will be displayed in the SIP-URI of the caller of the one who is being called after the “@” symbol. If we leave it empty, then after the "@" symbol there will be the ip-address of CUCM'a through which this call passes. If we specify a domain, then after the “@” symbol, there will actually be a domain. This is necessary in order to be able to call back, otherwise it will not be possible to call back using the SIP-URI name@ip-address.

Call when indicated Local from domain


call when NOT Set Local from domain


Be sure to explicitly specify Encrypted or Unencrypted for outgoing calls, because nothing works with the Auto parameter.

Recording

Video conferences are recorded by the Record-server. Recorder is exactly the same Cisco Meeting Server. Recorder does not require any licenses to be installed on itself. Recording licenses are required for servers running CallBridge services, i.e. The Recording license is required and must be applied to the CallBridge component, not to the server running the Recorder. The Recorder behaves like an Extensible Messaging and Presence Protocol (XMPP) client, so the XMPP server must be enabled on the server hosting the CallBridge.

Because we have a cluster and the license needs to be “stretched” to all three cluster servers. Then simply in the personal account in the licenses we associate (add) the MAC addresses of the a-interfaces of all CMS servers included in the cluster.

And this picture should be on each cluster server

In general, there are several scenarios for placing a Recorder, but we will stick to this:


Before setting up the Recorder, you need to prepare a place where video conferences will actually be recorded. Actually here linkhow to set up the whole Recording. I will focus on important points and details:

1. It is better to palm off the certificate from the first server in a cluster.
2. The error "Recorder unavailable" may occur because the wrong certificate is specified in the Recorder Trust.
3. The write may not go if the write specified is not the root directory in NFS.

Sometimes there is a need to automatically record a conference of one particular user or space.

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


And with automatic recording function


Further to the necessary space'u we "fasten" CallProfile with automatic function of record.


In CMS, it is so established that if a CallProfile is explicitly tied to some spaces or spaces, then this CallProfile works only for these specific spaces. And if the CallProfile is not bound to any space, then by default it is applied to those spaces to which no CallProfile is explicitly bound.

Next time I will try to describe how the CMS is accessed 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