RFC 3264 (rfc3264) - Page 2 of 25
An Offer/Answer Model with Session Description Protocol (SDP)
Alternative Format: Original Text Document
RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
8.1 Adding a Media Stream ............................... 13
8.2 Removing a Media Stream ............................. 14
8.3 Modifying a Media Stream ............................ 14
8.3.1 Modifying Address, Port or Transport ................ 14
8.3.2 Changing the Set of Media Formats ................... 15
8.3.3 Changing Media Types ................................ 17
8.3.4 Changing Attributes ................................. 17
8.4 Putting a Unicast Media Stream on Hold .............. 17
9 Indicating Capabilities ............................. 18
10 Example Offer/Answer Exchanges ...................... 19
10.1 Basic Exchange ...................................... 19
10.2 One of N Codec Selection ............................ 21
11 Security Considerations ............................. 23
12 IANA Considerations ................................. 23
13 Acknowledgements .................................... 23
14 Normative References ................................ 23
15 Informative References .............................. 24
16 Authors' Addresses .................................. 24
17 Full Copyright Statement............................. 25
1 Introduction
The Session Description Protocol (SDP) [1] was originally conceived
as a way to describe multicast sessions carried on the Mbone. The
Session Announcement Protocol (SAP) [6] was devised as a multicast
mechanism to carry SDP messages. Although the SDP specification
allows for unicast operation, it is not complete. Unlike multicast,
where there is a global view of the session that is used by all
participants, unicast sessions involve two participants, and a
complete view of the session requires information from both
participants, and agreement on parameters between them.
As an example, a multicast session requires conveying a single
multicast address for a particular media stream. However, for a
unicast session, two addresses are needed - one for each participant.
As another example, a multicast session requires an indication of
which codecs will be used in the session. However, for unicast, the
set of codecs needs to be determined by finding an overlap in the set
supported by each participant.
As a result, even though SDP has the expressiveness to describe
unicast sessions, it is missing the semantics and operational details
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 participant in the session generates an SDP message that
constitutes the offer - the set of media streams and codecs the
offerer wishes to use, along with the IP addresses and ports the
offerer would like to use to receive the media. The offer is
Rosenberg & Schulzrinne Standards Track