rfc3264.txt

RFC 的详细文档！

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
   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                     [Page 2]

RFC 3264  An Offer/Answer Model Session Description Protocol   June 2002


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

   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
   in the unicast case, but both sides send packets to the same
   multicast address, rather than unicast ones.  This document also
   discusses the application of the offer/answer model to multicast
   streams.

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

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

2 Terminology

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

3 Definitions

   The following terms are used throughout this document:

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

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

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







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


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

      Offer: An SDP message sent by an offerer.

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

4 Protocol Operation

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

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

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

   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 an offer which it has not yet answered or rejected.
   Furthermore, it MUST NOT generate a new offer if it has generated a
   prior offer for which it has not yet received an answer or a
   rejection.  If an agent receives an offer after having sent one, but
   before receiving an answer to it, this is considered a "glare"
   condition.

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







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


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

5 Generating the Initial Offer

   The offer (and answer) MUST be a valid SDP message, as defined by RFC
   2327 [1], with one exception.  RFC 2327 mandates that either an e or
   a p line is present in the SDP message.  This specification relaxes
   that constraint; an SDP formulated for an offer/answer application
   MAY omit both the e and p lines.  The numeric value of the session id
   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)-1, to avoid rollovers.  Although the SDP specification allows
   for multiple session descriptions to be concatenated together into a
   large SDP message, an SDP message used in the offer/answer model MUST
   contain exactly one session description.

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

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

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

   The offer will contain zero or more media streams (each media stream
   is described by an "m=" line and its associated attributes).  Zero
   media streams implies that the offerer wishes to communicate, but
   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 multicast; the latter obviously implies a multicast address in
   the relevant "c=" line(s).

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

5.1 Unicast Streams

   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
   refer to a stream as being marked with a certain direction if a
   direction attribute was present as either a media stream attribute or