RFC relevance of indicate

As per Relevance of the word indicate, we have this rfc below:

Network Working Group J.
Request for Comments: 3264
Obsoletes: 2543 H.
Category: Standards Track Columbia U
June 2002

An Offer/Answer Model with the Session Description Protocol (SDP

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2002). All Rights Reserved

This document defines a mechanism by which two entities can make
of the Session Description Protocol (SDP) to arrive at a common
of a multimedia session between them. In the model, one
offers the other a description of the desired session from
perspective, and the other participant answers with the
session from their perspective. This offer/answer model is
useful in unicast sessions where information from both
is needed for the complete view of the session. The offer/
model is used by protocols like the Session Initiation
(SIP).

Table of

1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 Definitions ......................................... 3
4 Protocol Operation .................................. 4
5 Generating the Initial Offer ........................ 5
5.1 Unicast Streams ..................................... 5
5.2 Multicast Streams ................................... 8
6 Generating the Answer ............................... 9
6.1 Unicast Streams ..................................... 9
6.2 Multicast Streams ................................... 12
7 Offerer Processing of the Answer .................... 12
8 Modifying the Session ............................... 13

Rosenberg & Schulzrinne Standards Track [Page 1]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

8.1 Adding a Media Stream ............................... 13
8.2 Removing a Media Stream ............................. 14
8.3 Modifying a Media Stream ............................ 14
8.3.1 Modifying Address, Port or Transport ................ 14
8.3.2 Changing the Set of Media Formats ................... 15
8.3.3 Changing Media Types ................................ 17
8.3.4 Changing Attributes ................................. 17
8.4 Putting a Unicast Media Stream on Hold .............. 17
9 Indicating Capabilities ............................. 18
10 Example Offer/Answer Exchanges ...................... 19
10.1 Basic Exchange ...................................... 19
10.2 One of N Codec Selection ............................ 21
11 Security Considerations ............................. 23
12 IANA Considerations ................................. 23
13 Acknowledgements .................................... 23
14 Normative References ................................ 23
15 Informative References .............................. 24
16 Authors' Addresses .................................. 24
17 Full Copyright Statement............................. 25

1

The Session Description Protocol (SDP) [1] was originally
as a way to describe multicast sessions carried on the Mbone.
Session Announcement Protocol (SAP) [6] was devised as a
mechanism to carry SDP messages. Although the SDP
allows for unicast operation, it is not complete. Unlike multicast
where there is a global view of the session that is used by
participants, unicast sessions involve two participants, and
complete view of the session requires information from
participants, and agreement on parameters between them

As an example, a multicast session requires conveying a
multicast address for a particular media stream. However, for
unicast session, two addresses are needed - one for each participant
As another example, a multicast session requires an indication
which codecs will be used in the session. However, for unicast,
set of codecs needs to be determined by finding an overlap in the
supported by each participant

As a result, even though SDP has the expressiveness to
unicast sessions, it is missing the semantics and operational
of how it is actually done. In this document, we remedy that
defining a simple offer/answer model based on SDP. In this model
one participant in the session generates an SDP message
constitutes the offer - the set of media streams and codecs
offerer wishes to use, along with the IP addresses and ports
offerer would like to use to receive the media. The offer

Rosenberg & Schulzrinne Standards Track [Page 2]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

conveyed to the other participant, called the answerer. The
generates an answer, which is an SDP message that responds to
offer provided by the offerer. The answer has a matching
stream for each stream in the offer, indicating whether the stream
accepted or not, along with the codecs that will be used and the
addresses and ports that the answerer wants to use to receive media

It is also possible for a multicast session to work similar to
unicast one; its parameters are negotiated between a pair of users
in the unicast case, but both sides send packets to the
multicast address, rather than unicast ones. This document
discusses the application of the offer/answer model to
streams

We also define guidelines for how the offer/answer model is used
update a session after an initial offer/answer exchange

The means by which the offers and answers are conveyed are
the scope of this document. The offer/answer model defined here
the mandatory baseline mechanism used by the Session
Protocol (SIP) [7].

2

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2]
indicate requirement levels for compliant implementations

3

The following terms are used throughout this document

Agent: An agent is the protocol implementation involved in
offer/answer exchange. There are two agents involved in
offer/answer exchange

Answer: An SDP message sent by an answerer in response to an
received from an offerer

Answerer: An agent which receives a session description
another agent describing aspects of desired
communication, and then responds to that with its own
description

Rosenberg & Schulzrinne Standards Track [Page 3]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

Media Stream: From RTSP [8], a media stream is a single
instance, e.g., an audio stream or a video stream as well as
single whiteboard or shared application group. In SDP, a
stream is described by an "m=" line and its
attributes

Offer: An SDP message sent by an offerer

Offerer: An agent which generates a session description in
to create or modify a session

4 Protocol

The offer/answer exchange assumes the existence of a higher
protocol (such as SIP) which is capable of exchanging SDP for
purposes of session establishment between agents

Protocol operation begins when one agent sends an initial offer
another agent. An offer is initial if it is outside of any
that may have already been established through the higher
protocol. It is assumed that the higher layer protocol
maintenance of some kind of context which allows the various
exchanges to be associated together

The agent receiving the offer MAY generate an answer, or it
reject the offer. The means for rejecting an offer are dependent
the higher layer protocol. The offer/answer exchange is atomic;
the answer is rejected, the session reverts to the state prior to
offer (which may be absence of a session).

At any time, either agent MAY generate a new offer that updates
session. However, it MUST NOT generate a new offer if it
received an offer which it has not yet answered or rejected
Furthermore, it MUST NOT generate a new offer if it has generated
prior offer for which it has not yet received an answer or
rejection. If an agent receives an offer after having sent one,
before receiving an answer to it, this is considered a "glare
condition

The term glare was originally used in circuit
telecommunications networks to describe the condition where
switches both attempt to seize the same available circuit on
same trunk at the same time. Here, it means both agents
attempted to send an updated offer at the same time

Rosenberg & Schulzrinne Standards Track [Page 4]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

The higher layer protocol needs to provide a means for resolving
conditions. The higher layer protocol will need to provide a
for ordering of messages in each direction. SIP meets
requirements [7].

5 Generating the Initial

The offer (and answer) MUST be a valid SDP message, as defined by
2327 [1], with one exception. RFC 2327 mandates that either an e
a p line is present in the SDP message. This specification
that constraint; an SDP formulated for an offer/answer
MAY omit both the e and p lines. The numeric value of the session
and version in the o line MUST be representable with a 64 bit
integer. The initial value of the version MUST be less
(2**62)-1, to avoid rollovers. Although the SDP specification
for multiple session descriptions to be concatenated together into
large SDP message, an SDP message used in the offer/answer model
contain exactly one session description

The SDP "s=" line conveys the subject of the session, which
reasonably defined for multicast, but ill defined for unicast.
unicast sessions, it is RECOMMENDED that it consist of a single
character (0x20) or a dash (-).

Unfortunately, SDP does not allow the "s=" line to be empty

The SDP "t=" line conveys the time of the session. Generally
streams for unicast sessions are created and destroyed
external signaling means, such as SIP. In that case, the "t="
SHOULD have a value of "0 0".

The offer will contain zero or more media streams (each media
is described by an "m=" line and its associated attributes).
media streams implies that the offerer wishes to communicate,
that the streams for the session will be added at a later
through a modified offer. The streams MAY be for a mix of
and multicast; the latter obviously implies a multicast address
the relevant "c=" line(s).

Construction of each offered stream depends on whether the stream
multicast or unicast

5.1 Unicast

If the offerer wishes to only send media on a stream to its peer,
MUST mark the stream as sendonly with the "a=sendonly" attribute.
refer to a stream as being marked with a certain direction if
direction attribute was present as either a media stream attribute

Rosenberg & Schulzrinne Standards Track [Page 5]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

a session attribute. If the offerer wishes to only receive
from its peer, it MUST mark the stream as recvonly. If the
wishes to communicate, but wishes to neither send nor receive
at this time, it MUST mark the stream with an "a=inactive" attribute
The inactive direction attribute is specified in RFC 3108 [3].
that in the case of the Real Time Transport Protocol (RTP) [4],
is still sent and received for sendonly, recvonly, and
streams. That is, the directionality of the media stream has
impact on the RTCP usage. If the offerer wishes to both send
receive media with its peer, it MAY include an "a=sendrecv
attribute, or it MAY omit it, since sendrecv is the default

For recvonly and sendrecv streams, the port number and address in
offer indicate where the offerer would like to receive the
stream. For sendonly RTP streams, the address and port
indirectly indicate where the offerer wants to receive RTCP reports
Unless there is an explicit indication otherwise, reports are sent
the port number one higher than the number indicated. The IP
and port present in the offer indicate nothing about the source
address and source port of RTP and RTCP packets that will be sent
the offerer. A port number of zero in the offer indicates that
stream is offered but MUST NOT be used. This has no useful
in an initial offer, but is allowed for reasons of completeness
since the answer can contain a zero port indicating a rejected
(Section 6). Furthermore, existing streams can be terminated
setting the port to zero (Section 8). In general, a port number
zero indicates that the media stream is not wanted

The list of media formats for each media stream conveys two pieces
information, namely the set of formats (codecs and any
associated with the codec, in the case of RTP) that the offerer
capable of sending and/or receiving (depending on the
attributes), and, in the case of RTP, the RTP payload type
used to identify those formats. If multiple formats are listed,
means that the offerer is capable of making use of any of
formats during the session. In other words, the answerer MAY
formats in the middle of the session, making use of any of
formats listed, without sending a new offer. For a sendonly stream
the offer SHOULD indicate those formats the offerer is willing
send for this stream. For a recvonly stream, the offer
indicate those formats the offerer is willing to receive for
stream. For a sendrecv stream, the offer SHOULD indicate
codecs that the offerer is willing to send and receive with

