Internet Engineering Task Force
Internet Draft Rajesh Kumar
Document: draft-rajeshkumar-mmusic-sdp-atm-00.txt Mohamed Mostafa
March 1, 2000 Cisco Systems
Expires: September 1, 2000
Extension of the Session Description Protocol (SDP) for ATM-based
Narrowband Telephony
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 extends the Session Description Protocol (SDP)
described in RFC2327 for narrowband telephony applications that use
AAL1 or AAL2. The list of extensions is meant to be exhaustive.
Individual applications can use subsets of these extensions.
Rajesh Kumar, Mohamed Mostafa [Page 1]
1. Introduction
SDP will be used in conjunction with a media control protocol such
as Megaco (draft-ietf-megaco-reqs-10.txt) or MGCP (RFC2705) to
communicate the information needed to set-up narrowband telephony
connections through an ATM fabric. These narrowband telephony
connections include voice connections, voiceband data connections,
clear channel circuit emulation connections and demodulated,
baseband data connections for facsimile relay and modem relay.
These extensions are meant to address the following narrowband
telephony applications:
* Applications in which a new SVC is set-up for each narrowband
telephony connection. These SVCs could be AAL1 SVCs or
single-CID AAL2 SVCs.
* Applications in which existing PVC resources are assigned to
narrowband telephony connections. These resources could be
AAL1 PVCs, AAL2 single-CID PVCs or channels within
multiplexed AAL2 PVCs.
Generally, the SDP session description will be constructed by an ATM
network element such as a media gateway or an ATM or AAL2 switch and
will be sent to a connection peer via a bearer-independent
connection control mechanism such as tunneling through an ISUP
fabric. ATM network elements will used the SDP information to
construct bearer signaling messages based on Q.2931 and
Q.2630.1. These messages are used for ATM bearer connection
establishment and the binding of an ATM bearer connection or channel
to a telephony connection.
It is also possible for the media gateway controller (call agent) to
construct, modify or append to the SDP session description.
2. Conventions used in this document
This document uses all the syntactic conventions of standard SDP as
defined in RFC2327.
The SDP protocol (RFC2327) requires that non-standard attributes
and codec names use an "X-" prefix.
In this internet draft, the "X-" prefix is used consistently for
codec names (Table 1) that have not been registered with IANA.
However, this prefix is not used for the extension SDP attributes
defined in this document, since these are targeted for
standardization.
Since some implementations might not use these conventions,
it is suggested that any parser/builder designed to this extensions
Rajesh Kumar, Mohamed Mostafa [Page 2]
document should accept codec names and attribute names with or
without the "X-" prefix.
3. Capabilities Provided by SDP extensions
To support these applications, the SDP extensions in this document
provide the following session establishment capabilities:
* Identification by an ATM network element of its own address,
in one of several possible formats. A connection peer can
initiate SVC set-up to this address.
* Identification of the ATM bearer connection that is to be
bound to the narrowband telephony connection. This is either
a VCC in AAL1 applications or a channel (identified by a CID)
in AAL2 applications. This is useful in PVC applications.
* In AAL1 applications, declaration of a set of payload types
that can be bound to the ATM bearer connection. RTP payload
types that have been registered with IANA are re-used for
AAL1. In the manner of standard SDP, unregistered payload
types are mapped dynamically,
* In AAL2 application, declaration of a set of profiles that
can be bound to the ATM bearer connection. A mechanism for
dynamically defining custom profiles within the SDP session
description is included. This allows the use of custom
profiles for connections that span multi-network interfaces.
* A means of correlating narrowband telephony connections with
underlying ATM bearer connections. The backbone network
connection identifier or bnc-id specified in ITU Q.BICC
standardization work is used for this purpose. In order to
provide a common SDP base for applications based on
ISUP+/Q.BICC and SIP/SIP+, the neutral term æeecidÆ is used
in lieu of æbnc-idÆ in the SDP session descriptor.
* A means of specifying the explicit mapping of one codec type
and one packetization period into a service type. Service
types are voice, voiceband data and facsimile. This is useful
in determining the encoding to use when the connection is
upspeeded in response to modem or facsimile tones.
* A means of describing the QoS class, traffic parameters and
QoS parameters of the underlying ATM bearer connection.
Rajesh Kumar, Mohamed Mostafa [Page 3]
4. Format of the ATM Session Description
Session Descriptions for Narrowband Telephony over ATM contain the
following lines:
v= (protocol version)
o= (origin)
s= (session name)
c= (connection information)
t= (timestamp)
m= (media information and transport address)
a= (media attribute)
A session description for ATM-based narrowband telephony has exactly
one of each of the following lines: ævÆ, æoÆ, æsÆ, æcÆ, ætÆ and æmÆ.
These are mandatory per RFC2327. The æaÆ line is optional. This line
can be omitted. Also, there can be multiple æaÆ lines in an ATM
session description.
The order of lines in an ATM session description is exactly as
depicted above.
The æoÆ, æsÆ and ætÆ lines are included for strict conformance with
RFC2327. It is recognized that these lines do not carry useful
information in some ATM-based narrowband telephony applications. For
maximum interoperability, SDP parsers should not reject session
descriptions that are without these lines.
An ATM network element or call agent can propose several session
descriptions, each of which begins with a protocol version (ævÆ)
line. Each proposed session description is an alternate method of
realizing the connection. These options are trimmed down as the
connection establishment progresses.
Rajesh Kumar, Mohamed Mostafa [Page 4]
5. Structure of the Session Description Lines
5.1 The Origin Line
The origin line for an ATM-based narrowband telephony session is
structured as follows:
o=<username> <session id> <version> <network type>
<ATMaddressType> <ATMaddress>
The <username> is set to æ-æ.
The <session id> can be set to one of the following:
* a Call ID, known from a signaling or control protocol.
* an NTP timestamp referring to the moment when the SDP session
descriptor was created.
The <version> refers to the version of the SDP session descriptor
(not that of the SDP protocol). This is can be set to one of the
following:
* æ0Æ
* an NTP timestamp referring to the moment when the SDP session
descriptor was modified. If the SDP session descriptor has not
been modified by an intermediate entity (such as a call agent),
then the <version> timestamp will be the same as the <session
id> timestamp, if any.
The <network type> in ATM-based narrowband telephony session
descriptions can be one of the following: æATMÆ, æAAL1Æ, æAAL2Æ or
æAAL5_FRF11Æ. The generic value æATMÆ is adequate since the
adaptation type and higher-layer protocols are indicated elsewhere
in the session description.
The <ATMaddressType> and <ATMaddress> parameters are identical to
those for the connection information (æcÆ) line. As with the æcÆ
line, these can be omitted where appropriate. Alternatively, each of
these parameters can be set to a æ-æ when it is not particularly
meaningful or necessary to specify the ATM address.
5.2 The Session Name Line
In general, the session name line is structured as follows:
s=<session name>
For ATM-based narrowband telephony sessions, the <session name>
parameter is either empty or is set to a æ-æ. The resulting
lines are:
s=
Rajesh Kumar, Mohamed Mostafa [Page 5]
s=-
5.3 The Connection Information Line
The connection information line for ATM-based narrowband telephony
sessions is structured as follows:
c=ATM <ATMaddressType> <ATMaddress>
The <ATM address> refers to the local ATM address rather than the
ATM address of the remote peer. See the description of the media
information line below for a means of indicating the ATM address of
the remote peer.
The <ATMaddressType> can be NSAP, E164 or GWID.
The <ATMaddress> format depends on the <ATMaddressType>.
NSAP: If the ATMaddressType is NSAP, the ATMaddress is expressed as
a string of 20 octets in dotted hex form. The last octet of the NSAP
address is the æselectorÆ field that is not used for ATM addressing
and is available for non-standard use. The prior six octets of the
NSAP are an IEEE 802 MAC address assigned to the gateway. For
example:
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
E164: If the ATMaddressType is E164, the ATMaddress is expressed as
decimal numbers with up to 15 digits. For example:
c=ATM E164 9738294382
GWID: If the ATMaddressType is GWID meaning that the address is a
private Voice Gateway identifier (unique within context of network),
the ATMaddress is expressed as ASCII string ("A"-"Z", "a"-"z", "0"-
"9",".","-","_"). For example:
c=ATM GWID officeABCmgx101vism12
The connection information line is always present in an SDP session
descriptor. However, if there is no address to transmit, this line
can be represented in one of the following equivalent ways:
c=ATM
c=ATM - -
This might be used when the address is known a priori.
Rajesh Kumar, Mohamed Mostafa [Page 6]
5.4 The Timestamp Line
The timestamp line for an SDP session descriptor is structured as
follows:
t= <start time> <stop time>
For ATM-based narrowband telephony sessions, the <start time>
parameter can be made equal to the NTP timestamp (if any) used for
the <session id> in the æoÆ line. It can also be set to 0
indicating its irrelevance.
The <stop time> parameter is set to 0 in the ATM-based narrowband
telephony context.
5.5 Media Information Line for AAL1 sessions
The media information line for AAL1-based narrowband telephony
sessions is structured as follows:
m=audio <virtualConnectionId> AAL1/AVP <payload_type#1>
<payload_type#2>...<payload_type #n>
Note that it is not possible to make this line identical to the æmÆ
line in VoAAL2 due to basic differences between the two
applications.
The <virtualConnectionId> parameter can be in one of the following
formats:
* <vcci>
* <ATMaddressType>-<ATMaddress>/<vcci>
* <port_id>/<vpi>/<vci>
where the number of slashes and/or the application context are
used to differentiate between the various options. Within the SDP
media information line, <vcci>, <port id>, <vpi> and <vci> are
decimal numbers. The <ATMaddressType> and <ATMaddress> are identical
to their definitions above for the connection information line with
the difference that this address refers to the remote peer in the
media information line.
A æ$Æ notation implies æanyÆ. A æ$Æ can be used in lieu of <vcci>,
<port id>, <vpi> , <vci> or the entire virtualConnectionId
parameter.
Additionally, a æ$Æ can be used in lieu of:
* the hyphenated concatenation of the remote peer
<ATMaddressType> and <ATMaddress>
* the remote peer <ATMaddress> but not the <ATMaddressType> .
Rajesh Kumar, Mohamed Mostafa [Page 7]
There are contexts such as SVC-based applications where there
is no need to communicate the <virtualConnectionId> parameter
across the call agent - media gateway interface. In these contexts,
it is sufficient to use a æ$Æ, æ$/$Æ or æ$/$/$Æ for the
<virtualConnectionId> parameter.
When the network uses PVCs the VCCI values are pre-provisioned. If
connections are established via SVCs or S/PVCs, the VCCI is selected
from the list of available VCCIs. The VCCI can be signaled end-to-
end within the Generic Information Transport (GIT) as part of the
ITU Recommendation Q.2931 Setup message per ITU Recommendation
Q.2941.2. Q.2941.2 proposes that bit 16 of a 16 bit VCCI be used
to prevent glare in the allocation of VCCIs from either end. This
Q.2941-based scheme is not adequate for preventing glare when a
limited number of PVCs are dynamically assigned to narrowband
telephony connections on a call-by-call basis. For this dynamic PVC
context, a mechanism for glare reduction such as assigning the
lowest available values from different ends is needed.
The <port id> parameter is used to identify the physical trunk port
on a stand-alone gateway or on a multiplexer into which the
gateway is plugged as a tributary module. The VPI and VCI have their
usual ATM connotation.
Although RTP encapsulation defined in rfc1889 is not used, the
payload type variables are used exactly as defined in rfc1890.
Hence, the protocol used for Voice-over-AAL1 is identified as
AAL1/AVP in the media information line.
Following the text string æAAL1/AVPÆ, there is a list of payload
types. The ordering of these payload types (preferred codecs before
less favored ones) can indicate preference is some applications.
These can be either statically assigned or dynamically mapped
payload types. Encodings that are not statically mapped to payload
types by IANA are to be dynamically mapped at the time of
connection establishment to payload types in the decimal range 96-
127. The SDP ærtpmapÆ attribute (renamed æatmmapÆ) is used for this
purpose.
The following are examples of the use of the media information line
in the descriptions of AAL1 narrowband telephony sessions.
Example 1:
m=audio 27 AAL1/AVP 18 0 96
a=atmmap:96 G727-32
implies that the AAL1 VCCI=27 and that the supported encoding
formats are G.729 (or G.729a), PCM Mu-law and 32 kbps G.727.
Example 2:
m=audio 3/4/50 AAL1/AVP 8 15
Rajesh Kumar, Mohamed Mostafa [Page 8]
implies that the AAL1 virtual circuit used has VPI=4, VCI=50 and is
on trunk port #3. Further, it implies that the encoding formats are
G.711 A-law and G.728.
Example 3:
m=audio $ AAL1/AVP 8 15
implies that any AAL1 VCC may be used (subject to glare rules).
Example 4:
m=audio 2/6/$ AAL1/AVP 8 15
implies that any VCI on VPI= 6 of trunk port #2 may be used.
5.6 Media Information Line for AAL2 sessions
The media information line for AAL2-based narrowband telephony
sessions is structured as follows:
m=audio <virtualConnectionId> <profileType #1> <profile #1>...
<profile #n1> à <profileType #M> <profile #1>...
<profile #nM>
In certain applications, the ordering of profiles (preferred
profiles before less favored ones) might imply a preference. In this
case, the profiles associated with different profile types can be
interspersed rather than grouped together as in the definition
above.
Note that it is not possible to make this line identical to the æmÆ
line in Voice-over-AAL1 due to basic differences between the two
applications.
The <virtualConnectionId> parameter can be in one of the following
formats:
* <vcci>/<cid>
* <ATMaddressType>-<ATMaddress>/<vcci>/<cid>
* <port id>/<vpi>/<vci>/<cid>
* <bcg>/<vpi>/<vci>/<cid>
* <bcg>/<vcci>/<cid>
where the number of slashes and/or the application context are
used to differentiate between the various options. Within the SDP
media information line, <vcci>, <port id>, <bcg>, <vpi> , <vci> and
<cid> are decimal numbers. The <ATMaddressType> and <ATMaddress> are
identical to the definitions above for the connection information
line with the difference that this address refers to the remote peer
in the media information line.
Rajesh Kumar, Mohamed Mostafa [Page 9]
A æ$Æ notation implies æanyÆ. A æ$Æ can be used in lieu of <vcci>,
<port id>, <vpi> , <vci>, <cid> or the entire virtualConnectionId
parameter.
Additionally, a æ$Æ can be used in lieu of:
* the hyphenated concatenation of the remote peer
<ATMaddressType> and <ATMaddress>
* the remote peer <ATMaddress> but not the <ATMaddressType>.
There are contexts such as SVC-based applications where there
is no need to communicate the <virtualConnectionId> parameter
across the call agent - media gateway interface. In these contexts,
it is sufficient to use a æ$Æ, æ$/$Æ, æ$/$/$Æ or æ$/$/$/$Æ for the
<virtualConnectionId> parameter.
When the network uses PVCs the VCCI values are pre-provisioned. If
connections are established via single-CID SVCs or S/PVCs, the VCCI
is selected from the list of available VCCIs. The VCCI can be
signaled end-to-end within the Generic Information Transport (GIT)
as part of the ITU Recommendation Q.2931 Setup message per ITU
Recommendation Q.2941.2. Q.2941.2 proposes that bit 16 of a 16 bit
VCCI be used to prevent glare in the allocation of VCCIs from
either end. This Q.2941-based scheme is not adequate for preventing
glare when a limited number of single-CID PVCs are dynamically
assigned to narrowband telephony connections. For this dynamic PVC
context, a mechanism for glare reduction such as assigning the
lowest available values from different ends is needed.
The <cid> in AAL2 has the same value on both gateways that are part
of the connection. It is expected that both gateways may be required
to select AAL2 channels for different calls dependent on the
direction from which the calls arrived. Therefore, the possibility
will occur that gateways may be selecting the channel for two
separate calls simultaneously. In this context, a mechanism for
glare reduction such as assigning the lowest available values from
different ends is needed.
The <port id> parameter is used to identify the physical trunk port
on a stand-alone gateway or on a multiplexer into which the
gateway is plugged as a tributary module. The <bcg> parameter refers
to the bearer connection group as defined in Q.2630.1. The <vpi>,
<vci>, <vcci> and <cid> have their usual ATM connotation.
The <profileType> parameter indicates the type of profile. It is
expressed in the format AAL2/<oui> where <oui> is an
organizationally unique identifier. Currently defined values of
<oui> are æITUÆ, æATMFÆ and æcustomÆ. The resulting profileType
values indicate the following:
* AAL2/ITU indicates that AAL2 is used as the adaptation layer
and the profiles are defined by ITU in specification I.366.2.
Rajesh Kumar, Mohamed Mostafa [Page 10]
* AAL2/ATMF indicates that AAL2 is used as the adaptation layer
and the profiles are defined by the ATM Forum in
specification AF-VTOA-0113.
* AAL2/custom indicates that AAL2 is used as the adaptation
layer and the profiles are non-standard custom profiles.
The <profile> parameter is expressed as a decimal number. The value
of the profile for profiles of the type AAL2/ITU or AAL2/ATMF are in
range 0-255 in accordance with ITU-T I.366.2 Annex P and AF-VTOA-
0113.
For example, the media information line may look like:
m=audio 123/5 AAL2/ITU 1
This media line indicates that the media contains audio. The VCCI
for the AAL2 connection is decimal 123 and the CID is decimal 5. The
AAL2 connection uses ITU profile 1 as defined in I.366.2.
m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1
implies that any AAL2 VCC may be used (subject to glare rules). A
preferentially ordered list of profiles is suggested for this
connection with AAL2/ITU 8 having the highest priority.
5.7 The Media Attribute Lines
In an SDP line sequence, the media information line æmÆ is
followed by one or more media attribute or æaÆ lines. Media
attribute lines are per the format below:
a=<attribute>:<value>
or
a=<value>
In general, media attribute lines are optional except when needed to
qualify the media information line. This qualification is necessary
when the "m" line for an AAL1 session specifies a payload type that
needs to be dynamically mapped. The æatmmapÆ media attribute line
defined below is used for this purpose.
The following media attribute lines are defined for use in
descriptions of ATM-based narrowband telephony sessions:
* The attributes defined in RFC2327 which allow indication of
the direction in which a session is active. These are
a=sendonly, a=recvonly, a=sendrecv, a=inactive.
* The æPtimeÆ attribute defined in RFC2327. It indicates the
packet period.
Rajesh Kumar, Mohamed Mostafa [Page 11]
* The æatmmapÆ attribute. In the AAL1 context, this is used to
dynamically map payload types into codec strings.
* The æeecidÆ attribute. This stands for æend-to-end connection
identifierÆ. It provides a means of correlating narrowband
telephony connections with underlying ATM bearer connections.
In the Q.BICC/ISUP+ context, the eecid is synonymous with the
bnc-id (backbone network connection identifier). In the SDP
session description, the more general term æeecidÆ is used in
order to provide a common SDP baseline for ATM telephony
applications using Q.BICC/ISUP+ and SIP/SIP+.
* The æprofiledescÆ attribute which can be used to describe
AAL2 profiles. Although any AAL2 profile can be so described,
this attribute is useful for describing, at connection
establishment time, custom profiles that might not be known
to the far end. This attribute applies in the AAL2 context
only.
* The ævselÆ attribute which, depending on the application, can
indicate preference for or selection of a single voice
codec. This can be optionally used in both the AAL1 and AAL2
contexts in conjunction with the æmÆ line.
* The ædselÆ attribute which, depending on the application, can
indicate preference or selection of a single voiceband data
codec. This can be optionally used in both the AAL1 and AAL2
contexts in conjunction with the æmÆ line.
* The æfselÆ attribute which, depending on the application, can
indicate preference or selection of a single fax codec.
This can be optionally used in both the AAL1 and AAL2
contexts in conjunction with the æmÆ line.
* The æqosclassÆ attribute which indicates the QoS class of the
ATM bearer connection.
* The æqosparmsÆ attribute which can be used to describe
certain key QoS parameters (called Extended QoS parameters in
UNI 4.0 and PNNI).
* The ægnrltrfcdescÆ attribute which can be used to describe
certain general traffic parameters.
* The æatmtrfcdescÆ attribute which can be used to describe
certain key ATM traffic parameters.
Rajesh Kumar, Mohamed Mostafa [Page 12]
5.7.1 The æatmmapÆ attribute
The æatmmapÆ attribute is defined on the basis of the ærtpmapÆ
attribute used in RFC2327.
a=atmmap:<payload_type> <encoding_name>
The æatmmapÆ attribute is used to dynamically map encoding names
into payload types. This is necessary for those encoding names which
have not been assigned a static payload type through IANA. Payload
types and encoding techniques that have been registered with IANA
for RTP are retained for AAL1-based narrowband telephony.
The encoding names in Table 1 are case-insensitive.
Table 1: Encoding Names and Payload Types
|---------------------|--------------|---------------------------|
| Encoding Technique | Encoding Name| Payload type |
|---------------------|--------------|---------------------------|
| PCM - Mu law | "PCMU" | 0 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| 32 kbps ADPCM | "G726-32" | 2 (Statically Mapped) |
|---------------------|--------------|---------------------------|
|Dual rate 5.3/6.3kbps| "G723" | 4 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| PCM- A law | "PCMA" | 8 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| 7 KHz audio coding | "G722" | 9 (Statically Mapped) |
| within 64 kbps | | |
|---------------------|--------------|---------------------------|
| LD-CELP | "G728" | 15 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| CS-ACELP | "G729" | 18 (Statically Mapped) |
|(normal/low-complexity) | |
|---------------------|--------------|---------------------------|
| Low-complexity | "X-G729a" | None, map dynamically |
| CS-ACELP | | |
|---------------------|--------------|---------------------------|
|Normal | "X-G729b" | None, map dynamically |
|CS-ACELP w/ ITU | | |
|defined silence | | |
|suppression | | |
|---------------------|--------------|---------------------------|
|Low-complexity | "X-G729ab" | None, map dynamically |
|CS-ACELP w/ ITU | | |
|defined silence | | |
|suppression | | |
|---------------------|--------------|---------------------------|
| 16 kbps ADPCM | "X-G726-16" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 24 kbps ADPCM | "X-G726-24" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 40 kbps ADPCM | "X-G726-40" | None, map dynamically |
|---------------------|--------------|---------------------------|
Rajesh Kumar, Mohamed Mostafa [Page 13]
Table 1 (continued): Encoding Names and Payload Types
|---------------------|--------------|---------------------------|
| Encoding Technique | Encoding Name| Payload type |
|---------------------|--------------|---------------------------|
| Dual rate 5.3/6.3 |"X-G7231-H" | None, map dynamically |
| kbps - high rate | | |
|---------------------|--------------|---------------------------|
| Dual rate 5.3/6.3 |"X-G7231-L" | None, map dynamically |
| kbps - low rate | | |
|---------------------|--------------|---------------------------|
| Dual rate 5.3/6.3 |"X-G7231a-H" | None, map dynamically |
| kbps - high rate w/ | | |
| ITU-defined silence | | |
| suppression | | |
|---------------------|--------------|---------------------------|
| Dual rate 5.3/6.3 |"X-G7231a-L" | None, map dynamically |
| kbps - high rate w/ | | |
| ITU-defined silence | | |
| suppression | | |
|---------------------|--------------|---------------------------|
| 16 kbps EADPCM | "X-G729a" | None, map dynamically |
| (2 bits/sample) | | |
|---------------------|--------------|---------------------------|
|Normal | "X-G729b" | None, map dynamically |
|CS-ACELP w/ ITU | | |
|defined silence | | |
|suppression | | |
|---------------------|--------------|---------------------------|
|Low-complexity | "X-G729ab" | None, map dynamically |
|CS-ACELP w/ ITU | | |
|defined silence | | |
|suppression | | |
|---------------------|--------------|---------------------------|
| 16 kbps ADPCM | "X-G726-16" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 24 kbps ADPCM | "X-G726-24" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 32 kbps ADPCM | "X-G726-32" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 40 kbps ADPCM | "X-G726-40" | None, map dynamically |
|---------------------|--------------|---------------------------|
|n x 64 kbps Clear | "X-CCD" | None, map dynamically |
|Channel without CAS | | |
|per af-vtoa-78. | | |
|---------------------|--------------|---------------------------|
|n x 64 kbps Clear | "X-CCD-CAS" | None, map dynamically |
|Channel with CAS | | |
|per af-vtoa-78. | | |
|---------------------|--------------|---------------------------|
|GSM Full Rate | "GSM" | 3 (Statically Mapped) |
|---------------------|--------------|---------------------------|
|GSM Half Rate | "X-GSM-HR" | None, map dynamically |
|---------------------|--------------|---------------------------|
|GSM-Enhanced Full Rate "X-GSM-EFR" | None, map dynamically |
|---------------------|--------------|---------------------------|
|GSM-Enhanced Half Rate "X-GSM-EHR" | None, map dynamically |
|---------------------|--------------|---------------------------|
Rajesh Kumar, Mohamed Mostafa [Page 14]
5.7.2 The æeecidÆ attribute
The æeecidÆ attribute is synonymous with the 4-byteæbnc-idÆ
parameter defined by T1SI, the ATM forum and the ITU Q.BICC
standardization effort. The term æeecidÆ stands for æend-to-end
connection identifierÆ, while æbnc-idÆ stands for æbackbone network
connection identifierÆ. The name "backbone" is slightly misleading
since it refers to the entire ATM network including the ATM edge and
ATM core networks. In Q.BICC terminology, an ATM "backbone"
connects TDM or analog edges.
While the term æbnc-idÆ might be used in the bearer signaling plane
and in an ISUP+/BICC call control plane, SDP session descriptors
use the neutral term æeecidÆ. This provides a common SDP baseline
for applications that use ISUP+/BICC and applications that use
SIP/SIP+.
In the forward SVC establishment model, the call-originating gateway
initiates SVC establishment and transmits an eecid to the call-
terminating gateway via SDP.
In backward SVC establishment model, the call-originating gateway
does not initiate SVC establishment. However, it transmits an
eecid to the call-terminating gateway via SDP. The call-terminating
gateway initiates SVC establishment.
The value of the eecid attribute values needs to be unique within
the gateway initiating the SVC set-up but not across multiple
gateways. Hence, the SVC-initiating gateway has complete control
over using and releasing values of this parameter. The eecid
attribute is used to correlate, one-to-one, received SVC SETUP
requests with service connection requests from the call agent. In
the forward call model, the call-terminating gateway uses the ATM
address of the call-originating gateway in the æcÆ line of the
session description to qualify the eecid. This is because multiple
call-originating gateways can sending identical eecids.
Within an SDP session description, the eecid attribute is used as
follows:
a=eecid:<value>
where <value> consists of up to 8 hex digits (equivalent to 4
octets).
The SVC-initiating gateway tunnels the eecid value through a
Q.2931 (UNI, PNNI, AINI, IISP, proprietary Q.2931 equivalent ) set-
up message or the Q.2630.1 Establish Request (ERQ) message.
Rajesh Kumar, Mohamed Mostafa [Page 15]
For Q.2931, the following viable options exist for tunneling the
eecid through bearer-plane signaling messages:
* Use the Generic Identifier Transport (GIT) IE. This method
is being standardized by the ATM forum for carriage of the
æbnc-idÆ (æeecidÆ).
* Use the called party subaddress IE in the backward SVC call
establishment model. Use the calling party subaddress IE in
the forward SVC call establishment model.
Several other non-viable options such as using the NSAP selector
byte are not described here.
For Q.2630.1, the SUGR (Served User Generated Reference) IE can be
used (subject to finalization of the standard).
In the backward path set-up model, the call-originating gateway can
release and re-use an eecid when it receives Q.2931 set-up or
Q.2630.1 establish request from the call-terminating end. As
described above, the æeecidÆ is tunneled through this Q.2931 or
Q.2630.1 message.
In the forward path set-up model, the call-originating gateway can
release and re-use an eecid when it receives a Q.2931 connect or
Q.2630.1 establish confirm from the call-terminating end. This
message need not carry the eecid. The Q.2931 call reference or the
Q.2630.1 Destination Signaling Association Identifier (DSAID) points
to the eecid.
Since the gateway that issued the <eecid> in the SDP æownsÆ it,
there can be no race conditions in re-using its value immediately on
release. If not already released by the gateway issuing it, the
<eecid> value is released by the issuing gateway if the connection
is deleted or the connection set-up aborted.
5.7.3 The æprofiledescÆ attribute
There is one æprofiledescÆ media attribute line for each AAL2
profile that is intended to be described. The æprofiledescÆ media
attribute line is structured as follows:
a=profiledesc: <profileType> <profile> <uui_code_range#1>
<encoding name#1> <packet_length#1> <packet_time#1>
<uui_code_range#2> <encoding name#2> <packet_length#2>
<packet_time#2>... <uui_code_range#N> <encoding name#N>
<packet_length#N> <packet_time#N>
Here, <profileType> and <profile> are identical to their
definition, above, for the æmÆ line.
The profile elements (rows in the profile tables of ITU I.366.2 or
AF-VTOA-0113) are represented as four-tuples following the <profile>
parameter in the æprofiledescÆ media attribute line. If a member of
one of these four-tuples is not specified or is implied, then it is
set to æ-æ.
The <uui_code_range> parameter is represented by D1-D2, where D1 and
D2 are decimal integers in the range 0 through 15.
Rajesh Kumar, Mohamed Mostafa [Page 16]
The <encoding_name> parameter can take one of the values in column 2
of Table 1. Additionally, it can take on the following descriptor
strings: "PCMG", "SIDG" and "SID729". These stand for generic PCM,
generic SID and G.729 SID respectively.
The <packet_length> is a decimal integer representation of the AAL2
packet length in octets.
The <packet_time> is a decimal integer representation of the AAL2
packetization interval in ms.
For instance, the æprofiledescÆ media attribute line below defines
the AAL2/custom 100 profile. This profile is reproduced in the table
below. For a description of the parameters in this profile such as
M and the sequence number interval, see ITU I.366.2.
a=profiledesc:AAL2/custom 100 0-7 PCMG 40 5 0-7 SIDG 1 5 8-15
G726-32 40 10 8-15 SIDG 1 5
If the <packet_time> parameter is to be omitted or implied, then the
same profile can be represented as follows:
a=profiledesc:AAL2/custom 100 0-7 PCMG 40 - 0-7 SIDG 1 - 8-15
G726-32 40 - 8-15 SIDG 1 -
If a gateway has a provisioned or hard coded definition of a
profile, then any definition provided via the æprofiledescÆ line
overrides it. The exception to this rule is with regard to standard
profiles such as ITU-defined profiles and ATMF-defined profiles. In
general, these should not be defined via a æprofiledescÆ media
attribute line. If they are, then the definition needs to be
consistent with the standard definition else the SDP session
descriptor should be rejected with an appropriate error code.
|---------------------------------------------------------------|
| UUI | Packet |Encoding | | |Packet|Seq.No. |
| Code | Length |per ITU |Description of | M |Time |Interval|
|point |(octets)|I.366.2 | Algorithm | |(ms) |(ms) |
|Range | | 2/99 | | | | |
| | | version | | | | |
|---------------------------------------------------------------|
| 0-7 | 40 | Figure | PCM, G.711-64,| 1 | 5 | 5 |
| | | B-1 | generic | | | |
|------|--------|---------|---------------|-----|------|--------|
| 0-7 | 1 | Figure | Generic SID | 1 | 5 | 5 |
| | | I-1 | | | | |
|------|--------|---------|---------------|-----|------|--------|
| 8-15 | 40 | Figure | ADPCM, | 2 | 10 | 5 |
| | | E-2 | G.726-32 | | | |
|------|--------|---------|---------------|-----|------|--------|
| 8-15 | 1 | Figure | Generic SID | 1 | 5 | 5 |
| | | I-1 | | | | |
|------|--------|---------|---------------|-----|------|--------|
Rajesh Kumar, Mohamed Mostafa [Page 17]
5.7.4 The ævselÆ attribute
The ævselÆ media attribute line can be used to indicate either
preference for or selection of a single voice codec in ATM-based
narrowband telephony applications. When present, it complements the
media information æmÆ line. The ævselÆ line is structured as
follows:
a=vsel:<encoding_name> <packet_length><packet_time>
where the <encoding_name> parameter can take one of the values in
column 2 of Table 1. The <packet_length> and <packet_time>
parameters are per their definition, above, for the æprofiledescÆ
media attribute line. Each of these parameters (<encoding_name>,
<packet_length>and <packet_time>) can be set to æ-æ when not needed.
Also, the entire ævselÆ media attribute line can be omitted when not
needed. For example,
a=vsel:G729 10 10
indicates preference for or selection of G.729 or G.729a (both are
interoperable) as the voice encoding scheme. A packet length of 10
octets and a packetization interval of 10 ms are indicated in this
media attribute line. If the packet length and packetization
interval are intended to be omitted, then this media attribute line
becomes
a=vsel:G729 - -
The media attribute line
a=vsel:G726-32 40 10
indicates preference for or selection of 32 kbps ADPCM with a packet
length of 40 octets and a packetization interval of 10 ms.
5.7.5 The ædselÆ attribute
The ædselÆ media attribute line can be used to indicate either
preference for or selection of a single voiceband data codec in
ATM-based narrowband telephony applications. If an æfselÆ media
attribute line is not present in the SDP session descriptor, then
ædselÆ applies to both modem data and fax data (unless the latter is
well-known by default). If an æfselÆ media attribute line is indeed
present in the same SDP session description, then ædselÆ applies to
modem data but not to fax data. When present, ædselÆ complements
the media information æmÆ line. The ædselÆ line is structured as
follows:
a=dsel:<encoding_name><packet_length><packet_time>
where the <encoding_name> parameter can take one of the values in
column 2 of Table 1. The <packet_length> and <packet_time>
parameters are per their definition, above, for the æprofiledescÆ
media attribute line. Each of these parameters (<encoding_name>,
<packet_length>and <packet_time>) can be set to æ-æ when not needed.
Also, the entire ædselÆ media attribute line can be omitted when not
needed.
Rajesh Kumar, Mohamed Mostafa [Page 18]
For example,
a=dsel:G726-32 20 5
indicates preference for or selection of 32 kbps ADPCM with a
packet length of 20 octets and a packetization interval of 5 ms as
the voiceband data encoding scheme.
5.7.6 The æfselÆ attribute
The æfselÆ media attribute line can be used to indicate either
preference for or selection of a single fax data codec in ATM-based
narrowband telephony applications. If an æfselÆ media attribute
line is not present in the SDP session descriptor, then ædselÆ
applies to both modem data and fax data (unless the latter is well-
known by default). When present, æfselÆ complements the media
information æmÆ line. The æfselÆ line is structured as follows:
a=fsel:<encoding_name> <packet_length><packet_time>
where the <encoding_name> parameter can take one of the values in
column 2 of Table 1. The <packet_length> and <packet_time>
parameters are per their definition, above, for the æprofiledescÆ
media attribute line. Each of these parameters (<encoding_name>,
<packet_length>and <packet_time>) can be set to æ-æ when not needed.
Also, the entire æfselÆ media attribute line can be omitted when not
needed.
For example,
a=fsel:FXDMOD-3 - -
indicates demodulation and remodulation of ITU-T group 3 fax at the
gateway.
5.7.7 The æqosclassÆ attribute
When present, the æqosclassÆ attribute indicates one QoS class
specified by the entity constructing the SDP session description.
The æqosclassÆ media attribute line is structured as follows:
a=qosclass: <QoS_class>
Here, <QoS_class> is a string that is understood by all entities
which parse or build the SDP descriptor. Possible values of this
parameter are per the ATMF forum af-tm-0056.000 definition (æcbrÆ,
ært-vbrÆ, ænrt-vbrÆ, æabrÆ, æubrÆ and ægfrÆ) or the ITU I.371
definition (æsbr1Æ, æsbr2Æ, æsbr3Æ, ædbrÆ, æabt/dtÆ, æabt/itÆ and
æabrÆ).
These string values are case-insensitive. When the bearer connection
is a single CID within a multiplexed AAL2 VC, then this SDP
attribute does not apply.
Rajesh Kumar, Mohamed Mostafa [Page 19]
5.7.8 The æqosparmsÆ attribute
When present, the æqosparmsÆ attribute can be used to describe
certain key QoS parameters (called Extended QoS parameters in UNI
4.0 and PNNI). In this context, these parameters can refer to
acceptable values (worst case) and can be used by the bearer
signaling and routing protocols.
The æqosparmsÆ media attribute line is structured as follows:
a=qosparms:<bsunit> <fjit> <fltcy> <flr> <bjit> <bltcy> <blr>
The <bsunit> parameter indicates the base unit used for the
remaining parameters in the æqosparmsÆ media attribute line. In the
æqosparmsÆ media attribute line, it can take on the values æpÆ or
æcÆ. A value of æpÆ indicates that the remainder of the æqosparmsÆ
media attribute line refers to packet latency, jitter and loss
ratio. An example of such a packet stream is an AAL2 packet stream
referenced by a CID value. A value of æcÆ indicates that the
remainder of the æqosparmsÆ media attribute line refers to cell
latency, jitter and loss ratio.
<fjit> and <bjit> refer to the forward and backward jitter in
microseconds. As qualified by <bsunit>, this can be packet jitter or
cell jitter. It is probably adequate to express it as a decimal
integer, although fractional values are not excluded.
<fltcy> and <bltcy> refer to the forward and backward latency in
microseconds. As qualified by <bsunit>, this can be packet latency
or cell latency. It is probably adequate to express it as a decimal
integer, although fractional values are not excluded.
<flr> and <blr> refer to forward and backward loss ratios. As
qualified by <bsunit>, this can be packet loss ratio or cell loss
ratio. The ratio referred to is between the number of units
(packets/cells) lost and the number of units transmitted. It is
expressed as an order of magnitude n, where the loss ratio takes on
the value 10 to the minus n. The value of n is coded as a decimal
integer.
Within the æqosparmsÆ media attribute line, forward (f) refers to
the direction from the entity initiating Bearer signaling (Q.2931-
based or Q.2630.1-based). Backward (b) refers to the opposite
direction.
If any of these parameters is not specified, inapplicable or is
implied, then it is set to æ-æ.
An example use of the <qosparms> attribute for an rt-VBR, single-
CID AAL2 voice VC is:
a=qosparms:c 8125 32000 11 4675 18000 12
Rajesh Kumar, Mohamed Mostafa [Page 20]
This implies a forward path cell delay variation of 8.125 ms, a
backward path cell delay variation of 4.675 ms, a forward path
latency of 32 ms, a backward path latency of 18 ms, a forward path
cell loss ratio of 10 to the minus 11 and a backward path cell loss
ratio of 10 to the minus 12.
5.7.9 The ægnrltrfcdescÆ attribute
When present, the ægnrltrfcdescÆ attribute can be used to indicate
traffic rates and maximum burst sizes. The ægnrltrfcdescÆ media
attribute line is structured as follows:
a=gnrltrfcdesc:<bsunit> <fpr> <fsr> <fmr> <fmbs> <bpr>
<bsr><bmr> <bmbs>
The <bsunit> parameter indicates the base unit used for the
remaining parameters in the ægnrltrfcdescÆ media attribute line. In
the ægnrltrfcdescÆ media attribute line, it can take on the values
æpÆ, æcÆ, æbÆ and æoÆ.
A value of æpÆ indicates that packets per second and packets are
used respectively as the units for rates and burst sizes in the
remainder of the ægnrltrfcdescÆ media attribute line. A value of
æcÆ indicates that cells per second and cells are used respectively
as the units for rates and burst sizes in the remainder of the
ægnrltrfcdescÆ media attribute line. A value of æbÆ indicates that
bits per second and bits are used respectively as the units for
rates and burst sizes in the remainder of the ægnrltrfcdescÆ media
attribute line. A value of æoÆ indicates that octets per second and
octets are used respectively as the units for rates and burst sizes
in the remainder of the ægnrltrfcdescÆ media attribute line. Units
of packets, cells, bits or octets are applicable depending on the
application context. For instance, when the underlying bearer
connection is an AAL1 VC or a single-CID AAL2 VC, cells are the
appropriate unit. When the underlying bearer connection is a
multiplexed AAL2 VC, packets are the appropriate unit.
<fpr> and <bpr> are the forward and backward peak rates. Depending
of the value of <bsunit>, their units are packets per second, cells
per second, bits per second or octets per second. When referring to
an ATM VC, <fpr> and <bpr> apply to cells with CLP values of 0 or 1
within the nrt-VBR, rt-VBR and CBR QoS classes.
<fsr> and <bsr> are the forward and backward sustainable rates.
Depending of the value of <bsunit>, their units are packets per
second, cells per second, bits per second or octets per second. When
referring to an ATM VC, <fsr> and <bsr> apply to cells with a CLP
value of 0 within the nrt-VBR and rt-VBR QoS classes.
<fmr> and <bmr> are the forward and backward minimum rates.
Depending of the value of <bsunit>, their units are packets per
second, cells per second, bits per second or octets per second. When
Rajesh Kumar, Mohamed Mostafa [Page 21]
referring to an ATM VC, <fmr> and <bmr> apply to cells with CLP
values of 0 or 1 within the ABR QoS class.
<fmbs> and <bmbs> are the forward and backward maximum burst sizes.
Depending of the value of <bsunit>, their units are packets, cells,
bits or octets. When referring to an ATM VC, <fmbs> and <bmbs> apply
to cells with a CLP value of 0 within the nrt-VBR and rt-VBR QoS
classes.
Within the ægnrltrfcdescÆ media attribute line, forward (f) refers
to the direction from the entity initiating Bearer signaling
(Q.2931-based or Q.2630.1-based). Backward (b) refers to the
opposite direction.
If any of these parameters is not specified, inapplicable or is
implied, then it is set to æ-æ.
An example use of the <gnrltrfcdesc> attribute for an rt-VBR,
single-CID AAL2 voice VC is:
a=gnrltrfcdesc:c 200 100 - 20 200 100 - 20
This implies a forward and backward PCR of 200 cells per second, a
forward and backward SCR of 100 cells per second, an MCR that is
unspecified since it is inapplicable and a forward and backward
maximum burst size of 20 cells.
5.7.10 The æatmtrfcdescÆ attribute
When present, the æatmtrfcdescÆ attribute can be used to indicate
ATM-specific traffic parameters such as CLP tagging, frame discard
and best effort indicators. The æatmtrfcdescÆ media attribute line
is structured as follows:
a=atmtrfcdesc: <bei> <ffd> <fte> <bfd> <bte>
<bei> is the best effort indicator flag. It can take on the values
of "on" and "off". An "on" value applies only to the UBR QoS class.
<ffd> and <bfd> indicate that frame discard is permitted in the
forward or backward directions. These can take on the values of
"on" or "off".
<fte> (forward tag enable) and <bte> (backward tag enable) indicate
that CLP tagging is requested in the forward or backward directions.
These can take on the values of "on" or "off".
In these parameters, forward (f) refers to the direction from the
entity initiating Bearer signaling (Q.2931-based or Q.2630.1-
based). Backward (b) refers to the opposite direction.
If any of these parameters is not specified or is implied, then it
is set to æ-æ.
Rajesh Kumar, Mohamed Mostafa [Page 22]
An example use of the <atmtrfcdesc> attribute for an rt-VBR,
single-CID AAL2 voice VC is:
a=atmtrfcdesc:- off off off off
This implies that best effort is inapplicable and that frame discard
and CLP tagging are disabled in the forward and backward directions.
5.8 Examples of ATM session descriptions using SDP
An example of a complete AAL1 session description in SDP is:
v=0
o=- A3C47F21456789F0 0 ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL1/AVP 18 0 96
a=atmmap:96 G727-32
a=eecid:B3D58E32
An example of a complete AAL2 session description in SDP is:
v=0
o=- A3C47F21456789F0 0 ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1
a=eecid:B3E32
Rajesh Kumar, Mohamed Mostafa [Page 23]
The AAL2 session descriptor below is the same as the one above
except that it states an explicit preference for a voice codec, a
voiceband data codec and a voiceband fax codec. Further, it defines
the profile AAL2/custom 100 rather than assume that the far-end is
cognizant of the elements of this profile.
v=0
o=- A3C47F21456789F0 0 ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1
a=eecid:B3E32
a=profiledesc:AAL2/custom 100 0-7 PCMG 40 5 0-7 SIDG 1
5 8-15 G726-32 40 10 8-15 SIDG 1 5
a=vsel:G726-32 40 10
a=dsel:PCMU - -
a=fsel:G726-32 40 10
5.9 Representation of data media
The following encoding names in Table 1 can refer to data as well
as audio media: CCD and CCD-CAS in Table 1.
The following encoding names in Table 1 refer to data media:
FXDMOD-3 in Table 1.
In the AAL1 context, the media information line for these media
should be constructed as follows:
<virtualConnectionId> is as defined above in this document for AAL1
sessions. æDPÆ stands for ædata profileÆ along the lines of æAVPÆ
for æaudio-video profileÆ.
<aggregation_mode> specifies the number of TDM DS0s that are
aggregated by this encoding. For T1-based applications, it can take
on integral values in the inclusive range [1...24]. For E1-based
applications, it can take on integral values in the inclusive range
[1...31]. The default value is 1 and is equivalent to omitting
this parameter. Setting this parameter to a æ-æ is equivalent to
omitting it.
In the AAL2 context, the media information line for these data
media should be structured as follows:
<virtualConnectionId> is as defined above in this document for AAL2
sessions. æDPÆ stands for ædata profileÆ along the lines of æAVPÆ
for æaudio-video profileÆ.
<aggregation_mode> is as defined above for the AAL1 context.
Rajesh Kumar, Mohamed Mostafa [Page 24]
Note that there is only one encoding technique specified in the
media information line. This is because:
* In the case of n x 64 kbps clear channel data, there only one
encoding and packetization format given a particular ænÆ and
a particular adaptation (AAL1/AAL2).
* In the case of fax demodulation and remodulation (ITU
I.366.2), parameters such as information type, image data
size and control type are negotiated in the æbearer planeÆ
via type 3 messages. Therefore, there is no need to define
several alternate encoding techniques. Similarly, for
sending fax over IP, it is likely that æbearer planeÆ
messages will be used to synchronize the two ends. Also, AAL1
is not likely to be used for relaying demodulated fax data
and control.
Examples of valid representations of data media are:
m=data 29 AAL1/DP CCD 6
This indicates that VCCI=29 uses AAL1 encapsulation to transmit an
nx64 clear channel with n=6.
m=data 122/8 AAL2/DP CCD 12
This indicates that VCCI/CID=122/8 uses AAL2 encapsulation to
transmit an nx64 clear channel with n=12.
m=data 122/8 AAL2/DP FXMOD-3 æ-æ
This indicates that VCCI/CID=122/8 uses AAL2 encapsulation to
transmit group 3 demodulated facsimile and the associated control.
m=data 122/8 AAL2/DP FXMOD-3
This indicates that VCCI/CID=122/8 uses AAL2 encapsulation to
transmit group 3 demodulated facsimile and the associated control.
Rajesh Kumar, Mohamed Mostafa [Page 25]
6.0 Security Considerations
Security considerations for SDP extended for ATM are similar to
those for standard SDP described in RFC2327. In general, the SDP
session descriptions might originate in untrusted areas such as
equipment owned by end-subscribers or located at end-subscriber
premises. SDP relies on the security mechanisms of the encapsulating
protocol or layers below the encapsulating protocol. Examples of
encapsulating protocols are the Session Initiation Protocol (SIP)
and the Multimedia Gateway Control Protocol (MEGACO). These
protocols can use IPSec authentication as described in RFC1826 [Ref.
27]. IPSec encryption can be optionally used with authentication to
provide an additional, potentially more expensive level of security.
IPSec security associations can be made between equipment located in
untrusted areas and equipment located in trusted areas through
configured shared secrets or the use of a certificate authority.
References
[1] IETF RFC 2327, æSDP: Session Description ProtocolÆ, April Æ98,
Mark Handley and Van Jacobson.
[2] IETF RFC 1889, æRTP: A Transport Protocol for Real-Time
ApplicationsÆ, Jan. 1996.
[3] IETF RFC 1890, æRTP Profile for Audio and Video Conferences
with Minimal ControlÆ, Jan. 1996.
[4] ATMF UNI 3.1 Specification, af-uni-0010.002. Of special
interest for this document is Section 5.4.5.5, ATM Adaptation
Layer Parameters.
[5] ATMF UNI 4.0 Specification, af-sig-0061.000.
[6] ATMF Traffic Management Specification, Version 4.0, af-tm-
0056.000.
[7] ATMF Circuit Emulation Service (CES) Interoperability
Specification, version 2.0, af-vtoa-0078.000, Jan. 97.
[8] ATMF Voice and Telephony over ATM û ATM Trunking using AAL1 for
Narrowband Services, version 1.0, af-vtoa-0089.000, July 1997.
[9] ATMF Specifications of (DBCES) Dynamic Bandwidth Utilization û
in 64kbps Timeslot Trunking over ATM - using CES, af-vtoa-
0085.000, July 1997.
[10] ITU-T I.363.1, B-ISDN ATM Adaptation Layer Specification: Type
1 AAL, August 1996.
Rajesh Kumar, Mohamed Mostafa [Page 26]
[11] ITU-T I.363.2, B-ISDN ATM Adaptation Layer Specification: Type
2 AAL, Sept. 1997.
[12] ITU-T I.366.1, Segmentation and Reassembly Service Specific
Convergence Sublayer for AAL Type 2, June 1998.
[13] ITU-T I.366.2, AAL Type 2 Reassembly Service Specific
Convergence Sublayer for Trunking, Feb. 99.
[14] Draft ietf-avt-telephone-tones-05.txt, RTP payloads for
Telephone Signal Events, S.B.Petrack, Nov. 17, 1998.
[15] ITU-T Q.2931, B-ISDN Application Protocol for Access Signaling.
[16] Amendment 2 to ITU-T Q.2931, B-ISDN Application Protocol for
Access Signaling.
[17] SAP: Session Announcement Protocol , draft-ietf-mmusic-sap-v2-
04.txt, Mark Handley, Colin Perkins and Edmund Whelan .
[18] rfc2543, Handley, M., H. Schulzrinne , Schooler, E. and
Rosenberg, J., "Session Initiation Protocol (SIP)", March
1999.
[19] rfc1349, Type of Service in the Internet Protocol Suite. P.
Almquist. July 1992.
[20] rfc2474, Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F.
Baker, D. Black. December 1998.
[21] ITU-T I.363.5, B-ISDN ATM Adaptation Layer Specification: Type
5 AAL, Aug. 1996.
[22] ATMF PNNI 1.0, af-pnni-0055.000, March 1996.
[23] ietf-avt-rtp-new-05.txt, Oct. 21, 1999, RTP: A Transport
Protocol for Real-Time Applications.
[24] ietf-avt-profile-new-07.txt, Oct. 21, 1999, RTP Profile for
Audio and Video Conferences with Minimal Control.
[25] Media Gateway Control Protocol (MGCP), Mauricio Arango, Isaac
Elliott, Christian Huitema, Scott Pickett, Version 1.0,
RFC2705.
[26] draft-ietf-megaco-reqs-10.txt, January 5, 2000, Media Gateway
control protocol architecture and requirements, Nancy Greene,
Michael A. Ramalho, Brian Rosen.
[27] IP Authentication Header, R. Atkinson, August 1995, RFC1826.
Rajesh Kumar, Mohamed Mostafa [Page 27]
Acknowledgements
The authors wish to thank several colleagues at Cisco and in the
industry who have contributed towards the development of these SDP
extensions, and who have reviewed, implemented and tested these
constructs. Valuable technical ideas that have been incorporated
into this internet draft have been provided by Hisham Abdelhamid,
David Auerbach, Robert Biskner, Steve Casner, Alex Clemm, Bill
Foster, Snehal Karia, Raghu Thirumalai Rajan, Joe Stone and Bruce
Thompson of Cisco, Michael Brown, Rade Gvozdanovic, Graeme Gibbs and
Sophia Scoggins of Nortel Networks, and Ed Guy and Petros Mouchtaris
of Telcordia. The authors also wish to thank the ISC device control
group, especially Charles Eckel, Christian Groves, Tom Jepsen, Brian
Rosen and Tom Taylor for their review comments and their assistance
in the preparation of this document.
Authors' Addresses
Rajesh Kumar
Cisco Systems, Inc.
M/S SJC01/3
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: 1-800-250-4800
Email: rkumar@cisco.com
Mohamed Mostafa
Cisco Systems, Inc.
M/S SJC01/3
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: 1-800-250-4800
Email: mmostafa@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (March 2, 2000). All Rights
Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Rajesh Kumar, Mohamed Mostafa [Page 28]
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Rajesh Kumar, Mohamed Mostafa [Page 29]