path: root/doc/rfc/rfc3660.txt

Network Working Group                                          B. Foster
Request for Comments: 3660                                  F. Andreasen
Updates: 2705                                              Cisco Systems
Category: Informational                                    December 2003


         Basic Media Gateway Control Protocol (MGCP) Packages

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

IESG Note

   This document is being published for the information of the
   community.  It describes a non-IETF protocol that is currently being
   deployed in a number of products.  Implementers should be aware of
   RFC 3525 [37], which was developed in the IETF Megaco Working Group
   and the ITU-T SG16, and is considered by the IETF and ITU-T to be the
   standards-based (including reviewed security considerations) way to
   meet the needs that MGCP was designed to address.  The IETF Megaco
   Working Group and the ITU-T Study Group 16 are developing extensions
   to RFC 3525 [37] that for functions of the type in addressed in this
   document.

Abstract

   This document provides a basic set of Media Gateway Control Protocol
   (MGCP) packages.  The generic, line, trunk, handset, RTP, DTMF (Dual
   Tone Multifrequency), announcement server and script packages are
   updates of packages from RFC 2705 with additional explanation and in
   some cases new versions of these packages.  In addition to these,
   five new packages are defined here.  These are the signal list,
   resource reservation, media format, supplementary services and digit
   map extension packages.










Foster & Andreasen           Informational                      [Page 1]
^L
RFC 3660                  Basic MGCP Packages              December 2003


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  List of Packages . . . . . . . . . . . . . . . . . . . .  3
       1.2.  Changes to Existing RFC 2705 Packages. . . . . . . . . .  3
             1.2.1.  Change in Signal Types . . . . . . . . . . . . .  3
             1.2.2.  Operation Complete and Operation Failure . . . .  3
             1.2.3.  Package Versions . . . . . . . . . . . . . . . .  4
             1.2.4.  Event Definitions, Aliases and Interoperability
                     Issues . . . . . . . . . . . . . . . . . . . . .  4
             1.2.5.  New Events . . . . . . . . . . . . . . . . . . .  5
       1.3.  New Packages and Excluded Packages . . . . . . . . . . .  5
   2.  Packages . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
       2.1.  Generic Media Package. . . . . . . . . . . . . . . . . .  7
       2.2.  DTMF Package . . . . . . . . . . . . . . . . . . . . . . 11
       2.3.  Trunk Package. . . . . . . . . . . . . . . . . . . . . . 16
       2.4.  Line Package . . . . . . . . . . . . . . . . . . . . . . 24
       2.5.  Handset Emulation Package. . . . . . . . . . . . . . . . 33
       2.6.  Supplementary Services Tone Package. . . . . . . . . . . 36
       2.7.  Digit Map Extension. . . . . . . . . . . . . . . . . . . 37
       2.8.  Signal List Package. . . . . . . . . . . . . . . . . . . 38
       2.9.  Media Format Parameter Package . . . . . . . . . . . . . 39
       2.10. RTP Package. . . . . . . . . . . . . . . . . . . . . . . 43
       2.11. Resource Reservation Package . . . . . . . . . . . . . . 48
             2.11.1. Description. . . . . . . . . . . . . . . . . . . 48
             2.11.2. Parameter Encoding . . . . . . . . . . . . . . . 52
             2.11.3. Events . . . . . . . . . . . . . . . . . . . . . 53
       2.12. Announcement Server Package. . . . . . . . . . . . . . . 55
       2.13. Script Package . . . . . . . . . . . . . . . . . . . . . 56
   3.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 59
   4.  Security Considerations. . . . . . . . . . . . . . . . . . . . 59
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
       6.1.  Normative References . . . . . . . . . . . . . . . . . . 60
       6.2.  Informative References . . . . . . . . . . . . . . . . . 62
   7.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 63
   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 64

1.  Introduction

   This document provides a basic set of Media Gateway Control Protocol
   (MGCP) packages.  The generic, line, trunk, handset, RTP, DTMF,
   announcement server and script packages are updates of packages from
   RFC 2705 [38] with additional explanation and in some cases new
   versions of these packages.  In addition to these, five new packages
   are defined here.  These are the signal list, resource reservation,
   media format, supplementary services and digit map extension
   packages.



Foster & Andreasen           Informational                      [Page 2]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [31].

1.1.  List of Packages

   The basic set of packages specified in this document is for use with
   MGCP 1.0 as defined in [1].  Included are the following packages:

              -------------------------------------------
             | Package                        |   Name   |
             |-------------------------------------------|
             | Generic Media Package          |   G      |
             | DTMF package                   |   D      |
             | Trunk Package                  |   T      |
             | Line Package                   |   L      |
             | Handset Package                |   H      |
             | Supplementary Services Package |   SST    |
             | Digit Map Extension            |   DM1    |
             | Signal List Package            |   SL     |
             | Media Format Package           |   FM     |
             | RTP Package                    |   R      |
             | Resource Reservation Package   |   RES    |
             | Announcement Server Package    |   A      |
             | Script Package                 |   Script |
              -------------------------------------------

1.2.  Changes to Existing RFC 2705 Packages

1.2.1.  Change in signal types

   MGCP 1.0, as defined in RFC 2705 [38] (and now updated in [1]),
   provided some additional clarification on the meaning of On-Off (OO)
   signals compared to earlier versions of MGCP.  This lead to some
   inconsistency in some of the signal definitions in the accompanying
   packages in RFC 2705 [38].  This has been corrected in the packages
   that are included here by changing some of the signals from type On-
   Off to type Time-Out (TO).

1.2.2.  Operation Complete and Operation Failure

   Another change made to improve consistency and interoperability was
   to add the "operation complete" and "operation failure" events in
   packages where there are TO signals defined, but where the "operation
   complete" and "operation failure" events were not previously included
   as part of the package.  By definition, all packages that contain





Foster & Andreasen           Informational                      [Page 3]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Time-Out type signals now contain the "operation failure" ("of") and
   "operation complete" ("oc") events as defined in [1], irrespective of
   whether they are provided as part of the package description or not.

   If a package without Time-Out signals contains definitions for the
   "oc" and "of" events, the event definitions provided in the package
   may over-ride those indicated here.  Such practice is however
   discouraged and is purely allowed to avoid potential backwards
   compatibility problems.

   It is considered good practice to explicitly mention that the "oc"
   and "of" events are supported in accordance with their default
   definitions.  If no definition is included in the package, the
   default syntax and semantics are assumed.

   Please refer to [1] for additional details on these events.

1.2.3.  Package Versions

   The generic, line, trunk, handset, RTP, DTMF, announcement server and
   script packages included in this document are new versions of
   packages that were previously contained in RFC 2705 [38].  The
   updated base MGCP 1.0 specification [1] provides an optional
   capability of auditing package versions.  Any gateway that implements
   versioned packages SHOULD also implement this option.

1.2.4.  Event Definitions, Aliases and Interoperability Issues

   Some event definitions or clarifications of previous event
   definitions have also been added in order to improve
   interoperability.

   In some cases, events have aliases either in the same or in other
   packages and a recommendation has been made for the use of alternates
   by Call Agents for future implementations.  For maximum
   interoperability, gateways MUST still implement these events (in fact
   they MUST always implement all of the events, signals, etc. in a
   package).

   Some events that were previously defined require specific
   provisioning in both the gateway and the Call Agent in order to allow
   for interoperability.  In those cases, a warning to that affect has
   been included.








Foster & Andreasen           Informational                      [Page 4]
^L
RFC 3660                  Basic MGCP Packages              December 2003


1.2.5.  New Events

   In some cases, new events have been added to existing packages.  Any
   changes to existing packages of course have resulted in the package
   version number being updated from unversioned (version 0) to version
   1.

