[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 3660

Internet Engineering Task Force                            B. Foster
Internet Draft                                          F. Andreasen
Document: <draft-foster-mgcp-basic-packages-07.txt>    Cisco Systems
Category: Informational                                  August 2002


                          Basic MGCP Packages

Status of this Document

  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC2026

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups. Note that other
  groups may also distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time. It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

Abstract

  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 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.

Conventions used in this document

  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 RFC-2119.












B. Foster, F. Andreasen      Informational                     [Page 1]


                          Basic MGCP Packages               August 2002

                            Table of Contents

1. Introduction.......................................................3
 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.................................................4
 1.3. New Packages and Excluded Packages.............................4
2. Packages...........................................................5
 2.1.  Generic Media Package.........................................7
 2.2.  DTMF package..................................................9
 2.3.  Trunk Package................................................14
 2.4.  Line Package.................................................21
 2.5.  Handset Emulation Package....................................29
 2.6.  Supplementary Services Tone Package..........................31
 2.7.  Digit Map Extension..........................................32
 2.8.  Signal List Package..........................................33
 2.9. Media Format Parameter Package................................34
 2.10. RTP Package..................................................37
 2.11.  Resource Reservation Package................................41
   2.11.1. Description..............................................41
   2.11.2. Parameter Encoding.......................................45
   2.11.3 Events....................................................45
 2.12.  Announcement Server Package.................................47
 2.13.  Script Package..............................................48
3.0. IANA Considerations.............................................50
4.0. Acknowledgements................................................51
5.0. References......................................................52
6.0. Authors' Addresses..............................................54
7.0. Full Copyright Statement........................................54






















B. Foster, F. Andreasen      Informational                     [Page 2]


                          Basic MGCP Packages               August 2002

1. Introduction

1.1. List of Packages

  This document provides a basic set of packages 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 (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. 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 also 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
  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 does contain 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.


B. Foster, F. Andreasen      Informational                     [Page 3]


                          Basic MGCP Packages               August 2002

  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 is assumed.

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

1.2.3. Package Versions

  Some of the packages included in this document are new versions of
  packages that were previously contained in RFC 2705. 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.

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 have not been included. These are the "MF"
  and the "NAS" package. These packages are still valid as are all
  unversioned (version 0) packages defined in RFC 2705. 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 was incomplete. A new
       MGCP "NAS" package has been developed and provided in a separate
       document.


B. Foster, F. Andreasen      Informational                     [Page 4]


                          Basic MGCP Packages               August 2002

  New packages have also been included beyond what was included in RFC
  2705. 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
  will be 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 requesting the
  detection of an "event" that occurs on the Media Gateway and is
  "Notified" to the Call Agent.

  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.

B. Foster, F. Andreasen      Informational                     [Page 5]


                          Basic MGCP Packages               August 2002


  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]). Example:

         S: sst/cw(to=20000)

      indicates a timeout value of 20 seconds.

  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.

  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.

















B. Foster, F. Andreasen      Informational                     [Page 6]


                          Basic MGCP Packages               August 2002

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|
    ---------------------------------------------------------------

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

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

  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 - LSSGR: SIGNALING, 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 and E.182. This maps to
  re-order tone in North America (refer to GR-506-CORE - LSSGR:
  SIGNALING, 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 and V.21.

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


B. Foster, F. Andreasen      Informational                     [Page 7]


                          Basic MGCP Packages               August 2002

  Long Duration Connection (ld): The "long duration connection" is
  detected when a connection has been established for more than some
  time. The default value is 1 hour, however the provisioning process
  may change this.

  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 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.

  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 and ITU-T E.182. 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. The


B. Foster, F. Andreasen      Informational                     [Page 8]


                          Basic MGCP Packages               August 2002

  cadence for Audible Ring Tone is 2 seconds on followed by 4 seconds
  off. See GR-506-CORE - 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 ring back tones, 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.

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 |                  |
   | X       |   DTMF Tones Wildcard,    |   x |                  |
   |         |    match any digit 0-9    |     |                  |
    --------------------------------------------------------------

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



B. Foster, F. Andreasen      Informational                     [Page 9]


                          Basic MGCP Packages               August 2002

  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)".

  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 - 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, 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 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>)): 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 when 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 the <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 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.

  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.

B. Foster, F. Andreasen      Informational                    [Page 10]


                          Basic MGCP Packages               August 2002

  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.

  If instead, the Requested event line had contained

    R: d/dd(N)(to=40),d/dd

  In that case, almost the same results would be obtained:

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

  after the "#" key is pressed for 40 ms, 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 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

