sip media · stub

Troubleshooting SRTP and crypto negotiation failures

Verified 2026-10-02 · 59 sources · tier 1–3

Also known as srtp crypto suite mismatch, srtp fallback.

Stub. This topic has 59 sources and no published article. The sources below are everything recorded so far.

So far, no summary has been generated for this topic. The sources below are everything recorded so far.

See also

Related to

Troubleshoots

  • SRTP and media encryption negotiation — srtp-media-security covers SRTP concepts and design; this topic covers failure symptoms in SDES/DTLS offer-answer; best-effort fallback and SRTP-RTP interworking

Sources

  1. 1
    RFC 6188 registers the 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.
    RFC 6188: The Use of AES-192 and AES-256 in Secure RTP · Sections 4 and 5 · Checked 2026-10-02
  2. 2
    The RFC 6188 AES-256 counter-mode suites use a 32-octet master key and a 14-octet master salt (46 octets of keying material), unlike the 30 octets used by the RFC 4568 suites.
    RFC 6188: The Use of AES-192 and AES-256 in Secure RTP · Section 4 (parameter tables) · Checked 2026-10-02
  3. 3
    The Asterisk res_pjsip endpoint option media_encryption accepts no (default), sdes (in-SDP SRTP keys) or dtls (DTLS-SRTP).
    res_pjsip - Asterisk Documentation · endpoint option media_encryption · Checked 2026-10-02
  4. 4
    With Asterisk media_encryption_optimistic enabled, encryption is used if possible but the session is not terminated if it cannot be established; the default is no.
    res_pjsip - Asterisk Documentation · endpoint option media_encryption_optimistic · Checked 2026-10-02
  5. 5
    From IOS XE Everest 16.5.1b CUBE enables AEAD_AES_256_GCM, AEAD_AES_128_GCM, AES_CM_128_HMAC_SHA1_80 and AES_CM_128_HMAC_SHA1_32 by default, and voice class srtp-crypto lets an administrator restrict and order them.
    Configure SRTP-RTP Interworking on CUBE · Background Information / Configurations (voice class srtp-crypto) · Checked 2026-10-02
  6. 6
    On CUBE, a call falls back to RTP when one endpoint does not support SRTP only if srtp fallback is configured on the relevant dial peer; otherwise the call fails.
  7. 7
    Cisco recommends configuring SRTP fallback on CUBE SIP trunks so supplementary services that switch media, such as music on hold, transfer and re-INVITE-based hold, keep working.
    Cisco UBE Support for SRTP-RTP Internetworking (Protocol-Independent Features and Setup Configuration Guide, IOS XE Release 3S, ASR 1000) · Supplementary services (search 'Cisco recommends that you configure such SIP trunks for SRTP fallback') · Checked 2026-10-02
  8. 8
    When the secure SIP trunk from CUBE faces Cisco UCM, srtp negotiate cisco must be configured under voice service voip for non-Cisco SRTP fallback to work.
  9. 9
    CUBE SRTP-RTP interworking does not support asymmetric SRTP fallback configurations, SRTCP-RTCP interworking, or SRTP-RTP video calls.
  10. 10
    If the target adjacency of a CUBE SRTP pass-through call does not support pass-through, CUBE rejects the call with SIP 415 Unsupported Media Type, not 488.
  11. 11
    CUBE SRTP pass-through transparently passes all crypto suites, supported and unsupported, so suite agreement is left to the two endpoints.
  12. 12
    CUBE SRTP pass-through must be configured on both call legs.
  13. 13
    When CUBE SRTP pass-through is enabled, media interworking is not supported on the call.
  14. 14
    On CUBE releases that use DSP transcoders for SRTP-RTP interworking, the call falls back to RTP-RTP when no transcoding resources are available.
  15. 15
    On CUBE, show call active voice brief shows whether SRTP is on or off for each call leg, and debug voip srtp error/session plus debug ccsip are the documented troubleshooting debugs.
    Configure SRTP-RTP Interworking on CUBE · Verify; Troubleshoot · Checked 2026-10-02
  16. 16
    For SRTP-RTP interworking on CUBE, platforms running IOS require DSP resources, while platforms running IOS XE do not.
    Configure SRTP-RTP Interworking on CUBE · Background Information · Checked 2026-10-02
  17. 17
    In CUCM, SRTP on a trunk with a non-secure profile still works, but the SRTP keys are visible in signaling and traces.
    Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Trunk and Gateway SIP Security · search 'keys will be exposed in signaling and traces' · Checked 2026-10-02
  18. 18
    If MTP Required is checked on a CUCM SIP trunk, CUCM disables audio pass-through and classifies the call as non-secure.
  19. 19
    In CUCM 15, when SRTP Allowed is checked on a SIP trunk, Cisco recommends an encrypted TLS SIP trunk security profile so keys are not exposed during call negotiation.
  20. 20
    CUCM uses RTP when it cannot set up a secure path or at least one device lacks SRTP support, and SRTP-to-RTP fallback can happen during transfers to non-secure devices, conferencing, transcoding and music on hold.
  21. 21
    In Cisco's CUCM-Expressway SRTP example, CUCM lets a call fall back to unencrypted media only when the x-cisco-srtp-fallback header is present; without it CUCM treats encryption as mandatory.
    Secure RTP between CUCM and VCS or Expressway Configuration Example · Media Encryption Options > Best Effort · Checked 2026-10-02
  22. 22
    If the certificate presented in the DTLS handshake does not match the SDP fingerprint, the endpoint must tear down the media session immediately.
  23. 23
    With DTLS-SRTP the SRTP keys are negotiated in the media path by the DTLS handshake; signaling only carries certificate fingerprints, so no a=crypto key appears in SDP.
  24. 24
    A DTLS-SRTP offerer must use a=setup:actpass and be ready to receive a DTLS ClientHello before the answer arrives.
  25. 25
    The Expressway zone media encryption mode Auto, the default, applies no encryption policy and leaves encryption to what the endpoints request.
    Cisco Expressway Administrator Guide (X14.0.1) - Zones and Neighbors · Configuring Media Encryption Policy · Checked 2026-10-02
  26. 26
    Expressway enforces media encryption policy through its B2BUA, which X14.0.1 limits to 100 concurrent encryption-policy calls (500 on Large systems).
    Cisco Expressway Administrator Guide (X14.0.1) - Zones and Neighbors · Configuring Media Encryption Policy (B2BUA notes) · Checked 2026-10-02
  27. 27
    On a Cisco Expressway zone set to Best effort, encryption is used if available and media otherwise falls back to unencrypted; Force unencrypted may drop calls from encryption-required targets.
    Cisco Expressway Administrator Guide (X14.0.1) - Zones and Neighbors · Configuring Media Encryption Policy · Checked 2026-10-02
  28. 28
    On a Cisco Expressway zone set to Force encrypted, all media must be encrypted and the call is dropped if the target is configured not to use encryption.
    Cisco Expressway Administrator Guide (X14.0.1) - Zones and Neighbors · Configuring Media Encryption Policy · Checked 2026-10-02
  29. 29
    Expressway requires TLS transport on the zone for the Force encrypted and Best effort media encryption modes.
    Cisco Expressway Administrator Guide (X14.0.1) - Zones and Neighbors · Configuring Media Encryption Policy (B2BUA notes) · Checked 2026-10-02
  30. 30
    In FreeSWITCH, an unset rtp_secure_media means inbound calls accept SAVP if offered without requiring it, and outbound calls do not offer SRTP; suites can be restricted by appending a colon-separated list.
    Chapter 17: Media Handling (FreeSWITCH documentation) · Secure Media with SRTP (defaults; crypto suite syntax) · Checked 2026-10-02
  31. 31
    FreeSWITCH rtp_secure_media=mandatory accepts or offers SAVP only, optional offers and accepts both SAVP and AVP preferring SAVP, and forbidden refuses SAVP so SRTP-only offers fail.
    Chapter 17: Media Handling (FreeSWITCH documentation) · Secure Media with SRTP · Checked 2026-10-02
  32. 32
    FreeSWITCH documents AES-256 counter-mode suites as AES_CM_256_HMAC_SHA1_80 while RFC 6188 registers AES_256_CM_HMAC_SHA1_80, so a strict-matching peer may fail to recognise a suite offered under the other spelling.inferred
    Chapter 17: Media Handling (FreeSWITCH documentation) · Secure Media with SRTP (supported suite names) · Checked 2026-10-02
  33. 33
    RFC 7714 registers the SDES crypto suites AEAD_AES_128_GCM and AEAD_AES_256_GCM for AES-GCM SRTP.
  34. 34
    RFC 7714 requires the AES-GCM SRTP authentication tag to be the full 16 octets; it must not be truncated.
    RFC 7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) · search string 'MUST NOT be truncated' · Checked 2026-10-02
  35. 35
    An answerer accepts OSRTP by returning SRTP keying attributes that match one of the keying methods in the offer.
    RFC 8643: Opportunistic Secure Real-time Transport Protocol (OSRTP) · Section 3.2 (Generating the Answer) · Checked 2026-10-02
  36. 36
    An answerer declines OSRTP by omitting SRTP keying attributes from the answer, and the session then proceeds as plain RTP with no encryption or authentication.
    RFC 8643: Opportunistic Secure Real-time Transport Protocol (OSRTP) · Section 3.2 (Generating the Answer) · Checked 2026-10-02
  37. 37
    Opportunistic SRTP (OSRTP) is specified in RFC 8643, an Informational RFC published August 2019, not a standards-track document.
    RFC 8643: Opportunistic Secure Real-time Transport Protocol (OSRTP) · RFC header (Category: Informational) · Checked 2026-10-02
  38. 38
    OSRTP does not require authentication of the key agreement, so it protects against passive eavesdropping but not against active attackers.
    RFC 8643: Opportunistic Secure Real-time Transport Protocol (OSRTP) · Introduction and Security Considerations · Checked 2026-10-02
  39. 39
    An OSRTP offer uses the RTP/AVP or RTP/AVPF profile but still includes SRTP keying attributes such as a=crypto or a=fingerprint.
    RFC 8643: Opportunistic Secure Real-time Transport Protocol (OSRTP) · Section 3.1 (Generating the Initial OSRTP Offer) · Checked 2026-10-02
  40. 40
    An SDES answer carries the tag and crypto-suite of the accepted crypto attribute from the offer, so the tag in the answer identifies which offered line was chosen.
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 5.1.2 (Generating the Initial Answer - Unicast Streams) · Checked 2026-10-02
  41. 41
    Under SDES the answerer must accept exactly one of the offered crypto attributes or reject the offered media stream; there is no partial acceptance.
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 5.1.2 (Generating the Initial Answer - Unicast Streams) · Checked 2026-10-02
  42. 42
    An SDES crypto attribute has the form a=crypto:<tag> <crypto-suite> <key-params> [<session-params>], where the tag is a decimal identifier unique within the media line.
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 4 (SDP crypto attribute and parameters) · Checked 2026-10-02
  43. 43
    RFC 4568 itself defines no best-effort or fallback-to-RTP procedure, so any SRTP-to-RTP fallback seen on a trunk is vendor or profile behaviour layered on top of SDES (for example OSRTP or a vendor fallback setting).inferred
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 5.1.2 read with absence of fallback text across the document · Checked 2026-10-02
  44. 44
    The SDES inline key-params value is the base64 key||salt optionally followed by a lifetime and an MKI:length field, each separated by '|'.
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 6.1 (SRTP Key Parameter) · Checked 2026-10-02
  45. 45
    When a re-offer changes the media IP address or port, SDES requires both offerer and answerer to supply a new master key, creating a fresh crypto context.
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 7.1.4 (Modifying the Session) · Checked 2026-10-02
  46. 46
    RFC 4568 defines three SRTP crypto suites for SDES: AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32 and F8_128_HMAC_SHA1_80, all using a 30-octet key-and-salt.
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 6.2 (SRTP crypto suites) · Checked 2026-10-02
  47. 47
    Because SDES carries the SRTP master key inline in SDP, RFC 4568 requires the signaling to be protected by S/MIME, TLS, IPsec or an equivalent data security service.
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 8.3 (Signaling Authentication and Signaling Encryption) · Checked 2026-10-02
  48. 48
    SDES session parameters UNENCRYPTED_SRTP, UNENCRYPTED_SRTCP and UNAUTHENTICATED_SRTP modify the default in which SRTP and SRTCP payloads are encrypted and authenticated.
  49. 49
    In SDP offer/answer an answerer rejects an individual offered media stream by setting the port of the corresponding m-line in the answer to zero, keeping the same number of m-lines as the offer.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6 (Generating the Answer) · Checked 2026-10-02
  50. 50
    SIP 488 Not Acceptable Here indicates that the session description in the request could not be accepted by the user agent at that Request-URI, which is how an SRTP-only or crypto-incompatible offer is commonly rejected at the SIP layer.
    RFC 3261 — SIP: Session Initiation Protocol · Section 21.4.26 (488 Not Acceptable Here) · Checked 2026-10-02
  51. 51
    In media bypass, an offer from the SBC must contain SDES and may optionally also carry DTLS attributes.
    Direct Routing support for media bypass - Microsoft Teams · Format for offer from SBC in bypass mode · Checked 2026-10-02
  52. 52
    Microsoft lists the Direct Routing media transport requirement as TCP/RTP/SAVP and UDP/RTP/SAVP, i.e. secure RTP profiles rather than plain RTP/AVP.
    Plan Direct Routing · Infrastructure requirements table, row 'Media transport' · Checked 2026-10-02
  53. 53
    For Direct Routing, MKI and length parameters are not required in the SDES inline key.
    Direct Routing support for media bypass - Microsoft Teams · SRTP support requirements · Checked 2026-10-02
  54. 54
    With media bypass, the SBC must answer each non-audio m-line Teams offers (such as m=video on a forwarded call) with a matching m-line set to port zero, per RFC 3264.
    Direct Routing support for media bypass - Microsoft Teams · Handling M lines in SDP · Checked 2026-10-02
  55. 55
    Microsoft's documented SDES-only offer from Teams to the SBC lists two crypto lines, AES_CM_128_HMAC_SHA1_32 (tag 0) and AES_CM_128_HMAC_SHA1_80 (tag 1), on an RTP/SAVP m-line.
    Direct Routing support for media bypass - Microsoft Teams · Format for offer from Teams to SBC > Format for SDES only offer to SBC · Checked 2026-10-02
  56. 56
    A Direct Routing SBC must support the SRTP cipher AES_CM_128_HMAC_SHA1_80 for both offer and answer, using the inline key||salt with optional lifetime format.
    Direct Routing support for media bypass - Microsoft Teams · SRTP support requirements · Checked 2026-10-02
  57. 57
    Between the SBC and the Direct Routing media processor SDES is always used, and Media Processors convert DTLS-only clients to SDES in non-bypass calls.
    Direct Routing support for media bypass - Microsoft Teams · SDES support requirements · Checked 2026-10-02
  58. 58
    Media between a Local Gateway and Webex Calling uses SRTP, and the Webex Calling trunk dial peer is configured with the srtp command.
    Configure Local Gateway on Cisco IOS XE for Webex Calling · Introduction; dial-peer 100 configuration · Checked 2026-10-02
  59. 59
    Cisco's Local Gateway configuration for Webex Calling defines voice class srtp-crypto with only AES_CM_128_HMAC_SHA1_80, stating that Webex Calling supports only SHA1_80.
    Configure Local Gateway on Cisco IOS XE for Webex Calling · Configure Webex Calling registration-based trunk (voice class srtp-crypto step) · Checked 2026-10-02

