rfc2327.txt

网络MPEG4IP流媒体开发源代码

   announcements that are of interest from those that are not.  SDP
   supports a categorisation mechanism for sessions that is capable of
   being automated.

5.6.  Internationalization

   The SDP specification recommends the use of the ISO 10646 character
   sets in the UTF-8 encoding (RFC 2044) to allow many different
   languages to be represented.  However, to assist in compact
   representations, SDP also allows other character sets such as ISO
   8859-1 to be used when desired.  Internationalization only applies to
   free-text fields (session name and background information), and not
   to SDP as a whole.

6.  SDP Specification

   SDP session descriptions are entirely textual using the ISO 10646
   character set in UTF-8 encoding. SDP field names and attributes names
   use only the US-ASCII subset of UTF-8, but textual fields and
   attribute values may use the full ISO 10646 character set.  The
   textual form, as opposed to a binary encoding such as ASN/1 or XDR,



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


   was chosen to enhance portability, to enable a variety of transports
   to be used (e.g, session description in a MIME email message) and to
   allow flexible, text-based toolkits (e.g., Tcl/Tk ) to be used to
   generate and to process session descriptions.  However, since the
   total bandwidth allocated to all SAP announcements is strictly
   limited, the encoding is deliberately compact.  Also, since
   announcements may be transported via very unreliable means (e.g.,
   email) or damaged by an intermediate caching server, the encoding was
   designed with strict order and formatting rules so that most errors
   would result in malformed announcements which could be detected
   easily and discarded. This also allows rapid discarding of encrypted
   announcements for which a receiver does not have the correct key.

   An SDP session description consists of a number of lines of text of
   the form <type>=<value> <type> is always exactly one character and is
   case-significant.  <value> is a structured text string whose format
   depends on <type>.  It also will be case-significant unless a
   specific field defines otherwise.  Whitespace is not permitted either
   side of the `=' sign. In general <value> is either a number of fields
   delimited by a single space character or a free format string.

   A session description consists of a session-level description
   (details that apply to the whole session and all media streams) and
   optionally several media-level descriptions (details that apply onto
   to a single media stream).

   An announcement consists of a session-level section followed by zero
   or more media-level sections.  The session-level part starts with a
   `v=' line and continues to the first media-level section.  The media
   description starts with an `m=' line and continues to the next media
   description or end of the whole session description.  In general,
   session-level values are the default for all media unless overridden
   by an equivalent media-level value.

   When SDP is conveyed by SAP, only one session description is allowed
   per packet.  When SDP is conveyed by other means, many SDP session
   descriptions may be concatenated together (the `v=' line indicating
   the start of a session description terminates the previous
   description).  Some lines in each description are required and some
   are optional but all must appear in exactly the order given here (the
   fixed order greatly enhances error detection and allows for a simple
   parser). Optional items are marked with a `*'.

Session description
        v=  (protocol version)
        o=  (owner/creator and session identifier).
        s=  (session name)
        i=* (session information)



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


        u=* (URI of description)
        e=* (email address)
        p=* (phone number)
        c=* (connection information - not required if included in all media)
        b=* (bandwidth information)
        One or more time descriptions (see below)
        z=* (time zone adjustments)
        k=* (encryption key)
        a=* (zero or more session attribute lines)
        Zero or more media descriptions (see below)

Time description
        t=  (time the session is active)
        r=* (zero or more repeat times)

Media description
        m=  (media name and transport address)
        i=* (media title)
        c=* (connection information - optional if included at session-level)
        b=* (bandwidth information)
        k=* (encryption key)
        a=* (zero or more media attribute lines)

   The set of `type' letters is deliberately small and not intended to
   be extensible -- SDP parsers must completely ignore any announcement
   that contains a `type' letter that it does not understand. The
   `attribute' mechanism ("a=" described below) is the primary means for
   extending SDP and tailoring it to particular applications or media.
   Some attributes (the ones listed in this document) have a defined
   meaning but others may be added on an application-, media- or
   session-specific basis.  A session directory must ignore any
   attribute it doesn't understand.

   The connection (`c=') and attribute (`a=') information in the
   session-level section applies to all the media of that session unless
   overridden by connection information or an attribute of the same name
   in the media description.  For instance, in the example below, each
   media behaves as if it were given a `recvonly' attribute.

   An example SDP description is:

        v=0
        o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
        s=SDP Seminar
        i=A Seminar on the session description protocol
        u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
        e=[e-mail] (Mark Handley)
        c=IN IP4 224.2.17.12/127



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


        t=2873397496 2873404696
        a=recvonly
        m=audio 49170 RTP/AVP 0
        m=video 51372 RTP/AVP 31
        m=application 32416 udp wb
        a=orient:portrait

   Text records such as the session name and information are bytes
   strings which may contain any byte with the exceptions of 0x00 (Nul),
   0x0a (ASCII newline) and 0x0d (ASCII carriage return).  The sequence
   CRLF (0x0d0a) is used to end a record, although parsers should be
   tolerant and also accept records terminated with a single newline
   character.  By default these byte strings contain ISO-10646
   characters in UTF-8 encoding, but this default may be changed using
   the `charset' attribute.

   Protocol Version

   v=0

   The "v=" field gives the version of the Session Description Protocol.
   There is no minor version number.

   Origin

   o=<username> <session id> <version> <network type> <address type>
   <address>

   The "o=" field gives the originator of the session (their username
   and the address of the user's host) plus a session id and session
   version number.

   <username> is the user's login on the originating host, or it is "-"
   if the originating host does not support the concept of user ids.
   <username> must not contain spaces.  <session id> is a numeric string
   such that the tuple of <username>, <session id>, <network type>,
   <address type> and <address> form a globally unique identifier for
   the session.

   The method of <session id> allocation is up to the creating tool, but
   it has been suggested that a Network Time Protocol (NTP) timestamp be
   used to ensure uniqueness [1].

   <version> is a version number for this announcement.  It is needed
   for proxy announcements to detect which of several announcements for
   the same session is the most recent.  Again its usage is up to the





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


   creating tool, so long as <version> is increased when a modification
   is made to the session data.  Again, it is recommended (but not
   mandatory) that an NTP timestamp is used.

   <network type> is a text string giving the type of network.
   Initially "IN" is defined to have the meaning "Internet".  <address
   type> is a text string giving the type of the address that follows.
   Initially "IP4" and "IP6" are defined.  <address> is the globally
   unique address of the machine from which the session was created.
   For an address type of IP4, this is either the fully-qualified domain
   name of the machine, or the dotted-decimal representation of the IP
   version 4 address of the machine.  For an address type of IP6, this
   is either the fully-qualified domain name of the machine, or the
   compressed textual representation of the IP version 6 address of the
   machine.  For both IP4 and IP6, the fully-qualified domain name is
   the form that SHOULD be given unless this is unavailable, in which
   case the globally unique address may be substituted.  A local IP
   address MUST NOT be used in any context where the SDP description
   might leave the scope in which the address is meaningful.

   In general, the "o=" field serves as a globally unique identifier for
   this version of this session description, and the subfields excepting
   the version taken together identify the session irrespective of any
   modifications.

   Session Name

   s=<session name>

   The "s=" field is the session name.  There must be one and only one
   "s=" field per session description, and it must contain ISO 10646
   characters (but see also the `charset' attribute below).

   Session and Media Information

   i=<session description>

   The "i=" field is information about the session.  There may be at
   most one session-level "i=" field per session description, and at
   most one "i=" field per media. Although it may be omitted, this is
   discouraged for session announcements, and user interfaces for
   composing sessions should require text to be entered.  If it is
   present it must contain ISO 10646 characters (but see also the
   `charset' attribute below).

   A single "i=" field can also be used for each media definition.  In
   media definitions, "i=" fields are primarily intended for labeling
   media streams. As such, they are most likely to be useful when a



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


   single session has more than one distinct media stream of the same
   media type.  An example would be two different whiteboards, one for
   slides and one for feedback and questions.

   URI

   u=<URI>

   o A URI is a Universal Resource Identifier as used by WWW clients

   o The URI should be a pointer to additional information about the
     conference

   o This field is optional, but if it is present it should be specified
     before the first media field

   o No more than one URI field is allowed per session description


   Email Address and Phone Number

   e=<email address>
   p=<phone number>

   o These specify contact information for the person responsible for
     the conference.  This is not necessarily the same person that
     created the conference announcement.

   o Either an email field or a phone field must be specified.
     Additional email and phone fields are allowed.

   o If these are present, they should be specified before the first
     media field.

   o More than one email or phone field can be given for a session
     description.

   o Phone numbers should be given in the conventional international

     format - preceded by a "+ and the international country code.
     There must be a space or a hyphen ("-") between the country code
     and the rest of the phone number.  Spaces and hyphens may be used
     to split up a phone field to aid readability if desired. For
     example:

                   p=[phone] or p=[phone]





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


   o Both email addresses and phone numbers can have an optional free
     text string associated with them, normally giving the name of the
     person who may be contacted.  This should be enclosed in
     parenthesis if it is present.  For example: