T. Taylor Internet Draft Nortel Networks Document: draft-taylor-mmusic-sdp-tdm-01.txt Expires: October 2002 April 2002 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) 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 2002 1 SDP Conventions For TDM Circuits April 2002 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 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 TDM circuits across a network using SIP or BICC [5]. This is a potential future application, included here for logical completeness, since neither SIP nor BICC is currently being designed with TDM 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 [10]. "TDM" stands for "Time Division Multiplex" digital transmission. In this document, the term "TDM circuit" is used to mean a 64 kbit/s TDM channel. 1.2 Scope This document provides the means to describe media flows in TDM circuits. Although it will be of use in the general categories of applications described in the introduction, it is specifically aimed at satisfying the requirements of the Megaco/H.248 media gateway control protocol including the voice, voice-band data (and NAS operation in particular), and multimedia conferencing (H.320 and H.324i) applications. Taylor Standards Track - Expires October 2002 2 SDP Conventions For TDM Circuits April 2002 This document provides conventions for: - use of the SDP "b=" line to convey the TDM circuit information transfer rate - addressing of TDM circuits on the SDP "c=" line - the transport types TDM, PKT/TDM, and FRM/TDM - a description of the content carried by the TDM circuit on the SDP "m=" line - 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 if they are required. 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. 3. Support of multi-rate (N x 64 kbit/s) service. This document conforms to the syntactic conventions of SDP as defined in [1]. 1.3 Why Are TDM-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 circuits must begin at a much lower level, with the basic organization of the bits across the 64 kbit/s channel. 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 circuits 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 "b=" line is present, it MUST indicate a bandwidth of 64 (kbit/s). The modifier used is "AS". The effective user rate, if less than this, is indicated by an attribute within the media Taylor Standards Track - Expires October 2002 3 SDP Conventions For TDM Circuits April 2002 description. 2. The "k=" line MAY be present. There are probably consistency conditions on the media format value in this case. 1.4 Changes From The Previous Version The main change from the previous version has been to limit the scope of the present document by placing greater reliance on the Megaco/H.248 multiplex concept. This has meant the removal of wideband or aggregated N x 64 kbit/s service from the scope of the document, and the reduction of H.320 and H.324 sessions to application/octet-stream media flows from the point of view of TDM transport. (Separate documents define SDP conventions for the H221, H223, and H226 transport types.) The syntax in this version conforms to [1] rather than RFC 2327. MIME subtype registrations for audio/PCMU, audio/PCMA, audio/G721, and application/octet-stream over TDM have been added in the appendices. 2. "c=" Line For TDM circuits 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 TDM circuits. The present issue of this document proposes two naming schemes for TDM circuits: 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 TDM circuit. The NUL connection-address MUST be present, but may be any string satisfying the syntactical requirements of [1], for example, "x". 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 GRP connection-address consists of two parts. The first part identifies the logical or physical group, while the second identifies the individual circuit within the group. grp-connection-address = group-part "/" member-part group-part = non-ws-string ; as defined in [1] member-part = non-ws-string ; as defined in [1] Taylor Standards Track - Expires October 2002 4 SDP Conventions For TDM Circuits April 2002 Over all, the syntax conforms to the extension-addr form of unicast- address as defined in [1]. There is one additional restriction: member-part MUST NOT contain the "/" character. 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 reference a MIME subtype. Since existing MIME type registration is for packet transport, it will be necessary to add or extend registrations to include TDM transport. Where possible, the extension route is preferable. 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 subtypes are audio/PCMA and audio/PCMU, corresponding to A-law and Mu-law companding respectively. The Q.931 codepoint "Recommendation G.721 [11] 32 kbit/s ADPCM and Recommendation I.460" is actually for G.726, which is covered in [14] by the audio/G726-16, audio/G726-24, audio/G726-32, and audio/G726-40 MIME subtypes. The Q.931 codepoints "Recommendations H.221 and H.242" and "Recommendations H.223 and H.245" refer to the use of H.320 and H.324I multimedia conferencing, respectively. In the Megaco/H.248 model, the TDM circuits carrying these sessions feed into terminations representing the respective multiplexes. It is the responsibility of the multiplexes to manage the audio, video, data, and control flows. The SDP for this purpose is documented separately, on the premise that each multiplex represents another transport type. From the TDM point of view, the flows are undifferentiated, so the MIME subtype application/octet-stream is appropriate. "application/octet-stream" is probably adequate to cover the other possibilities provided for in Q.931. Taylor Standards Track - Expires October 2002 5 SDP Conventions For TDM Circuits April 2002 In summary, the possible medium/format combinations for TDM transport are: - audio/pcma - audio/pcmu - audio/g726-16, 24, 32, 40 - application/octet-stream The MIME registrations for all of these must be updated to note the possibility of transport over TDM. This is done in the appendices to the present document. 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 circuits, but must be specified to satisfy SDP syntax. Where the present specification is being used in circumstances in which the offer-answer model [15] applies, setting port = 0 indicates rejection of a media stream. It is therefore RECOMMENDED that the sender set port = 1 except when it is being used in this way. The receiver must ignore non-zero port values, and must ignore zero values unless the application is one to which the offer-answer model applies. Megaco/H.248 in particular does not conform to the offer-answer model, and port is therefore irrelevant. 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). Taylor Standards Track - Expires October 2002 6 SDP Conventions For TDM Circuits April 2002 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 circuit. . "PKT/TDM" denotes packet mode transport over a TDM circuit . "FRM/TDM" denotes frame mode transport over a TDM circuit. The audio MIME type applies only to TDM transport. The application/octet-string MIME type may be carried by any of the three transports. 4. Attributes For TDM circuits 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 Protocol Profile The protocol profile attribute is required to distinguish payloads characterized by the apllication/octet-string MIME type. As mentioned above, 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. Taylor Standards Track - Expires October 2002 7 SDP Conventions For TDM Circuits April 2002 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> 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 following table contains the Layer 1 protocols defined in this document. They correspond to the non-audio codepoints for the User information layer 1 protocol given in Q.931. Symbol Description V110 ITU-T standardized rate adaption V.110, I.460 and X.30. Requires TDM transport. V120 ITU-T standardized rate adaption V.120. Requires TDM transport. Taylor Standards Track - Expires October 2002 8 SDP Conventions For TDM Circuits April 2002 X31 ITU-T standardized rate adaption X.31 HDLC flag stuffing. Requires PKT/TDM (packet-mode) transport. H221 An H.320 session using the H.221 multiplex. Requires TDM transport. H223 An H.324/I session using the H.223 multiplex [Note 1]. Requires TDM transport. Note 1: The H223 codepoint is not intended to preclude the use of an H.226 multiplex for multilink operation in accordance with H.324 Annex F. 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 either PKT/TDM (packet mode) or FRM/TDM (frame mode) transport is being used. 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) Requires TDM transport. Q922 Recommendation Q.922 (frame switching). Layer 1 must be unspecified. Requires FRM/TDM (frame mode) transport. Q922A Core aspects of frame mode (Annex A/Q.922) (frame relay). Layer 1 must be unspecified. Requires FRM/TDM (frame mode) transport. 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). Taylor Standards Track - Expires October 2002 9 SDP Conventions For TDM Circuits April 2002 X75SLP Recommendation X.75 single Link Procedure (SLP). ISO7776 ISO/IEC 7776 DTE-DCE operation. 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) Requires TDM transport. PPP Point to Point Protocol (RFC 1598, RFC 1618, or RFC 1973, depending on lower layer). Requires TDM transport. 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 circuit. This attribute is useful in cases where the user rate information is not passed end-to-end through in- band signalling and negotiation. 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 2002 10 SDP Conventions For TDM Circuits April 2002 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 circuit 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 2002 11 SDP Conventions For TDM Circuits April 2002 "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. Requires TDM transport and medium specified as audio/PCMU or audio/PCMA. Security Considerations This document deals with the signalling of information to direct the transfer of user information across TDM circuits. Threats to security may be identified both at the signalling level and at the media transport level. See [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 2002 12 SDP Conventions For TDM Circuits April 2002 References 1. M. Handley, V. Jacobson, C. Perkins "SDP: Session Description Protocol", IETF draft-ietf-mmusic-sdp-new-xx.txt, work in progress. 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.1-6, "Bearer Independent Call Control Protocol", July, 2001. 6. R. Kumar, M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", IETF RFC 3108, Standards Track, May 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. S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, Best Current Practice, March 1997. 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. 15. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with SDP", IETF Internet Draft approved as Standards Track RFC in March, 2002. Taylor Standards Track - Expires October 2002 13 SDP Conventions For TDM Circuits April 2002 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 2002 14