Internet Engineering Task Force                            M. Arango
Internet Draft                                      SUN Microsystems
Document: <draft-foster-mgcp-basic-packages-02.txt>         A. Dugan
Category: Informational                                   I. Elliott
Expires: February 2002                         Level3 Communications
                                                          C. Huitema
                                                           Microsoft
                                                          S. Pickett
                                                   Vertical Networks
                                                           B. Foster
                                                        F. Andreasen
                                                            R. Kumar
                                                       Cisco Systems
                                                         August 2001


                          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 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 have been added. These are the
  signal lists, resource reservation, media format, supplementary
  services tones 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.



Arango et al.                Informational                     [Page 1]


                    Basic MGCP Packages                     August 2001

1. Introduction

1.1. List of Packages

  This document provides a basic set of packages for MGCP. 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 Packages

1.2.1. Change in signal types

  MGCP 1.0 as defined in RFC 2705 provided some additional
  clarification on the meaning of OO signals compared to earlier
  versions of MGCP. This leads to some inconsistency in some of the
  signal definitions in the accompanying packages. This has been
  corrected in the packages that are included here by changing some of
  the signals from type OO to type 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 events defined but where the events were
  not 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.



Arango et al.                Informational                     [Page 2]


                    Basic MGCP Packages                     August 2001

  It is considered good practice to explicitly mention that these two
  events are supported in accordance with their default definitions. If
  no definition is included in the package, the above 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 base
  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 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 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:

     * The original MF package had no defined way to outpulse MF digits
       - so that a separate RFC was developed for MF CAS (RFC 3064).
     * The "N" package as defined in RFC 2705 was incomplete. A more
       complete MGCP "NAS" package has been developed and provided as a
       separate Internet draft.

  New packages have also been included beyond what was included in the
  original RFC 2705. The Resource Reservation ("RES") and Media Format
  ("FM") packages in particular are different from other packages in

Arango et al.                Informational                     [Page 3]


                    Basic MGCP Packages                     August 2001

  this document in that they do not contain events and signals but
  simply define extra LocalConnectionOptions. This is allowed by the
  new extension rules in [1]. Future packages of this type should 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 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.



