Tag Archives: Cisco Meeting Server

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

Sep 14

TMS Repeatedly Dialling PSTN Numbers with CMS

Posted on by

Has a very interesting problem with TMS and CMS integration piece. For any TMS meeting scheduled with dial out participants when the participant phone number had a zero prefix (Australian Standard for PSTN breakout), the TMS / CMS system would repeatedly dial the participant, even though the participant had already accepted the first TMS/CMS call out and had successfully joined the meeting.

This only occurred for phone numbers with a zero prefix. Hence phone number with +61 formation, or the straight 10 digit (again based in Australia).

Explanation

In CMS I have configured for user to dial a phone number using any standard means.. Straight 10-digit number, prefix with zero, plus e164 format, extension etc.. So catching all of the users dialling behaviours and making sure they route.. I transformed all of the above different dialling behaviours to a standard plus e164 format.. So essentially globalising the dialled number.

Any number leaving CMS is in a plus e164 format. Easy for the CUCM guys to manage routes.

TMS dialled number was in a zero prefix format. Example 00408842… so worries… TMS would make an API call to CMS to create a callleg for the above number. CMS would transform the number into a plus e164 number. So the number would become +61408842… CMS would route this to CUCM for PSTN breakout. CUCM would then localise the number into a compliant Telco format. The number now became 0408842…

The call would be dialled.. The participant would answer and be joined the CMS Meeting.. All good you say.. Well not quite yet.. While CMS had confirmed that indeed the participant had joined the meeting.. TMS never received such confirmation..

After CMS dials out to the participant, TMS will then send a GET request to CMS asking if a Call Leg has been established for the participant dialled. To break this down TMS sends a GET /api/v1/callLeg filter with 00408842… (notice this is the number TMS sent to CMS to be dialled originally). However.. CMS has no such Call Leg… TMS, then resends a POST request to CMS to create a Call Leg for the 00408842… so CMS the dials out to the participant again. The participant receives another call, even though they are already in the meeting!

This happens multiple times until TMS gives up.. (configurable).

Why is this So?

CMS contains a couple of key pieces of information in the Call Leg.

1. RemoteParty
2. OrginalRemoteParty

Remote Party is the connected Called Party ID. Remember how I was saying CUCM (or the CUBE) will localise the called number to comply with Telco Standards.. The CUCM (or CUBE) will send back the connected called ID to CMS.. This is then documented for the RemoteParty ID.

Original Remote Party ID is the dialled number from CMS to CUCM. Essentially this is the ‘Transformed’ number.

Following my case above.. The CMS Call Leg will have the below

remoteParty = 0408842…
orginalRemoteParty = +61408842…

By now, you’re probably putting the puzzle together.. The number TMS requested to be dialled is no where to be seen in the Call Leg, hence TMS believes the participant did not join the meeting (based in the results of the GET callLeg request by TMS), so TMS attempts a redial.

The Fix (for now)

To resolve this issue, allow the dialled number from TMS to be passed through CMS without transformation onto the CUCM Server. This reflects in the Original Remote Party field as being the number that TMS dialled.. Hence the GET request for TMS matches the dialled number.

Sep 05

Saving WAV Files for Cisco Meeting Server with Audacity

Posted on by

With audacity you can modify WAV files for the Cisco Meeting Server.. The important notes are the file must be under 500KB and be saved with ‘WAV (Microsoft)’ as type and Encoding to be Signed 16-bit PCM.

One important note to make aswell in regards to the wav file ‘only_participant.wav’. Cisco CMS will repeat this message continuously with no breaks for AUDIO ONLY callers. The default ‘only_participant.wav’ file is padded with 10 seconds silence. So…. We also need to pad the WAV file for 10 seconds.. (more if you like), otherwise audio callers will be driven crazy waiting for someone else to join the conference.. Again.. This only impacts audio only callers.. Video callers only hear this announcement once.

cms-wav-files

Jul 15

Cisco CMS Ad-Hoc Conferencing with CUCM

Posted on by

For those interested.. A short article of configuring CMS as an Ad-Hoc Conference resource in CUCM.

NOTE: prior to CUCM 11.5 SU3 TLS used is version 1.0. CMS 2.3+ uses TLS 1.2 by default, so to allow pre 11.5 CUCM versions to connect to CMS.. We need to set the minimum TLS version via MMP.

Commands are:

tls webadmin min-tls-version 1.0
tls sip min-tls-version 1.0

For CUCM to use CMS as an Ad-Hoc conference bridge we need to configure a user on CMS with the API role associated. CUCM essentially creates a temp conference space for the ad-hoc conferences.. CUCM does this via HTTPS using API strings.

Commands to configure a User on CMS

User add username api
The MMP console will ask you to set a password.

Lets remain on CMS, and log into the Web Admin portal. We now need to configure Incoming Call Settings. This will allow calls to enter and terminate on the CMS Server. CUCM will add the SIP Trunk Destination Address as the suffix/domain to all calls for ad-hoc conferences. So we need to configure the SIP Trunk Destination Address into the Incoming Call Handling page on CMS.

