# SRTP and media encryption negotiation

Canonical: https://warmtransfer.net/knowledge/srtp-media-security

Last verified: 2026-09-23

Secure Real-time Transport Protocol (SRTP) provides encryption, message authentication, and integrity protection for real-time media streams and their associated control packets[^14][^15][^20]. Key material and cryptographic transforms are established across network endpoints using signaling mechanisms such as Session Description Protocol Security Descriptions (SDES) or Datagram Transport Layer Security (DTLS-SRTP)[^39][^11].

## How it works

### Core SRTP cryptographic transforms

Under RFC 3711, the default SRTP encryption transform is Advanced Encryption Standard in Segmented Integer Counter Mode (AES-CM)[^14]. Alongside AES-CM, RFC 3711 designates the NULL cipher as mandatory to implement, permitting streams that are authenticated without being encrypted[^17]. The default message authentication algorithm is HMAC-SHA1, configured with a 160-bit session authentication key and an 80-bit authentication tag[^15]. While SRTP media streams may omit message authentication via specific configurations, message authentication is mandatory for Secure RTCP (SRTCP)[^20][^44].

RFC 3711 establishes standard key derivation defaults consisting of a 128-bit SRTP master key, a 112-bit master salt, and a key derivation rate of 0, which derives session keys once without periodic derivation refreshes[^16]. A single master key may protect at most 2^48 SRTP packets and 2^31 SRTCP packets[^18]. To calculate the packet index used in encryption transforms, SRTP maintains a 32-bit rollover counter (ROC) that the sender increments every time the 16-bit RTP sequence number wraps[^19].

RFC 6188 defines additional suites using 192-bit or 256-bit master keys with a 112-bit master salt: AES_192_CM_HMAC_SHA1_80, AES_192_CM_HMAC_SHA1_32, AES_256_CM_HMAC_SHA1_80, and AES_256_CM_HMAC_SHA1_32[^27]. RFC 7714 defines authenticated encryption through AES-GCM, specifying the SDES suites AEAD_AES_128_GCM and AEAD_AES_256_GCM, as well as the DTLS-SRTP protection profiles SRTP_AEAD_AES_128_GCM {0x00, 0x07} and SRTP_AEAD_AES_256_GCM {0x00, 0x08}[^30][^29]. AES-GCM implementations must support both AEAD_AES_128_GCM and AEAD_AES_256_GCM[^32]. AES-GCM SRTP utilizes a 96-bit master salt instead of the 112-bit salt used by AES-CM suites, requires a full 16-octet authentication tag with no truncation permitted, and authenticates RTP header fields (sequence numbers, timestamps, SSRCs, and header extensions) as associated data without encrypting them[^33][^28][^31].

### SDES signaling negotiation

RFC 4568 defines Session Description Protocol (SDP) Security Descriptions (SDES), which signals SRTP cryptographic parameters using media-level attributes formatted as `a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]`[^39]. In this attribute, the tag is a decimal identifier unique within the media line[^39]. RFC 4568 defines three core suites: AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32, and F8_128_HMAC_SHA1_80[^45]. The only key method specified in RFC 4568 is `inline`, which concatenates the base64-encoded master key and salt in the syntax `inline:<key||salt>[|lifetime][|MKI:length]`[^41]. SDES also defines optional session parameters to disable protections, such as UNENCRYPTED_SRTP, UNENCRYPTED_SRTCP, and UNAUTHENTICATED_SRTP[^44].

Because SDES embeds master keys directly in cleartext SDP, RFC 4568 mandates that signaling channels must be protected using message authentication and encryption, such as TLS, IPsec, or S/MIME[^43]. During offer/answer negotiation, the answering party must accept exactly 1 offered crypto attribute, returning that attribute's tag and suite in the answer[^38]. If none of the offered crypto attributes are acceptable, the answerer must reject the media stream[^42]. To avoid keystream reuse, the master keys in the answer must differ from those supplied in the offer[^40]. As of 2026-09-23, the IETF Datatracker lists RFC 4568 as a Proposed Standard and shows no obsoleting RFC[^22].

