Aurus Blog

This blog is to share our expertise in Cisco UCM, UCCX/UCCE and Cisco Telepresence.

  • Archive

    «   December 2019   »
    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 31          

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

In this article, we’ll go into the details of CMS deployment in a failover cluster.

Theoretics

Basically, there are 3 types of CMS deployment:

  • Single Combined with all services running on a single server. In most cases, this deployment type is only applicable for systems with internal clients, or for small environments with scalability and redundancy restrictions not being crucial, or for the situation when CMS only carries out certain functions, such as CUCM special conferences.
    Approximate working scheme:
  • Single Split extends the previous deployment type with a separate server for external access. In outdated deployments this meant having CMS server deployed in DMZ (demilitarized zone) where external clients can access it, and another CMS server in core layer for the local clients. This specific deployment model is being replaced with so-called Single Edge type with Cisco Expressway servers that have (or will have) most firewall bypassing techniques, so clients won’t have to add a separate CMS edge server.
    Approximate working scheme:
  • Scalable and Resilient type includes redundancy for each component, so the system can grow along with your needs up to the maximum capacity, providing redundancy in case of a failure. It also uses Single Edge conception to provide safe external access. This is the type we are going to discuss here. If we know how to deploy this type of cluster, not only will we understand other deployment types, but we also will be able to understand how to create CMS server clusters taking into account the potential requirement increases.

Before we discuss the deployment, we should clarify some basic ideas.

Basic CMS Program Components

  • Database: helps to combine some configurations, such as subscriber groups, user spaces and users. Supports high availability clustering only (one master).
  • Call Bridge: audio and video conferencing service that implements full control and processing of calls and multimedia processes. Supports high availability and scalable clustering.
  • XMPP server: controls registration and authentication for the clients that use Cisco Meeting Application and/or WebRTC (real-time communication, used in browser), and intercomponent signaling. Supports high availability clustering only.
  • Web Bridge: provides WebRTC access for the clients.
  • Load balancer: provides a unified connection point for Cisco Meeting Applications in Single Split mode. It listens on an external interface and port for incoming connections. The load balancer also accepts incoming TLS connections from an XMPP server and transfers incoming TCP connections from external clients. It won’t be used in our scenario.
  • TURN server: provides firewall bypassing technique that allows launching our CMS behind a Firewall or NAT with external clients using Cisco Meeting App or SIP devices. It won’t be used in our scenario.
  • Web Admin: administration interface and API access (for Unified CM special conferences as well).

Configuration Approaches

Unlike most Cisco products, Cisco Meeting Server supports 3 configuration approaches, allowing you to perform any deployment type:

  • Command line interface (CLI), also known as MMP, can be used for initial configuration and certificate management.
  • Web admin: mostly for Call Bridge-related configuration tasks, especially for the configuration of a single non-clustered server.
  • REST API: for the most complicated configuration tasks and for clustered database-related tasks.

Besides that, you can use SFTP protocol for transferring files, including licenses, certificates and logs, to/from your CMS server.

Practice

Cisco deployment guides say in cold print that in the context of databases, a cluster must consist of 3 nodes at least, since the new database Master selection mechanism can only work with an odd number of nodes:

Note: It's recommended to have an odd number of DB cluster nodes as it is important for the master selection and the active failover mechanism. Another reason for this is that the master DB node would be the node that has connections to the most of the DB in the cluster. You can have a maximum of 5 nodes in a DB cluster.

Indeed, as practice shows, 2 cluster nodes are not enough. The master selection snaps into action at the Master reset, and a Slave server becomes Master only after a rebooted server launches. However, if a Master server goes down in a cluster of two servers, then the Slave won’t become a Master. And if the Slave goes down, then the remaining Master will become a Slave, too.

Speaking of XMPP, a cluster should consist of 3 servers, indeed. If you stop XMPP service on the server that has XMPP in Leader status, then XMPP will stay in Follower status on the remaining server, and Call Bridges will be disconnected, because a Call Bridge can only connect to XMPP with Leader status. And this is critical, because no calls will go through.

These deployment guides also show a cluster with a single XMPP server.

