Tag Archives: CMS

Apr 28

Active Control and Cisco Meeting Server – Mute

Posted on by

Cisco Meeting Server provides a more feature rich conference environment with Active Control enabled. Not only the does the CMS Server need the SipUDT flag enabled (enabled by default), the Call Leg Profiles needs to have the feature enabled, the codecs need meet firmware versioning minimums and have the Active Control flag set to Auto as well as CUCM will need to have the relevant SIP Profiles sending the Xi Parameter for Devices and Trunks. Tracing Active Control is done via SIP and Active Control XCCP Packets, I’ve outlined below some key components to tracing Active Control Features. Below is an example of the Codec Muting and Unmuting itself. The unmuting will reflect the change in the rxAudioMute flag on the CMS Server, which is turn reflects the Microphone Unmuting in the CMM Management Screen. Also, worth to note, the below output is also based on ‘Linked’ Mute Behaviour as opposed to ‘Separate’ Mute Behaviour.

Scenario:

  • Multiple Call Bridges in a single Call Bridge Group with Load Balance enabled
  • Cisco SX20 Codec operating 9.15.X firmware.
  • Call Bridge version is 3.2.1
  • CUCM version 14 SU2
  • Direct routing between CUCM and CMS
  • Call Leg Profile is set as below
    • rxAudioMute = True (Mute on entry)
    • muteSelfAllowed = True (Allow Codec to unmute/mute as required)

Call Flow:

Codec -> CUCM -> CMS -> CMS

Codec dials into Space directly, CUCM sends a Delayed Offer to the landing point is which is CMS01. Load Balancing is then conducted, CMS02 Call Bridge is voted to host the conference. CMS02 then places an outgoing call to the Codec, hence sends a SIP INVITE to the CUCM. CMS01, will CANCEL the original SIP INVITE from the Codec/CUCM.

So, the within the SDP, there should be a couple of attributes to the tune of..
m=application 30419 UDP/UDT/IX *
a=ixmap:0 ping
a=ixmap:2 xccp

This is the Active Control negotiation within the SDP. If these lines are not present, then CMS is not enabled for Active Control. Vise versa.. If CUCM sends the 200 OK SIP Msg without the above attributes, then CUCM Sip Profiles do not have Active Control configured.

Active Control Tracing on the CMS will not show the Active Control State of the call via the b following line ‘ActiveControlState change, unknown -> negotiating’.

<?xml version=”1.0″ encoding=”UTF-8″?>\n
TX: <request type=”subscribe-capabilities” id=”1″>\n
TX: <subscribe-capabilities min-interval=”5″>\n
TX: <expires>1800</expires>\n
TX: </subscribe-capabilities>\n
TX: </request>\n
call 4942: need to start new conferencing link for XCCP
call 4942: starting up conferencing link for XCCP
call 4942: starting up conferencing link user for XCCP
call 4942: incoming XCCP message, size 197:
RX: <?xml version=”1.0″ encoding=”UTF-8″?>\n

Active Control Feature and Capabilities will now be negotiated between the CMS Call Bridge and the Codec.

CMS Call bridge will not set the feature capabilities upon the Codec. Below snippet is the Call Leg Parameter ‘rxAudioMute’ being pushed down to the Codec. (Also, within this same xml msg, the parameter ‘rxVideoMute’ is also pushed down to the Codc)

call 4942: outgoing XCCP message, size 684:
TX: <?xml version=”1.0″ encoding=”UTF-8″?>\n
TX: <notify type=”acked-self-info” notifyId=”4″>\n
TX: <self-info>\n
TX: <user id=”e0d5c105-5b68-44bd-85a6-3c3b2f23a749″ entity=”91021@justice.nsw.gov.au”>\n
TX: <display-text>SYD-DOWN-MULTIMEDIA-MR1- 91021</display-text>\n
TX: <recording>false</recording>\n
TX: <deactivated>false</deactivated>\n
TX: <endpoint entity=”91021@justice.nsw.gov.au”>\n
TX: <status>connected</status>\n
TX: <joining-method>dialed-out</joining-method>\n
TX: <capture-source-id>19416111</capture-source-id>\n
TX: <media id=”1″>\n
TX: <type>audio</type>\n
TX: <status>recvonly</status>\n
TX: </media>\n
TX: <media id=”2″>\n
TX: <type>video</type>\n
TX: <status>recvonly</status>\n
TX: </media>\n
TX: </endpoint>\n
TX: </user>\n
TX: <count>\n
TX: <visible>0</visible>\n
TX: </count>\n
TX: </self-info>\n
TX: </notify>\n

