Sep 14

TMS Repeatedly Dialling PSTN Numbers with CMS

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

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

Aug 15

Troubleshooting CMS Webrtc Connections – Incorrect Username/Password

cms-webrtc-tshoot1

You receive this error when you attempt to log into your personal space via the “Sign in” button and also when you attempt to join a meeting as a Guest.

The XMPP Server is guy who will authentication users, whether they be local domain users or guest users.

With Guest users. The web bridge sends the call bridge instructions to create a temp guest user account, the call bridge creates this account, then send the web bridge the username/password details.. The Web bridge, then will contact the XMPP Cluster to verify authentication for the newly created guest user.. As you can see below capturing packets on the EDGE device.. The port TCP 5222 is being blocked toward the XMPP Cluster.

Cisco Document references the below ports only.

cms-webrtc-tshoot2

cms-webrtc-tshoot3

cms-webrtc-tshoot4

Aug 04

Cisco Meeting Server – LDAP Discussion

Crikey.. All these API commands, recently have been doing a couple of CMS deployments.. And literally have to jot down my most used commands.. aswell as most used IDs.. Can be very tedious to configure then look back at what you have configured!

Thought I would jot down here the commands I most use.. More for my memory as I know more deployments will come my way.. And rather than cross referencing the API continuously.. well you get my drift..

LDAP is a killer.. Customers always seem to create their own variation of standardised ldap fields.. I reckon its just to keep guys like us on our toes..

LDAP API Commands

GET: /ldapservers – displays all ldapservers to go deeper, copy the ldapserver ID and paste it to the end of the above API string.. This will now show all fields for that ldap server connection. Note: you best copy this server ID somewhere safe, as you’ll need it later.

GET: /ldapmappings – this seems never ending when first trying to sync to an organisation’s LDAP..fields most used are , this is the authentication mapping. ie username for the CMA/webrtc client. REMEMBER to configure the XMPP Domain on the CMS and to create a _xmpp-client._tcp.domain 5222 SRV record.

GET: /ldapsources – if you thought ldapmappings was never ending.. you’ll quickly get used punching this little bugger in.. Main culprit is the filter field to ensure you’re only bring across the users required.. One organisation can have multiple ldapsources dependind on what userprofiles are to be assigned to users.

POST: /ldapsyncs – Yes finally we sync to LDAP.. You may need to enter this string a million times over before all the above settings are finalised and users have been successfully imported.. And then.. You’ll enter this string another million times for changes that need to be made..

*Handy Tip*
To remove LDAP users.. Simply delete the ldapsource, then run the POST: /ldapsyncs again…

Ok so what do the fields mean..

Ldapserver

<address> = the ldap server IP Address
<port> = port used to connect to ldap. Mainly 389 but can use 3268 if need be.
<username> = This is the service account used to access ldap user records. This must be in a CN path format. Eg. CN=service_user,OU=IT,DC=domain,DC=com
<password> = Password for the service account.. NOTE: this field does not show when running a GET: /ldapserver.
<secure> = whether you want a TLS Ldap connection or leave unsecure.

LdapMapping

<jidMapping> = This is the authentication string for users. The @domain MUST match one of your XMPP Domains configured. Example format is $sAMAccountName$@meet.domain.com.au NOTE: you can also insert any AD attribute here if the sAMAccountName is not to your liking. I like to try and the organisation’s email prefix as a standard.. So sometimes I will use $mailNickname$@meet.domain.com
<nameMapping> = This displays a friendly name for the user in the CMS System. Typically used is $giveName$ $sn$
<coSpaceNameMapping> = This is the display name for the user’s meeting space. Typically used is $givenName$ $sn$’s Meeting Space
<coSpaceUriMapping> = This is the meeting space’s URI prefix. IMPORTANT: This cannot be the same as the <jidMapping> prefix. So typically the URI would be $mailNickname$.space or $sAMAccountName$.space. Get the picture.. append a “.space”.
<coSpaceCallIdMapping> = This is the Meeting Room Number. This code is entered in when someone joins via an IVR or the Weblink. If you do not complete this field.. The CMS system will automatically generate a Call ID for you. NOTE: This field MUST be unique across the organisation AND… across ALL tenants configured on the system. If you can get away with using an extension number and all ldap accounts have a unique extension number (highly unlikely) use this.. Easy for the user to remember.. BUT as with most case.. A system generated Call ID is your only option.

LdapSource

This is where we tie everything together to essentially create profile for the ldap sync.
<server> = This is the ldapserver ID from previous steps.. Paste it in here
<mapping> = this is the ldapmapping ID from previous steps.. Paste it in here
<tenant> = if you are configuring multi-tenancy.. Well paste the tenant ID in here.
<baseDn> = This is the base ldap search path.. ALL users must be within this path. This doesn’t mean you want to import all users in the path.. That is what the “filter” is for.. Example is OU=Users,DC=domain,DC=com
<filter> = This how we specify ‘who’ exactly we want to import. Maybe its just an OU? Maybe its only members of a particular security group. Or only users with a telephone number.. You get my drift.. A couple of examples

Member of Group called ‘CMS’ = memberof=cn=CMS,ou=security,ou=groups,dc=domain,dc=com
Member of Group called ‘CMS’ AND have a mailNickname AND Telephone configured = (&(mailNickname=*)(telephoneNumber=*)(memberof=cn=CMS,ou=security,ou=groups,dc=domain,dc=com))
Users who have a Telephone Number, but who are not a member of the security Group called ‘CMS’ = (&(telephoneNumber=*)(!(memberof=cn=CMS,ou=security,ou=groups,dc=domain,dc=com)))

Why would we need to exclude a Group for? Maybe we only want to attach a PMP+ license to a specific Security Group? And the remaining users to share SMP+ licenses. In this case we would create TWO ldapsources.. One ldapsource with a filter matching all users but excludes users in a security group. Then the other ldapsource to filter only users in the security group. On this ldapsource we will also attach a ‘userProfile’. A userProfile allow us to apply a PMP+ license to users.
<userProfile> = Paste in the userProfile ID. (create a userProfile and attach the ‘haslicense’ to the profile)

LdapSyncs
We POST to this string.. With no Body everytime we want to sync to ldap.. At this stage there is no schedule we can apply. The option is to create a python script to run the ldapsync on a schedule.. I’ll leave that up to you. But, please post any scripts here for others to use or improve on.

Jul 15

Cisco CMS Ad-Hoc Conferencing with CUCM

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

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

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