### DTLS-SRTP key exchange

Under RFC 5764, DTLS-SRTP utilizes a DTLS handshake strictly to negotiate key material and protection profiles via the DTLS `use_srtp` extension; RTP and RTCP packets themselves are transmitted as SRTP/SRTCP and never carried as DTLS application data[^11]. The core protection profiles defined by RFC 5764 are SRTP_AES128_CM_HMAC_SHA1_80, SRTP_AES128_CM_HMAC_SHA1_32, SRTP_NULL_HMAC_SHA1_80, and SRTP_NULL_HMAC_SHA1_32[^12]. RFC 5764 relies on an out-of-band mechanism, such as SDP, to assign DTLS client and DTLS server roles[^13]. In January 2021, RFC 8842 updated RFC 5763 and RFC 7345 with offer/answer rules for DTLS and TLS in SDP[^37].

DTLS-SRTP derives directional SRTP master keys and salts using the TLS exporter label `EXTRACTOR-dtls_srtp`, keeping cryptographic keys out of SDP[^10]. When media, control, and handshakes share a single port, RFC 7983 (September 2016) updated RFC 5764's demultiplexing to distinguish incoming datagrams across first-byte ranges[^34]:

| Protocol | First-byte range |
| --- | --- |
| STUN | 0 to 3 |[^34]
| ZRTP | 16 to 19 |[^34]
| DTLS | 20 to 63 |[^34]
| TURN channel | 64 to 79 |[^34]
| RTP / RTCP | 128 to 191 |[^34]

### WebRTC requirements

RFC 8827 requires all WebRTC implementations to support DTLS and DTLS-SRTP for SRTP key establishment[^58]. WebRTC implementations are prohibited from offering SDES or accepting SDES if offered by a peer[^60]. In WebRTC, media must be secured with SRTP and SRTCP, plain RTP and plain RTCP are forbidden, and no NULL-encryption suites are allowed[^59]. Consistent with these requirements, Google removed SDES key exchange for WebRTC from Chrome in Chrome 97[^2].

## Platform differences

### Microsoft Teams Direct Routing

Microsoft requires Direct Routing Session Border Controllers (SBCs) to support the AES_CM_128_HMAC_SHA1_80 suite in both offers and answers using the `inline:<key||salt>[|lifetime]` key format, without requiring MKI or length parameters[^50]. Microsoft Media Processors always prefer SDES, and SDES is always used between the SBC and the Direct Routing media processor[^49]. Without media bypass, a DTLS-only client is converted to SDES by the media processor[^49]. When media bypass is enabled, Direct Routing inserts a media processor and converts the call to non-bypass if the Teams client is DTLS-only; however, Microsoft states that no current Teams client offers only DTLS[^46].

In Direct Routing bypass mode, an SBC offer must contain SDES `a=crypto` lines and may also include DTLS attributes such as `a=fingerprint` and `a=setup:actpass`[^47]. Microsoft illustrates bypass offers using the `UDP/TLS/RTP/SAVP` profile with `rtcp-mux`[^47]. In Microsoft's published example of an SDES-only offer toward an SBC, AES_CM_128_HMAC_SHA1_32 appears as crypto tag 0 ahead of AES_CM_128_HMAC_SHA1_80 as tag 1 on an `RTP/SAVP` media line[^52]. Microsoft's infrastructure requirements list `TCP/RTP/SAVP` and `UDP/RTP/SAVP` for media transport[^48]. Bidirectional media between the SBC and the Microsoft Media Processor travels as UDP/SRTP across destination ports 3478 through 3481 and 49152 through 53247[^51].

### Cisco Webex Calling and CUBE

