The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to set up a secure Real-time Transport Protocol (RTP) between the Cisco Video Communication Server (VCS) and Cisco Unified Communication Manager (CUCM).
Cisco recommends that you have knowledge of these topics:
Cisco VCS or Cisco Expressway
The information in this document is based on these software and hardware versions:
Cisco VCS or Cisco Expressway
Note: This article uses the Cisco Expressway products for purposes of explanation (except where stated), but the information also applies if your deployment uses the Cisco VCS.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Session Initiation Protocol (SIP) calls routed between CUCM and Expressway
Media encryption is best-effort / optional between Expressway-C and CUCM
There have been difficulties reported for the configuration of best effort media encryption for SIP calls that are routed between CUCM and VCS/Expressway. A common misconfiguration affects the signaling of encrypted media, via Secure Real-time Transport Protocol (SRTP), which causes failure of best-effort encrypted calls when the transport between CUCM and Expressway is not secure.
If the transport is not secure, then the media encryption signaling could be read by an eavesdropper. In this case, the media encryption signaling information is stripped from the Session Description Protocol (SDP). However, it is possible to configure CUCM to send (and expect to receive) media encryption signaling over an unsecured connection. You can work around this misconfiguration in one of two ways, dependent upon whether the calls are routed trunk-side or line-side to CUCM.
Trunk-side and Line-side Examples
Trunk-side: A SIP trunk is configured on CUCM towards Expressway. A corresponding neighbor zone is configured on the Expressway towards CUCM. You would need a trunk if you wanted VCS-registered (Expressway is not a registrar, but VCS is) endpoints to call CUCM-registered endpoints. Another example would be to enable H.323 interworking in your deployment.
Line-side: Line-side calls go directly to CUCM, not via a trunk. If all registration and call control is provided by CUCM, your deployment might not require a trunk to Expressway. For example, if Expressway is deployed purely for Mobile and Remote Access (MRA), it proxies the line-side calls from external endpoints to CUCM.
If there is a SIP trunk between CUCM and Expressway, a normalization script on the CUCM rewrites the SDP appropriately so that the best-effort encryption call is not rejected. This script is automatically installed with later releases of CUCM, but if you have best-effort encrypted calls rejected, Cisco recommends that you download and install the latest vcs-interop script for your version of CUCM.
If the call goes line-side to CUCM, then CUCM expects to see the x-cisco-srtp-fallback header if the media encryption is optional. If CUCM does not see this header, it considers the call to be encryption-mandatory. Support for this header was added to Expressway in version X8.2, so Cisco recommends X8.2 or later for MRA (collaboration edge).
In order to enable best-effort encryption of line-side calls from Expressway-C to CUCM:
Use a supported deployment / solution (for example, MRA)
Use Mixed Mode security on CUCM
Ensure that Expressway and CUCM trust each other (the Certificate Authority (CA) that signs each party's certificates must be trusted by the other party)
Use version X8.2 or later of Expressway
Use secure phone profiles on CUCM, with Device Security Mode set to Authenticated or Encrypted - for these modes the transport type is Transport Layer Security (TLS)
Use a supported deployment / solution
Use Mixed Mode security on CUCM
Ensure that Expressway and CUCM trust each other (the CA that signs each party's certificates must be trusted by the other party)
Choose best effort as the encryption mode and TLS as the transport on the neighbor zone from Expressway to CUCM (these values are automatically prepopulated in the line-side case)
Select TLS as the inbound and outbound transport on the SIP trunk security profile
Check SRTP Allowed (see the Caution statement) on the SIP trunk from CUCM to Expressway
Check for, and apply if necessary, the correct normalization script for your versions of CUCM and Expressway
Caution: If you check the SRTP Allowed check box, Cisco strongly recommends that you use an encrypted TLS profile so that keys and other security-related information does not get exposed during call negotiations. If you use a non-secure profile, SRTP will still work. However, the keys will be exposed in signaling and traces. In that case, you must ensure the security of the network between CUCM and the destination side of the trunk.
Media Encryption Options
Encryption is not allowed. Calls that require encryption should fail because they cannot be secure. CUCM and Expressway are consistent in signaling for this case.
CUCM and Expressway both use m=RTP/AVP in order to describe the media in the SDP. There are no crypto attributes (no a=crypto... lines in the media sections of the SDP).
Media encryption is required. Unencrypted calls should always fail; no fallback is allowed. CUCM and Expressway are consistent in signaling for this case.
CUCM and Expressway both use m=RTP/SAVP in order to describe the media in the SDP. The SDP has crypto attributes (a=crypto... lines in the media sections of the SDP).
Calls that can be encrypted are encrypted. If encryption cannot be established, calls might and should fall back to unencrypted media. CUCM and Expressway are inconsistent in this case.
Expressway always refuses encryption if the transport is Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). You must secure the transport between CUCM and Expressway if you want media encryption.
SDP (as CUCM writes it): Encrypted media is described as m=RTP/SAVP and a=crypto lines are written into the SDP. This is the correct signaling for media encryption, but the crypto lines are readable if the transport is not secure.
If CUCM sees the x-cisco-srtp-fallback header, it allows the call to fall back to unencrypted. If this header is absent, CUCM assumes the call requires encryption (does not allow fallback).
As of X8.2, Expressway does best effort the same way as CUCM does in the line-side case.
SDP (as Expressway writes trunk-side): Encrypted media is described as m=RTP/AVP and a=crypto lines are written into the SDP.
However, there are two reasons that the a=crypto lines could be absent:
When a transport hop to or from the SIP proxy on the Expressway is not secure, the proxy strips the crypto lines in order to prevent them from exposure on the unsecure hop.
The answering party strips out the crypto lines in order to signal that it cannot or will not do encryption.
Use of the correct SIP normalization script on CUCM mitigates this issue.
There is currently no verification procedure available for this configuration.
There is currently no specific troubleshooting information available for this configuration.