B. Foster, F. Andreasen      Informational                    [Page 11]


                          Basic MGCP Packages               August 2002

  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 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 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.


B. Foster, F. Andreasen      Informational                    [Page 12]


                          Basic MGCP Packages               August 2002

   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 trigger immediately since timer T is completely irrelevant.

  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.



























B. Foster, F. Andreasen      Informational                    [Page 13]


                          Basic MGCP Packages               August 2002

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.


  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 [12] (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 [6].



B. Foster, F. Andreasen      Informational                    [Page 14]


                          Basic MGCP Packages               August 2002

  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 [12].

  Busy Tone (bz): Refer to ITU-T E.180. 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 - LSSGR: SIGNALING,
  Section 17.2.6.

  Continuity Tone (co1): A tone at 2010 Hz (see section 3.1.1.3 of
  [13]). 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
  [13]). 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
  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 as well as
  by Bellcore GR-317-CORE 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 and 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)



B. Foster, F. Andreasen      Informational                    [Page 15]


                          Basic MGCP Packages               August 2002

  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

  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 return tone has been removed within specified performance
  limits (i.e. GR-246-CORE, T1.113.4, Annex B). 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

B. Foster, F. Andreasen      Informational                    [Page 16]


                          Basic MGCP Packages               August 2002

       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) are 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 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 connection mode, i.e. this is an alternative way to provide the
  same functionality as "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).




B. Foster, F. Andreasen      Informational                    [Page 17]


                          Basic MGCP Packages               August 2002

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

  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 [7] and section
  8.2.5 of [6].

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

  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 [7] and section
  8.2.5 of [6]

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

  Quiet Termination (qt): used in 102 test Trunk. Reference section
  6.20.5 [6] as well as [7].

  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 [5], Section 17.2.7.

  Special Information Tone(sit(#)): As described in ITU-T E.180, 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 [6]:










B. Foster, F. Andreasen      Informational                    [Page 18]


                          Basic MGCP Packages               August 2002

       -------------------------------------------
      | 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
  [3]). In this case special information tone 1 as defined in [3] 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 [6].

  Test Pattern (tp(###)): The tp(###) signal inserts the pattern ###
  continuously into the channel until the timout 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).

  A typical use for the test pattern signal is for the test line 108
  (digital loopback) test (refer to section 8.2.5 of [6]). 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.


B. Foster, F. Andreasen      Informational                    [Page 19]


                          Basic MGCP Packages               August 2002

  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)".



































B. Foster, F. Andreasen      Informational                    [Page 20]


                          Basic MGCP Packages               August 2002

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.    |     |   TO infinite |
   |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".

  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.


B. Foster, F. Andreasen      Informational                    [Page 21]


                          Basic MGCP Packages               August 2002

  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. 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 [5], 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 TR-NWT-001188, GR-30-CORE,
  and TR-NWT-000031. For backwards compatibility, each of the three
  fields are optional, however each of the commas will always be
  included. In accordance with the general MGCP grammar, it is however
  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 Month between 01 and 12, DD is a two-digit
     value for 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 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").

     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, however 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:


B. Foster, F. Andreasen      Informational                    [Page 22]


                          Basic MGCP Packages               August 2002

          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 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 - 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 [5], 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).

  Flash Hook (hf): See GR-506-CORE [5], 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 [4].

  On-hook Transition (hu): See GR-506-CORE [5], Section 12. The timing
  for the onhook 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 [5]) 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 [5], 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

B. Foster, F. Andreasen      Informational                    [Page 23]


                          Basic MGCP Packages               August 2002

  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 and 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].

  Network Disconnect (osi): 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 [5], see also See GR-505-CORE [15], 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, repeating. GR-506-CORE [5], 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): This signal is included here to maintain
  compatibility with the previous version of this package. The prompt
  signal is an alias for the calling card service tone ("z"). Future
  implementations that require this signal should use "z".

  Ringing (rg): See GR-506-CORE [5], 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.:


B. Foster, F. Andreasen      Informational                    [Page 24]


                          Basic MGCP Packages               August 2002

     S: l/rg(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/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 [5], Section 14. Default values for r1 to r5 are as defined for
  distinctive ringing pattern 1 to 5 in GR-506-CORE. The default values
  for r0, r6 and r7 is 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.

  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).