In view of the aforementioned, it’s clear: it works in failover mode.

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

Suppose that all three servers are up.

DNS Records

Before we proceed to the servers’ configuration, the following A and SRV DNS records must be created:

Record typeRecordDescription

A

servername-01.example.com
servername-02.example.com
servername-03.example.com
Resolving the name of each server in our cluster into its IP address.
A join.example.com
join.example.com
join.example.com
Three identical records resolved into the corresponding servers’ IP addresses. Users can enter this DNS name in a browser to access a conference from web.

SRV

_xmpp-client._tcp.conf.example.com
_xmpp-client._tcp.conf.example.com
_xmpp-client._tcp.conf.example.com
Three identical records referring to A records: servername-0x.example.com, allowing the servers’ port 5222. Cisco Meeting App clients use these records to find XMPP server.

SRV

_xmpp-component._tcp.conf.example.com
_xmpp-component._tcp.conf.example.com
_xmpp-component._tcp.conf.example.com
Three identical records referring to A records: servername-0x.example.com, allowing the servers’ 5223 port. Call Bridges use these records to detect XMPP server, if it is not defined explicitly.

Note that our DNS records have 2 domains: example.com and conf.example.com. Example.com can be used in URIs by all subscribers of Cisco Unified Communication Manager (which most likely is or will be used in your infrastructure). Or: example.com is the same domain that is used for email addresses. Or: Jabber client on your notebook can have the following URI: user@example.com.

Conf.example.com is the domain to be configured for all Cisco Meeting Server users. The Cisco Meeting Server domain will be conf.example.com, and Jabber users should use user@conf.example.com URI to log it to Cisco Meeting Server.

Basic Configuration

The configuration process will be described for a single server, but it should be performed for each server in a cluster.

QoS

Since CMS produces real-time traffic that is sensitive to delays and packet loss, in most cases it’s recommended to set up quality of service (QoS). CMS supports marking packets with DSCP (differentiated services code points). DSCP-based traffic prioritizing depends on the way the traffic is processed by the network components in your infrastructure. We are going to configure our CMS with typical DSCP prioritizing that is based on best QoS practices.

Enter the following commands on each server:

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 will be marked with AF41 (DSCP 0x22), all voice traffic will be marked with EF (DSCP 0x2E), other low-latency traffic types, such as SIP and XMPP, will be marked with AF31 (DSCP 0x1A).

Let’s check:

NTP

Not only is network time protocol (NTP) important for providing precise timestamps for the calls, but also for certificate verification.

Use the following command to add your NTP servers:

ntp server add <server>

In our case, there are two of them, so the command will be executed twice.

Let’s check:

Set the time zone for your server.

DNS

Use the following command on CMS to add DNS servers:

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

In our case, there are two of them, so the command will be executed twice.

Let’s check:

Network Interface Configuration

Use the following command to create a network interface:

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

Let’s check:

Hostname

Use the following command to set the hostname:

hostname <name>

Then reboot the system.

The basic configuration is over.

Certificates

Theoretics

Cisco Meeting Server uses an encrypted connection between different components, therefore X.509 certificates are required for all CMS deployments, so servers and services know if they can trust each other.

Each service needs a certificate, but creating a separate certificate for each service may lead to confusion and excessive complexity. Fortunately, we can generate a public and private certificate key pair and then use it for several services. In our case, one and the same certificate will be used for Call Bridge, XMPP server, Web Bridge and Web Admin. So, we only have to create a public/private key pair for each server in a cluster.

Database clustering, however, has special requirements to the certificates, so it needs separate certificates that are different from the other services’ certificates. CMS utilizes a server certificate that is similar to other servers’ certificates, but there also is a client certificate to be used for database connections. Database certificates are used for authentication and encryption both. Instead of providing a username and password to connect a client to the database, it provides a client certificate that is trusted by the server. Each server in a database cluster uses one and the same public/private key pair. So, any server in a cluster can create encrypted data that can be decrypted by any other server that uses the same key pair.

