rfc3108.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,523 行 · 第 1/5 页

   left are more significant than digits to the right.

2.3 Directionality Convention

   This section defined the meaning of the terms 'forward' and
   'backward' as used in this document.  This is specially applicable to
   parameters that have a specific direction associated with them.

   In this document, 'forward' refers to the direction away from the ATM
   node under consideration, while 'backward' refers to the direction
   towards the ATM node.  This convention must be used in all SDP-based
   session descriptions regardless of whether underlying bearer is an
   SVC, a dynamically allocated PVC/SPVC or a dynamically allocated CID.
   This is regardless of which side originates the service connection.
   If ATM SVC or AAL2 Q.2630.1 signaling is used, the directionality
   convention is independent of which side originates the SVC or AAL2
   connection.

   This provides a simple way of identifying the direction in which a
   parameter is applicable, in a manner that is independent of the
   underlying ATM or AAL2 bearer.  This simplicity comes at a price,
   described below.

   The convention used by all ATM/AAL2 signaling specifications (e.g.,
   Q.2931 Section 1.3.3 and Q.2630.1) mandates that forward direction is
   from the end initiating setup/establishment via bearer signaling
   towards the end receiving the setup/establishment request.  The
   backward direction is in the opposite direction.  In some cases, the
   'forward' and 'backward' directions of the ATM signaling convention



Kumar & Mostafa             Standards Track                     [Page 6]

RFC 3108                        ATM SDP                         May 2001


   might be the exact opposite of the SDP convention described above,
   requiring the media gateway to perform the necessary translation.  An
   example case in which this is needed is described below.

   Consider an SDP description sent by a media gateway controller to the
   gateway originating a service-level call.  In the backward SVC call
   set-up model, this gateway terminates (rather than originates) an SVC
   call.  The media gateway refers to the traffic descriptor (and hence
   the PCR) in the direction away from this gateway as the forward
   traffic descriptor and forward PCR.  Clearly, this is at odds with
   ATM SVC signaling which refers to this very PCR as the backward PCR.
   The gateway needs to be able to perform the required swap of
   directions.  In this example, the media gateway terminating the
   service level call (and hence originating the SVC call) does not need
   to perform this swap.

   Certain parameters within attributes are defined exclusively for the
   forward or  backward directions.  Examples for the forward direction
   are the <fsssar> subparameter within the 'aal2sscs3661unassured'
   media attribute line, the <fsssar>, <fsscopsdu> and <fsscopuu>
   subparameters within the 'aal2sscs3661assured' media attribute line,
   the <fsscopsdu> and <fsscopuu> subparameters within the 'aal5sscop'
   media attribute line, and the <fmaxFrame> parameter within the
   'aal2sscs3662' media attribute line.  Examples for the backward
   direction are the <bsssar> subparameter within the
   'aal2sscs3661unassured' media attribute line, the <bsssar>,
   <bsscopsdu> and <bsscopuu> subparameters within the
   'aal2sscs3661assured' media attribute line, the <bsscopsdu> and
   <bsscopuu> subparameters within the 'aal5sscop' media attribute line,
   and the <bmaxFrame> parameter within the 'aal2sscs3662' media
   attribute line.

2.4 Case convention

   As defined in RFC 2327 [1], SDP syntax is case-sensitive.  Since
   these ATM conventions conform strictly with SDP syntax, they are
   case-sensitive.  SDP line types (e.g., "c", "m", "o", "a") and fields
   in the SDP lines should be built according to the case conventions in
   [1] and in this document.  It is suggested, but not required, that
   SDP parsers for ATM applications be case-tolerant where ignoring case
   does not result in ambiguity.  Encoding names, which are defined
   outside the SDP protocol, are case-insensitive.









Kumar & Mostafa             Standards Track                     [Page 7]

RFC 3108                        ATM SDP                         May 2001


2.5 Use of special characters in SDP parameter values

   In general, RFC 2327-conformant string values of SDP parameters [1]
   do not include special characters that are neither alphabets nor
   digits.  An exception is the "/" character used in the value
   "RTP/AVP" of transport sub-field of the 'm' line.

   String values used in SDP descriptions of ATM connections retain this
   convention, while allowing the use of the special character "/" in a
   manner commensurate with [1].  In addition, the special characters
   "$" and "-" are used in the following manner.  A "$" value is a
   wildcard that allows the recipient of the SDP description to select
   any permitted value of the parameter.  A "-" value indicates that it
   is not necessary to specify the value of the parameter in the SDP
   description because this parameter is irrelevant for this
   application, or because its value can be known from another source
   such as provisioning, defaults, another protocol, another SDP
   descriptor or another part of the same SDP descriptor.  If the use of
   these special characters is construed as a violation of RFC 2327 [1]
   syntax, then reserved string values can be used.  The string "CHOOSE"
   can be used in lieu of "$".  The string "OMIT" can be used in lieu of
   "-" for an omitted parameter.

3. Capabilities Provided by SDP conventions

   To support the applications listed in section 1, the SDP conventions
   in this document provide the following session control capabilities:

      *  Identification of the underlying bearer network type as ATM.

      *  Identification by an ATM network element of its own address, in
         one of several possible formats.  A connection peer can
         initiate SVC set-up to this address.  A call agent or
         connection peer can select an pre-established bearer path to
         this address.

      *  Identification of the ATM bearer connection that is to be bound
         to the service-level connection.  Depending on the application,
         this is either a VCC or a subchannel (identified by a CID)
         within a VCC.

      * Identification of media type: audio, video, data.

      *  In AAL1/AAL5  applications, declaration of a set of payload
         types that can be bound to the ATM bearer connection.  The
         encoding names and payload types defined for use in the RTP
         context [31] are re-used for AAL1 and AAL5, if applicable.