Documents

tier 1 standards and regulators

RFC 3261 — SIP: Session Initiation Protocol

IETF / RFC Editor · 2002-06 · accessed 2026-09-04

tier 1 standards and regulators

RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)

IETF / RFC Editor · 2002-06 · accessed 2026-09-04

tier 1 standards and regulators

RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams

IETF / RFC Editor · 2006-07-01 · accessed 2026-09-23

tier 1 standards and regulators

RFC 6188: The Use of AES-192 and AES-256 in Secure RTP

IETF / RFC Editor · 2011-03-01 · accessed 2026-09-23

tier 1 standards and regulators

RFC 7714: AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)

IETF / RFC Editor · 2015-12-01 · accessed 2026-09-23

tier 1 standards and regulators

RFC 8643: Opportunistic Secure Real-time Transport Protocol (OSRTP)

IETF / RFC Editor · 2019-08-01 · accessed 2026-10-02

tier 2 current vendor documentation

Chapter 17: Media Handling (FreeSWITCH documentation)

SignalWire · 2026-10-02 · accessed 2026-10-02

tier 2 current vendor documentation

Cisco Expressway Administrator Guide (X14.0.1) - Zones and Neighbors

Cisco · 2021-06-02 · accessed 2026-10-02

tier 2 current vendor documentation

Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-SRTP Pass-Through