Arango et al.                Informational                     [Page 4]


                    Basic MGCP Packages                     August 2001

      Default time-out values may be over-ridden by the Call Agent for
      any Time-Out event defined in this document 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.

  In some of the signal definitions below, specific tone definitions
  are provided even though actual frequencies may vary from country to
  country. Country variations should be handled by gateway
  provisioning.


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 detected        |   x |                 |
     | it       |   Intercept tone           |     | TO    infinite  |
     | ld       |   Long duration connection |   C |                 |
     | mt       |   Modem detected           |   x |                 |
     | oc       |   Operation complete       |   x |                 |
     | of       |   Operation failure        |   x |                 |
     | pt       |   Preemption tone          |     | TO    infinite  |
     | rt       |   Ringback tone            |     | TO,C 180 seconds|
     | rbk(###) |   Ringback                 |     | TO,C 180 seconds|
     | pat(###) |   Pattern Detected         |   x | OO              |
      ---------------------------------------------------------------

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

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

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

Arango et al.                Informational                     [Page 5]


                    Basic MGCP Packages                     August 2001

  is on hook and an error should 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): Indicates that V.21 fax preamble detected.

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

  Long Duration (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.

  The 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" 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 tones (mt): Indicates V.25 Answer tone 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.

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

  Ring back tone (rt):  Refer to ITU E.180 and ITU 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
  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 should 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
  should be played regardless of the connection mode. For example, in a

Arango et al.                Informational                     [Page 6]


                    Basic MGCP Packages                     August 2001

  call-waiting situation, ringback tone may be played on a connection
  in "inactive" mode.

  Ringback (rbk): 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 ringback signal does not support the
  "@connection" syntax.

  pat(###): pattern detected. 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.

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             |
    | L       |   long duration indicator |   x |                  |
    | DD(..)  |   DTMF tone duration      |   x |   TO  3 seconds  |
    | DO(..)  |   DTMF OO signal          |     |   OO             |
    | X       |   Wildcard, match         |   x |                  |
    |         |   any digit 0-9           |     |                  |
    | oc      |   operation complete      |   x |                  |
    | of      |   operation failure       |   x |                  |
    | T       |   Interdigit timer        |   x |                  |
     --------------------------------------------------------------

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




Arango et al.                Informational                     [Page 7]


                    Basic MGCP Packages                     August 2001

  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
  signals 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 should consequently be returned
  when such attempts are made (error code 402 - phone on hook). The
  events 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.

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

  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 value of <tone> can be any of the DTMF tone symbols
  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 between 50 ms and 60000 ms can be


Arango et al.                Informational                     [Page 8]


                    Basic MGCP Packages                     August 2001

  requested. Gateways generating or detecting the tone may round-off
  the requested time to the nearest 10 ms.

  The "dd" event can be used in place of the "l" 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 depressed.

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

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

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


Arango et al.                Informational                     [Page 9]


                    Basic MGCP Packages                     August 2001

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

  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.

  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.



Arango et al.                Informational                    [Page 10]


                    Basic MGCP Packages                     August 2001

   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.

2.3.  Trunk Package

   Package Name: T
   Version: 1

      ----------------------------------------------------------------
     | Symbol   |   Definition                   |   R | S  Duration  |
     |----------------------------------------------------------------|
     | 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)                  |     |              |
     | lb(##)   |   Loopback                     |     | OO           |
     | nm       |   New Milliwatt Tone           |   x | TO  3 sec    |
     | mm       |   Newest Milliwatt Tone        |   x | TO  3 sec    |
     | oc       |   Operation Complete           |   x |              |
     | of       |   report failure               |   x |              |
     | om       |   Old Milliwatt Tone           |   x | TO  3 sec    |
     | 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  infinite |
     | as       |   Answer Supervision           |   x | BR           |
     | bl       |   Blocking                     |     | BR           |
      ----------------------------------------------------------------


Arango et al.                Informational                    [Page 11]


                    Basic MGCP Packages                     August 2001

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

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


  The definition of trunk package events are as follows:

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


  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:

Arango et al.                Informational                    [Page 12]


                    Basic MGCP Packages                     August 2001


     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

  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 signals corresponding to the continuity tones 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: co1(to=2000)"). Note that removal of
  the go tone by the gateway is determined by continuity test
  requirements (i.e. it is under control of the gateway) and is not
  determined by the timout period.

  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 fail event indicates failure
       prior to timeout (i.e. "O: t/of(t/co1)") and
     * 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. It is up to the termination end to make sure that the return

Arango et al.                Informational                    [Page 13]


                    Basic MGCP Packages                     August 2001

  tone is removed as soon as the go tone disappears. The Call Agent
  does the removal of "contest" or "loopback" connections at a
  termination end when the results of the continuity test are obtained.

  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.

  Loopback (lb(in=<tone-in>,out=<tone-out>, <+ or ->): This signal is
  used to provide loopback or transponder functionality independent of
  connection mode, i.e. this is an alternative way to provide the same
  functionality as "conttest" and "loopback" connection modes. 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 these parameters are left out, the value of <tone-in>
  defaults to 2010 Hz and the value of <tone-out> defaults to 1780 Hz.
  The provisioning process may alter both of these values (in fact
  these default values would be incorrect for a test from a 4-wire
  switch to a 2-wire switch).

  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 loopback signal is explicitly turned off (e.g. "S: t/lb(-)")
       or
     * Removal of the <tone-in> tone is detected.

  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 the packet network (i.e. the loopback signal must be
  explicitly turned off by the Call Agent in order to allow media to be
  forwarded to 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].

  Old Milliwatt Tone (om): 1000 Hz tone - refer to [7] and section
  8.2.5 of [6]

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

Arango et al.                Informational                    [Page 14]


                    Basic MGCP Packages                     August 2001

  continuously (until time-out). See GR-506-CORE - LSSGR: SIGNALING,
  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]:

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

  Line Test (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


Arango et al.                Informational                    [Page 15]


                    Basic MGCP Packages                     August 2001

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

  Answer Supervision (as): This event is used for off-hook representing
  "answer" in CAS. An alternative is to use the "answer" event in the
  appropriate CAS packages [12].

  Blocking (bl): This event is used to indicate an incoming off-hook
  for the purposes of blocking a one-way trunk in CAS trunks. An
  alternative is the "block" event in the appropriate CAS packages
  [12].
















Arango et al.                Informational                    [Page 16]


                    Basic MGCP Packages                     August 2001

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 |               |
|hu           |   On hook transition       |   S |               |
|hf           |   Flash hook               |   x |               |
|ht           |   On Hold Tone             |     |   OO          |
|lsa          |   Line Side Answer Sup.    |     |   TO infinite |
|mwi          |   Message waiting ind.     |     |   TO 16 sec.  |
|oc           |   operation complete       |   x |               |
|of           |   operation failure        |   x |               |
|osi          |   open switch interval     |     |   TO 900 ms   |
|ot           |   Off hook warning tone    |     |   TO infinite |
|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          |
|sit          |   Special Information Tone |     |   TO 2 sec.   |
|             |                            |     |   (see notes) |
|sl           |   Stutter dialtone         |     |   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          |
|p            |   Prompt tone              |   x |   BR          |
|nbz          |   Network busy             |   x |   TO infinite |
|s(###)       |   Distinctive tone pattern |   x |   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.


Arango et al.                Informational                    [Page 17]


                    Basic MGCP Packages                     August 2001

  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 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. It is considered an error to try and play busy tone on a
  phone that is on hook and an error should 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 value for Month between 01 and 12, DD is a two-digit value
     for Day between 1 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.

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

     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. The following example illustrates the use of the
     caller-id signal:

     S: ci(10/14/17/26, "555 1212", somename)

  Dial-tone (dl): Refer to the ITU 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

Arango et al.                Informational                    [Page 18]


                    Basic MGCP Packages                     August 2001

  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 should consequently be
  returned when such attempts are made (error code 402 - phone on
  hook).

  Error tone (e): This tone is maintained for backwards compatibility.

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

  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 - LSSGR: SIGNALING, 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 should consequently be returned when such attempts
  are made (error code 402 - phone on hook).

  Open Switch Interval (osi): This 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). This is needed for
  some customer premises equipment (e.g. certain answering machines) in
  order to get the equipment to hang up. 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, 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 should consequently be returned when such attempts
  are made (error code 402 - phone on hook).

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


Arango et al.                Informational                    [Page 19]


                    Basic MGCP Packages                     August 2001

  can be requested and will occur at the end of the timeout/number of
  rings)

  It is considered an error to try and ring a phone that is off hook
  and an error should 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
  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 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)

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

  Reorder Tone (ro): This maps to congestion tone in the ITU 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.

  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
  CF sub-feature is active. In the US, it is defined to be a 0.5(-
  0,+0.1) second burst of power ringing. See Bellcore TR-TSY-000586 -
  Call Forwarding Sub-features.

  Special Information Tone (sit): As described in ITU-T E.180, the
  special information tone (SIT) 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). In North America, multiple SIT
  tones have been defined (see SR-2275, section 6.21.2 [6]). These
  tones are available in the trunk package. The particular SIT tone
  defined here is NC' SIT which corresponds to the signal "t/sit(3)".

  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.

Arango et al.                Informational                    [Page 20]


                    Basic MGCP Packages                     August 2001


  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 following will
  apply stutter dial tone with a delay of 1.5 seconds between the
  confirmation tone and the dial tone:

     S: 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 should 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.

  Visual Message Waiting Indicator (vmwi): The transmission of the VMWI
  messages will conform to the requirements in Section 2.3.2, "On-hook
  Data Transmission Not Associated with Ringing" in Bellcore TR-H-
  000030 and the CPE guidelines in SR-TSV-002476. 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. If the gateway does a restart (sends a Restart-in-
  Progress message, the Call Agent must refresh the CPE's visual
  indicator. See TR-NWT-001401 - Visual Message Waiting Indicator
  Generic Requirements; and GR- 30-CORE - Voiceband Data Transmission
  Interface.

  Call Waiting tone1 (wt, wt1, .., wt4): Refer to ITU E.180. For North
  American tone definitions refer to GR-506-CORE, 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), where 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=1)").

  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 TR-TSY-000571
  - Call Waiting. It is considered an error to try and apply call
  waiting tone on a phone that is on hook and an error should
  consequently be returned when such attempts are made (error code 402
  - phone on hook).

  Recorder Warning Tone(y): Refer to ITU E.180 - also Bellcore document
  SSR75 section 6.20. When recording equipment is used, this tone is
  connected to the line to inform the distant party that the