For recvonly RTP streams, the payload type numbers indicate the
of the payload type field in RTP packets the offerer is expecting
receive for that codec. For sendonly RTP streams, the payload
numbers indicate the value of the payload type field in RTP

Rosenberg & Schulzrinne Standards Track [Page 6]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

the offerer is planning to send for that codec. For sendrecv
streams, the payload type numbers indicate the value of the
type field the offerer expects to receive, and would prefer to send
However, for sendonly and sendrecv streams, the answer might
different payload type numbers for the same codecs, in which case
the offerer MUST send with the payload type numbers from the answer

Different payload type numbers may be needed in each
because of interoperability concerns with H.323.

As per RFC 2327, fmtp parameters MAY be present to provide
parameters of the media format

In the case of RTP streams, all media descriptions SHOULD
"a=rtpmap" mappings from RTP payload types to encodings. If there
no "a=rtpmap", the default payload type mapping, as defined by
current profile in use (for example, RFC 1890 [5]) is to be used

This allows easier migration away from static payload types

In all cases, the formats in the "m=" line MUST be listed in order
preference, with the first format listed being preferred. In
case, preferred means that the recipient of the offer SHOULD use
format with the highest preference that is acceptable to it

If the ptime attribute is present for a stream, it indicates
desired packetization interval that the offerer would like
receive. The ptime attribute MUST be greater than zero

If the bandwidth attribute is present for a stream, it indicates
desired bandwidth that the offerer would like to receive. A value
zero is allowed, but discouraged. It indicates that no media
be sent. In the case of RTP, it would also disable all RTCP

If multiple media streams of different types are present, it
that the offerer wishes to use those streams at the same time.
typical case is an audio and a video stream as part of
videoconference

If multiple media streams of the same type are present in an offer
it means that the offerer wishes to send (and/or receive)
streams of that type at the same time. When sending multiple
of the same type, it is a matter of local policy as to how each
source of that type (for example, a video camera and VCR in the
of video) is mapped to each stream. When a user has a single
for a particular media type, only one policy makes sense: the
is sent to each stream of the same type. Each stream MAY
different encodings. When receiving multiple streams of the

Rosenberg & Schulzrinne Standards Track [Page 7]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

type, it is a matter of local policy as to how each stream is
to the various media sinks for that particular type (for example
speakers or a recording device in the case of audio). There are
few constraints on the policies, however. First, when
multiple streams of the same type, each stream MUST be mapped to
least one sink for the purpose of presentation to the user. In
words, the intent of receiving multiple streams of the same type
that they should all be presented in parallel, rather than
just one. Another constraint is that when multiple streams
received and sent to the same sink, they MUST be combined in
media specific way. For example, in the case of two audio streams
the received media from each might be mapped to the speakers.
that case, the combining operation would be to mix them. In the
of multiple instant messaging streams, where the sink is the screen
the combining operation would be to present all of them to the
interface. The third constraint is that if multiple sources
mapped to the same stream, those sources MUST be combined in
media specific way before they are sent on the stream.
policies beyond these constraints are flexible, an agent won'
generally want a policy that will copy media from its sinks to
sources unless it is a conference server (i.e., don't copy
media on one stream to another stream).

A typical usage example for multiple media streams of the same
is a pre-paid calling card application, where the user can press
hold the pound ("#") key at any time during a call to hangup and
a new call on the same card. This requires media from the user
two destinations - the remote gateway, and the DTMF
application which looks for the pound. This could be
with two media streams, one sendrecv to the gateway, and the
sendonly (from the perspective of the user) to the DTMF application

Once the offerer has sent the offer, it MUST be prepared to
media for any recvonly streams described by that offer. It MUST
prepared to send and receive media for any sendrecv streams in
offer, and send media for any sendonly streams in the offer (
course, it cannot actually send until the peer provides an
with the needed address and port information). In the case of RTP
even though it may receive media before the answer arrives, it
not be able to send RTCP receiver reports until the answer arrives

5.2 Multicast

If a session description contains a multicast media stream which
listed as receive (send) only, it means that the participants
including the offerer and answerer, can only receive (send) on
stream. This differs from the unicast view, where the
refers to the flow of media between offerer and answerer

Rosenberg & Schulzrinne Standards Track [Page 8]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

Beyond that clarification, the semantics of an offered
stream are exactly as described in RFC 2327 [1].

6 Generating the

The answer to an offered session description is based on the
session description. If the answer is different from the offer
any way (different IP addresses, ports, etc.), the origin line
be different in the answer, since the answer is generated by
different entity. In that case, the version number in the "o="
of the answer is unrelated to the version number in the o line of
offer

For each "m=" line in the offer, there MUST be a corresponding "m="
line in the answer. The answer MUST contain exactly the same
of "m=" lines as the offer. This allows for streams to be matched
based on their order. This implies that if the offer contained
"m=" lines, the answer MUST contain zero "m=" lines

