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   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
session下载
        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 rec
eiving 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
Rosenberg & Schulzrinne    Standards Track                    [Page 5]
RFC 3264  An Offer/Answer Model Session Description Protocol  June 2002
  a session attribute.  If the offerer wishes to only receive media
  from its peer, it MUST mark the stream as recvonly.  If the offerer
  wishes to communicate, but wishes to neither send nor receive media
  at this time, it MUST mark the stream with an "a=inactive" attribute.
  The inactive direction attribute is specified in RFC 3108 [3].  Note
  that in the case of the Real Time Transport Protocol (RTP) [4], RTCP
  is still sent and received for sendonly, recvonly, and inactive
  streams.  That is, the directionality of the media stream has no
  impact on the RTCP usage.  If the offerer wishes to both send and
  receive media with its peer, it MAY include an "a=sendrecv"
  attribute, or it MAY omit it, since sendrecv is the default.
  For recvonly and sendrecv streams, the port number and address in the
  offer indicate where the offerer would like to receive the media
  stream.  For sendonly RTP streams, the address and port number
  indirectly indicate where the offerer wants to receive RTCP reports.
  Unless there is an explicit indication otherwise, reports are sent to
  the port number one higher than the number indicated.  The IP address
  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
  the offerer.  A port number of zero in the offer indicates that the
  stream is offered but MUST NOT be used.  This has no useful semantics
  in an initial offer, but is allowed for reasons of completeness,
  since the answer can contain a zero port indicating a rejected stream
  (Section 6).  Furthermore, existing streams can be terminated by
  setting the port to zero (Section 8).  In general, a port number of
  zero indicates that the media stream is not wanted.
  The list of media formats for each media stream conveys two pieces of
  information, namely the set of formats (codecs and any parameters
  associated with the codec, in the case of RTP) that the offerer is
  capable of sending and/or receiving (depending on the direction
  attributes), and, in the case of RTP, the RTP p

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。