Overview
The Cisco Unified Border Element (CUBE) support for SRTP-RTP interworking feature allows secure network to non-secure network calls and provides operational enhancements for Session Initiation Protocol (SIP) trunks from Cisco Unified Call Manager and Cisco Unified Call Manager Express. Support for Secure Real-Time Transport Protocol (SRTP) to Real-Time Transport Protocol (RTP) interworking in a network is enabled for SIP-SIP audio calls.
To configure support for SRTP-RTP interworking, you should understand the following concepts:
Support for SRTP-RTP Interworking
The CUBE support for SRTP-RTP Interworking feature connects SRTP Cisco Unified Call Manager domains with the following:
-
RTP Cisco Unified Call Manager domains. Domains that do not support SRTP or is not configured for SRTP.
-
RTP Cisco applications or servers. For example, Cisco Unified Meeting Place, Cisco WebEx, or Cisco Unity, which do not support SRTP, or is not configured for SRTP, or are resident in a secure data center.
-
RTP to third-party equipment. For example, IP trunks to PBXs or virtual machines, which do not support SRTP.
The CUBE support for SRTP-RTP interworking feature connects SRTP enterprise domains to RTP SIP provider SIP trunks. SRTP-RTP interworking connects RTP enterprise networks with SRTP over an external network between businesses. This provides flexible and secure business-to-business communications without the need for static IPsec tunnels or the need to deploy SRTP within the enterprise.
SRTP-RTP interworking also connects SRTP enterprise networks with static IPsec over external networks.
SRTP-RTP interworking on the CUBE in a network topology uses single-pair keygen. Existing audio and dual-tone multifrequency (DTMF) transcoding supports voice calls. There is no impact on SRTP-SRTP pass-through calls.
Use the srtp and srtp fallback commands to configure SRTP on one dial peer. Configure the RTP on the other dial peer. The dial peer configuration takes precedence over the global configuration on the CUBE.
Fallback handling occurs if one of the call endpoints does not support SRTP. The call can fall back to RTP-RTP, or the call can fail, depending on the configuration. Fallback takes place only if the srtp fallback command is configured on the respective dial peer.
Use SRTP-RTP Chain for Interworking Between AES_CM_128_HMAC_SHA1_32 and AES_CM_128_HMAC_SHA1_80 Crypto Suites
A single Cisco Unified Communications Manager (CUCM) device cannot terminate a Secure Real-Time Transport Protocol (SRTP) connection with an IP Phone using the AES_CM_128_HMAC_SHA1_32 crypto suite and initiate an SRTP connection with an external CUBE device with the AES_CM_128_HMAC_SHA1_80 crypto suite at the same time.
For Cisco Unified Communications Manager (Cisco Unified Communications Manager) and IP Phone devices that support only AES_CM_128_HMAC_SHA1_32 crypto suite, the interim SRTP-RTP interworking solution that is described below can be implemented.
-
Cisco Unified Communications Manager or IP Phone side:
-
An SRTP connection using the AES_CM_128_HMAC_SHA1_32 crypto suite exists between the IP phone and CUBE1.
-
An RTP connection exists between CUBE1 and CUBE2.
-
-
SIP trunk sideāAn SRTP connection using the AES_CM_128_HMAC_SHA1_80 crypto suite is initiated by CUBE2 here. In the image below, CUBE2 is the border element on the Customer Network and SBC is the border element on the Service Provider Network.
Note |
|
Supplementary Services Support
The following supplementary services are supported:
-
Midcall codec change with voice class codec configuration
-
Reinvite-based call hold and resume
-
Music on hold (MoH) invoked from the Cisco Unified Communications Manager (Cisco UCM), where the call leg changes between SRTP and RTP for an MoH source
-
Reinvite-based call forward and call transfer
-
Call transfer based on a REFER message, with local consumption or pass-through of the REFER message on the CUBE
-
Call forward based on a 302 message, with local consumption or pass-through of the 302 message on the CUBE
-
T.38 fax switchover
-
Fax pass-through switchover
For call transfers involving REFER and 302 messages (messages that are locally consumed on CUBE), end-to-end media renegotiation is initiated from CUBE only when you configure the supplementary-service media-renegotiate command in voice service voip configuration mode.
Note |
Any call-flow wherein there is a switchover from RTP to SRTP on the same SIP call-leg requires the supplementary-service media-renegotiate command enabled in global or voice service voip configuration mode to ensure there is 2-way audio. Example call-flows:
|
When supplementary services are invoked from the end points, the call can switch between SRTP and RTP during the call duration. Hence, Cisco recommends that you configure such SIP trunks for SRTP fallback. For information on configuring SRTP fallback, refer Enable SRTP Fallback .
Feature Information
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Feature Name |
Releases |
Feature Information |
---|---|---|
Support for AEAD_AES_GCM_256 and AEAD_AES_GCM_128 crypto-suites |
Cisco IOS XE Everest 16.5.1b |
AEAD_AES_GCM_256 and AEAD_AES_GCM_128 crypto suites were added to support SRTP-RTP interworking. |