Arango et al.                Informational                    [Page 21]


                    Basic MGCP Packages                     August 2001

  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 SR2275, section 6.20.

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

  Network Busy (nbz): This signal is included here to maintain
  compatibility with the previous version of this package. The "nbz"
  signal is an alias for re-order tone ("ro"). Future Call Agent
  implementations that require a network busy signal should use the
  "ro" signal.

  Distinctive Tone Pattern (s): This signal is included here to
  maintain compatibility with the previous version of this package.
  This event requires special provisioning in the Call Agent and
  gateway to insure interoperability.































Arango et al.                Informational                    [Page 22]


                    Basic MGCP Packages                     August 2001

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          |
|mwi          |   Message waiting ind.     |   x |   TO 16 sec.  |
|oc           |   operation complete       |   x |               |
|ot           |   Off hook warning tone    |   x |   TO infinite |
|of           |   report failure           |   x |               |
|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          |
|sl           |   Stutter dialtone         |   x |   TO 16 sec.  |
|sit          |   Sit tone                 |   x |   TO 2 sec.   |
|v            |   Alerting Tone            |   x |   OO          |
|vmwi         |   Vis. Message Waiting Ind.|   x |   OO          |
|wt           |   Call Waiting tone        |   x |   TO 12 sec.  |
|y            |   Recorder Warning Tone    |   x |   TO infinite |
|z            |   Calling Card Serv. Tone  |   x |   BR          |
|p            |   Prompt tone              |   x |   BR          |
|nbz          |   Network Busy             |   x |   TO infinite |
|s(###)       |   Distinctive tone pattern |   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:

  Visual Message Waiting: when requested as an event by the Call Agent,
  the event is not parameterized. However, a parameter is included when
  it is reported i.e.:


Arango et al.                Informational                    [Page 23]


                    Basic MGCP Packages                     August 2001

        O: vmwi(+) to indicate message waiting on and
        O: vmwi(-) to indicate message waiting off

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.  |
  |ni           |   negative indication      |     |   TO infinite |
  |nu           |   number unobtainable      |     |   TO infinite |
  |oc           |   operation complete       |   x |               |
  |of           |   operation fail           |   x |               |
  |pr           |   payphone 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].

  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.

  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.

  Pay Phone Recognition (pr): A tone advising an operator that the
  termination 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].