The "t=" line in the answer MUST equal that of the offer. The
of the session cannot be negotiated

An offered stream MAY be rejected in the answer, for any reason.
a stream is rejected, the offerer and answerer MUST NOT
media (or RTCP packets) for that stream. To reject an
stream, the port number in the corresponding stream in the
MUST be set to zero. Any media formats listed are ignored. At
one MUST be present, as specified by SDP

Constructing an answer for each offered stream differs for
and multicast

6.1 Unicast

If a stream is offered with a unicast address, the answer for
stream MUST contain a unicast address. The media type of the
in the answer MUST match that of the offer

If a stream is offered as sendonly, the corresponding stream MUST
marked as recvonly or inactive in the answer. If a media stream
listed as recvonly in the offer, the answer MUST be marked
sendonly or inactive in the answer. If an offered media stream
listed as sendrecv (or if there is no direction attribute at
media or session level, in which case the stream is sendrecv
default), the corresponding stream in the answer MAY be marked
sendonly, recvonly, sendrecv, or inactive. If an offered
stream is listed as inactive, it MUST be marked as inactive in
answer

Rosenberg & Schulzrinne Standards Track [Page 9]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

For streams marked as recvonly in the answer, the "m=" line
contain at least one media format the answerer is willing to
with from amongst those listed in the offer. The stream MAY
additional media formats, not listed in the corresponding stream
the offer, that the answerer is willing to receive. For
marked as sendonly in the answer, the "m=" line MUST contain at
one media format the answerer is willing to send from amongst
listed in the offer. For streams marked as sendrecv in the answer
the "m=" line MUST contain at least one codec the answerer is
to both send and receive, from amongst those listed in the offer
The stream MAY indicate additional media formats, not listed in
corresponding stream in the offer, that the answerer is willing
send or receive (of course, it will not be able to send them at
time, since it was not listed in the offer). For streams marked
inactive in the answer, the list of media formats is
based on the offer. If the offer was sendonly, the list
constructed as if the answer were recvonly. Similarly, if the
was recvonly, the list is constructed as if the answer were sendonly
and if the offer was sendrecv, the list is constructed as if
answer were sendrecv. If the offer was inactive, the list
constructed as if the offer were actually sendrecv and the
were sendrecv

The connection address and port in the answer indicate the
where the answerer wishes to receive media (in the case of RTP,
will be received on the port which is one higher unless there is
explicit indication otherwise). This address and port MUST
present even for sendonly streams; in the case of RTP, the port
higher is still used to receive RTCP

In the case of RTP, if a particular codec was referenced with
specific payload type number in the offer, that same payload
number SHOULD be used for that codec in the answer. Even if the
payload type number is used, the answer MUST contain
attributes to define the payload type mappings for dynamic
types, and SHOULD contain mappings for static payload types.
media formats in the "m=" line MUST be listed in order of preference
with the first format listed being preferred. In this case
preferred means that the offerer SHOULD use the format with
highest preference from the answer

Although the answerer MAY list the formats in their desired order
preference, it is RECOMMENDED that unless there is a specific reason
the answerer list formats in the same relative order they
present in the offer. In other words, if a stream in the offer
audio codecs 8, 22 and 48, in that order, and the answerer
supports codecs 8 and 48, it is RECOMMENDED that, if the answerer

Rosenberg & Schulzrinne Standards Track [Page 10]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

no reason to change it, the ordering of codecs in the answer be 8,
48, and not 48, 8. This helps assure that the same codec is used
both directions

The interpretation of fmtp parameters in an offer depends on
parameters. In many cases, those parameters describe
configurations of the media format, and should therefore be
as the media format value itself would be. This means that the
fmtp parameters with the same values MUST be present in the answer
the media format they describe is present in the answer. Other
parameters are more like parameters, for which it is
acceptable for each agent to use different values. In that case,
answer MAY contain fmtp parameters, and those MAY have the
values as those in the offer, or they MAY be different.
extensions that define new parameters SHOULD specify the
interpretation in offer/answer

The answerer MAY include a non-zero ptime attribute for any
stream; this indicates the packetization interval that the
would like to receive. There is no requirement that
packetization interval be the same in each direction for a
stream

The answerer MAY include a bandwidth attribute for any media stream
this indicates the bandwidth that the answerer would like the
to use when sending media. The value of zero is allowed,
as described in Section 5.

If the answerer has no media formats in common for a
offered stream, the answerer MUST reject that media stream by
the port to zero

If there are no media formats in common for all streams, the
offered session is rejected

Once the answerer has sent the answer, it MUST be prepared to
media for any recvonly streams described by that answer. It MUST
prepared to send and receive media for any sendrecv streams in
answer, and it MAY send media immediately. The answerer MUST
prepared to receive media for recvonly or sendrecv streams using
media formats listed for those streams in the answer, and it MAY
media immediately. When sending media, it SHOULD use a
interval equal to the value of the ptime attribute in the offer,
any was present. It SHOULD send media using a bandwidth no
than the value of the bandwidth attribute in the offer, if any
present. The answerer MUST send using a media format in the
that is also listed in the answer, and SHOULD send using the
preferred media format in the offer that is also listed in