At this point, the Codec has successfully joined the Conference, the Call Bridge has set the relevant features upon the Codec. The Codec has been Muted both Audio and Video.

The Meeting Room Operator, can now press the Mute Button on either the Touch 10 or an external Microphone to unmute the Codec.  Below is snippet for the XML Msg sent to the Call Bridge from the Codec.

call 4942: incoming XCCP message, size 225:
RX: <?xml version=”1.0″ encoding=”UTF-8″?>\n
RX: <request type=”self-mute” id=”7″>\n
RX:   <self-mute>\n
RX:     <endpoint entity=”91021@justice.nsw.gov.au”>\n
RX:       <media id=”1″ media-allowed=”sendrecv”/>\n
RX:     </endpoint>\n
RX:   </self-mute>\n
RX: </request>\n

The Call Leg parameter ‘rxAudioMute’ is not set to false and the CMM Server will indicate the Mute is now off from the Codec.

Further Notes to Muting/Unmuting behaviour with Active Control. The CMM Server cannot unmute the Codec. If you attempt to unmute via CMM Console, the microphone icon will switch off for a couple of seconds, then switch back on indicating the microphone is muted again.

Nov 01

Cisco Meeting Server – Part 8: Call Bridge Groups

Posted on by

Call Bridge groups allows call bridges that are clustered to load balance in/outgoing calls, apply the smarts behind load sharing resources. We then link services or functions to the Call Bridge Groups. (as seen is later steps)

1. Using the an API Tool like POSTMAN, create a Call Bridge Group, and store the Call Bridge Group ID somewhere on your PC for later use. The command to use is POST https://172.18.27.24:445/api/v1/callbridgegroups.
2. Collect the Call Bridge IDs that will be members of the Call Bridge Group using the GET cmd.

cms-cbg-1

3. Modify the Call Bridges to add the Call Bridge Group ID

PUT -> api/v1/callbridges/call_bridge_id/
BODY – > callBridgeGroup = call_bridge_group_id

cms-cbg-2

4. Next we enable load balancing for the Call Bridge Group.

PUT -> api/v1/callbridgegroups/callbridgegroup_id
BODY -> loadbalancingEnabled = true
BODY -> loadbalancOutgoingCalls = true

cms-cbg-3

Oct 20

Cisco Meeting Server – Part 7: Call Bridge Cluster

Posted on by

Call Bridges operate as a single entity when clustered, scaling available resources. A prerequisite is to have a fully configured and functioning Database cluster. (Read PART 5 of this blog series).

Two cluster types exist. Peer to peer and via Call Control. Most efficient method is Peer-to-Peer. Where Call bridges route media directly between themselves and not via a call control server (CUCM).

Steps to Configure a Call Bridge Cluster

1. Log into Web Admin of each Call Bridge CMS Server. Navigate to Configuration -> Cluster. Enter a unique name for the Call Bridge. Eg CMS_01 (must not contain spaces).
2. On the first Call Bridge, go to Configuration -> Cluster and add All Cluster nodes into table using the above Unique Node Names. Do not enter the “Peer Link SIP Domain” field. Also ensure the Address is https://fqdn:445 (webAdmin Port). Ensure this address is DNS resolvable!

cms-cb-cluster-1

Another key factor to this configuration is the dial plan. For inter-peer calls.. (between Call Bridges in a Call bridge Cluster), a route must exist for the IP Address for peer members. There is a required when the “Peer Link SIP Domain” is left blank for the Call bridge Cluster.