Arango et al.                Informational                    [Page 24]


                    Basic MGCP Packages                     August 2001


2.7.  Digit Map Extension

  Package Name: dm1
  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. The
  letter "P" (for partial match override) at the end of a digit map
  entry instructs the gateway to only consider this 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, however a current dial string of "411" would be considered a
  match. A current dial string of "8234" would be considered a match,
  since there is no other partial match.

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

  Support for this package is strongly recommended.



2.8.  Signal List Package

  Package Name: SL
  Version: 0

    ---------------------------------------------------------
   | Symbol  |   Definition             |  R  | S   Duration |
   |---------------------------------------------------------|
   | s(###)  |  Signal List             |     | TO  variable |
   | oc      |  Operation complete      |  x  |              |
   | of      |  Operation failure       |  x  |              |
    ---------------------------------------------------------

  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)



Arango et al.                Informational                    [Page 25]


                    Basic MGCP Packages                     August 2001

  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 will 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 requested to stop playing the "SL/S" signal (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 will be generated. Only the signal list name
  will be included, thus it is not possible to determine which signal
  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.

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

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

2.9.  Media Format Package

  Package Name: FM
  Version: 0

  This package provides support for the media format Local Connection
  Option (LCO). The media format LCO has a similar significance to the
  "fmtp" attribute in SDP [8]. The media format parameter is encoded as
  the keyword "fmtp" or "o-fmtp" followed by a colon and a quoted
  string beginning with the codec name followed by a space, followed
  the format associated with that codec. Multiple media formats may be


Arango et al.                Informational                    [Page 26]


                    Basic MGCP Packages                     August 2001

  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 as in:

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

  The two formats may be mixed.

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

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

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

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

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

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

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

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



Arango et al.                Informational                    [Page 27]


                    Basic MGCP Packages                     August 2001

  One example use of the media format LCO is in conjunction with the
  codec "telephone-event" as defined in RFC 2833 [14]. If the codec
  "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 LCO can 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" codec in the SDP in its response. On
  the other hand, if it can support those telephone events, it should
  indicate support for those events as well as any of the events 16, 70
  and 71 that it supports.

  If a request is made to audit the capabilities of an endpoint and the
  endpoint supports the "telephone event" codec 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 codec 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:

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




Arango et al.                Informational                    [Page 28]


                    Basic MGCP Packages                     August 2001

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

  These two LocalConnectionOptions will consequently be registered with
  IANA.


































Arango et al.                Informational                    [Page 29]


                    Basic MGCP Packages                     August 2001

2.10. RTP Package

   Package Name: R
   Version: 1

    -------------------------------------------------------------
   | Symbol  |   Definition                 |   R |   S Duration |
   |-------------------------------------------------------------|
   | iu(..)  |   ICMP unreachable           |   C |              |
   |         |     received                 |     |              |
   | rto(..) |   RTP/RTCP timeout           |   C |              |
   | uc      |   Used codec changed         |   C |              |
   | sr      |   Sampling rate changed      |   C |              |
   | ji(..)  |   Jitter buffer size changed |   C |              |
   | pl(..)  |   Packet loss exceeded       |   C |              |
   | qa      |   Quality alert              |   C |              |
   | 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) |     |              |
   | oc      |   operation complete         |   C |              |
   | of      |   operation failure          |   C |              |
    -------------------------------------------------------------

  Changes in event types: "co1" and "co2" signals changed from OO to
  TO. A direction parameter is also added to the "uc" and "sr" events.

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

  These events all refer to RTP streams (connections), i.e. they can
  not be detected on an endpoint. Signals requested ("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 report uc on all connections) or

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

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

        O: r/uc@connectionID(15)


  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

Arango et al.                Informational                    [Page 30]


                    Basic MGCP Packages                     August 2001

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

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




Arango et al.                Informational                    [Page 31]


                    Basic MGCP Packages                     August 2001

  RTP/RTCP Timeout (rto):

     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 is supplied as a
     decimal number from 1 to 65535 in the parameter when the request
     is made. The parameter is also supplied in ObservedEvents when the
     event is reported - it then simply repeats the value supplied
     originally. 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 a
     parameter then a default timeout of 60 seconds is assumed. This is
     a one-shot event in that once the event occurs, a further request
     is required in order to re-initialize the timer.


  An example of a request might be as follows:

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

  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)


  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.

  Sampling Rate Changed (sr):
     This event is only included here to maintain compatibility with
     the previous version of this package. This event was meant to
     indicate that the packetization period changed to some decimal
     number in milliseconds enclosed in parenthesis, as in SR(20),
     which would indicate that the sampling rate was changed to 20
     milliseconds. Some implementations of media gateways may not allow
     the sampling rate to be changed upon command from a call agent.