Rosenberg & Schulzrinne Standards Track [Page 11]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

answer. In the case of RTP, it MUST use the payload type
from the offer, even if they differ from those in the answer

6.2 Multicast

Unlike unicast, where there is a two-sided view of the stream,
is only a single view of the stream for multicast. As such
generating an answer to a multicast offer generally
modifying a limited set of aspects of the stream

If a multicast stream is accepted, the address and port
in the answer MUST match that of the offer. Similarly,
directionality information in the answer (sendonly, recvonly,
sendrecv) MUST equal that of the offer. This is because
participants in a multicast session need to have equivalent views
the parameters of the session, an underlying assumption of
multicast bias of RFC 2327.

The set of media formats in the answer MUST be equal to or be
subset of those in the offer. Removing a format is a way for
answerer to indicate that the format is not supported

The ptime and bandwidth attributes in the answer MUST equal the
in the offer, if present. If not present, a non-zero ptime MAY
added to the answer

7 Offerer Processing of the

When the offerer receives the answer, it MAY send media on
accepted stream(s) (assuming it is listed as sendrecv or recvonly
the answer). It MUST send using a media format listed in the answer
and it SHOULD use the first media format listed in the answer when
does send

The reason this is a SHOULD, and not a MUST (its also a SHOULD
and not a MUST, for the answerer), is because there
oftentimes be a need to change codecs on the fly. For example
during silence periods, an agent might like to switch to a
noise codec. Or, if the user presses a number on the keypad,
agent might like to send that using RFC 2833 [9].
control might necessitate changing to a lower rate codec based
feedback

The offerer SHOULD send media according to the value of any ptime
bandwidth attribute in the answer

The offerer MAY immediately cease listening for media formats
were listed in the initial offer, but not present in the answer

Rosenberg & Schulzrinne Standards Track [Page 12]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

8 Modifying the

At any point during the session, either participant MAY issue a
offer to modify characteristics of the session. It is fundamental
the operation of the offer/answer model that the exact
offer/answer procedure defined above is used for modifying
of an existing session

The offer MAY be identical to the last SDP provided to the
party (which may have been provided in an offer or an answer), or
MAY be different. We refer to the last SDP provided as the "
SDP". If the offer is the same, the answer MAY be the same as
previous SDP from the answerer, or it MAY be different. If
offered SDP is different from the previous SDP, some constraints
placed on its construction, discussed below

Nearly all aspects of the session can be modified. New streams
be added, existing streams can be deleted, and parameters of
streams can change. When issuing an offer that modifies the session
the "o=" line of the new SDP MUST be identical to that in
previous SDP, except that the version in the origin field
increment by one from the previous SDP. If the version in the
line does not increment, the SDP MUST be identical to the SDP
that version number. The answerer MUST be prepared to receive
offer that contains SDP with a version that has not changed; this
effectively a no-op. However, the answerer MUST generate a
answer (which MAY be the same as the previous SDP from the answerer
or MAY be different), according to the procedures defined in
6.

If an SDP is offered, which is different from the previous SDP,
new SDP MUST have a matching media stream for each media stream
the previous SDP. In other words, if the previous SDP had N "m="
lines, the new SDP MUST have at least N "m=" lines. The i-th
stream in the previous SDP, counting from the top, matches the i-
media stream in the new SDP, counting from the top. This matching
necessary in order for the answerer to determine which stream in
new SDP corresponds to a stream in the previous SDP. Because
these requirements, the number of "m=" lines in a stream
decreases, but either stays the same or increases. Deleted
streams from a previous SDP MUST NOT be removed in a new SDP
however, attributes for these streams need not be present

8.1 Adding a Media

New media streams are created by new additional media
below the existing ones, or by reusing the "slot" used by an
media stream which had been disabled by setting its port to zero

Rosenberg & Schulzrinne Standards Track [Page 13]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

Reusing its slot means that the new media description replaces
old one, but retains its positioning relative to other
descriptions in the SDP. New media descriptions MUST appear
any existing media sections. The rules for formatting these
descriptions are identical to those described in Section 5.

When the answerer receives an SDP with more media descriptions
the previous SDP from the offerer, or it receives an SDP with a
stream in a slot where the port was previously zero, the
knows that new media streams are being added. These can be
or accepted by placing an appropriately structured media
in the answer. The procedures for constructing the new
description in the answer are described in Section 6.

8.2 Removing a Media

Existing media streams are removed by creating a new SDP with
port number for that stream set to zero. The stream description
omit all attributes present previously, and MAY list just a
media format

A stream that is offered with a port of zero MUST be marked with
zero in the answer. Like the offer, the answer MAY omit
attributes present previously, and MAY list just a single
format from amongst those in the offer

