One document matched: draft-taylor-mmusic-sdp-tdm-01.txt
Differences from draft-taylor-mmusic-sdp-tdm-00.txt
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 | PAFTECH AB 2003-2026 | 2026-04-24 10:35:01 |