*If you do not configure these outbound rules, you will see an error “remote media link to call bridge CALLBRIDGE failed for call”.

The impact will see a single video conference that is split between two CMS Call bridges.. Thus the conference participants will only see other participants on that same Call Bridge Host.

cms-cb-cluster-2

Oct 08

Cisco Meeting Server – Part 6: Call Bridges

Posted on by

Now we move onto creating the call bridges within our CMS Architecture. Call Bridges are the work horses.. These guys mix the media streams for conference participants. We will cluster the call bridges in the next step, for now lets setup the base services for the call bridges.

First is to upload the key an certificate files from the above ‘Certificates’ step via SFTP. I name the cert files for the call bridges “callbridge.key” “callbridge.cer”.

The certificate files will be shared among the call bridge servers.. So be sure to upload to each call bridge.

Select the interface for the Call Bridge to listen on. (Typical deployments will have interface ‘a’ selected)

Commands are:

callbridge listen a
callbridge certs callbridge.key callbridge.cer chain.cer
callbridge restart

cms_callbridge_1

*Repeat all Call Bridges

The base call bridge service has now been setup for each call bridge.

Oct 04

Cisco Meeting Server – Part 5: Database Cluster

Posted on by

As with any cluster, there is a master/slave relationship and there is no difference with CMS DB Clustering. We first need to initialise the DB Master, followed then by connecting all DB slaves. Remember.. The CMS DB Cluster must have an ‘odd’ number of members.. Another note to make about cluster members is the Call Bridge doesn’t have to be operational.. Hence DB Cluster members can be on general/standard VMs with typical resource usage such as CPU and Memory.. No need to allocate huge amounts of resources to DB Cluster members.. One example I can give is to have a 2 node Call Bridge Group configured linking to a 3 node DB Cluster.

Configuration steps starting with the CMS Database Master

Attach certificates to the database cluster.. We have already provides CSRs and have signed certificates from previous steps.

From the console enter:

database cluster certs dbserver.key dbserver.cer dbclient.key dbclient.cer chain.cer
cms_database_1

database cluster localnode a (We are specifying the CMS network interface for the DB to use)

database cluster initialize
cms_database_2

database cluster status
cms_database_3

Now Join each of the Slave Database Servers to the database cluster

Upload via SFTP the below certificate files

- Dbserver.key
- Dbserver.cer
- Dbclient.key
- Dbclient.cer

The above files were generated under the Certificates section. These files will be shared among CMS Servers.

Validate the certificate files on the CMS Server via the ‘pki list’ command
cms_database_4

database cluster certs dbserver.key dbserver.cer dbclient.key dbclient.cer chain.cer
cms_database_5

database cluster localnode a

database cluster join cms_hostname.com.au (this is the DB Master’s hostname)
cms_database_6

Database cluster status
cms_database_7

Repeat for each Slave Database Server. Note: Do not have an equal number of Database Servers in the cluster, must have odd number count. Example Cluster of 3 or 5 not 2 or 4.

Sep 27

Cisco Meeting Server – Part 4: Web Admin Configuration

Posted on by

We are now is a position to start configuring the Core functions of CMS. One of which is the Web Admin to give us access to the GUI.

Ensure, you have copied the webadmin.key from the CMS 1 host to the remaining CMS Hosts. Then also copy the webadmin.cer and chain certificate to all CMS Servers.

From the console enter the below.

