# SDP offer answer and codec negotiation

Canonical: https://warmtransfer.net/knowledge/sdp-offer-answer

Last verified: 2026-09-15

The offer-answer model defines protocol rules for establishing and modifying unicast multimedia sessions using the Session Description Protocol[^13]. The exchange operates atomically so that a rejected answer returns the session to its prior state[^8].

## How it works

An agent must not generate a new offer while an offer remains outstanding in either direction[^13]. RFC 3264 defines glare as the condition where an offer arrives after one has been sent but before its answer is received, leaving the higher-layer protocol to resolve the conflict[^13]. An initial offer may carry 0 media streams, indicating that the offerer intends to establish communication and add streams in a subsequent modified offer[^2]. For unicast sessions, offer-answer SDP relaxes RFC 2327 requirements by permitting the omission of both `e=` and `p=` lines, requiring exactly 1 session description, and recommending a time line of `0 0` with a subject line consisting of a dash or a single space[^17]. If an SDP message is sent solely to indicate capabilities, it sets every port to 0 with a unique session ID to prevent media establishment if misinterpreted as an offer or answer[^5].

In the field, modifications require that a new offer's origin line match the previous one byte for byte unless the version increments by 1, making an unincremented version a no-operation that still mandates a valid answer[^18]. Field reports suggest that the total number of media lines never decreases across session modifications: every existing stream retains its position from the top, and removed streams occupy their original slots rather than disappearing[^11]. To remove a stream, an offerer sets its media port to 0, which requires the answerer to respond with port 0 on that stream[^16]. If an answerer shares no common media format for a specific offered stream, it rejects that stream using port 0; if no format is shared for any stream, the entire session offer is rejected[^12].

## Stream direction and hold mechanics

Field reports suggest that stream direction in the answer is constrained by the offer:[^7]

| Offered direction | Permitted answer directions | Notes |
| --- | --- | --- |
| sendonly | recvonly, inactive | In the field, constrained by offer[^7] |
| recvonly | sendonly, inactive | In the field, constrained by offer[^7] |
| inactive | inactive | In the field, constrained by offer[^7] |
| sendrecv | sendrecv, sendonly, recvonly, inactive | In the field, permitted any of the 4 directions[^7] |

A sendonly stream still requires a valid connection address and port, because RTP uses the port 1 higher to receive RTCP[^1]. Hold states are applied per stream and per direction: setting a `sendrecv` stream to `sendonly` or a `recvonly` stream to `inactive` holds that stream, allowing multi-stream calls to be partially held[^10]. An answerer receiving an offer for a held stream should not mirror the held SDP back, because RFC 3264 notes that certain third-party call control scenarios fail when held SDP is answered with held SDP[^4]. Setting the connection address to `0.0.0.0` to place a stream on hold is deprecated because it breaks connection-oriented media, stops RTCP, and is incompatible with IPv6; however, agents must remain capable of receiving this address[^19].

## Codec negotiation and format parameters

Field reports suggest that media formats must be listed in order of preference starting with the most preferred format, and the offerer should select the highest-preference format returned in the answer, meaning the answerer's order determines the active codec[^9]. RFC 3264 recommends that an answerer preserve the relative format ordering of the offer unless a specific reason dictates otherwise, which helps ensure identical codecs are used in both directions[^3]. Codecs assigned a specific payload type number in the offer should retain that number in the answer[^15]. The answer must include `rtpmap` attributes for dynamic payload types and should include them for static payload types[^15].

When media formats carry configuration parameters in `fmtp`, the parameter must be echoed in the answer with an identical value if that format is retained[^6]. Non-configuration `fmtp` parameters may differ between the two endpoints[^6]. Furthermore, the answerer may specify its own packetisation interval using `ptime`, and this interval is not required to match across directions[^14].

## See also