Arango et al.                Informational                    [Page 32]


                    Basic MGCP Packages                     August 2001

  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.

   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.

  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 loopback proceeds as usual except that
     telephone events corresponding to the co1 tone are sent rather
     than the co1 tone itself.

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

  Operation failure (of):

Arango et al.                Informational                    [Page 33]


                    Basic MGCP Packages                     August 2001

     This is the standard definition of operation failure.


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, for example using RSVP, on a
  given connection. When a reservation is needed, the Call Agent will
  specify the reservation profile that should be used, which is either
  "controlled load" or "guaranteed service". The absence of reservation
  can be indicated by asking for the "best effort" service, which is
  the default value for this parameter.

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



Arango et al.                Informational                    [Page 34]


                    Basic MGCP Packages                     August 2001

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

   *  If the "reservation confirmation" parameter is set to "send-only",
     the gateway will "Ack" when the RESV is received to indicate
     reservation in the send direction.

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

   *  If the reservation confirmation parameter is set to "send-
     receive", the gateway will "Ack" only after 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 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 is simply ignored as a pre-
     condition.

     In this approach, resource reservation success is the pre-
     condition to final acknowledgement of the connection request. If

Arango et al.                Informational                    [Page 35]


                    Basic MGCP Packages                     August 2001

     the reservation fails, the connection request also fails (error
     code 526 - 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 results 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 in the other direction). The SDP
     information and connectionID must be included in both the
     provisional response and the final response. Note that in order to
     ensure rapid detection of a lost final response, final responses
     issued after provisional responses for a transaction shall be
     acknowledged, i.e., they shall include an empty "ResponseAck"
     parameter in the final response (see [1]).

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

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


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

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

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

Arango et al.                Informational                    [Page 36]


                    Basic MGCP Packages                     August 2001

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


