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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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

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

Status of this Memo

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

Copyright Notice

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

Abstract

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

Table of Contents

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

Rosenberg & Schulzrinne     Standards Track                     [Page 1]
RFC 3264  An Offer/Answer Model Session Description Protocol   June 2002

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

1 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