Incoming Call Settings

cms-ad-hoc-2

Now we turn to the CUCM Server. First step is to upload the certificate chain that signed the ‘Web Admin’ service certificate to the CUCM as CallManager-trust.To find out which trust certificate to use you can jump back on the MMP for CMS and run the command ‘webadmin’ and look for the ‘CA Bundle File’. Jump into your SFTP client and download the CA file to you PC.. ready for upload to the CUCM Server.

Once uploaded, navigate to Media Resources and Conference Bridge and select ‘Add new’.

Complete the following fields on the conference bridge configuration page.

Conference Bridge Name = Nothing special here.. Just assign a logical name for the conference bridge.
Description = Again.. Something logical always helps
Conference Bridge Prefix = If you have multiple CUCM Clusters linked to CMS or multiple CMS Call Bridges, you will need to apply a prefix. This mitigates the risk of two CUCM Servers from two difference clusters creating a temp ad-hoc conference with the same conference ID. If there are two Call Bridges, you must then create a conference bridge resource for each with a different prefix. This will assist with load balancing issues (Load balancing across two or more Call Bridges is not supported in the Ad-Hoc Conferencing setup).
SIP Trunk = Select the CMS SIP Trunk, which will also be referenced below.
Override SIP Trunk Destination as HTTP Address = checked.
Hostname/IP Address = FQDN of your CMS Server..
Username = enter the username create in the above steps
Password = self explanatory..
Use HTTPS = checked.
HTTP Port = This is the port you have configured for the Web Admin Server.. I use 445 in this case, default is 443.

Save, then we reset the bridge. Should now show as registered. You can add the Conference Bridge to your select MRGs and MRGLs for testing.

cms-ad-hoc-3

cms-ad-hoc-4

Jun 24

Cisco CMS Upgrade – Resilient Split Deployment

Posted on by

Just a quick blurb on upgrading this CMS beast.. the key is to backup configs, certificates and license files.. if you do that.. you can easily restore if all goes bums up!

Step 1a. is take a Manual Backup, I say manual as the guide recommended not to rely on on the automated backup that the system uses once the upgrade kicks off.. I like to errr on the side of safety and peace of mind.. so take a separate manual backup.
Step 1b. Download the backup file to your local PC Drive..
Step 2. While you on the SFTP/FTP Client.. copy the cms.lic file to your PC Drive
Step 3. Now copy all… ALL certificates, Certificate Chains and Certificate Keys to your PC Drive..
Step 4. Download the upgrade ZIP from Cisco.com. Extract to your SFTP Directory ready for upload.
Step 5. Upload the extracted content (upgrade.img) to the root directory of all CMS Servers.

Before we go any further, for a resilient deployment, we should be upgrading slaves first, the the master. We need to ensure the Database cluster is in-sync before we proceed with any upgrade.

Step 6. Check database status and confirm which CMS Server is the current DB Master. > database cluster status

Step 7. NOW jump onto the MMP and run the upgrade starting with the slave Database cluster servers.. command is “upgrade upgrade.img no-backup”

cms-upgrade-1

Wait until each CMS Server has rebooted and connected back into the database cluster (> database cluster status) before proceeding to upgrade the next CMS Server. Repeat until all CMS Servers have been upgrade (with the Master being the last node to be upgraded).

Step 8. Once we have upgraded all CMS Server and the database cluster is again in-sync we can progress to updating the database schema (if required by the upgrade version).

Log into the Database Master CMS Node, and run the database cluster upgrade_schema.

Check the upgrade with > database cluster status. Enable = success.

Confirmation Checks

Command is “version”

cms-upgrade-2

Then validate the cms.lic, certificate keys etc are still residing on the CMS Server. Fingers Crossed! (seriously.. all should be good)

Commands to use:

“pki list” to display keys and certificates.
“license” to display active licensing

If something is missing.. simply upload required files from your PC Drive..

cms-upgrade-3

Just a screen shot to show validation from the Web Admin portal

cms-upgrade-4

Jun 14

Cisco Meeting Server Displaying Reconnecting for the Web Admin

Posted on by

Deploying a cluster of CMS servers, I had one host that didn’t want to play the game. After enabling the Web Admin service for port 445 I could not reach the Web Admin portal. The CMS Server just sat at “Reconnecting”.

I changed the Web Admin port back to 445. No Luck
I tried both Chrome, IE and Firewfox browsers. No Luck
I used both IP Address and CN Name to access the Web Admin. No Luck.

Version was 2.1.5 (the version Cisco ships with CMS as of June 2018).

I proceeded to download the latest CMS Server version which is 2.3.4 (31st May Release Date). I upgraded the CMS Server, change the Web Admin port back to 445 and I can now access the Web Admin portal.

Not too sure why I only had this issue on this one CMS Server.. I had deployed 4x CMS Server exact same version same hardware.

Webadmin status command output.
webadmin status - cms