1.3.  New Packages and Excluded Packages

   Two packages from RFC 2705 [38] have not been included.  These are
   the "MF" and the "NAS" packages.  These packages are still valid as
   are all unversioned (version 0) packages defined in RFC 2705 [38].
   The reason these packages were not included are:

      *  The original MF package had no defined way to outpulse MF
         digits so that MF CAS is now provided by other packages (i.e.,
         the "MS", "MO" and "MD" packages) in a separate document.

      *  The "N" package, as defined in RFC 2705 [38], was incomplete.
         A new MGCP "NAS" package has been developed and provided in a
         separate document.

   New packages have also been included beyond what was included in RFC
   2705 [38].  These are the signal list, resource reservation, media
   format, supplementary services and digit map extension packages.  The
   Resource Reservation ("RES") and Media Format ("FM") packages in
   particular are different from other packages in this document in that
   they contain new LocalConnectionOptions.  This is allowed by the new
   extension rules in [1].  Future packages of this type MUST use a
   packages prefix in front of local connection options ("<package-
   name>/<Local Connection Option>") so as to avoid name-space problems.
   However because of the timing of the arrival of these packages
   relative to updating MGCP 1.0, this was not done for the "RES" and
   "FM" packages.  The resulting new local connection options have been
   registered with IANA.  For future cases where a package prefix is
   included, only the package name needs to be registered.

2.  Packages

   For those packages that involve MGCP events, the terms "signal" and
   "event" are used to differentiate a request from a Call Agent to a
   Media Gateway to apply an event ("signal"), from the request for the
   detection of an "event" that occurs on the Media Gateway and is
   "Notified" to the Call Agent.







Foster & Andreasen           Informational                      [Page 5]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   For packages that involve events and signals, the tables contain five
   columns:

      Symbol:  the (package) unique symbol used to identify the event.

      Definition:   a short description of the event.

      R:  an x appears in this column if the event can be requested by
      the Call Agent.  Alternatively, one or more of the following
      symbols may appear.  An "S" is included if the event-state may be
      audited.  A "C" indicates that the event can be detected on a
      connection, and a "P" indicates the event is persistent.

      S: if nothing appears in this column for an event, then the event
      cannot be signaled by the Call Agent.  Otherwise, the following
      symbols identify the type of event:

         * OO     On/Off signal

         * TO     Time-Out signal.

         * BR     Brief signal.

      In addition, a "C" will be included if the signal can be generated
      on a connection.

      Duration: specifies the default duration of TO signals.  If a
      duration is left unspecified, then the default timeout will be
      assumed to be infinite, unless explicitly noted in the description
      of the signal.  A duration may also be declared as being variable
      in a case where signals involve complex sequencing (e.g., scripts
      or digit out-pulsing) where the amount of time may vary with
      either processing time or the signaling environment.

   Default time-out values may be over-ridden by the Call Agent for any
   Time-Out event defined in this document (with the exception of those
   that have a default value of "variable") by a "to" signal parameter
   which specifies the timeout value in milliseconds (see [1]).  The
   following example indicates a timeout value of 20 seconds:

         S: sst/cw(to=20000)

   As indicated in [1]: by default, a supplied time-out value MAY be
   rounded to the nearest non-zero value divisible by 1000, i.e., whole
   second.  However, individual signal definitions within a package may
   define other rounding rules.





Foster & Andreasen           Informational                      [Page 6]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Note that Time-Out signals that involve other parameters still allow
   the use of the "to" signal parameter e.g.:

         S: T/sit(1,to=3000)

   The order of the "to" parameter relative to the other parameters is
   not important.

   Note: as per [1], On-Off (OO) signals are parameterized with "+"
   (meaning turn on) or "-" (meaning turn off).  If the parameter is
   missing, the default is to turn on the signal.  Unlike Time-Out
   signals, On-Off signals do not stop when an event occurs.

   Other than the "to" parameter for Time-out (TO) signals and the "+"
   and "-" for On-Off (OO) signals, signals and events in the packages
   in this document do not have parameters unless explicitly indicated
   in the description of the event for that package.

   In some of the signal definitions below, specific tone definitions
   are provided even though actual frequencies may vary from country to
   country.

2.1.  Generic Media Package

   Package Name: G
   Version: 1

   The generic media package groups the events and signals that can be
   observed on several types of endpoints, such as trunk gateway
   endpoints, access gateway endpoints or residential gateway endpoints.

    ---------------------------------------------------------------
   | Symbol   |   Definition               |   R | S     Duration  |
   |---------------------------------------------------------------|
   | cf       |   Confirm Tone             |     | BR              |
   | cg       |   Congestion Tone          |     | TO    infinite  |
   | ft       |   Fax Tone                 |   x |                 |
   | it       |   Intercept Tone           |     | TO    infinite  |
   | ld       |   Long Duration Connection |   C |                 |
   | mt       |   Modem Tone               |   x |                 |
   | oc       |   Operation Complete       |   x |                 |
   | of       |   Operation Failure        |   x |                 |
   | pat(###) |   Pattern Detected         |   x | OO              |
   | pt       |   Preemption Tone          |     | TO    infinite  |
   | rbk(...) |   Ringback                 |     | TO,C 180 seconds|
   | rt       |   Ringback Tone            |     | TO,C 180 seconds|
    ---------------------------------------------------------------




Foster & Andreasen           Informational                      [Page 7]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   New events added to this package from the previously unversioned
   package: "oc"

   Changes: "it" and "pt" signals changed from OO to TO.

   Note that default time-out values may be over-ridden by the Call
   Agent for any Time-Out signal defined in this package by a "to"
   signal parameter.  Refer to section 2 of this document, as well as
   [1] for details.

   The events and signals are defined as follows:

   Confirmation Tone (cf):
      This is also referred to as "positive indication tone" in ITU-T
      E.182.  In North America, Confirmation Tone uses the same
      frequencies and levels as dial tone (350 and 440 Hertz) but with a
      cadence of 0.1 second on, 0.1 second off, repeated three times.
      See GR-506-CORE [7] Section 17.2.4.  It is considered an error to
      try and play confirmation tone on a phone that is on-hook and an
      error MUST consequently be returned when such attempts are made
      (error code 402 - phone on-hook).

   Congestion Tone (cg):
      Refer to ITU-T E.180 [8] and E.182 [10].  This maps to re-order
      tone in North America (refer to GR-506-CORE [7] Section 17.2.7).

   Fax Tone (ft):
      The fax tone event is generated whenever a fax call is detected by
      the presence of V.21 fax preamble.  The fax tone event SHOULD also
      be generated when the T.30 CNG tone is detected.  See ITU-T
      Recommendations T.30 [21] and V.21 [22].

   Intercept Tone(it):
      This is a country specific tone as defined in ITU-T E.180
      Supplement 2 [9].

   Long Duration Connection (ld):
      The "long duration connection" is detected when a connection has
      been established for more than a provisioned amount of time.  The
      default value is 1 hour.

      This event is detected on a connection.  When no connection is
      specified as part of the request, the event applies to all
      connections for the endpoint, regardless of when the connections
      are created.  The "all connections" wildcard (see [1]) may also be
      used for this case, and is in fact preferred for consistency.  In





Foster & Andreasen           Informational                      [Page 8]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      either case, the name of the connection on which the event was
      detected will be included when the event is observed, e.g.:

         G/ld@0A3F58

   Modem Tone (mt):
      Indicates V.25 Answer tone (ANS) with or without phase reversals
      or V.8 Modified Answer Tone (ANSam) tone with or without phase
      reversals.  Note that this implies the presence of a data call.
      Also note that despite the name of the event, devices other than
      modems may generate such tones, e.g., a fax machine.

   Operation Complete (oc):
      The standard definition of operation complete [1].

   Operation Failure (of):
      The standard definition of operation failure [1].

   Pattern Detected (pat(###)):
      This event requires special provisioning that needs to be agreed
      on between the Call Agent and media gateway in order to ensure
      interoperability.  It is retained in order to maintain backwards
      compatibility with version 0 of the "G" package.  This event MUST
      be parameterized with a decimal numeric value from 0 to 999
      specifying the pattern to detect.  When reported, the pattern is
      also included as a parameter.

   Preemption Tone (pt):
      This is a country specific tone and is defined in ITU-T E.180
      Supplement 2 [9].

   Ringback (rbk(connectionID)):
      This is an alias for "rt@connectionID" and is included here for
      backwards compatibility only.  It is recommended that Call Agents
      use "rt@connectionID" instead of "rbk(connectionID)" for ring-back
      over a connection for new implementations.  Although the ringback
      signal is applied on a connection, the "rbk" signal does not
      support the "@connection" syntax.  When the signal is requested,
      it MUST be parameterized with a connection-ID or a connection-ID
      wildcard as specified in [1].

   Ringback Tone (rt):
      Refer to ITU-T E.180 [8] and ITU-T E.182 [10].  Also referred to
      as ringing tone - a tone advising the caller that a connection has
      been made and that a calling signal is being applied to the called
      party or service point.  In North America, this tone is a
      combination of two AC tones with frequencies of 440 and 480 Hertz
      and levels of -19 dBm each, to give a combined level of -16 dBm.



Foster & Andreasen           Informational                      [Page 9]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      The cadence for Audible Ring Tone is 2 seconds on, followed by 4
      seconds off.  See GR-506-CORE [7] - LSSGR: SIGNALING, Section
      17.2.5.

      This signal can be applied directly to an endpoint or
      alternatively on a connection using the syntax "rt@connectionID".
      When the ringback signal is applied to an endpoint, it is
      considered an error to try and play ringback tone if the endpoint
      is considered on-hook, and an error MUST consequently be returned
      when such attempts are made (error code 402 - phone on-hook).
      When the ringback signal is applied to a connection, no such check
      is to be made.

      Note that as specified in [1], signals requested on a connection
      MUST be played regardless of the connection mode.  For example, in
      a call-waiting situation, ringback tone may be played on a
      connection in "inactive" mode.


































Foster & Andreasen           Informational                     [Page 10]
^L
RFC 3660                  Basic MGCP Packages              December 2003


2.2.  DTMF package

   Package name: D
   Version: 1

    --------------------------------------------------------------
   | Symbol  |   Definition              |   R |   S     Duration |
   |--------------------------------------------------------------|
   | 0       |   DTMF 0                  |   x |   BR             |
   | 1       |   DTMF 1                  |   x |   BR             |
   | 2       |   DTMF 2                  |   x |   BR             |
   | 3       |   DTMF 3                  |   x |   BR             |
   | 4       |   DTMF 4                  |   x |   BR             |
   | 5       |   DTMF 5                  |   x |   BR             |
   | 6       |   DTMF 6                  |   x |   BR             |
   | 7       |   DTMF 7                  |   x |   BR             |
   | 8       |   DTMF 8                  |   x |   BR             |
   | 9       |   DTMF 9                  |   x |   BR             |
   | #       |   DTMF #                  |   x |   BR             |
   | *       |   DTMF *                  |   x |   BR             |
   | A       |   DTMF A                  |   x |   BR             |
   | B       |   DTMF B                  |   x |   BR             |
   | C       |   DTMF C                  |   x |   BR             |
   | D       |   DTMF D                  |   x |   BR             |
   | DD(..)  |   DTMF Tone Duration      |   x |   TO  3 seconds  |
   | DO(..)  |   DTMF OO Signal          |     |   OO             |
   | L       |   Long Duration Indicator |   x |                  |
   | oc      |   Operation Complete      |   x |                  |
   | of      |   Operation Failure       |   x |                  |
   | T       |   Interdigit Timer        |   x |   TO 16 seconds  |
   | X       |   DTMF Tones Wildcard,    |   x |                  |
   |         |    match any digit 0-9    |     |                  |
    --------------------------------------------------------------

   Changes from the previous version of the package: events "dd", "do",
   "oc" were added.

   Note that DTMF tones including the DTMF tones wildcard can use the
   eventRange notation defined in [1] when requesting events, e.g.,
   "D/[0-9](N)".

   Note that default time-out values may be over-ridden by the Call
   Agent for any Time-Out signal defined in this package by a "to"
   signal parameter.  Refer to section 2 of this document, as well as
   [1] for details.






Foster & Andreasen           Informational                     [Page 11]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   The events are defined as follows:

   DTMF tones (0-9,#,*,A,B,C,D):
      Detection and generation of DTMF tones is described in GR-506-CORE
      [7] - LSSGR: SIGNALING, Section 15.  Note that it is considered an
      error to try and play DTMF tones on a phone that is on-hook and an
      error MUST consequently be returned when such attempts are made
      (error code 402 - phone on-hook).  The event codes can be
      specified in a digit map.  When requested as a signal, as per
      GR-506-CORE [7], section 15, a minimum tone duration of 50 ms will
      be followed by a minimum interdigit silence period of 45 ms, i.e.,
      if requested in a signal list such as "S: sl/s(d/5,d/6,d/7)", then
      interdigit timing requirements will be satisfied.

      Note that some types of endpoints, such as announcement endpoints,
      MAY allow detection and/or generation of a DTMF tone over a
      connection.  However, this requires consistent provisioning
      between the Call Agent and announcement server (it is not required
      in order to be compliant with the DTMF package).

   DTMF Tone Duration (dd(dg=<tone>,to=<time>,su=<TrueOrFalse>)):
      This event can be used to indicate if/when the specified <tone>
      has a duration greater than the <time> value indicated (and is
      reported once the duration is exceeded).  The parameters can be
      supplied in any order.  The value of <tone> can be any of the DTMF
      tone symbols (without including the package name) specified in the
      DTMF package (including X in the case of events, but not signals).
      If this parameter is absent, any DTMF tone that occurs will be
      reported.  The parameter <time> is in milli-seconds and may be
      rounded to the nearest 10 ms by the gateway.  The minimum value of
      <time> that can be requested when requesting an event is 40 ms.
      When requesting a signal, the minimum value of <time> that can be
      requested is 50 ms.  The maximum value of <time> that can be
      requested for either an event or a signal is 60000 ms.  If the
      "to=<time>" parameter is absent when requested as an event, the
      event will report the full duration (up to 60000 ms) of the tone
      when the tone is completed.  When reported as an ObservedEvent,
      both parameters are always supplied.  In this case, <tone> is the
      actual tone detected and <time> is either:

         *  The <time> specified in the request (possibly rounded), or

         *  If the request did not contain a "to=<time>" parameter, the
            full duration of the tone.

      The parameter "su" MAY be included when this is requested as an
      event (but is not reported).  This parameter is used to indicate
      whether or not the DTMF digits requested should be suppressed



Foster & Andreasen           Informational                     [Page 12]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      in-band when it is requested.  Possible values are "true",
      indicating that in-band DTMF should be suppressed and "false"
      indicating that DTMF should continue to be passed in-band.  The
      default value of the parameter, if missing, is "false".  The "su"
      parameter MUST NOT be included when requesting "D/dd" as a signal.

      When used as a signal, "dd" provides the ability to generate a
      DTMF tone as a TO signal.  When applied as a signal, an additional
      50 ms of silence will be tacked onto the end before the operation
      complete occurs, i.e., "S: dd(dg=5,to=2500)" will play the DTMF
      tone for the number "5" for 2.5 seconds, followed by 50 ms of
      silence period.  The operation complete (if requested) will be
      notified after the silence interval occurs.  Any value from 50 ms
      to 60000 ms can be requested.  Gateways generating or detecting
      the tone may round off the requested time to the nearest 10 ms.

      The "dd" event can be used in place of the "long duration" event
      in order to detect a digit pressed for longer than 2 seconds.  For
      example, in order to detect if a user presses the long "#" for
      longer than 2 seconds, a request could be made with the
      RequestedEvents line "R: d/dd(N)(dg=#,to=2000)".  The resulting
      ObservedEvents line would be "O: d/dd(dg=#,to=2000)".

      Suppose instead, that the RequestedEvents line contains

         R: d/[0-9*#],d/dd

      Suppose the user then pushes the "#" for 2.5 seconds.  In this
      case, two events will be notified:

         O: d/#

      when the "#" key is first pressed, and

         O: d/dd(dg=#,to=2500)

      when the "#" key is finally released.

   DTMF OO Signal (do(dg=<tone>,<on-or-off>)):
      This signal is used to generate a DTMF tone as an on-off signal.
      The <tone> parameter is any of the symbols for a specific tone in
      the DTMF package (i.e., "0" to "9", "A", "B", "C", "D", "*", or
      "#").  The <on-or-off> indicator is "+" for on and "-" for off as
      per [1].  The <tone> parameter MUST be supplied, otherwise a
      return code of 538 - "Event/signal parameter error" will be
      provided in the response.  If the <on-or-off> parameter is
      missing, the default is to turn the signal on as usual (i.e., "+"
      is the default).  The order of the parameters is not significant



Foster & Andreasen           Informational                     [Page 13]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      since "+" and "-" are reserved characters and are easily
      distinguished from the <tone> parameter.

   Long Duration Indicator (l):
      The "long duration indicator" is observed when a DTMF signal is
      produced for a duration larger than two seconds.  In this case,
      the gateway will detect two successive events: first, when the
      signal has been recognized, the DTMF signal, and then, 2 seconds
      later, the long duration signal.

   Operation Complete (oc):
      This is the standard definition of operation complete [1].

   Operation Failure (of):
      This is the standard definition of operation failure [1].

   Timer (t):
      Timer T can be used as an event or as a time-out (TO) signal.  As
      a signal, its only behavior is the normal characteristics of a
      "TO" signal as defined in [1] (i.e., if no event occurs before the
      time-out, an operation complete event will be generated).

      As an event, Timer T is a digit input timer that can be used in
      two ways:

         *  When timer T is used with the accumulate according to digit
            map action, the timer is not started until the first DTMF
            tone is entered, and the timer is restarted after each new
            DTMF tone is entered until either a digit map match or
            mismatch occurs.  In this case, timer T functions as an
            inter-digit timer as illustrated by:

               R: D/[0-9T](D)

         *  When timer T is used without the "accumulate according to
            digit map" action, the timer is started immediately and
            simply cancelled (but not restarted) as soon as a DTMF tone
            is entered.  In this case, timer T can be used as an inter-
            digit timer when overlap sending is used, as in:

               R: D/[0-9](N), D/T(N)

      When used with the "accumulate according to digit map" action,
      timer T takes on one of two values, T-partial or T-critical.  When
      at least one more symbol is required for the "current dial string"
      to match any one of the patterns in the digit map, timer T takes
      on the value T-partial, corresponding to partial dial timing.  If
      a timer is all that is required to produce a match, timer T takes



Foster & Andreasen           Informational                     [Page 14]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      on the value T-critical corresponding to critical dial timing.
      When timer T is used without the "accumulate according to digit
      map" action, timer T takes on the value T-critical.  The default
      value for T-partial is 16 seconds and the default value for
      T-critical is 4 seconds.  The provisioning process may alter both
      of these.  If timer T is not used, then inter-digit timing will
      not be performed.

      The following examples illustrate this.  Consider the digit map:

         (xxxxxxx|x11T)

      and assume that DTMF and the timer T is accumulated according to
      digit map.  At the first DTMF input, say "4", timer T is started
      with a value of T-partial since at least one more symbol is
      required.  If "1" is then input, it leads to a restart of timer T
      with a value of T-partial again.  If "1" is now input again, we
      have a current dial string of "411" and a timer is now all that is
      required to produce a match.  Hence timer T is now restarted with
      value T-critical.

      Finally, consider the following subtle examples (all assuming DTMF
      and timer T being accumulated according to digit map):

      The digit map

         (1[2-3T].)

      will match immediately on the input "1" since zero or more matches
      of the range are specified.

      The digit map

         (1[2-3].T)

      and an input of "1" will lead to timer T being set to T-critical.

      A digit map of

         (1[2-3]T.)

      and an input of "1" will lead to timer T being set to T-partial.
      Furthermore, upon subsequent input of "2" or "3" a perfect match
      will be triggered immediately since timer T is completely
      irrelevant.






Foster & Andreasen           Informational                     [Page 15]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   DTMF Tones Wildcard (X):
      The DTMF tones wildcard matches any DTMF digit between 0 and 9.
      The actual event code generated will however be the event code for
      the digit detected.  The DTMF tones wildcard is often used to
      detect DTMF input to be matched against a digit map.

2.3.  Trunk Package

   Package Name: T
   Version: 1

    ----------------------------------------------------------------
   | Symbol   |   Definition                   |   R | S  Duration  |
   |----------------------------------------------------------------|
   | as       |   Answer Supervision           |   x | BR           |
   | bl       |   Blocking                     |     | BR           |
   | bz       |   Busy                         |     | TO  30 sec.  |
   | co1      |   Continuity Tone (go tone,    |   x | TO  3 sec.   |
   |          |   or return tone)              |     |              |
   | co2      |   Continuity Test (go tone,    |   x | TO  3 sec.   |
   |          |   or return tone in dual tone  |     |              |
   |          |   procedures)                  |     |              |
   | ct(...)  |   Continuity Transponder       |     | OO           |
   | lb       |   Loopback                     |     | OO           |
   | nm       |   New Milliwatt Tone           |   x | TO  3 sec    |
   | mm       |   Newest Milliwatt Tone        |   x | TO  3 sec    |
   | oc       |   Operation Complete           |   x |              |
   | of       |   Operation Failure            |   x |              |
   | om       |   Old Milliwatt Tone           |   x | TO  3 sec    |
   | pst      |   Permanent Signal Tone        |     | TO  infinite |
   | qt       |   Quiet Termination            |     | TO  infinite |
   | ro       |   Reorder Tone                 |   x | TO  30 sec.  |
   | sit(#)   |   Special Information Tone     |   x | TO  2 sec.   |
   |          |                                |     |  (see notes) |
   | tl       |   Test Line                    |   x | TO  infinite |
   | tp(###)  |   Test Pattern                 |   x | TO  3 sec    |
   | zz       |   No Circuit                   |   x | TO  2 sec    |
    ----------------------------------------------------------------

   New events added to this package from the previously unversioned
   package: "bz", "ct", "mm", "oc", "pst", "qt", "sit", and "tp".

   Changes in event types: "co1", "co2", "nm", "om", "tl", "zz" signals
   changed from OO to TO; "as" and "bl" changed from OO to BR.







Foster & Andreasen           Informational                     [Page 16]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Note that default time-out values may be over-ridden by the Call
   Agent for any Time-Out signal defined in this package by a "to"
   signal parameter.  Refer to section 2 of this document, as well as
   [1] for details.

   The definition of the trunk package events are as follows:

   Answer Supervision (as):
      This event is used to indicate the occurrence answer supervision.
      In most cases, it is a result of a steady off-hook in response to
      a call request.  This event is included for backwards
      compatibility with the previous version of the package.  The
      preferred alternative is to use the "answer" event in the
      appropriate CAS packages [34] (Note: check the details on the use
      of "answer" in the particular CAS package; in most cases "answer"
      as an event is an indication of a steady off-hook regardless of
      whether or not it is an indication of answer supervision).  For
      details on when answer supervision is appropriate refer to [5].

   Blocking (bl):
      This event is used to indicate an incoming off-hook for the
      purposes of blocking a one-way trunk in CAS trunks.  This event is
      included for backwards compatibility with the previous version of
      the package.  The preferred alternative is the "block" event in
      the appropriate CAS packages [34].

   Busy Tone (bz):
      Refer to ITU-T E.180 [8].  In North America, station Busy is a
      combination of two AC tones with frequencies of 480 and 620 Hertz
      and levels of -24 dBm each, to give a combined level of -21 dBm.
      The cadence for Station Busy Tone is 0.5 seconds on, followed by
      0.5 seconds off, then repeating.  See GR-506-CORE [7]- LSSGR:
      SIGNALING, Section 17.2.6.

   Continuity Tone (co1):
      A tone at 2010 Hz (see section 3.1.1.3 of [2]).  When generated as
      a signal, the frequency of the tone must be within + or - 8 Hz,
      while the frequency of the tone corresponding to the event must be
      within + or - 30 Hz.

   Continuity Test (co2):
      A tone at 1780 Hz (see section 3.1.1.3 of [2]).  When generated as
      a signal, the frequency of the tone must be within + or - 20 Hz,
      while the frequency of the tone corresponding to the event must be
      within + or - 30 Hz.

      In continuity testing the tone corresponding to the signal at the
      originating gateway is referred to as the "go" tone, and the tone



Foster & Andreasen           Informational                     [Page 17]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      corresponding to the event at that same gateway is referred to as
      the "return" or "check" tone.

      Note that generation and notification of continuity tones are done
      as per continuity test requirements as defined in ITU-T Q.724 [3],
      as well as by Bellcore GR-317-CORE [2] specifications, i.e., the
      semantics of notification of the return tone is more than that the
      tone was received, but is an indication that the test has passed.
      Details are provided in the following paragraphs.

      The continuity tones represented by co1 and co2 are used when the
      Call Agent wants to initiate a continuity test.  There are two
      types of tests, single tone and dual tone; In the case of the dual
      tone, either tone can be sent and the opposite received depending
      on the trunk interconnections (4-wire or 2-wire) as indicated
      below:

         Originating                               Terminating
         ============                              ===========

            4w   -------------- 1780 Hz ----------->  2w
                 <------------- 2010 Hz ------------  (transponder)

            2w   -------------- 2010 Hz ----------->  2w/4w
                 <------------- 1780 Hz ------------  (transponder)

            4w   -------------- 2010 Hz ----------->  4w
                 <------------- 2010 Hz ------------  (loopback)

      The Call agent is expected to know, through provisioning
      information, which test should be applied to a given endpoint.  As
      an example, for a 4-wire to 2-wire connection, the Call Agent
      might send a request like the following to an originating gateway:

         RQNT 1234 ds/ds1-1/17@tgw2.example.net
         X: AB123FE0
         S: t/co1
         R: t/co2,t/oc,t/of

      On a terminating side of a trunk, the call agent may request a
      continuity test connection (connection mode "conttest") to the
      terminating gateway as follows:

         CRCX 3001 ds/ds1-2/4@tgw34.example.net
         C: 3748ABC364
         M: conttest





Foster & Andreasen           Informational                     [Page 18]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      Alternatively, rather than using a connection mode, the "T/ct"
      signal can be used (see description of this signal further below):

         RQNT 3001 ds/ds1-2/4@tgw34.example.net
         X: 1233472
         S: t/ct(in=co1,out=co2,+)

      The originating gateway would send the requested "go" tone, and
      would look for the appropriate "return tone".  Once the return
      tone is received, the originating gateway removes the go tone and
      checks to see that the return tone has been removed within the
      specified performance limits (i.e., GR-246-CORE, T1.113.4, Annex B
      [23]).  When it detects that the test is successful, the gateway
      will send a notification of the return tone event (Note that
      notification of the return tone event therefore must not be sent
      prior to detection of the removal of the return tone).

      The "T/co1" and "T/co2" signals are TO signals so that an
      operation complete event will occur when the signal times out.  If
      a timeout value other than the default is desired, the "to"
      parameter may be used (e.g., "S: T/co1(to=2000)").

      If the gateway detects the failure of the continuity test prior to
      the timeout, an operation failure event will be generated.
      Otherwise, the failure of the continuity test is determined by the
      failure to receive the return tone event before the timeout occurs
      (operation complete event).  As with TO signals in general,
      operation complete and operation fail events are parameterized
      with the name of the signal.

      In the example above where the go tone is "co1" and the return
      tone is "co2":

         *  A notification of the "co2" event indicates success (i.e.,
            "O: t/co2").

         *  A notification of the operation failure event indicates
            failure prior to timeout (i.e., "O: t/of(t/co1)").

         *  A notification of the operation complete event indicates
            that the return tone was not received properly prior to the
            occurrence of the timeout (i.e., "O: t/oc(t/co2)").

      On a terminating end of a trunk, either a "loopback" connection
      (single tone test) or "conttest" connection (dual tone test) is
      made (or alternatively the "T/lb" or "T/ct" signals are
      requested).  It is up to the termination end to make sure that the
      return tone is removed as soon as the go tone disappears.  The



Foster & Andreasen           Informational                     [Page 19]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      Call Agent requests the removal of "contest" or "loopback"
      connections (or "T/lb" or "T/ct" signals) at a termination end
      when the results of the continuity test are obtained.

      When "conttest" is used, the endpoint is provisioned as to which
      transponder test is being performed (2010 Hz received and 1780 Hz
      sent or vice versa).  In the case of the corresponding "T/ct"
      signal, the Call Agent can specify which tone is received and sent
      as parameters.

      Note that continuity tones in the trunk package are only ever sent
      to the telephony endpoint.  For network-based continuity, there
      are continuity tones available in the RTP ("R") package.  Although
      a transponder (dual tone) test can be done, a single tone test is
      generally sufficient in the case of continuity testing across an
      IP network.

   Continuity Transponder(ct(in=<tone-in>,out=<tone-out>, <+ or ->)):
      This signal is used to provide transponder functionality
      independent of the connection mode, i.e., this is an alternative
      way to provide the same functionality as the "conttest" connection
      mode.  The parameters can be provided in any order.  The <tone-in>
      and <tone-out> parameters can have values "co1" or "co2",
      corresponding to the 2010 Hz and 1780 Hz tones associated with
      those symbols.  If one of the tones is "co1", then the other must
      be "co2" and vice versa (i.e., <tone-in> and <tone-out> must have
      different values; if loopback is required, then the "lb" signal in
      this package or "loopback" connection mode should be used).

      On detecting <tone-in>, <tone-out> will be generated in return.
      The tone corresponding to <tone-out> will continue to be generated
      until either:

         *  The signal is explicitly turned off (e.g., "S: t/ct(-)") or

         *  Removal of the <tone-in> tone is detected.

      Note that while the signal is active (regardless of whether a tone
      is active or not), media from the endpoint will not be forwarded
      to or from the packet network (i.e., the continuity transponder
      signal must be explicitly turned off by the Call Agent in order to
      resume passing media between the packet network and the endpoint).

   Loopback (lb):
      This signal is used to provide loopback functionality independent
      of the connection mode, i.e., this is an alternative way to
      provide the same functionality as "loopback" connection mode.




Foster & Andreasen           Informational                     [Page 20]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      Note that while the loop-back signal is active (regardless of
      whether a tone is active or not), media from the endpoint will not
      be forwarded to or from the packet network (i.e., the loopback
      signal must be explicitly turned off by the Call Agent in order to
      resume passing media between the packet network and the endpoint).

   New Milliwatt Tone (nm):
      1004 Hz tone - refer to [4] and section 8.2.5 of [5].

   Newest Milliwatt Tone (mm):
      1013.8 Hz - refer to [4].

   Operation Complete (oc):
      This is the standard definition of operation complete [1].

   Operation Failure (of):
      This is the standard definition of operation failure [1].

   Old Milliwatt Tone (om):
      1000 Hz tone - refer to [4] and section 8.2.5 of [5].

   Permanent Signal Tone (pst):
      In North America, this tone is applied to a busy line
      verify/operator interrupt under specific circumstances as
      described in [17].

   Quiet Termination (qt):
      Quiet Termination is used in a 102 trunk test.  Reference section
      6.20.5 [5] as well as [4].

   Reorder Tone(ro):
      This maps to congestion tone in the ITU-T E.182 specification.  In
      North America, reorder tone is a combination of two AC tones with
      frequencies of 480 and 620 Hertz and levels of -24 dBm each, to
      give a combined level of -21 dBm.  The cadence for reorder tone is
      0.25 seconds on, followed by 0.25 seconds off, repeating
      continuously (until time-out).  See GR-506-CORE [7], Section
      17.2.7.

   Special Information Tone(sit(#)):
      As described in ITU-T E.180 [8], the special information tone
      consists of a tone period in which 3 tones are produced followed
      by a silent period of 1 second (total TO period of approximately 2
      seconds).  When used as a signal, it MUST be parameterized with a
      parameter value from 1 to 7, with the following meaning as defined
      in SR-2275, section 6.21.2 of [5].





Foster & Andreasen           Informational                     [Page 21]
^L
RFC 3660                  Basic MGCP Packages              December 2003


             -------------------------------------------
            | sit(1) | RO' | reorder SIT, intra-LATA    |
            | sit(2) | RO" | reorder SIT, inter-LATA    |
            | sit(3) | NC' | no circuit SIT, intra-LATA |
            | sit(4) | NC" | no circuit SIT, inter-LATA |
            | sit(5) | IC  | intercept SIT              |
            | sit(6) | VC  | vacant code SIT            |
            | sit(7) | IO  | ineffective other SIT      |
             -------------------------------------------

      When requested as an event, the event MUST be parameterized with a
      decimal number from 1 to 7 to indicate which tone the gateway is
      required to detect.  The resulting notification also includes the
      parameter.  Other countries may have one or more special
      information tones with country specific definitions (refer to
      ITU-T E.180 supp. 2 [9]).  In this case, special information tone
      1 as defined in [9] is sit(1), special information tone 2 is
      sit(2) etc.

      As an example, the Call Agent might make a request such as:

          RQNT 1234 ds/ds1-1/17@tgw2.example.net
          X: AB123FE0
          R: t/sit(N)(2)

      If the tone is detected, the resulting notification might appear
      as follows:

          NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
          X: AB123FE0
          O: t/sit(2)

   Test Line (tl):
      105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10
      dBm0).  Refer to section 8.2.5 of [5].

   Test Pattern (tp(###)):
      The tp(###) signal inserts the pattern ### continuously into the
      channel until the timeout period expires.  The parameter is
      provided as a decimal number from 0 to 255.  If the parameter is
      omitted, the default value is decimal 95.

      In RequestedEvents, the parameter MAY be supplied to indicate what
      pattern the Call Agent wishes the gateway to detect.  If the
      parameter is omitted, the value 95 is assumed.  The pattern MUST
      be returned in the ObservedEvent (even if the parameter was not
      requested).




Foster & Andreasen           Informational                     [Page 22]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      A typical use for the test pattern signal is for the test line 108
      (digital loopback) test (refer to section 8.2.5 of [5]).  At the
      termination side of a trunk, the Call Agent would request a
      connection in "loopback" mode, which would do a digital loopback.
      On the origination side of the trunk, the Call Agent would request
      that the test pattern be injected into the digital channel, and
      would check to see that the pattern was returned within the
      timeout period.  As an example, the Call Agent would make the
      following request on the origination side:

         RQNT 1234 ds/ds1-1/17@tgw2.example.net
         X: AB123FE0
         S: t/tp
         R: t/tp, t/oc, t/of

      In this case the Call Agent will either receive:

         *  An ObservedEvent indicating that the test has passed (i.e.,
            "O:t/op(95)") or

         *  An ObservedEvent indicating that the timeout occurred before
            the pattern was received (i.e., "O:t/oc(t/tp)"), indicating
            that the test failed.  Of course an operation failure would
            indicate failure as well.

   No Circuit (zz):
      This is an alias for Special Information Tone 2, i.e., "sit(2)".
























Foster & Andreasen           Informational                     [Page 23]
^L
RFC 3660                  Basic MGCP Packages              December 2003


2.4.  Line Package

   Package Name: L
   Version: 1

    ----------------------------------------------------------------
   |Symbol       |   Definition               |   R |  S  Duration  |
   |----------------------------------------------------------------|
   |adsi(string) |   ADSI Display             |     |  BR           |
   |aw           |   Answer Tone              |   x |  OO           |
   |bz           |   Busy Tone                |     |  TO 30 sec.   |
   |ci(ti,nu,na) |   Caller-id                |     |  BR           |
   |dl           |   Dial Tone                |     |  TO 16 sec.   |
   |e            |   Error Tone               |   x |  TO 2 sec.    |
   |hd           |   Off-hook Transition      |   S |               |
   |hf           |   Flash-hook               |   x |               |
   |ht           |   On Hold Tone             |     |   OO          |
   |hu           |   On-hook Transition       |   S |               |
   |lsa          |   Line Side Answer Sup.    |     |   OO          |
   |mwi          |   Message Waiting ind.     |     |   TO 16 sec.  |
   |nbz          |   Network busy             |   x |   TO infinite |
   |oc           |   Operation Complete       |   x |               |
   |of           |   Operation Failure        |   x |               |
   |osi          |   Network Disconnect       |     |   TO 900 ms   |
   |ot           |   Off-hook Warning Tone    |     |   TO infinite |
   |p            |   Prompt Tone              |   x |   BR          |
   |rg           |   Ringing                  |     |   TO 180 sec. |
   |r0, r1, r2,  |   Distinctive Ringing      |     |   TO 180 sec. |
   |r3, r4, r5,  |                            |     |               |
   |r6 or r7     |                            |     |               |
   |ro           |   Reorder Tone             |     |   TO 30 sec.  |
   |rs           |   Ringsplash               |     |   BR          |
   |s(###)       |   Distinctive Tone Pattern |   x |   BR          |
   |sit(#)       |   Special Information Tone |     |   TO 2 sec.   |
   |             |                            |     |   (see notes) |
   |sl           |   Stutter Dial Tone        |     |   TO 16 sec.  |
   |v            |   Alerting Tone            |     |   OO          |
   |vmwi         |   Visual Message           |     |   OO          |
   |             |     Waiting Indicator      |     |               |
   |wt           |   Call Waiting Tone        |     |   TO 12 sec   |
   |wt1, wt2,    |   Alternative Call         |     |   TO 12 sec   |
   |wt3, wt4     |     Waiting Tones          |     |   (see notes) |
   |y            |   Recorder Warning Tone    |     |   TO infinite |
   |z            |   Calling Card Service Tone|     |   BR          |
    ----------------------------------------------------------------

   New events added to this package from the previously unversioned
   package: "ht", "osi", and "lsa".



Foster & Andreasen           Informational                     [Page 24]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Changes in event types: signals "y", "z", changed from OO to TO and
   BR respectively.  Ringing tones were extended to allow for a ring
   repetition signal parameter.

   Note that default time-out values may be over-ridden by the Call
   Agent for any Time-Out signal defined in this package by a "to"
   signal parameter.  Refer to section 2 of this document, as well as
   [1] for details.

   The description of events and signals in the line package are as
   follows:

   ADSI Display (adsi):
      This signal is included here to maintain compatibility with the
      previous version of this package.  The signal is not well-defined
      and its use is discouraged.

   Answer Tone (aw):
      This event is included here to maintain compatibility with the
      previous version of this package.  The event is not well-defined
      and its use is discouraged.

   Busy Tone (bz):
      Refer to ITU-T E.180 [8].  In North America, station Busy is a
      combination of two AC tones with frequencies of 480 and 620 Hertz
      and levels of -24 dBm each, to give a combined level of -21 dBm.
      The cadence for Station Busy Tone is 0.5 seconds on followed by
      0.5 seconds off, repeating.  See GR-506-CORE [7], Section 17.2.6.
      It is considered an error to try and play busy tone on a phone
      that is on-hook and an error MUST consequently be returned when
      such attempts are made (error code 402 - phone on-hook).

   Caller-id (ci(time, number, name)):
      See GR-1188 [24], GR-30-CORE [14], and GR-31 [25].  For backwards
      compatibility, each of the three fields are optional, but each of
      the commas will always be included.  In accordance with the
      general MGCP grammar, it is RECOMMENDED to always include all
      three fields - an empty quoted string can then be used in lieu of
      omitting a parameter:

      The time parameter is coded as "MM/DD/HH/MM", where MM is a two-
      digit decimal value for a Month between 01 and 12, DD is a two-
      digit value for a Day between 01 and 31, and Hour and Minute are
      two-digit values coded according to military local time, e.g., 00
      is midnight, 01 is 1 a.m., and 13 is 1 p.m.  (Note: two digits
      MUST always be provided for each of the values of month, day,
      hour, minutes e.g., the month of January is indicated by the two
      digits "01" rather than just "1").



Foster & Andreasen           Informational                     [Page 25]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      The number parameter is coded as an ASCII character string of
      decimal digits that identify the calling line number.  White
      spaces are permitted if the string is quoted, but they will be
      ignored.  If a quoted-string is provided, the string itself is
      UTF-8 encoded (RFC 2279) as usual for signal parameters.

      The name parameter is coded as a string of ASCII characters that
      identify the calling line name.  White spaces are permitted if the
      string is quoted.  If a quoted-string is provided, the string
      itself is UTF-8 encoded (RFC 2279).

      A "P" in the number or name field is used to indicate a private
      number or name, and an "O" is used to indicate an unavailable
      number or name.  Other letters MAY be used to provide additional
      clarification as per provider or vendor specifications.

      The following example illustrates the use of the caller-id signal:

         S: l/ci(09/14/17/26, "555 1212", "John Doe")

      An example indicating that the name and number are private:

         S: l/ci(09/14/17/26,P,P)

   Dial Tone (dl):
      Refer to the ITU-T E.180 [8] specification.  In North America,
      dial tone is a combination of two continuous AC tones with
      frequencies of 350 and 440 Hertz and levels of -13dBm each, to
      give a combined level of -10 dBm.  See GR-506-CORE [7] - LSSGR:
      SIGNALING, Section 17.2.1.  It is considered an error to try and
      play dial-tone on a phone that is on-hook and an error MUST
      consequently be returned when such attempts are made (error code
      402 - phone on-hook).

   Error Tone (e):
      This tone is maintained for backwards compatibility.  The tone is
      not well defined and its use is discouraged.

   Off-hook Transition (hd):
      See GR-506-CORE [7], Section 12.  It is considered an error to try
      and request off-hook on a phone that is off-hook and an error MUST
      consequently be returned when such attempts are made (error code
      401 - phone off-hook).








Foster & Andreasen           Informational                     [Page 26]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Flash Hook (hf):
      See GR-506-CORE [7], Section 12.  It is considered an error to try
      and request flash hook on a phone that is on-hook and an error
      MUST consequently be returned when such attempts are made (error
      code 402 - phone on-hook).

   Tone On Hold (ht):
      A tone used to reassure a calling subscriber who has been placed
      on "hold".  Refer to ITU-T E.182 [10].

   On-hook Transition (hu):
      See GR-506-CORE [7], Section 12.  The timing for the on-hook
      signal is for flash response enabled, unless provisioned
      otherwise.  It is considered an error to try and request flash
      hook on a phone that is on-hook and an error MUST consequently be
      returned when such attempts are made (error code 402 - phone on-
      hook).

   Line Side Answer Supervision (lsa):
      This provides Reverse Loop Current Feed (RLCF) on the line (refer
      to GR-506-CORE [7]) and is a way of indicating that the called
      party has answered for some line-side equipment.

   Message Waiting Indicator (mwi):
      Message Waiting indicator tone uses the same frequencies and
      levels as dial tone (350 and 440 Hertz at -13dBm each), but with a
      cadence of 0.1 second on, 0.1 second off, repeated 10 times,
      followed by steady application of dial tone.  See GR-506-CORE [7],
      Section 17.2.3.  It is considered an error to try and play
      message-waiting indicator on a phone that is on-hook and an error
      MUST consequently be returned when such attempts are made (error
      code 402 - phone on-hook).

   Network Busy (nbz):
      This is included here to maintain compatibility with the previous
      version of this package.  The "nbz" signal is an alias for re-
      order tone signal("ro").  Future Call Agent implementations that
      require a network busy signal should use the "ro" signal.  It is
      also recommended that future Call Agents not request to be
      notified of the "nbz" event (a network busy event is generally not
      required in a line package; hence, "ro" is only a signal, not an
      event).

   Operation Complete (oc):
      This is the standard definition of operation complete [1].

   Operation Failure (of):
      This is the standard definition of operation failure [1].



Foster & Andreasen           Informational                     [Page 27]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Network Disconnect (osi):
      Network Disconnect indicates that the far-end party has
      disconnected.  The signal that is sent on the line is provisioned
      in the media gateway since it may vary from country to country.
      In North America, this signal is an open switch interval which
      results in a Loop Current Feed Open Signal (LCFO) being applied to
      the line (refer to GR-506-CORE [7], see also See GR-505-CORE [6],
      Section 4.5.2.1).  The default time-out value for this signal is
      900 ms.

   Off-hook Warning Tone (ot):
      Off-hook warning tone, also known as receiver Off-Hook Tone (ROH
      Tone).  This is the irritating noise a telephone makes when it is
      not hung up correctly.  In North America, ROH Tone is generated by
      combining four tones at frequencies of 1400 Hertz, 2060 Hertz,
      2450 Hertz and 2600 Hertz, at a cadence of 0.1 second on, 0.1
      second off, then repeating.  GR-506-CORE [7], Section 17.2.8
      contains details about required power levels.  It is considered an
      error to try and play off-hook warning tone on a phone that is
      on-hook, and an error MUST consequently be returned when such
      attempts are made (error code 402 - phone on-hook).

   Prompt Tone (p):
      The definition of the prompt tone and its use may be found in
      requirement GR-220 [20].  The tone in GR-220 (requirement "R3-170"
      or GR-220) is a 300 ms burst of a 400 Hz tone.

   Ringing (rg):
      See GR-506-CORE [7], Section 14.  The provisioning process may
      define the ringing cadence.  The ringing signal may be
      parameterized with the signal parameter "rep" which specifies the
      maximum number of ringing cycles (repetitions) to apply.  The
      value for "rep" is specified in decimal and can have any value
      from 1 to 255.  The following will apply the ringing signal for up
      to 6 ringing cycles:

         S: l/rg(rep=6)

      If the "rep" parameter is specified, the signal times-out when the
      number of repetitions are completed (i.e., an operation complete
      event can be requested and will occur at the end of the
      timeout/number of rings).

      If the "rep" parameter is supplied, then any timeout ("to") value
      that is included will be ignored, i.e.:

         S: l/rg(rep=6,to=12000)




Foster & Andreasen           Informational                     [Page 28]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      will be treated the same as the previous example where the
      parameter "to=12000" was not included.  Of course, if the "to"
      parameter is included without the "rep", it will be acted upon
      i.e.:

         S: l/rg(to=12000)

      will ring for 12 seconds.

      It is considered an error to try and ring a phone that is off-hook
      and an error MUST consequently be returned when such attempts are
      made (error code 401 - phone off-hook).

   Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7):
      See GR-506-CORE [7], Section 14.  Default values for r1 to r5 are
      as defined for distinctive ringing pattern 1 to 5 in GR-506-CORE
      [7].  The default values for r0, r6 and r7 are normal ringing
      (i.e., the same cadence "rg").  The provisioning process may
      define the ringing cadence for each of these signals.  The
      distinctive ringing signals may be parameterized with the signal
      parameter "rep" which specifies the maximum number of ringing
      cycles (repetitions) to apply.  The value for "rep" is specified
      in decimal and can have any value from 1 to 255.

      The following will apply the ringing signal for up to 6 ringing
      cycles:

         S: l/r1(rep=6)

      If the "rep" parameter is specified, the signal times-out when the
      number of repetitions are completed (i.e., an operation complete
      event can be requested and will occur at the end of the
      timeout/number of rings)

      If the "rep" parameter is supplied, then any timeout ("to") value
      that is included will be ignored, i.e.:

         S: l/r1(rep=6,to=12000)

      will be treated the same as the previous example where the
      parameter "to=12000" was not included.  Of course, if the "to"
      parameter is included without the "rep", it will be acted upon
      i.e.:

         S: l/r1(to=12000)

      will ring for 12 seconds.




Foster & Andreasen           Informational                     [Page 29]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      It is considered an error to try and ring a phone that is off-hook
      and an error MUST consequently be returned when such attempts are
      made (error code 401 - phone off-hook).

   Reorder Tone (ro):
      This maps to congestion tone in the ITU-T E.182 [10]
      specification.  In North America, reorder tone is a combination of
      two AC tones with frequencies of 480 and 620 Hertz, and levels of
      -24 dBm each, to give a combined level of -21 dBm.  The cadence
      for reorder tone is 0.25 seconds on, followed by 0.25 seconds off,
      repeating continuously.

   Ringsplash (rs):
      Also known as "Reminder ring", this tone is a burst of ringing
      that may be applied to the physical forwarding line (when idle) to
      indicate that a call has been forwarded and to remind the user
      that a Call Forward sub-feature is active.  In the US, it is
      defined to be a 0.5(-0,+0.1) second burst of power ringing (see
      [11]).

   Distinctive Tone Pattern (s(###)):
      This is used to signal or detect a tone pattern defined by the
      parameter where the parameter may have a value from 0 to 999.
      When specified as an event, the parameter MUST be included.  The
      parameter will also be included when the event is reported.  This
      event (the definition of tones associated with each parameter
      value) requires special provisioning in the Call Agent and gateway
      to insure interoperability.  This signal is included here to
      maintain compatibility with the previous version of this package.

   Special Information Tone(sit(#)):
      As described in ITU-T E.180 [8], the special information tone
      consists of a tone period in which 3 tones are produced, followed
      by a silent period of 1 second (total TO period of approximately 2
      seconds).  It MAY be parameterized with a parameter value from 1
      to 7, with the following meaning as defined in SR-2275, section
      6.21.2 [5]:

             -------------------------------------------
            | sit(1) | RO' | reorder SIT, intra-LATA    |
            | sit(2) | RO" | reorder SIT, inter-LATA    |
            | sit(3) | NC' | no circuit SIT, intra-LATA |
            | sit(4) | NC" | no circuit SIT, inter-LATA |
            | sit(5) | IC  | intercept SIT              |
            | sit(6) | VC  | vacant code SIT            |
            | sit(7) | IO  | ineffective other SIT      |
             -------------------------------------------




Foster & Andreasen           Informational                     [Page 30]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      If the parameter is left out, the NC' SIT tone that corresponds to
      the signal "L/sit(3)" is assumed.

      Other countries may have one or more special information tones
      with country specific definitions (refer to ITU-T E.180 supp. 2
      [9]).  In this case, special information tone 1 as defined in [9]
      is sit(1), special information tone 2 is sit(2) etc.

   Stutter Dial Tone (sl):
      Stutter Dial Tone (also called Recall Dial Tone in GR-506-CORE [7]
      and "special dial tone" in ITU-T E.182 [10]) is used to confirm
      some action and request additional input from the user.  An
      example application is to cancel call-waiting, prior to entering a
      destination address.

      The stutter dial tone signal may be parameterized with the signal
      parameter "del", which will specify a delay in milliseconds to
      apply between the confirmation tone and the dial tone.  The
      parameter can have any value from 0 to 10000 ms, rounded to the
      nearest non-zero value divisible by 100 (i.e., tenth of a second).
      The following will apply stutter dial tone with a delay of 1.5
      seconds between the confirmation tone and the dial tone:

         S: l/sl(del=1500)

      It is considered an error to try and play stutter dial tone on a
      phone that is on-hook and an error MUST consequently be returned
      when such attempts are made (error code 402 - phone on-hook).

   Alerting Tone (v):
      A 440 Hz Tone of a 2 second duration, followed by a 1/2 second of
      tone every 10 seconds.  This event is included for backwards
      compatibility with the previous version of the package.

   Visual Message Waiting Indicator (vmwi):
      The transmission of the VMWI messages will conform to the
      requirements in [13] and the CPE guidelines in [12].  Refer also
      to section 6.6 of GR-30-CORE [14].  VMWI messages will only be
      sent from the gateway to the attached equipment when the line is
      idle.  If new messages arrive while the line is busy, the VMWI
      indicator message will be delayed until the line goes back to the
      idle state.  After the gateway restarts, the state of the signal
      will be "off", and hence the Call Agent MUST refresh the CPE's
      visual indicator if it is supposed to be "on".







Foster & Andreasen           Informational                     [Page 31]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Alternative Call Waiting Tones (wt, wt1, .., wt4):
      Refer to ITU-T E.180 [8].  For North American tone definitions,
      refer to GR-506-CORE [7], Section 14.2.  "wt" and "wt1" are both
      aliases for the default Call Waiting tone, which in North America,
      is a 440-Hz tone applied for 300 plus or minus 50 ms.  The tone is
      then repeated once after 10 seconds.

      These signals are timeout signals with a default timeout value of
      12 seconds, which allows the tone to be played twice with a single
      request (refer to GR-571-CORE [16]).  However, there are cases
      (Requirement R3-73 of GR-575-CORE [18]), in which only a single
      tone is required.  In that case, the Call Agent may make the
      request with a shorter timeout period to eliminate the second tone
      (e.g., "S: wt(to=2000)" - which stops the signal after 2 seconds
      so that the second tone will not occur).

      Signals wt2, wt3 and wt4 are alternates that are used for
      distinctive call-waiting tone patterns (refer to GR-506-CORE,
      Section 14.2 [7].  It is considered an error to try and apply
      call-waiting tone on a phone that is on-hook and an error MUST
      consequently be returned when such attempts are made (error code
      402 - phone on-hook).

   Recorder Warning Tone(y):
      Refer to ITU-T E.180 [8] - also Bellcore document SR-2275 [5]
      section 6.20.  When recording equipment is used, this tone is
      connected to the line to inform the distant party that the
      conversation is being recorded  - typical value used is a 1400 Hz
      Tone of a 0.5 second duration every 15 seconds.

   Calling Card Service Tone(z):
      This tone is used to inform the customer that credit card
      information must be keyed in.  Typically, it consists of 60 ms of
      941 + 1477 Hz (the DTMF #digit) and 940 ms of 350 + 440 Hz (dial
      tone), decaying exponentially with a time constant of 200 ms.
      Refer to Bellcore document SR-2275 [5], section 6.20.















Foster & Andreasen           Informational                     [Page 32]
^L
RFC 3660                  Basic MGCP Packages              December 2003


2.5.  Handset Emulation Package

   Package Name: H
   Version: 1

    ----------------------------------------------------------------
   |Symbol       |   Definition               |   R |   S  Duration |
   |----------------------------------------------------------------|
   |adsi(string) |   ADSI Display             |   x |   BR          |
   |aw           |   Answer Tone              |   x |   OO          |
   |bz           |   Busy Tone                |   x |   TO 30 sec.  |
   |ci(ti,nu,na) |   Caller-id                |   x |   BR          |
   |dl           |   Dial Tone                |   x |   TO 16  sec. |
   |e            |   Error Tone               |   x |   TO 2 sec.   |
   |hd           |   Off-hook Transition      |   S |   BR          |
   |hu           |   On-hook Transition       |   S |   BR          |
   |hf           |   Flash Hook               |   x |   BR          |
   |ht           |   Tone On Hold             |   x |   OO          |
   |lsa          |   Line Side Answer Sup.    |   x |   OO          |
   |mwi          |   Message Waiting Ind.     |   x |   TO 16 sec.  |
   |nbz          |   Network Busy             |   x |   TO infinite |
   |oc           |   Operation Complete       |   x |               |
   |ot           |   Off-hook Warning Tone    |   x |   TO infinite |
   |of           |   Operation Failure        |   x |               |
   |osi          |   Network Disconnect       |   x |   TO 900 ms   |
   |p            |   Prompt Tone              |   x |   BR          |
   |rg           |   Ringing                  |   x |   TO 180 sec. |
   |r0, r1, r2,  |   Distinctive Ringing      |   x |   TO 180 sec. |
   |r3, r4, r5,  |                            |     |               |
   |r6 or r7     |                            |     |               |
   |ro           |   Reorder Tone             |   x |   TO 30 sec.  |
   |rs           |   Ringsplash               |   x |   BR          |
   |s(###)       |   Distinctive Tone Pattern |   x |   BR          |
   |sit(#)       |   Sit Tone                 |   x |   TO 2 sec.   |
   |sl           |   Stutter Dial Tone        |   x |   TO 16 sec.  |
   |v            |   Alerting Tone            |   x |   OO          |
   |vmwi         |   Vis. Message Waiting Ind.|   x |   OO          |
   |wt           |   Call Waiting tone        |   x |   TO 12 sec.  |
   |wt1, wt2,    |   Alternative Call         |   x |   TO 12 sec   |
   |wt3, wt4     |     Waiting Tones          |     |   (see notes) |
   |y            |   Recorder Warning Tone    |   x |   TO infinite |
   |z            |   Calling Card Serv. Tone  |   x |   BR          |
    ----------------------------------------------------------------

   The handset emulation package is similar to the line package except
   that events such as "off-hook" can be signaled as well as detected.





Foster & Andreasen           Informational                     [Page 33]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Changes from the original package - are the same changes as were made
   for the line package, plus "hu" and "hd" signal types were changed
   from OO to BR.

   Event definitions are the same as for the line package with the
   following exceptions:

   ASDI:
      When requested as an event by the Call Agent, the event is not
      parameterized.  However, the parameter is included when the event
      is reported.

   Caller-id:
      When requested as an event by the Call Agent, the event MUST not
      be parameterized.  However, parameters are included when the event
      is reported i.e.:

         O: l/ci(09/14/17/26,"555 1212","John Doe")

   Line Side Answer Supervision:
      When requested as an event by the Call Agent, it indicates when
      the reverse loop current feed (RLCF) was turned on and off.  The
      event is not parameterized when it is requested.  However, a
      parameter is included when it is reported i.e.:

         O: l/lsa(+) to indicate RLCF was turned on
         O: l/lsa(-) to indicate RLCF was turned off

   Ringing (rg):
      When requested as an event, the Call Agent may optionally include
      the rep parameter indicating a request to report after some number
      of rings e.g.:

         RQNT 1234 aaln/1@rgw2.example.net
         X: AB123FE0
         R: h/rg(N)(rep=3)

      The resulting notification after the number of rings is detected
      includes the parameter again:

         NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
         X: AB123FE0
         O: h/rg(rep=3)

      If the parameter is not included in the request, it is also not
      included in the report.  In that case, the event is reported as
      soon as ringing is detected.




Foster & Andreasen           Informational                     [Page 34]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7):
      As with the "rg" event, if the "rep" parameter is included when
      one of these is requested as an event, it is also reported.  If it
      is not requested with the parameter, then the parameter is also
      not included in the report.  In that case, the event is reported
      as soon as ringing with the requested cadence is detected.

   Stutter Dial Tone (sl):
      Stutter Dial Tone MUST not be parameterized when requested as an
      event.  However, the "del" parameter is reported.

         RQNT 1234 aaln/1@rgw2.example.net
         X: AB123FE0
         R: h/sl

      The resulting notification indicates the delay between the
      confirmation tone and the dial tone:

         NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
         X: AB123FE0
         O: h/sl(del=1500)

      As with the signal, the report indicates the delay rounded to the
      nearest 100 ms.

   Visual Message Waiting:
      When requested as an event by the Call Agent, it indicates when
      the visual message waiting indicator was turned on and off.  The
      event is not parameterized when it is requested.  However, a
      parameter is included when it is reported i.e.:

         O: l/vmwi(+) to indicate message waiting turned on
         O: l/vmwi(-) to indicate message waiting turned off

   Note that:

      *  All TO signals in the handset package can include a "to"
         parameter when requested as a signal.

      *  However, requests to be notified about these events MUST NOT
         include the "to" parameter, i.e., the "to" parameter is not
         valid in RequestedEvents.









Foster & Andreasen           Informational                     [Page 35]
^L
RFC 3660                  Basic MGCP Packages              December 2003


2.6.  Supplementary Services Tone Package

   Package Name: SST
   Version: 0

    ---------------------------------------------------------------
   |Symbol       |   Definition               |   R |  S Duration  |
   |---------------------------------------------------------------|
   |cd           |   Conference Depart        |     |  BR          |
   |cj           |   Conference Join          |     |  BR          |
   |cm           |   Comfort Tone             |     |  TO infinite |
   |cw           |   Caller Waiting Tone      |     |  TO 30 sec.  |
   |ht           |   On Hold Tone             |     |  OO          |
   |ni           |   Negative Indication      |     |  TO infinite |
   |nu           |   Number Unobtainable      |     |  TO infinite |
   |oc           |   Operation Complete       |   x |              |
   |of           |   Operation Failure        |   x |              |
   |pr           |   Pay Phone Recognition    |     |  BR          |
   |pt           |   Pay Tone                 |     |  BR          |
     ----------------------------------------------------------------

   Note that default time-out values may be over-ridden by the Call
   Agent for any Time-Out signal defined in this package by a "to"
   signal parameter.  Refer to section 2 of this document, as well as
   [1] for details.

   The events in this package are defined as follows:

   Conference Depart(cd):
      Tone used to indicate that a participant has left a conference
      call.  The tone characteristics are left to the specific gateway
      implementation.

   Conference Join (cj):
      Tone used to indicate that a party has joined a conference call.
      The tone characteristics are left to the specific gateway
      implementation.

   Comfort Tone (cm):
      Comfort Tone is used to indicate that the call is being processed
      and that the caller should wait.  Refer to ITU-T E.182 [10].

   Caller Waiting Tone (cw):
      Not to be confused with a call-waiting tone, this is a tone
      advising a caller that a called station, though busy, has a call
      waiting service active.  Refer to ITU-T E.182 [10].





Foster & Andreasen           Informational                     [Page 36]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Tone on-hold (ht):
      A tone used to reassure a calling subscriber who has been placed
      on "hold".  Refer to ITU-T E.182 [10].

   Negative Indication (ni):
      A tone advising a subscriber that the request for service cannot
      be accepted.  Refer to ITU-T E.182 [10].  For North America, this
      maps to the re-order tone (see GR-506-CORE [7], Section 17.2.7).

   Number Unobtainable Tone (nu):
      Refer to ITU-T E.180, supplement 2 [9].  This is also referred to
      as "vacant tone" and maps to a "re-order tone" in North America
      (see GR-506-CORE [7], Section 17.2.7).

   Operation Complete (oc):
      The standard definition of operation complete [1].

   Operation Failure (of):
      The standard definition of operation failure [1].

   Pay Phone Recognition (pr):
      A tone advising an operator that the endpoint is identified as a
      payphone.  Refer to ITU-T E.182 [10].

   Pay Tone (pt):
      A tone indicating that payment is required.  Refer to ITU-T E.182
      [10].

2.7.  Digit Map Extension

   Package Name: dm1  ("dm" followed by the number "1")
   Version: 0
   Extension Digit Map Letters: P

   This package defines an Extension Digit Map Letter that is used to
   override the shortest possible match behavior for a given entry in a
   digit map (see [1]).  The letter "P" (for partial match override), at
   the end of a digit map entry, instructs the gateway to only consider
   that entry a match if the current dial string does not partially
   match another entry.  For example, given the digit map

      ([3-7]11|123xxxxxxx|[1-7]xxxxxxP|8xxxP)

   and a current dial string of "1234567", we would not consider this a
   match (as the rules in [1] would otherwise imply); however a current
   dial string of "411" would be considered a match as usual.  A current
   dial string of "8234" would be considered a match since there is no
   other partial match.



Foster & Andreasen           Informational                     [Page 37]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Note that the digit map letter "P" is not an event, but simply a
   syntactic and semantic digit map extension.  Thus, the "P" is not
   included in the list of requested or observed events.

   Support for this package is strongly RECOMMENDED.

2.8.  Signal List Package

   Package Name: SL
   Version: 0

    ---------------------------------------------------------
   | Symbol  |   Definition             |  R  | S   Duration |
   |---------------------------------------------------------|
   | oc      |  Operation Complete      |  x  |              |
   | of      |  Operation Failure       |  x  |              |
   | s(list) |  Signal List             |     | TO  variable |
    ---------------------------------------------------------

   Operation Complete (oc):
      This is the standard definition of operation complete from [1].

   Operation Failure (of):
      This is the standard definition of operation failure from [1].

   Signal List(s(<list>)):
      The <list> contains a comma-separated list of signals to be played
      out.  Each of the signals in <list> MUST be either of type BR or
      type TO.  Semantically, the signal list is still treated as a
      single parameterized signal of type Time-Out though.  The signals
      in the list are played to completion one after the other in the
      left to right order specified.  The package for each signal in the
      list must be specified.  For example, to play out the DTMF digits
      123456:

         S: sl/s(d/1,d/2,d/3,d/4,d/5,d/6)

      This will result in the DTMF digits 1, 2, 3, 4, 5 and 6 being
      played out in order.

      It is illegal to include an OO signal as one of the signals in the
      list or to request recursive definitions (signal lists within
      signal lists).  If this or any other unsupported signal is
      included, error code 538 (event/signal parameter error) MUST be
      returned by the gateway.






Foster & Andreasen           Informational                     [Page 38]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      Note that as the gateway plays the ordered list of signals, if it
      encounters a TO signal with an infinite timeout, it will continue
      to play that signal until the Signal List signal is stopped (i.e.,
      other signals later in the list will never be played).

      If the operation complete ("oc") event is requested, it will be
      detected once, when the last signal in the list has been played
      out (regardless of whether there are any TO signals in the list).
      The operation complete event will only report the signal list name
      itself, i.e., without the parameters supplied as in:

         O:   sl/oc(sl/s)

      Should any of the signals in the signal list result in an error,
      an operation failure event for the Signal List signal MUST be
      generated.  Only the signal list name will be included, thus it is
      not possible to determine which of the signals in the signal list
      actually failed.

      Note that if an event occurs while the "SL/S" signal is playing,
      the "SL/S" signal is stopped in the following manner:

         *  If the signal in the list that was playing at the time the
            event occurred is of type BR, then the BR signal will be
            played to completion and no other signals in the list will
            be played.

         *  If the signal in the list that was playing at the time the
            event occurred is of type TO, then the TO signal will stop
            immediately and no other signals in the list will be played.

2.9.  Media Format Parameter Package

   Package Name: FM
   Version: 0

   This package provides support for the media format parameter Local
   Connection Option (LCO).  The media format parameter LCO is similar
   to the "fmtp" attribute in SDP [15] and is applicable to all of the
   same media formats that the corresponding SDP fmtp attribute could be
   used with (i.e., media format parameters for any media format MIME
   type).  The media format parameter is encoded as the keyword "fmtp"
   or "o-fmtp", followed by a colon and a quoted string beginning with
   the media format name (MIME subtype only) followed by a space,
   followed by the media format parameters associated with that media
   format.  For simplicity, we will use the terms "codec" and "media





Foster & Andreasen           Informational                     [Page 39]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   format" interchangeably in the following.  Multiple formats may be
   indicated by either repeating the "fmtp" local connection option
   multiple times, such as:

      L:a:codec1;codec2, fmtp:"codec1 formatX", fmtp:"codec2 formatY"

   or alternatively by having a single "fmtp" keyword followed by a
   colon, and a semi-colon separated list of quoted strings for each
   media format parameter, as in:

      L:a:codec1;codec2, fmtp:"codec1 formatX";"codec2 formatY"

   The two formats may be mixed.

   If it is possible for the same codec to be requested with and without
   the special "fmtp" format, the following could result:

      L:a:codec1;codec1, fmtp:"codec1 formatX"

   However, it would not be clear if the fmtp parameter was to be
   applied to the first or the second occurrence of the codec.  The
   problem with that is, that codec ordering is important (i.e., codecs
   are listed in preferred order), and the above syntax does not provide
   a way to indicate if "formatX" is preferred (i.e., associated with
   the first "codec1") or not (i.e., associated with the second
   "codec1").  In order to resolve this dilemma, when the same codec is
   requested with multiple formats, the codec name in the "fmtp" format
   string is followed by a colon and an <order>, where <order> is a
   number from one to N for N occurrences of the same codec in the codec
   list i.e.:

      L:a:codec1;codec1, fmtp:"codec1:2 formatX"

   indicates that "formatX" is associated with the second instance of
   "codec1" in the "a:codec1;codec1" list.  If an invalid instance
   number is supplied (e.g., instance 3 where there are only two
   instances), then error code 524 - inconsistency in local connection
   options will be returned.

   Pre-pending "fmtp" with the string "o-" (i.e., "o-fmtp") indicates
   that the format is optional.  In that case, the gateway may decide
   not to use the fmtp parameter specified, or only use it in part.

   If the "fmtp" in an LCO is not optional (i.e., does not have "o-" in
   front of it), and the LCO value is either not recognized or not
   supported, then the associated codec is considered "not supported".





Foster & Andreasen           Informational                     [Page 40]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   When auditing capabilities, the "fmtp" local connection option MUST
   be returned with a semi-colon separated list of supported formats
   and/or multiple independent "fmtp" parameters as in:

      A: a:telephone-event, fmtp:"telephone-event 0-15,32-35",...

      A: a:PCMU;G729, fmtp:"PCMU foo";"PCMU bar", fmtp:"G729 foobar",...

   One example uses the media format parameter LCO in conjunction with
   the media format "telephone-event", as defined in RFC 2833 [33].  If
   the media format "telephone-event" is used without the "fmtp" media
   format parameter, the DTMF digits (telephone events 0-15 from RFC
   2833 [33]) are assumed - such practice is however discouraged.  On
   the other hand, the media format parameter LCO MAY be used to specify
   the exact set of events that are being requested via RFC 2833 [33].
   Example:

      L: a:PCMU;telephone-event,fmtp:"telephone-event 16"

   indicates that if telephone events are supported at all, then this
   request is specifically for event 16.

   In another case, the Call Agent may indicate that some format
   parameters are "required", while others are optional.  In the example
   below, telephone events 0-15 are a "must", while telephone events 16,
   70 and 71 are optional.

      L: a:PCMU;telephone-event, o-fmtp:"telephone-event 16,70,71",
      fmtp:"telephone-event 0-15"

   If the gateway cannot support telephone events 0-15, it MUST NOT
   include the "telephone-event" media format in the SDP in its
   response.  On the other hand, if it can support those telephone
   events, it SHOULD indicate support for those events, as well as any
   of the events 16, 70 and 71 that it supports.

   If a request is made to audit the capabilities of an endpoint, and
   the endpoint supports the "telephone event" media format with events
   "0-16", then the audit would include the following:

      A: a:telephone-event, fmtp: "telephone-event 0-16"

   Another example is the use of redundancy with RFC 2198 [32].  Again,
   the format of the fmtp string is similar to that used in the SDP
   except that the literal string ("red" in this case) is used rather
   than the payload type:

      L: a:G729;pcmu;red,fmtp:"red pcmu/g729"



Foster & Andreasen           Informational                     [Page 41]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   The corresponding media description in the SDP as part of the
   connection request acknowledgment might look like:

      m=audio 12345 RTP/AVP 98 18 0
      a=rtpmap:98 red/8000/1
      a=fmtp:98 0/18

   If we combine both telephone events and redundancy, an example local
   connection option might look as follows (carriage return added for
   formatting reasons here):

      L: a:G729;pcmu;red;telephone-event,fmtp:"red pcmu/g729",
                                         fmtp: "telephone-event 16"

   Note that we again specify the literal string for the encoding method
   rather than its payload type.  This is a general principle that
   should be used with this LocalConnectionOption.

   The corresponding SDP might appear as follows:

      m=audio 12345 RTP/AVP 97 98 18 0
      a=rtpmap:97 red/8000/1
      a=fmtp:97 0/18
      a=rtpmap:98 telephone event
      a=fmtp:98 16

   Note that the fmtp LCO may be used in any situation where the
   corresponding SDP attribute may be used.  An example of a local
   connection option that involves a media type other than audio and a
   "foobar" fmtp parameter:

      L: a:image/tiff, fmtp:"tiff foobar"

   Note that normally local connection options that are associated with
   a package should have the package prefix included as per the package
   extension rules in [1].  The "fmtp" and "o-fmtp" LCO in the "FM"
   package are an exception.  The package prefix is not included in the
   case of the "fmtp" and "o-fmtp" local connection options because they
   were created before the extension rules in [1] were defined.

   These two LocalConnectionOptions have been registered with IANA.










Foster & Andreasen           Informational                     [Page 42]
^L
RFC 3660                  Basic MGCP Packages              December 2003


2.10.  RTP Package

   Package Name: R
   Version: 1

    -------------------------------------------------------------
   | Symbol  |   Definition                 |   R |   S Duration |
   |-------------------------------------------------------------|
   | co1     |   Continuity Tone (single    |   C | TO,C 3 sec.  |
   |         |     or return tone)          |     |              |
   | co2     |   Continuity Test (go tone,  |   C | TO,C 3 sec.  |
   |         |     in dual tone procedures) |     |              |
   | iu(..)  |   ICMP Unreachable           |   C |              |
   |         |     Received                 |     |              |
   | ji(..)  |   Jitter Buffer Size Changed |   C |              |
   | ma      |   Media Start                |   C |              |
   | oc      |   Operation Complete         |   x |              |
   | of      |   Operation Failure          |   x |              |
   | pl(..)  |   Packet Loss Exceeded       |   C |              |
   | qa      |   Quality Alert              |   C |              |
   | rto(..) |   RTP/RTCP Timeout           |   C |              |
   | sr      |   Sampling Rate Changed      |   C |              |
   | uc      |   Used Codec Changed         |   C |              |
    -------------------------------------------------------------

   Changes in event types: "co1" and "co2" signals changed from OO to
   TO.

   New events added to this package from the previously unversioned
   package: "iu", "rto", "ma".

   Note that default time-out values may be over-ridden by the Call
   Agent for any Time-Out signal defined in this package by a "to"
   signal parameter.  Refer to section 2 of this document, as well as
   [1] for details.

   The events in this package all refer to media streams (connections),
   i.e., they cannot be detected on an endpoint.  Furthermore, with the
   exception of the "iu" event, which is defined for any type of media,
   all other events in this package are defined for RTP media streams
   only (i.e., if they are used on connections that do not use RTP, the
   behavior is not defined).

   Signals requested (e.g., "co1" and "co2") must indicate the
   connection ID (e.g., "S: r/co1@connectionID").  An event may be
   requested for all existing connections using the "*" wildcard for the
   connectionID as described in [1].




Foster & Andreasen           Informational                     [Page 43]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Example:

      R: r/uc@*    (request to detect uc on all connections) or

      R: r/uc@connectionID   (request to detect uc only on a specific
      connection)

   An event detected on a connection will include the connectionID,
   e.g.:

      O: r/uc@connectionID(15)

   Continuity tones (co1 and co2):
      These are the same as the events defined in the Trunk package,
      except in this case, they are only played over a network
      connection and the connectionID MUST be supplied (e.g., "s:
      r/co1@connectionID").  They can be used in conjunction with the
      Network LoopBack (netwloop) or Network Continuity Test (netwtest)
      modes to test the continuity of an RTP circuit.  However, in the
      case of testing IP continuity, a one-tone test is sufficient i.e.,
      generating and detecting "co1" at one end, with connection mode in
      network loopback mode at the other end.  Note that the test can
      also be done using telephone events rather than tones, i.e., event
      167 in RFC 2833 [33] corresponds to "co1".  In this case,
      connection requests are made with local connection options such
      as:

         L: a:PCMU;telephone-event,fmtp:"telephone-event 167"

      in order to request support for telephone event 167.  If both ends
      support the event, then the network loopback proceeds as usual,
      except that telephone events corresponding to the co1 tone are
      sent, as opposed to the co1 tone itself.

   ICMP Unreachable Received (iu):
      This event indicates that some number of ICMP unreachable packets
      [19] was received for this connection since an RQNT was received
      requesting this event.  This notification indicates that packets
      that were sent by the gateway on this connection either did not
      arrive at their destination or were not accepted (e.g., the port
      was closed).  When this event is requested, a single parameter
      with a decimal number from 1 to 255 may be included to indicate
      the number of ICMP un-reachable packets that must occur before the
      event is notified.  If no parameter is supplied, with the request
      then a default value of 3 is assumed.  This is a one-shot event in
      that once the event occurs, a further request is required in order
      to re-initiate counting.




Foster & Andreasen           Informational                     [Page 44]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      The observed event is parameterized with two parameters:

         *  The first parameter is the number of ICMP unreachable
            packets received (i.e., the same value that was included in
            the request - or the value 3, if the requested event was not
            parameterized)

         *  The second parameter is the error code indicated in the ICMP
            unreachable packet, e.g.:

               0 = net unreachable;

               1 = host unreachable;

               2 = protocol unreachable;

               3 = port unreachable;

               4 = fragmentation needed and DF set;

               5 = source route failed.

               etc.

      An example of a request might be as follows:

         RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
         X: 0123456789B0
         R: r/iu@364823(N)(5)

      In this case, a notify will occur if 5 ICMP port unreachable
      packets are received as a result of RTP and/or RTCP packets being
      sent from this gateway on the connection with connection ID
      364823.

      The resulting NTFY with observed events might be as follows:

         NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
         X: 0123456789B0
         O: r/iu@364823(5,3)

      The first parameter indicates 5 ICMP unreachable packets were
      received since the RQNT with this request was sent.  The second
      parameter ("3") specifies the reason, which in this case, is "port
      unreachable".






Foster & Andreasen           Informational                     [Page 45]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Jitter Buffer Size Changed (ji):
      This event is only included here to maintain compatibility with
      the previous version of this package.  This event is used to
      indicate that the gateway has made an adjustment to the depth of
      the jitter buffer.  The syntax for requesting notification is
      "ji", which tells the media gateway that the controller wants
      notification of any jitter buffer size changes.  The syntax for
      notification from the media gateway to the controller is
      "JI(####)", where the #### is a decimal number from 1 to 65536,
      indicating the new size of the jitter buffer in milliseconds.

   Media Start (ma):
      The media start event occurs on a connection when the first valid
      RTP media packet is received on the connection.  This event can be
      used to synchronize a local signal, e.g., ringback, with the
      arrival of media from the other party.

      The event is detected on a connection.  If no connection is
      specified, the event applies to all connections for the endpoint,
      regardless of when the connections are created (i.e., if a
      connection is not specified, the event will occur when the first
      valid RTP packet arrives on any one of the connections on that
      endpoint).

   Operation complete (oc):
      This is the standard definition of operation complete [1].

   Operation failure (of):
      This is the standard definition of operation failure [1].

   Packet Loss Exceeded (pl):
      Packet loss rate exceeds the threshold of the specified decimal
      number (with a range of 1 to 100,000) of packets per 100,000
      packets, where the packet loss number is indicated in parenthesis.
      For example, PL(10) is a drop rate of 10 in 100,000 packets.  This
      event is requested with a parameter indicating at what packet loss
      rate the Call Agent wishes to be reported.  If the packet loss
      exceeds that value, the event is reported with that same
      parameter.  The event is only reported once when the packet loss
      threshold is exceeded.  Once reported, a following request will
      re-initiate packet loss measurements and report when the threshold
      is exceeded again.

   Quality alert (qa):
      The packet loss rate or the combination of delay and jitter
      exceeding a quality threshold.  The quality thresholds for delay,
      jitter and packet loss rate are provisioned values.




Foster & Andreasen           Informational                     [Page 46]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   RTP/RTCP Timeout (rto(<timeout>,st=<start-time>)):
      This event indicates that neither RTP nor RTCP packets have been
      received on this connection for a period of time equal to the
      <timeout> value (in seconds).  The timeout value can be supplied
      as a decimal number from 1 to 65535 in the parameter when the
      request is made.  The <timeout> parameter will be supplied in
      ObservedEvents when the event is reported - it then simply repeats
      the value used.  If an RTP or RTCP packet is received before the
      timer expires, then the timer is reset and re-started.  The event
      will only be generated if the timer expires without an RTP or RTCP
      packet arriving on the specified connection during the specified
      period of time.  Note that if the event is requested without the
      <timeout> parameter, then a default timeout of 60 seconds is
      assumed.  The <timeout> value will still be reported in
      ObservedEvents, even if no timeout value was indicated in the
      request (the default value will be indicated in that case).  This
      is a one-shot event in that once the event occurs, a further
      request is required in order to re-initialize the timer.

      Another optional <start-time> parameter may also be included.
      This is used to indicate when the timer starts.  It can have one
      of the following values:

         *  "im" for immediate i.e., the timer starts as soon as the
            request is received.  This is the default.

         *  "ra" to indicate that the timer should start only after an
            RTCP packet has been received from the other end (i.e., the
            timer will be initiated when the first RTCP packet is
            received after the request is made).  Note that in the case
            where the other end does not support RTCP, the timer will
            never be initiated.

      Note that either the <timeout> or <start-time> may be included in
      the request, but only the <timeout> value is included in the
      report.

      An example of a request might be as follows:

         RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
         X: 0123456789B0
         R: r/rto@364823(N)(120,st=im)

      In this case, a notify will occur if there is a period of time
      when no RTP or RTCP packets have been received on connection
      364823 for 120 seconds.





Foster & Andreasen           Informational                     [Page 47]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      The resulting NTFY with observed events would be as follows:

         NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
         X: 0123456789B0
         O: r/rto@364823(120)

   Sampling Rate Changed (sr):
      This event is only included here to maintain compatibility with
      the previous version of this package.  This event indicates that
      the packetization period changed to some decimal number in
      milliseconds enclosed in parenthesis, as in SR(20).

   Used Codec Changed (uc):
      This event is only included here to maintain compatibility with
      the previous version of this package.  This event is requested
      without a parameter, but when reported, the hexadecimal payload
      type is enclosed in parenthesis, as in UC(8), to indicate the
      codec was changed to PCM A-law.  Codec Numbers are specified in
      RFC 3551 [26], or in a new definition of the audio profiles for
      RTP that replaces this RFC.

2.11.  Resource Reservation Package

   Package Name: RES
   Version: 0

2.11.1.  Description

   The "RES" package provides local connection option support for
   resource reservations as well as an event to indicate reservation
   loss.

   A number of LocalConnectionOption parameters are used in doing
   resource reservations: "reservation request", "reservation
   direction", "reservation confirmation" and "resource sharing".

   Reservation Request LocalConnectionOption: The gateways can be
   instructed to perform a reservation on a given connection using RSVP.
   When a reservation is needed, the Call Agent will specify the
   reservation profile that should be used, which is either "controlled
   load" or "guaranteed service".  The absence of reservation can be
   indicated by asking for the "best effort" service, which is the
   default value for this parameter.

   Whether or not RSVP will be done is dependent on whether the
   reservation request LocalConnectionOption parameter has been included
   in a connection request for this connection (with either "controlled
   load" or "guaranteed service" indicated).  If a modify connection



Foster & Andreasen           Informational                     [Page 48]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   (MDCX) request requires a change in the reservation and the
   "reservation request" parameter is not included in the
   LocalConnectionOptions, but was included in the
   LocalConnectionOptions for a previous connection request for that
   connection, then the "reservation request" value defaults to its
   previously saved value for that connection.  If a modify connection
   (MDCX) request explicitly contains a "reservation request",
   indicating a request for "best effort" for a connection that has an
   existing reservation, the existing reservation will be torn down.

   Reservation Direction LocalConnectionOption:
      When reservation has been requested on a connection, the gateway
      will examine the reservation direction LocalConnectionOption
      parameter to determine the direction that the reservations require
      and do the following:

         *  Start emitting RSVP "PATH" messages if the reservation
            direction LocalConnectionOptions parameter specified "send-
            only" or "send-receive".

         *  Start emitting RSVP "RESV" messages as soon as it receives
            "PATH" messages if the reservation direction parameter
            specified "receive-only" or "send-receive".

      If an RSVP reservation is requested, but the reservation direction
      LocalConnectionOption parameter is missing, the reservation
      direction defaults to the previously saved value of the
      reservation direction parameter for that connection.  If there was
      no previous reservation direction parameter for that connection,
      the value is deduced from the connection mode.  That is:

         *  Start emitting RSVP "PATH" messages if the connection is in
            "send-only", "send-receive", "conference", "network loop
            back" or "network continuity test" mode (if a remote
            connection descriptor has been received).

         *  Start emitting RSVP "RESV" messages as soon as it receives
            "PATH" messages if the connection is in "receive-only",
            "send-receive", "conference", "network loop back" or
            "network continuity test" mode.

   Reservation Confirmation LocalConnectionOption:
      Another LocalConnectionOption parameter for RSVP reservations is
      the reservation confirmation parameter, which determines what the
      resource reservation pre-condition (see [1]) is for acknowledging
      a successful connection request:





Foster & Andreasen           Informational                     [Page 49]
^L
RFC 3660                  Basic MGCP Packages              December 2003


         *  If the reservation confirmation parameter is set to "none",
            the gateway will "Ack" the connection request without
            waiting for reservation completion.  This is the default
            behavior.

         *  If the "reservation confirmation" parameter is set to
            "send-only", the gateway will "Ack" when the PATH message
            has been sent and the corresponding RESV is received to
            indicate successful reservation in the send direction.

         *  If the "reservation confirmation" parameter is set to
            "receive-only", the gateway will "Ack" when reservation
            confirm for a reservation has been received.

         *  If the reservation confirmation parameter is set to "send-
            receive", the gateway will "Ack" only after the PATH message
            has been sent and the corresponding RESV has been received
            for send direction, and reservation confirm has been
            received for the receive direction.

   Note that:

      Values "receive-only" and "send-receive" are triggers for the
      gateway to request reservation confirm (RESVCONF) when it sends
      out the RESV.

      Pre-conditions SHOULD only be added for the direction(s) for which
      resource reservations have been requested.  If a direction is
      added as a pre-condition, and that direction was not requested in
      the resource reservation, the direction MUST simply be ignored as
      a pre-condition.

      In this approach, resource reservation success is the pre-
      condition to final acknowledgement of the connection request.  If
      the reservation fails, the connection request also fails (error
      code 404 - insufficient bandwidth) - as will any other part of the
      transaction, e.g., a notification request included as part of the
      connection request.  A typical example of this would be a request
      to ring the phone and look for off-hook, included with the
      connection request.  If the reservation fails, the phone will not
      ring.  Similarly, if the phone is already off-hook, the command
      fails and there will be no resource reservation.

      A provisional response SHOULD be provided if confirmation is
      expected to occur outside the normal retry timers and in fact a
      provisional response MUST be provided if the reservation
      confirmation parameter has value "send-receive" (without a
      provisional response, SDP information cannot be returned until the



Foster & Andreasen           Informational                     [Page 50]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      final "Ack" which will not occur until the reservation is
      complete.  This can result in a deadlock since the SDP information
      typically needs to be passed to the other end in order for it to
      initiate the RSVP PATH message in the other direction).  The SDP
      information and connectionID MUST be included in both the
      provisional response and the final response.  Note that in order
      to ensure rapid detection of a lost final response, final
      responses issued after provisional responses for a transaction
      SHALL be acknowledged, i.e., they SHALL include an empty
      "ResponseAck" parameter in the final response (see [1]).

      If the transaction time is outside the expected bounds (time
      T-HIST - see the section on provisional responses in [1]), error
      code 406 (transaction timeout) SHOULD be returned.

      Also note that if the reservation confirmation parameter is
      omitted, the value of the reservation confirmation parameter
      defaults to its previously saved value.  If there is no previously
      saved value for the reservation confirmation parameter, or the
      reservation confirmation parameter has the value "none", then
      successful resource reservation is not a pre-condition to
      providing an acknowledgement to the connection request (i.e., the
      gateway can "Ack" right away without waiting for the reservation
      to complete and a provisional response will not be necessary).

   Resource Sharing LocalConnectionOption:
      It may be possible to share network resources across multiple
      connections.  An example is a call-waiting scenario, where only
      one connection will ever be active at a time.  In a 3-way calling
      scenario with a similar set of connections, sharing is not
      possible.  Only the Call Agent knows what may be possible,
      depending on the feature that is being invoked.

      In order to allow the Call Agent to indicate that sharing is
      possible, a resource sharing LocalConnectionOption parameter is
      introduced.  This parameter can have one of the following values:

         *  A value "$" can be specified where $ refers to "this
            connection".  This value is used when doing a create
            connection and indicates the intent to share resources with
            this connection.

         *  A connection ID can be specified which indicates that this
            is a request to share resources with the connection having
            this connection ID (allowing multiple connections to share
            resources with the connection indicated).





Foster & Andreasen           Informational                     [Page 51]
^L
RFC 3660                  Basic MGCP Packages              December 2003


         *  The value can be empty, which indicates a request to no
            longer share the resources of this connection with other
            connections.

      In the case of a CRCX, the default value for the resource sharing
      local connection option is empty, and for an MDCX, the default
      value is its current value.

   The RSVP filters will be deduced from the characteristics of the
   connection.  The RSVP resource profiles will be deduced from the
   connection's bandwidth and packetization period.

   Note that if RSVP is used with PacketCable Dynamic Quality of Service
   [35], then the parameters in NCS [36] would be used instead of the
   reservation direction, confirmation and reservation sharing
   parameters described here.

2.11.2.  Parameter Encoding

   The Local Connection Options for the "RES" package consist of the
   following:

      *  The resource reservation parameter, encoded as the keyword "r",
         followed by a colon and the value "g" (guaranteed service),
         "cl" (controlled load) or "be" (best effort).

      *  The reservation direction parameter, encoded as the keyword
         "r-dir" followed by a colon and the value "sendonly",
         "recvonly" or "sendrecv".

      *  The reservation confirmation parameter, encoded as the keyword
         "r-cnf" followed by a colon and the value "none", "sendonly",
         "recvonly" or "sendrecv".

      *  The resource sharing parameter, encoded as the keyword "r-sh"
         followed by a colon and either:

            *  The wild-card character "$" indicating this connection,
               indicating future plans to share resources with this
               connection, or

            *  A connection ID, indicating a request to share resources
               with the connection having the specified connection ID
               (and all other connections sharing resources with that
               connection), or






Foster & Andreasen           Informational                     [Page 52]
^L
RFC 3660                  Basic MGCP Packages              December 2003


            *  An empty value (i.e., "r-sh:" with no value indicated),
               indicating a request to no longer share the resources of
               this connection with other connections

   Note that normally local connection options that are associated with
   a package have the package prefix included as per the package
   extension rules in [1].  The local connection options in the "RES"
   package are exceptions.  The package prefix is not included in the
   case of the "RES" package because it was created before the extension
   rules in [1] were defined.

2.11.3.  Events

   The following events are included as part of the resource reservation
   package:

    ------------------------------------------------------
   | Symbol  | Definition           |   R |   S  Duration |
   |------------------------------------------------------|
   |  re     | Resource Error       |   C |               |
   |  rl     | Resource Lost        |   C |               |
    ------------------------------------------------------

   Resource Error (re):
      This is an indication that an error in the resource reservation
      occurred during the life of the connection.  This event is not
      requested with a parameter, but is reported with a parameter (see
      possible values below).  This event may or may not indicate the
      permanent loss of the reservation (i.e., any error associated with
      the reservation whether permanent or temporary will be reported).
      If requested on an endpoint (without specifying the connection
      ID), the request refers to all present and future connections on
      that endpoint.  When reported, the connectionID is always supplied
      along with a reason for the error indicated as a parameter.  One
      of the following possible reasons for loss MUST be included as the
      parameter when the event is reported:

         -  "resverr" is used to indicate that a ResvErr message was
            received.

         -  "patherr" is used to indicate that a PathErr message was
            received.

         -  "other"

      In addition to a parameter indicating one of the reasons above,
      additional information on the type of error MAY be included as a
      second parameter in the form of a quoted string.



Foster & Andreasen           Informational                     [Page 53]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      Example report might include:

         O: res/rl@0A3F58(resverr)

      or

         O: res/rl@0A3F58(resverr, "some additional commentary")

      Note that this event will not be reported if an error occurs while
      a resource reservation is initially being set up (i.e., the event
      was only reported as a result of an error that occurred after the
      reservation was set up).

   Resource Lost (rl):
      Loss of reservation during the life of a connection can be
      reported by using the "rl" event.  This event is not requested
      with a parameter, but is reported with a parameter (see below for
      possible values).  If requested on an endpoint (without specifying
      the connection ID), the request refers to all present and future
      connections on that endpoint.

      When reported, the connectionID is always supplied along with a
      reason for the loss indicated as a parameter.  One of the
      following possible reasons for loss MUST be supplied as the
      parameter when the event is reported:

         -  "resvtear" indicating that the reservation loss was
            indicated by ResvTear message.

         -  "pathtear" indicating that the reservation loss was
            indicated by PathTear message.

         -  "other"

      In addition to a parameter indicating one of the reasons above,
      additional information on the type of error MAY be included as a
      second parameter in the form of a quoted string.

      Example report might include:

         O: res/rl@0A3F58(ResvTear)

      or

         O: res/rl@0A3F58(ResvTear, "some other commentary")






Foster & Andreasen           Informational                     [Page 54]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      Note that this event will not be reported if an error occurs while
      a resource reservation is initially being set up (i.e., the event
      is only reported if the reservation was lost after it was
      initially set up).

2.12.  Announcement Server Package

   Package Name: A
   Version: 1

    ---------------------------------------------------------------
   | Symbol         | Definition           |   R |  S     Duration |
   |---------------------------------------------------------------|
   | ann(url)       | Play an Announcement |     |  TO, C variable |
   | oc             | Operation Complete   |   x |                 |
   | of             | Operation Failure    |   x |                 |
    ---------------------------------------------------------------

   Changes from the previous version: change to conform to standard
   reporting of operation failure and operation complete events.

   The announcement signal is qualified by a URL name:

      S: ann(http://scripts.example.net/all-lines-busy.au)

   The URL name MAY be followed by a list of initial parameters,
   separated by commas.  However, standard parameters are not included
   as part of this package definition (Note: use of additional
   parameters is optional and would result in a proprietary interface).

   The gateway SHOULD support one or more standard URL schemes such as:

      *  file, http, ftp (RFC 1738 [28]), which indicate where the audio
         file is located (where to load the file from before playing the
         audio file on the gateway).

      *  RTSP URL (section 3.2 of RFC 2326 [29]), which in this case
         allows the media gateway to directly initiate playing of the
         announcement via an RTSP server.

   The pre-condition for a successful response (return code of "200") is
   correct syntax and capability (support is available for this
   request).  Standard MGCP return codes apply in the case of failure.
   Further indications of failure are provided in the operation failure
   event as a comment after the name of the failed event in the form of
   a quoted string.





Foster & Andreasen           Informational                     [Page 55]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   If the announcement cannot be played out for a reason determined
   after a successful response to the request has been provided, an
   operation failure event will be returned.  The failure MAY be
   explained by some commentary (in the form of a quoted string), as in:

      O: a/of(a/ann,"file not found")

   The "operation complete" event will be detected when the announcement
   is played out.

      O: a/oc(a/ann)

2.13.  Script Package

   Package Name: Script
   Version: 1

    -----------------------------------------------------------------
   | Symbol       |   Definition              | R |  S  |   Duration |
   |-----------------------------------------------------------------|
   | ir(..)        | Intermediate Results/Req.| x |  BR |            |
   | java(url,...) | Load & Run java script   |   |  TO |   variable |
   | oc            | operation complete       | x |     |            |
   | of            | operation failure        | x |     |            |
   | perl(url,...) | Load & Run perl script   |   |  TO |   variable |
   | tcl(url,...)  | Load & Run TCL script    |   |  TO |   variable |
   | vxml(url,...) | Load & Run VXML doc.     |   |  TO |   variable |
   | xml(url,...)  | Load & Run XML script    |   |  TO |   variable |
    -----------------------------------------------------------------

   Changes from the previous version of the package: "vxml" was added as
   a language type for loading and running VXML documents; change to
   conform with standard reporting of operation failure and operation
   complete events; addition of "ir" event.

   The current definition defines keywords for the most common
   languages.  More languages may be defined in later versions of this
   package.

   The "signal" specifying the scripting language is parameterized with
   a URL indicating the location of the script.  The URL parameter MAY
   be optionally followed by a comma-separated list of arguments as
   initial parameters to use in running the script.  URL schemes may
   include file ftp, or http schemes with syntax according to RFC 2396
   [30].  As an example:

      S: script/vxml(ftp://ftp.example.net/credit-card.vxml,arg1,arg2,
                                                              ...,argn)



Foster & Andreasen           Informational                     [Page 56]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   The argument list "arg1,arg2,...,argn" is passed to the
   script/document as a list of initial parameters.

   The pre-condition for a successful response (return code of "200") is
   correct syntax and capability (support is available for this
   request).  Standard MGCP return codes apply in the case of failure.
   Some further (non-application/script specific) failure indications
   MAY be provided in the operation failure event as a comment in the
   form of a quoted string following the name of the failed event.

   Example

      O: script/of(script/vxml,"file not found")

   The script produces an output, which consists of one or several text
   strings, separated by commas.  This provides the return-status of the
   script as well as return parameters (if there are any)

      O: script/oc(script/vxml,return-status=<status>,
                        name1=value1,name2=value2,...)

   where <status> can have one of the values "success" or "failure".
   This is then followed by output parameters as a comma-separated list
   of name-value pairs.

   Intermediate Result/Request (ir(<params>)):
      This provides a way for:

         *  The script to inform the Call Agent of intermediate results
            (e.g., a case where it is important because of timing
            concerns to inform the Call Agent prior to operation
            complete).

         *  The script to request some information from the Call Agent.

         *  The Call Agent to inform the script of some event or
            information that may be important for the operation of the
            script (in this case "ir" is used as a signal).

      Parameters (i.e., <params>) SHOULD be a comma-separated list of
      name-value pairs e.g., ir(name1=value1,name2=value2,..).  The Call
      Agent MAY include event parameters when it requests this event, in
      which case, the MGCP syntax requirements require that the action
      be specified (e.g., "R: ir(N)(nam1=value1,name2=value2,..)").

      If the Call Agent requests "ir" as a signal, at least one
      parameter MUST be provided.




Foster & Andreasen           Informational                     [Page 57]
^L
RFC 3660                  Basic MGCP Packages              December 2003


      When requesting the "ir" signal, the Call Agent MUST also repeat
      the original script signal.  This is in order to be consistent
      with the semantics of TO signals in MGCP (i.e., if the original
      "script" signal is not included, then the signal/script will be
      stopped).  The only problem with this is that there is a possible
      race condition in which a request to send an "ir" signal could
      occur just as the script stopped.  In order to avoid this
      confusion, the following is RECOMMENDED: when the script signal is
      included with an "ir" signal, include a parameter (of the script
      signal) to indicate that this is not a new instance of the script
      i.e., if there is no script executing at the present time do not
      start executing a new one.

      The "ir" signal is only associated with an executing script.  If
      none are running when a request for the event/signal is made, or
      if a new script request is not included with the request, then the
      "ir" signal/event will not be executed (i.e., the "ir" event with
      its parameters is passed to an existing script for parsing and
      execution and is considered opaque as far as MGCP as concerned.
      If no such script exists, response code "800" will be returned,
      indicating that the script is not executing).

   The following response code is associated with this package:

      Code    Text                 Explanation

      800     Script not           Request for "ir" signal or event
              Executing            but no script is executing at the
                                   time the request was received.

      Note that package specific error codes include the package name
      following the error code.  For example, if error code 800 occurs
      in response to a request with a transaction ID of 1001, it would
      be sent as:

         800 1001 /SCRIPT















Foster & Andreasen           Informational                     [Page 58]
^L
RFC 3660                  Basic MGCP Packages              December 2003


3.  IANA Considerations

   The following packages and their versions have been registered with
   IANA as per the instructions in [1].

      Package Title         Name     Version
      -------------         ----     -------
      Announcement           A        1
      DTMF                   D        1
      Digit Map Extension    DM1      0
      Media Format           FM       0
      Generic                G        1
      Handset                H        1
      Line                   L        1
      RTP                    R        1
      Resource Reservation   RES      0
      Script                 SCRIPT   1
      Supplementary Tones    SST      0
      Signal List            SL       0
      Trunk                  T        1

   The following extension digit map letter has been registered with
   IANA:

      Package Letter
      ------- ------
      DM1     P

   The following Local Connections have been registered with IANA:

      Field                       Name
      -------                     -----
      Media Format                fmtp
      Reservation Confirmation    r-cnf
      Reservation Direction       r-dir
      Resource Sharing            r-sh

4.  Security Considerations

   The MGCP packages contained in this document do not require any
   further security considerations beyond those indicated in the base
   MGCP specification [1].

5.  Acknowledgements

   Special thanks are due to the authors of the original MGCP 1.0
   specification: Mauricio Arango, Andrew Dugan, Isaac Elliott,
   Christian Huitema, and Scott Picket.



Foster & Andreasen           Informational                     [Page 59]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   Thanks also to the reviewers of this document, including but not
   limited to: Jerry Kamitses, Sonus Networks; Dave Auerbach, Dan Wing,
   Cisco Systems; Ed Guy, EMC Software; Martin Wakley, Nortel Networks.

6.  References

6.1.  Normative References

   [1]  Andreasen, F. and B. Foster, "Media Gateway Control Protocol
        (MGCP) Version 1.0", RFC 3435, January 2003.

   [2]  Bellcore, "LSSGR: Switching System Generic Requirements for Call
        Control Using the Integrated Services Digital Network User Part
        (ISDNUP)", GR-317-CORE, Issue 2, December 1997.

   [3]  ITU-T, "Telephone User Part Signaling Procedures", ITU-T Q.724,
        November 1988.

   [4]  ANSI, "OAM&P - Terminating Test Line Access and Capabilities",
        T1.207-2000.

   [5]  Bellcore, "Notes on the Network", Special Report SR-2275, Issue
        3, December 1997.

   [6]  Bellcore, "Call Processing" GR-505-CORE, Issue 1, December 1997.

   [7]  Bellcore, "LSSGR: Signaling for Analog Interfaces", GR-506-CORE,
        Issue 1, June 1996.

   [8]  ITU-T, "Technical Characteristics of Tones for the Telephone
        Service", ITU-T E.180, March 1998.

   [9]  ITU-T, "Various Tones Used in National Networks", ITU-T E.180,
        Supplement 2, January 1994.

   [10] ITU-T, "Applications of Tones and Recorded Announcements in
        Telephone Services", ITU-T E.182, March 1998.

   [11] Bellcore, "Call Forwarding Sub-Features FSD-01-02-1450, GR-586,
        Issue 1, June 2000.

   [12] Bellcore, "CPE Compatibility Considerations for the Voiceband
        Data Transmission Interface", SR-TSV-002476, December 1992.

   [13] Bellcore, "LSSGR: Visual Message Waiting Indicator Generic
        Requirements (FSD 01-02-2000)", GR-1401, Issue 01, June 2000.





Foster & Andreasen           Informational                     [Page 60]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   [14] Bellcore, "LSSGR Voiceband Data Transmission Interface", Section
        6.6, GR-30-CORE, Issue 02, December 1998.

   [15] Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [16] Bellcore, "LSSGR: Call Waiting, FSD 01-02-1201", GR-571, Issue
        01, June 2000.

   [17] Bellcore, "LSSGR: Verification Connections FSD 25-05-0903", GR-
        531-CORE, Issue 1, June 2000.

   [18] Bellcore, " LSSGR: CLASS Feature: Calling Identity Delivery on
        Call Waiting, FSD 01-02-1090, GR-575, Issue 01, June 2000.

   [19] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
        September 1981.

   [20] Bellcore, "Class Feature: Screen Editing (FSD 30-28-0000)", GR-
        220, Issue 2, April 2002.

   [21] ITU-T, "Procedure for document facsimile transmission in the
        general switched telephone network", ITU-T T.30, April 1999.

   [22] ITU-T, "300 bits per second duplex modem standardized for use in
        the general switched telephone network", ITU-T V.21, November
        1988.

   [23] Telcordia Technologies, "Telcordia Technologies Specification of
        Signaling System Number 7", GR-246-CORE, Issue 7, December 2002.

   [24] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Name
        Delivery Generic Requirements (FSD 01-02-1070)", GR-1188, Issue
        02, December 2000.

   [25] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Number
        Delivery (FSD 01-02-1051)", GR-31, Issue 01, June 2000.

   [26] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
        Conferences with Minimal Control", RFC 3551, July 2003.

   [27] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
        "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
        Specification", RFC 2205, September 1997.

   [28] Berners-Lee, T., Masinter, L. and M. McCahill, Eds., "Uniform
        Resource Locators (URL)", RFC 1738, December 1994.




Foster & Andreasen           Informational                     [Page 61]
^L
RFC 3660                  Basic MGCP Packages              December 2003


   [29] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
        Protocol (RTSP)", RFC 2326, April 1998.

   [30] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [31] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

6.2.  Informative References

   [32] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
        Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload
        for Redundant Audio Data", RFC 2198, September 1997.

   [33] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
        Telephony Tones and Telephony Signals", RFC 2833, May 2000.

   [34] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001.

   [35] PacketCableTM, Dynamic Quality if Service Specification,
        http://www.packetcable.com/downloads/specs/PKT-SP-DQOS-I07-
        030815.pdf

   [36] PacketCableTM Network-Based Call Signaling Protocol
        http://www.packetcable.com/downloads/specs/PKT-SP-EC-MGCP-I08-
        030728.pdf

   [37]  Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, Eds.,
        "Gateway Control Protocol Version 1", RFC 3525, June 2003.

   [38] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett,
        "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705,
        October 1999.

















Foster & Andreasen           Informational                     [Page 62]
^L
RFC 3660                  Basic MGCP Packages              December 2003


7.  Authors' Addresses

   Bill Foster
   Cisco Systems

   Phone: +1 250 758 9418
   EMail: bfoster@cisco.com


   Flemming Andreasen
   Cisco Systems
   Edison, NJ 08837

   EMail: fandreas@cisco.com





































Foster & Andreasen           Informational                     [Page 63]
^L
RFC 3660                  Basic MGCP Packages              December 2003


8.  Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Foster & Andreasen           Informational                     [Page 64]
^L