Kumar & Mostafa             Standards Track                     [Page 8]

RFC 3108                        ATM SDP                         May 2001


      *  In AAL2 applications, declaration of a set of profiles that can
         be bound to the ATM bearer connection.  A mechanism for
         dynamically defining custom profiles within the SDP session
         description is included.  This allows the use of custom
         profiles for connections that span multi-network interfaces.

      *  A means of correlating service-level connections with
         underlying ATM bearer connections.  The backbone network
         connection identifier or bnc-id specified in ITU Q.1901 [36]
         standardization work is used for this purpose.  In order to
         provide a common SDP base for applications based on Q.1901 and
         SIP/SIP+, the neutral term 'eecid' is used in lieu of 'bnc-id'
         in the SDP session descriptor.

      *  A means of  mapping codec types and packetization periods into
         service types (voice, voiceband data and facsimile).  This is
         useful in determining the encoding to use when the connection
         is upspeeded in response to modem or facsimile tones.

      *  A means of describing the adaptation type, QoS class, ATM
         transfer capability/service category, broadband bearer class,
         traffic parameters, CPS parameters and SSCS parameters related
         the underlying bearer connection.

      *  Means for enabling or describing special functions such as
         leaf- initiated-join, anycast and SVC caching.

      *  For H.323 Annex C applications, a means of specifying the IP
         address and port number on which the node will receive RTCP
         messages.

      *  A means of chaining consecutive SDP descriptors so that they
         refer to different layers of the same connection.

4. Format of the ATM Session Description

   The sequence of lines in the session descriptions in this document
   conforms to RFC 2327 [1].  In general, a session description consists
   of a  session-level part followed by zero or more media-level parts.
   ATM session descriptions consist of a session-level part followed by
   one or two media-level parts.  The only two media applicable are the
   ATM bearer medium and RTCP control (where applicable).

   The session level part consists of the following lines:

   v=  (protocol version, zero or one line)
   o=  (origin, zero or one line)
   s=  (session name, zero or one line)



Kumar & Mostafa             Standards Track                     [Page 9]

RFC 3108                        ATM SDP                         May 2001


   c=  (connection information, one line)
   b=  (bandwidth, zero or more lines)
   t=  (timestamp, zero or one line)
   k=  (encryption key, zero or one line)

   In ATM session descriptions, there are no media attribute lines in
   the session level part.  These are present in the media-level parts.

   The media-level part for the ATM bearer consists of the following
   lines:

   m=  (media information and transport address, one line)
   b=  (bandwidth, zero or more lines)
   k=  (encryption key, zero or more lines)
   a=  (media attribute, zero or more lines)

   The media-level part for RTCP control consists of the following
   lines:

   m=  (media information and transport address, one line)
   c=  (connection information for control only, one line)

   In general, the 'v', 'o', 's', and 't' lines are mandatory.  However,
   in the Megaco [26] context, these lines have been made optional.  The
   'o', 's', and 't' lines are omitted in most MGCP [25] applications.

   Note that SDP session descriptors for ATM can contain bandwidth (b=)
   and encryption key (k=) lines.  Like all other lines, these lines
   should strictly conform to the SDP standard [1].

   The bandwidth (b=) line is not necessarily redundant in the ATM
   context since, in some applications, it can be used to convey
   application-level information which does not map directly into the
   atmTrfcDesc media attribute line.  For instance, the 'b' line can be
   used in SDP descriptors in RTSP commands to describe content
   bandwidth.

   The encryption key line (k=) can be used to indicate an encryption
   key for the bearer, and a method to obtain the key.  At present, the
   encryption of ATM and AAL2 bearers has not been conventionalized,
   unlike the encryption of RTP payloads.  Nor has the authentication or
   encryption of ATM or AAL2 bearer signaling.  In the ATM and AAL2
   contexts, the term 'bearer' can include 'bearer signaling' as well as
   'bearer payloads'.

   The order of lines in an ATM session description is exactly in the
   RFC 2327-conformant order depicted above.  However, there is no order
   of the media attribute ('a') lines with respect to other 'a' lines.



Kumar & Mostafa             Standards Track                    [Page 10]

RFC 3108                        ATM SDP                         May 2001


   The SDP protocol version for session descriptions using these
   conventions is 0.  In conformance with standard SDP, it  is strongly
   recommended that the 'v' line be included at the beginning of each
   SDP session description.  In some contexts such as Megaco, the
   'v' line is optional and may be omitted unless several session
   descriptions are provided in sequence, in which case the 'v' line
   serves as a delimiter.  Depending on the application, sequences of
   session descriptions might refer to:

   -  Different connections or sessions.
   -  Alternate ways of realizing the same connection or session.
   -  Different layers of the same session (section 5.6.4.1).

   The 'o', 's' and 't' lines are included for strict conformance with
   RFC 2327.  It is possible that these lines might not carry useful
   information in some ATM-based applications.  Therefore, some
   applications might omit these lines, although it is recommended that
   they not do so.  For maximum interoperability, it is preferable that
   SDP parsers not reject session descriptions that do not contain these
   lines.

5. Structure of the Session Description Lines

5.1 The Origin Line

   The origin line for an ATM-based session is structured as follows:

         o=<username> <sessionID> <version> <networkType>
           <addressType> <address>

   The <username> is set to "-".

   The <sessionID> can be  set to one of the following:

      *  an NTP timestamp referring to the moment when the SDP session
         descriptor was created.
      *  a Call ID, connection ID or context ID that uniquely identifies
         the session within the scope of the ATM node.  Since calls can
         comprise multiple connections (sessions), call IDs are
         generally not suitable for this purpose.

   NTP time stamps can be represented as decimal or hex integers.  The
   part of the NTP timestamp that refers to an integer number of seconds
   is sufficient.  This is a 32-bit field