In order for reservation to work properly, a database cluster should consist of three servers at least and five at most, with maximum signal transmission time of 200 ms between any two nodes. This limit is more restrictive than Call Bridge limits, so it usually becomes the limiting factor in geographically distributed deployments.

CMS database role has several specific requirements. Unlike other roles, it requires client and server certificates, with client certificate having the CN field specified to be presented to the server.

CMS uses postgres database with one main server and several identical replications. Every single moment there is only one main database (“database server”). Other nodes are replications or “database clients”.

A database cluster requires a dedicated server certificate and a client certificate. They must be signed, usually by an internal private CA. Since any node in a database cluster can become the main one, the certificates for database server and client (public/private key pairs) must be copied on each server, so it can become a database client or server. Besides that, the root CA certificate must be uploaded, so the client and server certificates can be verified.

Certificate Requests

So, use the following command to create a certificate request for all server services except database (it will require a separate request):

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

CN should contain the common name of our servers. For example, if the hostnames are: server01, server02, server03, the CN should be server.example.com.

Do the same for both other servers with the corresponding hostnames used in commands.

Create two request for the certificates that will be used by the database service:

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

pki csr dbclusterclient CN:postgres

where dbclusterserver and dbclusterclient are the names of our request and future certificates, and hostname1(2)(3) are the corresponding server names.

Perform this procedure on one server only, and upload the certificates and corresponding .key files to the other servers.

Enable AD CS to Issue “Client and Server” Certificates

Merge Certificates

Merge all servers’ certificates 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 the following files to each server:

  • The server's certificate.
  • Root certificate (with intermediate ones if they exist).
  • Database certificates (“server” and “client” ones) and .key files that have been created upon the request for “server” and “client” database certificates. These are the same files for all servers.
  • All servers’ certificates.

You should get a similar set of files on each server:

In the next part of this article we’ll continue discussing the details of CMS clustered deployment.

What are you missing in Cisco Meeting Server?

This post is to list some of the gaps of Cisco Meeting Server highlighted by our customers migrating from Cisco TelePresence Server to Meeting Server and partners who deploy Cisco videoconferencing solutions. 


1) UI to configure users and spaces
As you know most of the configuration options are only available via CMS API 

2) Camera snapshots in conference control
The Cisco Meeting Manager tool does not provide camera snapshots. See CMM 2.6 user guide for video operators for more.

3) Monitoring and reporting tool
CMS servers provide API and CDR records but no native reporting tool is available.

4) Lecture mode with hand raising
There used to be a native lecture more for Telepresence Server conferences. Though there are guides about how to configure it with API (see https://kb.acano.com/content/9/68/en/how-do-i-set-up-%E2%80%9Clecture-mode%E2%80%9D.html) the hand raising feature is missing.

5) UI to access meeting recordings
CMS can record meetings (special license is required) but it only stores recording on a NFS. No interface to play recordings, manage access rights etc.

6) Ad-hoc meetings with automatic dial-out
Lots of clients want to start a meeting with a push of a button and have a predefined list of participants to be dialed and joined automatically.

7) Streaming Server
CMS meetings can be streamed to a predefined IP, but you have to deploy some 3rd party media streaming engine to capture it and broadcast to users.

If you feel something major is missing in this list, please give us a shout.

Integration of Cisco Meeting Server with CUCM 11 – PART 3


The last part is about SIP trunking, сonference bridge, route patterns and users.

SIP trunk security profile

Now create a SIP trunk security profile.

If the calls won’t be encrypted, select the values specified below. Enter Call Bridge certificate CN (your CMS server FQDN).

Check Accept Replaces Header if you are going to use conference call bridges.

Conference Bridge

Create a Conference Bridge as described below. Enter username and password of the user with appadmin role (we have created this user in the very beginning).

Create a Media Resource Group and add your Conference Bridge there.

Create Media Resource Group List and add your Media Resource Group there.

Proceed to Standard SIP Profile For TelePresence Conferencing and make sure that Allow iX Application Media, Use Fully Qualified Domain Name in SIP Requests, and Allow Presentation Sharing use BFCP options are checked.

SIP Trunk

Now create a SIP Trunk to CMS server.