B. Foster, F. Andreasen      Informational                    [Page 25]


                          Basic MGCP Packages               August 2002

  Reorder Tone (ro): This maps to congestion tone in the ITU-T E.182
  [4] 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" 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 [19]).

  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 [2],
  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 [6]:

       -------------------------------------------
      | 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      |
       -------------------------------------------


  If the parameter is left out, the NC' SIT tone which 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 [3]). In
  this case special information tone 1 as defined in [3] 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 and "special dial tone" in ITU-T E.182) 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.


B. Foster, F. Andreasen      Informational                    [Page 26]


                          Basic MGCP Packages               August 2002

  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 2 second duration followed by 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 [21] and the CPE
  guidelines in [20]. Refer also to section 6.6 of GR-30 [22]. 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".

  Alternative Call Waiting Tones (wt, wt1, .., wt4): Refer to ITU-T
  E.180 [2]. For North American tone definitions refer to GR-506-CORE
  [5], 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 ˜ 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. However, there are cases (Requirement R3-73 of
  GR-575-CORE [24]), 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. The talking path should be interrupted
  for a maximum of 400 ms for the application of CW tone. The Call
  Agent implements the actual call waiting service - see GR-571 [23].
  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 - also Bellcore
  document SR-2275 [6]section 6.20. When recording equipment is used,
  this tone is connected to the line to inform the distant party that

B. Foster, F. Andreasen      Informational                    [Page 27]


                          Basic MGCP Packages               August 2002

  the conversation is being recorded  - typical value used is a 1400 Hz
  Tone of 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 [6], section 6.20.















































B. Foster, F. Andreasen      Informational                    [Page 28]


                          Basic MGCP Packages               August 2002

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 |   TO infinite |
   |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.

  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.

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


B. Foster, F. Andreasen      Informational                    [Page 29]


                          Basic MGCP Packages               August 2002

  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 parameterized. However, parameters are included when the
  event is reported i.e.:

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

  Ringing (rg): When requested as an event, the Call Agent may optional
  include the rep parameter indicating 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 report as soon as
  ringing is detected.

  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): MUST not 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.

B. Foster, F. Andreasen      Informational                    [Page 30]


                          Basic MGCP Packages               August 2002


  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.

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          |
     ----------------------------------------------------------------

  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): used to indicate that the call is being processed
  and that the caller should wait. Refer to E.182 [4].

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



B. Foster, F. Andreasen      Informational                    [Page 31]


                          Basic MGCP Packages               August 2002

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

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

  Number Unobtainable Tone (nu): Refer to E.180, supplement 2 [3]. This
  is also referred to as "vacant tone" and maps to "re-order tone" in
  North America (see GR-506-CORE [5], 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 E.182 [4].

  Pay Tone (pt): a tone indicating that payment is required. Refer to
  E.182 [4].


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.

  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.




B. Foster, F. Andreasen      Informational                    [Page 32]


                          Basic MGCP Packages               August 2002

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.

  Note that as the gateway plays the ordered list of signals, if it
  encounters a TO signal with 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.

B. Foster, F. Andreasen      Informational                    [Page 33]


                          Basic MGCP Packages               August 2002

  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 [8] 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 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

B. Foster, F. Andreasen      Informational                    [Page 34]


                          Basic MGCP Packages               August 2002

  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".

  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 use of the media format parameter LCO is in conjunction
  with the media format "telephone-event" as defined in RFC 2833 [14].
  If the media format "telephone-event" is used without the "fmtp"
  media format parameter, the DTMF digits (telephone events 0-15 from
  RFC 2833) 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. 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


B. Foster, F. Andreasen      Informational                    [Page 35]


                          Basic MGCP Packages               August 2002

  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 [9]. Again,
  the format of the fmtp string is similar to that used in the SDP
  except the medea format ("red" in this case) rather than the payload
  type is used:

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

  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 it's 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


B. Foster, F. Andreasen      Informational                    [Page 36]


                          Basic MGCP Packages               August 2002

  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 will consequently be registered with
  IANA.


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".

  These events 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].

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

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

B. Foster, F. Andreasen      Informational                    [Page 37]


                          Basic MGCP Packages               August 2002

       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 those 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 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 rather
  than the co1 tone itself.

  ICMP Unreachable Received (iu): This event indicates that some number
  of ICMP unreachable packets 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.

  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;


B. Foster, F. Andreasen      Informational                    [Page 38]


                          Basic MGCP Packages               August 2002

        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".

  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].


B. Foster, F. Andreasen      Informational                    [Page 39]


                          Basic MGCP Packages               August 2002

  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
  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 exceeded a quality threshold. The quality thresholds for
  delay, jitter and packet loss rate are provisioned values.

  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:

B. Foster, F. Andreasen      Informational                    [Page 40]


                          Basic MGCP Packages               August 2002


      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.

  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
  1890, 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.



B. Foster, F. Andreasen      Informational                    [Page 41]


                          Basic MGCP Packages               August 2002

  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
  (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
  "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 reservations are required 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:

   *  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.


B. Foster, F. Andreasen      Informational                    [Page 42]


                          Basic MGCP Packages               August 2002

   *  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 precondition 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 regardless if reservation
     confirmation parameter has value "send-receive" (without a
     provisional response, SDP information cannot be returned until the
     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]).

B. Foster, F. Andreasen      Informational                    [Page 43]


                          Basic MGCP Packages               August 2002


     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. This is an indication to the gateway to use the
        "Shared Explicit" style of reservation as defined in RFC 2205.

      * 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)

      * 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
  [17], then the parameters in NCS [18] would be used instead of the
  reservation direction, confirmation and reservation sharing
  parameters described here.


B. Foster, F. Andreasen      Informational                    [Page 44]


                          Basic MGCP Packages               August 2002


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
        (i.e. indicating that a shared explicit style of reservation
        should be used - see RFC 2205), 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

      * 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 |               |
    ------------------------------------------------------



B. Foster, F. Andreasen      Informational                    [Page 45]


                          Basic MGCP Packages               August 2002

  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.

  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 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"


B. Foster, F. Andreasen      Informational                    [Page 46]


                          Basic MGCP Packages               August 2002

  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")

  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), 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), which in this case allows
       the media gateway to directly initiate playing of the
       announcement via an RTSP server.



B. Foster, F. Andreasen      Informational                    [Page 47]


                          Basic MGCP Packages               August 2002

  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.

  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. As an
  example:

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

B. Foster, F. Andreasen      Informational                    [Page 48]


                          Basic MGCP Packages               August 2002

                                                             ...,argn)

  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.

  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,

B. Foster, F. Andreasen      Informational                    [Page 49]


                          Basic MGCP Packages               August 2002

  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 don't start executing a new one.

  The "ir" signal is only associated with an executing script, if none
  is 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


3.0. IANA Considerations

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

  Package  Version
  -------  -------
     A        1
     D        1
    DM1       0
     FM       0
     G        1
     H        1
     L        1
     R        1
    RES       0
  SCRIPT      1
    SST       0
     SL       0
     T        1






B. Foster, F. Andreasen      Informational                    [Page 50]


                          Basic MGCP Packages               August 2002

  The following extension digit map letter should be registered with
  IANA:

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

  The following Local Connections should be registered with IANA:

    fmtp
    r-cnf
    r-dir
    r-sh

4.0. 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.

  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.































B. Foster, F. Andreasen      Informational                    [Page 51]


                          Basic MGCP Packages               August 2002

5.0. References

  [1]  F. Andreasen, B. Foster, "Media Gateway Control Protocol (MGCP)
       Version 1.0", RFC XXXX {editors note - to be put in when RFC
       number is assigned to draft-andreasen-mgcp-rfc2705bis-05.txt)

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

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

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

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

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

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

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

  [9]  C. Perkins et al, RTP Payload for Redundant Audio Data, RFC
       2198, September 1997.
       .
  [10] Bellcore, "Basic 911 Emergency Service (FSD 15-01-0000)", GR-
       529-CORE, Issue 1, June 2000.

  [11] J. Postel, "Internet Control Message Protocol", RFC 792,
       September 1981.

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

  [13] 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.

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

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

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

  [17] PacketCableTM, Dynamic Quality if Service Specification,
       http://www.packetcable.com/specifications.html



B. Foster, F. Andreasen      Informational                    [Page 52]


                          Basic MGCP Packages               August 2002

  [18] PacketCableTM Network-Based Call Signaling Protocol
       Specification, http://www.packetcable.com/specifications.html

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

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

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

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

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

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



































B. Foster, F. Andreasen      Informational                    [Page 53]


                          Basic MGCP Packages               August 2002

6.0. Authors' Addresses

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

  Flemming Andreasen
  Cisco Systems
  499 Thornall Street, 8th Floor
  Edison, NJ 08837
  Phone: +1 732 452 1667
  EMail: fandreas@cisco.com

7.0. Full Copyright Statement

  Copyright (C) The Internet Society (2002).  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 assigns.

  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.










B. Foster, F. Andreasen      Informational                    [Page 54]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/