rfc2327.txt

网络MPEG4IP流媒体开发源代码

   The following attributes are suggested.  Since application writers
   may add new attributes as they are required, this list is not
   exhaustive.

   a=cat:<category>
       This attribute gives the dot-separated hierarchical category of
       the session.  This is to enable a receiver to filter unwanted
       sessions by category.  It would probably have been a compulsory
       separate field, except for its experimental nature at this time.
       It is a session-level attribute, and is not dependent on charset.

   a=keywds:<keywords>
       Like the cat attribute, this is to assist identifying wanted
       sessions at the receiver.  This allows a receiver to select
       interesting session based on keywords describing the purpose of
       the session.  It is a session-level attribute. It is a charset
       dependent attribute, meaning that its value should be interpreted
       in the charset specified for the session description if one is
       specified, or by default in ISO 10646/UTF-8.

   a=tool:<name and version of tool>
       This gives the name and version number of the tool used to create
       the session description.  It is a session-level attribute, and is
       not dependent on charset.

   a=ptime:<packet time>
       This gives the length of time in milliseconds represented by the
       media in a packet. This is probably only meaningful for audio
       data.  It should not be necessary to know ptime to decode RTP or
       vat audio, and it is intended as a recommendation for the
       encoding/packetisation of audio.  It is a media attribute, and is
       not dependent on charset.





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


   a=recvonly
       This specifies that the tools should be started in receive-only
       mode where applicable. It can be either a session or media
       attribute, and is not dependent on charset.

   a=sendrecv
       This specifies that the tools should be started in send and
       receive mode.  This is necessary for interactive conferences with
       tools such as wb which defaults to receive only mode. It can be
       either a session or media attribute, and is not dependent on
       charset.

   a=sendonly
       This specifies that the tools should be started in send-only
       mode.  An example may be where a different unicast address is to
       be used for a traffic destination than for a traffic source. In
       such a case, two media descriptions may be use, one sendonly and
       one recvonly. It can be either a session or media attribute, but
       would normally only be used as a media attribute, and is not
       dependent on charset.

   a=orient:<whiteboard orientation>
       Normally this is only used in a whiteboard media specification.
       It specifies the orientation of a the whiteboard on the screen.
       It is a media attribute. Permitted values are `portrait',
       `landscape' and `seascape' (upside down landscape). It is not
       dependent on charset

   a=type:<conference type>
       This specifies the type of the conference.  Suggested values are
       `broadcast', `meeting', `moderated', `test' and `H332'.
       `recvonly' should be the default for `type:broadcast' sessions,
       `type:meeting' should imply `sendrecv' and `type:moderated'
       should indicate the use of a floor control tool and that the
       media tools are started so as to "mute" new sites joining the
       conference.

       Specifying the attribute type:H332 indicates that this loosely
       coupled session is part of a H.332 session as defined in the ITU
       H.332 specification [10].  Media tools should be started
       `recvonly'.

       Specifying the attribute type:test is suggested as a hint that,
       unless explicitly requested otherwise, receivers can safely avoid
       displaying this session description to users.

       The type attribute is a session-level attribute, and is not
       dependent on charset.



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


   a=charset:<character set>
       This specifies the character set to be used to display the
       session name and information data.  By default, the ISO-10646
       character set in UTF-8 encoding is used. If a more compact
       representation is required, other character sets may be used such
       as ISO-8859-1 for Northern European languages.  In particular,
       the ISO 8859-1 is specified with the following SDP attribute:

                             a=charset:ISO-8859-1

       This is a session-level attribute; if this attribute is present,
       it must be before the first media field.  The charset specified
       MUST be one of those registered with IANA, such as ISO-8859-1.
       The character set identifier is a US-ASCII string and MUST be
       compared against the IANA identifiers using a case-insensitive
       comparison.  If the identifier is not recognised or not
       supported, all strings that are affected by it SHOULD be regarded
       as byte strings.

       Note that a character set specified MUST still prohibit the use
       of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets
       requiring the use of these characters MUST define a quoting
       mechanism that prevents these bytes appearing within text fields.

   a=sdplang:<language tag>
       This can be a session level attribute or a media level attribute.
       As a session level attribute, it specifies the language for the
       session description.  As a media level attribute, it specifies
       the language for any media-level SDP information field associated
       with that media.  Multiple sdplang attributes can be provided
       either at session or media level if multiple languages in the
       session description or media use multiple languages, in which
       case the order of the attributes indicates the order of
       importance of the various languages in the session or media from
       most important to least important.

       In general, sending session descriptions consisting of multiple
       languages should be discouraged.  Instead, multiple descriptions
       should be sent describing the session, one in each language.
       However this is not possible with all transport mechanisms, and
       so multiple sdplang attributes are allowed although not
       recommended.

       The sdplang attribute value must be a single RFC 1766 language
       tag in US-ASCII.  It is not dependent on the charset attribute.
       An sdplang attribute SHOULD be specified when a session is of





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


       sufficient scope to cross geographic boundaries where the
       language of recipients cannot be assumed, or where the session is
       in a different language from the locally assumed norm.

   a=lang:<language tag>
       This can be a session level attribute or a media level attribute.
       As a session level attribute, it specifies the default language
       for the session being described.  As a media level attribute, it
       specifies the language for that media, overriding any session-
       level language specified.  Multiple lang attributes can be
       provided either at session or media level if multiple languages
       if the session description or media use multiple languages, in
       which case the order of the attributes indicates the order of
       importance of the various languages in the session or media from
       most important to least important.

       The lang attribute value must be a single RFC 1766 language tag
       in US-ASCII. It is not dependent on the charset attribute.  A
       lang attribute SHOULD be specified when a session is of
       sufficient scope to cross geographic boundaries where the
       language of recipients cannot be assumed, or where the session is
       in a different language from the locally assumed norm.

   a=framerate:<frame rate>
       This gives the maximum video frame rate in frames/sec.  It is
       intended as a recommendation for the encoding of video data.
       Decimal representations of fractional values using the notation
       "<integer>.<fraction>" are allowed.  It is a media attribute, is
       only defined for video media, and is not dependent on charset.

   a=quality:<quality>
       This gives a suggestion for the quality of the encoding as an
       integer value.

       The intention of the quality attribute for video is to specify a
       non-default trade-off between frame-rate and still-image quality.
       For video, the value in the range 0 to 10, with the following
       suggested meaning:

       10 - the best still-image quality the compression scheme can
       give.

       5 - the default behaviour given no quality suggestion.

       0 - the worst still-image quality the codec designer thinks is
           still usable.

       It is a media attribute, and is not dependent on charset.



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


   a=fmtp:<format> <format specific parameters>
       This attribute allows parameters that are specific to a
       particular format to be conveyed in a way that SDP doesn't have
       to understand them.  The format must be one of the formats
       specified for the media.  Format-specific parameters may be any
       set of parameters required to be conveyed by SDP and given
       unchanged to the media tool that will use this format.

       It is a media attribute, and is not dependent on charset.

6.1.  Communicating Conference Control Policy

   There is some debate over the way conference control policy should be
   communicated.  In general, the authors believe that an implicit
   declarative style of specifying conference control is desirable where
   possible.

   A simple declarative style uses a single conference attribute field
   before the first media field, possibly supplemented by properties
   such as `recvonly' for some of the media tools.  This conference
   attribute conveys the conference control policy. An example might be:

                             a=type:moderated

   In some cases, however, it is possible that this may be insufficient
   to communicate the details of an unusual conference control policy.
   If this is the case, then a conference attribute specifying external
   control might be set, and then one or more "media" fields might be
   used to specify the conference control tools and configuration data
   for those tools. An example is an ITU H.332 session:

                c=IN IP4 224.5.6.7
                a=type:H332
                m=audio 49230 RTP/AVP 0
                m=video 49232 RTP/AVP 31
                m=application 12349 udp wb
                m=control 49234 H323 mc
                c=IN IP4 134.134.157.81

   In this example, a general conference attribute (type:H332) is
   specified stating that conference control will be provided by an
   external H.332 tool, and a contact addresses for the H.323 session
   multipoint controller is given.

   In this document, only the declarative style of conference control
   declaration is specified.  Other forms of conference control should
   specify an appropriate type attribute, and should define the
   implications this has for control media.



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