Removal of a media stream implies that media is no longer sent
that stream, and any media that is received is discarded. In
case of RTP, RTCP transmission also ceases, as does processing of
received RTCP packets. Any resources associated with it can
released. The user interface might indicate that the stream
terminated, by closing the associated window on a PC, for example

8.3 Modifying a Media

Nearly all characteristics of a media stream can be modified

8.3.1 Modifying Address, Port or

The port number for a stream MAY be changed. To do this, the
creates a new media description, with the port number in the m
different from the corresponding stream in the previous SDP. If
the port number is to be changed, the rest of the media
description SHOULD remain unchanged. The offerer MUST be prepared
receive media on both the old and new ports as soon as the offer
sent. The offerer SHOULD NOT cease listening for media on the
port until the answer is received and media arrives on the new port
Doing so could result in loss of media during the transition

Rosenberg & Schulzrinne Standards Track [Page 14]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

Received, in this case, means that the media is passed to a
sink. This means that if there is a playout buffer, the agent
continue to listen on the old port until the media on the new
reached the top of the playout buffer. At that time, it MAY
listening for media on the old port

The corresponding media stream in the answer MAY be the same as
stream in the previous SDP from the answerer, or it MAY be different
If the updated stream is accepted by the answerer, the
SHOULD begin sending traffic for that stream to the new
immediately. If the answerer changes the port from the previous SDP
it MUST be prepared to receive media on both the old and new ports
soon as the answer is sent. The answerer MUST NOT cease
for media on the old port until media arrives on the new port.
that time, it MAY cease listening for media on the old port.
same is true for an offerer that sends an updated offer with a
port; it MUST NOT cease listening for media on the old port
media arrives on the new port

Of course, if the offered stream is rejected, the offerer can
being prepared to receive using the new port as soon as the
is received

To change the IP address where media is sent to, the same
is followed for changing the port number. The only difference
that the connection line is updated, not the port number

The transport for a stream MAY be changed. The process for
this is identical to changing the port, except the transport
updated, not the port

8.3.2 Changing the Set of Media

The list of media formats used in the session MAY be changed. To
this, the offerer creates a new media description, with the list
media formats in the "m=" line different from the corresponding
stream in the previous SDP. This list MAY include new formats,
MAY remove formats present from the previous SDP. However, in
case of RTP, the mapping from a particular dynamic payload
number to a particular codec within that media stream MUST NOT
for the duration of a session. For example, if A generates an
with G.711 assigned to dynamic payload type number 46, payload
number 46 MUST refer to G.711 from that point forward in any
or answers for that media stream within the session. However, it
acceptable for multiple payload type numbers to be mapped to the
codec, so that an updated offer could also use payload type number 72
for G.711.

Rosenberg & Schulzrinne Standards Track [Page 15]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

The mappings need to remain fixed for the duration of the
because of the loose synchronization between signaling
of SDP and the media stream

The corresponding media stream in the answer is formulated
described in Section 6, and may result in a change in media
as well. Similarly, as described in Section 6, as soon as it
its answer, the answerer MUST begin sending media using any
in the offer that were also present in the answer, and SHOULD use
most preferred format in the offer that was also listed in the
(assuming the stream allows for sending), and MUST NOT send using
formats that are not in the offer, even if they were present in
previous SDP from the peer. Similarly, when the offerer receives
answer, it MUST begin sending media using any formats in the answer
and SHOULD use the most preferred one (assuming the stream allows
sending), and MUST NOT send using any formats that are not in
answer, even if they were present in a previous SDP from the peer

When an agent ceases using a media format (by not listing that
in an offer or answer, even though it was in a previous SDP)
agent will still need to be prepared to receive media with
format for a brief time. How does it know when it can be prepared
stop receiving with that format? If it needs to know, there are
techniques that can be applied. First, the agent can change ports
addition to changing formats. When media arrives on the new port,
knows that the peer has ceased sending with the old format, and
can cease being prepared to receive with it. This approach has
benefit of being media format independent. However, changes in
may require changes in resource reservation or rekeying of
protocols. The second approach is to use a totally new set
dynamic payload types for all codecs when one is discarded.
media is received with one of the new payload types, the agent
that the peer has ceased sending with the old format. This
doesn't affect reservations or security contexts, but it is
specific and wasteful of a very small payload type space. A
approach is to use a timer. When the SDP from the peer is received
the timer is set. When it fires, the agent can cease being
to receive with the old format. A value of one minute
typically be more than sufficient. In some cases, an agent may
care, and thus continually be prepared to receive with the
formats. Nothing need be done in this case

Of course, if the offered stream is rejected, the offer can
being prepared to receive using any new formats as soon as
rejection is received

Rosenberg & Schulzrinne Standards Track [Page 16]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

8.3.3 Changing Media