webadmin listen a 445 (This allows the 1st Interface to listen of port 445 for the Web Administration portal. We keep this portal off port 443, as we will configure a Web Bridge later for internal webrtc clients.)
webadmin certs keyfile function_certificate cert_bundle (example: webadmin certs webadmin.key webadmin.cer chain.cer
webadmin enable

The CMS server will cross check the Key file matches the Certificate file, and then ensure the Chain Certificate is the actual signing CA Authority.

To validate the webadmin service.. Enter webadmin status.

Now browse to the https://cms1server.example.com.au:445

Sep 20

Cisco Meeting Server – Part 3: Certificates

Posted on by

Certificates are the next step in the CMS deployment. Now with version 2.7+ certificates are mandatory all to be signed by a CA. I’ve listed the functions below that we will generate CSR’s for. A brief description of how to generate the CSR is included. I find it easier to generate all CSRs from a single host, then have the IT Administrator sign all the certificates.. Then I’ll distribute the keys and signed certificates to the appropriate CMS Hosts.

I like to group certificate to functions. Yes, you can just issue a single certificate.. But again, I like to logically separate certificates to functions..

The general command to run is “pki csr function_name CN:cms-host1.example.com subjectAltName:cms-host2.example.com.au,cms-host3.example.com.au

Reboot each CMS Server after licenses have been applied.

Functions

WebAdmin – Standard certificate. I include ALL CMS Servers, including the EDGE (interface a) servers. Use the subjectAltName: attribute for the additional CMS Servers.
Call Bridge – Standard certificate. I will include only the CMS Servers that will host conferences.
Database Server – Standard certificate. I will only include on the CMS Servers that will share the Database.
Database Client – Specific CN for the certificate: CN:postgres Only enter this CN into the CSR. No subjectAltName attribute.
XMPP Server- This certificate will include all CMS Servers that will be a member of the XMPP Cluster. This certificate will also list domains for the organisation, including all domains in a multi-tenancy deployment.
Trunk – Standard certificate. Will include only the CMS Servers that are a member of the XMPP Cluster.
Load Balancing – Standard certificate. I will include only the EDGE servers.

The Chain or Root Certificate

The Cert Bundle is the Trusted Root Certificate. This is required when attaching signed certificates to the various components such as Web Admin. If there is only a single Root CA, then all you need to do is copy the Root CA cert to the CMS Servers via an SFTP client. Then simple reference the cert when activating a component. If there is also an Intermediate CA.. Then you will need to manually create a certificate bundle. To create a certificate bundle, open both the Root CA and the Intermediate CA certificates into notepad. Copy the text of both certificates into a new text file. Root CA text first, then next line add the intermediate certificate text. (no line break), then add a blank (space) line at the end of the file. Save this as a “.cer”. Copy this Root Chain certificate to the CMS Server. Then simply reference the chain certificate when activation components.

I use Filezilla FTP client to upload certificates, download CSRs and keys etc. All certificates, keys etc are loaded into the root directory on each CMS Server.

Run the command pki list to show a list of CSR’s, keys and certificates.

**NOTE: For certificates to be shared among the CMS Servers, copy the cert.key & the certificate to all required CMS Servers.

Sep 12

Cisco Meeting Server – Part 2: Licensing

Posted on by

All CMS Servers require a LIC-CMS-K9 host license. (Top Level SKU is R-CMS-K9). This enables Call Bridge, Web Bridge and TURN Server featurs. This is a zero dollar license from Cisco, that’s right.. You can deploy as many CMS VMs as you like.. However to allow conferencing you will need to purchase SMP+ or PMP+ licenses.

Quick run-down on the two licensing types:

SMP+ is a shared license. This license is invoked for all unknown users/owners that are hosting a conference within the CMS infrastructure.
PMP+ is a Personal Multiparty License. This license is assigned to users within the organisation. When a ‘licensed’ user hosts a meeting instead of a SMP+ license being used, a PMP+ license is granted. PMP+ licenses are included with the CUWL Meetings licensing type. Can be upgraded from CUWL Std or Pro.

How to Apply Licensing to CMS Servers.

Following the same typical process as you would for assigning PAK for the Part LIC-CMS-K9. You will need the MAC Address from the CMS. (cmd is ipv4 a). This will generate a cms.lic file for download. As mentioned above, this license will enable Call Bridge, Web Bridge and Turn Service.

Keeping with the first CMS Server, Next step is to assign the PAK for either SMP+ or PMP+. Exact same process as above. This will generate another cms.lic for you to download.

We can now install this cms.lic via an SFTP Client such as Filezilla. Simply drop the cms.lic file to the root of the CMS Server.

Process for Remaining CMS Servers

Moving onto the second and remaining CMS Servers.

First step is to again assign the Server PAK (Part LIC-CMS-K9) to the second CMS Server, you will need the MAC Address. A cms.lic file will be generated and available for download..

Next step is to share the additional features, in this case it’s the PMP+ / SMP+ licenses between the CMS 1 and CMS2 Server. To do this we navigate to the ‘Licenses’ tab on the Cisco Licensing Portal (traditional). Drop down the ‘Move’ menu and select Share -> Get Activation Code. Paste in the source MAC which is CMS 1′s MAC Address and Destination MAC being the CMS 2 MAC Address. Enter your CCO related email address to receive the activation code. Submit. An activation code will be emailed to the previously mentioned address.

Now we’ll copy this activation code and go back to the ‘Move’ menu and select Share -> Use Activation Code. Past the activation code and submit. The next page will list the additional licenses or feature you wish to share. Select the PMP+ / SMP+ feature and submit. This will generate a new cms.lic for CMS 2 server. Now simply follow the above process to add the license file to the CMS 2 Server via SFTP client.

Repeat the ‘Process for Remaining CMS Server’ for any additional CMS Servers.

Call Bridge Server with features (SMP+ and PMP+)
cms_license_1

Sep 04

Cisco Meeting Server – Part 1: Base Settings

Posted on by

I’ll be going through a scalable and resilient deployment in parts, as there is simply too much to get through in a single post. Some will also be applicable to single deployments. The CMS design is using three CMS Call Bridges and Expressway as the reverse proxy and video path. I will not be deploying an Edge Server in this design.. However, I’ll add on the Edge configuration after the blog series, as the CMA App still requires this infrastructure.

Start Virtual Server from VMWare, then log into CMS as username: admin and password: admin. The system will have you change the password. Select a secure password and confirm. We now have access to the console. Lets configure some basic connectivity and system settings.

Add IP Address to Interface ‘a’ – ipv4 a add ipaddress/prefix gateway_ipaddress
Add DNS Servers – dns add forwardzone . dns_server_ipaddress **The dot represents ALL Domains.
Add NTP Servers – ntp server add ntp_server_ipaddress
Add Hostname (Reboot required) – hostname name_of_CMS (exclude the domain suffix)
Add Timezone (Reboot required) – timezone Australia/Sydney. (timezone list, shows you all the Timezones available to use if you’re not in Aussie Land)

To validate above settings run the below commands

Validate IP Address and Gateway -> ipv4 a
Validate DNS server and forward zone -> dns
Validate NTP server and sync -> ntp status
Validate Timezone -> timezone

**Note**

CMS passwords expire after 6 months by default. Hence, I also like to set the password age to the max 9999. Below is how to achieve this.

Firstly display the current password age/expiry

>user info admin

Configure the new password age rule (global)

>user rule password_age 9999

We then have to reset the admin username’s password for the password age rule to take effect.

>passwd admin
>ENTER THE PASSWORD FOR THE ADMIN ACCOUNT

Confirm the password age for the admin account

>user info admin

Sep 24

Cisco Meeting Server – CMA ‘Copy Weblink’

Posted on by

You might be wondering where the Copy Weblink is in the CMA Invite Menu, or why can’t participants just click on my ‘join’ weblink and be connected straight into my meeting room.

Simple explanation.. The ‘Web Bridge URI’ field on the WEB Admin GUI is blank. That’s it.. However, for you Multi-Tenancy deployments.. Unfortunately there is a limitation! Only one URL can be defined, as this setting is required to be done via the WEB Admin GUI.

In a multi-tenancy case, users will have to forgo this ‘Copy Weblink’ etc and simply have the ‘https://join.tenant_domain.com.au’ listed in the invite, requiring participants to enter the Meeting ID to connect into a meeting room

cms-web-link-1