WarmTransfer
sip media · published

SIP 488 and codec negotiation failures

Verified 2026-09-25 · 60 sources · tier 1–2

Session Description Protocol (SDP) negotiation governs the codecs and media profiles accepted across SIP sessions 3​35. When endpoints cannot agree on media parameters or encryption profiles, RFC 6337 directs the receiving user agent (UA) to reject the offer with SIP response 488, while WarmTransfer's reading of the sources is that an offer with no acceptable crypto suite also most likely yields a 488 to the INVITE 29​4.

How offer/answer negotiation works

RFC 8866 is the current SDP specification and obsoletes RFC 4566 42. An SDP answer must contain exactly the same number of m= lines as the offer, with one corresponding to each offered m= line 3. Formats on an offered m= line are listed in order of preference, where the first format listed is the most preferred 33. The answerer may reorder formats by its own preference, but RFC 3264 recommends keeping the offer's relative order unless there is a specific reason not to 2. For an accepted sendrecv, sendonly, or recvonly stream, the answer must list at least one media format that was present in the offer, and may list additional formats not offered 1.

RFC 3551 assigns static RTP payload types 0 to PCMU, 8 to PCMA, 9 to G722, and 18 to G729 47. The RTP clock rate for G722 is 8000 Hz even though G.722 samples at 16000 Hz, which is kept for backward compatibility with an error in RFC 1890 27. RTP payload types 96 to 127 constitute the dynamic range, used for formats such as telephone-event, Opus, or SILK whose mapping is established in SDP 25. A dynamically assigned payload type in SDP must be accompanied by an a=rtpmap attribute naming the format and its parameters 43. Within a media stream, the mapping of a dynamic payload type number to a codec must not change for the duration of the session 26. RFC 6337 describes call hold as an offer with a=sendonly on each held stream answered with a=recvonly, or alternatively an offer with a=inactive when the holder will send no media 28.

Offer rejection and SIP 488 handling

RFC 6337, which gives the 488 guidance for rejecting offers, is an Informational RFC rather than a standards-track specification 41. An answerer rejects an individual offered stream by setting the port of the corresponding m= line in the answer to 0 38. If the answerer has no media format in common with a particular offered stream, it must reject that stream by setting its port to 0 31. If there are no media formats in common for any of the offered streams, RFC 3264 states that the entire offered session is rejected 30.

A UA that receives an INVITE (including a re-INVITE) carrying an unacceptable offer should respond 488, preferably with a Warning header field giving the reason 29. Similarly, a UA that receives an UPDATE carrying an offer it cannot accept should respond 488, preferably with a Warning header field 60. An offer that arrives in a response (such as in a 2xx to a delayed-offer INVITE) cannot be rejected with 488; the UA should answer it and then start a new offer/answer exchange to fix parameters, or terminate the session 32. RFC 6337 also cautions that if media is already flowing using a re-INVITE's new offer, the UA should send a 2xx instead of 488 and then correct parameters with UPDATE or terminate 37.

Media encryption and transport profile mismatches

The m= line proto field distinguishes plain RTP under the audio/video profile over UDP (RTP/AVP) from SRTP over UDP (RTP/SAVP), allowing the transport profile to be negotiated separately from the codec list 35. WarmTransfer's reading of the sources is that an offer using RTP/AVP sent to a peer that only accepts SRTP (or the reverse) gives the answerer no acceptable stream even when codecs match, which can produce the same 488 or port-0 outcome as a codec mismatch 34.

Under RFC 4568, Session Description Protocol Security Descriptions (SDES) a=crypto attributes are defined only for SRTP transports such as RTP/SAVP and RTP/SAVPF, not for plain RTP/AVP 46. Because SDES carries keying material in clear SDP, RFC 4568 requires confidentiality and integrity protection of the signaling and states SIP deployments should use SIPS or S/MIME 44. If an offer carries crypto attributes but none is valid or supported, the answerer must reject that media stream 45. WarmTransfer's reading of the sources is that when every offered stream is rejected for lack of an acceptable crypto suite, the SIP-level result is most likely a 488 to the INVITE, combining RFC 4568 stream rejection with RFC 6337 offer-rejection guidance, as RFC 4568 itself names no SIP response code 4.

Microsoft Teams Direct Routing behaviors

