RFC 3264 (rfc3264) - Page 2 of 25

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

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