Emulated Loop Control Protocol (ELCP) [52]. The Application ID is
defined by the ATM forum [61]. The SSCS used is per ITU I.366.2
[13].
a=aalApp:itu_i3662 A03E A
If leading zeros are not dropped, this can be represented as:
a=aalApp:itu_i3662 00A03E 0000000A
Since application identifiers have been specified only in the context
of the AAL2 SSCS defined in ITU I.366.2 [13],the <appClass> can be
set to '-' without ambiguity. The aalApp media attribute line can be
reduced to:
a=aalApp:- A03E A
or
a=aalApp:- 00A03E 0000000A
5.6.2.2 The 'cbrRate' attribute
When present, the 'cbrRate' attribute is used to represent the CBR
rate octet defined in Table 4-6 of ITU Q.2931 [15]. The format of
this media attribute line is:
a=cbrRate: <cbrRate>
Here, <cbrRate> is represented as exactly two hex digits. The "0x"
prefix is omitted since this parameter is always represented in hex.
Values currently defined by the ITU are:
+------------+-----------------------------------------------+
| VALUE | MEANING |
| (hex) | |
+------------+-----------------------------------------------+
| 01 | 64 kbps |
+------------+-----------------------------------------------+
| 04 | 1544 kbps |
+------------+-----------------------------------------------+
| 05 | 6312 kbps |
+------------+-----------------------------------------------+
| 06 | 32064 kbps |
+------------+-----------------------------------------------+
| 07 | 44736 kbps |
+------------+-----------------------------------------------+
| 08 | 97728 kbps |
+------------+-----------------------------------------------+
| 10 | 2048 kbps |
+------------+-----------------------------------------------+
| 11 | 8448 kbps |
+------------+-----------------------------------------------+
| 12 | 34368 kbps |
+------------+-----------------------------------------------+
| 13 | 139264 kbps |
+------------+-----------------------------------------------+
| 40 | n x 64 kbps |
+------------+-----------------------------------------------+
| 41 | n x 8 kbps |
+------------+-----------------------------------------------+
It is preferable that the cbrRate attribute be omitted rather than
set to an unspecified value of "-", since it conveys no information
in the latter case.
5.6.2.3 The 'sbc' attribute
The 'sbc' media attribute line denotes the subchannel count and is
meaningful only in the case of n x 64 clear channel communication. A
clear n x 64 channel can use AAL1 (ATM forum af-vtoa-78) or AAL2
adaptation (ITU I.366.2). Although no such standard definition
exists, it is also possible to use AAL5 for this purpose. An n x 64
clear channel is represented by the encoding names of "X-CCD" and
"X-CCD-CAS" in Table 2.
The format of the 'sbc' media attribute line is as follows:
a=sbc:<sbc>
Here, <sbc> can be expressed as a decimal or hex integer. This
attribute indicates the number of DS0s in a T1 or E1 frame that are
aggregated for transmitting clear channel data. 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]. When omitted, other means are to be
used to determine the subchannel count.
Use of the 'sbc' attribute provides a direct way to indicate the
number of 64 kbps subchannels bundled into an n x 64 clear channel.
An alternate mechanism to indicate this exists within the SDP
bandwidth information, or 'b', line [1]. In this case, instead of
specifying the number of subchannels, the aggregate bandwidth in kbps
is specified. The syntax of the 'b' line, copied verbatim from [1],
is as follows:
b=<modifier>:<bandwidth-value>
In the case of n x 64 clear channels, the <modifier> is assigned a
text string value of "AS", indicating that the 'b' line is
application-specific. The <bandwidth-value> parameter, which is a
decimal number indicating the bandwidth in kbps, is limited to one of
the following values in the n x 64 clear channel application context:
64, 128, 192, 256, 320, 384, 448, 512, 576, 640, 704, 768, 832,
896, 960, 1024, 1088, 1152, 1216, 1280, 1344, 1408, 1472, 1600,
1664, 1728, 1792, 1856, 1920, 1984
Thus, for n x 64 circuit mode data service,
a=sbc:6
is equivalent to
b=AS:384
The media attribute line
a=sbc:2
is equivalent to
b=AS:128
5.6.2.4 The 'clkrec' attribute
When present, the 'clkrec' attribute is used to indicate the clock
recovery method. This attribute is meaningful in the case of AAL1
unstructured data transfer (UDT). The format of the 'clkrec' media
attribute line is as follows:
a=clkrec:<clkrec>
The <clkrec> field can take on the following string values: "NULL",
"SRTS" or "ADAPTIVE". SRTS and adaptive clock recovery are defined
in ITU I.363.1 [10]. "NULL" indicates that the stream (e.g., T1/E1)
encapsulated in ATM is synchronous to the ATM network or is retimed,
before AAL1 encapsulation, via slip buffers.
5.6.2.5 The 'fec' attribute
When present, the 'fec' attribute is used to indicate the use of
forward error correction. Currently, there exists a forward error
correction method defined for AAL1 in ITU I.363.1 [10]. The format
of the 'fec' media attribute line is as follows:
a=fec:<fecEnable>
The <fecEnable> flag indicates the presence of absence of Forward
Error Correction. It can take on the string values of "NULL",
"LOSS_SENSITIVE" and "DELAY_SENSITIVE". An "NULL" value implies
disabling this capability. FEC can be enabled differently for
delay-sensitive and loss-sensitive connections.
5.6.2.6 The 'prtfl' attribute
When present, the 'prtfl' attribute is used to indicate the fill
level of cells. When this attribute is absent, then other means
(such as provisionable defaults) are used to determine the presence
and level of partial fill.
This attribute indicates the number of non-pad payload octets, not
including any AAL SAR or convergence sublayer octets. For example,
in some AAL1 applications that use partially filled cells with
padding at the end, this attribute indicates the number of leading
payload octets not including any AAL overhead.
The format of the 'prtfl' media attribute line is as follows:
a=prtfl:<partialFill>
Here, <partialFill> can be expressed as a decimal or a hex integer.
In general, permitted values are integers in the range 1 - 48
inclusive. However, this upper bound is different for different
adaptations since the AAL overhead, if any, is different. If the
specified partial fill is greater than or equal to the maximum fill,
then complete fill is used. Using a 'partial' fill of 48 always
disables partial fill.
In the AAL1 context, this media attribute line applies uniformly to
both P and non-P cells. In AAL1 applications that do not distinguish
between P and non-P cells, a value of 47 indicates complete fill
(i.e., the absence of partial fill). In AAL1 applications that
distinguish between P and non-P cells, a value of 46 indicates no
padding in P-cells and a padding of one in non-P cells.
If partial fill is enabled (i.e there is padding in at least some
cells), then AAL1 structures must not be split across cell
boundaries. These shall fit in any cell. Hence, their size shall be
less than or equal to the partial fill size. Further, the partial
fill size is preferably an integer multiple of the structure size.
If not, then the partial fill size stated in the SDP description
shall be truncated to an integer multiple (e.g., a partial fill size
of 40 is truncated to 36 to support six 6 x 64 channels).
5.6.2.7 The 'structure' attribute
This attribute applies to AAL1 connections only. When present, the '
structure' attribute is used to indicate the presence or absence of
structured data transfer (SDT), and the size in octets of the SDT
blocks. The format of the 'structure' media attribute line is as
follows:
a=structure: <structureEnable> <blksz>
where the <structureEnable> flag indicates the presence of absence of
SDT. It can take on the values of "on" or "off". An "on" value
implies AAL1 structured data transfer (SDT), while an "off" value
implies AAL1 unstructured data transfer (UDT).
The block size field, <blksz>, is an optional 16-bit field [15] that
can be represented in decimal or hex. It is set to a "-" when not
applicable, as in the case of unstructured data transfer (UDT). For
SDT, it can be set to a "-" when <blksz> is known by other means.
For instance, af-vtoa-78 [7] fixes the structure size for n x 64
service, with or without CAS. The theoretical maximum value of
<blksz> is 65,535, although most services use much less.
5.6.2.8 The 'cpsSDUsize' attribute
When present, the 'cpsSDUsize' attribute is used to indicate the
maximum size of the CPCS SDU payload. There can be several '
cpsSDUsize' lines in an SDP description.
The format of this media attribute line is as follows:
a=cpsSDUsize:<directionFlag><cpcs>
The <directionFlag> can be assigned the following string values: "f",
"b" and "fb". "f" and "b" indicate the forward and backward
directions respectively. "fb" refers to both directions (forward and
backward). Conventions for the forward and backward directions are
per section 2.3.
The <cpcs> fields is a 16-bit integer that can be represented in
decimal or in hex. The meaning and values of these fields are as
follows:
Application Field Meaning Values
AAL5 <cpcs> Maximum CPCS-SDU size 1- 65,535
AAL2 <cpcs> Maximum CPCS-SDU size 45 or 64
5.6.2.9 The 'aal2CPS' attribute
When present, the 'aal2CPS' attribute is used to describe parameters
associated with the AAL2 CPS layer.
The format of the 'aal2CPS' media attribute line is as follows:
a=aal2CPS:<cidLowerLimit><cidUpperLimit><timerCU> <simplifiedCPS>
Each of these fields can be set to a "-" when the intention is to not
specify them in an SDP descriptor.
The <cidLowerLimit> and <cidUpperLimit> can be assigned integer
values between 8 and 255 [11], with the limitation that
<cidUpperLimit> be greater than or equal to <cidLowerLimit>. For
instance, for POTS applications based on [52], <cidLowerLimit> and
<cidUpperLimit> can have values of 16 and 223 respectively.
The <timerCU> integer represents the "combined use" timerCU defined
in ITU I.363.2. This timer is represented as an integer number of
microseconds. It is represented as the decimal integer equivalent of
32 bits.
The <simplifiedCPS> parameter can be assigned the values "on" or
"off". When it is "on", the AAL2 CPS simplification described in
[52] is adopted. Under this simplification, each ATM cell contains
exactly on AAL2 packet. If necessary, octets at the end of the cell
are padded with zeros. Since the <timerCU> value in this context is
always 0, it can be set to "-".
5.6.2.10 The 'aal2CPSSDUrate' attribute
When present, the 'aal2CPSSDUrate' attribute is used to place an
upper bound on the SDU bit rate for an AAL2 CID. This is useful for
limiting the bandwidth used by a CID, specially if the CID is used
for frame mode data defined in [13], or with the SSSAR defined in
[12]. The format of this media attribute line is as follows:
a=aal2CPSSDUrate: <fSDUrate><bSDUrate>
The fSDUrate and bSDUrate are the maximum forward and backward SDU
rates in bits/second. These are represented as decimal integers,
with range as defined in Section 6. If any of these parameters in
these media attribute lines is not specified, is inapplicable or is
implied, then it is set to "-".
5.6.2.11 The 'aal2sscs3661unassured' attribute
When present, the 'aal2sscs3661unassured' attribute is used to
indicate the options that pertain to the unassured transmission SSCS
defined in ITU I.366.1 [12]. This SSCS can be selected via the
aalApp attribute defined below, or by virtue of the presence of the '
aal2sscs3661unassured' attribute. The format of this media attribute
line is as follows:
a=aal2sscs3661unassured: <ted> <rastimer> <fsssar> <bsssar>
Each of these fields can be set to a "-" when the intention is to not
specify them in an SDP descriptor.
The <ted> flag indicates the presence or absence of transmission
error detection as defined in I.366.1. It can be assigned the values
of "on" or "off". An "on" value indicates presence of the
capability.
The <rastimer> subparameter indicates the SSSAR reassembly timer in
microseconds. It is represented as the decimal equivalent of 32
bits.
The <fsssar> and <bsssar> fields are 24-bit integers that can be
represented in decimal or in hex. The meaning and values of the
<fsssar> and <bsssar> fields are as follows:
Field Meaning Values
<fsssar> Maximum SSSAR-SDU size 1- 65,568
forward direction
<bsssar> Maximum SSSAR-SDU size 1- 65,568
backward direction
If present, the SSTED (Service-Specific Transmission Error Detection)
sublayer is above the SSSAR (Service-Specific Segmentation and
Reassembly) sublayer [12]. Since the maximum size of the SSTED-SDUs
can be derived from the maximum SSSAR-SDU size, it need not be
specified separately.
5.6.2.12 The 'aal2sscs3661assured' attribute
When present, the 'aal2sscs3661assured' attribute is used to indicate
the options that pertain to the assured transmission SSCS defined in
ITU I.366.1 [12] on the basis of ITU Q.2110 [43]. This SSCS can be
selected via the aalApp attribute defined below, or by virtue of the
presence of the 'aal2sscs3661assured' attribute. The format of this
media attribute line is as follows:
a=aal2sscs3661assured: <rastimer> <fsssar> <bsssar> <fsscopsdu>
<bsscopsdu><fsscopuu> <bsscopuu>
Each of these fields can be set to a "-" when the intention is to not
specify them in an SDP descriptor.
The <rastimer> subparameter indicates the SSSAR reassembly timer in
microseconds. It is represented as the decimal equivalent of 32
bits.
The <fsssar> and <bsssar> fields are 24-bit integers that can be
represented in decimal or in hex. The <fsscopsdu>, <bsscopsdu>,
<fsscopuu> and <bsscopuu> fields are 16-bit integers that can be
represented in decimal or in hex. The meaning and values of these
fields is as follows:
Field Meaning Values
<fsssar> Maximum SSSAR-SDU size 1- 65,568
forward direction
<bsssar> Maximum SSSAR-SDU size 1- 65,568
backward direction
<fsscopsdu> Maximum SSCOP-SDU size 1- 65,528
forward direction
<bsscopsdu> Maximum SSCOP-SDU size 1- 65,528
backward direction
<fsscopuu> Maximum SSCOP-UU field 1- 65,524
size, forward direction
<bsscopuu> Maximum SSCOP-UU field 1- 65,524
size, backward direction
The SSTED (Service-Specific Transmission Error Detection) sublayer is
above the SSSAR (Service-Specific Segmentation and Reassembly)
sublayer [12]. The SSADT (Service-Specific Assured Data Transfer)
sublayer is above the SSTED sublayer. Since the maximum size of the
SSTED-SDUs and SSADT-SDUs can be derived from the maximum SSSAR-SDU
size, they need not be specified separately.
The SSCOP protocol defined in [43] is used by the Assured Data
Transfer service defined in [12]. In the context of the ITU I.366.1
SSCS, it is possible to use the 'aal2sscs3661assured' attribute to
limit the maximum sizes of the SSCOP SDUs and UU (user-to-user)
fields in either direction. Note that it is necessary for the
parameters on the 'aal2sscs3661assured' media attribute line to be
consistent with each other.
5.6.2.13 The 'aal2sscs3662' attribute
When present, the 'aal2sscs3662' attribute is used to indicate the
options that pertain to the SSCS defined in ITU I.366.2 [13]. This
SSCS can be selected via the aalApp attribute defined below, or by
the presence of the 'aal2sscs3662' attribute.
The format of this media attribute line is as follows:
a=aal2sscs3662: <sap> <circuitMode> <frameMode> <faxDemod>
<cas> <dtmf> <mfall> <mfr1> <mfr2>
<PCMencoding> <fmaxFrame> <bmaxFrame>
Each of these fields can be set to a "-" when the intention is to not
specify them in an SDP descriptor. Additionally, the values of these
fields need to be consistent with each other. Inconsistencies should
be flagged as errors.
The <sap> field can take on the following string values: "AUDIO" and
"MULTIRATE". These correspond to the audio and multirate Service
Access Points (SAPs) defined in ITU I.366.2.
For the multirate SAP, the following parameters on the aal2sscs3662
attribute line do not apply: <faxDemod>,<cas>, <dtmf>, <mfall>,
<mfr1>, <mfr2> and <PCMencoding>. These are set to "-" for the
multirate SAP.
The <circuitMode> flag indicates whether the transport of circuit
mode data is enabled or disabled, corresponding to the string values
of "on" and "off" respectively. For the multirate SAP, it cannot
have a value of "off". For the audio SAP, it can be assigned a value
of "on", "off" or "-". Note that the <sbc> attribute, defined
elsewhere in this document, can be used to specify the number of 64
kbps subchannels bundled into a circuit mode data channel.
The <frameMode> flag indicates whether the transport of frame mode
data is enabled or disabled, corresponding to the string values of
"on" and "off" respectively.
The <faxDemod> flag indicates whether facsimile demodulation and
remodulation are enabled or disabled, corresponding to the string
values of "on" and "off" respectively.
The <cas> flag indicates whether the transport of Channel Associated
Signaling (CAS) bits in AAL2 type 3 packets is enabled or disabled,
corresponding to the string values of "on" and "off" respectively.
The <dtmf> flag indicates whether the transport of DTMF dialled
digits in AAL2 type 3 packets is enabled or disabled, corresponding
to the string values of "on" and "off" respectively.
The <mfall> flag indicates whether the transport of MF dialled digits
in AAL2 type 3 packets is enabled or disabled, corresponding to the
string values of "on" and "off" respectively. This flag enables MF
dialled digits in a generic manner, without specifying type (e.g.,
R1, R2 etc.).
The <mfr1> flag indicates whether the transport, in AAL2 type 3
packets, of MF dialled digits for signaling system R1 is enabled or
disabled, corresponding to the string values of "on" and "off"
respectively.
The <mfr2> flag indicates whether the transport, in AAL2 type 3
packets, of MF dialled digits for signaling system R2 is enabled or
disabled, corresponding to the string values of "on" and "off"
respectively.
The <PCMencoding> field indicates whether PCM encoding, if used, is
based on the A-law or the Mu-law. This can be used to qualify the '
generic PCM' codec stated in some of the AAL2 profiles. The
<PCMencoding> field can take on the string values of "PCMA" and
"PCMU".
The <fmaxFrame> and <bmaxFrame> fields are 16-bit integers that can
be represented in decimal or in hex. The meaning and values of the
<fmaxFrame> and <bmaxFrame> fields are as follows:
Field Meaning Values
<fmaxFrame> Maximum length of a 1- 65,535
frame mode data unit,
forward direction
<bmaxFrame> Maximum length of a 1- 65,535
frame mode data unit,
backward direction
5.6.2.14 The 'aal5sscop' attribute
When present, the 'aal5sscop' attribute is used to indicate the
existence of an SSCOP [43] protocol layer over an AAL5 CPS layer
[21], and the parameters which pertain to this SSCOP layer. SSCOP
over AAL5 can also be selected via the aalApp attribute defined
below. The format of the 'aal5sscop' media attribute line is as
follows:
a=aal5sscop: <fsscopsdu> <bsscopsdu> <fsscopuu> <bsscopuu>
Each of these fields can be set to a "-" when the intention is to not
specify them in an SDP descriptor.
The representation, meaning and values of the <fsscopsdu>,
<bsscopsdu>, <fsscopuu> and <bsscopuu> fields are identical to those
for the 'aal2sscs3661assured' media attribute line (Section
5.6.2.12). Note that it is necessary for the parameters on the '
aal5sscop' media attribute line to be consistent with each other.
5.6.3 Service attributes
The following is a summary list of the SDP media attributes that can
be used to describe the services that use the ATM Adaptation Layer
(AAL). These attributes are detailed in subsequent subsections.
* The 'atmmap' attribute. In the AAL1 and AAL5 contexts, this is
used to dynamically map payload types into codec strings.
* The 'silenceSupp' attribute, used to indicate the use of of
voice activity detection for silence suppression, and to
optionally parameterize the silence suppression function.
* The 'ecan' attribute, used to indicate the use of of echo
cancellation, and to parameterize the this function.
* The 'gc' attribute, used to indicate the use of of gain
control, and to parameterize the this function.
* 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 indicates a prioritized list of 3-
tuples for voice service. Each 3-tuple indicates a codec, an
optional packet length and an optional packetization period.
This complements the 'm' line information and should be
consistent with it.
* The 'dsel' attribute, which indicates a prioritized list of 3-
tuples for voiceband data service. Each 3-tuple indicates a
codec, an optional packet length and an optional packetization
period. This complements the 'm' line information and should
be consistent with it.
* The 'fsel' attribute, which indicates a prioritized list of 3-
tuples for facsimile service. Each 3-tuple indicates a codec,
an optional packet length and an optional packetization period.
This complements the 'm' line information and should be
consistent with it.
* The 'onewaySel' attribute, which indicates a prioritized list
of 3-tuples for one direction of an asymmetric connection.
Each 3-tuple indicates a codec, an optional packet length and
an optional packetization period. This complements the 'm'
line information and should be consistent with it.
* The 'codecconfig' attribute, which is used to represent the
contents of the single codec information element (IE) defined
in ITU Q.765.5 [57].
* The 'isup_usi' attribute which is used to represent the bearer
capability information element defined in Section 4.5.5 of ITU
Q.931 [59], and reiterated as the user service information
element (IE) in Section 3.57 of ITU Q.763 [60].
* The 'uiLayer1_Prot' attribute, which is used to represent the '
User Information Layer 1 protocol' field within the bearer
capability information element defined in Section 4.5.5 of ITU
Q.931 [59].
5.6.3.1 The 'atmmap' attribute
The 'atmmap' attribute is defined on the basis of the 'rtpmap'
attribute used in RFC2327.
a=atmmap:<payloadType> <encodingName>
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 [31]. Payload
types and encoding techniques that have been registered with IANA for
RTP are retained for AAL1 and AAL5.
The range of statically defined payload types is in the range 0-95.
All static assignments of payload types to codecs are listed in [31].
The range of payload types defined dynamically via the 'atmmap'
attribute is 96-127.
In addition to reiterating the payload types and encoding names in
[31], Table 2 defines non-standard encoding names (with "X-"
prefixes). Note that [31], rather than Table 2, is the authoritative
list of standard codec names and payload types in the ATM context.
Table 2: 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 |
|---------------------|--------------|---------------------------|
| 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-G727-16" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 24 kbps EADPCM | "X-G727-24" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 32 kbps EADPCM | "X-G727-32" | None, map dynamically |
|---------------------|--------------|---------------------------|
|n x 64 kbps Clear | "X-CCD" | None, map dynamically |
|Channel without CAS | | |
|per af-vtoa-78 [7] | | |
|---------------------|--------------|---------------------------|
|n x 64 kbps Clear | "X-CCD-CAS" | None, map dynamically |
|Channel with CAS | | |
|per af-vtoa-78 [7] | | |
|---------------------|--------------|---------------------------|
|GSM Full Rate | "GSM" | 3 (Statically Mapped) |
|---------------------|--------------|---------------------------|
|GSM Half Rate | "GSM-HR" | None, map dynamically |
|---------------------|--------------|---------------------------|
|GSM-Enhanced Full Rate "GSM-EFR" | None, map dynamically |
|---------------------|--------------|---------------------------|
|GSM-Enhanced Half Rate "GSM-EHR" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Group 3 fax demod. | "X-FXDMOD-3" | None, map dynamically |
|---------------------|--------------|---------------------------|
| Federal Standard | "1016" | 1 (Statically Mapped) |
| FED-STD 1016 CELP | | |
|---------------------|--------------|---------------------------|
| DVI4, 8 KHz [3] | "DVI4" | 5 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| DVI4, 16 KHz [3] | "DVI4" | 6 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| LPC [3], Linear | "LPC" | 7 (Statically Mapped) |
| Predictive Coding | | |
|---------------------|--------------|---------------------------|
| L16 [3], Sixteen | "L16" | 10 (Statically Mapped) |
| Bit Linear PCM, | | |
| Double channel | | |
|---------------------|--------------|---------------------------|
| L16 [3], Sixteen | "L16" | 11 (Statically Mapped) |
| Bit Linear PCM, | | |
| Single channel | | |
|---------------------|--------------|---------------------------|
| QCELP [3] | "QCELP" | 12 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| MPEG1/MPEG2 audio | "MPA" | 14 (Statically Mapped) |
|---------------------|--------------|---------------------------|
+---------------------+--------------+---------------------------+
| DVI4, 11.025 KHz[3] | "DVI4" | 16 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| DVI4, 22.05 KHz [3] | "DVI4" | 17 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| MPEG1/MPEG2 video | "MPV" | 32 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| MPEG 2 audio/video | "MP2T" | 33 (Statically Mapped) |
| transport stream | | |
|---------------------|--------------|---------------------------|
| ITU H.261 video | "H261" | 31 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| ITU H.263 video | "H263" | 33 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| ITU H.263 video |"H263-1998" | None, map dynamically |
| 1998 version | | |
|---------------------|--------------|---------------------------|
|MPEG 1 system stream | "MP1S" | None, map dynamically |
|---------------------|--------------|---------------------------|
|MPEG 2 program stream| "MP2P" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Redundancy | "RED" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Variable rate DVI4 | "VDVI" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Cell-B | "CelB" | 25 |
|---------------------|--------------|---------------------------|
|JPEG | "JPEG" | 26 |
|---------------------|--------------|---------------------------|
|nv | "nv" | 28 |
|---------------------|--------------|---------------------------|
|L8, Eight Bit Linear | "L8" | None, map dynamically |
|PCM | | |
|---------------------|--------------|---------------------------|
| ITU-R Recommendation| "BT656" | None, map dynamically |
| BT.656-3 for | | |
| digital video | | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "FR-AMR" | None, map dynamically |
|-Full Rate (3GPP)[58]| | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "HR-AMR" | None, map dynamically |
|-Half Rate (3GPP)[58]| | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "UMTS-AMR" | None, map dynamically |
|- UMTS(3GPP) [58] | | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "AMR" | None, map dynamically |
|- Generic [58] | | |
|---------------------|--------------|---------------------------|
5.6.3.2 The 'silenceSupp' attribute
When present, the 'silenceSupp' attribute is used to indicate the use
or non-use of silence suppression. The format of the 'silenceSupp'
media attribute line is as follows:
a=silenceSupp: <silenceSuppEnable> <silenceTimer> <suppPref> <sidUse>
<fxnslevel>
If any of the parameters in the silenceSupp media attribute line is
not specified, is inapplicable or is implied, then it is set to "-".
The <silenceSuppEnable> can take on values of "on" or "off". If it
is "on", then silence suppression is enabled.
The <silenceTimer> is a 16-bit field which can be represented in
decimal or hex. Each increment (tick) of this timer represents a
millisecond. The maximum value of this timer is between 1 and 3
minutes. This timer represents the time-lag before silence
suppression kicks in. Even though this can, theoretically, be as low
as 1 ms, most DSP algorithms take more than that to detect silence.
Setting <silenceTimer> to a large value (say 1 minute> is equivalent
to disabling silence suppression within a call. However, idle
channel suppression between calls on the basis of silence suppression
is still operative in non-switched, trunking applications if
<silenceSuppEnable> = "on" and <silenceTimer> is a large value.
The <suppPref> specifies the preferred silence suppression method
that is preferred or already selected. It can take on the string
values of "standard" and "custom". If its value is "standard", then
a standard method (e.g., ITU-defined) is preferred to custom methods
if such a standard is defined. Otherwise, a custom method may be
used. If <suppPref> is set to "custom", then a custom method, if
available, is preferred to the standard method.
The <sidUse> indicates whether SIDs (Silence Insertion Descriptors)
are to be used, and whether they use fixed comfort noise or sampled
background noise. It can take on the string values of "No SID",
"Fixed Noise", "Sampled Noise".
If the value of <sidUse> is "Fixed Noise", then <fxnslevel> provides
its level. It can take on integer values in the range 0-127, as
follows:
+-----------------------+---------------------+
| <fxnslevel> value | Meaning |
+-----------------------+---------------------+
| 0-29 | Reserved |
| 30 | -30 dBm0 |
| 31 | -31 dBm0 |
| . . . | . . . |
| 77 | -77 dBm0 |
| 78 | -78 dBm0 |
| 79-126 | reserved |
| 127 | Idle Code (no noise)|
+-----------------------+---------------------+
In addition to the decimal representation of <fxnslevel>, a hex
representation, preceded by a "0x" prefix, is also allowed.
5.6.3.3 The 'ecan' attribute
When present, the 'ecan' attribute s is used to indicate the use or
non-use of echo cancellation. There can be several 'ecan' lines in
an SDP description.
The format of the 'ecan' media attribute line is as follows:
a=ecan:<directionFlag><ecanEnable><ecanType>
The <directionFlag> can be assigned the following string values: "f",
"b" and "fb". "f" and "b" indicate the forward and backward
directions respectively. "fb" refers to both directions (forward and
backward). Conventions for the forward and backward directions are
per section 2.3.
The <directionFlag> is always specified. Except for the
<directionFlag>, the remaining parameters can be set to "-" to
indicate that they are not specified, inapplicable or implied.
However, there must be some specified parameters for the line to be
useful in an SDP description.
If the 'ecan' media attribute lines is not present, then means other
than the SDP descriptor must be used to determine the applicability
and nature of echo cancellation for a connection direction. Examples
of such means are MIB provisioning, the local connection options
structure in MGCP etc.
The <ecanEnable> parameter can take on values of "on" or "off". If
it is "on", then echo cancellation is enabled. If it is "off", then
echo cancellation is disabled.
The <ecanType> parameter can take on the string values "G165" and
"G168" respectively.
When SDP is used with some media gateway control protocols such as
MGCP and Megaco [26], there exist means outside SDP descriptions to
specify the echo cancellation properties of a connection.
Nevertheless, this media attribute line is included for completeness.
As a result, the SDP can be used for describing echo cancellation in
applications where alternate means for this are unavailable.
5.6.3.4 The 'gc' attributes
When present, the 'gc' attribute is used to indicate the use or non-
use of gain control. There can be several 'gc' lines in an SDP
description.
The format of the 'gc' media attribute line is as follows:
a=gc:<directionFlag><gcEnable><gcLvl>
The <directionFlag> can be assigned the following string values: "f",
"b" and "fb". "f" and "b" indicate the forward and backward
directions respectively. "fb" refers to both directions (forward and
backward). Conventions for the forward and backward directions are
per section 2.3.
The <directionFlag> is always specified. Except for the
<directionFlag>, the remaining parameters can be set to "-" to
indicate that they are not specified, inapplicable or implied.
However, there must be some specified parameters for the line to be
useful in an SDP description.
If the 'gc' media attribute lines is not present, then means other
than the SDP descriptor must be used to determine the applicability
and nature of gain control for a connection direction. Examples of
such means are MIB provisioning, the local connection options
structure in MGCP etc.
The <gcEnable> parameter can take on values of "on" or "off". If it
is "on", then gain control is enabled. If it is "off", then gain
control is disabled.
The <gcLvl> parameter is represented as the decimal or hex equivalent
of a 16-bit binary field. A value of 0xFFFF implies automatic gain
control. Otherwise, this number indicates the number of decibels of
inserted loss. The upper bound, 65,535 dB (0xFFFE) of inserted loss,
is a large number and is a carryover from Megaco [26]. In practical
applications, the inserted loss is much lower.
When SDP is used with some media gateway control protocols such as
MGCP and Megaco [26], there exist means outside SDP descriptions to
specify the gain control properties of a connection. Nevertheless,
this media attribute line is included for completeness. As a result,
the SDP can be used for describing gain control in applications where
alternate means for this are unavailable.
5.6.3.5 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: <aal2transport> <profile> <uuiCodeRange#1>
<encodingName#1> <packetLength#1> <packetTime#1>
<uuiCodeRange#2> <encodingName#2> <packetLength#2>
<packetTime#2>... <uuiCodeRange#N> <encodingName#N>
<packetLength#N> <packetTime#N>
Here, <aal2transport> can have those values of <transport> (Table 1)
that pertain to AAL2. These are:
AAL2/ATMF
AAL2/ITU
AAL2/custom
AAL2/<corporateName>
AAL2/IEEE:<oui>
The parameter <profile> is identical to its definition for the 'm'
line (Section 5.5.4).
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 <uuiCodeRange> parameter is represented by D1-D2, where D1 and D2
are decimal integers in the range 0 through 15.
The <encodingName> parameter can take one of the values in column 2
of Table 2. 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 <packetLength> is a decimal integer representation of the AAL2
packet length in octets.
The <packetTime> is a decimal integer representation of the AAL2
packetization interval in microseconds.
For instance, the 'profileDesc' media attribute line below defines
the AAL2/custom 100 profile. This profile is reproduced in the Table
3 below. For a description of the parameters in this profile such as
M and the sequence number interval, see ITU I.366.2 [13].
a=profileDesc:AAL2/custom 100 0-7 PCMG 40 5000 0-7 SIDG 1 5000 8-15
G726-32 40 10000 8-15 SIDG 1 5000
If the <packetTime> 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.
Table 3: Example of a custom AAL2 profile
|---------------------------------------------------------------|
| 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 | | | | |
|------|--------|---------|---------------|-----|------|--------|
5.6.3.6 The 'vsel' attribute
The 'vsel' attribute indicates a prioritized list of one or more 3-
tuples for voice service. Each 3-tuple indicates a codec, an
optional packet length and an optional packetization period. This
complements the 'm' line information and should be consistent with
it.
The 'vsel' attribute refers to all directions of a connection. For a
bidirectional connection, these are the forward and backward
directions. For a unidirectional connection, this can be either the
backward or forward direction.
The 'vsel' attribute is not meant to be used with bidirectional
connections that have asymmetric codec configurations described in a
single SDP descriptor. For these, the 'onewaySel' attribute (section
5.6.3.9) should be used. See section 5.6.3.9 for the requirement to
not use the 'vsel' and 'onewaySel' attributes in the same SDP
descriptor.
The 'vsel' line is structured as follows:
a=vsel:<encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>
where the <encodingName> parameter can take one of the values in
column 2 of Table 2. The <packetLength> is a decimal integer
representation of the packet length in octets. The <packetTime> is a
decimal integer representation of the packetization interval in
microseconds. The parameters <packetLength> and <packetTime> 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 10000 G726-32 40 10000
indicates first preference 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 associated with this
codec. G726-32 is the second preference stated in this line, with an
associated packet length of 40 octets and a packetization interval of
10 ms. If the packet length and packetization interval are intended
to be omitted, then this media attribute line becomes
a=vsel:G729 - - G726-32 - -
The media attribute line
a=vsel:G726-32 40 10000
indicates preference for or selection of 32 kbps ADPCM with a packet
length of 40 octets and a packetization interval of 10 ms.
This media attribute line can be used in ATM as well as non-ATM
contexts. Within the ATM context, it can be applied to the AAL1,
AAL2 and AAL5 adaptations. The <packetLength> and <packetTime> are
not meaningful in the AAL1 case and should be set to "-". In the
AAL2 case, this line determines the use of some or all of the rows in
a given profile table. If multiple 3-tuples are present, they can
indicate a hierarchical assignment of some rows in that profile to
voice service (e.g., row A preferred to row B etc.). If multiple
profiles are present on the 'm' line, the profile qualified by this
attribute is the first profile. If a single profile that has been
selected for a connection is indicated in the 'm' line, the 'vsel'
attribute qualifies the use, for voice service, of codecs within that
profile.
With most of the encoding names in Figure 2, the packet length and
packetization period can be derived from each other. One of them can
be set to "-" without a loss of information. There are some
exceptions such as the IANA-registered encoding names G723, DVI4 and
L16 for which this is not true. Therefore, there is a need to retain
both the packet length and packetization period in the definition of
the 'vsel' line.
5.6.3.7 The 'dsel' attribute
The 'dsel' attribute indicates a prioritized list of one or more 3-
tuples for voiceband data service. The <fxIncl> flag indicates
whether this definition of voiceband data includes fax ("on" value)
or not ("off" value). If <fxIncl> is "on", then the 'dsel' line must
be consistent with any 'fsel' line in the session description. In
this case, an error event is generated in the case of inconsistency.
Each 3-tuple indicates a codec, an optional packet length and an
optional packetization period. This complements the 'm' line
information and should be consistent with it.
The 'dsel' attribute refers to all directions of a connection. For a
bidirectional connection, these are the forward and backward
directions. For a unidirectional connection, this can be either the
backward or forward direction.
The 'dsel' attribute is not meant to be used with bidirectional
connections that have asymmetric codec configurations described in a
single SDP descriptor. For these, the 'onewaySel' attribute (section
5.6.3.9) should be used. See section 5.6.3.9 for the requirement to
not use the 'dsel' and 'onewaySel' attributes in the same SDP
descriptor.
The 'dsel' line is structured as follows:
a=dsel:<fxIncl> <encodingName #1> <packetLength #1><packetTime #1>