The media type (audio, video, etc.) for a stream MAY be changed.
is RECOMMENDED that the media type be changed (as opposed to adding
new stream), when the same logical data is being conveyed, but
in a different media format. This is particularly useful
changing between voiceband fax and fax in a single stream, which
both separate media types. To do this, the offerer creates a
media description, with a new media type, in place of the
in the previous SDP which is to be changed

The corresponding media stream in the answer is formulated
described in Section 6. Assuming the stream is acceptable,
answerer SHOULD begin sending with the new media type and formats
soon as it receives the offer. The offerer MUST be prepared
receive media with both the old and new types until the answer
received, and media with the new type is received and reaches the
of the playout buffer

8.3.4 Changing

Any other attributes in a media description MAY be updated in
offer or answer. Generally, an agent MUST send media (if
directionality of the stream allows) using the new parameters
the SDP with the change is received

8.4 Putting a Unicast Media Stream on

If a party in a call wants to put the other party "on hold", i.e.,
request that it temporarily stops sending one or more unicast
streams, a party offers the other an updated SDP

If the stream to be placed on hold was previously a sendrecv
stream, it is placed on hold by marking it as sendonly. If
stream to be placed on hold was previously a recvonly media stream
it is placed on hold by marking it inactive

This means that a stream is placed "on hold" separately in
direction. Each stream is placed "on hold" independently.
recipient of an offer for a stream on-hold SHOULD NOT
return an answer with the corresponding stream on hold. An SDP
all streams "on hold" is referred to as held SDP

Certain third party call control scenarios do not work when
answerer responds to held SDP with held SDP

Rosenberg & Schulzrinne Standards Track [Page 17]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

Typically, when a user "presses" hold, the agent will generate
offer with all streams in the SDP indicating a direction of sendonly
and it will also locally mute, so that no media is sent to the
end, and no media is played out

RFC 2543 [10] specified that placing a user on hold was
by setting the connection address to 0.0.0.0. Its usage for
a call on hold is no longer recommended, since it doesn't allow
RTCP to be used with held streams, doesn't work with IPv6, and
with connection oriented media. However, it can be useful in
initial offer when the offerer knows it wants to use a particular
of media streams and formats, but doesn't know the addresses
ports at the time of the offer. Of course, when used, the
number MUST NOT be zero, which would specify that the stream has
disabled. An agent MUST be capable of receiving SDP with
connection address of 0.0.0.0, in which case it means that
RTP nor RTCP should be sent to the peer

9 Indicating

Before an agent sends an offer, it is helpful to know if the
formats in that offer would be acceptable to the answerer.
protocols, like SIP, provide a means to query for such capabilities
SDP can be used in responses to such queries to
capabilities. This section describes how such an SDP message
formatted. Since SDP has no way to indicate that the message is
the purpose of capability indication, this is determined from
context of the higher layer protocol. The ability of baseline SDP
indicate capabilities is very limited. It cannot express
parameter ranges or values, and can not be done in parallel with
offer/answer itself. Extensions might address such limitations
the future

An SDP constructed to indicate media capabilities is structured
follows. It MUST be a valid SDP, except that it MAY omit both "e="
and "p=" lines. The "t=" line MUST be equal to "0 0". For
media type supported by the agent, there MUST be a
media description of that type. The session ID in the origin
MUST be unique for each SDP constructed to indicate
capabilities. The port MUST be set to zero, but the
address is arbitrary. The usage of port zero makes sure that an
formatted for capabilities does not cause media streams to
established if it is interpreted as an offer or answer

The transport component of the "m=" line indicates the transport
that media type. For each media format of that type supported by
agent, there SHOULD be a media format listed in the "m=" line.
the case of RTP, if dynamic payload types are used, an

Rosenberg & Schulzrinne Standards Track [Page 18]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

attribute MUST be present to bind the type to a specific format
There is no way to indicate constraints, such as how
simultaneous streams can be supported for a particular codec, and
on

v=0
o=carol 28908764872 28908764872 IN IP4 100.3.6.6
s=-
t=0 0
c=IN IP4 192.0.2.4
m=audio 0 RTP/AVP 0 1 3
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000
m=video 0 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000

Figure 1: SDP Indicating

The SDP of Figure 1 indicates that the agent can support three
codecs (PCMU, 1016, and GSM) and two video codecs (H.261 and H.263).

10 Example Offer/Answer

This section provides example offer/answer exchanges

10.1 Basic

Assume that the caller, Alice, has included the following
in her offer. It includes a bidirectional audio stream and
bidirectional video streams, using H.261 (payload type 31) and
(payload type 32). The offered SDP is

v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.
s
c=IN IP4 host.anywhere.
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000

Rosenberg & Schulzrinne Standards Track [Page 19]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

The callee, Bob, does not want to receive or send the first
stream, so he returns the SDP below as the answer

v=0
o=bob 2890844730 2890844730 IN IP4 host.example.
s
c=IN IP4 host.example.
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000

At some point later, Bob decides to change the port where he
receive the audio stream (from 49920 to 65422), and at the same time
add an additional audio stream as receive only, using the RTP
format for events [9]. Bob offers the following SDP in the offer

