rfc2327.txt

网络MPEG4IP流媒体开发源代码

Network Working Group                                           M. Handley
Request for Comments: 2327                                     V. Jacobson
Category: Standards Track                                         ISI/LBNL
                                                                April 1998


                   SDP: Session Description Protocol

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 (1998).  All Rights Reserved.

Abstract

   This document defines the Session Description Protocol, SDP.  SDP is
   intended for describing multimedia sessions for the purposes of
   session announcement, session invitation, and other forms of
   multimedia session initiation.

   This document is a product of the Multiparty Multimedia Session
   Control (MMUSIC) working group of the Internet Engineering Task
   Force. Comments are solicited and should be addressed to the working
   group's mailing list at [e-mail] and/or the authors.

1.  Introduction

   On the Internet multicast backbone (Mbone), a session directory tool
   is used to advertise multimedia conferences and communicate the
   conference addresses and conference tool-specific information
   necessary for participation.  This document defines a session
   description protocol for this purpose, and for general real-time
   multimedia session description purposes. This memo does not describe
   multicast address allocation or the distribution of SDP messages in
   detail.  These are described in accompanying memos.  SDP is not
   intended for negotiation of media encodings.








Handley & Jacobson          Standards Track                     [Page 1]

RFC 2327                          SDP                         April 1998


2.  Background

   The Mbone is the part of the internet that supports IP multicast, and
   thus permits efficient many-to-many communication.  It is used
   extensively for multimedia conferencing.  Such conferences usually
   have the property that tight coordination of conference membership is
   not necessary; to receive a conference, a user at an Mbone site only
   has to know the conference's multicast group address and the UDP
   ports for the conference data streams.

   Session directories assist the advertisement of conference sessions
   and communicate the relevant conference setup information to
   prospective participants.  SDP is designed to convey such information
   to recipients.  SDP is purely a format for session description - it
   does not incorporate a transport protocol, and is intended to use
   different transport protocols as appropriate including the Session
   Announcement Protocol [4], Session Initiation Protocol [11], Real-
   Time Streaming Protocol [12], electronic mail using the MIME
   extensions, and the Hypertext Transport Protocol.

   SDP is intended to be general purpose so that it can be used for a
   wider range of network environments and applications than just
   multicast session directories.  However, it is not intended to
   support negotiation of session content or media encodings - this is
   viewed as outside the scope of session description.

3.  Glossary of Terms

   The following terms are used in this document, and have specific
   meaning within the context of this document.

   Conference
     A multimedia conference is a set of two or more communicating users
     along with the software they are using to communicate.

   Session
     A multimedia session is a set of multimedia senders and receivers
     and the data streams flowing from senders to receivers.  A
     multimedia conference is an example of a multimedia session.

   Session Advertisement
     See session announcement.

   Session Announcement
     A session announcement is a mechanism by which a session
     description is conveyed to users in a proactive fashion, i.e., the
     session description was not explicitly requested by the user.




Handley & Jacobson          Standards Track                     [Page 2]

RFC 2327                          SDP                         April 1998


   Session Description
     A well defined format for conveying sufficient information to
     discover and participate in a multimedia session.

3.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

4.  SDP Usage

4.1.  Multicast Announcements

   SDP is a session description protocol for multimedia sessions. A
   common mode of usage is for a client to announce a conference session
   by periodically multicasting an announcement packet to a well known
   multicast address and port using the Session Announcement Protocol
   (SAP).

   SAP packets are UDP packets with the following format:

         |--------------------|
         | SAP header         |
         |--------------------|
         | text payload       |
         |//////////


   The header is the Session Announcement Protocol header.  SAP is
   described in more detail in a companion memo [4]

   The text payload is an SDP session description, as described in this
   memo.  The text payload should be no greater than 1 Kbyte in length.
   If announced by SAP, only one session announcement is permitted in a
   single packet.

4.2.  Email and WWW Announcements

   Alternative means of conveying session descriptions include
   electronic mail and the World Wide Web. For both email and WWW
   distribution, the use of the MIME content type "application/sdp"
   should be used.  This enables the automatic launching of applications
   for participation in the session from the WWW client or mail reader
   in a standard manner.