Cisco's Webex Calling security specifications mandate TLS 1.2 or TLS 1.3 for secure SIP signaling and list AES_CM_128_HMAC_SHA1_80 as the only supported SRTP cipher suite[^54][^55]. For Cisco Unified Border Element (CUBE) operating as a Local Gateway with Webex Calling, Cisco documents configuring `voice class srtp-crypto` specifying `crypto 1 AES_CM_128_HMAC_SHA1_80` as the sole cipher suite offered or answered on the dial-peer toward Webex Calling[^56].

On CUBE enterprise routers, the default crypto-suite preference order, highest first, is AEAD_AES_256_GCM, AEAD_AES_128_GCM, AES_CM_128_HMAC_SHA1_80, and AES_CM_128_HMAC_SHA1_32[^4]. Preferences are configured using the `voice class srtp-crypto` command, which establishes a list numbered 1 to 4 (with 1 being highest) and can be applied globally, to a voice class tenant, or per dial-peer using `voice-class sip srtp-crypto`[^8]. CUBE SRTP-SRTP interworking allows different crypto suites on each call leg and was introduced in Cisco IOS XE Everest 16.5.1b[^6]. This interworking capability does not support SRTCP-RTCP interworking, asymmetric SRTP fallback, GCM ciphers combined with RTP header extensions, or sessions with more than 1 audio or video m-line[^7]. CUBE also provides an SRTP fallback option allowing calls to revert to unencrypted RTP if the remote end lacks SRTP support; Cisco positions this fallback as necessary for non-secure supplementary services like music on hold and call transfer[^9]. Cisco's CUBE hardening guide recommends prioritizing AEAD_AES_256_GCM followed by AEAD_AES_128_GCM, while warning that older Cisco or peer devices may lack AEAD cipher support[^5].

WarmTransfer's reading of the sources is that because AES_CM_128_HMAC_SHA1_80 keyed via SDES is the only configuration documented as supported or required by both Teams Direct Routing and Webex Calling, an SBC integrating both services must include it within its crypto list[^3].

## See also

