draft-ietf-mmusic-sdp-offer-answer-02.txt   rfc3264.txt 
Internet Engineering Task Force MMUSIC WG Network Working Group J. Rosenberg
Internet Draft J.Rosenberg Request for Comments: 3264 dynamicsoft
dynamicsoft Obsoletes: 2543 H. Schulzrinne
H.Schulzrinne Category: Standards Track Columbia U.
Columbia U. June 2002
draft-ietf-mmusic-sdp-offer-answer-02.txt
February 27, 2002
Expires: August 2002
An Offer/Answer Model with SDP
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with An Offer/Answer Model with the Session Description Protocol (SDP)
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress". Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see Copyright (C) The Internet Society (2002). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines a mechanism by which two entities can make use This document defines a mechanism by which two entities can make use
of SDP to arrive at a common view of a multimedia session between of the Session Description Protocol (SDP) to arrive at a common view
them. In the model, one participant offers the other a description of of a multimedia session between them. In the model, one participant
the desired session from their perspective, and the other participant offers the other a description of the desired session from their
answers with the desired session from their perspective. This perspective, and the other participant answers with the desired
offer/answer model is most useful in unicast sessions where session from their perspective. This offer/answer model is most
information from both participants is needed for the complete view of useful in unicast sessions where information from both participants
the session. The offer/answer model is used by protocols like the is needed for the complete view of the session. The offer/answer
Session Initiation Protocol (SIP). model is used by protocols like the Session Initiation Protocol
(SIP).
Table of Contents Table of Contents
1 Introduction ........................................ 2 1 Introduction ........................................ 2
2 Terminology ......................................... 3 2 Terminology ......................................... 3
3 Definitions ......................................... 3 3 Definitions ......................................... 3
4 Protocol Operation .................................. 3 4 Protocol Operation .................................. 4
5 Generating the initial offer ........................ 4 5 Generating the Initial Offer ........................ 5
5.1 Unicast Streams ..................................... 5 5.1 Unicast Streams ..................................... 5
5.2 Multicast Streams ................................... 8 5.2 Multicast Streams ................................... 8
6 Generating the answer ............................... 8 6 Generating the Answer ............................... 9
6.1 Unicast Streams ..................................... 9 6.1 Unicast Streams ..................................... 9
6.2 Multicast Streams ................................... 11 6.2 Multicast Streams ................................... 12
7 Offerer Processing of the Answer .................... 12 7 Offerer Processing of the Answer .................... 12
8 Modifying the session ............................... 12 8 Modifying the Session ............................... 13
8.1 Adding a Media Stream ............................... 13 8.1 Adding a Media Stream ............................... 13
8.2 Removing a Media Stream ............................. 13 8.2 Removing a Media Stream ............................. 14
8.3 Modifying a Media Stream ............................ 14 8.3 Modifying a Media Stream ............................ 14
8.3.1 Modifying Address, Port or Transport ................ 14 8.3.1 Modifying Address, Port or Transport ................ 14
8.3.2 Changing the Set of Media Formats ................... 15 8.3.2 Changing the Set of Media Formats ................... 15
8.3.3 Changing Media Types ................................ 16 8.3.3 Changing Media Types ................................ 17
8.3.4 Changing Attributes ................................. 16 8.3.4 Changing Attributes ................................. 17
8.4 Putting a Unicast Media Stream on Hold .............. 16 8.4 Putting a Unicast Media Stream on Hold .............. 17
9 Indicating Capabilities ............................. 17 9 Indicating Capabilities ............................. 18
10 Example Offer/Answer Exchanges ...................... 18 10 Example Offer/Answer Exchanges ...................... 19
10.1 Basic Exchange ...................................... 18 10.1 Basic Exchange ...................................... 19
10.2 One of N Codec Selection ............................ 20 10.2 One of N Codec Selection ............................ 21
11 Security Considerations ............................. 22 11 Security Considerations ............................. 23
12 IANA Considerations ................................. 23 12 IANA Considerations ................................. 23
13 Acknowledgements .................................... 23 13 Acknowledgements .................................... 23
14 Author's Addresses .................................. 23 14 Normative References ................................ 23
15 Normative References ................................ 23 15 Informative References .............................. 24
16 Informative References .............................. 24 16 Authors' Addresses .................................. 24
17 Full Copyright Statement............................. 25
1 Introduction 1 Introduction
The Session Description Protocol (SDP) [1] was originally conceived The Session Description Protocol (SDP) [1] was originally conceived
as a way to describe multicast sessions carried on the Mbone. The as a way to describe multicast sessions carried on the Mbone. The
Session Announcement Protocol (SAP) [6] was devised as a multicast Session Announcement Protocol (SAP) [6] was devised as a multicast
mechanism to carry SDP messages. Although the SDP specification mechanism to carry SDP messages. Although the SDP specification
allows for unicast operation, it is not complete. Unlike multicast, allows for unicast operation, it is not complete. Unlike multicast,
where there is a global view of the session that is used by all where there is a global view of the session that is used by all
participants, unicast sessions involve two participants, and a participants, unicast sessions involve two participants, and a
complete view of the session requires information from both complete view of the session requires information from both
participants, and agreement on parameters between them. participants, and agreement on parameters between them.
As an example, a multicast session requires conveying a single As an example, a multicast session requires conveying a single
multicast address for a particular media stream. However, for a multicast address for a particular media stream. However, for a
unicast session, two addresses are needed - one for each participant. unicast session, two addresses are needed - one for each participant.
As another example, a multicast session requires indication of which As another example, a multicast session requires an indication of
codecs will be used in the session. However, for unicast, the set of which codecs will be used in the session. However, for unicast, the
codecs needs to be determined by finding an overlap in the set set of codecs needs to be determined by finding an overlap in the set
supported by each participant. supported by each participant.
As a result, even though SDP has the expressiveness to describe As a result, even though SDP has the expressiveness to describe
unicast sessions, it is missing the semantics and operational details unicast sessions, it is missing the semantics and operational details
of how it is actually done. In this document, we remedy that by of how it is actually done. In this document, we remedy that by
defining a simple offer/answer model based on SDP. In this model, one defining a simple offer/answer model based on SDP. In this model,
participant in the session generates an SDP that constitutes the one participant in the session generates an SDP message that
offer - the set of media streams and codecs the offerer wishes to constitutes the offer - the set of media streams and codecs the
use, along with the IP addresses and ports the offer would like to offerer wishes to use, along with the IP addresses and ports the
use to receive the media. The offer is conveyed to the other offerer would like to use to receive the media. The offer is
participant, called the answerer. The answerer generates an answer, conveyed to the other participant, called the answerer. The answerer
which is an SDP that responds to the offer provided it. The answer generates an answer, which is an SDP message that responds to the
has a matching media stream for each stream in the offer, indicating offer provided by the offerer. The answer has a matching media
whether the stream is accepted or not, along with the codecs that stream for each stream in the offer, indicating whether the stream is
will be used and the IP addresses and ports that the answerer wants accepted or not, along with the codecs that will be used and the IP
to use to receive media. addresses and ports that the answerer wants to use to receive media.
It is also possible for a multicast session to work similarly to a It is also possible for a multicast session to work similar to a
unicast one; its parameters are negotiated between a pair of users as unicast one; its parameters are negotiated between a pair of users as
in the unicast case, but both sides send packets to the same in the unicast case, but both sides send packets to the same
multicast address, rather than unicast ones. This document also multicast address, rather than unicast ones. This document also
discusses the application of the offer/answer model to multicast discusses the application of the offer/answer model to multicast
streams. streams.
We also define guidelines for how the offer/answer model is used to We also define guidelines for how the offer/answer model is used to
update a session after an initial offer/answer exchange. update a session after an initial offer/answer exchange.
The means by which the offers and answers are conveyed are outside The means by which the offers and answers are conveyed are outside
skipping to change at page 3, line 21 skipping to change at page 3, line 41
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3 Definitions 3 Definitions
The following terms are used throughout this document: The following terms are used throughout this document:
Agent: An agent is the protocol implementation involved in the Agent: An agent is the protocol implementation involved in the
offer/answer exchange. There are two agents involved in an offer/answer exchange. There are two agents involved in an
offer/answer exchange. offer/answer exchange.
Answer: An SDP message sent by an answerer in response to an Answer: An SDP message sent by an answerer in response to an offer
offer received from an offerer. received from an offerer.
Answerer: An agent which receives a session description from Answerer: An agent which receives a session description from
another agent describing aspects of desired media another agent describing aspects of desired media
communication, and then responds to that with its own communication, and then responds to that with its own session
session description. description.
Media Stream: From RTSP [8], a media stream is a single media Media Stream: From RTSP [8], a media stream is a single media
instance, e.g., an audio stream or a video stream as well instance, e.g., an audio stream or a video stream as well as a
as a single whiteboard or shared application group. In SDP, single whiteboard or shared application group. In SDP, a media
a media stream is described by an "m=" line and its stream is described by an "m=" line and its associated
associated attributes. attributes.
Offer: An SDP message sent by an offerer. Offer: An SDP message sent by an offerer.
Offerer: An agent which generates a session description in order Offerer: An agent which generates a session description in order
to create or modify a session. to create or modify a session.
4 Protocol Operation 4 Protocol Operation
The offer/answer exchange assumes the existence of a higher layer The offer/answer exchange assumes the existence of a higher layer
protocol (such as SIP) which is capable of exchanging SDP for the protocol (such as SIP) which is capable of exchanging SDP for the
skipping to change at page 4, line 12 skipping to change at page 4, line 36
maintenance of some kind of context which allows the various SDP maintenance of some kind of context which allows the various SDP
exchanges to be associated together. exchanges to be associated together.
The agent receiving the offer MAY generate an answer, or it MAY The agent receiving the offer MAY generate an answer, or it MAY
reject the offer. The means for rejecting an offer are dependent on reject the offer. The means for rejecting an offer are dependent on
the higher layer protocol. The offer/answer exchange is atomic; if the higher layer protocol. The offer/answer exchange is atomic; if
the answer is rejected, the session reverts to the state prior to the the answer is rejected, the session reverts to the state prior to the
offer (which may be absence of a session). offer (which may be absence of a session).
At any time, either agent MAY generate a new offer that updates the At any time, either agent MAY generate a new offer that updates the
session. However, it MUST NOT generate a new offer if it has received session. However, it MUST NOT generate a new offer if it has
an offer which it has not yet answered or rejected. Furthermore, it received an offer which it has not yet answered or rejected.
MUST NOT generate a new offer if it has generated a prior offer for Furthermore, it MUST NOT generate a new offer if it has generated a
which it has not yet received an answer or a rejection. If an agent prior offer for which it has not yet received an answer or a
receives an offer after having sent one, but before receiving an rejection. If an agent receives an offer after having sent one, but
answer to it, this is considered a "glare" condition. before receiving an answer to it, this is considered a "glare"
condition.
The term glare was originally used in circuit switched The term glare was originally used in circuit switched
telecommunications networks to describe the condition where telecommunications networks to describe the condition where two
two switches both attempt to seize the same available switches both attempt to seize the same available circuit on the
circuit on the same trunk at the same time. Here, it means same trunk at the same time. Here, it means both agents have
both agents have attempted to send an updated offer at the attempted to send an updated offer at the same time.
same time.
The higher layer protocol needs to provide a means for resolving such The higher layer protocol needs to provide a means for resolving such
conditions. The higher layer protocol will need to provide a means conditions. The higher layer protocol will need to provide a means
for ordering of messages in each direction. SIP meets these for ordering of messages in each direction. SIP meets these
requirements [7]. requirements [7].
5 Generating the initial offer 5 Generating the Initial Offer
The offer (and answer) MUST be a valid SDP, as defined by RFC 2327 The offer (and answer) MUST be a valid SDP message, as defined by RFC
[1], with one exception. RFC 2327 mandates that either an e or a p 2327 [1], with one exception. RFC 2327 mandates that either an e or
line is present in the SDP. This specification relaxes that a p line is present in the SDP message. This specification relaxes
constraint; an SDP formulated for an offer/answer application MAY that constraint; an SDP formulated for an offer/answer application
omit both the e and p lines. The numeric value of the session id and MAY omit both the e and p lines. The numeric value of the session id
version in the o line MUST be representable with a 64 bit signed and version in the o line MUST be representable with a 64 bit signed
integer. The initial value of the version MUST be less than (2**62)- integer. The initial value of the version MUST be less than
1, to avoid rollovers. Although the SDP specification allows for (2**62)-1, to avoid rollovers. Although the SDP specification allows
multiple session descriptions to be concatenated together into a for multiple session descriptions to be concatenated together into a
large SDP message, an SDP message used in the offer/answer model MUST large SDP message, an SDP message used in the offer/answer model MUST
contain exactly one session description. contain exactly one session description.
The SDP "s=" line conveys the subject of the media stream, which is The SDP "s=" line conveys the subject of the session, which is
reasonably defined for multicast, but ill defined for unicast. For reasonably defined for multicast, but ill defined for unicast. For
unicast streams, it is RECOMMENDED that it consist of a single space unicast sessions, it is RECOMMENDED that it consist of a single space
character (0x20). character (0x20) or a dash (-).
Unfortunately, SDP does not allow the "s=" line to be Unfortunately, SDP does not allow the "s=" line to be empty.
empty.
The SDP "t=" line conveys the time of the session. Generally, streams The SDP "t=" line conveys the time of the session. Generally,
for unicast sessions are created and destroyed through external streams for unicast sessions are created and destroyed through
signaling means, such as SIP. In that case, the "t=" line SHOULD have external signaling means, such as SIP. In that case, the "t=" line
a value of "0 0". SHOULD have a value of "0 0".
The offer will contain zero or more media streams (each media stream The offer will contain zero or more media streams (each media stream
is described by an "m=" line and its associated attributes). Zero is described by an "m=" line and its associated attributes). Zero
media streams implies that the offerer wishes to communicate, but media streams implies that the offerer wishes to communicate, but
that the streams for the session will be added at a later time that the streams for the session will be added at a later time
through a modified offer. The streams MAY be for a mix of unicast and through a modified offer. The streams MAY be for a mix of unicast
multicast; the latter obviously implies a multicast address in the and multicast; the latter obviously implies a multicast address in
relevant "c=" line(s). the relevant "c=" line(s).
Construction of each offered stream depends on whether the stream is Construction of each offered stream depends on whether the stream is
multicast or unicast. multicast or unicast.
5.1 Unicast Streams 5.1 Unicast Streams
If the offerer wishes to only send media on a stream to its peer, it If the offerer wishes to only send media on a stream to its peer, it
MUST mark the stream as sendonly with the "a=sendonly" attribute. We MUST mark the stream as sendonly with the "a=sendonly" attribute. We
refer to a stream as being marked with a certain direction if a refer to a stream as being marked with a certain direction if a
direction attribute was present as either a media stream attribute or direction attribute was present as either a media stream attribute or
a session attribute. If the offerer wishes to only receive media from a session attribute. If the offerer wishes to only receive media
its peer, it MUST mark the stream as recvonly. If the offerer wishes from its peer, it MUST mark the stream as recvonly. If the offerer
to communicate, but wishes to neither send nor receive media at this wishes to communicate, but wishes to neither send nor receive media
time, it MUST mark the stream with an "a=inactive" attribute. The at this time, it MUST mark the stream with an "a=inactive" attribute.
inactive direction attribute is specified in RFC 3108 [3]. Note that The inactive direction attribute is specified in RFC 3108 [3]. Note
in the case of the Real Time Transport Protocol (RTP) [4], RTCP is that in the case of the Real Time Transport Protocol (RTP) [4], RTCP
still sent and received for sendonly, recvonly and inactive streams. is still sent and received for sendonly, recvonly, and inactive
That is, the directionality of the media stream has no impact on the streams. That is, the directionality of the media stream has no
RTCP usage. If the offerer wishes to both send and receive media with impact on the RTCP usage. If the offerer wishes to both send and
its peer, it MAY include an "a=sendrecv" attribute, or it MAY omit receive media with its peer, it MAY include an "a=sendrecv"
it, since sendrecv is the default. attribute, or it MAY omit it, since sendrecv is the default.
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
and port present in the offer indicate nothing about the source IP and port present in the offer indicate nothing about the source IP
address and source port of RTP and RTCP packets that will be sent by address and source port of RTP and RTCP packets that will be sent by
the offerer. A port number of zero in the offer indicates that the the offerer. A port number of zero in the offer indicates that the
skipping to change at page 6, line 16 skipping to change at page 6, line 40
zero indicates that the media stream is not wanted. zero indicates that the media stream is not wanted.
The list of media formats for each media stream conveys two pieces of The list of media formats for each media stream conveys two pieces of
information, namely the set of formats (codecs and any parameters information, namely the set of formats (codecs and any parameters
associated with the codec, in the case of RTP) that the offerer is associated with the codec, in the case of RTP) that the offerer is
capable of sending and/or receiving (depending on the direction capable of sending and/or receiving (depending on the direction
attributes), and, in the case of RTP, the RTP payload type numbers attributes), and, in the case of RTP, the RTP payload type numbers
used to identify those formats. If multiple formats are listed, it used to identify those formats. If multiple formats are listed, it
means that the offerer is capable of making use of any of those means that the offerer is capable of making use of any of those
formats during the session. In other words, the answerer MAY change formats during the session. In other words, the answerer MAY change
formats in the middle of the session, without sending a new offer, to formats in the middle of the session, making use of any of the
make use of any of the formats listed. For a sendonly stream, the formats listed, without sending a new offer. For a sendonly stream,
offer SHOULD indicate those formats the offerer is willing to send the offer SHOULD indicate those formats the offerer is willing to
for this stream. For a recvonly stream, the offer SHOULD indicate send for this stream. For a recvonly stream, the offer SHOULD
those formats the offerer is willing to receive for this stream. For indicate those formats the offerer is willing to receive for this
a sendrecv stream, the offer SHOULD indicate those codecs that the stream. For a sendrecv stream, the offer SHOULD indicate those
offerer is willing to send and receive with. codecs that the offerer is willing to send and receive with.
For recvonly RTP streams, the payload type numbers indicate the value For recvonly RTP streams, the payload type numbers indicate the value
of the payload type field in RTP packets the offerer is expecting to of the payload type field in RTP packets the offerer is expecting to
receive for that codec. For sendonly RTP streams, the payload type receive for that codec. For sendonly RTP streams, the payload type
numbers indicate the value of the payload type field in RTP packets numbers indicate the value of the payload type field in RTP packets
the offerer is planning to send for that codec. For sendrecv RTP the offerer is planning to send for that codec. For sendrecv RTP
streams, the payload type numbers indicate the value of the payload streams, the payload type numbers indicate the value of the payload
type field the offerer expects to receive, and would prefer to send. type field the offerer expects to receive, and would prefer to send.
However, for sendonly and sendrecv streams, the answer might indicate However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case, different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer. the offerer MUST send with the payload type numbers from the answer.
Different payload type numbers may be needed in each Different payload type numbers may be needed in each direction
direction because of interoperability concerns with H.323. because of interoperability concerns with H.323.
As per RFC 2327, fmtp parameters MAY be present to provide additional As per RFC 2327, fmtp parameters MAY be present to provide additional
parameters of the media format. parameters of the media format.
In the case of RTP streams, all media descriptions SHOULD contain In the case of RTP streams, all media descriptions SHOULD contain
"a=rtpmap" mappings from RTP payload types to encodings. If there is "a=rtpmap" mappings from RTP payload types to encodings. If there is
no "a=rtpmap", the default payload type mapping, as defined by the no "a=rtpmap", the default payload type mapping, as defined by the
current profile in use (for example, RFC 1890 [5]) is to be used. current profile in use (for example, RFC 1890 [5]) is to be used.
This allows easier migration away from static payload This allows easier migration away from static payload types.
types.
In all cases, the formats in the "m=" line MUST be listed in order of In all cases, the formats in the "m=" line MUST be listed in order of
preference, with the first format listed being preferred. In this preference, with the first format listed being preferred. In this
case, preferred means that the recipient of the offer SHOULD use the case, preferred means that the recipient of the offer SHOULD use the
format with the highest preference that is acceptable to it. format with the highest preference that is acceptable to it.
If the ptime attribute is present for a stream, it indicates the If the ptime attribute is present for a stream, it indicates the
desired packetization interval that the offerer would like to desired packetization interval that the offerer would like to
receive. The ptime attribute MUST be greater than zero. receive. The ptime attribute MUST be greater than zero.
skipping to change at page 7, line 33 skipping to change at page 8, line 6
it means that the offerer wishes to send (and/or receive) multiple it means that the offerer wishes to send (and/or receive) multiple
streams of that type at the same time. When sending multiple streams streams of that type at the same time. When sending multiple streams
of the same type, it is a matter of local policy as to how each media of the same type, it is a matter of local policy as to how each media
source of that type (for example, a video camera and VCR in the case source of that type (for example, a video camera and VCR in the case
of video) is mapped to each stream. When a user has a single source of video) is mapped to each stream. When a user has a single source
for a particular media type, only one policy makes sense: the source for a particular media type, only one policy makes sense: the source
is sent to each stream of the same type. Each stream MAY use is sent to each stream of the same type. Each stream MAY use
different encodings. When receiving multiple streams of the same different encodings. When receiving multiple streams of the same
type, it is a matter of local policy as to how each stream is mapped type, it is a matter of local policy as to how each stream is mapped
to the various media sinks for that particular type (for example, to the various media sinks for that particular type (for example,
speakers or a recording device in the case of audio). There are a few speakers or a recording device in the case of audio). There are a
constraints on the policies, however. First, when receiving multiple few constraints on the policies, however. First, when receiving
streams of the same type, each stream MUST be mapped to at least one multiple streams of the same type, each stream MUST be mapped to at
sink for the purpose of presentation to the user. In other words, the least one sink for the purpose of presentation to the user. In other
intent of receiving multiple streams of the same type is that they words, the intent of receiving multiple streams of the same type is
should all be presented in parallel, rather than choosing just one. that they should all be presented in parallel, rather than choosing
Another constraint is that when multiple streams are received and just one. Another constraint is that when multiple streams are
sent to the same sink, they MUST be combined in some media specific received and sent to the same sink, they MUST be combined in some
way. For example, in the case of two audio streams, the received media specific way. For example, in the case of two audio streams,
media from each might be mapped to the speakers. In that case, the the received media from each might be mapped to the speakers. In
combining operation would be to mix them. In the case of multiple that case, the combining operation would be to mix them. In the case
instant messaging streams, where the sink is the screen, the of multiple instant messaging streams, where the sink is the screen,
combining operation would be to present all of them to the user the combining operation would be to present all of them to the user
interface. The third constraint is that if multiple sources are interface. The third constraint is that if multiple sources are
mapped to the same stream, those sources MUST be combined in some mapped to the same stream, those sources MUST be combined in some
media specific way before they are sent on the stream. Although media specific way before they are sent on the stream. Although
policies beyond these constraints are flexible, an agent won't policies beyond these constraints are flexible, an agent won't
generally want a policy that will copy media from its sinks to its generally want a policy that will copy media from its sinks to its
sources unless it is a conference server (i.e., don't copy received sources unless it is a conference server (i.e., don't copy received
media on one stream to another stream). media on one stream to another stream).
A typical usage example for multiple media streams of the same type A typical usage example for multiple media streams of the same type
is a pre-paid calling card application, where the user can press and is a pre-paid calling card application, where the user can press and
hold the pound ("#") key at any time during a call to hangup and make hold the pound ("#") key at any time during a call to hangup and make
a new call on the same card. This requires media from the user to two a new call on the same card. This requires media from the user to
destinations - the remote gateway, and the DTMF processing two destinations - the remote gateway, and the DTMF processing
application which looks for the pound. This could be accomplished application which looks for the pound. This could be accomplished
with two media streams, one sendrecv to the gateway, and the other with two media streams, one sendrecv to the gateway, and the other
sendonly (from the perspective of the user) to the DTMF application. sendonly (from the perspective of the user) to the DTMF application.
Once the offerer has sent the offer, it MUST be prepared to receive Once the offerer has sent the offer, it MUST be prepared to receive
media for any recvonly streams described by that offer. It MUST be media for any recvonly streams described by that offer. It MUST be
prepared to send and receive media for any sendrecv streams in the prepared to send and receive media for any sendrecv streams in the
offer, and send media for any sendonly streams in the offer (of offer, and send media for any sendonly streams in the offer (of
course, it cannot actually send until the peer provides an answer course, it cannot actually send until the peer provides an answer
with the needed address and port information). In the case of RTP, with the needed address and port information). In the case of RTP,
skipping to change at page 8, line 35 skipping to change at page 9, line 8
If a session description contains a multicast media stream which is If a session description contains a multicast media stream which is
listed as receive (send) only, it means that the participants, listed as receive (send) only, it means that the participants,
including the offerer and answerer, can only receive (send) on that including the offerer and answerer, can only receive (send) on that
stream. This differs from the unicast view, where the directionality stream. This differs from the unicast view, where the directionality
refers to the flow of media between offerer and answerer. refers to the flow of media between offerer and answerer.
Beyond that clarification, the semantics of an offered multicast Beyond that clarification, the semantics of an offered multicast
stream are exactly as described in RFC 2327 [1]. stream are exactly as described in RFC 2327 [1].
6 Generating the answer 6 Generating the Answer
The answer to an offered SDP is based on the offered SDP. If the The answer to an offered session description is based on the offered
answer is different from the offer in any way (different IP session description. If the answer is different from the offer in
addresses, ports, etc.), the origin line MUST be different in the any way (different IP addresses, ports, etc.), the origin line MUST
answer, since the answer is generated by a different entity. In that be different in the answer, since the answer is generated by a
case, the version number in the "o=" line of the answer is unrelated different entity. In that case, the version number in the "o=" line
to the version number in the o line of the offer. of the answer is unrelated to the version number in the o line of the
offer.
For each "m=" line in the offer, there MUST be a corresponding "m=" For each "m=" line in the offer, there MUST be a corresponding "m="
line in the answer. The answer MUST contain exactly the same number line in the answer. The answer MUST contain exactly the same number
of "m=" lines as the offer. This allows for streams to be matched up of "m=" lines as the offer. This allows for streams to be matched up
based on their order. This implies that if the offer contained zero based on their order. This implies that if the offer contained zero
"m=" lines, the answer MUST contain zero "m=" lines. "m=" lines, the answer MUST contain zero "m=" lines.
The "t=" line in the answer MUST equal that of the offer. The time of The "t=" line in the answer MUST equal that of the offer. The time
the session cannot be negotiated. of the session cannot be negotiated.
An offered stream MAY be rejected in the answer, for any reason. If a An offered stream MAY be rejected in the answer, for any reason. If
stream is rejected, the offerer and answerer MUST NOT generate media a stream is rejected, the offerer and answerer MUST NOT generate
(or RTCP packets) for that stream. To reject an offered stream, the media (or RTCP packets) for that stream. To reject an offered
port number in the corresponding stream in the answer MUST be set to stream, the port number in the corresponding stream in the answer
zero. Any media formats listed are ignored. At least one MUST be MUST be set to zero. Any media formats listed are ignored. At least
present, as specified by SDP. one MUST be present, as specified by SDP.
Constructing an answer for each offered stream differs for unicast Constructing an answer for each offered stream differs for unicast
and multicast. and multicast.
6.1 Unicast Streams 6.1 Unicast Streams
If a stream is offered with a unicast address, the answer for that If a stream is offered with a unicast address, the answer for that
stream MUST contain a unicast address. The media type of the stream stream MUST contain a unicast address. The media type of the stream
in the answer MUST match that of the offer. in the answer MUST match that of the offer.
If a stream is offered as sendonly, the corresponding stream MUST be If a stream is offered as sendonly, the corresponding stream MUST be
marked as recvonly or inactive in the answer. If a media stream is marked as recvonly or inactive in the answer. If a media stream is
listed as recvonly in the offer, the answer MUST be marked as listed as recvonly in the offer, the answer MUST be marked as
sendonly or inactive in the answer. If an offered media stream is sendonly or inactive in the answer. If an offered media stream is
listed as sendrecv (or if there is no direction attribute at the listed as sendrecv (or if there is no direction attribute at the
media or session level, in which case the stream is sendrecv by media or session level, in which case the stream is sendrecv by
default), the corresponding stream in the answer MAY be marked as default), the corresponding stream in the answer MAY be marked as
sendonly, recvonly, sendrecv, or inactive in the answer. If an sendonly, recvonly, sendrecv, or inactive. If an offered media
offered media stream is listed as inactive, it MUST be marked as stream is listed as inactive, it MUST be marked as inactive in the
inactive in the answer. answer.
For streams marked as recvonly in the answer, the "m=" line MUST For streams marked as recvonly in the answer, the "m=" line MUST
contain at least one media format the answerer is willing to receive contain at least one media format the answerer is willing to receive
with from amongst those listed in the offer. The stream MAY indicate with from amongst those listed in the offer. The stream MAY indicate
additional media formats, not listed in the corresponding stream in additional media formats, not listed in the corresponding stream in
the offer, that the answerer is willing to receive with. For streams the offer, that the answerer is willing to receive. For streams
marked as sendonly in the answer, the "m=" line MUST contain at least marked as sendonly in the answer, the "m=" line MUST contain at least
one media format the answerer is willing to send with from amongst one media format the answerer is willing to send from amongst those
those listed in the offer. For streams marked as sendrecv in the listed in the offer. For streams marked as sendrecv in the answer,
answer, the "m=" line MUST contain at least one codec the answerer is the "m=" line MUST contain at least one codec the answerer is willing
willing to both send and receive with, from amongst those listed in to both send and receive, from amongst those listed in the offer.
the offer. The stream MAY indicate additional media formats, not The stream MAY indicate additional media formats, not listed in the
listed in the corresponding stream in the offer, that the answerer is corresponding stream in the offer, that the answerer is willing to
willing to send or receive with (of course, it not be able to send send or receive (of course, it will not be able to send them at this
with them at this time, since it was not listed in the offer). For time, since it was not listed in the offer). For streams marked as
streams marked as inactive in the answer, the list of media formats inactive in the answer, the list of media formats is constructed
is constructed based on the offer. If the offer was sendonly, the based on the offer. If the offer was sendonly, the list is
list is constructed as if the answer were recvonly. Similarly, if the constructed as if the answer were recvonly. Similarly, if the offer
offer was recvonly, the list is constructed as if the answer were was recvonly, the list is constructed as if the answer were sendonly,
sendonly, and if the offer was sendrecv, the list is constructed as and if the offer was sendrecv, the list is constructed as if the
if the answer were sendrecv. If the offer was inactive, the list is answer were sendrecv. If the offer was inactive, the list is
constructed as if the offer were actually sendrecv and the answer constructed as if the offer were actually sendrecv and the answer
were sendrecv. were sendrecv.
The connection address and port in the answer indicate the address The connection address and port in the answer indicate the address
where the answerer wishes to receive media (in the case of RTP, RTCP where the answerer wishes to receive media (in the case of RTP, RTCP
will be received on the port which is one higher unless there is an will be received on the port which is one higher unless there is an
explicit indication otherwise). This address and port MUST be present explicit indication otherwise). This address and port MUST be
even for sendonly streams; in the case of RTP, the port one higher is present even for sendonly streams; in the case of RTP, the port one
still used to receive RTCP. higher is still used to receive RTCP.
In the case of RTP, if a particular codec was referenced with a In the case of RTP, if a particular codec was referenced with a
specific payload type number in the offer, that same payload type specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer. Even if the same number SHOULD be used for that codec in the answer. Even if the same
payload type number is used, the answer MUST contain rtpmap payload type number is used, the answer MUST contain rtpmap
attributes to define the payload type mappings for dynamic payload attributes to define the payload type mappings for dynamic payload
types, and SHOULD contain mappings for static payload types. The types, and SHOULD contain mappings for static payload types. The
media formats in the "m=" line MUST be listed in order of preference, media formats in the "m=" line MUST be listed in order of preference,
with the first format listed being preferred. In this case, preferred with the first format listed being preferred. In this case,
means that the offerer SHOULD use the format with the highest preferred means that the offerer SHOULD use the format with the
preference from the answer. highest preference from the answer.
Although the answerer MAY list the formats in their desired order of Although the answerer MAY list the formats in their desired order of
preference, it is RECOMMENDED that unless there is a specific reason, preference, it is RECOMMENDED that unless there is a specific reason,
the answerer list formats in the same relative order they were the answerer list formats in the same relative order they were
present in the offer. In other words, if a stream in the offer lists present in the offer. In other words, if a stream in the offer lists
audio codecs 8, 22 and 48, in that order, and the answerer only audio codecs 8, 22 and 48, in that order, and the answerer only
supports codecs 8 and 48, it is RECOMMENDED that, if the answerer has supports codecs 8 and 48, it is RECOMMENDED that, if the answerer has
no reason to change it, the ordering of codecs in the answer be 8, 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 in 48, and not 48, 8. This helps assure that the same codec is used in
both directions. both directions.
skipping to change at page 10, line 49 skipping to change at page 11, line 23
the media format they describe is present in the answer. Other fmtp the media format they describe is present in the answer. Other fmtp
parameters are more like parameters, for which it is perfectly parameters are more like parameters, for which it is perfectly
acceptable for each agent to use different values. In that case, the acceptable for each agent to use different values. In that case, the
answer MAY contain fmtp parameters, and those MAY have the same answer MAY contain fmtp parameters, and those MAY have the same
values as those in the offer, or they MAY be different. SDP values as those in the offer, or they MAY be different. SDP
extensions that define new parameters SHOULD specify the proper extensions that define new parameters SHOULD specify the proper
interpretation in offer/answer. interpretation in offer/answer.
The answerer MAY include a non-zero ptime attribute for any media The answerer MAY include a non-zero ptime attribute for any media
stream; this indicates the packetization interval that the answerer stream; this indicates the packetization interval that the answerer
would like to receive. There is no requirement that the packetization would like to receive. There is no requirement that the
interval be the same in each direction for a particular stream. packetization interval be the same in each direction for a particular
stream.
The answerer MAY include a bandwidth attribute for any media stream; The answerer MAY include a bandwidth attribute for any media stream;
this indicates the banwdith that the answerer would like the offerer this indicates the bandwidth that the answerer would like the offerer
to use when sending media. The value of zero is allowed, interpreted to use when sending media. The value of zero is allowed, interpreted
as described in Section 5. as described in Section 5.
If the answerer has no media formats in common for a particular If the answerer has no media formats in common for a particular
offered stream, the answerer MUST reject that media stream by setting offered stream, the answerer MUST reject that media stream by setting
the port to zero. the port to zero.
If there are no media formats in common for all streams, the entire If there are no media formats in common for all streams, the entire
offered session is rejected. offered session is rejected.
Once the answerer has sent the answer, it MUST be prepared to receive Once the answerer has sent the answer, it MUST be prepared to receive
media for any recvonly streams described by that answer. It MUST be media for any recvonly streams described by that answer. It MUST be
prepared to send and receive media for any sendrecv streams in the prepared to send and receive media for any sendrecv streams in the
answer, and it MAY send media immediately. The answerer MUST be answer, and it MAY send media immediately. The answerer MUST be
prepared to receive media for recvonly or sendrecv streams using any prepared to receive media for recvonly or sendrecv streams using any
media formats listed for those streams in the answer, and it MAY send media formats listed for those streams in the answer, and it MAY send
media immediately. When sending media, it SHOULD use a packetization media immediately. When sending media, it SHOULD use a packetization
interval equal to the value of the ptime attribute in the offer, if interval equal to the value of the ptime attribute in the offer, if
any was present. It SHOULD send media using a bandwidth no higher any was present. It SHOULD send media using a bandwidth no higher
than the value of the bandwidth attribute in the offer, if any was than the value of the bandwidth attribute in the offer, if any was
present. The answerer SHOULD send using the most preferred media present. The answerer MUST send using a media format in the offer
format in the offer that is also listed in the answer. In the case of that is also listed in the answer, and SHOULD send using the most
RTP, it MUST use the payload type numbers from the offer, even if preferred media format in the offer that is also listed in the
they differ from those in the answer. answer. In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer.
6.2 Multicast Streams 6.2 Multicast Streams
Unlike unicast, where there is a two-sided view of the stream, there Unlike unicast, where there is a two-sided view of the stream, there
is only a single view of the stream for multicast. As such, is only a single view of the stream for multicast. As such,
generating an answer to a multicast offer generally involves generating an answer to a multicast offer generally involves
modifying a limited set of aspects of the stream. modifying a limited set of aspects of the stream.
If a multicast stream is accepted, the address and port information If a multicast stream is accepted, the address and port information
in the answer MUST match that of the offer. Similarly, the in the answer MUST match that of the offer. Similarly, the
directionality information in the answer (sendonly, recvonly, or directionality information in the answer (sendonly, recvonly, or
sendrecv) MUST equal that of the offer. This is because all sendrecv) MUST equal that of the offer. This is because all
participants in a multicast session need to have equivalent views of participants in a multicast session need to have equivalent views of
the parameters of the session, and underlying assumption of the the parameters of the session, an underlying assumption of the
multicast bias of RFC 2327. multicast bias of RFC 2327.
The set of media formats in the answer MUST be equal to or be a The set of media formats in the answer MUST be equal to or be a
subset of those in the offer. Removing a format is a way for the subset of those in the offer. Removing a format is a way for the
answerer to indicate that the format is not supported. answerer to indicate that the format is not supported.
The ptime and bandwidth attributes in the answer MUST equal the ones The ptime and bandwidth attributes in the answer MUST equal the ones
in the offer, if present. If not present, a non-zero ptime MAY be in the offer, if present. If not present, a non-zero ptime MAY be
added to the answer. added to the answer.
7 Offerer Processing of the Answer 7 Offerer Processing of the Answer
When the offerer receives the answer, it MAY send media on the When the offerer receives the answer, it MAY send media on the
accepted stream(s) (assuming it is listed as sendrecv or recvonly in accepted stream(s) (assuming it is listed as sendrecv or recvonly in
the answer). It MUST send using a media format listed in the answer, 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 it and it SHOULD use the first media format listed in the answer when it
does send. does send.
The reason this is a SHOULD, and not a MUST, is because The reason this is a SHOULD, and not a MUST (its also a SHOULD,
there will oftentimes be a need to change codecs on the and not a MUST, for the answerer), is because there will
fly. For example, during silence periods, an agent might oftentimes be a need to change codecs on the fly. For example,
like to switch to a comfort noise codec. Or, if the user during silence periods, an agent might like to switch to a comfort
presses a number on the keypad, the agent might like to noise codec. Or, if the user presses a number on the keypad, the
send that using RFC 2833 [9]. Congestion control might agent might like to send that using RFC 2833 [9]. Congestion
necessitate changing to a lower rate codec based on control might necessitate changing to a lower rate codec based on
feedback. feedback.
The offerer SHOULD send media according to the value of any ptime and The offerer SHOULD send media according to the value of any ptime and
bandwidth attribute in the answer. bandwidth attribute in the answer.
The offerer MAY immediately cease listening for media formats that The offerer MAY immediately cease listening for media formats that
were listed in the initial offer, but not present in the answer. were listed in the initial offer, but not present in the answer.
8 Modifying the session 8 Modifying the Session
At any point during the session, either participant MAY issue a new At any point during the session, either participant MAY issue a new
offer to modify characteristics of the session. It is fundamental to offer to modify characteristics of the session. It is fundamental to
the operation of the offer/answer model that the exact same the operation of the offer/answer model that the exact same
offer/answer procedure defined above is used for modifying parameters offer/answer procedure defined above is used for modifying parameters
of an existing session. of an existing session.
The offer MAY be identical to the last SDP provided to the other The offer MAY be identical to the last SDP provided to the other
party (which may have been provided in an offer or an answer), or it party (which may have been provided in an offer or an answer), or it
MAY be different. We refer to the last SDP provided as the "previous MAY be different. We refer to the last SDP provided as the "previous
SDP". If the offer is the same, the answer MAY be the same as the SDP". If the offer is the same, the answer MAY be the same as the
previous SDP from the answerer, or it MAY be different. If the previous SDP from the answerer, or it MAY be different. If the
offered SDP is different from the previous SDP, some constraints are offered SDP is different from the previous SDP, some constraints are
placed on its construction, discussed below. placed on its construction, discussed below.
Nearly all aspects of the session can be modified. New streams can be Nearly all aspects of the session can be modified. New streams can
added, existing streams can be deleted, and parameters of existing be added, existing streams can be deleted, and parameters of existing
streams can change. When issuing an offer that modifies the session, streams can change. When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST previous SDP, except that the version in the origin field MUST
increment from the previous SDP by one. If the version in the origin increment by one from the previous SDP. If the version in the origin
line does not increment, the SDP MUST be identical to the SDP with line does not increment, the SDP MUST be identical to the SDP with
that version number. The answerer MUST be prepared to receive an that version number. The answerer MUST be prepared to receive an
offer that contains SDP with a version that has not changed; this is offer that contains SDP with a version that has not changed; this is
effectively a no-op. However, the answerer MUST generate a valid effectively a no-op. However, the answerer MUST generate a valid
answer (which MAY be the same as the previous SDP from the answerer, answer (which MAY be the same as the previous SDP from the answerer,
or MAY be different), according to the procedures defined in Section or MAY be different), according to the procedures defined in Section
6. 6.
If an SDP is offered, which is different from the previous SDP, the If an SDP is offered, which is different from the previous SDP, the
new SDP MUST have a matching media stream for each media stream in new SDP MUST have a matching media stream for each media stream in
the previous SDP. In other words, if the previous SDP had N "m=" 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 media lines, the new SDP MUST have at least N "m=" lines. The i-th media
stream in the previous SDP, counting from the top, matches the i-th stream in the previous SDP, counting from the top, matches the i-th
media stream in the new SDP, counting from the top. This matching is media stream in the new SDP, counting from the top. This matching is
necessary in order for the answerer to determine which stream in the necessary in order for the answerer to determine which stream in the
new SDP corresponds to a stream in the previous SDP. Because of these new SDP corresponds to a stream in the previous SDP. Because of
requirements, the number of "m=" lines in a stream never decreases, these requirements, the number of "m=" lines in a stream never
but either stays the same or increases. Deleted media streams from a decreases, but either stays the same or increases. Deleted media
previous SDP MUST NOT be removed in a new SDP; however, attributes streams from a previous SDP MUST NOT be removed in a new SDP;
for these streams need not be present. however, attributes for these streams need not be present.
8.1 Adding a Media Stream 8.1 Adding a Media Stream
New media streams are created by new additional media descriptions New media streams are created by new additional media descriptions
below the existing ones, or by reusing the "slot" used by an old below the existing ones, or by reusing the "slot" used by an old
media stream which had been disabled by setting its port to zero. New media stream which had been disabled by setting its port to zero.
media descriptions MUST appear below any existing media sections. The
rules for formatting these media descriptions are identical to those Reusing its slot means that the new media description replaces the
described in Section 5. old one, but retains its positioning relative to other media
descriptions in the SDP. New media descriptions MUST appear below
any existing media sections. The rules for formatting these media
descriptions are identical to those described in Section 5.
When the answerer receives an SDP with more media descriptions than When the answerer receives an SDP with more media descriptions than
the previous SDP from the offerer, or it receives an SDP with a media the previous SDP from the offerer, or it receives an SDP with a media
stream in a slot where the port was previously zero, the answerer stream in a slot where the port was previously zero, the answerer
knows that new media streams are being added. These can be rejected knows that new media streams are being added. These can be rejected
or accepted by placing a matching media description in the answer. or accepted by placing an appropriately structured media description
The procedures for constructing the new media description in the in the answer. The procedures for constructing the new media
answer are described in Section 6. description in the answer are described in Section 6.
8.2 Removing a Media Stream 8.2 Removing a Media Stream
Existing media streams are removed by creating a new SDP with the Existing media streams are removed by creating a new SDP with the
port number for that stream set to zero. The stream description MAY port number for that stream set to zero. The stream description MAY
omit all attributes present previously, and MAY list just a single omit all attributes present previously, and MAY list just a single
media format. media format.
A stream that is offered with a port of zero MUST be marked with port A stream that is offered with a port of zero MUST be marked with port
zero in the answer. Like the offer, the answer MAY omit all zero in the answer. Like the offer, the answer MAY omit all
attributes present previously, and MAY list just a single media attributes present previously, and MAY list just a single media
format from amongst those in the offer. format from amongst those in the offer.
Removal of a media stream implies that media is no longer sent for Removal of a media stream implies that media is no longer sent for
that stream, and any media that is received is discarded. In the case that stream, and any media that is received is discarded. In the
of RTP, RTCP transmission also ceases, as does processing of any case of RTP, RTCP transmission also ceases, as does processing of any
received RTCP packets. Any resources associated with it can be received RTCP packets. Any resources associated with it can be
released. The user interface might indicate that the stream has released. The user interface might indicate that the stream has
terminated, by closing the associated window on a PC, for example. terminated, by closing the associated window on a PC, for example.
8.3 Modifying a Media Stream 8.3 Modifying a Media Stream
Nearly all characteristics of a media stream can be modified. Nearly all characteristics of a media stream can be modified.
8.3.1 Modifying Address, Port or Transport 8.3.1 Modifying Address, Port or Transport
skipping to change at page 14, line 40 skipping to change at page 15, line 17
continue to listen on the old port until the media on the new port continue to listen on the old port until the media on the new port
reached the top of the playout buffer. At that time, it MAY cease reached the top of the playout buffer. At that time, it MAY cease
listening for media on the old port. listening for media on the old port.
The corresponding media stream in the answer MAY be the same as the The corresponding media stream in the answer MAY be the same as the
stream in the previous SDP from the answerer, or it MAY be different. stream in the previous SDP from the answerer, or it MAY be different.
If the updated stream is accepted by the answerer, the answerer If the updated stream is accepted by the answerer, the answerer
SHOULD begin sending traffic for that stream to the new port SHOULD begin sending traffic for that stream to the new port
immediately. If the answerer changes the port from the previous SDP, 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 as it MUST be prepared to receive media on both the old and new ports as
soon as the answer is sent. The answerer MUST NOT cease listening for soon as the answer is sent. The answerer MUST NOT cease listening
media on the old port until media arrives on the new port. At that for media on the old port until media arrives on the new port. At
time, it MAY cease listening for media on the old port. The same is that time, it MAY cease listening for media on the old port. The
true for an offerer that sends an updated offer with a new port; it same is true for an offerer that sends an updated offer with a new
MUST NOT cease listening for media on the old port until media port; it MUST NOT cease listening for media on the old port until
arrives on the new port. media arrives on the new port.
Of course, if the offered stream is rejected, the offerer can cease Of course, if the offered stream is rejected, the offerer can cease
being prepared to receive using the new port as soon as the rejection being prepared to receive using the new port as soon as the rejection
is received. is received.
To change the IP address where media is sent to, the same procedure To change the IP address where media is sent to, the same procedure
is followed for changing the port number. The only difference is that is followed for changing the port number. The only difference is
the connection line is updated, not the port number. that the connection line is updated, not the port number.
The transport for a stream MAY be changed. The process for doing this The transport for a stream MAY be changed. The process for doing
is identical to changing the port, except the transport is updated, this is identical to changing the port, except the transport is
not the port. updated, not the port.
8.3.2 Changing the Set of Media Formats 8.3.2 Changing the Set of Media Formats
The list of media formats used in the session MAY be changed. To do The list of media formats used in the session MAY be changed. To do
this, the offerer creates a new media description, with the list of this, the offerer creates a new media description, with the list of
media formats in the "m=" line different from the corresponding media media formats in the "m=" line different from the corresponding media
stream in the previous SDP. This list MAY include new formats, and stream in the previous SDP. This list MAY include new formats, and
MAY remove formats present from the previous SDP. However, in the MAY remove formats present from the previous SDP. However, in the
case of RTP, the mapping from a particular dynamic payload type case of RTP, the mapping from a particular dynamic payload type
number to a particular codec within that media stream MUST NOT change number to a particular codec within that media stream MUST NOT change
for the duration of a session. For example, if A generates an offer for the duration of a session. For example, if A generates an offer
with G.711 assigned to dynamic payload type number 46, payload type with G.711 assigned to dynamic payload type number 46, payload type
number 46 MUST refer to G.711 from that point forward in any offers number 46 MUST refer to G.711 from that point forward in any offers
or answers for that media stream within the session. However, it is or answers for that media stream within the session. However, it is
acceptable for multiple payload type numbers to be mapped to the same acceptable for multiple payload type numbers to be mapped to the same
codec, so that an updated offer could also use payload type number 72 codec, so that an updated offer could also use payload type number 72
for G.711. for G.711.
The mappings need to remain fixed for the duration of the The mappings need to remain fixed for the duration of the session
session because of the loose synchronization between because of the loose synchronization between signaling exchanges
signaling exchanges of SDP and the media stream. of SDP and the media stream.
The corresponding media stream in the answer is formulated as The corresponding media stream in the answer is formulated as
described in Section 6, and may result in a change in media formats described in Section 6, and may result in a change in media formats
as well. Similarly, as described in Section 6, as soon as it sends as well. Similarly, as described in Section 6, as soon as it sends
its answer, the answerer MAY begin sending media using any new codecs its answer, the answerer MUST begin sending media using any formats
in the offer (assuming the stream allows for sending), and MUST NOT in the offer that were also present in the answer, and SHOULD use the
send using any formats that are not in the offer, even if they were most preferred format in the offer that was also listed in the answer
present in a previous SDP from the peer. Similarly, when the offerer (assuming the stream allows for sending), and MUST NOT send using any
receives the answer, it MAY begin sending media using any new codecs formats that are not in the offer, even if they were present in a
in the answer (assuming the stream allows for sending), and MUST NOT previous SDP from the peer. Similarly, when the offerer receives the
send using any formats that are not in the answer, even if they were answer, it MUST begin sending media using any formats in the answer,
present in a previous SDP from the peer. and SHOULD use the most preferred one (assuming the stream allows for
sending), and MUST NOT send using any formats that are not in the
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 format When an agent ceases using a media format (by not listing that format
in an offer or answer, even though it was in a previous SDP) the in an offer or answer, even though it was in a previous SDP) the
agent will still need to be prepared to receive media with that agent will still need to be prepared to receive media with that
format for a brief time. How does it know when it can be prepared to format for a brief time. How does it know when it can be prepared to
stop receiving with that format? If it needs to know, there are three stop receiving with that format? If it needs to know, there are three
techniques that can be applied. First, the agent can change ports in techniques that can be applied. First, the agent can change ports in
addition to changing formats. When media arrives on the new port, it addition to changing formats. When media arrives on the new port, it
knows that the peer has ceased sending with the old format, and it knows that the peer has ceased sending with the old format, and it
can cease being prepared to receive with it. This approach has the can cease being prepared to receive with it. This approach has the
benefit of being media format independent. However, changes in ports benefit of being media format independent. However, changes in ports
may require changes in resource reservation or rekeying of security may require changes in resource reservation or rekeying of security
protocols. The second approach is to use a totally new set of dynamic protocols. The second approach is to use a totally new set of
payload types for all codecs when one is discarded. When media is dynamic payload types for all codecs when one is discarded. When
received with one of the new payload types, the agent knows that the media is received with one of the new payload types, the agent knows
peer has ceased sending with the old format. This approach doesn't that the peer has ceased sending with the old format. This approach
affect reservations or security contexts, but it is RTP specific and doesn't affect reservations or security contexts, but it is RTP
wasteful of a very small payload type space. A third approach is to specific and wasteful of a very small payload type space. A third
use a timer. When the SDP from the peer is received, the timer is approach is to use a timer. When the SDP from the peer is received,
set. When it fires, the agent can cease being prepared to receive the timer is set. When it fires, the agent can cease being prepared
with the old format. A value of one minute would typically be more to receive with the old format. A value of one minute would
than sufficient. In some cases, an agent may not care, and thus typically be more than sufficient. In some cases, an agent may not
continually be prepared to receive with the old formats. Nothing need care, and thus continually be prepared to receive with the old
be done in this case. formats. Nothing need be done in this case.
Of course, if the offered stream is rejected, the offer can cease Of course, if the offered stream is rejected, the offer can cease
being prepared to receive using any new codecs as soon as the being prepared to receive using any new formats as soon as the
rejection is received. rejection is received.
8.3.3 Changing Media Types 8.3.3 Changing Media Types
The media type (audio, video, etc.) for a stream MAY be changed. It The media type (audio, video, etc.) for a stream MAY be changed. It
is RECOMMENDED that the media type be changed (as opposed to adding a is RECOMMENDED that the media type be changed (as opposed to adding a
new stream), when the same logical data is being conveyed, but just new stream), when the same logical data is being conveyed, but just
in a different media format. This is particularly useful for changing in a different media format. This is particularly useful for
between voiceband fax and fax in a single stream, which are both changing between voiceband fax and fax in a single stream, which are
separate media types. To do this, the offerer creates a new media both separate media types. To do this, the offerer creates a new
description, with a new media type, in place of the description in media description, with a new media type, in place of the description
the previous SDP which is to be changed. in the previous SDP which is to be changed.
The corresponding media stream in the answer is formulated as The corresponding media stream in the answer is formulated as
described in Section 6. Assuming the stream is acceptable, the described in Section 6. Assuming the stream is acceptable, the
answerer SHOULD begin sending with the new media type and codecs as answerer SHOULD begin sending with the new media type and formats as
soon as it receives the offer. soon as it receives the offer. The offerer MUST be prepared to
receive media with both the old and new types until the answer is
received, and media with the new type is received and reaches the top
of the playout buffer.
8.3.4 Changing Attributes 8.3.4 Changing Attributes
Any other attributes in a media description MAY be updated in an Any other attributes in a media description MAY be updated in an
offer or answer. Generally, an agent MUST send media (if the offer or answer. Generally, an agent MUST send media (if the
directionality of the stream allows) using the new parameters once directionality of the stream allows) using the new parameters once
the SDP with the change is received. the SDP with the change is received.
8.4 Putting a Unicast Media Stream on Hold 8.4 Putting a Unicast Media Stream on Hold
If a party in a call wants to put the other party "on hold", i.e., 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 media request that it temporarily stops sending one or more unicast media
streams, a party offers the other an updated SDP. streams, a party offers the other an updated SDP.
If the stream to be placed on hold was previously a sendrecv media If the stream to be placed on hold was previously a sendrecv media
stream, it is placed on hold by marking it as sendonly. If the stream stream, it is placed on hold by marking it as sendonly. If the
to be placed on hold was previously a recvonly media stream, it is stream to be placed on hold was previously a recvonly media stream,
placed on hold by marking it inactive. it is placed on hold by marking it inactive.
This means that a stream is placed "on hold" separately in each This means that a stream is placed "on hold" separately in each
direction. Each stream is placed "on hold" independently. The direction. Each stream is placed "on hold" independently. The
recipient of an offer for a stream on-hold SHOULD NOT automatically recipient of an offer for a stream on-hold SHOULD NOT automatically
return an answer with the corresponding stream on hold. An SDP with return an answer with the corresponding stream on hold. An SDP with
all streams "on hold" is referred to as held SDP all streams "on hold" is referred to as held SDP.
Certain third party call control scenarios do not work when Certain third party call control scenarios do not work when an
an answerer responds to held SDP with held SDP. answerer responds to held SDP with held SDP.
Typically, when a user "presses" hold, the agent will generate an Typically, when a user "presses" hold, the agent will generate an
offer with all streams in the SDP indicating a direction of sendonly, 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 far and it will also locally mute, so that no media is sent to the far
end, and no media is played out. end, and no media is played out.
RFC 2543 [10] specified that placing a user on hold was accomplished RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting a by setting the connection address to 0.0.0.0. Its usage for putting
call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media. However, it can be useful in an with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port number ports at the time of the offer. Of course, when used, the port
MUST NOT be zero, which would specify that the stream has been number MUST NOT be zero, which would specify that the stream has been
disabled. An agent MUST be capable of receiving SDP with a connection disabled. An agent MUST be capable of receiving SDP with a
address of 0.0.0.0, in which case it means that neither RTP nor RTCP connection address of 0.0.0.0, in which case it means that neither
should be sent to the peer. RTP nor RTCP should be sent to the peer.
9 Indicating Capabilities 9 Indicating Capabilities
Before an agent sends an offer, it is helpful to know if the media Before an agent sends an offer, it is helpful to know if the media
formats in that offer would be acceptable to the answerer. Certain formats in that offer would be acceptable to the answerer. Certain
protocols, like SIP, provide a means to query for such capabilities. protocols, like SIP, provide a means to query for such capabilities.
SDP can be used in responses to such queries to indicate SDP can be used in responses to such queries to indicate
capabilities. This section describes how such an SDP message is capabilities. This section describes how such an SDP message is
formatted. Since SDP has no way to indicate that the message is for formatted. Since SDP has no way to indicate that the message is for
the purpose of capability indication, this is determined from the the purpose of capability indication, this is determined from the
context of the higher layer protocol. The ability of baseline SDP to context of the higher layer protocol. The ability of baseline SDP to
indicate capabilities is very limited. It cannot express allowed indicate capabilities is very limited. It cannot express allowed
parameter ranges or values, and can not be done in parallel with an parameter ranges or values, and can not be done in parallel with an
offer/answer itself. Extensions might address such limitations in the offer/answer itself. Extensions might address such limitations in
future. the future.
An SDP constructed to indicate media capabilities is structured as An SDP constructed to indicate media capabilities is structured as
follows. It MUST be a valid SDP, except that it MAY omit both "e=" 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 each media and "p=" lines. The "t=" line MUST be equal to "0 0". For each
type supported by the agent, there MUST be a corresponding media media type supported by the agent, there MUST be a corresponding
description of that type. The session ID in the origin field MUST be media description of that type. The session ID in the origin field
unique for each SDP constructed to indicate media capabilities. The MUST be unique for each SDP constructed to indicate media
port MUST be set to zero, but the connection address is arbitrary. capabilities. The port MUST be set to zero, but the connection
The usage of port zero makes sure that an SDP formatted for address is arbitrary. The usage of port zero makes sure that an SDP
capabilities does not cause media streams to be established if it is formatted for capabilities does not cause media streams to be
interpreted as an offer or answer. established if it is interpreted as an offer or answer.
The transport component of the "m=" line indicates the transport for The transport component of the "m=" line indicates the transport for
that media type. For each media format of that type supported by the that media type. For each media format of that type supported by the
agent, there SHOULD be a media format listed in the "m=" line. In the agent, there SHOULD be a media format listed in the "m=" line. In
case of RTP, if dynamic payload types are used, an rtpmap attribute the case of RTP, if dynamic payload types are used, an rtpmap
MUST be present to bind the type to a specific format. There is no attribute MUST be present to bind the type to a specific format.
way to indicate constraints, such as how many simultaneous streams There is no way to indicate constraints, such as how many
can be supported for a particular codec, and so on. simultaneous streams can be supported for a particular codec, and so
on.
v=0 v=0
o=carol 28908764872 28908764872 IN IP4 100.3.6.6 o=carol 28908764872 28908764872 IN IP4 100.3.6.6
s=- s=-
t=0 0 t=0 0
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
m=audio 0 RTP/AVP 0 1 3 m=audio 0 RTP/AVP 0 1 3
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000 a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000 a=rtpmap:3 GSM/8000
skipping to change at page 19, line 4 skipping to change at page 19, line 32
Figure 1: SDP Indicating Capabilities Figure 1: SDP Indicating Capabilities
The SDP of Figure 1 indicates that the agent can support three audio The SDP of Figure 1 indicates that the agent can support three audio
codecs (PCMU, 1016, and GSM) and two video codecs (H.261 and H.263). codecs (PCMU, 1016, and GSM) and two video codecs (H.261 and H.263).
10 Example Offer/Answer Exchanges 10 Example Offer/Answer Exchanges
This section provides example offer/answer exchanges. This section provides example offer/answer exchanges.
10.1 Basic Exchange 10.1 Basic Exchange
Assume that the caller Alice, has included the following description
Assume that the caller, Alice, has included the following description
in her offer. It includes a bidirectional audio stream and two in her offer. It includes a bidirectional audio stream and two
bidirectional video streams, using H.261 (payload type 31) and MPEG bidirectional video streams, using H.261 (payload type 31) and MPEG
(payload type 32). The offered SDP is: (payload type 32). The offered SDP is:
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s= s=
c=IN IP4 host.anywhere.com c=IN IP4 host.anywhere.com
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
skipping to change at page 20, line 26 skipping to change at page 21, line 14
Alice accepts the additional media stream, and so generates the Alice accepts the additional media stream, and so generates the
following answer: following answer:
v=0 v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s= s=
c=IN IP4 host.anywhere.com c=IN IP4 host.anywhere.com
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31 m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32 m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110 m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000 a=rtpmap:110 telephone-events/8000
a=sendonly a=sendonly
10.2 One of N Codec Selection 10.2 One of N Codec Selection
A common occurence in embedded phones is that the Digital Signal A common occurrence in embedded phones is that the Digital Signal
Processor (DSP) used for compression can support multiple codecs at a Processor (DSP) used for compression can support multiple codecs at a
time, but once that codec is selected, it cannot be readily changed time, but once that codec is selected, it cannot be readily changed
on the fly. This example shows how a session can be set up using an on the fly. This example shows how a session can be set up using an
initial offer/answer exchange, followed immediately by a second one initial offer/answer exchange, followed immediately by a second one
to lock down the set of codecs. to lock down the set of codecs.
The initial offer from Alice to Bob indicates a single audio stream The initial offer from Alice to Bob indicates a single audio stream
with the three audio codecs that are available in the DSP. The stream with the three audio codecs that are available in the DSP. The
is marked as inactive, since media cannot be received until a codec stream is marked as inactive, since media cannot be received until a
is locked down: codec is locked down:
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s= s=
c=IN IP4 host.anywhere.com c=IN IP4 host.anywhere.com
t=0 0 t=0 0
m=audio 62986 RTP/AVP 0 4 18 m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000 a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000 a=rtpmap:18 G729/8000
skipping to change at page 22, line 15 skipping to change at page 22, line 40
v=0 v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com o=bob 2890844730 2890844732 IN IP4 host.example.com
s= s=
c=IN IP4 host.example.com c=IN IP4 host.example.com
t=0 0 t=0 0
m=audio 54344 RTP/AVP 4 m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000 a=rtpmap:4 G723/8000
a=sendrecv a=sendrecv
If the answerer (Bob), was only capable of supporting one-of-N
codecs, Bob would select one of the codecs from the offer, and place
that in his answer. In this case, Alice would do a re-INVITE to
activate that stream with that codec.
As an alternative to using "a=inactive" in the first exchange, Alice As an alternative to using "a=inactive" in the first exchange, Alice
can list all codecs, and as soon as she receives media from Bob, can list all codecs, and as soon as she receives media from Bob,
generate an updated offer locking down the codec to the one just generate an updated offer locking down the codec to the one just
recevied. There is a potential race condition, however. If both Bob received. Of course, if Bob only supports one-of-N codecs, there
and Alice do this (Alice in her offer, Bob in his answer), both may would only be one codec in his answer, and in this case, there is no
attempt to issue updated offers at the same time. The protocol which need for a re-INVITE to lock down to a single codec.
carries offers and answers has to provide a means to resolve these
glare conditions, so that only one offer will be used.
11 Security Considerations 11 Security Considerations
There are numerous attacks possible if an attacker can modify offers There are numerous attacks possible if an attacker can modify offers
or answers in transit. Generally, these include diversion of media or answers in transit. Generally, these include diversion of media
streams (enabling eavesdropping), disabling of calls, and injection streams (enabling eavesdropping), disabling of calls, and injection
of unwanted media streams. If a passive listener can construct fake of unwanted media streams. If a passive listener can construct fake
offers, and inject those into an exchange, similar attacks are offers, and inject those into an exchange, similar attacks are
possible. Even if an attacker can simply observe offers and answers, possible. Even if an attacker can simply observe offers and answers,
they can inject media streams into an existing conversation. they can inject media streams into an existing conversation.
Offer/answer relies on transport within an application signaling Offer/answer relies on transport within an application signaling
protocol, such as SIP. It also relies on that protocol for security protocol, such as SIP. It also relies on that protocol for security
capabilities. Because of the attacks described above, that protocol capabilities. Because of the attacks described above, that protocol
MUST provide a means for end-to-end authentication and integrity MUST provide a means for end-to-end authentication and integrity
protection of offers and answers. It SHOULD offer encryption of protection of offers and answers. It SHOULD offer encryption of
bodies to prevent eavesdropping. However, media injection attacks can bodies to prevent eavesdropping. However, media injection attacks
alternatively be resolved through authenticated media exchange, and can alternatively be resolved through authenticated media exchange,
therefore the encryption requirement is a SHOULD instead of a MUST. and therefore the encryption requirement is a SHOULD instead of a
MUST.
Replay attacks are also problematic. An attacker can replay an old Replay attacks are also problematic. An attacker can replay an old
offer, perhaps one that had put media on hold, and thus disable media offer, perhaps one that had put media on hold, and thus disable media
streams in a conversation. Therefore, the application protocol MUST streams in a conversation. Therefore, the application protocol MUST
provide a secure way to sequence offers and answers, and to detect provide a secure way to sequence offers and answers, and to detect
and reject old offers or answers. and reject old offers or answers.
SIP [7] meets all of these requirements. SIP [7] meets all of these requirements.
12 IANA Considerations 12 IANA Considerations
There are no IANA considerations with this specification. There are no IANA considerations with this specification.
13 Acknowledgements 13 Acknowledgements
The authors would like to thank Allison Mankin, Rohan Mahy, Joerg The authors would like to thank Allison Mankin, Rohan Mahy, Joerg
Ott, and Flemming Andreasen for their detailed comments. Ott, and Flemming Andreasen for their detailed comments.
14 Author's Addresses 14 Normative References
Jonathan Rosenberg [1] Handley, M. and V. Jacobson, "SDP: Session Description
dynamicsoft Protocol", RFC 2327, April 1998.
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Henning Schulzrinne [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Dept. of Computer Science Levels", BCP 14, RFC 2119, March 1997.
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
email: schulzrinne@cs.columbia.edu
15 Normative References [3] Kumar, R. and M. Mostafa, "Conventions For the Use of The
Session Description Protocol (SDP) for ATM Bearer Connections",
RFC 3108, May 2001.
[1] M. Handley and V. Jacobson, "SDP: session description protocol," [4] Schulzrinne, H., Casner, S, Frederick, R. and V. Jacobson,
Request for Comments 2327, Internet Engineering Task Force, Apr. "RTP: A Transport Protocol for Real-Time Applications", RFC
1998. 1889, January 1996.
[2] S. Bradner, "Key words for use in RFCs to indicate requirement [5] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
levels," Request for Comments 2119, Internet Engineering Task Force, with Minimal Control", RFC 1890, January 1996.
Mar. 1997.
[3] R. Kumar and M. Mostafa, "Conventions for the use of the session 15 Informative References
description protocol (SDP) for ATM bearer connections," Request for
Comments 3108, Internet Engineering Task Force, May 2001.
[4] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a [6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
transport protocol for real-time applications," Request for Comments Protocol", RFC 2974, October 2000.
1889, Internet Engineering Task Force, Jan. 1996.
[5] H. Schulzrinne, "RTP profile for audio and video conferences with [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
minimal control," Request for Comments 1890, Internet Engineering Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Task Force, Jan. 1996. Session Initiation Protocol", RFC 3261, June 2002.
16 Informative References [8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[6] M. Handley, C. Perkins, and E. Whelan, "Session announcement [9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
protocol," Request for Comments 2974, Internet Engineering Task Telephony Tones and Telephony Signals", RFC 2833, May 2000.
Force, Oct. 2000.
[7] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation [10] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
protocol," Internet Draft, Internet Engineering Task Force, Feb. "SIP: Session Initiation Protocol", RFC 2543, March 1999.
2002. Work in progress.
[8] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming 16 Authors' Addresses
protocol (RTSP)," Request for Comments 2326, Internet Engineering
Task Force, Apr. 1998.
[9] H. Schulzrinne and S. Petrack, "RTP payload for DTMF digits, Jonathan Rosenberg
telephony tones and telephony signals," Request for Comments 2833, dynamicsoft
Internet Engineering Task Force, May 2000. 72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
[10] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: EMail: jdrosen@dynamicsoft.com
session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999.
Full Copyright Statement Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
Copyright (c) The Internet Society (2002). All Rights Reserved. EMail: schulzrinne@cs.columbia.edu
17. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at line 1147 skipping to change at page 25, line 32
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/