tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3108

 
 
 

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

Part 3 of 4, p. 58 to 82
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 58 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part