The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to add participants to an existing CMS conference in deployment of Clustered CMS with Load Balancing enabled.
Cisco recommends that you have knowledge of these topics:
This document assumes that Load Balacing is already configured for your clustered Callbridges (CB) and working for direct calls to these CMS servers (calling directly to an existing CMS space). This means that these requirements are already configured:
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Note: There are three main methods of adding a participant to an existing CMS conference: add a participant via API, add a participant via Active Control, and add a participant without Active Control.
1. Add a participant via API
To use this method, LoadbalanceOutgoingCalls on the Callbridge Group has to be enabled.
To add the participant using this method, an API POST request has to be made to /calls/<active-call-id>/participants/. The POST request needs to include the participantID of the participant which is being added to the conference as value of the remoteParty parameter, which is part of this POST request.
This POST request instructs CMS to make an outgoing call to the participant which is being added. If LoadbalanceOutgoingCalls on the Callbridge Group is enabled, and if CMS has reached its load limit, it finds a free CMS server in the cluster to make an outgoing call to the participant being added, and a distributed call is created between the two servers. This is the same method used by CMM to add participants to a CMS conference.
2. Add a participant via Active Control
To use Active Control participant add, Active Control has to be negotiated first between the CMS server and the user which is adding the participant.
You need to enable Active Control on the SIP Trunk Profile that is configured on the SIP Trunk connecting CUCM with CMS, to do so enable parameter Allow IX application media, and note that the Standard SIP Profile For TelePresence Conferencing has it enabled by default. In addition, LoadbalanceOutgoingCalls on the Callbridge Group has to be enabled.
When a participant is added via Active Control to an existing CMS conference, CMS1 is instructed by the user (via active control message) to make an outgoing call to the new participant. If the load limit value configured on CMS1 is reached and the user tries to add a new participant with active control, CMS1 displays this error message (up to CMS version 2.9.1):
add participant "<participant-uri>" request failed: call bridge unavailable
This applies to both use cases - when the participant is added to an adhoc conference, and when it is added to an exsiting CMS space via active control.
This is a deffective behaviour and it is being tracked under the defect: CSCvu72374
3. Add a participant without Active Control
When a participant is added without using active control (therefore Allow IX application media not enabled on the SIP Profile), CUCM makes a call between the user who is initiating the action and the new participant. Then, when the user is ready to join the new participant to the conference, CUCM makes an outgoing call to the adhoc conference running on CMS1. If the load limit is reached on CMS1, the participant cannot be added and CMS1 displays this error message (55 is an example call number):
call 55: ending; local teardown, system participant limit reached - not connected after 0:00
This error message is a normal error message to be printed by a CMS server when it receives an incoming call and after it has reached its max load limit. It is then up to the call control server (CUCM or VCS) to continue routing the call to other members in the cluster. However, in the case of an adhoc conference, this does not work and it is not possible since CUCM does not have a Route List for adhoc conferences.
This document provides the configuration steps required to use the 3rd way of adding participant to existing conference (Add a participant without Active Control).
The behaviour addressed with the configurational steps in this document is:
1. User creates an adhoc conference, CMS1 server is hosting it
2. After the adhoc conference is established, gradually CMS1 reaches its configured loadlimit (configured over API at /system/configuration/cluster)
3. The user tries to add a new participant to the ongoing adhoc conference, however, the new user does not get connected to the conference
Note: This configuration procedure allows for a user to add participants to an existing CMS adhoc conference even if the CMS server hosting the adhoc conference has reached its load limit, and it can be used until the active control defect is fixed. Active Control becomes disabled in that ad-hoc conference.
Step 1. Create a new SIP Trunk Security Profile for Trunk1
![]() |
Step 2. Create a new SIP Trunk Security Profile for Trunk2
![]() |
Step 3. Create a new SIP Normalization Script
M = {} function M.outbound_INVITE(msg) msg:removeHeaderValue("Call-Info", "<urn:x-cisco-remotecc:conference>") end return M
Step 4. Create a new SIP Profile
Step 5. Create a new Partition
Step 6. Create a new Calling Search Space (CSS):
![]() |
Step 7. Create a new SIP trunk, Trunk1:
Device Name | Enter a name for the SIP Trunk, Trunk1 |
Run On All Active Unified CM Nodes | Checked |
Destination Address | Enter the IP of the CUCM server itself, for example 10.48.36.50 |
Destination Port | Enter the port on which Trunk2 listens on, 5041 |
SIP Trunk Security Profile | Select the Profile created in step 1, Trunk1 non secure receiving on 5040 |
SIP Profile | Select the profile created in step 4, No active control telepresence conferencing |
DTMF Signaling Method | Select RFC 2833 |
SIP Normalization script |
Select the script created in step 3, remove_conference_from_call_info_header |
![]() |
Step 8. Create a new SIP trunk, Trunk2:
Device Name | Enter a name for the SIP Trunk, Trunk2 |
Run On All Active Unified CM Nodes | Checked |
Calling Search Space | Select the CSS created in step 6, CMS_adhoc_numbers |
Destination Address | Enter the IP address or FQDN of the CUCM server itself, for example 10.48.36.50 |
Destination Port | Enter the port on which Trunk1 listens on, 5040 |
SIP Trunk Security Profile | Select the Profile created in step 2, Trunk2 non secure receiving on 5041 |
SIP Profile | Select the profile created in step 4, No active control telepresence conferencing |
DTMF Signaling Method | Select RFC 2833 |
SIP Normalization script |
Select the existing normalization script cisco-meeting-server-interop |
![]() |
Step 9. Create a new Route Pattern
![]() |
![]() |
![]() |
Step 10. Modify the CMS adhoc Conference Bridge configuration
![]() |
![]() |
![]() |
Step 11. Reset SIP trunks Trunk1 and Trunk2
Step 12. Reset CMS adhoc servers
Use this section in order to confirm that your configuration works properly.
![]() |
![]() |
![]() |
![]() |
There is currently no specific troubleshooting information available for this configuration.
You can use the Collaboration Solutions Analyser tool for log analysis.