7.  Security Considerations

   SDP is a session description format that describes multimedia
   sessions.  A session description should not be trusted unless it has
   been obtained by an authenticated transport protocol from a trusted
   source.  Many different transport protocols may be used to distribute
   session description, and the nature of the authentication will differ
   from transport to transport.

   One transport that will frequently be used to distribute session
   descriptions is the Session Announcement Protocol (SAP).  SAP
   provides both encryption and authentication mechanisms but due to the
   nature of session announcements it is likely that there are many
   occasions where the originator of a session announcement cannot be
   authenticated because they are previously unknown to the receiver of
   the announcement and because no common public key infrastructure is
   available.

   On receiving a session description over an unauthenticated transport
   mechanism or from an untrusted party, software parsing the session
   should take a few precautions. Session description contain
   information required to start software on the receivers system.
   Software that parses a session description MUST not be able to start
   other software except that which is specifically configured as
   appropriate software to participate in multimedia sessions.  It is
   normally considered INAPPROPRIATE for software parsing a session
   description to start, on a user's system, software that is
   appropriate to participate in multimedia sessions, without the user
   first being informed that such software will be started and giving
   their consent.  Thus a session description arriving by session
   announcement, email, session invitation, or WWW page SHOULD not
   deliver the user into an {it interactive} multimedia session without
   the user being aware that this will happen.  As it is not always
   simple to tell whether a session is interactive or not, applications
   that are unsure should assume sessions are interactive.

   In this specification, there are no attributes which would allow the
   recipient of a session description to be informed to start multimedia
   tools in a mode where they default to transmitting.  Under some
   circumstances it might be appropriate to define such attributes.  If
   this is done an application parsing a session description containing
   such attributes SHOULD either ignore them, or inform the user that
   joining this session will result in the automatic transmission of
   multimedia data.  The default behaviour for an