You should set the correct Calling Search Space, so calls will be successful. Otherwise, CMS won’t be able to find the required phone number. Both the device and the phone number have to be added to the Calling Search Space.

Media Resource Group List — select the one you have created.

SRTP Allowed flag allows encrypted calls. You can disable it.

SIP Information > Destination address — enter your CMS FQDN or IP address.
SIP Information > Destination Port — standard SIP port is 5060, 5061 is for encrypted calls.
SIP Trunk Security Profile — select the one you have created.
SIP Profile — select Standard SIP Profile For TelePresence Conferencing
Normalization Script — don’t set. It is only needed for encrypted calls. Set cisco-telepresence-conductor-interop if you are using encryption.

Pay attention to the green marked parameters. You should gain an understanding of Calling Search Spaces to fill them correctly.

Leave other fields with default values.

SIP Route Pattern

Create a SIP Route Pattern for calls to SIP addresses like smith.j@example.com

Check CMS and CUCM:

The trunk is up.

However, the Conference Bridge is down due to the difference in TLS versions on CUCM and CMS. This issue can be solved by TLS 1.0 installation on CMS:

tls webadmin min-tls-version 1.0
webadmin restart

Check the Conference Bridge:

Our configuration is being performed on trunks without Media Termination Point (MTP).
Disable MTP if it won’t affect your services.

Disbling MTP can affect your services if your phones use SCCP protocol and you have to send DTMS to CMS.

If this is true for your services, you may have to increase MTP capacity on CUCM depending on the number of simultaneous calls.

Importing Active Directory Users

Now import the users from Active Directory.

Proceed to Configuration -> Active Directory, fill out the fields (see the figure below).

Filter is a very important field. You can enter your own filter or use the filter shown on the picture.

Look through the logs.

Everything is right.

Proceed to Status -> Users to make sure that all users have been imported.

Availability check

We got to the best part.

To perform a call, access the web interface: cms.example.com
Enter an Active Directory user login and password to log in.

Now let’s check a video call from an IP Phone (we are using Cisco E20) to our user account.

I have web and desktop Cisco Meeting clients running, and both are calling.

You can also test the video call from your user account to IP Phone. In our case, the video call was successful in both directions.

Encrypted calls can bring in some complications, but that’s a story for another day.

See also:

Integration of Cisco Meeting Server with CUCM 11 – PART 2


Part 2 explains call settings, Incoming and Outbound calls configuration, spaces and CUCM certificates

Basic Call Settings Configuration

Proceed to Configuration > Call settings and set the values as given below:

Incoming Call Handling Configuration

Proceed to Configuration > Incoming calls and set the values as specified below:

This configuration determines the way of incoming SIP calls handling on CMS. Any call routed to CMS will have a verified alias. The rules in call matching table determine where CMS will look for potential matches. Each rule can be set to match any combination of users, IVR or MicrosoftSkype / Lync. To handle incoming calls, Cisco Meeting Server tries to match the value after "@" sign with the values in “domain name” column.

Outbound Call Handling Configuration

Proceed to Configuration > Outbound calls.
Domain name: leave empty (to match all domains)
SIP Proxy to use: enter your CUCM FQDN (IP address is admissible, but FQDN is recommended)
Local contact domain: leave empty, it is only needed for Skype for Business SIP Trunk configuration.
Local from domain: enter Cisco Meeting Server SIP domain (e.g. cms.example.com)
Trunk type: Standard SIP
Behavior: Continue
Priority: 1
Encryption: Auto or Unencrypted
Click Add New to save the changes.

Space Creation

Create a space where the users will be stored.

Proceed to Configuration > Spaces

The Secondary URI should be a E.164 value compatible with your dial plan that will be routed to CMS. The CallID can be any number that is not used yet. In this example we use the same value as for Secondary URI.

Configure Web Bridge for Call Bridge

To allow guest access to Web Bridge, configure Call Bridge to set Web Bridge address.

Proceed to Configuration > General

Configure a HTTPS CMS URL address for a guest account. For example:
meetingserver.example.com

Fill External Access field if you want to add Cisco Expressway web proxy. This address will be used in invites for external users.