- [SDP offer answer and codec negotiation](https://warmtransfer.net/knowledge/sdp-offer-answer)
- [Teams Phone Direct Routing and SBC certification](https://warmtransfer.net/knowledge/teams-direct-routing)
- [Webex Calling ICE media path optimization](https://warmtransfer.net/knowledge/webex-calling-media-optimization)
- [WebRTC in modern contact centers](https://warmtransfer.net/knowledge/webrtc-deployment)

## Applicability

Applies to: IETF SRTP, IETF SDES, IETF DTLS-SRTP, IETF DTLS-SRTP with SDP, IETF WebRTC, Google Chrome (WebRTC), Microsoft Teams Phone Direct Routing, Cisco Webex Calling, Cisco Webex Calling Local Gateway (CUBE on IOS XE), Cisco Unified Border Element (CUBE) on IOS XE, Cisco Unified Border Element (CUBE) Enterprise, and Teams Phone Direct Routing; Webex Calling. Deployments: on-premises, hybrid, multi-tenant, any, and client. Sources checked 2026-09-23. CUBE SRTP-SRTP interworking is supported on Cisco IOS XE starting in release Everest 16.5.1b[^6]. Google Chrome removed SDES key exchange in Chrome 97[^2]. Direct Routing, Webex Calling, and SDES standards status are verified as of 2026-09-23[^22][^50][^54].

## What remains uncertain

Specific interoperability behaviors for intermediate proxy handling of encrypted headers are not covered by the sources below.

## Sources

[^1]: Google's Chrome 97 deprecation notice says the IETF has declared the SDES specification historic. The IETF Datatracker still lists RFC 4568 as a Proposed Standard, so the two sources conflict (disputed). Source: [Deprecations and removals in Chrome 97](https://developer.chrome.com/blog/deps-rems-97), Section 'Remove SDES key exchange for WebRTC'. Checked 2026-09-23.
[^2]: Google removed SDES key exchange for WebRTC from Chrome in Chrome 97. Source: [Deprecations and removals in Chrome 97](https://developer.chrome.com/blog/deps-rems-97), Section 'Remove SDES key exchange for WebRTC'. Checked 2026-09-23.
[^3]: AES_CM_128_HMAC_SHA1_80 keyed by SDES is the one SRTP configuration that both Teams Direct Routing and Webex Calling document as required or supported, so an SBC serving both needs it in its crypto list (inferred). Source: [Direct Routing support for media bypass - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-media), Section 'SRTP support requirements' combined with cisco-help-jwkbt2-security-requirements 'Requirements for SIP and media'. Checked 2026-09-23.
[^4]: CUBE's default SRTP crypto-suite preference, highest first, is AEAD_AES_256_GCM, AEAD_AES_128_GCM, AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-SRTP Interworking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/cube_m_srtp-srtp-interworking.html), SRTP-SRTP Interworking, supported cipher suites / default preference. Checked 2026-09-23.
[^5]: Cisco's CUBE hardening guide recommends trimming SRTP ciphers to prefer AEAD_AES_256_GCM and then AEAD_AES_128_GCM, and warns that some older Cisco or peer devices may not support AEAD ciphers. Source: [Cisco Guide to Harden Cisco Unified Border Element (CUBE) Enterprise Devices](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220380-cisco-guide-to-harden-cisco-unified-bord.html), Section on trimming insecure SRTP ciphers. Checked 2026-09-23.
[^6]: CUBE SRTP-SRTP interworking, which lets the two call legs use different crypto suites, was first supported in Cisco IOS XE Everest 16.5.1b. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-SRTP Interworking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/cube_m_srtp-srtp-interworking.html), Feature information table, SRTP-SRTP Interworking. Checked 2026-09-23.
[^7]: CUBE SRTP-SRTP interworking does not support SRTCP-RTCP interworking, asymmetric SRTP fallback, GCM ciphers with RTP header extensions, or more than one audio or video m-line. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-SRTP Interworking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/cube_m_srtp-srtp-interworking.html), SRTP-SRTP Interworking, restrictions. Checked 2026-09-23.
[^8]: On CUBE, voice class srtp-crypto sets a crypto preference list numbered 1 to 4, with 1 highest. It can be applied globally, to a voice class tenant, or per dial-peer with voice-class sip srtp-crypto. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-SRTP Interworking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/cube_m_srtp-srtp-interworking.html), SRTP-SRTP Interworking, voice class srtp-crypto configuration. Checked 2026-09-23.
[^9]: CUBE's SRTP fallback option lets a call revert to RTP when the far end does not support SRTP, which Cisco positions as needed for non-secure supplementary services such as music on hold and call transfer. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-SRTP Interworking](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/cube_m_srtp-srtp-interworking.html), SRTP-SRTP Interworking, SRTP fallback. Checked 2026-09-23.
[^10]: DTLS-SRTP derives the SRTP master key and salt for each direction from the DTLS handshake using the TLS exporter label 'EXTRACTOR-dtls_srtp', so no keys appear in SDP. Source: [RFC 5764: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc5764.html), Section 4.2 (Key Derivation). Checked 2026-09-23.
[^11]: In DTLS-SRTP, DTLS is used only to establish keys. Once use_srtp is negotiated, RTP and RTCP are protected solely by SRTP and never sent as DTLS application data. Source: [RFC 5764: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc5764.html), Section 4.1 (The use_srtp Extension). Checked 2026-09-23.
[^12]: RFC 5764 defines the DTLS-SRTP protection profiles SRTP_AES128_CM_HMAC_SHA1_80, SRTP_AES128_CM_HMAC_SHA1_32, SRTP_NULL_HMAC_SHA1_80 and SRTP_NULL_HMAC_SHA1_32, which are negotiated in the DTLS use_srtp extension. Source: [RFC 5764: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc5764.html), Section 4.1.1 (use_srtp Extension Definition); Section 4.1.2 (SRTP Protection Profiles). Checked 2026-09-23.
[^13]: RFC 5764 leaves the choice of DTLS client and DTLS server to an out-of-band mechanism such as SDP. Source: [RFC 5764: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc5764.html), Section 3 (Overview of DTLS-SRTP Operation). Checked 2026-09-23.
[^14]: RFC 3711 makes AES in Segmented Integer Counter Mode (AES-CM) the default SRTP encryption transform. Source: [RFC 3711: The Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc3711.html), Section 5.1 (Encryption). Checked 2026-09-23.
[^15]: RFC 3711 makes HMAC-SHA1 the default SRTP message authentication, with an 80-bit authentication tag and a 160-bit session authentication key. Source: [RFC 3711: The Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc3711.html), Section 5.2 (Message Authentication and Integrity). Checked 2026-09-23.
[^16]: RFC 3711 defaults to a 128-bit SRTP master key, a 112-bit master salt and a key derivation rate of zero, meaning session keys are derived once and not periodically refreshed. Source: [RFC 3711: The Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc3711.html), Section 5.3 (Key Derivation). Checked 2026-09-23.
[^17]: RFC 3711 makes the NULL cipher mandatory to implement alongside AES-CM, which permits SRTP streams that are authenticated but not encrypted. Source: [RFC 3711: The Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc3711.html), Section 5.1 (Encryption); Section 4.1.3 (NULL Cipher). Checked 2026-09-23.
[^18]: Under RFC 3711 a single master key may protect at most 2^48 SRTP packets and 2^31 SRTCP packets. Source: [RFC 3711: The Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc3711.html), Section 3.3.1 (Packet Index Determination, and Sender's Processing); Section 9.2. Checked 2026-09-23.
[^19]: SRTP keeps a 32-bit rollover counter (ROC) that the sender must increment each time the 16-bit RTP sequence number wraps, and the ROC forms part of the packet index used for encryption. Source: [RFC 3711: The Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc3711.html), Section 3.3.1 (Packet Index Determination, and Sender's Processing). Checked 2026-09-23.
[^20]: Message authentication is mandatory for SRTCP under RFC 3711. Source: [RFC 3711: The Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc3711.html), Section 3.4 (Secure RTCP). Checked 2026-09-23.
[^21]: For SRTP (as opposed to SRTCP), RFC 3711 makes the authentication tag RECOMMENDED rather than mandatory. Source: [RFC 3711: The Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc3711.html), Section 3.1 (SRTP packet format, authentication tag field); summariser cited Section 2. Checked 2026-09-23.
[^22]: As of 2026-09-23 the IETF Datatracker lists RFC 4568 (SDES) as a Proposed Standard and shows no obsoleting RFC. Source: [RFC 4568 - Session Description Protocol (SDP) Security Descriptions for Media Streams (Datatracker)](https://datatracker.ietf.org/doc/rfc4568/), Datatracker document page, status field. Checked 2026-09-23.
[^23]: RFC 5763 requires the SIP offerer in DTLS-SRTP to use a=setup:actpass, and the answerer replies with setup:active or setup:passive. Source: [RFC 5763: Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)](https://www.rfc-editor.org/rfc/rfc5763.html), Section 5 (Establishing a Secure Channel), unverified section number. Checked 2026-09-23.
[^24]: RFC 5763 relies on the integrity of the SDP fingerprint and recommends SIP Identity (RFC 4474) to stop intermediaries modifying it, with SIPS or S/MIME as alternatives. Source: [RFC 5763: Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)](https://www.rfc-editor.org/rfc/rfc5763.html), Sections 5-8 (fingerprint integrity discussion), unverified section number. Checked 2026-09-23.
[^25]: RFC 5763 allows the DTLS certificates to be self-signed. Authentication comes from matching the handshake certificate against the a=fingerprint value carried in signalling, not from a certificate authority. Source: [RFC 5763: Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)](https://www.rfc-editor.org/rfc/rfc5763.html), Section 5 (Establishing a Secure Channel), unverified section number. Checked 2026-09-23.
[^26]: As published in 2010, RFC 5764 demultiplexed packets on a shared port by first byte: 0-1 STUN, 20-63 DTLS and 128-191 RTP/RTCP. Source: [RFC 5764: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc5764.html), Section 5.1.2 (Reception), Figure 3. Checked 2026-09-23.
[^27]: RFC 6188 adds four SDES crypto suites, AES_192_CM_HMAC_SHA1_80, AES_192_CM_HMAC_SHA1_32, AES_256_CM_HMAC_SHA1_80 and AES_256_CM_HMAC_SHA1_32, with 192-bit or 256-bit master keys and a 112-bit master salt. Source: [RFC 6188: The Use of AES-192 and AES-256 in Secure RTP](https://www.rfc-editor.org/rfc/rfc6188.html), Section 4 (Crypto Suites), Tables 1-4. Checked 2026-09-23.
[^28]: RFC 7714 requires the AES-GCM SRTP authentication tag to be a full 16 octets and forbids truncating it. Source: [RFC 7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc7714.html), Section 13.2 (Size of the Authentication Tag). Checked 2026-09-23.
[^29]: RFC 7714 registers the DTLS-SRTP protection profiles SRTP_AEAD_AES_128_GCM {0x00, 0x07} and SRTP_AEAD_AES_256_GCM {0x00, 0x08}. Source: [RFC 7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc7714.html), Section 14.2 (DTLS-SRTP). Checked 2026-09-23.
[^30]: RFC 7714 registers the SDES crypto suites AEAD_AES_128_GCM and AEAD_AES_256_GCM for AES-GCM authenticated encryption in SRTP. Source: [RFC 7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc7714.html), Section 14.1 (SDES). Checked 2026-09-23.
[^31]: In AES-GCM SRTP the RTP header fields (including sequence number, timestamp, SSRC and any header extensions) are authenticated as associated data but not encrypted. Source: [RFC 7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc7714.html), Section 8.2. Checked 2026-09-23.
[^32]: Any AES-GCM SRTP implementation must support both AEAD_AES_128_GCM and AEAD_AES_256_GCM. Source: [RFC 7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc7714.html), Section 12 (Summary of AES-GCM in SRTP/SRTCP). Checked 2026-09-23.
[^33]: AES-GCM SRTP uses a 96-bit master salt, not the 112-bit salt of the AES-CM suites. Source: [RFC 7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc7714.html), Section 12 (Summary of AES-GCM in SRTP/SRTCP), Tables 2 and 3. Checked 2026-09-23.
[^34]: RFC 7983 (September 2016) updates RFC 5764's demultiplexing to these first-byte ranges: 0-3 STUN, 16-19 ZRTP, 20-63 DTLS, 64-79 TURN channel and 128-191 RTP/RTCP. Source: [RFC 7983: Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)](https://www.rfc-editor.org/rfc/rfc7983.html), Section 7. Checked 2026-09-23.
[^35]: Under RFC 8842, modifying, adding or removing a fingerprint value in an SDP offer or answer requires a new DTLS association. Source: [RFC 8842: Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)](https://www.rfc-editor.org/rfc/rfc8842.html), Section on establishing a new DTLS association, unverified section number. Checked 2026-09-23.
[^36]: RFC 8842 defines the media-level a=tls-id attribute. The offerer's and answerer's values together identify a DTLS association, and a new value is required for each new association. Source: [RFC 8842: Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)](https://www.rfc-editor.org/rfc/rfc8842.html), Section defining the 'tls-id' attribute, unverified section number. Checked 2026-09-23.
[^37]: RFC 8842 (January 2021) updates RFC 5763 and RFC 7345 with offer/answer rules for DTLS and TLS in SDP. Source: [RFC 8842: Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)](https://www.rfc-editor.org/rfc/rfc8842.html), Header (Updates: 5763, 7345). Checked 2026-09-23.
[^38]: Under RFC 4568 offer/answer, the answerer must accept exactly one of the offered crypto attributes and return that attribute's tag and crypto suite in the answer. Source: [RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams](https://www.rfc-editor.org/rfc/rfc4568.html), Section 5.1.2 (Generating the Initial Answer - Unicast Streams). Checked 2026-09-23.
[^39]: RFC 4568 carries SRTP keying in the SDP media-level attribute a=crypto:<tag> <crypto-suite> <key-params> [<session-params>], where the tag is a decimal identifier unique within the media line. Source: [RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams](https://www.rfc-editor.org/rfc/rfc4568.html), Section 4 (The Crypto Attribute). Checked 2026-09-23.
[^40]: RFC 4568 requires the master keys in an SDES answer to differ from those in the offer, to avoid keystream reuse. Source: [RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams](https://www.rfc-editor.org/rfc/rfc4568.html), Section 7.1.2 (Generating the Initial Answer - Unicast Streams); Section 8.2 (Keystream Reuse). Checked 2026-09-23.
[^41]: The only SRTP key method RFC 4568 defines is 'inline', formatted as inline:<key||salt>[|lifetime][|MKI:length], with the base64 master key and salt concatenated. Source: [RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams](https://www.rfc-editor.org/rfc/rfc4568.html), Section 6.1 (SRTP Key Parameter). Checked 2026-09-23.
[^42]: If none of the offered crypto attributes is acceptable, RFC 4568 requires the answerer to reject the offered media stream. Source: [RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams](https://www.rfc-editor.org/rfc/rfc4568.html), Section 5.1.2; Section 7.1.2. Checked 2026-09-23.
[^43]: Because SDES puts the master key in cleartext SDP, RFC 4568 requires the signalling to be protected with message authentication and encryption, for example TLS, IPsec or S/MIME. Source: [RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams](https://www.rfc-editor.org/rfc/rfc4568.html), Section 8.3 (Signaling Authentication and Signaling Encryption). Checked 2026-09-23.
[^44]: RFC 4568 defines optional session parameters, including UNENCRYPTED_SRTP, UNENCRYPTED_SRTCP and UNAUTHENTICATED_SRTP, that switch off encryption or authentication for a stream. Source: [RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams](https://www.rfc-editor.org/rfc/rfc4568.html), Section 6.3.2; Section 6.3.3. Checked 2026-09-23.
[^45]: RFC 4568 defines three SRTP crypto suites: AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32 and F8_128_HMAC_SHA1_80. Source: [RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams](https://www.rfc-editor.org/rfc/rfc4568.html), Sections 6.2.1, 6.2.2, 6.2.3. Checked 2026-09-23.
[^46]: With Direct Routing media bypass, if the Teams client is DTLS-only, Direct Routing inserts a media processor and converts the call to non-bypass. Microsoft says no current Teams client offers only DTLS. Source: [Direct Routing support for media bypass - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-media), Section 'SDES support requirements'. Checked 2026-09-23.
[^47]: In Direct Routing bypass mode, the SBC's offer must contain SDES (a=crypto) and may also carry DTLS attributes (a=fingerprint, a=setup:actpass). Microsoft's example uses UDP/TLS/RTP/SAVP with rtcp-mux. Source: [Direct Routing support for media bypass - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-media), Section 'Format for offer from SBC in bypass mode'. Checked 2026-09-23.
[^48]: Microsoft's Direct Routing plan lists TCP/RTP/SAVP and UDP/RTP/SAVP as the media transport infrastructure requirement. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Section 'Infrastructure requirements', row 'Media transport'. Checked 2026-09-23.
[^49]: Microsoft Media Processors always prefer SDES, and SDES is always used between the SBC and the Direct Routing media processor. Without media bypass, a DTLS-only client is converted to SDES by the media processor. Source: [Direct Routing support for media bypass - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-media), Section 'SDES support requirements'. Checked 2026-09-23.
[^50]: Microsoft requires a Direct Routing SBC to support the SRTP cipher AES_CM_128_HMAC_SHA1_80 in offers and answers, using the inline:<key||salt>[|lifetime] format. MKI and length parameters are not required. Source: [Direct Routing support for media bypass - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-media), Section 'SRTP support requirements'. Checked 2026-09-23.
[^51]: Direct Routing media flows as UDP/SRTP in both directions between the Microsoft Media Processor and the SBC on ports 3478-3481 and 49152-53247. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Section 'Media ports'. Checked 2026-09-23.
[^52]: Microsoft's example of an SDES-only offer from Teams to an SBC lists AES_CM_128_HMAC_SHA1_32 as crypto tag 0 ahead of AES_CM_128_HMAC_SHA1_80 as tag 1, on an RTP/SAVP media line. Source: [Direct Routing support for media bypass - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-media), Section 'Format for SDES only offer to SBC'. Checked 2026-09-23.
[^53]: RFC 5763 identifies SRTP keyed by DTLS over UDP with the SDP transport protocol UDP/TLS/RTP/SAVP. Source: [RFC 5763: Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)](https://www.rfc-editor.org/rfc/rfc5763.html), Section 5, unverified section number. Checked 2026-09-23.
[^54]: Cisco's Webex Calling security requirements list AES_CM_128_HMAC_SHA1_80 as the only supported SRTP key cipher suite. Source: [Security requirements for Webex Calling](https://help.webex.com/en-us/article/jwkbt2/Security-requirements-for-Webex-Calling), Section 'Requirements for SIP and media'. Checked 2026-09-23.
[^55]: Webex Calling supports TLS 1.2 and TLS 1.3 for secure SIP. Source: [Security requirements for Webex Calling](https://help.webex.com/en-us/article/jwkbt2/Security-requirements-for-Webex-Calling), Section 'Requirements for SIP and media'. Checked 2026-09-23.
[^56]: Cisco's Local Gateway guide for Webex Calling configures voice class srtp-crypto with crypto 1 AES_CM_128_HMAC_SHA1_80 as the only cipher suite CUBE offers or answers toward Webex Calling, and enables srtp on the Webex Calling dial-peer. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Section 'Configure Webex Calling registration-based trunk' (voice class srtp-crypto 100; dial-peer voice 100 voip). Checked 2026-09-23.
[^57]: For the registration-based trunk to Webex Calling, the Local Gateway guide configures SIP transport as TLS v1.2 (transport tcp tls v1.2). Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Section 'Configure Webex Calling registration-based trunk'. Checked 2026-09-23.
[^58]: RFC 8827 requires WebRTC implementations to support DTLS and DTLS-SRTP for SRTP keying. Source: [RFC 8827: WebRTC Security Architecture](https://www.rfc-editor.org/rfc/rfc8827.html), Section 6.5 (Communications Security). Checked 2026-09-23.
[^59]: RFC 8827 requires all WebRTC media to be protected with SRTP and SRTCP, forbids plain RTP or RTCP, and allows no NULL-encryption suites. Source: [RFC 8827: WebRTC Security Architecture](https://www.rfc-editor.org/rfc/rfc8827.html), Section 6.5 (Communications Security). Checked 2026-09-23.
[^60]: RFC 8827 forbids WebRTC implementations from offering SDP Security Descriptions (SDES) or selecting them if offered. Source: [RFC 8827: WebRTC Security Architecture](https://www.rfc-editor.org/rfc/rfc8827.html), Section 6.5 (Communications Security). Checked 2026-09-23.