2.11.2. Parameter Encoding

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

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

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

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

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

      * the wild-card character "$" indicating this connection,
        indicating future plans to share resources with this connection
        (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


Arango et al.                Informational                    [Page 37]


                    Basic MGCP Packages                     August 2001

      * an empty value, 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 should 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 event is included as part of the resource reservation
  package:

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

  Resource Lost:
     Loss of reservation during the life of a connection can be
     reported by using the ôrlö event. 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, as in:

          O: res/rl@0A3F58

          Resource lost will also occur if a resource reservation is in
     progress when the event is requested, and the reservation fails.


2.12.  Announcement Server Package

   Package Name: A
   Version: 1

    -------------------------------------------------------------
   | Symbol         | Definition           |   R |   S  Duration |
   |-------------------------------------------------------------|
   | ann(url)       | Play an announcement |     |   TO variable |
   | oc             | operation complete   |   x |               |
   | of             | operation failure    |   x |               |
    -------------------------------------------------------------

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

  The announcement action is qualified by a URL name:

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


Arango et al.                Informational                    [Page 38]


                    Basic MGCP Packages                     August 2001

  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.

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

  If the announcement cannot be played out for a reason determined
  after a successful response to the request as been provided, an
  operation failure event will be returned. The failure may be
  explained by a commentary, 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)























Arango et al.                Informational                    [Page 39]


                    Basic MGCP Packages                     August 2001

2.13.  Script Package

  Package Name: Script
  Version: 1

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

  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.

  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,
                                                             ...,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
  are provided in the operation failure 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,...))


Arango et al.                Informational                    [Page 40]


                    Basic MGCP Packages                     August 2001

  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.


3.0 Changes since draft-foster-mgcp-basic-packages-00.txt

       * Version events were removed in favor of using an audit
          capability in the base specification.
       * "do" and "dd" added to the DTMF package
       * Test pattern signal added to the T package; loopback signal
          definition added
       * "osi" and "lsa" added to the line package
       * Change to the SST package - removal of country specific
          tones.
       * Changes to the FM package
       * ICMP unreachable and RTP/RTCP timeout and loopback events
          added to the R package
       * Resource Lost event added to the RSVP "res" package.
       * Announcement Server and script package updated so that
          operation fail and operation complete events are consistent
          with [1].

4.0. Acknowledgements

  These packages are an update of the original packages in RFC 2705
  along with some new packages. Thanks to a number of people, including
  but not limited to: Jerry Kamitses, Sonus Networks; Dave Auerbach,
  Dan Wing, Cisco Systems; Ed Guy, Telcordia Technologies.

5.0. References

  [1] Arango et al, Media Gateway Control Protocol (MGCP)Version
  1.0bis, draft-andreasen-mgcp-rfc2705bis-01.txt

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

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

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

  [5] LSSGR: Signaling for Analog Interfaces, GR-506-CORE

  [6] Bellcore, Notes on the Network, Special Report SR-2275

  [7]  ANSI T1.207-2000, American National Standard for
  Telecommunications - Operations, Administration, Maintenance, and
  Provisioning (OAM&P) - Terminating Test Line Capabilities and Access
  Arrangements.



Arango et al.                Informational                    [Page 41]


                    Basic MGCP Packages                     August 2001

  [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] GR-529-CORE, Basic 911 Emergency Service (FSD 15-01-0000)

  [11] Internet Control Message Protocol, RFC 792.

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

  [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] GR-505-CORE, Call Processing

  [16] GR-531-CORE, LSSGR: Verification Connections, FSD 25-05-0903

6.0. Authors' Addresses

  Mauricio Arango
  901 San Antonio Road, UMPK15-214
  Palo Alto, CA 94303

  Email: Mauricio.Arango@sun.com


  Andrew Dugan
  Level3 Communications
  1025 Eldorado Blvd
  Broomfield, CO 80021
  Phone: +1 720 888 2983
  EMail: andrew.dugan@level3.com


  Isaac Elliott
  Level3 Communications
  1025 Eldorado Blvd., Bldg 4000
  Broomfield, CO 80021
  Phone: +1 720 888 6763
  EMail: ike.elliott@level3.com


  Christian Huitema
  Microsoft Corporation
  One Microsoft Way
  Redmond, WA 98052-6399

  EMail: huitema@microsoft.com

Arango et al.                Informational                    [Page 42]


                    Basic MGCP Packages                     August 2001



  Scott Pickett
  Vertical Networks
  1148 East Arques Ave
  Sunnyvale, CA 94086
  Phone: +1 408 585 3200
  EMail: ScottP@vertical.com


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


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

7.0. Full Copyright Statement

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

Arango et al.                Informational                    [Page 43]