CUCM Certificates

Perform the requests for Tomcat (CUCM web server) and CallManager services.
Proceed to Cisco Unified OS Administration > Security-Certificate Management and click Generate CSR.

First, select Tomcat in the Certificate Purpose field, so you won’t get errors in your browser.

Click Generate.

Then select CallManager, so CMS and CUCM will check each other’s certificates for Conference Bridge registration.

Click Generate.

Now download the certificate signing request files for CA.


Upload root and intermediate certificates for Tomcat-trust and CallManager-trust, either one by one (root certificate first) or as a single file (as described above).

Click Upload.

Upload the CA certificate files formed upon your request.

Now restart Cisco Tomcat, Cisco CallManager and Cisco TFTP services.

Restart Cisco Tomcat from the command line.

The other ones can be restarted from web interface.


Click Restart and wait for the services to be restarted.

Integration of Cisco Meeting Server with CUCM 11 – PART 1


The first part covers network settings, CMS License and Certificates, Call Bridge, Web admin, XMPP, Web Bridge.

This article is about CMS (Cisco Meeting Server) and its integration with CUCM (Cisco Unified Communications Manager).

Suppose that CMS and CUCM have already been deployed on virtual machines.

Before the configuration, make the following preparations:

  • Create a DNS record for CMS IP address with an alias to be used by end users. For example:
    meetingserver.example.com
  • XMPP Domain Name: the name that will be used to log in to Cisco Meeting App. In our case, it will be the user’s sAMAccountName, imported from Active Directory.
  • To support Cisco Meeting App users, add a DNS SRV record for XMPP domain name. SRV record for _xmpp-client._tcp.<xmpp domain> needs TCP port 5222.
  • Note: you don’t need this if you use the desktop application only.
    SIP domain for the meeting server.

Suppose you are using a sub-domen, for example, meet.example.com.

IP address, mask, gateway, DNS, NTP, new user

First of all, enter the valid IP address of your service (CMS has several interfaces, select the first one: "a";).

Add DNS addresses for your zone (if needed). Use "dns" command to check the configuration.

Set CMS hostname and reboot.

It’s recommended to create separate administrator accounts for safety purposes. «Admin» account is not safe enough. Besides that, it’s recommended to have 2 administrator accounts in case you lose one of the administrator passwords. In this situation, you’ll still be able to log in as the second administrator and reset the lost password.

Username: «root», role: «admin».

Getting ahead of it, create another user with role "appadmin", so CUCM will be able to configure CMS on application level via Web Admin interface (i.e. for Conference Bridge registration).

Now set your NTP server and timezone and reboot.

CMS License and Certificates

Now you have to form a request for CMS certificates.

Cisco Meeting Server services use x.509 certificates for TLS connections and for some authentication purposes. In our case, the certificate is needed for Call Bridge, XMPP, Web Bridge and Web Admin services. Certificates can be self-signed or signed by internal or external CA.

Self-signed certificate is admissible, but not recommended, as it causes errors on web pages and prevents registering CMS Conference Bridge on CUCM.

Generate a request:

pki csr Cert CN:example.com subjectAltName:callbridge.example.com,xmpp.example.com,webbridge.example.com

Since we are using one certificate for all services, AltName should contain this services’ names.

Download, install and run WinSCP to get your request file and to put the license file on your CMS server.

To get the license (a 90-days demo version), apply to some Cisco partner and piteously ask for a demo license for education or demonstration purposes, or buy a full license and add your interface MAC address to your piteous letter.

Get the MAC address with the following command: "iface a"

Suppose you get lucky and obtain the license file with .lic extension. Rename it to "cms.lic"

Now run WinSCP. Create a connection to CMS.

Connect:

Save cms.lic and Cert.csr to CMS.

To create a full chain certificate file (because our CMS won’t use .p7b file), do the following:

In a command line:

a. In UNIX OS: cat “intermediate certificate 1” “intermediate certificate 2” “intermediate certificate 3” “root certificate” > ca-bundle

b. In Windows/DOS: copy “intermediate certificate 1” + “intermediate certificate 2” + “intermediate certificate 3” + “root certificate” ca-bundle