Microsoft Direct Routing supports SILK, G.711, G.722, G.729, and AMR-WB (non-bypass only) between Teams and the SBC, and administrators can prioritize or restrict codecs on the SBC 51. The SBC-to-Teams media transport is SRTP, listed in Direct Routing infrastructure requirements as TCP/RTP/SAVP and UDP/RTP/SAVP 52. The SBC must support the SRTP cipher AES_CM_128_HMAC_SHA1_80 in both offer and answer using the inline key||salt format with optional lifetime 59. MKI and length parameters are not required in the Direct Routing crypto attribute 53. Microsoft Media Processors always prefer SDES, convert DTLS-only clients to SDES in non-bypass calls, and always use SDES on the SBC-to-Media-Processor leg 58. Microsoft's example SDES-only offer from Teams to the SBC carries two crypto lines, AES_CM_128_HMAC_SHA1_32 and AES_CM_128_HMAC_SHA1_80, on an RTP/SAVP m= line 57.

In media bypass mode, an SBC offer must contain SDES and may optionally also contain DTLS parameters 50. Furthermore, non-audio m= lines such as m=video are not stripped by the service during media bypass, and the SBC must answer each with a corresponding m= line with port 0 per RFC 3264 49. The Teams Media Processor is a B2BUA that can transcode (such as SILK toward the client and G.711 toward the SBC), whereas Transport Relays never change the codec between client and SBC 54. WarmTransfer's reading of the sources is that in a bypassed Direct Routing call the Media Processor is never in the path, so the client and SBC must share a codec directly because no Microsoft component transcodes 48. Media Processors are always in the media path for Teams voice applications such as Call Park, Auto Attendant, and Call Queues, and for web clients, even on media-bypass trunks 55. Microsoft does not support media re-targeting during an active Direct Routing call 56.

Cisco CUBE and Unified CM handling

By default, Cisco Unified Border Element (CUBE) filters codecs to the common subset and sends only the filtered codecs in its outgoing offer; the voice-class codec offer-all option sends every codec in the configured voice class instead 7. CUBE follows the codec preference order of the incoming INVITE's SDP rather than the voice class codec preference on the outgoing dial-peer 9. With voice-class codec transparent, CUBE passes only the offer unfiltered, still filters SDP in the answer, and Cisco describes only the first codec of the offer list being included in the outbound message 5. Cisco points to pass-thru content sdp as the option when CUBE should not take part in codec negotiation at all 13.

CUBE configuration imposes several restrictions:

  • CUBE does not support codec re-packetization when codec preference lists are configured, and does not support video codecs or multiple audio streams in preference lists 10.
  • Calls on CUBE that require a transcoder are not checkpointed for high availability 17.
  • CUBE does not support calls between a VAD-enabled leg and a no-VAD leg 18.
  • With SRTP pass-thru enabled, CUBE does not support media interworking, and Cisco states incoming and outgoing dial-peers must be configured symmetrically to avoid media issues 12.

On IOS XE platforms, CUBE performs SRTP-to-RTP interworking without DSP resources 16. When one endpoint does not support SRTP, a CUBE call falls back to RTP only if srtp fallback is configured on the relevant dial-peer; otherwise the call fails 15. 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 6. Crypto-suite preference on CUBE is set with voice class srtp-crypto, while the older srtp-auth command is deprecated 14. CUBE SRTP-RTP interworking does not support GCM ciphers with RTP header extensions or more than 1 video m= line 8.

In Cisco Unified Communications Manager (Unified CM), the call leg's audio codec is selected by taking the codecs both sides support, removing those above the region's maximum audio bit rate, and choosing the most preferred remaining codec from the audio codec preference list 19. Unified CM allocates transcoders and Media Termination Points (MTPs) from the Media Resource Group List (MRGL) assigned to the device or its device pool, in priority order 20. Unified CM invokes a transcoder when endpoints use different voice codecs, converting one codec stream into another such as G.711 to G.729 24. If codec conversion is required and no hardware transcoder is available, the Unified CM call fails 21. When a call needs both MTP and transcoding functions, Unified CM can allocate a transcoder because it can provide both simultaneously 23. From Unified CM 14SU3, secure MTP is supported from the gateway side for DTMF translation with IOS XE 17.10.1a or later gateways 22.

See also

Applicability

