Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3108

Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections

Pages: 110
Proposed Standard
Errata
Part 3 of 4 – Pages 58 to 82
First   Prev   Next

Top   ToC   RFC3108 - Page 58   prevText

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.
Top   ToC   RFC3108 - Page 59
      *  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].
Top   ToC   RFC3108 - Page 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) | |
Top   ToC   RFC3108 - Page 61
      |---------------------|--------------|---------------------------|
      | 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]   |              |                           |
      |---------------------|--------------|---------------------------|
Top   ToC   RFC3108 - Page 62
      |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)  |
      |---------------------|--------------|---------------------------|
Top   ToC   RFC3108 - Page 63
      | 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>
Top   ToC   RFC3108 - Page 64
   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)|
         +-----------------------+---------------------+
Top   ToC   RFC3108 - Page 65
   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.
Top   ToC   RFC3108 - Page 66
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.
Top   ToC   RFC3108 - Page 67
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].
Top   ToC   RFC3108 - Page 68
   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.
Top   ToC   RFC3108 - Page 69
   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.
Top   ToC   RFC3108 - Page 70
   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.
Top   ToC   RFC3108 - Page 71
   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.
Top   ToC   RFC3108 - Page 72
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
Top   ToC   RFC3108 - Page 73
   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
Top   ToC   RFC3108 - Page 74
   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
Top   ToC   RFC3108 - Page 75
   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
Top   ToC   RFC3108 - Page 76
   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:
Top   ToC   RFC3108 - Page 77
   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 stuffing

5.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
Top   ToC   RFC3108 - Page 78
   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.).
Top   ToC   RFC3108 - Page 79
                            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.
Top   ToC   RFC3108 - Page 80
   (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.
Top   ToC   RFC3108 - Page 81
        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
Top   ToC   RFC3108 - Page 82
   (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)

Next Section