Use WinSCP to load the resultant file and the CMS certificate file to CMS.

Reboot, check the license:

Call Bridge, Web admin, XMPP, Web Bridge

Call Bridge

Configure Call Bridge to listen on a interface:

callbridge listen a

Configure Call Bridge to use the certificate, key and CA bundle files:

callbridge certs <keyfile> <certificatefile> <ca bundle>

Restart callbridge:

callbridge restart

Web Admin

Setup Web Admin service:

webadmin listen a 445

Port 445 has been chosen because 443 is already used for web access.
Configure the certificate files for Web Admin service:

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

And turn it on:

webadmin enable

If everything is right, you'll get SUCCESS messages telling about Web Admin certificate and network parameters being correctly configured. To check if the service is available, enter the web administrator address in your web browser, for example: cms.example.com:445

XMPP

Setup XMPP service:

xmpp listen a

Configure the certificate files for XMPP service:

xmpp certs <keyfile> <certificatefile> <ca bundle>

Set XMPP deployment domain:

xmpp domain <domain name>

Turn the service on:

xmpp enable

Check CMS and CUCM:

Add Call Bridge to XMPP server:

xmpp callbridge add

Copy the Secret and paste it to XMPP server settings, configure the other parameters (see the figure below)

Web Bridge

Setup Web Bridge service:

webbridge listen a:443

Configure the certificate files for Web Bridge service:

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

Web Bridge supports HTTPS. If it is configured to use httpredirect, then HTTP will be redirected to HTTPS. To enable HTTP redirection, use the following command:

webbridge http-redirect enable

Use the following command to make Web Bridge trust Call Bridge connections with the certificate previously issued by a certification center:

webbridge trust <certfile>

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

Cisco Meeting Server (CMS) and Skype for Business (Lync) Integration – Basics and Hints

On S4B front-end server, configure a trusted application and routing. Execute the following commands in PowerShell:

  • New-CsTrustedApplicationPool -Identity cms.vc.domain.com -ComputerFqdn cms.vc.domain.com -Registrar S4BFE.domain.com -Site 2 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true
  • New-CsTrustedApplication -Applicationid cms -TrustedApplicationPoolFqdn cms.vc.domain.com -Port 5061
  • New-CsStaticRoutingConfiguration -Identity "Service:Registrar:S4BFE.domain.com"
  • $route = New-CsStaticRoute -TLSRoute -Destination "cms.vc.domain.com" -Port 5061 -MatchUri "vc.domain.com" -UseDefaultCertificate $true
  • Set-CsStaticRoutingConfiguration -Identity "Service:Registrar:S4BFE.domain.com" -Route @{Add=$route}
  • Set-CsMediaConfiguration -MaxVideoRateAllowed Hd720p15M
  • Enable-CsTopology

On CMS proceed to Configuration\General and enter the S4B front-end server address and the username to be used to register.

In General Incoming Calls section, enter the CMS local domain name.

In General\Outbound Calls, enter the domain names to be called from Cisco Meeting. To allow calls to any domains, leave the Domain field empty. It will be set to ⟨match all domains⟩.

The Local From Domain field contains different domain names to be used to call domain.com and other domains. Calls from CMS will be transferred to the domains federated with yours in Skype for Business. However, it can be possibly configured differently. The last step is to configure encryption in General\Call Settings section.

That’s it. Now your Cisco Meting App clients and Skype for Business (Lync) clients should be able to call each other.

HINT: Limitation of the number of registrations in Skype for Business

During one of our conferences, we faced a limitation of the number of external Skype for Business participants. New participants would just disconnect, never visiting the room.

After talking to specialists, we decided to increase the number of CMS registrations on S4B servers.

First of all, we created 5 AD users for CMS and registered these accounts in Skype for Business. The accounts meet the following template: username[1-9]. So, to increase the number of participants up to 5, you should create 5 users: username1, username2, username3, username4 and username5, and add corresponding accounts to S4B.

Then you should enter the required number of registrations in CMS configuration:

After this simple manipulation you shouldn't face this kind of limitation anymore.