Handley & Jacobson          Standards Track                     [Page 3]

RFC 2327                          SDP                         April 1998


   Note that announcements of multicast sessions made only via email or
   the World Wide Web (WWW) do not have the property that the receiver
   of a session announcement can necessarily receive the session because
   the multicast sessions may be restricted in scope, and access to the
   WWW server or reception of email is possible outside this scope.  SAP
   announcements do not suffer from this mismatch.

5.  Requirements and Recommendations

   The purpose of SDP is to convey information about media streams in
   multimedia sessions to allow the recipients of a session description
   to participate in the session.  SDP is primarily intended for use in
   an internetwork, although it is sufficiently general that it can
   describe conferences in other network environments.

   A multimedia session, for these purposes, is defined as a set of
   media streams that exist for some duration of time.  Media streams
   can be many-to-many.  The times during which the session is active
   need not be continuous.

   Thus far, multicast based sessions on the Internet have differed from
   many other forms of conferencing in that anyone receiving the traffic
   can join the session (unless the session traffic is encrypted).  In
   such an environment, SDP serves two primary purposes.  It is a means
   to communicate the existence of a session, and is a means to convey
   sufficient information to enable joining and participating in the
   session.  In a unicast environment, only the latter purpose is likely
   to be relevant.

   Thus SDP includes:

   o Session name and purpose

   o Time(s) the session is active

   o The media comprising the session

   o Information to receive those media (addresses, ports, formats and
     so on)

   As resources necessary to participate in a session may be limited,
   some additional information may also be desirable:

   o Information about the bandwidth to be used by the conference

   o Contact information for the person responsible for the session





Handley & Jacobson          Standards Track                     [Page 4]

RFC 2327                          SDP                         April 1998


   In general, SDP must convey sufficient information to be able to join
   a session (with the possible exception of encryption keys) and to
   announce the resources to be used to non-participants that may need
   to know.

5.1.  Media Information

   SDP includes:

   o The type of media (video, audio, etc)

   o The transport protocol (RTP/UDP/IP, H.320, etc)

   o The format of the media (H.261 video, MPEG video, etc)

   For an IP multicast session, the following are also conveyed:

   o Multicast address for media

   o Transport Port for media

   This address and port are the destination address and destination
   port of the multicast stream, whether being sent, received, or both.

   For an IP unicast session, the following are conveyed:

   o Remote address for media

   o Transport port for contact address

   The semantics of this address and port depend on the media and
   transport protocol defined.  By default, this is the remote address
   and remote port to which data is sent, and the remote address and
   local port on which to receive data.  However, some media may define
   to use these to establish a control channel for the actual media
   flow.

5.2.  Timing Information

   Sessions may either be bounded or unbounded in time. Whether or not
   they are bounded, they may be only active at specific times.

   SDP can convey:

   o An arbitrary list of start and stop times bounding the session

   o For each bound, repeat times such as "every Wednesday at 10am for
     one hour"



Handley & Jacobson          Standards Track                     [Page 5]

RFC 2327                          SDP                         April 1998


   This timing information is globally consistent, irrespective of local
   time zone or daylight saving time.

5.3.  Private Sessions

   It is possible to create both public sessions and private sessions.
   Private sessions will typically be conveyed by encrypting the session
   description to distribute it.  The details of how encryption is
   performed are dependent on the mechanism used to convey SDP - see [4]
   for how this is done for session announcements.

   If a session announcement is private it is possible to use that
   private announcement to convey encryption keys necessary to decode
   each of the media in a conference, including enough information to
   know which encryption scheme is used for each media.

5.4.  Obtaining Further Information about a Session

   A session description should convey enough information to decide
   whether or not to participate in a session.  SDP may include
   additional pointers in the form of Universal Resources Identifiers
   (URIs) for more information about the session.

5.5.  Categorisation

   When many session descriptions are being distributed by SAP or any
   other advertisement mechanism, it may be desirable to filter