RFC 3108
Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections
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 RFC 2327.
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>
<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> and <packetTime> parameters
are per their definition, above, for the 'vsel' media attribute line.
The parameters <packetLength> and <packetTime>) can be set to "-"
when not needed. The <fxIncl> flag is presumed to be "off" if it is
set to "-". Also, the entire 'dsel' media attribute line can be
omitted when not needed.
For example,
a=dsel:- G726-32 20 5000 PCMU 40 5000
indicates that this line does not address facsimile, and that the
first preference for the voiceband data codes is 32 kbps ADPCM, while
the second preference is PCMU. The packet length and the
packetization interval associated with G726-32 are 20 octets and 5 ms
respectively. For PCMU, they are 40 octets and 5 ms respectively.
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
voiceband data 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 '
dsel' attribute qualifies the use, for voiceband data 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 'dsel' line.
5.6.3.8 The 'fsel' attribute
The 'fsel' attribute indicates a prioritized list of one or more 3- tuples for facsimile service. If an 'fsel' line is present, any ' dsel' line with <fxIncl> set to "on" in the session description must be consistent with it. 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 'fsel' 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 'fsel' 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 'fsel' and 'onewaySel' attributes in the same SDP descriptor. The 'fsel' line is structured as follows: a=fsel:<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> and <packetTime> parameters are per their definition, above, for the 'vsel' media attribute line. The parameters <packetLength> and <packetTime> 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. a=fsel:PCMU 40 5000 G726-32 20 5000
indicates a first and second preference of Mu-law PCM and 32 kbps ADPCM as the facsimile encoding scheme. The packet length and the packetization interval associated with G726-32 are 20 octets and 5 ms respectively. For PCMU, they are 40 octets and 5 ms respectively. 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 facsimile 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 'fsel' attribute qualifies the use, for facsimile 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 'fsel' line.5.6.3.9 The 'onewaySel' attribute
The 'onewaySel' (one way select) attribute can be used with connections that have asymmetric codec configurations. There can be several 'onewaySel' lines in an SDP description. The 'onewaySel' line is structured as follows: a=onewaySel:<serviceType> <directionFlag> <encodingName #1> <packetLength #1><packetTime #1> <encodingName #2> <packetLength #2><packetTime #2> ... <encodingName #N> <packetLength #N><packetTime #N> The <serviceType> parameter can be assigned the following string values: "v", "d", "f", "df" and "all". These indicate voice, voiceband data (fax not included), fax, voiceband data (fax included) and all services respectively. 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) and shall not be used with the 'onewaySel' line. Conventions for the forward and backward directions are per section 2.3. Following <directionFlag>, there is a prioritized list of one or more 3-tuples. 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. Within each 3-tuple, 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 'onewaySel' attribute must not be used in SDP descriptors that have one or more of the following attributes: 'vsel', 'dsel', 'fsel'. If it is present, then command containing the SDP description may be rejected. An alternate response to such an ill-formed SDP descriptor might the selective ignoring of some attributes, which must be coordinated via an application-wide policy. The <serviceType>, <directionFlag> and <encodingName> parameters may not be set to "-". However, the parameters <packetLength> and <packetTime> can be set to "-" when not needed. For example, a=onewaySel:v f G729 10 10000 a=onewaySel:v b G726-32 40 10000 indicates that for voice service, the codec to be used in the forward direction is G.729 or G.729a (both are interoperable), and the codec to be used in the backward direction is G726-32. A packet length of 10 octets and a packetization interval of 10 ms are associated with the G.729/G.729a codec. A packet length of 40 octets and a packetization interval of 10 ms are associated with the G726-32 codec. For example, a=onewaySel:d f G726-32 20 5000 a=onewaySel:d b PCMU 40 5000 indicates that for voiceband service (fax not included), the codec to be used in the forward direction is G726-32), and the codec to be used in the backward direction is PCMU. A packet length of 20 octets
and a packetization interval of 5 ms are associated with the G726-32 codec. A packet length of 40 octets and a packetization interval of 5 ms are associated with the PCMU codec. 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, these lines determine 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. 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 'onewaySel' line.5.6.3.10 The 'codecconfig' attribute
When present, the 'codecconfig' attribute is used to represent the contents of the single codec information element (IE) defined in [57]. The contents of this IE are: a single-octet Organizational Identifier (OID) field, followed by a single-octet Codec Type field, followed by zero or more octets of a codec configuration bit-map. The semantics of the codec configuration bit-map are specific to the organization [57, 58]. The 'codecconfig' attribute is represented as follows: a=codecconfig:<q7655scc> The <q7655scc> (Q.765.5 single codec IE contents) parameter is represented as a string of hex digits. The number of hex digits is even (range 4 -32). The "0x" prefix shall be omitted since this value is always hexadecimal. As with other hex values [Section 2.2], digits to the left are more significant than digits to the right. Leading zeros shall not be omitted. An example of the use of this media attribute is: a=codecconfig:01080C
The first octet indicates an Organizational Identifier of 0x01 (the ITU-T). Using ITU Q.765.5 [57], the second octet (0x08) indicates a codec type of G.726 (ADPCM). The last octet, 0x0C indicates that 16 kbps and 24 kbps rates are NOT supported, while the 32 kbps and 40 kbps rates ARE supported.5.6.3.11 The 'isup_usi' attribute
When present, the 'isup_usi' attribute is used to represent the bearer capability information element defined in Section 4.5.5 of ITU Q.931 [59] (excluding the information element identifier and length). This information element is reiterated as the user service information element (IE) in Section 3.57 of ITU Q.763 [60]. The ' isup_usi' attribute is represented as follows: a=isup_usi:<isupUsi> The <isupUsi> parameter is represented as a string of hex digits. The number of hex digits is even (allowed range 4 -24). The "0x" prefix shall be omitted since this value is always hexadecimal. As with other hex values [Section 2.2], digits to the left are more significant than digits to the right. Leading zeros shall not be omitted.5.6.3.12 The 'uiLayer1_Prot' attribute
When present, the 'uiLayer1_Prot' attribute is used to represent the 'User Information Layer 1 protocol' field within the bearer capability information element defined in Section 4.5.5 of [59], and reiterated as the user service information element (IE) in Section 3.57 of [60]. The 'User Information Layer 1 protocol' field consists of the five least significant bits of Octet 5 of this information element. Within SDP, the 'uiLayer1_Prot' attribute is represented as follows: a='uiLayer1_Prot':<uiLayer1Prot> The <uiLayer1Prot> parameter is represented as a string of two hex digits. The "0x" prefix shall be omitted since this value is always hexadecimal. As with other hex values [Section 2.2], digits to the left are more significant than digits to the right. These hex digits are constructed from an octet with three leading '0' bits and last five bits equal to the 'User Information Layer 1 protocol' field described above. As specified in [59] and [26], bit 5 of this field is the most significant bit. The resulting values of the <uiLayer1Prot> parameter are as follows:
VALUE MEANING 0x01 CCITT standardized rate adaption V.110 and X.30 0x02 Recommendation G.711 Mu-law 0x03 Recommendation G.711 A-law 0x04 Recommendation G.721 32 kbps ADPCM and Recommendation I.460 0x05 Recommendations H.221 and H.242 0x06 Recommendation H.223 and H.245 0x07 Non-ITU-T standardized rate adaption 0x08 ITU-T standardized rate adaption V.120 0x09 CCITT standardized rate adaption X.31 HDLC flag stuffing5.6.4 Miscellaneous media attributes
The 'chain' media attribute line, which is used to chain consecutive SDP descriptions, cannot be classified as an ATM, AAL or service attribute. It is detailed in the following subsection.5.6.4.1 The 'chain' attribute
The start of an SDP descriptor is marked by a 'v' line. In some applications, consecutive SDP descriptions are alternative descriptions of the same session. In others, these describe different layers of the same connection (e.g., IP, ATM, frame relay). This is useful when these connectivity at these layers are established at the same time (e.g., an IP-based session over an ATM SVC). To distinguish between the alternation and concatenation of SDP descriptions, a 'chain' attribute can be used in the case of concatenation. When present, the 'chain' attribute binds an SDP description to the next or previous SDP description. The next or previous description is separated from the current one by a 'v' line. It is not necessary that this description also have a 'chain' media attribute line. Chaining averts the need to set up a single SDP description for a session that is simultaneously created at multiple layers. It allows the SDP descriptors for different layers to remain simple and clean. Chaining is not needed in the Megaco context, where it is possible to create separate terminations for the different layers of a connection. The 'chain' media attribute line has the following format: a=chain:<chainPointer> The <chainPointer> field can take on the following string values: "NEXT", "PREVIOUS" and "NULL". The value "NULL" is not equivalent to omitting the chain attribute from a description since it expressly
precludes the possibility of chaining. If the 'chain' attribute is absent in an SDP description, chaining can still be realized by the presence of a chain media attribute line in the previous or next description.5.6.5 Use of the second media-level part in H.323 Annex C applications
Section 4 mentions that H.323 annex C applications have a second media level part for the ATM session description. This is used to convey information about the RTCP stream. Although the RTP stream is encapsulated in AAL5 with no intervening IP layer, the RTCP stream is sent to an IP address and RTCP port. This media-level part has the following format: m= control <rtcpPortNum> H323c - c= IN IP4 <rtcpIPaddr> Consistency with RFC 2327 is maintained in the location and format of these lines. The <fmt list> in the 'm' line is set to "-". The 'c' line in the second media-level part pertains to RTCP only. The <rtcpPortNum> and <rtcpIPaddr> subparameters indicate the port number and IP address on which the media gateway is prepared to receive RTCP packets. Any of the subparameters on these lines can be set to "-" if they are known by other means. The range and format of the <rtcpPortNum> and <rtcpIPaddr> subparameters is per [1]. The <rtcpPortNum> is a decimal number between 1024 and 65535. It is an odd number. If an even number in this range is specified, the next odd number is used. The <rtcpIPaddr> is expressed in the usual dotted decimal IP address representation, from 0.0.0.0 to 255.255.255.255.5.6.6 Use of the eecid media attribute in call establishment procedures
This informative section supplements the definition of the eecid attribute (Section 5.6.1.1) by describing example procedures for its use. These procedures assume a bearer-signaling mechanism for connection set-up that is independent of service-level call control. These procedures are independent of the media gateway control protocol (MGCP, Megaco, SIP etc.), the protocol used between media gateway controllers (ITU Q.1901, SIP etc.) and the protocol used for bearer connection set-up (Q.2931, UNI, PNNI, AINI, IISP, Q.2630.1 etc.).
Inter-MGC
+---------+ Protocol +---------+
| MGC |------------------| MGC |
+---------+ +---------+
| |
|Media Gateway |Media Gateway
|Control Protocol |Control Protocol
| |
+------------+ (ATM Network) +------------+
|Originating |------------------|Terminating |
|Media | Bearer Setup |Media |
|Gateway | Protocol |Gateway |
+------------+ +------------+
In the diagram above, the originating media gateway originates the
service-level call. The terminating media gateway terminates it. In
the forward bearer connection set-up model, the originating media
gateway initiates bearer connection set-up. In the backward bearer
connection set-up model, the terminating gateway initiates bearer
connection set-up.
Example use of the Backward Bearer Connection Set-up Model:
(1) The originating media gateway controller (OMGC) initiates
service-level call establishment by sending the appropriate
control message to the originating media gateway (OMG).
(2) The originating media gateway (OMG) provides its NSAP address
and an eecid value to the OMGC, using the following SDP
description:
v=0
o=- 2873397496 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
a=eecid:B3D58E32
(3) The originating media gateway controller (OMGC) signals the
terminating media gateway controller (TMGC) through the
appropriate mechanism (ISUP with Q.1901 extensions, SIP etc.).
It provides the TMGC with the NSAP address and the eecid
provided by the OMG.
(4) The TMGC sends the appropriate control message to the TMG. This
includes the session descriptor received from the OMG. This
descriptor contains the NSAP address of the OMG and the EECID
assigned by the OMG. Additionally, the TMGC instructs the TMG
to set up an SVC to the OMG. It also requests the TMG to notify
the TMGC when SVC set-up is complete. Depending on the control
protocol used, this can be done through a variety of means. In
the Megaco context, the request to set-up an SVC (not the
notification request for the SVC set-up event) can be made
through the following local descriptor:
v=0
o=- 2873397497 0 ATM - -
s=-
c=ATM - -
t=0 0
m=audio $ - -
a=bearerType:SVC on
The 'bearerType' attribute indicates that an SVC is to be used and
that the <localInitiation> flag is on i.e., the SVC is to be set up
by the TMG.
(5) The TMG acknowledges the control message from the TMGC. It
returns the following SDP descriptor with the acknowledge:
v=0
o=- 2873397498 0 ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
s=-
c=ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
t=0 0
m=audio $ AAL2/ITU 8
The NSAP address information provided in this descriptor is not
needed. It can be omitted (by setting it to "- -").
(6) The TMG sends an SVC set-up message to the OMG. Within the GIT
information element, it includes eecid (B3D58E32) received from
the OMG.
(7) The OMG uses the eecid to correlate the SVC set-up request with
service-level control message received before from the OMGC.
(8) The OMG returns an SVC connect message to the TMG. On receiving
this message, the TMG sends an event notification to the TMGC
indicating successful SVC set-up.
Note that, for this example, the "v=", "o=", "s=" and "t=" lines
can be omitted in the Megaco context.
Example use of the Forward Bearer Connection Set-up Model:
(1) The originating media gateway controller (OMGC) initiates
service-level call establishment by sending the appropriate
controlsmessage to the originating media gateway (OMG).
(2) The originating media gateway (OMG) provides its NSAP address to
the OMGC, using the following SDP description:
v=0
o=- 2873397496 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
The NSAP address information provided in this descriptor is not
needed. It can be omitted (by setting it to "- -").
(3) The originating media gateway controller (OMGC) signals the
terminating media gateway controller (TMGC) through the
appropriate mechanism (ISUP with Q.1901 extensions, SIP etc.).
Although this is not necessary, it can provide the TMGC with the
NSAP address provided by the OMG.
(4) The TMGC sends the appropriate control message to the TMG. This
includes the session descriptor received from the OMG. This
descriptor contains the NSAP address of the OMG.
(5) The TMG acknowledges the control message from the TMGC. Along
with the acknowledgement, it provides an SDP descriptor with a
locally assigned eecid.
v=0
o=- 2873397714 0 ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
s=-
c=ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
t=0 0
m=audio $ AAL2/ITU 8
a=eecid:B3D58E32
(6) The terminating media gateway controller (TMGC) signals the
originating media gateway controller (OMGC) through the
appropriate mechanism (ISUP with Q.1901 extensions, SIP etc.).
It provides the OMGC with the NSAP address and the eecid
provided by the TMG.
(7) The OMGC sends the appropriate control message to the OMG. This
includes the session descriptor received from the TMG. This
descriptor contains the NSAP address of the TMG and the EECID
assigned by the TMG. Additionally, the OMGC instructs the OMG
to set up an SVC to the TMG. It also requests the OMG to notify
the OMGC when SVC set-up is complete. Depending on the control
protocol used, this can be done through a variety of means. In
the Megaco context, the request to set-up an SVC (not the
notification request for the SVC set-up event) can be made
through the following local descriptor:
v=0
o=- 2873397874 0 ATM - -
s=-
c=ATM - -
t=0 0
m=audio $ - -
a=bearerType:SVC on
The 'bearerType' attribute indicates that an SVC is to be used and
that the <localInitiation> flag is on i.e., the SVC is to be set up
by the TMG.
(8) The OMG acknowledges the control message from the OMGC.
(9) The OMG sends an SVC set-up message to the TMG. Within the GIT
information element, it includes eecid (B3D58E32) received from
the TMG.
(10) The TMG uses the eecid to correlate the SVC set-up request with
the service-level control message received before from the TMGC.
(11) The TMG returns an SVC connect message to the OMG. On receiving
this message, the OMG sends an event notification to the OMGC
indicating successful SVC set-up.
Note that, for this example, the "v=", "o=", "s=" and "t="
lines can be omitted in the Megaco context.
(next page on part 4)