Applies to: IETF SDP offer, IETF SIP, IETF SDES, IETF RTP, IETF SDP, Microsoft Teams Phone Direct Routing, Cisco CUBE, and Cisco Unified Communications Manager. Deployments: on-premises, multi-tenant, dedicated instance, and any. Sources checked 2026-09-25. From IOS XE Everest 16.5.1b, CUBE enables default crypto suites 6. Secure MTP is supported from Unified CM 14SU3 with IOS XE 17.10.1a or later gateways 22.

What remains uncertain

Whether specific SBC vendors return alternative SIP 4xx or 5xx status codes instead of 488 when dynamic payload type collisions occur is not covered by the sources below.

See also

Referenced by

  • Unified CM media resources — Codec mismatches that Unified CM resolves by inserting a transcoder from the MRGL; a missing transcoder is one path to a failed call

Sources

  1. 1
    For an accepted sendrecv, sendonly or recvonly stream the answer must list at least one media format that was in the offer, and may list additional formats not offered.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 Unicast Streams · Checked 2026-09-25
  2. 2
    The answerer may reorder formats by its own preference but RFC 3264 recommends keeping the offer's relative order unless there is a specific reason not to.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 Unicast Streams · Checked 2026-09-25
  3. 3
    An SDP answer must contain exactly the same number of m= lines as the offer, one corresponding to each offered m= line.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6 Generating the Answer · Checked 2026-09-25
  4. 4
    When every offered stream is rejected for lack of an acceptable crypto suite, the SIP-level result is most likely a 488 to the INVITE, by combining RFC 4568 stream rejection with RFC 6337 offer-rejection guidance; RFC 4568 itself names no SIP response code.inferred
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 5.1.2 combined with RFC 6337 Section 2.3 · Checked 2026-09-25
  5. 5
    With voice-class codec transparent, CUBE passes only the offer unfiltered; it still filters SDP in the answer, and Cisco describes only the first codec of the offer list being included in the outbound message.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Introduction to Codecs · Introduction to Codecs - Restrictions · Checked 2026-09-25
  6. 6
    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.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-RTP Internetworking · SRTP-RTP Internetworking - supported crypto suites · Checked 2026-09-25
  7. 7
    By default CUBE filters codecs to the common subset and sends only the filtered codecs in its outgoing offer; the voice-class codec offer-all option sends every codec in the configured voice class instead.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Codec Preference Lists · Codec Preference Lists - Overview / offer-all description · Checked 2026-09-25
  8. 8
    CUBE SRTP-RTP interworking does not support GCM ciphers with RTP header extensions or more than one video m= line.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-RTP Internetworking · SRTP-RTP Internetworking - Restrictions · Checked 2026-09-25
  9. 9
    CUBE follows the codec preference order of the incoming INVITE's SDP rather than the voice class codec preference on the outgoing dial-peer.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Codec Preference Lists · Codec Preference Lists - section on incoming offer preference · Checked 2026-09-25
  10. 10
    CUBE does not support codec re-packetization when codec preference lists are configured, and does not support video codecs or multiple audio streams in preference lists.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Codec Preference Lists · Codec Preference Lists - Restrictions · Checked 2026-09-25
  11. 11
    Cisco's SRTP pass-through overview says that if the target adjacency does not support SRTP pass-through the call is rejected with 415 Unsupported Media Type, so an SRTP failure on CUBE can surface as a 415 rather than a 488.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-SRTP Pass-Through · SRTP-SRTP Pass-Through - Overview · Checked 2026-09-25
  12. 12
    With SRTP pass-thru enabled CUBE does not support media interworking, and Cisco says incoming and outgoing dial-peers must be configured symmetrically to avoid media issues.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-SRTP Pass-Through · SRTP-SRTP Pass-Through - Restrictions · Checked 2026-09-25
  13. 13
    Cisco points to pass-thru content sdp as the option when CUBE should not take part in codec negotiation at all.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Introduction to Codecs · Introduction to Codecs - Restrictions · Checked 2026-09-25
  14. 14
    Crypto-suite preference on CUBE is set with voice class srtp-crypto; the older srtp-auth command is deprecated.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-RTP Internetworking · SRTP-RTP Internetworking - crypto suite configuration · Checked 2026-09-25
  15. 15
    When one endpoint does not support SRTP, a CUBE call falls back to RTP only if srtp fallback is configured on the relevant dial-peer; otherwise the call fails.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-RTP Internetworking · SRTP-RTP Internetworking - fallback handling · Checked 2026-09-25
  16. 16
    On IOS XE platforms CUBE performs SRTP-to-RTP interworking without DSP resources.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-RTP Internetworking · SRTP-RTP Internetworking - platform/DSP note · Checked 2026-09-25
  17. 17
    Calls on CUBE that require a transcoder are not checkpointed for high availability.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Codec Preference Lists · Codec Preference Lists - Restrictions · Checked 2026-09-25
  18. 18
    CUBE does not support calls between a VAD-enabled leg and a no-VAD leg.
    Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Introduction to Codecs · Introduction to Codecs - Restrictions · Checked 2026-09-25
  19. 19
    Unified CM picks a call leg's audio codec by taking the codecs both sides support, removing those above the region's maximum audio bit rate, and then choosing the most preferred remaining codec from the audio codec preference list.
    System Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Configure Core Settings for Device Pools · Configure Core Settings for Device Pools - Regions / audio codec selection · Checked 2026-09-25
  20. 20
    Unified CM allocates transcoders and MTPs from the Media Resource Group List assigned to the device or its device pool, in priority order.
    System Configuration Guide for Cisco Unified Communications Manager Release 15 and SUs - Configure Media Resources · Configure Media Resources - Media Resource Group Lists · Checked 2026-09-25
  21. 21
    If codec conversion is required and no hardware transcoder is available, the Unified CM call fails.
    System Configuration Guide for Cisco Unified Communications Manager Release 15 and SUs - Configure Media Resources · Configure Media Resources - Transcoders · Checked 2026-09-25
  22. 22
    From Unified CM 14SU3, secure MTP is supported from the gateway side for DTMF translation with IOS XE 17.10.1a or later gateways.
    System Configuration Guide for Cisco Unified Communications Manager Release 15 and SUs - Configure Media Resources · Configure Media Resources - Media Termination Points (secure MTP note) · Checked 2026-09-25
  23. 23
    When a call needs both MTP and transcoding functions Unified CM can allocate a transcoder, because a transcoder can provide both at the same time.
    System Configuration Guide for Cisco Unified Communications Manager Release 15 and SUs - Configure Media Resources · Configure Media Resources - Transcoders / MTP · Checked 2026-09-25
  24. 24
    Unified CM invokes a transcoder when the endpoints in a call use different voice codecs, converting one codec stream into another such as G.711 to G.729.
    System Configuration Guide for Cisco Unified Communications Manager Release 15 and SUs - Configure Media Resources · Configure Media Resources - Transcoders · Checked 2026-09-25
  25. 25
    RTP payload types 96 to 127 are the dynamic range, used for codecs such as telephone-event, Opus or SILK whose mapping is set in SDP.
    RTP Profile for Audio and Video Conferences with Minimal Control · Section 3 (dynamic payload type range) · Checked 2026-09-25
  26. 26
    Within a media stream the mapping of a dynamic payload type number to a codec must not change for the duration of the session.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 8.3.2 Changing the Set of Media Formats · Checked 2026-09-25
  27. 27
    The RTP clock rate for G722 is 8000 Hz even though G.722 samples at 16000 Hz, kept for backward compatibility with an error in RFC 1890.
    RTP Profile for Audio and Video Conferences with Minimal Control · Section 4.5.2 G722 · Checked 2026-09-25
  28. 28
    RFC 6337 describes hold as an offer with a=sendonly on each held stream answered with a=recvonly, or alternatively an offer with a=inactive when the holder will send no media.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 5.3 Hold and Resume of Media · Checked 2026-09-25
  29. 29
    A UA that receives an INVITE (including a re-INVITE) carrying an unacceptable offer should respond 488, preferably with a Warning header field giving the reason.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 2.3 Rejection of an Offer · Checked 2026-09-25
  30. 30
    If there are no media formats in common for any of the offered streams, RFC 3264 says the entire offered session is rejected.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 Unicast Streams · Checked 2026-09-25
  31. 31
    If the answerer has no media format in common with a particular offered stream it must reject that stream by setting its port to zero.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6.1 Unicast Streams · Checked 2026-09-25
  32. 32
    An offer that arrives in a response (for example in a 2xx to a delayed-offer INVITE) cannot be rejected with 488; the UA should answer it and then start a new offer/answer exchange to fix parameters, or terminate the session.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 2.3 Rejection of an Offer · Checked 2026-09-25
  33. 33
    Formats on an offered m= line are listed in order of preference, with the first format listed being the most preferred.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 5.1 Unicast Streams (Generating the Initial Offer) · Checked 2026-09-25
  34. 34
    An offer using RTP/AVP sent to a peer that only accepts SRTP (or the reverse) gives the answerer no acceptable stream even when codecs match, so a profile mismatch can produce the same 488 or port-zero outcome as a codec mismatch.inferred
    SDP: Session Description Protocol · Section 5.14 combined with RFC 3264 Section 6 and RFC 6337 Section 2.3 · Checked 2026-09-25
  35. 35
    The m= line proto field distinguishes RTP/AVP (plain RTP under the audio/video profile over UDP) from RTP/SAVP (SRTP over UDP), so the transport profile is negotiated separately from the codec list.
    SDP: Session Description Protocol · Section 5.14 Media Descriptions (m=) · Checked 2026-09-25
  36. 36
    Under RFC 3261 a failed re-INVITE does not tear down the existing call; the session continues with the previously negotiated characteristics.
    RFC 3261 — SIP: Session Initiation Protocol · Section 14.2 UAS Behavior · Checked 2026-09-25
  37. 37
    RFC 6337 cautions that if media is already flowing using a re-INVITE's new offer, the UA should send a 2xx instead of 488 and then correct parameters with UPDATE or terminate.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 2.3 Rejection of an Offer · Checked 2026-09-25
  38. 38
    An answerer rejects an individual offered stream by setting the port of the corresponding m= line in the answer to zero.
    RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP) · Section 6 Generating the Answer · Checked 2026-09-25
  39. 39
    RFC 3261 defines 415 Unsupported Media Type as the server refusing a request because the message body is in a format the server does not support for that method; it concerns the body type (for example the Content-Type) rather than codecs inside SDP.
    RFC 3261 — SIP: Session Initiation Protocol · Section 21.4.13 415 Unsupported Media Type · Checked 2026-09-25
  40. 40
    RFC 3261 defines 488 Not Acceptable Here in section 21.4.26 as a 4xx rejection of the session description offered in the request, scoped to the addressed resource, with 606 Not Acceptable in section 21.6.4 as its global-failure counterpart.
    RFC 3261 — SIP: Session Initiation Protocol · Section 21.4.26 488 Not Acceptable Here; Section 21.6.4 606 Not Acceptable · Checked 2026-09-25
  41. 41
    RFC 6337, which gives the 488 guidance for rejecting offers, is an Informational RFC rather than a standards-track specification.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Status of This Memo · Checked 2026-09-25
  42. 42
    RFC 8866 is the current SDP specification and obsoletes RFC 4566.
    SDP: Session Description Protocol · Abstract / header (Obsoletes: 4566) · Checked 2026-09-25
  43. 43
    A dynamically assigned payload type in SDP must be accompanied by an a=rtpmap attribute naming the format and its parameters.
    SDP: Session Description Protocol · Section 5.14 Media Descriptions (m=) · Checked 2026-09-25
  44. 44
    Because SDES carries keying material in clear SDP, RFC 4568 requires confidentiality and integrity protection of the signaling and says SIP deployments should use SIPS or S/MIME.
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 3 Applicability; Section 8.3 · Checked 2026-09-25
  45. 45
    If an offer carries crypto attributes but none is valid or supported, the answerer must reject that media stream.
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 5.1.2 Generating the Initial Answer - Unicast Streams · Checked 2026-09-25
  46. 46
    SDES a=crypto attributes are defined only for SRTP transports such as RTP/SAVP and RTP/SAVPF, not for plain RTP/AVP.
    RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams · Section 6 SRTP Security Descriptions · Checked 2026-09-25
  47. 47
    RFC 3551 assigns static RTP payload types 0 to PCMU, 8 to PCMA, 9 to G722 and 18 to G729.
    RTP Profile for Audio and Video Conferences with Minimal Control · Section 6 Table 4 · Checked 2026-09-25
  48. 48
    In a bypassed Direct Routing call the Media Processor is never in the path, so the client and SBC must share a codec directly because no Microsoft component transcodes.inferred
    Plan for media bypass with Direct Routing · Section Use of Media Processors and Transport Relays (comparison table) · Checked 2026-09-25
  49. 49
    With media bypass, non-audio m= lines such as m=video are not stripped by the service, and the SBC must answer each with a corresponding m= line with port zero per RFC 3264.
    Direct Routing support for media bypass - Microsoft Teams · Section Handling M lines in SDP · Checked 2026-09-25
  50. 50
    In media bypass mode an SBC offer must contain SDES and may optionally also contain DTLS parameters.
    Direct Routing support for media bypass - Microsoft Teams · Section Format for offer from SBC in bypass mode · Checked 2026-09-25
  51. 51
    Microsoft lists SILK, G.711, G.722, G.729 and AMR-WB (non-bypass only) as the codecs Direct Routing supports between Teams and the SBC, and says administrators can prioritize or restrict codecs on the SBC.
    Plan Direct Routing · Section Supported codecs · Checked 2026-09-25
  52. 52
    Microsoft's Direct Routing infrastructure table lists media transport as TCP/RTP/SAVP and UDP/RTP/SAVP, meaning the SBC-to-Teams media leg is SRTP.
    Plan Direct Routing · Section Infrastructure requirements, row Media transport · Checked 2026-09-25
  53. 53
    Microsoft states that MKI and length parameters are not required in the Direct Routing crypto attribute.
    Direct Routing support for media bypass - Microsoft Teams · Section SRTP support requirements · Checked 2026-09-25
  54. 54
    The Teams Media Processor is a B2BUA that can transcode (for example SILK toward the client and G.711 toward the SBC), whereas Transport Relays never change the codec between client and SBC.
    Plan for media bypass with Direct Routing · Section Use of Media Processors and Transport Relays (transcoding explanation note) · Checked 2026-09-25
  55. 55
    Media Processors are always in the media path for Teams voice applications such as Call Park, Auto Attendant and Call Queues, and for web clients, even on media-bypass trunks.
    Plan for media bypass with Direct Routing · Sections Use of Media Processors and Transport Relays; Requirements for using media processors · Checked 2026-09-25
  56. 56
    Microsoft does not support media re-targeting during an active Direct Routing call.
    Plan Direct Routing · Section Supported codecs (Note) · Checked 2026-09-25
  57. 57
    Microsoft's example SDES-only offer from Teams to the SBC carries two crypto lines, AES_CM_128_HMAC_SHA1_32 and AES_CM_128_HMAC_SHA1_80, on an RTP/SAVP m= line.
    Direct Routing support for media bypass - Microsoft Teams · Section Format for SDES only offer to SBC (example block) · Checked 2026-09-25
  58. 58
    Microsoft Media Processors always prefer SDES, convert DTLS-only clients to SDES in non-bypass calls, and always use SDES on the SBC-to-Media-Processor leg.
    Direct Routing support for media bypass - Microsoft Teams · Section SDES support requirements · Checked 2026-09-25
  59. 59
    For Direct Routing the SBC must support SRTP cipher AES_CM_128_HMAC_SHA1_80 in both offer and answer using the inline key||salt format with optional lifetime.
    Direct Routing support for media bypass - Microsoft Teams · Section SRTP support requirements · Checked 2026-09-25
  60. 60
    A UA that receives an UPDATE carrying an offer it cannot accept should respond 488, preferably with a Warning header field giving the reason.
    RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model · Section 2.3 Rejection of an Offer · Checked 2026-09-25

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 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model