v=0
o=bob 2890844730 2890844731 IN IP4 host.example.
s
c=IN IP4 host.example.
t=0 0
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 51434 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=

Rosenberg & Schulzrinne Standards Track [Page 20]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

Alice accepts the additional media stream, and so generates
following answer

v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.
s
c=IN IP4 host.anywhere.
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=

10.2 One of N Codec

A common occurrence in embedded phones is that the Digital
Processor (DSP) used for compression can support multiple codecs at
time, but once that codec is selected, it cannot be readily
on the fly. This example shows how a session can be set up using
initial offer/answer exchange, followed immediately by a second
to lock down the set of codecs

The initial offer from Alice to Bob indicates a single audio
with the three audio codecs that are available in the DSP.
stream is marked as inactive, since media cannot be received until
codec is locked down

v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.
s
c=IN IP4 host.anywhere.
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=

Rosenberg & Schulzrinne Standards Track [Page 21]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

Bob can support dynamic switching between PCMU and G.723. So,
sends the following answer

v=0
o=bob 2890844730 2890844731 IN IP4 host.example.
s
c=IN IP4 host.example.
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=

Alice can then select any one of these two codecs. So, she sends
updated offer with a sendrecv stream

v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.
s
c=IN IP4 host.anywhere.
t=0 0
m=audio 62986 RTP/AVP 4
a=rtpmap:4 G723/8000
a=

Bob accepts the single codec

v=0
o=bob 2890844730 2890844732 IN IP4 host.example.
s
c=IN IP4 host.example.
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
a=

If the answerer (Bob), was only capable of supporting one-of-
codecs, Bob would select one of the codecs from the offer, and
that in his answer. In this case, Alice would do a re-INVITE
activate that stream with that codec

As an alternative to using "a=inactive" in the first exchange,
can list all codecs, and as soon as she receives media from Bob
generate an updated offer locking down the codec to the one
received. Of course, if Bob only supports one-of-N codecs,
would only be one codec in his answer, and in this case, there is
need for a re-INVITE to lock down to a single codec

Rosenberg & Schulzrinne Standards Track [Page 22]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

11 Security

There are numerous attacks possible if an attacker can modify
or answers in transit. Generally, these include diversion of
streams (enabling eavesdropping), disabling of calls, and
of unwanted media streams. If a passive listener can construct
offers, and inject those into an exchange, similar attacks
possible. Even if an attacker can simply observe offers and answers
they can inject media streams into an existing conversation

Offer/answer relies on transport within an application
protocol, such as SIP. It also relies on that protocol for
capabilities. Because of the attacks described above, that
MUST provide a means for end-to-end authentication and
protection of offers and answers. It SHOULD offer encryption
bodies to prevent eavesdropping. However, media injection
can alternatively be resolved through authenticated media exchange
and therefore the encryption requirement is a SHOULD instead of
MUST

Replay attacks are also problematic. An attacker can replay an
offer, perhaps one that had put media on hold, and thus disable
streams in a conversation. Therefore, the application protocol
provide a secure way to sequence offers and answers, and to
and reject old offers or answers

SIP [7] meets all of these requirements

12 IANA

There are no IANA considerations with this specification

13

The authors would like to thank Allison Mankin, Rohan Mahy,
Ott, and Flemming Andreasen for their detailed comments

14 Normative

[1] Handley, M. and V. Jacobson, "SDP: Session
Protocol", RFC 2327, April 1998.

[2] Bradner, S., "Key Words for Use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.

[3] Kumar, R. and M. Mostafa, "Conventions For the Use of
Session Description Protocol (SDP) for ATM Bearer Connections",
RFC 3108, May 2001.

Rosenberg & Schulzrinne Standards Track [Page 23]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

[4] Schulzrinne, H., Casner, S, Frederick, R. and V. Jacobson
"RTP: A Transport Protocol for Real-Time Applications",
1889, January 1996.

[5] Schulzrinne, H., "RTP Profile for Audio and Video
with Minimal Control", RFC 1890, January 1996.

15 Informative

[6] Handley, M., Perkins, C. and E. Whelan, "Session
Protocol", RFC 2974, October 2000.

[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP
Session Initiation Protocol", RFC 3261, June 2002.

[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time
Protocol (RTSP)", RFC 2326, April 1998.

[9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits
Telephony Tones and Telephony Signals", RFC 2833, May 2000.

[10] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg
"SIP: Session Initiation Protocol", RFC 2543, March 1999.

16 Authors'

Jonathan

72 Eagle Rock
First
East Hanover, NJ 07936

EMail: jdrosen@dynamicsoft.

Henning
Dept. of Computer
Columbia
1214 Amsterdam
New York, NY 10027

EMail: schulzrinne@cs.columbia.

Rosenberg & Schulzrinne Standards Track [Page 24]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

17. Full Copyright

Copyright (C) The Internet Society (2002). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Rosenberg & Schulzrinne Standards Track [Page 25]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX