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:
- 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.
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
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>
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:
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
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:
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)
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>
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.
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.
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 email@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
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.
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.
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
Encryption: Auto or Unencrypted
Click Add New to save the changes.
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:
Fill External Access field if you want to add Cisco Expressway web proxy. This address will be used in invites for external users.
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.
Then select CallManager, so CMS and CUCM will check each other’s certificates for Conference Bridge registration.
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).
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.
Some SIP providers prefer to work with INVITE field, while CISCO CUBE traditionally works with From: and To: fields.
Let’s take MSN provider as an example.
An incoming call header looks like this:
Cisco translation-profile and translation-rule can only operate with numbers, and the complex header in To: field complicates the situation.
You can use sip-profiles to copy the number from INVITE field to To: field.
The structure should be the following:
voice service voip
voice class sip-profiles 10
request INVITE sip-header SIP-Req-URI copy "sip:(.*)@" u01
request INVITE sip-header To modify ".*@(.*)" "To:
rule 1 /^48879800$/ /1401/
voice translation-rule 20
rule 1 /^8\(..........$\)/ /+7\1/
voice translation-profile ITSP_Incoming
translate calling 20
translate called 10
dial-peer voice 1 voip
description incoming from MCN-1
translation-profile incoming ITSP_Incoming
session protocol sipv2
session target sip-server
incoming called-number 48879800
voice-class codec 1
voice-class sip profiles 10 inbound
voice-class sip bind control source-interface GigabitEthernet0/0/0.300
voice-class sip bind media source-interface GigabitEthernet0/0/0.300
dtmf-relay rtp-nte digit-drop
dial-peer voice 500115 voip
description To CUCM
session protocol sipv2
session target ipv4:10.7.20.251
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/1.200
voice-class sip bind media source-interface GigabitEthernet0/0/1.200
dtmf-relay rtp-nte digit-drop
ip qos dscp cs3 signaling
Then the number 48879800 can be sent to CUCM.
In the end, the call will look like this:
If you have UCCX (Cisco Unified Contact Center Express) premium license, one of the best features is possible integration and requests to database. These requests can use any information provided by the caller, or the caller’s number, etc.
It’s very important to create a reasonable initial script design and to take the server load into account. Big and heavy scripts with many database handles increase the load greatly. If the DB is on a remote server and there is a net lag, it may influence your business and the calling client's loyalty.
CISCO UNIFIED CCX SCRIPT EDITOR Review
There is a special tool in UCCX to create and manage IVR scripts: Cisco Unified CCX Editor. Here you can manage visual blocks responsible for this or that action. It looks like this:
Let’s look at the Database section. It has 4 items:
- DB Get – map the data from DB to the script variables;
- DB Read – connect to the server and send a request;
- DB Release – close the connection with DB;
- DB Write – use Write method if changes in DB are required;
On the screenshot above, you can see that each script begins with Start event and ends with End event. As the script is being executed during a call, we can perform as many DB requests as we need. Each request has its own sequence of steps that are listed above.
We recommend you to test all SQL requests, access to the system and other factors before releasing to the enterprise environment.
As an example, let's look into DB Read block:
These fields are available for configuration:
- DB Resource Name – marker of the request;
- Data Source Name – data source specified in UCCX console (Cisco Unified CCX Administration Database);
- Timeout (in sec) – request execution timeout. This timeout protects your system from database disconnection. If you set it to 0, the request won’t have any time limitations;
Now proceed from General tab to Field Selection:
- Write the SQL request you want to execute. For example: SELECT fld1, fld2 from tbl where fld1 = $variable – select two fields from the table, where the first field’s value is equal to a variable that we have initialized earlier in our script.
- Test (button) – click this button to check the request syntax and the database connection;
- Number of rows returned – number or rows returned by the request after the Test button was clicked;
- Show all fields (select table/view) – show all fields of the used tables;
Now let’s look into DB Get block:
- DB Resource Name – label or name of this request;
- Data Source Name – database name (configured in Cisco Unified CCX Administration panel);
- Refresh Database Schema (button) – click this button to load database data and tables to CCX Editor;
Proceed to Field Selection tab:
- Table/View – name of the DB table that was selected on General tab (see above);
- Table fields:
- Field Name – field name in the selected table;
- Data Type – data type (string/number, etc.);
- Local Variable – script variable that will store the corresponding field value;
- Add/Modify (buttons) – buttons responsible for field modification (except for data type, which is read-only);
The obtained data can be used in the script, for example, to vocalize (using TTS) the client’s phone number or the entered digits (e.g. order number).
- old-school 7900 series,
- intermediate 6900, 8900 and 9900 models,
- newly introduced 7800 and 8800 IP phones,
- finally some experiments like 3905, Android-based DX650 etc
So these times are over.
For the past couple of year Cisco step by step cleaned up the IP phones portfolio: In Cisco Unified Communications Manager 11.5 they deprecated 7902, 7905, 7910, 7912, 7920, Conference Station 7935.
The following models were deprecated in Cisco UCM 12 - wireless IP Phone 7921, 7970 and 7971.
And now the MAJOR CLEANUP is coming with Cisco Unified Communications Manager, Release 14 affecting CUCM 14, Cisco BE 6000 / 7000.
Just take a look. The phone models to be deprecated in Release 14 are:
- Cisco Unified SIP Phone 3911
- Cisco Unified SIP Phone 3951
- Cisco Unified IP Phone 6911
- Cisco Unified IP Phone 6921
- Cisco Unified IP Phone 6941
- Cisco Unified IP Phone 6945
- Cisco Unified IP Phone 6961
- Cisco Unified IP Phone 7906G
- Cisco Unified IP Phone 7911G
- Cisco Unified Wireless IP Phone 7925
- Cisco Unified Wireless IP Phone 7925G-EX
- Cisco Unified Wireless IP Phone 7926
- Cisco Unified IP Phone 7931
- Cisco Unified IP Conference Station 7936
- Cisco Unified IP Conference Station 7937G
- Cisco Unified IP Phone 7940
- Cisco Unified IP Phone 7941
- Cisco Unified IP Phone 7960
- Cisco Unified IP Phone 7961
- Cisco Unified IP Phone 7985
- Cisco Unified IP Phone 8941
If you are using any of these phone models and you upgrade to Release 14, you will not be able to use these phones after the upgrade.
After you switch over to CUCM 14, registration of these phone models will be blocked.
So, better check the phones you use and plan the migration to 7800 and 8800 series in advance.
Yes, CUCM can collect CDR (Call Detail Record). This article will show you how to enable this feature (disabled by default).
Open Cisco Unified CM Administration interface:
Proceed to System → Service Parameters and select the following parameters:
- Server — select the node to be manipulated,
- Service — select Cisco CallManager (Active).
In the Parameters section that appears, find System and select:
- CDR Enabled Flag * — True. This parameter indicates the call manager to create and store CDR records for each call passing through this UCM;
- CDR Log Calls with Zero Duration Flag * — True. Enabling this parameter makes the server save the unsuccessful calls and calls that were shorter than 1 second (helpful for troubleshooting).
Don’t forget to apply the changes. Repeat this actions for each node in a cluster (if you have more than one server in System → Service Parameters → Server menu).
Now let’s explore advanced parameters. On the configuration toolbar, click Advanced:
Select the following options:
- Call Diagnostics Enabled – Enabled Only When CDR Enabled Flag is True. This parameter switches on so-called Call Management Records (CMR), which are very helpful for troubleshooting;
- Display FAC in CDR – True. This parameter indicates whether Forced Authorization Code (FAC) should be displayed in CDR. Generally, this parameter depends on your security policies. We chose to display it;
- Show Line Group Member DN in finalCalledPartyNumber CDR Field – True. Briefly, this parameter shows DN (directory number) of the group member that answered a call, instead of the group’s number;
- Show Line Group Member Non Masked DN in finalCalledPartyNumber CDR Field – basically, the same as the previous one.
Open Cisco Unified Serviceability page, proceed to Tools → CDR Analysis and Reporting section. Now you can select CDR tab to use Search or export the data. Enjoy!