IETF / RFC Editor · 2011-08-01 · accessed 2026-09-24

tier 1 standards and regulators

RTP Profile for Audio and Video Conferences with Minimal Control

IETF / RFC Editor · 2003-07-01 · accessed 2026-09-24

tier 1 standards and regulators

SDP: Session Description Protocol

IETF / RFC Editor · 2021-01-01 · accessed 2026-09-24

tier 2 current vendor documentation

Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Codec Preference Lists

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

tier 2 current vendor documentation

Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Introduction to Codecs

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

tier 2 current vendor documentation

Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SRTP-RTP Internetworking

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

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

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

Plan for media bypass with Direct Routing

Microsoft · 2026-09-10 · accessed 2026-09-16

tier 2 current vendor documentation

System Configuration Guide for Cisco Unified Communications Manager Release 15 and SUs - Configure Media Resources

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

tier 2 current vendor documentation

System Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Configure Core Settings for Device Pools

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

Cite this page

APA

WarmTransfer. (2026, September 25). SIP 488 and codec negotiation failures. WarmTransfer. https://warmtransfer.net/knowledge/sip-488-codec-failures

BibTeX

@misc{warmtransfer-sip-488-codec-failures,
  title  = {SIP 488 and codec negotiation failures},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/sip-488-codec-failures},
  note   = {Verified 2026-09-25}
}