Cisco Systems · 2026-04-25 · accessed 2026-09-25

tier 2 current vendor documentation

Configure Local Gateway on Cisco IOS XE for Webex Calling

Cisco Systems, Inc. (Webex Help Center) · 2026-07-09 · accessed 2026-09-04

tier 2 current vendor documentation

Configure SRTP-RTP Interworking on CUBE

Cisco · 2024-10-28 · accessed 2026-09-25

tier 2 current vendor documentation

Direct Routing support for media bypass - Microsoft Teams

Microsoft Learn · 2026-09-10 · accessed 2026-09-23

tier 2 current vendor documentation

Plan Direct Routing

Microsoft (Microsoft Learn) · 2026-08-21 · accessed 2026-09-06

tier 2 current vendor documentation

Secure RTP between CUCM and VCS or Expressway Configuration Example

Cisco · 2015-04-01 · accessed 2026-10-02

tier 2 current vendor documentation

Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Trunk and Gateway SIP Security

Cisco Systems · 2026-09-22 · accessed 2026-09-24

tier 3 vendor-maintained repositories

res_pjsip - Asterisk Documentation

Sangoma / Asterisk project · accessed 2026-09-24

Cite this page

APA

WarmTransfer. (2026, October 2). Troubleshooting SRTP and crypto negotiation failures. WarmTransfer. https://warmtransfer.net/knowledge/srtp-negotiation-failures

BibTeX

@misc{warmtransfer-srtp-negotiation-failures,
  title  = {Troubleshooting SRTP and crypto negotiation failures},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/srtp-negotiation-failures},
  note   = {Verified 2026-10-02}
}