rfc2327.txt

网络MPEG4IP流媒体开发源代码

                        e=[e-mail] (Mark Handley)

     The alternative RFC822 name quoting convention is also allowed for
     both email addresses and phone numbers.  For example,

                        e=Mark Handley <[e-mail]>

     The free text string should be in the ISO-10646 character set with
     UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings
     if the appropriate charset session-level attribute is set.

   Connection Data

   c=<network type> <address type> <connection address>

   The "c=" field contains connection data.

   A session announcement must contain one "c=" field in each media
   description (see below) or a "c=" field at the session-level.  It may
   contain a session-level "c=" field and one additional "c=" field per
   media description, in which case the per-media values override the
   session-level settings for the relevant media.

   The first sub-field is the network type, which is a text string
   giving the type of network.  Initially "IN" is defined to have the
   meaning "Internet".

   The second sub-field is the address type.  This allows SDP to be used
   for sessions that are not IP based.  Currently only IP4 is defined.

   The third sub-field is the connection address.  Optional extra
   subfields may be added after the connection address depending on the
   value of the <address type> field.

   For IP4 addresses, the connection address is defined as follows:

   o Typically the connection address will be a class-D IP multicast

     group address.  If the session is not multicast, then the
     connection address contains the fully-qualified domain name or the
     unicast IP address of the expected data source or data relay or
     data sink as determined by additional attribute fields. It is not
     expected that fully-qualified domain names or unicast addresses



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


     will be given in a session description that is communicated by a
     multicast announcement, though this is not prohibited.  If a
     unicast data stream is to pass through a network address
     translator, the use of a fully-qualified domain name rather than an
     unicast IP address is RECOMMENDED.  In other cases, the use of an
     IP address to specify a particular interface on a multi-homed host
     might be required.  Thus this specification leaves the decision as
     to which to use up to the individual application, but all
     applications MUST be able to cope with receiving both formats.

   o Conferences using an IP multicast connection address must also have
     a time to live (TTL) value present in addition to the multicast
     address.  The TTL and the address together define the scope with
     which multicast packets sent in this conference will be sent. TTL
     values must be in the range 0-255.

     The TTL for the session is appended to the address using a slash as
     a separator.  An example is:

                           c=IN IP4 224.2.1.1/127

     Hierarchical or layered encoding schemes are data streams where the
     encoding from a single media source is split into a number of
     layers.  The receiver can choose the desired quality (and hence
     bandwidth) by only subscribing to a subset of these layers.  Such
     layered encodings are normally transmitted in multiple multicast
     groups to allow multicast pruning.  This technique keeps unwanted
     traffic from sites only requiring certain levels of the hierarchy.
     For applications requiring multiple multicast groups, we allow the
     following notation to be used for the connection address:

            <base multicast address>/<ttl>/<number of addresses>

     If the number of addresses is not given it is assumed to be one.
     Multicast addresses so assigned are contiguously allocated above
     the base address, so that, for example:

                          c=IN IP4 224.2.1.1/127/3

     would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are
     to be used at a ttl of 127.  This is semantically identical to
     including multiple "c=" lines in a media description:

                           c=IN IP4 224.2.1.1/127
                           c=IN IP4 224.2.1.2/127
                           c=IN IP4 224.2.1.3/127





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


     Multiple addresses or "c=" lines can only be specified on a per-
     media basis, and not for a session-level "c=" field.

     It is illegal for the slash notation described above to be used for
     IP unicast addresses.

   Bandwidth

   b=<modifier>:<bandwidth-value>

   o This specifies the proposed bandwidth to be used by the session or
     media, and is optional.

   o <bandwidth-value> is in kilobits per second

   o <modifier> is a single alphanumeric word giving the meaning of the
     bandwidth figure.

   o Two modifiers are initially defined:

   CT Conference Total: An implicit maximum bandwidth is associated with
     each TTL on the Mbone or within a particular multicast
     administrative scope region (the Mbone bandwidth vs. TTL limits are
     given in the MBone FAQ). If the bandwidth of a session or media in
     a session is different from the bandwidth implicit from the scope,
     a `b=CT:...' line should be supplied for the session giving the
     proposed upper limit to the bandwidth used. The primary purpose of
     this is to give an approximate idea as to whether two or more
     conferences can co-exist simultaneously.

   AS Application-Specific Maximum: The bandwidth is interpreted to be
     application-specific, i.e., will be the application's concept of
     maximum bandwidth.  Normally this will coincide with what is set on
     the application's "maximum bandwidth" control if applicable.

     Note that CT gives a total bandwidth figure for all the media at
     all sites.  AS gives a bandwidth figure for a single media at a
     single site, although there may be many sites sending
     simultaneously.

   o Extension Mechanism: Tool writers can define experimental bandwidth
     modifiers by prefixing their modifier with "X-". For example:

                                 b=X-YZ:128

     SDP parsers should ignore bandwidth fields with unknown modifiers.
     Modifiers should be alpha-numeric and, although no length limit is
     given, they are recommended to be short.



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


   Times, Repeat Times and Time Zones

   t=<start time>  <stop time>

   o "t=" fields specify the start and stop times for a conference
     session.  Multiple "t=" fields may be used if a session is active
     at multiple irregularly spaced times; each additional "t=" field
     specifies an additional period of time for which the session will
     be active.  If the session is active at regular times, an "r="
     field (see below) should be used in addition to and following a
     "t=" field - in which case the "t=" field specifies the start and
     stop times of the repeat sequence.

   o The first and second sub-fields give the start and stop times for
     the conference respectively.  These values are the decimal
     representation of Network Time Protocol (NTP) time values in
     seconds [1].  To convert these values to UNIX time, subtract
     decimal 2208988800.

   o If the stop-time is set to zero, then the session is not bounded,
     though it will not become active until after the start-time.  If
     the start-time is also zero, the session is regarded as permanent.

     User interfaces should strongly discourage the creation of
     unbounded and permanent sessions as they give no information about
     when the session is actually going to terminate, and so make
     scheduling difficult.

     The general assumption may be made, when displaying unbounded
     sessions that have not timed out to the user, that an unbounded
     session will only be active until half an hour from the current
     time or the session start time, whichever is the later.  If
     behaviour other than this is required, an end-time should be given
     and modified as appropriate when new information becomes available
     about when the session should really end.

     Permanent sessions may be shown to the user as never being active
     unless there are associated repeat times which state precisely when
     the session will be active.  In general, permanent sessions should
     not be created for any session expected to have a duration of less
     than 2 months, and should be discouraged for sessions expected to
     have a duration of less than 6 months.

     r=<repeat interval> <active duration> <list of offsets from start-
     time>

   o "r=" fields specify repeat times for a session.  For example, if
     a session is active at 10am on Monday and 11am on Tuesday for one



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


     hour each week for three months, then the <start time> in the
     corresponding "t=" field would be the NTP representation of 10am on
     the first Monday, the <repeat interval> would be 1 week, the
     <active duration> would be 1 hour, and the offsets would be zero
     and 25 hours. The corresponding "t=" field stop time would be the
     NTP representation of the end of the last session three months
     later. By default all fields are in seconds, so the "r=" and "t="
     fields might be:

                           t=3034423619 3042462419
                            r=604800 3600 0 90000

    To make announcements more compact, times may also be given in units
    of days, hours or minutes. The syntax for these is a number
    immediately followed by a single case-sensitive character.
    Fractional units are not allowed - a smaller unit should be used
    instead.  The following unit specification characters are allowed:

                         d - days (86400 seconds)
                        h - minutes (3600 seconds)
                         m - minutes (60 seconds)
         s - seconds (allowed for completeness but not recommended)

   Thus, the above announcement could also have been written:

                               r=7d 1h 0 25h

     Monthly and yearly repeats cannot currently be directly specified
     with a single SDP repeat time - instead separate "t" fields should
     be used to explicitly list the session times.

        z=<adjustment time> <offset> <adjustment time> <offset> ....

   o To schedule a repeated session which spans a change from daylight-
     saving time to standard time or vice-versa, it is necessary to
     specify offsets from the base repeat times. This is required
     because different time zones change time at different times of day,
     different countries change to or from daylight time on different
     dates, and some countries do not have daylight saving time at all.

     Thus in order to schedule a session that is at the same time winter
     and summer, it must be possible to specify unambiguously by whose
     time zone a session is scheduled.  To simplify this task for
     receivers, we allow the sender to specify the NTP time that a time
     zone adjustment happens and the offset from the time when the
     session was first scheduled.  The "z" field allows the sender to
     specify a list of these adjustment times and offsets from the base
     time.



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


     An example might be:

                        z=2882844526 -1h 2898848070 0

     This specifies that at time 2882844526 the time base by which the
     session's repeat times are calculated is shifted back by 1 hour,
     and that at time 2898848070 the session's original time base is
     restored. Adjustments are always relative to the specified start
     time - they are not cumulative.

   o    If a session is likely to last several years, it is  expected
   that
     the session announcement will be modified periodically rather than
     transmit several years worth of adjustments in one announcement.

   Encryption Keys

   k=<method>
   k=<method>:<encryption key>

   o The session description protocol may be used to convey encryption
     keys.  A key field is permitted before the first media entry (in
     which case it applies to all media in the session), or for each
     media entry as required.

   o The format of keys and their usage is outside the scope of this
     document, but see [3].

   o The method indicates the mechanism to be used to obtain a usable
     key by external means, or from the encoded encryption key given.

     The following methods are defined:

      k=clear:<encryption key>
        The encryption key (as described in [3] for  RTP  media  streams
        under  the  AV  profile)  is  included untransformed in this key
        field.