Let’s Cook: SRTP!!!

SRTP (Secure Real-Time protocol), as the name suggests, is a secure RTP, or in simple terms, encrypted RTP. SRTP can be implemented in both CUCM or CME environments. There are a lot of things involved which we need to prepare before going forward. The goal of this post is to provide an understanding of implementing this protocol, but it cannot be considered as a complete guide because there is so much information that cannot be summarized in a single blog. This post will be focused on implementing the SRTP functionality in a CUCM environment.




There are multiple things to consider, so we will take a look at all of them one by one.


If we have ever downloaded a full ISO image of CUCM from Cisco, we must have seen two images of every version released. These are categorized as:


  • (a) Restricted (includes full encryption capabilities | export restricted outside U.S.)
  • (b) Un-restricted (includes fewer encryption capabilities | can be exported outside U.S.)


We need the restricted version image to deploy SRTP in a CUCM environment as it contains all encryption capabilities. We can convert or upgrade an existing cluster from restricted to un-restricted, but the opposite is not possible. The cost & license procedure is all the same for both.




Two Types of Security Modes in CUCM Cluster:


  1. Non-Secure Mode: as the name suggests, there is almost no security with this mode, and it is enabled by default.
  2. Mixed Mode: This mode can work as non-secure + secure mode; I think that’s why it’s called mixed mode.


When We install CUCM, the default mode is always non-secure mode, which means no signalling & media encryption is enabled. We need to convert the cluster security mode from non-secure to mixed mode. As the name suggests, mixed mode supports both non-secure as well as secure (encryption) modes via the phone security profile.


Navigate to CUCM Admin Page > System > Enterprise Parameters and verify whether the cluster was set to mixed mode (a value of 1 indicates mixed mode):


Non-Secure Mode:


N-S M.png


Secure Mode:




There are two ways to change cluster security to mixed mode:


  1. Use USB security tokens & install the CTL plugin on the machine (PC). USB tokens contain the private key to sign the CUCM certificates. We need to buy secure USB tokens for this procedure.
  2. Token-less CTL method. {it was introduced since Version 10.0(1) of CUCM}


We will focus on the second method for now, as it does not require any cost involvement (:P) and it’s the best choice if we want to test this feature in a lab environment. The token-less method will use self-signing process instead of signing the certificates via USB security tokens.


Note: Before singing the certificates make sure all information in the certificates is correct. Most information in the certificates is taken from information provided during CUCM installation.


If We want to modify or correct the information, then...


Go to: System -> Security -> Certificate


Click on the desired certificate to edit the information. We can also see which CUCM service the particular certificate is associated with.


We can also check all the certificates self-signed/ca-signed in CUCM OS Administration. It will also show the expiration date of certificates.


CUCM -> OS Administration -> Security -> Certificate Management


There are lots of things to discuss about certificates which cannot be done in this post as of now.


Note: We must be aware of what we are about to do. Try to keep a backup in case anything goes wrong.


Implementation or Configuration:


Let’s take a walk towards the implementation process. We are assuming our cluster is in non-secure mode now. We will need the CLI credentials of CUCM publisher for converting the security mode of the cluster.


admin:show ctl
Length of CTL file: 0
CTL File not found. Please run CTLClient plugin or run the CLI - utils ctl.. to
generate the CTL file.
Error parsing the CTL File.


We can see above there is no CTL file present in the cluster and it’s in non-secure mode. We can also verify via enterprise parameters as shown in the above image.


We need to run the below command in publisher to convert the mode into mixed mode:


In CUCM Administration, Go To


Serviceability > Tools > Control Center - Feature Services


Enable CAPF as well as CTL services on the CUCM publisher and CTL service on all CUCM subscribers.


We need to run below command in publisher to convert the mode into Mixed-mode:


admin:utils ctl set-cluster mixed-mode
This operation will set the cluster to Mixed mode. Do We want to continue? (y/n):y

Moving Cluster to Mixed Mode
Cluster set to Mixed Mode
Please Restart the TFTP and Cisco CallManager services on all nodes in the cluster
that run these services


Once completed, restart the TFTP and Cisco Call Manager services on all of the nodes in the cluster that run these services. Restart all of the IP phones so that they can obtain the CTL file from the CUCM TFTP service.


admin:show ctl
The checksum value of the CTL file:



Length of CTL file: 5728
The CTL File was last modified on Fri Mar 06 21:48:48 CET 2015

CTL Record #:5
------- ---            ------  -----
1      RECORDLENGTH    2      1186
2      DNSNAME        1
3      SUBJECTNAME    56      cn="SAST-ADN008580ef ";ou=IPCBU;o="Cisco Systems
4      FUNCTION        2      System Administrator Security Token
5      ISSUERNAME      42      cn=Cisco Manufacturing CA;o=Cisco Systems
6      SERIALNUMBER    10     
7      PUBLICKEY      140
9      CERTIFICATE    902    85 CD 5D AD EA FC 34 B8 3E 2F F2 CB 9C 76 B0 93
3E 8B 3A 4F (SHA1 Hash HEX)
10      IPADDRESS      4
This etoken was used to sign the CTL file.

The CTL file was verified successfully


Before Enabling Mixed Mode:


After Enabling Mixed-Mode & CTL file installed on IP Phone:



Till now we had enabled the security mode in the cluster, and the phones are ready but they will not run SRTP yet. We need to create a profile for it or tell the phone to do so with some parameters for every device type and protocol.


Device Security Modes:


There are 3 types of Device Security Modes:

  1. Non-Secure: No security features except image, file, and device authentication exist for the phone. A TCP connection opens to Cisco Unified Communications Manager.
  2. Authentication: Cisco Unified Communications Manager provides integrity and authentication for the phone. A TLS connection that uses NULL/SHA opens for signaling.
  3. Encryption: Cisco Unified Communications Manager provides integrity, authentication, and encryption for the phone. A TLS connection that uses AES128/SHA opens for signaling, and SRTP carries the media for all phone calls.





Now Go to CUCM administration page:


System -> Security Profile -> Phone Security Profile


Click -> Add New


Create a security profile. For every device model & protocol its using. Select the desired one & save.




TFTP Encrypted Config: When this check box is checked, Cisco Unified Communications Manager encrypts phone downloads from the TFTP server.


Phone Security Profile CAPF


We can choose the authentication type for the device:


  1. Existing Certificate (LSC or MIC) – Installs/upgrades, deletes, or troubleshoots a locally significant certificate if a manufacture-installed certificate (MIC) or locally significant certificate (LSC) exists in the phone. Cisco recommends using LSC, as MIC can be compromised.
  2. Authentication String – Installs/upgrades, deletes, or troubleshoots a locally significant certificate only when the user enters the CAPF authentication string on the phone.
  3. Null String: Installs/upgrades, deletes, or troubleshoots a locally significant certificate without user intervention. This option provides no security; Cisco strongly recommends that we choose this option only for closed, secure environments.




Certificate Operation Over IP Phone:


If we have updated the CTL (Cisco Trust List) file with new or re-generated certificate and want to manually push the updated certificates into the phone, we need to go to protocol-specific section of the device page, and from there we can install/delete/troubleshoot the issue.




Apply device security profile on the device page and reset the phone. To apply to multiple phones at once, use the BAT tool.




Now we make a call between the two phones to check if we see a lock icon on the call display over phone. It means the call is encrypted, it’s running SRTP and some CUCM versions will show a shield icon and some a lock icon as shown below.




This is just a basic practice for SRTP, but if we are going to implement the same in a production environment, we will also need to take care of certificate import on the Gateways/Conference Bridge router and on the SRST router.




Let’s take a look at secure SRST. This guide will be focusing on implementation of sSRST over unified SRST, not CME-SRST.


The first step is the requirement:


  1. UCK9 license
  2. SRST license
  3. Security license (needed to run the encryption capabilities of the SRST)
  4. Cisco IOS image with payload encryption capabilities. In other words, the IOS image should not be NPE (non-payload encryption).


We need to import the CUCM certificates into the SRST & enable secure SRST in the SRST profile.




CUCM: SRST Profile:


We need to manually import a few certificates from CUCM to the SRST router where as SRST self-signed certificates will be automatically transferred to CUCM when we check the box (is SRST Secure?). If transfers complete successfully, changes will be saved in the profile; otherwise the change will not be saved in the SRST profile in CUCM.


When we enable secure SRST, CUCM asks for the SRST self-signed certificate and credential service running on the SRST router and does the same with CUCM. This process is called certification enrollment.


Everything cannot be covered here in a single blog so I will try to include more information future posts. I want to thank my friends Ebin & Engg for helping me prepare this blog. And a special thanks to CLN team for providing a platform to share things & learn together. Thanks !!!