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