[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
                                                              T. Taylor
   Internet Draft                                       Nortel Networks
   Document: draft-taylor-mmusic-sdp-tdm-00.txt
   Expires: October 2001                                     April 2001


     Conventions for the use of the Session Description Protocol (SDP)
                      for Digital Circuit Connections


Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   This document describes conventions for using the Session
   Description Protocol (SDP) described in RFC2327 [1] for controlling
   digital circuits.  These conventions describe
    - circuit addressing conventions for use on the SDP "c=" line
    - content of the "m=" line(s) for digital circuits
    - attributes to convey the parameters contained within the Bearer
      Capability, Low Layer Compatibility, and High Layer Compatibility
      Information Elements of ITU-T Recommendation Q.931.

   These conventions have been defined for use in media gateway
   control, particularly in support of NAS operation, but may also be
   used by IP-based call signalling schemes (SIP, BICC) to control
   media exchange over digital circuits.









   Taylor       Standards Track - Expires October 2001               1

                   SDP Conventions For TDM Circuits         April 2001

1. Introduction

   The scope of SDP control is being extended to a variety of bearer
   types, particularly to serve the needs of media gateway control
   protocols such as Megaco/H.248 [2] and MGCP [3], but also those of
   the bearer-related portions of call signalling over the internet as
   represented by SIP [4] and BICC [5].  Control of ATM bearers was
   documented in [6].  This document uses [6] as a model for a rather
   simpler case, the control of n x 64 kbit/s digital circuits.  These
   circuits may carry voice, video or multiplexed multimedia, voiceband
   data (fax relay, modem relay), or baseband data (PPP, frame relay
   etc.).

   The conventions in this document may be applied in three possible
   situations:

   (1) For media gateway control at the boundary between an ISDN access
   network and another bearer network.  In this case, SDP must capture
   bearer characteristics conveyed in the Q.931 call signalling
   protocol [7].

   (2) For media gateway control at the boundary between an ISDN core
   network and another bearer network.  In this case, SDP must capture
   bearer characteristics conveyed in the SS7 ISUP call signalling
   protocol [8].  Since a mapping has been defined between ISUP and
   Q.931 [9], the SDP conventions required will be in large part the
   same as in the first case.

   (3) For control of digital circuits across a network using SIP or
   BICC [10].  This is a potential future application, included here
   for logical completeness, since neither SIP nor BICC is currently
   being designed with circuit networks in mind.

1.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 [xxxx].

   "TDM" stands for "Time Division Multiplex" digital transmission.

   The term "TDM bearer" refers to a set of one or more 64 kbit/s TDM
   channels which collectively support the media session.

   The term "digital circuit" is used interchangeably with the term
   "TDM channel".

   Frequently throughout the document, "bearer" is used to mean a TDM
   bearer, and "circuit" is used to mean a 64 kbit/s TDM channel.  This
   should not cause confusion, since the document deals with no other
   bearer or circuit type.




   Taylor       Standards Track - Expires October 2001               2

                   SDP Conventions For TDM Circuits         April 2001

1.2 Scope

   This document provides the means to describe media flows in TDM
   bearers.  It provides conventions for:
    - addressing of TDM bearers on the SDP "c=" line
    - a description of the content carried by the TDM bearer on the SDP
      "m=" line
    - use of the SDP "b=" line to convey the TDM bearer information
      transfer rate
    - attributes to convey the content of the Q.931 Low Layer and High
      Layer Compatibility Information Elements.

   The present issue of this document excludes the following:

    1. Mapping of Layer 2 and Layer 3 protocol parameters (e.g. for
      X.25, frame relay) into SDP attributes.  It is assumed that such
      mappings will be defined in separate protocol-specific documents.

    2. Bearer capability negotiation.  Q.931 and ISUP support the
      inclusion of multiple Bearer Capability Information Elements for
      negotiation.  This document supports transfer of only one set of
      bearer capability information per session description.

   This document conforms to the syntactic conventions of standard SDP
   as defined in RFC2327 [1], except that it relies on the ability to
   place the character "/" in the proto element of the "m=" line,
   following the precedent of "RTP/AVP".

1.3 Why Are Digital-Circuit-Specific Conventions Needed?

   SDP was originally designed for the description of media sessions
   carried over IP packets, typically using RTP [11] encapsulation and
   UDP transport.  In contrast, description of media transport over TDM
   bearers must begin at a much lower level, with the basic
   organization of the bits across the 64 kbit/s channel(s) making up
   the TDM bearer.  Moreover, the higher-layer organization of the
   content is typically negotiated "in-band", through protocols such as
   V.8bis or V.140.  This forces a re-interpretation of the contents of
   the SDP "m=" line in particular, and the creation of a number of
   additional attributes to describe the lower layers of transport.

   Addressing of TDM bearers is also different, and for media gateway
   control is actually irrelevant, since the information is conveyed by
   other means (terminationIDs in Megaco/H.248, and endpoint
   identifiers in MGCP).  This affects the SDP "c=" line and makes
   redundant the port identification on the "m=" line.

   The other lines of the SDP session description can generally be used
   without modification from their use as described in [1], with the
   following notes:

    1. If the "o=" line is present, it will almost surely contain an IP
      network address, not a TDM bearer identifier.


   Taylor       Standards Track - Expires October 2001               3

                   SDP Conventions For TDM Circuits         April 2001

    2. The "b=" line MUST be present, and MUST be used to indicate the
      total bit rate of the TDM bearer.  The modifier used is "AS".
      The bandwidth MUST always be a multiple of 64 (kbit/s).  The
      effective user rate, if less than this, is indicated by an
      attribute within the media description.

      The total bit rate may be taken directly from call signalling
      (e.g. the Q.931 "Information Transfer Rate" when the bearer is
      operating in circuit mode), or may be calculated by multiplying
      the number of circuits making up the bearer by 64.  The latter
      method is necessary when multirate operation is used or if the
      bearer was set up through multiple call signalling sessions
      (multilink or BONDING).

    3. The "k=" line MAY be present.  There are probably consistency
      conditions on the media format value in this case.


2. "c=" Line For TDM bearers

   The connection field ("c=" line) is structured as follows [1]:

      connection-field =    "c=" nettype space addrtype space
                            connection-address CRLF

   This document reserves a nettype value of "TDM" for Time Division
   Multiplexed (TDM) bearers.

   The present issue of this document proposes two naming schemes for
   TDM bearers: the NUL scheme (addrtype is "NUL") and the group-and-
   member scheme (addrtype is "GRP").  Future issues of this document
   may specify other schemes.

   The NUL scheme is suitable for use with media gateway control, since
   other means are available (as mentioned above) for designating the
   channels making up the TDM bearer.  (For multi-channel bearers,
   Megaco/H.248 provides the information in the MUX Descriptor,
   assuming that each individual channel is provisioned as a
   termination on the media gateway.)  The NUL connection-address MUST
   be present, but may be any string satisfying the syntactical
   requirements of RFC 2327[1], for example, "xxxx".  The receiver MUST
   ignore the connection-address when addrtype is NUL.

   The GRP scheme designates a logical or physical grouping of circuits
   within which individual 64 kbit/s channels may be identified by
   integer values.  The identity of the channel(s) making up the bearer
   MUST be specified in an a=chnls: attribute (see below) within the
   media description.  The connection-address MUST be set to a string
   identifying the digital facility and satisfying the syntactical
   requirements of RFC 2327[1].  In quick summary, such a string will
   consist of one or more components separated by dots. Each component
   begins with an alpha, ends with an alpha or digit, and may have
   additional alphas, digits, or dashes in the interior.  The GRP
   scheme can be used to describe a multi-channel connection set up by

   Taylor       Standards Track - Expires October 2001               4

                   SDP Conventions For TDM Circuits         April 2001

   a multi-link procedure, but only in the special case where all of
   the channels belong to the same logical or physical group.


3. "m=" Line For TDM Circuits

   [1] defines the syntax of the media field ("m=" line) as follows:

      media-field =         "m=" media space port ["/" integer]
                            space proto 1*(space fmt) CRLF

3.1 Specification of Medium and Format

   In accordance with [1], the media token must be a MIME type and the
   fmt token must be a MIME subtype.  Based on RFC 2046 [13] and a
   review of the various fields of the Bearer Capability Information
   Element, the two possible settings for the media token appear to be
   "audio" and "application".  The available range of subtypes is more
   problematic.

   We begin the discussion with "audio".  RFC 2046 defines one audio
   subtype: "basic".  This denotes G.711 mu-law PCM.  This would be
   been quite acceptable to match the Q.931 User Information Layer 1
   protocol codepoint "Recommendation G.711 mu-law", but leaves
   "Recommendation G.711 A-law" out in the cold.  Very fortunately, the
   AVT Working Group has created a new document [14] to register RTP
   payload types as MIME subtypes.  Two of these types are PCMA and
   PCMU, corresponding to A-law and Mu-law companding respectively.
   The registrations will have to be updated to note the possibility of
   transport over TDM.  G.721 compression, an additional Q.931
   codepoint, is not covered by [14], so it will have to be registered
   separately.

   There is really no alternative to defining new MIME subtypes to
   cover the Q.931 codepoints "Recommendations H.221 and H.242" and
   "Recommendations H.223 and H.245".  These refer to the use of H.320
   and H.324I multimedia conferencing, respectively.  Description of
   "h320" and "h324i" MIME subtypes of "application" will be provided
   in a separate document.

   "application/octet-stream" is probably adequate to cover the other
   possibilities provided for in Q.931, so no additional work is
   required.

   In summary, the possible medium/format combinations for TDM
   transport are:
    - audio/pcma
    - audio/pcmu
    - audio/g721
    - application/h320
    - application/h324i
    - application/octet-stream



   Taylor       Standards Track - Expires October 2001               5

                   SDP Conventions For TDM Circuits         April 2001

   If the nature of the medium (typically "audio") is known, it should
   be specified accordingly.  Otherwise, medium and format are derived
   from the Transmission Mode, Information Transfer Capability, and
   User Information Layer 1 Protocol of the bearer, as follows:

      1. Set media = "application" if Transmission Mode is not
         "circuit", or if Information Transfer Capability is
         "unrestricted digital information" or "restricted digital
         information".

      2. If Transmission Mode is "circuit" and Information Transfer
         Capability is "Speech" or "3.1 kHz audio", set media =
         "audio".

      3. If Transmission Mode is "circuit" and Information Transfer
         Capability is "Unrestricted digital information with tones and
         announcements", set media = "audio" while the call is being
         set up, then set it to "application".

      4. If Transmission Mode is "circuit" and Information Transfer
         Capability is "Video", set media = "application".
         "Application" is more appropriate than "video" as a MIME type
         because the bit stream carries more than just video and an
         application tool is required to interpret it.

3.2 Specification of Port

   Port number is inapplicable to TDM bearers.  To satisfy SDP syntax,
   the sender SHOULD set port = 0 in all cases.  The receiver MUST
   ignore port.

3.3 Specification of Protocol

   Q.931 and Q.939 distinguish between protocol information which the
   network sees and may modify (in the Bearer Capability Information
   Element) and protocol information which is available only between
   endpoints (in the Low Layer Compatibility Information Element).
   Depending on endpoint intentions, any of the protocol information at
   layers 1, 2, or 3 may appear in either place.  The only information
   which is guaranteed to be visible to the network is the transfer
   mode (circuit, packet, or frame mode).  It is therefore proposed
   that the transport profile on the "m=" line indicate the transfer
   mode, but that additional protocol information be indicated on
   attribute lines within the media description.  This document
   accordingly defines three transport profiles:

   . "TDM" denotes circuit mode (octet-oriented) transport over a TDM
     bearer

   . "PKT/TDM" denotes packet mode transport over a TDM bearer

   . "FRM/TDM" denotes frame mode transport over a TDM bearer.



   Taylor       Standards Track - Expires October 2001               6

                   SDP Conventions For TDM Circuits         April 2001

4. Attributes For TDM Bearers

4.1 Audio Transfer Capability

   a= spchonly

   When present, attribute "spchonly" indicates that an audio
   connection is suitable only for speech (Q.931 Information Transfer
   Capability = speech) and not for modem or FAX signals.


4.2 Bandwidth Restriction

   a=56kmax

   When present, this attribute indicates that the transfer rate for
   user data is limited to 56 kbit/s per channel.  ITU-T Recommendation
   I.464 gives further details of operation under these circumstances.


4.3 Channel List

   a=chnls:<list>

   This attribute identifies one or more 64 kbit/s channels making up a
   circuit connection.  It is required when addrtype on the "c=" line
   is "GRP", and otherwise MUST be ignored.  The channels are given as
   a comma-separated series of integers.  The ordering is significant
   when multiple channels are listed, and indicates the order in which
   frames or packets are built up across those channels.

   The information for this attribute may be derived from the Q.931
   Channel Information IE.  The bandwidth shown on the "b=" line MUST
   equal 64 x the number of channels listed in the chnls attribute.


4.4 Protocol Profile

   Q.931 provides two places for user protocols to be specified: in
   Bearer Capability, where they are subject to inspection and
   modification by network equipment such as gateways or proxies, and
   in Low Layer Compatibility, where they are placed for the
   information of the remote peer.  Rules for the choice of placement
   are given in Recommendation Q.939.

   The present document assumes that if a protocol is exposed to the
   network, all parameters describing that protocol are also exposed.
   Thus it is unnecessary to provide segregated versions of the various
   protocol parameters, only of the protocol stacks themselves.

   a=netprof:<profile>
   a=e2eprof:<profile>



   Taylor       Standards Track - Expires October 2001               7

                   SDP Conventions For TDM Circuits         April 2001

   Attribute "netprof" lists the protocols which the sender is prepared
   to expose to network inspection.  Attribute "e2eprof" lists those
   which are intended for remote peer use only.  Attribute "netprof"
   SHOULD be present if media = "application" on the "m=" line, even if
   it is empty.

   <profile> consists of up to three protocol designators, one per
   layer, separated by "/".  The protocols are ordered from highest to
   lowest.  Missing layers are omitted, along with their separators.
   For any given layer:
    - no protocol is specified in either "netprof" or "e2eprof", or
    - some protocol is specified in "netprof", or
    - some protocol is specified in "e2eprof".

   Protocol parameters for protocols listed in "e2eprof" SHOULD be
   transmitted by network entities without modification.

   Examples:

   a=netprof:Q922A
        frame relay

   a=e2eprof:X25P/X25L/V110
        X.25 packet layer over X.25 link layer over V.110 rate adaption
        (circuit mode operation with user rate less than 64 kbit/s).

   a=e2eprof:PPP
        layers 1 and 2 are specified in "netprof" or not needed (e.g.
        because framing is auto-sensed).

 4.4.1 Layer 1 Protocols

   The User Information Layer 1 protocol codepoints provided in Q.931
   include a number of values which map to the media and format fields
   as discussed above.  The three remaining ITU-T codepoints are shown
   in the table below, along with the symbols used to designate them
   within the protocol profile.  Other layer 1 protocols may be added
   in future issues of this document if required.

   Symbol  Description

   V110    ITU-T standardized rate adaption V.110, I.460 and
            X.30.
            Requires m=application 0 TDM octet-stream

   V120    ITU-T standardized rate adaption V.120.
            Requires m=application 0 TDM octet-stream

   X31     ITU-T standardized rate adaption X.31 HDLC flag
            stuffing.
            Requires m=application 0 PKT/TDM octet-stream



   Taylor       Standards Track - Expires October 2001               8

                   SDP Conventions For TDM Circuits         April 2001


 4.4.2 Layer 2 Protocols

   The Layer 2 codepoints defined in Q.931 and Q.933 are shown in the
   table below.  The Layer 2 protocol MUST be specified in attribute
   "netprof" if proto on the "m=" line is either "PKT/TDM" or
   "FRM/TDM".

   Symbol    Description

   Q921      Recommendation Q.921/I.441 (typically used for D-
             channel data).

   X25L      Recommendation X.25, link layer.

   ISO8802   LAN logical link control (ISO/IEC 8802-2)
              Can only appear in netprof if proto = "TDM" on
              the "m=" line.

   Q922      Recommendation Q.922 (frame switching). Layer 1
             must be unspecified.
              Requires m=application 0 FRM/TDM octet-stream

   Q922A     Core aspects of frame mode (Annex A/Q.922) (frame
              relay).  Layer 1 must be unspecified.
              Requires m=application 0 FRM/TDM octet-stream

   ISO1745   Basic mode (ISO/IEC 1745)

   X25ML     Recommendation X.25 Multilink.

   T71       Extended LAPB; for half duplex operation
              (Recommendation T.71)

   HDLC-ARM  HDLC ARM (ISO/IEC 4335).

   HDLC-NRM  HDLC NRM (ISO/IEC 4335).

   HDLC-ABM  HDLC ABM (ISO/IEC 4335).

   X75SLP    Recommendation X.75 single Link Procedure (SLP).

   ISO7776   ISO/IEC 7776 DTE-DCE operation.











   Taylor       Standards Track - Expires October 2001               9

                   SDP Conventions For TDM Circuits         April 2001

 4.4.3 Layer 3 Protocols

   The Layer 3 codepoints defined in Q.931 are shown in the table
   below.

   Symbol  Description

   Q931    Recommendation Q.931 (i.e. call signalling).

   X25P    Recommendation X.25, packet layer.

   IP      Internet Protocol (RFC 791)
            Can only appear in netprof if proto = "TDM" on the
            "m=" line.

   PPP     Point to Point Protocol (RFC 1598, RFC 1618, or
            RFC 1973, depending on lower layer).
            Can only appear in netprof if proto = "TDM" on the
            "m=" line.

   X25PLP  ISO/IEC 8208 [41] (X.25 packet level protocol for
            data terminal equipment)

   ISO8878 ITU-T Rec. X.223 and ISO/IEC 8878 (use of ISO/IEC
            8208 and Recommendation X.25 to provide the OSI-
            CONS)

   ISO8473 ISO/IEC 8473 (OSI connectionless mode protocol)

   T70MIN  Recommendation T.70 minimum network layer


4.5 User Rate

   a=userbw:<bits>

   <bits> is the user data rate in bits per second per 64 kbit/s
   channel within the TDM bearer.  This attribute is useful in cases
   where the user rate information is not passed end-to-end through in-
   band signalling and negotiation.  Further research is required on
   whether there is a requirement to express a different user rate for
   each channel of a multi-channel bearer.


4.6 In-Band Negotiation

   a=ibneg

   This attribute if present indicates that in-band negotiation is
   supported by the V.110, X.30, I.460 or modem layer 1 protocol.




   Taylor       Standards Track - Expires October 2001              10

                   SDP Conventions For TDM Circuits         April 2001

4.7 V.110/X.30/I.460 Protocol Parameters

   a=v110parms:<parms>

   <parms> consists of a comma-separated list of parameters.  The only
   required parameter is the intermediate rate for rate adaptation,
   which has the form:
        "intrat="<kbits>
   <kbits> is the intermediate rate in kbit/s, and has the possible
   values 8, 16, 32, or "NONE".

   The remaining parameters are keyword values, as follows:

        "sendNIC" indicates by its presence that network-independent
        clocking will be sent with the outgoing media stream.

        "sendFC" indicates that flow control will be sent with the
        outgoing media stream.

        "recvNIC" indicates that network-independent clocking may be
        present in the incoming media stream.

        "recvFC" indicates that flow control may be present in the
        incoming media stream.

   Note that the directionality convention used here is entity-
   relative, whereas the directionality convention in Q.931 is call-
   relative.  The two conventions coincide at the end of the TDM bearer
   closer to the calling party, but are opposed at the end closer to
   the called party.  The convention in this document is the more
   suitable for media gateway control, since the media gateway is
   unaware of call direction.


 4.8 V.120 Protocol Parameters

   a=v120parms:<parms>

   <parms> consists of a comma-separated list of parameters, as
   follows.  These parameters are required unless otherwise indicated.

        "mode="<mode>
        Indicates whether rate adaptation mode is bit-transparent
        (<mode> = "transp") or protocol-sensitive (<mode> = "protdep").

        "llineg="<negotiation>
        Indicates whether and how Logical Link Identifier (LLI)
        negotiation is done.  <negotiation> has the possible values
        "NONE" (default) if LLI = 256 is the only value supported, "OB"
        if negotiation is possible over a temporary signalling channel,
        or "IB" if negotiation is done on LLI 0.




   Taylor       Standards Track - Expires October 2001              11

                   SDP Conventions For TDM Circuits         April 2001

        "hdr"
        Optional keyword parameter.  If present, indicates that the
        rate adaption header is included.

        "multifrm"
        Optional keyword parameter.  If present, indicates that
        multiframe establishment is supported.

        "assgn"
        Optional keyword parameter.  If present, indicates that the
        message originator is "Assignor only".  If absent, message
        originator is "Default assignee".


4.9 Asynchronous Parameters

   a=asynch:stop=<sbits>,data=<dbits>,parity=<par>,duplex=<dlx>

   If present, indicates asynchronous data transport.

4.10 Modem

   a=modem:<modem>

   If present, indicates data transport via modem.  <modem> indicates
   the type of modem used.  It may have values "V34" or "V90".  Other
   values may be added in subsequent issues of this document if
   required.  Note that this attribute is unnecessary in Megaco/H.248
   because the Modem Descriptor provides the same information.
   Requires "m=audio 0 TDM <fmt>" where <fmt> designates G.711 A- or
   mu-law.

Security Considerations

   This document deals with the signalling of information to direct the
   transfer of user information across TDM bearers.  Threats to
   security may be identified both at the signalling level and at the
   media transport level.  See RFC 2327 [1] for a discussion of
   security issues at the signalling level.

   Media transport is in general subject to threats to integrity and
   confidentiality.  (Injection of spurious media into an ongoing
   session is classed here as a breach of integrity.  Passing of
   spurious media outside of an established session is considered to be
   a signalling problem.)  These threats are sharply reduced for TDM as
   opposed to IP bearer transport.  However, the user is not normally
   aware of what sort of transport is in use on an end-to-end basis,
   and the media flow may well pass from one network to another.  Where
   integrity or confidentiality are a concern, end-to-end encryption of
   the media stream should be considered.





   Taylor       Standards Track - Expires October 2001              12

                   SDP Conventions For TDM Circuits         April 2001


References
     1.  M. Handley, V. Jacobson, "SDP: Session Description Protocol",
          IETF RFC 2327, Standards Track, April 1998.

     2.  B. Rosen, J. Segers et al, "Megaco Protocol Version 1.0",
          IETF RFC 3015, Standards Track, November 2000.

     3.  C. Huitema et al, "Media Gateway Control Protocol (MGCP)
          Version 1.0", IETF RFC 2705, Informational, October 1999.

     4.  M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP:
          Session Initiation Protocol", IETF RFC 2543, Standards Track,
          March 1999.

     5.  ITU-T Recommendation Q.1902, "Bearer Independent Call Control
          Protocol (CS2)", work in progress.

     6.  R. Kumar, M. Mostafa, "Conventions for the use of the Session
          Description Protocol (SDP) for ATM Bearer Connections", IETF
          draft-ietf-mmusic-sdp-atm-05.txt, February 2001.

     7.  ITU-T Recommendation Q.931, "Digital subscriber Signalling
          System No. 1 รป Network layer", May 1998.

     8.  ITU-T Recommendation Q.763, "Signalling system No. 7 - ISDN
          user part formats and codes", September 1997.

     9.  ITU-T Recommendation Q.699, "Interworking between ISDN access
          and non-ISDN access over ISDN User Part of signalling system
          No. 7", September 1997.

     10. ITU-T Recommendation Q.1901, "Bearer independent call control
          protocol", June 2000.

     11. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, " RTP:
          A Transport Protocol for Real-Time Applications", IETF RFC
          1889, Standards Track, January 1996.

     12. ITU-T Recommendation I.230, "Definition of bearer service
          categories", November 1988.

     13. N. Freed, N. Borenstein, "Multipurpose Internet Mail
          Extensions (MIME) Part Two: Media Types", IETF RFC 2046,
          November 1996.

     14. S. Casner, P.Hoschka, "MIME Type Registration of RTP Payload
          Type Formats", IETF work in progress.







   Taylor       Standards Track - Expires October 2001              13

                   SDP Conventions For TDM Circuits         April 2001

Author's Address

   Tom Taylor
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, Ontario                  Phone:  +1 613 736 0961
   Canada K1Y 4H7                   Email:  taylor@nortelnetworks.com
















































   Taylor       Standards Track - Expires October 2001              14