- [SIP transactions dialogs and call setup](https://warmtransfer.net/knowledge/sip-transactions-dialogs)
- [Hold resume and conference signaling](https://warmtransfer.net/knowledge/hold-resume-conference)
- [RTP and RTCP quality metrics](https://warmtransfer.net/knowledge/rtp-rtcp-quality)
- [Early media and ringback behavior](https://warmtransfer.net/knowledge/early-media-ringback)

## Applicability

Applies to: IETF SIP. Sources checked 2026-09-15.

## What remains uncertain

What ICE, BUNDLE, and the WebRTC profile change about an offer is not covered by the sources below. Whether the products the corpus covers mirror held SDP is not covered by the sources below. Which hold convention Webex Calling and Unified CM emit is not covered by the sources below. How RFC 3398 maps a SIP status onto a Q.850 cause is not covered by the sources below. How an `fmtp` parameter is known to be a configuration rather than a parameter is not covered by the sources below.

## Sources

[^1]: The connection address and port must be present even on a sendonly stream, because in the case of RTP the port one higher is still used to receive RTCP. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 6.1 Unicast Streams. Checked 2026-09-15.
[^2]: An offer may contain zero media streams, which means the offerer wishes to communicate but intends to add the streams later in a modified offer. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 5 Generating the Initial Offer. Checked 2026-09-15.
[^3]: RFC 3264 recommends that unless there is a specific reason the answerer lists formats in the same relative order as the offer, and gives the reason: it helps assure that the same codec is used in both directions. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 6.1 Unicast Streams. Checked 2026-09-15.
[^4]: The recipient of an offer for a held stream should not automatically answer with the corresponding stream held, and RFC 3264 gives the reason: certain third party call control scenarios do not work when an answerer responds to held SDP with held SDP. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 8.4 Putting a Unicast Media Stream on Hold. Checked 2026-09-15.
[^5]: An SDP sent to indicate capabilities rather than to make an offer sets every port to zero precisely so that it cannot establish media if something interprets it as an offer or answer, and its session id must be unique for each such message. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 9 Indicating Capabilities. Checked 2026-09-15.
[^6]: An fmtp parameter that describes a specific configuration of a media format must appear in the answer with the same value if that format is kept, while an fmtp parameter that is merely a parameter may differ between the two agents. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 6.1 Unicast Streams. Checked 2026-09-15.
[^7]: The answer's direction is constrained by the offer's: a sendonly offer must be answered recvonly or inactive, a recvonly offer sendonly or inactive, an inactive offer inactive, and only a sendrecv offer may be answered with any of the four (field report). Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 6.1 Unicast Streams. Checked 2026-09-15.
[^8]: The offer answer exchange is atomic: if the answer is rejected the session reverts to the state it had before the offer, which may be the absence of a session. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 4 Protocol Operation. Checked 2026-09-15.
[^9]: Media formats must be listed in order of preference with the first being preferred, and the offerer should use the format with the highest preference from the answer, so the codec a call actually uses is chosen by the answerer's ordering and not the offerer's (field report). Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 6.1 Unicast Streams. Checked 2026-09-15.
[^10]: Hold is applied per stream and per direction: a sendrecv stream is held by marking it sendonly and a recvonly stream by marking it inactive, so a call with several streams can be half held. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 8.4 Putting a Unicast Media Stream on Hold. Checked 2026-09-15.
[^11]: The number of media lines in a session never decreases: a new offer must carry a matching media line for each one in the previous SDP, matched by position from the top, and a removed stream keeps its slot rather than disappearing (field report). Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 8 Modifying the Session. Checked 2026-09-15.
[^12]: If the answerer has no media format in common for an offered stream it must reject that stream by setting the port to zero, and if there is no format in common for any stream the entire offered session is rejected. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 6.1 Unicast Streams. Checked 2026-09-15.
[^13]: An agent must not generate a new offer while it has an offer outstanding in either direction, and an offer arriving after one has been sent but before its answer is the condition RFC 3264 calls glare, which the higher layer protocol has to resolve. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 4 Protocol Operation. Checked 2026-09-15.
[^14]: The answerer may set its own ptime for any stream to state the packetisation interval it wants to receive, and there is no requirement that the interval be the same in each direction. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 6.1 Unicast Streams. Checked 2026-09-15.
[^15]: A codec referenced with a specific payload type number in the offer should carry the same number in the answer, and even then the answer must contain rtpmap attributes for dynamic payload types and should contain them for static ones. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 6.1 Unicast Streams. Checked 2026-09-15.
[^16]: A media stream is removed by setting its port to zero in a new offer, and a stream offered with port zero must be answered with port zero. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 8.2 Removing a Media Stream. Checked 2026-09-15.
[^17]: An SDP written for offer answer may omit both the e and p lines that RFC 2327 requires, must contain exactly one session description, and for a unicast session should carry a time line of 0 0 and a subject line of a single space or a dash. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 5 Generating the Initial Offer. Checked 2026-09-15.
[^18]: A new offer's origin line must be identical to the previous one except that the version increments by one, and if the version does not increment the SDP must be byte for byte the same, so a repeated version is a no operation that still requires a valid answer (field report). Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 8 Modifying the Session. Checked 2026-09-15.
[^19]: Holding a call by setting the connection address to 0.0.0.0 is no longer recommended because it prevents RTCP on held streams, does not work with IPv6 and breaks connection oriented media, but an agent must still be capable of receiving an SDP with that address. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 8.4 Putting a Unicast Media Stream on Hold. Checked 2026-09-15.