Source record · tier 1 standards and regulators

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

Publisher: IETF / RFC Editor
URL: https://www.rfc-editor.org/rfc/rfc3264.html
Published: 2002-06
Updated: unknown
Accessed: 2026-09-04
HTTP status: 200
License: IETF Trust / BCP 78; permitted with the RFC's own copyright and license notices intact

Source notes citing this source

Under RFC 3264 an answer to a stream offered as inactive MUST mark that stream inactive. in context
Under RFC 3264 an answer to a stream offered as recvonly MUST mark that stream sendonly or inactive. in context
Under RFC 3264 an answer to a stream offered as sendonly MUST mark that stream recvonly or inactive. in context
Under RFC 3264 an answer to a stream offered as sendrecv MAY mark that stream sendonly or recvonly or sendrecv or inactive. in context
Under RFC 3264 a media stream that was previously recvonly is placed on hold by marking it inactive. in context
Under RFC 3264 a media stream that was previously sendrecv is placed on hold by marking it sendonly in a new offer. in context
Under RFC 3264 an offerer that wants to keep the session but neither send nor receive media on a stream MUST mark that stream inactive. in context
Under RFC 3264 a modified SDP must contain at least as many m= lines as the previous SDP. in context
RFC 3264 says the recipient of an offer that puts a stream on hold SHOULD NOT automatically answer with its own side of that stream on hold. in context
RFC 3264 lists RFC 2543 as obsoleted. in context
Under RFC 3264 a modified offer such as a hold or resume offer must increment the version in the SDP origin (o=) line by exactly one from the previous SDP. in context
RFC 3264 states that for RTP media RTCP is still sent and received on sendonly and recvonly and inactive streams. in context
RFC 3264 requires an agent to be capable of receiving SDP with connection address 0.0.0.0 and to treat it as meaning neither RTP nor RTCP should be sent to the peer. in context
RFC 3264 says using connection address 0.0.0.0 to put a call on hold is no longer recommended because it prevents RTCP on held streams and does not work with IPv6 and breaks connection-oriented media. in context
RFC 3264 says RTCP is still sent and received on sendonly, recvonly and inactive RTP streams. Seeing RTCP therefore does not mean media is flowing in both directions. in context
Under RFC 3264, a media stream with no direction attribute is treated as sendrecv. in context
Under RFC 3264, if an offer marks a stream sendonly, the answer must mark it recvonly or inactive. If the offer marks it recvonly, the answer must mark it sendonly or inactive. in context
RFC 3264 no longer recommends setting the connection address to 0.0.0.0 to signal hold (the RFC 2543 method), but agents must still handle it. When it is received, neither RTP nor RTCP should be sent to the peer. in context
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. in context
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. in context
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. in context
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. in context
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. in context
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. in context
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 in context
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. in context
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 in context
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. in context
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 in context
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. in context
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. in context
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. in context
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. in context
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. in context
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. in context
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 in context
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. in context
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. in context
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. in context
An SDP answer must contain exactly the same number of m= lines as the offer, one corresponding to each offered m= line. in context
Within a media stream the mapping of a dynamic payload type number to a codec must not change for the duration of the session. in context
If there are no media formats in common for any of the offered streams, RFC 3264 says the entire offered session is rejected. in context
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. in context
Formats on an offered m= line are listed in order of preference, with the first format listed being the most preferred. in context
An answerer rejects an individual offered stream by setting the port of the corresponding m= line in the answer to zero. in context
With no direction attribute a stream is sendrecv; a stream offered as sendonly must be answered as recvonly or inactive. in context
A sendrecv stream is put on hold by re-offering it as sendonly; the older method of setting the connection address to 0.0.0.0 is no longer recommended. in context
In SDP offer/answer the answer must contain exactly the same number of m= lines as the offer, one per offered stream. in context
An answerer rejects an offered media stream by setting the port of the corresponding m= line in the answer to zero. in context

Cite this source record

APA

WarmTransfer. (n.d.). RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP). WarmTransfer. https://warmtransfer.net/knowledge/sources/rfc-3264-offer-answer

BibTeX

@misc{warmtransfer-rfc-3264-offer-answer,
  title  = {RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)},
  author = {{WarmTransfer}},
  year   = {2002},
  url    = {https://warmtransfer.net/knowledge/sources/rfc-3264-offer-answer},
  note   = {IETF / RFC Editor, accessed 2026-09-04}
}