Skip to main content

Basic Media Gateway Control Protocol (MGCP) Packages
draft-foster-mgcp-basic-packages-10

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 3660.
Authors Bill Foster , Flemming Andreasen
Last updated 2015-10-14 (Latest revision 2003-02-28)
RFC stream Legacy
Intended RFC status Informational
Formats
Stream Legacy state (None)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 3660 (Informational)
Action Holders
(None)
Telechat date (None)
Responsible AD Allison J. Mankin
IESG note
Send notices to <andrew.dugan@L3.com>
draft-foster-mgcp-basic-packages-10
Internet Engineering Task Force                            B. Foster 
Internet Draft                                          F. Andreasen 
Document: <draft-foster-mgcp-basic-packages-10.txt>    Cisco Systems 
Category: Informational                                February 2003 
 
 
                          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. 
 
IESG NOTE: 
 
  This document is being published for the information of the 
  community. It describes a non-IETF protocol that is currently being 
  deployed in a number of products. Implementers should be aware that 
  the IETF Megaco working group and the ITU-T Study Group 16 have 
  produced a standards track RFC "Megaco Protocol Version 1.0" (RFC 
  3015, also published as ITU recommendation H.248) which addresses the 
  same problem space and are developing extensions to that protocol for 
  functions of this type. 
   
Abstract 
 
  This document provides a basic set of Media Gateway Control Protocol 
  (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF, 
  announcement server and script packages are updates of packages from 
  RFC 2705 with additional explanation and in some cases new versions 
  of these packages. In addition to these, five new packages are 
  defined here. These are the signal list, resource reservation, media 
  format, supplementary services and digit map extension packages. 
 
Conventions used in this document 
   
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
  "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
  document are to be interpreted as described in RFC-2119. 
 
B. Foster, F. Andreasen      Informational                     [Page 1] 


                          Basic MGCP Packages             February 2003 

                                      
                            Table of Contents 
                                      
                                      
1. Introduction......................................................3 
 1.1. List of Packages...............................................3 
 1.2. Changes to Existing RFC 2705 Packages..........................3 
   1.2.1. Change in signal types.....................................3 
   1.2.2. Operation Complete and Operation Failure...................3 
   1.2.3. Package Versions...........................................4 
   1.2.4. Event Definitions, Aliases and Interoperability Issues.....4 
   1.2.5. New Events.................................................4 
 1.3. New Packages and Excluded Packages.............................5 
2. Packages..........................................................5 
 2.1.  Generic Media Package.........................................7 
 2.2.  DTMF package.................................................10 
 2.3.  Trunk Package................................................15 
 2.4.  Line Package.................................................22 
 2.5.  Handset Emulation Package....................................30 
 2.6.  Supplementary Services Tone Package..........................32 
 2.7.  Digit Map Extension..........................................34 
 2.8.  Signal List Package..........................................34 
 2.9. Media Format Parameter Package................................35 
 2.10. RTP Package..................................................39 
 2.11.  Resource Reservation Package................................44 
   2.11.1. Description..............................................44 
   2.11.2. Parameter Encoding.......................................47 
   2.11.3 Events....................................................48 
 2.12.  Announcement Server Package.................................50 
 2.13.  Script Package..............................................51 
3.0. IANA Considerations............................................53 
4.0. Security Considerations........................................53 
5.0. Acknowledgements...............................................54 
6.0. Normative References...........................................54 
7.0. Informative References.........................................55 
8.0. Authors' Addresses.............................................55 
9.0. Full Copyright Statement.......................................57 
   
   

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


                          Basic MGCP Packages             February 2003 

1. Introduction 
 
  This document provides a basic set of Media Gateway Control Protocol 
  (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF, 
  announcement server and script packages are updates of packages from 
  RFC 2705 with additional explanation and in some cases new versions 
  of these packages. In addition to these, five new packages are 
  defined here. These are the signal list, resource reservation, media 
  format, supplementary services and digit map extension packages. 
   
1.1. List of Packages 
   
  The basic set of packages specified in this document is for use with 
  MGCP 1.0 as defined in [1]. Included are the following packages: 
 
           ------------------------------------------- 
          | Package                        |   Name   | 
          |-------------------------------------------| 
          | Generic Media Package          |   G      | 
          | DTMF package                   |   D      | 
          | Trunk Package                  |   T      | 
          | Line Package                   |   L      | 
          | Handset Package                |   H      | 
          | Supplementary Services Package |   SST    | 
          | Digit Map Extension            |   DM1    | 
          | Signal List Package            |   SL     | 
          | Media Format Package           |   FM     | 
          | RTP Package                    |   R      | 
          | Resource Reservation Package   |   RES    | 
          | Announcement Server Package    |   A      | 
          | Script Package                 |   Script | 
           ------------------------------------------- 
 
1.2. Changes to Existing RFC 2705 Packages 
 
1.2.1. Change in signal types 
 
  MGCP 1.0 as defined in RFC 2705 (and now updated in [1]) provided 
  some additional clarification on the meaning of On-Off (OO) signals 
  compared to earlier versions of MGCP. This lead to some inconsistency 
  in some of the signal definitions in the accompanying packages in RFC 
  2705. This has been corrected in the packages that are included here 
  by changing some of the signals from type On-Off to type Time-Out 
  (TO).  
   
1.2.2. Operation Complete and Operation Failure 
 
  Another change also made to improve consistency and interoperability 
  was to add the "operation complete" and "operation failure" events in 
  packages where there are TO signals defined but where the "operation 
  complete" and "operation failure" events were not previously included 
  as part of the package. By definition, all packages that contain 
  Time-Out type signals now contain the "operation failure" ("of") and 

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


                          Basic MGCP Packages             February 2003 

  "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.  
    
  It is considered good practice to explicitly mention that the "oc" 
  and "of" events are supported in accordance with their default 
  definitions. If no definition is included in the package, the default 
  syntax and semantics is assumed.  
   
  Please refer to [1] for additional details on these events.  
   
1.2.3. Package Versions 
 
  The generic, line, trunk, handset, RTP, DTMF, announcement server and 
  script packages included in this document are new versions of 
  packages that were previously contained in RFC 2705. The updated base 
  MGCP 1.0 specification [1] provides an optional capability of 
  auditing package versions. Any gateway that implements versioned 
  packages SHOULD also implement this option. 
   
1.2.4. Event Definitions, Aliases and Interoperability Issues 
 
  Some event definitions or clarifications of previous event 
  definitions have also been added in order to improve 
  interoperability.  
   
  In some cases events have aliases either in the same or in other 
  packages and a recommendation has been made for the use of alternates 
  by Call Agents for future implementations. For maximum 
  interoperability, gateways MUST still implement these events (in fact 
  they MUST always implement all of the events, signals, etc. in a 
  package). 
   
  Some events that were previously defined require specific 
  provisioning in both the gateway and the Call Agent in order to allow 
  for interoperability. In those cases, a warning to that affect has 
  been included. 
   
1.2.5. New Events 
   
  In some cases new events have been added to existing packages. Any 
  changes to existing packages of course have resulted in the package 
  version number being updated from unversioned (version 0) to version 
  1. 
   

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


                          Basic MGCP Packages             February 2003 

1.3. New Packages and Excluded Packages 
 
  Two packages from RFC 2705 have not been included. These are the "MF" 
  and the "NAS" package. These packages are still valid as are all 
  unversioned (version 0) packages defined in RFC 2705. The reason 
  these packages were not included are: 
   
     * The original MF package had no defined way to outpulse MF digits 
       so that MF CAS is now provided by other packages (i.e. the "MS", 
       "MO" and "MD" packages) in a separate document.  
     * The "N" package as defined in RFC 2705 was incomplete. A new 
       MGCP "NAS" package has been developed and provided in a separate 
       document. 
   
  New packages have also been included beyond what was included in RFC 
  2705. These are the signal list, resource reservation, media format, 
  supplementary services and digit map extension packages. The Resource 
  Reservation ("RES") and Media Format ("FM") packages in particular 
  are different from other packages in this document in that they 
  contain new LocalConnectionOptions. This is allowed by the new 
  extension rules in [1]. Future packages of this type MUST use a 
  packages prefix in front of local connection options ("<package-
  name>/<Local Connection Option>") so as to avoid name-space problems. 
  However because of the timing of the arrival of these packages 
  relative to updating MGCP 1.0, this was not done for the "RES" and 
  "FM" packages. The resulting new local connection options 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: 
 
 
B. Foster, F. Andreasen      Informational                     [Page 5] 


                          Basic MGCP Packages             February 2003 

      * OO     On/Off signal 
 
      * TO     Time-Out signal. 
 
      * BR     Brief signal. 
 
      In addition, a "C" will be included if the signal can be 
      generated on a connection. 
 
      Duration: specifies the default duration of TO signals. If a 
      duration is left unspecified then the default timeout will be 
      assumed to be infinite unless explicitly noted in the description 
      of the signal. A duration may also be declared as being variable 
      in a case where signals involve complex sequencing (e.g. scripts 
      or digit out-pulsing) where the amount of time may vary with 
      either processing time or the signaling environment. 
       
  Default time-out values may be over-ridden by the Call Agent for any 
  Time-Out event defined in this document (with the exception of those 
  that have a default value of "variable") by a "to" signal parameter 
  which specifies the timeout value in milliseconds (see [1]). Example: 
 
         S: sst/cw(to=20000) 
   
  indicates a timeout value of 20 seconds. 
      
  As indicated in [1]: by default, a supplied time-out value MAY be 
  rounded to the nearest non-zero value divisible by 1000, i.e. whole 
  second. However, individual signal definitions within a package may 
  define other rounding rules. 
   
  Note that Time-Out signals that involve other parameters still allow 
  the use of the "to" signal parameter e.g.: 
   
        S: T/sit(1,to=3000) 
   
  The order of the "to" parameter relative to the other parameters is 
  not important. 
   
  Note: as per [1], On-Off (OO) signals are parameterized with "+" 
  (meaning turn on) or "-" (meaning turn off). If the parameter is 
  missing, the default is to turn on the signal. Unlike Time-Out 
  signals, On-Off signals do not stop when an event occurs. 
   
  Other than the "to" parameter for Time-out (TO) signals and the "+" 
  and "-" for On-Off (OO) signals, signals and events in the packages 
  in this document do not have parameters unless explicitly indicated 
  in the description of the event for that package. 
   
  In some of the signal definitions below, specific tone definitions 
  are provided even though actual frequencies may vary from country to 
  country. 
    

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


                          Basic MGCP Packages             February 2003 

2.1.  Generic Media Package 
 
  Package Name: G 
  Version: 1 
   
  The generic media package groups the events and signals that can be 
  observed on several types of endpoints, such as trunk gateway 
  endpoints, access gateway endpoints or residential gateway endpoints. 
   
   --------------------------------------------------------------- 
  | Symbol   |   Definition               |   R | S     Duration  | 
  |---------------------------------------------------------------| 
  | cf       |   Confirm Tone             |     | BR              | 
  | cg       |   Congestion Tone          |     | TO    infinite  | 
  | ft       |   Fax Tone                 |   x |                 | 
  | it       |   Intercept Tone           |     | TO    infinite  | 
  | ld       |   Long Duration Connection |   C |                 | 
  | mt       |   Modem Tone               |   x |                 | 
  | oc       |   Operation Complete       |   x |                 | 
  | of       |   Operation Failure        |   x |                 | 
  | pat(###) |   Pattern Detected         |   x | OO              | 
  | pt       |   Preemption Tone          |     | TO    infinite  | 
  | rbk(...) |   Ringback                 |     | TO,C 180 seconds| 
  | rt       |   Ringback Tone            |     | TO,C 180 seconds| 
   --------------------------------------------------------------- 
   
  New events added to this package from the previously unversioned 
  package: "oc" 
   
  Changes: "it" and "pt" signals changed from OO to TO. 
   
  Note that default time-out values may be over-ridden by the Call 
  Agent for any Time-Out signal defined in this package by a "to" 
  signal parameter. Refer to section 2 of this document as well as [1] 
  for details. 
   
  The events and signals are defined as follows: 
   
  Confirmation Tone (cf):  
     This is also referred to as "positive indication tone" in ITU-T 
     E.182. In North America, Confirmation Tone uses the same 
     frequencies and levels as dial tone (350 and 440 Hertz) but with a 
     cadence of 0.1 second on, 0.1 second off repeated three times. See 
     GR-506-CORE [7] Section 17.2.4. It is considered an error to try 
     and play confirmation tone on a phone that is on hook and an error 
     MUST consequently be returned when such attempts are made (error 
     code 402 - phone on hook).  
   
  Congestion Tone (cg): 
     Refer to ITU-T E.180 [8] and E.182 [10]. This maps to re-order 
     tone in North America (refer to GR-506-CORE [7] Section 17.2.7). 
   
   
   
 
B. Foster, F. Andreasen      Informational                     [Page 7] 


                          Basic MGCP Packages             February 2003 

  Fax Tone (ft): 
     The fax tone event is generated whenever a fax call is detected by 
     the presence of V.21 fax preamble. The fax tone event SHOULD also 
     be generated when the T.30 CNG tone is detected. See ITU-T 
     Recommendations T.30 and V.21. 
   
  Intercept Tone(it): 
     This is a country specific tone as defined in ITU-T, E.180 
     Supplement 2 [9].  
   
  Long Duration Connection (ld): 
     The "long duration connection" is detected when a connection has 
     been established for more than some time. The default value is 1 
     hour, however the provisioning process may change this. 
   
     This event is detected on a connection. When no connection is 
     specified as part of the request, the event applies to all 
     connections for the endpoint, regardless of when the connections 
     are created. The "all connections" wildcard (see [1]) may also be 
     used for this case, and is in fact preferred for consistency. In 
     either case, the name of the connection on which the event was 
     detected will be included when the event is observed, e.g.: 
   
          G/ld@0A3F58 
   
  Modem Tone (mt): 
     Indicates V.25 Answer tone (ANS) with or without phase reversals 
     or V.8 Modified Answer Tone (ANSam) tone with or without phase 
     reversals. Note that this implies the presence of a data call. 
     Also note that despite the name of the event, devices other than 
     modems may generate such tones, e.g. a fax machine. 
   
  Operation Complete (oc): 
     The standard definition of operation complete [1].      
   
  Operation Failure (of): 
     The standard definition of operation failure [1]. 
   
  Pattern Detected (pat(###)): 
     This event requires special provisioning that needs to be agreed 
     on between the Call Agent and media gateway in order to ensure 
     interoperability. It is retained in order to maintain backwards 
     compatibility with version 0 of the "G" package. This event MUST 
     be parameterized with a decimal numeric value from 0 to 999 
     specifying the pattern to detect. When reported, the pattern is 
     also included as a parameter. 
   
  Preemption Tone (pt): 
     This is a country specific tone and is defined in ITU-T, E.180 
     Supplement 2. 
 

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


                          Basic MGCP Packages             February 2003 

  Ringback (rbk(connectionID)): 
     This is an alias for "rt@connectionID" and is included here for 
     backwards compatibility only. It is recommended that Call Agents 
     use "rt@connectionID" instead of "rbk(connectionID)" for ring-back 
     over a connection for new implementations. Although the ringback 
     signal is applied on a connection, the "rbk" signal does not 
     support the "@connection" syntax. When the signal is requested, it 
     MUST be parameterized with a connection-ID or a connection-ID 
     wildcard as specified in [1].   
   
  Ringback Tone (rt): 
     Refer to ITU-T E.180 and ITU-T E.182. Also referred to as ringing 
     tone - a tone advising the caller that a connection has been made 
     and that a calling signal is being applied to the called party or 
     service point. In North America this tone is a combination of two 
     AC tones with frequencies of 440 and 480 Hertz and levels of -19 
     dBm each, to give a combined level of -16 dBm. The cadence for 
     Audible Ring Tone is 2 seconds on followed by 4 seconds off. See 
     GR-506-CORE - LSSGR: SIGNALING, Section 17.2.5.  
   
     This signal can be applied directly to an endpoint or 
     alternatively on a connection using the syntax "rt@connectionID". 
     When the ringback signal is applied to an endpoint, it is 
     considered an error to try and play ring back tones, if the 
     endpoint is considered on hook and an error MUST consequently be 
     returned when such attempts are made (error code 402 - phone on 
     hook). When the ringback signal is applied to a connection, no 
     such check is to be made.  
   
     Note that as specified in [1], signals requested on a connection 
     MUST be played regardless of the connection mode. For example, in 
     a call-waiting situation, ringback tone may be played on a 
     connection in "inactive" mode. 
 

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


                          Basic MGCP Packages             February 2003 

2.2.  DTMF package 
   
  Package name: D 
  Version: 1 
   
   -------------------------------------------------------------- 
  | Symbol  |   Definition              |   R |   S     Duration | 
  |--------------------------------------------------------------| 
  | 0       |   DTMF 0                  |   x |   BR             | 
  | 1       |   DTMF 1                  |   x |   BR             | 
  | 2       |   DTMF 2                  |   x |   BR             | 
  | 3       |   DTMF 3                  |   x |   BR             | 
  | 4       |   DTMF 4                  |   x |   BR             | 
  | 5       |   DTMF 5                  |   x |   BR             | 
  | 6       |   DTMF 6                  |   x |   BR             | 
  | 7       |   DTMF 7                  |   x |   BR             | 
  | 8       |   DTMF 8                  |   x |   BR             | 
  | 9       |   DTMF 9                  |   x |   BR             | 
  | #       |   DTMF #                  |   x |   BR             | 
  | *       |   DTMF *                  |   x |   BR             | 
  | A       |   DTMF A                  |   x |   BR             | 
  | B       |   DTMF B                  |   x |   BR             | 
  | C       |   DTMF C                  |   x |   BR             | 
  | D       |   DTMF D                  |   x |   BR             | 
  | DD(..)  |   DTMF Tone Duration      |   x |   TO  3 seconds  | 
  | DO(..)  |   DTMF OO Signal          |     |   OO             | 
  | L       |   Long Duration Indicator |   x |                  | 
  | oc      |   Operation Complete      |   x |                  | 
  | of      |   Operation Failure       |   x |                  | 
  | T       |   Interdigit Timer        |   x |   TO 16 seconds  | 
  | X       |   DTMF Tones Wildcard,    |   x |                  | 
  |         |    match any digit 0-9    |     |                  | 
   -------------------------------------------------------------- 
   
  Changes from the previous version of the package: events "dd", "do", 
  "oc" were added. 
   
  Note that DTMF tones including the DTMF tones wildcard can use the 
  eventRange notation defined in [1] when requesting events, e.g. 
  "D/[0-9](N)". 
   
  Note that default time-out values may be over-ridden by the Call 
  Agent for any Time-Out signal defined in this package by a "to" 
  signal parameter. Refer to section 2 of this document as well as [1] 
  for details. 
   
  The events are defined as follows: 
   
  DTMF tones (0-9,#,*,A,B,C,D): 
     Detection and generation of DTMF tones is described in GR-506-CORE 
     - LSSGR: SIGNALING, Section 15. Note that it is considered an 
     error to try and play DTMF tones on a phone that is on hook and an 
     error MUST consequently be returned when such attempts are made 
     (error code 402 - phone on hook). The event codes can be specified 
 
B. Foster, F. Andreasen      Informational                    [Page 10] 


                          Basic MGCP Packages             February 2003 

     in a digit map. When requested as a signal, as per GR-506-CORE, 
     section 15, a minimum tone duration of 50 ms will be followed by a 
     minimum interdigit silence period of 45 ms, i.e. if requested in a 
     signal list such as "S: sl/s(d/5,d/6,d/7)", then interdigit timing 
     requirements will be satisfied. 
   
     Note that some types of endpoints such as announcement endpoints 
     MAY allow detection and/or generation of DTMF tone over a 
     connection. However, this requires consistent provisioning between 
     the Call Agent and announcement server (it is not required in 
     order to be compliant with the DTMF package). 
 
  DTMF Tone Duration (dd(dg=<tone>,to=<time>,su=<TrueOrFalse>)): 
     This event can be used to indicate if/when the specified <tone>, 
     has a duration greater than the <time> value indicated (and is 
     reported once when the duration is exceeded). The parameters can 
     be supplied in any order. The value of <tone> can be any of the 
     DTMF tone symbols (without including the package name) specified 
     in the DTMF package (including X in the case of events, but not 
     signals). If this parameter is absent, any DTMF tone that occurs 
     will be reported. The parameter <time> is in milli-seconds and may 
     be rounded to the nearest 10 ms by the gateway. The minimum value 
     of <time> that can be requested when requesting an event is 40 ms. 
     When requesting a signal, the minimum value of <time> that can be 
     requested is 50 ms. The maximum value of the <time> that can be 
     requested for either an event or a signal is 60000 ms. If the 
     "to=<time>" parameter is absent when requested as an event, the 
     event will report the full duration (up to 60000 ms) of the tone 
     when the tone is completed. When reported as an ObservedEvent, 
     both parameters are always supplied. In this case <tone> is the 
     actual tone detected and <time> is either: 
   
        * The <time> specified in the request (possibly rounded), or 
   
        * If the request did not contain a "to=<time>" parameter, the 
           full duration of the tone. 
   
     The parameter "su" MAY be included when this is requested as an 
     event (but is not reported). This parameter is used to indicate 
     whether or not the DTMF digits requested should be suppressed in-
     band when it is requested. Possible values are "true", indicating 
     that in-band DTMF should be suppressed and "false" indicating that 
     DTMF should continue to be passed in-band. The default value if 
     the parameter is missing is "false". The "su" parameter MUST NOT 
     be included when requesting "D/dd" as a signal. 
      
     When used as a signal, "dd" provides the ability to generate a 
     DTMF tone as a TO signal. When applied as a signal, an additional 
     50 ms of silence will be tacked onto the end before the operation 
     complete occurs, i.e. "S: dd(dg=5,to=2500)" will play the DTMF 
     tone for the number "5" for 2.5 seconds, followed by 50 ms of 
     silence period. The operation complete (if requested) will be 
     notified after the silence interval occurs. Any value from 50 ms 

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


                          Basic MGCP Packages             February 2003 

     to 60000 ms can be requested. Gateways generating or detecting the 
     tone may round off the requested time to the nearest 10 ms. 
   
     The "dd" event can be used in place of the "long duration" event 
     in order to detect a digit pressed for longer than 2 seconds. For 
     example, in order to detect if a user presses the long "#" for 
     longer than 2 seconds, a request could be made with the 
     RequestedEvents line "R: d/dd(N)(dg=#,to=2000)". The resulting 
     ObservedEvents line would be "O: d/dd(dg=#,to=2000)". 
      
     Suppose instead, that the RequestedEvents line contains  
   
          R: d/[0-9*#],d/dd 
      
     Suppose the user then pushes the "#" for 2.5 seconds. In this 
     case, two events will be notified: 
   
          O: d/# 
   
     when the "#" key is first pressed, and 
   
          O: d/dd(dg=#,to=2500) 
   
     when the "#" key is finally released. 
   
  DTMF OO Signal (do(dg=<tone>,<on-or-off>)): 
     This signal is used to generate a DTMF tone as an on-off signal. 
     The <tone> parameter is any of the symbols for a specific tone in 
     the DTMF package (i.e. "0" to "9", "A", "B", "C", "D", "*", or 
     "#"). The <on-or-off> indicator is "+" for on and "-" for off as 
     per [1]. The <tone> parameter MUST be supplied, otherwise a return 
     code of 538 - "Event/signal parameter error" will be provided in 
     the response. If the <on-or-off> parameter is missing, the default 
     is to turn the signal on as usual (i.e. "+" is the default). The 
     order of the parameters is not significant since "+" and "-" are 
     reserved characters and are easily distinguished from the <tone> 
     parameter. 
   
  Long Duration Indicator (l): 
     The "long duration indicator" is observed when a DTMF signal is 
     produced for a duration larger than two seconds. In this case, the 
     gateway will detect two successive events: first, when the signal 
     has been recognized, the DTMF signal, and then, 2 seconds later, 
     the long duration signal.  
   
  Operation Complete (oc):    
     This is the standard definition of operation complete [1]. 
   
  Operation Failure (of): 
     This is the standard definition of operation failure [1]. 
   

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


                          Basic MGCP Packages             February 2003 

  Timer (t): 
     Timer T can be used as an event or as a time-out (TO) signal. As a 
     signal it's only behavior is the normal characteristics of a "TO" 
     signal as defined in [1] (i.e. if no event occurs before the time-
     out, an operation complete event will be generated). 
      
     As an event, Timer T is a digit input timer that can be used in 
     two ways: 
    
     *  When timer T is used with the accumulate according to digit map 
        action, the timer is not started until the first DTMF tone is 
        entered, and the timer is restarted after each new DTMF tone is 
        entered until either a digit map match or mismatch occurs. In 
        this case, timer T functions as an inter-digit timer as 
        illustrated by: 
         
          R: D/[0-9T](D)  
    
     *  When timer T is used without the "accumulate according to digit 
        map" action, the timer is started immediately and simply 
        cancelled (but not restarted) as soon as a DTMF tone is 
        entered. In this case, timer T can be used as an inter-digit 
        timer when overlap sending is used, as in: 
         
          R: D/[0-9](N), D/T(N) 
         
     When used with the "accumulate according to digit map" action, 
     timer T takes on one of two values, T-partial or T-critical. When 
     at least one more symbol is required for the "current dial string" 
     to match any one of the patterns in the digit map, timer T takes 
     on the value T-partial, corresponding to partial dial timing. If a 
     timer is all that is required to produce a match, timer T takes on 
     the value T-critical corresponding to critical dial timing. When 
     timer T is used without the "accumulate according to digit map" 
     action, timer T takes on the value T-critical. The default value 
     for T-partial is 16 seconds and the default value for T-critical 
     is 4 seconds. The provisioning process may alter both of these. If 
     timer T is not used, then inter-digit timing will not be 
     performed. 
    
     The following examples illustrate this. Consider the digit map: 
    
          (xxxxxxx|x11T) 
    
     and assume that DTMF and the timer T is accumulated according to 
     digit map. At the first DTMF input, say "4", timer T is started 
     with a value of T-partial since at least one more symbol is 
     required. If "1" is then input, it leads to a restart of timer T 
     with a value of T-partial again. If "1" is now input again, we 
     have a current dial string of "411" and a timer is now all that is 
     required to produce a match. Hence timer T is now restarted with 
     value T-critical.  
    

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


                          Basic MGCP Packages             February 2003 

     Finally, consider the following subtle examples (all assuming DTMF 
     and timer T being accumulated according to digit map):  
    
     The digit map  
      
          (1[2-3T].) 
      
     will match immediately on the input "1" since zero or more matches 
     of the range are specified.  
      
     The digit map 
      
          (1[2-3].T) 
      
     and an input of "1" will lead to timer T being set to T-critical. 
      
     A digit map of  
      
          (1[2-3]T.) 
      
     and an input of "1" will lead to timer T being set to T-partial. 
     Furthermore, upon subsequent input of "2" or "3" a perfect match 
     will trigger immediately since timer T is completely irrelevant.  
    
  DTMF Tones Wildcard (X): 
     The DTMF tones wildcard matches any DTMF digit between 0 and 9. 
     The actual event code generated will however be the event code for 
     the digit detected. The DTMF tones wildcard is often used to 
     detect DTMF input to be matched against a digit map. 
      
   

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


                          Basic MGCP Packages             February 2003 

2.3.  Trunk Package 
   
  Package Name: T 
  Version: 1 
   
   ---------------------------------------------------------------- 
  | Symbol   |   Definition                   |   R | S  Duration  | 
  |----------------------------------------------------------------| 
  | as       |   Answer Supervision           |   x | BR           | 
  | bl       |   Blocking                     |     | BR           | 
  | bz       |   Busy                         |     | TO  30 sec.  | 
  | co1      |   Continuity Tone (go tone,    |   x | TO  3 sec.   | 
  |          |   or return tone)              |     |              | 
  | co2      |   Continuity Test (go tone,    |   x | TO  3 sec.   | 
  |          |   or return tone in dual tone  |     |              | 
  |          |   procedures)                  |     |              | 
  | ct(...)  |   Continuity Transponder       |     | OO           | 
  | lb       |   Loopback                     |     | OO           | 
  | nm       |   New Milliwatt Tone           |   x | TO  3 sec    | 
  | mm       |   Newest Milliwatt Tone        |   x | TO  3 sec    | 
  | oc       |   Operation Complete           |   x |              | 
  | of       |   Operation Failure            |   x |              | 
  | om       |   Old Milliwatt Tone           |   x | TO  3 sec    | 
  | pst      |   Permanent Signal Tone        |     | TO  infinite | 
  | qt       |   Quiet Termination            |     | TO  infinite | 
  | ro       |   Reorder Tone                 |   x | TO  30 sec.  | 
  | sit(#)   |   Special Information Tone     |   x | TO  2 sec.   | 
  |          |                                |     |  (see notes) | 
  | tl       |   Test Line                    |   x | TO  infinite | 
  | tp(###)  |   Test Pattern                 |   x | TO  3 sec    | 
  | zz       |   No Circuit                   |   x | TO  2 sec    | 
   ---------------------------------------------------------------- 
 
  New events added to this package from the previously unversioned 
  package: "bz", "ct", "mm", "oc", "pst", "qt", "sit", and "tp". 
   
  Changes in event types: "co1", "co2", "nm", "om", "tl", "zz" signals 
  changed from OO to TO; "as" and "bl" changed from OO to BR. 
   
  Note that default time-out values may be over-ridden by the Call 
  Agent for any Time-Out signal defined in this package by a "to" 
  signal parameter. Refer to section 2 of this document as well as [1] 
  for details. 

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


                          Basic MGCP Packages             February 2003 

  The definition of the trunk package events are as follows: 
   
  Answer Supervision (as): 
     This event is used to indicate the occurrence answer supervision. 
     In most cases it is a result of a steady off-hook in response to a 
     call request. This event is included for backwards compatibility 
     with the previous version of the package. The preferred 
     alternative is to use the "answer" event in the appropriate CAS 
     packages [23] (Note: check the details on the use of "answer" in 
     the particular CAS package; in most cases "answer" as an event is 
     an indication of a steady off-hook regardless of whether or not it 
     is an indication of answer supervision). For details on when 
     answer supervision is appropriate refer to [5]. 
   
  Blocking (bl): 
     This event is used to indicate an incoming off-hook for the 
     purposes of blocking a one-way trunk in CAS trunks. This event is 
     included for backwards compatibility with the previous version of 
     the package. The preferred alternative is the "block" event in the 
     appropriate CAS packages [23]. 
   
  Busy Tone (bz): 
     Refer to ITU-T E.180. In North America, station Busy is a 
     combination of two AC tones with frequencies of 480 and 620 Hertz 
     and levels of -24 dBm each, to give a combined level of -21 dBm. 
     The cadence for Station Busy Tone is 0.5 seconds on followed by 
     0.5 seconds off, repeating. See GR-506-CORE - LSSGR: SIGNALING, 
     Section 17.2.6. 
   
  Continuity Tone (co1): 
     A tone at 2010 Hz (see section 3.1.1.3 of [2]). When generated as 
     a signal, the frequency of the tone must be within + or - 8 Hz, 
     while the frequency of the tone corresponding to the event must be 
     within + or - 30 Hz. 
   
  Continuity Test (co2): 
     A tone at 1780 Hz (see section 3.1.1.3 of [2]). When generated as 
     a signal, the frequency of the tone must be within + or - 20 Hz, 
     while the frequency of the tone corresponding to the event must be 
     within + or - 30 Hz. 
   
     In continuity testing the tone corresponding to the signal at the 
     originating gateway is referred to as the "go" tone and the tone 
     corresponding to the event at that same gateway is referred to as 
     the "return" or "check" tone. 
      
     Note that generation and notification of continuity tones are done 
     as per continuity test requirements as defined in ITU-T Q.724 [3] 
     as well as by Bellcore GR-317-CORE [2] specifications, i.e. the 
     semantics of notification of the return tone is more than that the 
     tone was received, but is an indication that the test has passed. 
     Details are provided in the following paragraphs. 
      

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


                          Basic MGCP Packages             February 2003 

     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: 
   
       RQNT 1234 ds/ds1-1/17@tgw2.example.net 
       X: AB123FE0 
       S: t/co1 
       R: t/co2,t/oc,t/of 
      
     On a terminating side of a trunk, the call agent may request a 
     continuity test connection (connection mode "conttest") to the 
     terminating gateway as follows: 
      
       CRCX 3001 ds/ds1-2/4@tgw34.example.net 
       C: 3748ABC364 
       M: conttest 
      
     Alternatively, rather than using a connection mode, the "T/ct" 
     signal can be used (see description of this signal further below): 
      
       RQNT 3001 ds/ds1-2/4@tgw34.example.net 
       X: 1233472 
       S: t/ct(in=co1,out=co2,+) 
      
     The originating gateway would send the requested "go" tone, and 
     would look for the appropriate "return tone". Once the return tone 
     is received, the originating gateway removes the go tone and 
     checks to see that return tone has been removed within specified 
     performance limits (i.e. GR-246-CORE, T1.113.4, Annex B). When it 
     detects that the test is successful, the gateway will send a 
     notification of the return tone event (Note that notification of 
     the return tone event therefore must not be sent prior to 
     detection of the removal of the return tone). 
 
B. Foster, F. Andreasen      Informational                    [Page 17] 


                          Basic MGCP Packages             February 2003 

      
     The "T/co1" and "T/co2" signals are TO signals so that an 
     operation complete event will occur when the signal times out. If 
     a timeout value other than the default is desired, the "to" 
     parameter may be used (e.g. "S: T/co1(to=2000)"). 
      
     If the gateway detects the failure of the continuity test prior to 
     the timeout, an operation failure event will be generated. 
     Otherwise the failure of the continuity test is determined by the 
     failure to receive the return tone event before the timeout occurs 
     (operation complete event). As with TO signals in general, 
     operation complete and operation fail events are parameterized 
     with the name of the signal. 
      
     In the example above where the go tone is "co1" and the return 
     tone is "co2": 
      
        * A notification of the "co2" event indicates success (i.e.  
           "O: t/co2"). 
        * A notification of the operation failure event indicates 
           failure prior to timeout (i.e. "O: t/of(t/co1)"). 
        * A notification of the operation complete event, indicates 
           that the return tone was not received properly prior to the 
           occurrence of the timeout (i.e. "O: t/oc(t/co2)"). 
      
     On a terminating end of a trunk, either a "loopback" connection 
     (single tone test) or "conttest" connection (dual tone test) are 
     made (or alternatively the "T/lb" or "T/ct" signals are 
     requested). It is up to the termination end to make sure that the 
     return tone is removed as soon as the go tone disappears. The Call 
     Agent requests the removal of "contest" or "loopback" connections 
     (or "T/lb" or "T/ct" signals) at a termination end when the 
     results of the continuity test are obtained. 
      
     When "conttest" is used, the endpoint is provisioned as to which 
     transponder test is being performed (2010 Hz received and 1780 Hz 
     sent or vice versa). In the case of the corresponding "T/ct" 
     signal, the Call Agent can specify which tone is received and sent 
     as parameters. 
   
     Note that continuity tones in the trunk package are only ever sent 
     to the telephony endpoint. For network-based continuity, there are 
     continuity tones available in the RTP ("R") package. Although a 
     transponder (dual tone) test can be done, a single tone test is 
     generally sufficient in the case of continuity testing across an 
     IP network. 
   
  Continuity Transponder(ct(in=<tone-in>,out=<tone-out>, <+ or ->)):  
     This signal is used to provide transponder functionality 
     independent of connection mode, i.e. this is an alternative way to 
     provide the same functionality as "conttest" connection mode. The 
     parameters can be provided in any order. The <tone-in> and <tone-
     out> parameters can have values "co1" or "co2" corresponding to 
     the 2010 Hz and 1780 Hz tones associated with those symbols. If 
 
B. Foster, F. Andreasen      Informational                    [Page 18] 


                          Basic MGCP Packages             February 2003 

     one of the tones is "co1", then the other must be "co2" and vice 
     versa (i.e. <tone-in> and <tone-out> must have different values; 
     if loopback is required, then the "lb" signal in this package or 
     "loopback" connection mode should be used). 
      
     On detecting <tone-in>, <tone-out> will be generated in return. 
     The tone corresponding to <tone-out> will continue to be generated 
     until either: 
      
       * The signal is explicitly turned off (e.g. "S: t/ct(-)") or 
       * Removal of the <tone-in> tone is detected. 
   
     Note that while the signal is active (regardless of whether a tone 
     is active or not), media from the endpoint will not be forwarded 
     to or from the packet network (i.e. the continuity transponder 
     signal must be explicitly turned off by the Call Agent in order to 
     resume passing media between the packet network and the endpoint). 
      
  Loopback (lb): 
     This signal is used to provide loopback functionality independent 
     of connection mode, i.e. this is an alternative way to provide the 
     same functionality as "loopback" connection mode. 
 
     Note that while the loop-back signal is active (regardless of 
     whether a tone is active or not), media from the endpoint will not 
     be forwarded to or from the packet network (i.e. the loopback 
     signal must be explicitly turned off by the Call Agent in order to 
     resume passing media between the packet network and the endpoint). 
   
   
  New Milliwatt Tone (nm): 
     1004 Hz tone - refer to [4] and section 8.2.5 of [5]. 
   
  Newest Milliwatt Tone (mm): 
     1013.8 Hz - refer to [4]. 
   
  Operation Complete (oc): 
     This is the standard definition of operation complete [1]. 
   
  Operation Failure (of): 
     This is the standard definition of operation failure [1]. 
   
  Old Milliwatt Tone (om): 
     1000 Hz tone - refer to [4] and section 8.2.5 of [5]. 
   
  Permanent Signal Tone (pst): 
     In North America, this tone is applied to a busy line 
     verify/operator interrupt under specific circumstances as 
     described in [17]. 
   
  Quiet Termination (qt): 
     Quiet Termination is used in a 102 trunk test. Reference section 
     6.20.5 [5] as well as [4]. 
 
 
B. Foster, F. Andreasen      Informational                    [Page 19] 


                          Basic MGCP Packages             February 2003 

  Reorder Tone(ro): 
     This maps to congestion tone in the ITU-T E.182 specification. In 
     North America, reorder tone is a combination of two AC tones with 
     frequencies of 480 and 620 Hertz and levels of -24 dBm each, to 
     give a combined level of -21 dBm. The cadence for reorder tone is 
     0.25 seconds on followed by 0.25 seconds off, repeating 
     continuously (until time-out). See GR-506-CORE [7], Section 
     17.2.7. 
 
  Special Information Tone(sit(#)): 
     As described in ITU-T E.180, the special information tone consists 
     of a tone period in which 3 tones are produced followed by a 
     silent period of 1 second (total TO period of approximately 2 
     seconds). When used as a signal, it MUST be parameterized with a 
     parameter value from 1 to 7 with the following meaning as defined 
     in SR-2275, section 6.21.2 of [5]. 
      
         ------------------------------------------- 
        | sit(1) | RO' | reorder SIT, intra-LATA    | 
        | sit(2) | RO" | reorder SIT, inter-LATA    | 
        | sit(3) | NC' | no circuit SIT, intra-LATA | 
        | sit(4) | NC" | no circuit SIT, inter-LATA | 
        | sit(5) | IC  | intercept SIT              | 
        | sit(6) | VC  | vacant code SIT            | 
        | sit(7) | IO  | ineffective other SIT      | 
         ------------------------------------------- 
         
         
     When requested as an event, the event MUST be parameterized with a 
     decimal number from 1 to 7 to indicate which tone the gateway is 
     required to detect. The resulting notification also includes the 
     parameter. Other countries may have one or more special 
     information tones with country specific definitions (refer to ITU-
     T E.180 supp. 2 [9]). In this case special information tone 1 as 
     defined in [9] is sit(1), special information tone 2 is sit(2) 
     etc. 
      
     As an example, the Call Agent might make a request such as: 
      
        RQNT 1234 ds/ds1-1/17@tgw2.example.net 
        X: AB123FE0 
        R: t/sit(N)(2) 
      
     If the tone is detected, the resulting notification might appear 
     as follows: 
      
        NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 
        X: AB123FE0 
        O: t/sit(2) 
      
  Test Line (tl): 
     105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 
     dBm0). Refer to section 8.2.5 of [5]. 
 
B. Foster, F. Andreasen      Informational                    [Page 20] 


                          Basic MGCP Packages             February 2003 

   
  Test Pattern (tp(###)): 
     The tp(###) signal inserts the pattern ### continuously into the 
     channel until the timout period expires. The parameter is provided 
     as a decimal number from 0 to 255. If the parameter is omitted, 
     the default value is decimal 95. 
      
     In RequestedEvents, the parameter MAY be supplied to indicate what 
     pattern the Call Agent wishes the gateway to detect. If the 
     parameter is omitted, the value 95 is assumed. The pattern MUST be 
     returned in the ObservedEvent (even if the parameter was not 
     requested). 
      
     A typical use for the test pattern signal is for the test line 108 
     (digital loopback) test (refer to section 8.2.5 of [5]). At the 
     termination side of a trunk, the Call Agent would request a 
     connection in "loopback" mode, which would do a digital loopback. 
     On the origination side of the trunk, the Call Agent would request 
     that the test pattern be injected into the digital channel, and 
     would check to see that the pattern was returned within the 
     timeout period. As an example, the Call Agent would make the 
     following request on the origination side: 
      
              RQNT 1234 ds/ds1-1/17@tgw2.example.net 
              X: AB123FE0 
              S: t/tp 
              R: t/tp, t/oc, t/of 
      
     In this case the Call Agent will either receive: 
      
        * An ObservedEvent indicating that the test has passed  
           (i.e. "O:t/op(95)") or 
        * An ObservedEvent indicating that the timeout occurred before 
           the pattern was received (i.e. "O:t/oc(t/tp)"), indicating 
           that the test failed. Of course an operation failure would 
           indicate failure as well. 
   
  No Circuit (zz): 
     This is an alias for Special Information Tone 2, i.e. "sit(2)". 
      

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


                          Basic MGCP Packages             February 2003 

2.4.  Line Package 
   
  Package Name: L 
  Version: 1 
   
   ----------------------------------------------------------------  
  |Symbol       |   Definition               |   R |  S  Duration  | 
  |----------------------------------------------------------------| 
  |adsi(string) |   ADSI Display             |     |  BR           | 
  |aw           |   Answer Tone              |   x |  OO           | 
  |bz           |   Busy Tone                |     |  TO 30 sec.   | 
  |ci(ti,nu,na) |   Caller-id                |     |  BR           | 
  |dl           |   Dial Tone                |     |  TO 16 sec.   | 
  |e            |   Error Tone               |   x |  TO 2 sec.    | 
  |hd           |   Off-hook Transition      |   S |               | 
  |hf           |   Flash-hook               |   x |               | 
  |ht           |   On Hold Tone             |     |   OO          | 
  |hu           |   On-hook Transition       |   S |               | 
  |lsa          |   Line Side Answer Sup.    |     |   OO          | 
  |mwi          |   Message Waiting ind.     |     |   TO 16 sec.  | 
  |nbz          |   Network busy             |   x |   TO infinite | 
  |oc           |   Operation Complete       |   x |               | 
  |of           |   Operation Failure        |   x |               | 
  |osi          |   Network Disconnect       |     |   TO 900 ms   | 
  |ot           |   Off hook Warning Tone    |     |   TO infinite | 
  |p            |   Prompt Tone              |   x |   BR          | 
  |rg           |   Ringing                  |     |   TO 180 sec. | 
  |r0, r1, r2,  |   Distinctive Ringing      |     |   TO 180 sec. | 
  |r3, r4, r5,  |                            |     |               | 
  |r6 or r7     |                            |     |               | 
  |ro           |   Reorder Tone             |     |   TO 30 sec.  | 
  |rs           |   Ringsplash               |     |   BR          | 
  |s(###)       |   Distinctive Tone Pattern |   x |   BR          | 
  |sit(#)       |   Special Information Tone |     |   TO 2 sec.   | 
  |             |                            |     |   (see notes) | 
  |sl           |   Stutter Dial Tone        |     |   TO 16 sec.  | 
  |v            |   Alerting Tone            |     |   OO          | 
  |vmwi         |   Visual Message           |     |   OO          | 
  |             |     Waiting Indicator      |     |               | 
  |wt           |   Call Waiting Tone        |     |   TO 12 sec   | 
  |wt1, wt2,    |   Alternative Call         |     |   TO 12 sec   | 
  |wt3, wt4     |     Waiting Tones          |     |   (see notes) | 
  |y            |   Recorder Warning Tone    |     |   TO infinite | 
  |z            |   Calling Card Service Tone|     |   BR          | 
   ---------------------------------------------------------------- 
   
   
  New events added to this package from the previously unversioned 
  package: "ht", "osi", and "lsa". 
   
  Changes in event types: signals "y", "z", changed from OO to TO and 
  BR respectively. Ringing tones were extended to allow for a ring 
  repetition signal parameter. 
   
 
B. Foster, F. Andreasen      Informational                    [Page 22] 


                          Basic MGCP Packages             February 2003 

  Note that default time-out values may be over-ridden by the Call 
  Agent for any Time-Out signal defined in this package by a "to" 
  signal parameter. Refer to section 2 of this document as well as [1] 
  for details. 
   
  The description of events and signals in the line package are as 
  follows: 
   
  ADSI Display (adsi):  
     This signal is included here to maintain compatibility with the 
     previous version of this package. The signal is not well-defined 
     and its use is discouraged. 
 
  Answer Tone (aw): 
     This event is included here to maintain compatibility with the 
     previous version of this package. The event is not well-defined 
     and its use is discouraged. 
   
  Busy Tone (bz): 
     Refer to ITU-T E.180. In North America, station Busy is a 
     combination of two AC tones with frequencies of 480 and 620 Hertz 
     and levels of -24 dBm each, to give a combined level of -21 dBm. 
     The cadence for Station Busy Tone is 0.5 seconds on followed by 
     0.5 seconds off, repeating. See GR-506-CORE [7], Section 17.2.6. 
     It is considered an error to try and play busy tone on a phone 
     that is on hook and an error MUST consequently be returned when 
     such attempts are made (error code 402 - phone on hook). 
   
  Caller-id (ci(time, number, name)):  
     See TR-NWT-001188, GR-30-CORE, and TR-NWT-000031. For backwards 
     compatibility, each of the three fields are optional, however each 
     of the commas will always be included. In accordance with the 
     general MGCP grammar, it is however RECOMMENDED to always include 
     all three fields - an empty quoted string can then be used in lieu 
     of omitting a parameter: 
      
     The time parameter is coded as "MM/DD/HH/MM", where MM is a two-
     digit decimal value for Month between 01 and 12, DD is a two-digit 
     value for Day between 01 and 31, and Hour and Minute are two-digit 
     values coded according to military local time, e.g., 00 is 
     midnight, 01 is 1 a.m., and 13 is 1 p.m. (Note: two digits MUST 
     always provided for each of the values of month, day, hour, 
     minutes e.g. the month of January is indicated by the two digits 
     "01" rather than just "1"). 
        
     The number parameter is coded as an ASCII character string of 
     decimal digits that identify the calling line number. White spaces 
     are permitted if the string is quoted, however they will be 
     ignored. If a quoted-string is provided, the string itself is UTF-
     8 encoded (RFC 2279) as usual for signal parameters. 
        
     The name parameter is coded as a string of ASCII characters that 
     identify the calling line name. White spaces are permitted if the 

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


                          Basic MGCP Packages             February 2003 

     string is quoted. If a quoted-string is provided, the string 
     itself is UTF-8 encoded (RFC 2279).  
        
     A "P" in the number or name field is used to indicate a private 
     number or name, and an "O" is used to indicate an unavailable 
     number or name. Other letters MAY be used to provide additional 
     clarification as per provider or vendor specifications. 
        
     The following example illustrates the use of the caller-id signal: 
      
       S: l/ci(09/14/17/26, "555 1212", "John Doe") 
      
     An example indicating that the name and number are private: 
      
       S: l/ci(09/14/17/26,P,P) 
   
  Dial Tone (dl): 
     Refer to the ITU-T E.180 specification. In North America, dial 
     tone is a combination of two continuous AC tones with frequencies 
     of 350 and 440 Hertz and levels of -13dBm each to give a combined 
     level of -10 dBm. See GR-506-CORE - LSSGR: SIGNALING, Section 
     17.2.1. It is considered an error to try and play dial-tone on a 
     phone that is on hook and an error MUST consequently be returned 
     when such attempts are made (error code 402 - phone on hook). 
   
  Error Tone (e): 
     This tone is maintained for backwards compatibility. The tone is 
     not well defined and its use is discouraged. 
   
  Off-hook Transition (hd): 
     See GR-506-CORE [7], Section 12. It is considered an error to try 
     and request off-hook on a phone that is off-hook and an error MUST 
     consequently be returned when such attempts are made (error code 
     401 - phone off-hook). 
   
  Flash Hook (hf): 
     See GR-506-CORE [7], Section 12. It is considered an error to try 
     and request flash hook on a phone that is on-hook and an error 
     MUST consequently be returned when such attempts are made (error 
     code 402 - phone on-hook). 
   
  Tone On Hold (ht): 
     A tone used to reassure a calling subscriber who has been placed 
     on "hold". Refer to ITU-T E.182 [10]. 
   
  On-hook Transition (hu): 
     See GR-506-CORE [7], Section 12. The timing for the onhook signal 
     is for flash response enabled, unless provisioned otherwise. It is 
     considered an error to try and request flash hook on a phone that 
     is on-hook and an error MUST consequently be returned when such 
     attempts are made (error code 402 - phone on-hook). 
   

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


                          Basic MGCP Packages             February 2003 

  Line Side Answer Supervision (lsa): 
     This provides Reverse Loop Current Feed (RLCF) on the line (refer 
     to GR-506-CORE [7]) and is a way of indicating that the called 
     party has answered for some line-side equipment. 
   
  Message Waiting Indicator (mwi): 
     Message Waiting indicator tone uses the same frequencies and 
     levels as dial tone (350 and 440 Hertz at -13dBm each) but with a 
     cadence of 0.1 second on, 0.1 second off repeated 10 times 
     followed by steady application of dial tone. See GR-506-CORE [7], 
     Section 17.2.3. It is considered an error to try and play message-
     waiting indicator on a phone that is on hook and an error MUST 
     consequently be returned when such attempts are made (error code 
     402 - phone on hook). 
   
  Network Busy (nbz): 
     This is included here to maintain compatibility with the previous 
     version of this package. The "nbz" signal is an alias for re-order 
     tone signal("ro"). Future Call Agent implementations that require 
     a network busy signal should use the "ro" signal. It is also 
     recommended that future Call Agents not request to be notified of 
     the "nbz" event (a network busy event is generally not required in 
     a line package and hence "ro" is only a signal, not an event). 
   
  Operation Complete (oc): 
     This is the standard definition of operation complete [1]. 
   
  Operation Failure (of): 
     This is the standard definition of operation failure [1]. 
   
  Network Disconnect (osi): 
     Network Disconnect indicates that the far-end party has 
     disconnected. The signal that is sent on the line is provisioned 
     in the media gateway since it may vary from country to country. In 
     North America this signal is an open switch interval which results 
     in a Loop Current Feed Open Signal (LCFO) being applied to the 
     line (refer to GR-506-CORE [7], see also See GR-505-CORE [6], 
     Section 4.5.2.1). The default time-out value for this signal is 
     900 ms. 
   
  Off-hook Warning Tone (ot): 
     Off-hook warning tone, also known as receiver Off Hook Tone (ROH 
     Tone). This is the irritating noise a telephone makes when it is 
     not hung up correctly. In North America ROH Tone is generated by 
     combining four tones at frequencies of 1400 Hertz, 2060 Hertz, 
     2450 Hertz and 2600 Hertz at a cadence of 0.1 second on, 0.1 
     second off, repeating. GR-506-CORE [7], Section 17.2.8 contains 
     details about required power levels. It is considered an error to 
     try and play off-hook warning tone on a phone that is on hook and 
     an error MUST consequently be returned when such attempts are made 
     (error code 402 - phone on hook). 
   

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


                          Basic MGCP Packages             February 2003 

  Prompt Tone (p): 
     The definition of the prompt tone and its use may be found in 
     requirement GR-220 [20]. The tone in GR-220 (requirement "R3-170" 
     or GR-220) is a 300 ms burst of a 400 Hz tone. 
   
  Ringing (rg): 
     See GR-506-CORE [7], Section 14. The provisioning process may 
     define the ringing cadence. The ringing signal may be 
     parameterized with the signal parameter "rep" which specifies the 
     maximum number of ringing cycles (repetitions) to apply. The value 
     for "rep" is specified in decimal and can have any value from 1 to 
     255). The following will apply the ringing signal for up to 6 
     ringing cycles: 
      
       S: l/rg(rep=6) 
      
     If the "rep" parameter is specified, the signal times-out when the 
     number of repetitions are completed (i.e. an operation complete 
     event can be requested and will occur at the end of the 
     timeout/number of rings). 
      
     If the "rep" parameter is supplied, then any timeout ("to") value 
     that is included will be ignored. i.e.: 
      
       S: l/rg(rep=6,to=12000) 
        
     will be treated the same as the previous example where the 
     parameter "to=12000" was not included). Of course, if the "to" 
     parameter is included without the "rep", it will be acted upon 
     i.e.: 
      
      
       S: l/rg(to=12000) 
        
     will ring for 12 seconds. 
      
     It is considered an error to try and ring a phone that is off hook 
     and an error MUST consequently be returned when such attempts are 
     made (error code 401 - phone off hook). 
   
  Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7): 
     See GR-506-CORE [7], Section 14. Default values for r1 to r5 are 
     as defined for distinctive ringing pattern 1 to 5 in GR-506-CORE. 
     The default values for r0, r6 and r7 is normal ringing (i.e. the 
     same cadence "rg"). The provisioning process may define the 
     ringing cadence for each of these signals. The distinctive ringing 
     signals may be parameterized with the signal parameter "rep" which 
     specifies the maximum number of ringing cycles (repetitions) to 
     apply. The value for "rep" is specified in decimal and can have 
     any value from 1 to 255). 
      
     The following will apply the ringing signal for up to 6 ringing 
     cycles: 
      
 
B. Foster, F. Andreasen      Informational                    [Page 26] 


                          Basic MGCP Packages             February 2003 

       S: l/r1(rep=6) 
      
     If the "rep" parameter is specified, the signal times-out when the 
     number of repetitions are completed (i.e. an operation complete 
     event can be requested and will occur at the end of the 
     timeout/number of rings) 
      
     If the "rep" parameter is supplied, then any timeout ("to") value 
     that is included will be ignored. i.e.: 
      
       S: l/r1(rep=6,to=12000) 
        
     will be treated the same as the previous example where the 
     parameter "to=12000" was not included). Of course, if the "to" 
     parameter is included without the "rep", it will be acted upon 
     i.e.: 
      
      
       S: l/r1(to=12000) 
        
     will ring for 12 seconds. 
      
     It is considered an error to try and ring a phone that is off hook 
     and an error MUST consequently be returned when such attempts are 
     made (error code 401 - phone off hook). 
   
  Reorder Tone (ro): 
     This maps to congestion tone in the ITU-T E.182 [10] 
     specification. In North America, reorder tone is a combination of 
     two AC tones with frequencies of 480 and 620 Hertz and levels of -
     24 dBm each, to give a combined level of -21 dBm. The cadence for 
     reorder tone is 0.25 seconds on followed by 0.25 seconds off, 
     repeating continuously.  
   
  Ringsplash (rs): 
     Also known as "Reminder ring", this tone is a burst of ringing 
     that may be applied to the physical forwarding line (when idle) to 
     indicate that a call has been forwarded and to remind the user 
     that a Call Forward sub-feature is active. In the US, it is 
     defined to be a 0.5(-0,+0.1) second burst of power ringing (see 
     [11]). 
   
  Distinctive Tone Pattern (s(###)): 
     This is used to signal or detect a tone pattern defined by the 
     parameter where the parameter may have a value from 0 to 999. When 
     specified as an event, the parameter MUST be included. The 
     parameter will also be included when the event is reported. This 
     event (the definition of tones associated with each parameter 
     value) requires special provisioning in the Call Agent and gateway 
     to insure interoperability. This signal is included here to 
     maintain compatibility with the previous version of this package. 
   

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


                          Basic MGCP Packages             February 2003 

  Special Information Tone(sit(#)): 
     As described in ITU-T E.180 [8], the special information tone 
     consists of a tone period in which 3 tones are produced followed 
     by a silent period of 1 second (total TO period of approximately 2 
     seconds). It MAY be parameterized with a parameter value from 1 to 
     7 with the following meaning as defined in SR-2275, section 6.21.2 
     [5]: 
      
         ------------------------------------------- 
        | sit(1) | RO' | reorder SIT, intra-LATA    | 
        | sit(2) | RO" | reorder SIT, inter-LATA    | 
        | sit(3) | NC' | no circuit SIT, intra-LATA | 
        | sit(4) | NC" | no circuit SIT, inter-LATA | 
        | sit(5) | IC  | intercept SIT              | 
        | sit(6) | VC  | vacant code SIT            | 
        | sit(7) | IO  | ineffective other SIT      | 
         ------------------------------------------- 
         
         
     If the parameter is left out, the NC' SIT tone which corresponds 
     to the signal "L/sit(3)" is assumed. 
      
     Other countries may have one or more special information tones 
     with country specific definitions (refer to ITU-T E.180 supp. 2 
     [9]). In this case special information tone 1 as defined in [9] is 
     sit(1), special information tone 2 is sit(2) etc. 
   
  Stutter Dial Tone (sl): 
     Stutter Dial Tone (also called Recall Dial Tone in GR-506-CORE 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.  
   
     The stutter dial tone signal may be parameterized with the signal 
     parameter "del" which will specify a delay in milliseconds to 
     apply between the confirmation tone and the dial tone. The 
     parameter can have any value from 0 to 10000 ms, rounded to the 
     nearest non-zero value divisible by 100 (i.e. tenth of a second). 
     The following will apply stutter dial tone with a delay of 1.5 
     seconds between the confirmation tone and the dial tone: 
      
       S: l/sl(del=1500) 
      
     It is considered an error to try and play stutter dial tone on a 
     phone that is on hook and an error MUST consequently be returned 
     when such attempts are made (error code 402 - phone on hook). 
 
  Alerting Tone (v): 
     A 440 Hz Tone of 2 second duration followed by 1/2 second of tone 
     every 10 seconds. This event is included for backwards 
     compatibility with the previous version of the package. 
   
   
 
B. Foster, F. Andreasen      Informational                    [Page 28] 


                          Basic MGCP Packages             February 2003 

  Visual Message Waiting Indicator (vmwi): 
     The transmission of the VMWI messages will conform to the 
     requirements in [13] and the CPE guidelines in [12]. Refer also to 
     section 6.6 of GR-30 [14]. VMWI messages will only be sent from 
     the gateway to the attached equipment when the line is idle. If 
     new messages arrive while the line is busy, the VMWI indicator 
     message will be delayed until the line goes back to the idle 
     state. After the gateway restarts, the state of the signal will be 
     "off", and hence the Call Agent MUST refresh the CPE's visual 
     indicator if it is supposed to be "on". 
   
  Alternative Call Waiting Tones (wt, wt1, .., wt4): 
     Refer to ITU-T E.180 [8]. For North American tone definitions 
     refer to GR-506-CORE [7], Section 14.2. "wt" and "wt1" are both 
     aliases for the default Call Waiting tone which in North America 
     is a 440-Hz tone applied for 300 plus or minus 50 ms. The tone is 
     then repeated once after 10 seconds. 
   
     These signals are timeout signals with a default timeout value of 
     12 seconds, which allows the tone to be played twice with a single 
     request (refer to GR-571-CORE [16]). However, there are cases 
     (Requirement R3-73 of GR-575-CORE [18]), in which only a single 
     tone is required. In that case, the Call Agent may make the 
     request with a shorter timeout period to eliminate the second tone 
     (e.g. "S: wt(to=2000)" - which stops the signal after 2 seconds so 
     that the second tone will not occur). 
      
     Signals wt2, wt3 and wt4 are alternates that are used for 
     distinctive call-waiting tone patterns (refer to GR-506-CORE, 
     Section 14.2 [7]. It is considered an error to try and apply call-
     waiting tone on a phone that is on hook and an error MUST 
     consequently be returned when such attempts are made (error code 
     402 - phone on hook). 
 
  Recorder Warning Tone(y): 
     Refer to ITU-T E.180 [8] - also Bellcore document SR-2275 [5] 
     section 6.20. When recording equipment is used, this tone is 
     connected to the line to inform the distant party that the 
     conversation is being recorded  - typical value used is a 1400 Hz 
     Tone of 0.5 second duration every 15 seconds. 
 
  Calling Card Service Tone(z): 
     This tone is used to inform the customer that credit card 
     information must be keyed in. Typically it consists of 60 ms of 
     941 + 1477 Hz (the DTMF #digit) and 940 ms of 350 + 440 Hz (dial 
     tone), decaying exponentially with a time constant of 200 ms. 
     Refer to Bellcore document SR-2275 [5], section 6.20. 
   
   

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


                          Basic MGCP Packages             February 2003 

2.5.  Handset Emulation Package 
   
  Package Name: H 
  Version: 1 
   
   ---------------------------------------------------------------- 
  |Symbol       |   Definition               |   R |   S  Duration | 
  |----------------------------------------------------------------| 
  |adsi(string) |   ADSI Display             |   x |   BR          | 
  |aw           |   Answer Tone              |   x |   OO          | 
  |bz           |   Busy Tone                |   x |   TO 30 sec.  | 
  |ci(ti,nu,na) |   Caller-id                |   x |   BR          | 
  |dl           |   Dial Tone                |   x |   TO 16  sec. | 
  |e            |   Error Tone               |   x |   TO 2 sec.   | 
  |hd           |   Off-hook Transition      |   S |   BR          | 
  |hu           |   On-hook Transition       |   S |   BR          | 
  |hf           |   Flash Hook               |   x |   BR          | 
  |ht           |   Tone On Hold             |   x |   OO          | 
  |lsa          |   Line Side Answer Sup.    |   x |   OO          | 
  |mwi          |   Message Waiting Ind.     |   x |   TO 16 sec.  | 
  |nbz          |   Network Busy             |   x |   TO infinite | 
  |oc           |   Operation Complete       |   x |               | 
  |ot           |   Off-hook Warning Tone    |   x |   TO infinite | 
  |of           |   Operation Failure        |   x |               | 
  |osi          |   Network Disconnect       |   x |   TO 900 ms   | 
  |p            |   Prompt Tone              |   x |   BR          | 
  |rg           |   Ringing                  |   x |   TO 180 sec. | 
  |r0, r1, r2,  |   Distinctive Ringing      |   x |   TO 180 sec. | 
  |r3, r4, r5,  |                            |     |               | 
  |r6 or r7     |                            |     |               | 
  |ro           |   Reorder Tone             |   x |   TO 30 sec.  | 
  |rs           |   Ringsplash               |   x |   BR          | 
  |s(###)       |   Distinctive Tone Pattern |   x |   BR          | 
  |sit(#)       |   Sit Tone                 |   x |   TO 2 sec.   | 
  |sl           |   Stutter Dial Tone        |   x |   TO 16 sec.  | 
  |v            |   Alerting Tone            |   x |   OO          | 
  |vmwi         |   Vis. Message Waiting Ind.|   x |   OO          | 
  |wt           |   Call Waiting tone        |   x |   TO 12 sec.  | 
  |wt1, wt2,    |   Alternative Call         |   x |   TO 12 sec   | 
  |wt3, wt4     |     Waiting Tones          |     |   (see notes) | 
  |y            |   Recorder Warning Tone    |   x |   TO infinite | 
  |z            |   Calling Card Serv. Tone  |   x |   BR          | 
   ---------------------------------------------------------------- 
 
  The handset emulation package is similar to the line package except 
  that events such as "off hook" can be signaled as well as detected. 
   
  Changes from the original package - are the same changes as were made 
  for the line package plus "hu" and "hd" signal types were changed 
  from OO to BR. 
   
  Event definitions are the same as for the line package with the 
  following exceptions: 
   
 
B. Foster, F. Andreasen      Informational                    [Page 30] 


                          Basic MGCP Packages             February 2003 

  ASDI: 
     When requested as an event by the Call Agent, the event is not 
     parameterized. However, the parameter is included when the event 
     is reported. 
   
  Caller-id: 
     When requested as an event by the Call Agent, the event MUST not 
     parameterized. However, parameters are included when the event is 
     reported i.e.: 
      
       O: l/ci(09/14/17/26,"555 1212","John Doe") 
      
  Line Side Answer Supervision:  
     When requested as an event by the Call Agent, it indicates when 
     the reverse loop current feed (RLCF) was turned on and off. The 
     event is not parameterized when it is requested. However, a 
     parameter is included when it is reported i.e.:  
          O: l/lsa(+) to indicate RLCF was turned on  
          O: l/lsa(-) to indicate RLCF was turned off 
   
  Ringing (rg): 
     When requested as an event, the Call Agent may optional include 
     the rep parameter indicating to report after some number of rings 
     e.g.: 
      
        RQNT 1234 aaln/1@rgw2.example.net 
        X: AB123FE0 
        R: h/rg(N)(rep=3) 
      
     The resulting notification after the number of rings is detected 
     includes the parameter again: 
      
        NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 
        X: AB123FE0 
        O: h/rg(rep=3) 
      
     If the parameter is not included in the request, it is also not 
     included in the report. In that case, the event is report as soon 
     as ringing is detected. 
   
  Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7): 
     As with the "rg" event, if the "rep" parameter is included when 
     one of these is requested as an event, it is also reported. If it 
     is not requested with the parameter, then the parameter is also 
     not included in the report. In that case, the event is reported as 
     soon as ringing with the requested cadence is detected. 
   
  Stutter Dial Tone (sl): 
     Stutter Dial Tone MUST not parameterized when requested as an 
     event. However, the "del" parameter is reported. 
      
        RQNT 1234 aaln/1@rgw2.example.net 

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


                          Basic MGCP Packages             February 2003 

        X: AB123FE0 
        R: h/sl 
      
     The resulting notification indicates the delay between the 
     confirmation tone and the dial tone: 
      
        NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 
        X: AB123FE0 
        O: h/sl(del=1500) 
      
     As with the signal, the report indicates the delay rounded to the 
     nearest 100 ms. 
   
  Visual Message Waiting: 
     When requested as an event by the Call Agent, it indicates when 
     the visual message waiting indicator was turned on and off. The 
     event is not parameterized when it is requested. However, a 
     parameter is included when it is reported i.e.: 
      
       O: l/vmwi(+) to indicate message waiting turned on 
       O: l/vmwi(-) to indicate message waiting turned off 
 
  Note that: 
   
        * All TO signals in the handset package can include a "to" 
           parameter, when requested as a signal. 
        * However, requests to be notified about these events MUST NOT 
           include the "to" parameter, i.e. the "to" parameter is not 
           valid in RequestedEvents. 
   
2.6.  Supplementary Services Tone Package 
 
  Package Name: SST 
  Version: 0 
   
   ---------------------------------------------------------------  
  |Symbol       |   Definition               |   R |  S Duration  | 
  |---------------------------------------------------------------| 
  |cd           |   Conference Depart        |     |  BR          | 
  |cj           |   Conference Join          |     |  BR          | 
  |cm           |   Comfort Tone             |     |  TO infinite | 
  |cw           |   Caller Waiting Tone      |     |  TO 30 sec.  | 
  |ht           |   On Hold Tone             |     |  OO          | 
  |ni           |   Negative Indication      |     |  TO infinite | 
  |nu           |   Number Unobtainable      |     |  TO infinite | 
  |oc           |   Operation Complete       |   x |              | 
  |of           |   Operation Failure        |   x |              | 
  |pr           |   Pay Phone Recognition    |     |  BR          | 
  |pt           |   Pay Tone                 |     |  BR          | 
    ---------------------------------------------------------------- 
 
  Note that default time-out values may be over-ridden by the Call 
  Agent for any Time-Out signal defined in this package by a "to" 
 
B. Foster, F. Andreasen      Informational                    [Page 32] 


                          Basic MGCP Packages             February 2003 

  signal parameter. Refer to section 2 of this document as well as [1] 
  for details. 
   
  The events in this package are defined as follows: 
   
  Conference Depart(cd): 
     Tone used to indicate that a participant has left a conference 
     call. The tone characteristics are left to the specific gateway 
     implementation.  
   
  Conference Join (cj): 
     Tone used to indicate that a party has joined a conference call. 
     The tone characteristics are left to the specific gateway 
     implementation.  
   
  Comfort Tone (cm):  
     Comfort Tone is used to indicate that the call is being processed 
     and that the caller should wait. Refer to E.182 [10]. 
   
  Caller Waiting Tone (cw):  
     Not to be confused with call-waiting tone this is a tone advising 
     a caller that a called station, though busy, has a call waiting 
     service active. Refer to E.182 [10]. 
   
  Tone on-hold (ht): 
     A tone used to reassure a calling subscriber who has been placed 
     on "hold". Refer to ITU-T E.182 [10]. 
   
  Negative Indication (ni): 
     A tone advising a subscriber that the request for service cannot 
     be accepted. Refer to E.182 [10]. For North America, this maps to 
     re-order tone (see GR-506-CORE [7], Section 17.2.7). 
   
  Number Unobtainable Tone (nu): 
     Refer to E.180, supplement 2 [9]. This is also referred to as 
     "vacant tone" and maps to "re-order tone" in North America (see 
     GR-506-CORE [7], Section 17.2.7). 
   
  Operation Complete (oc): 
     The standard definition of operation complete [1].      
   
  Operation Failure (of): 
     The standard definition of operation failure [1]. 
   
  Pay Phone Recognition (pr): 
     A tone advising an operator that the endpoint is identified as a 
     payphone. Refer to E.182 [10]. 
   
  Pay Tone (pt): 
     A tone indicating that payment is required. Refer to E.182 [10]. 
   

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


                          Basic MGCP Packages             February 2003 

2.7.  Digit Map Extension 
   
  Package Name: dm1  ("dm" followed by the number "1") 
  Version: 0 
  Extension Digit Map Letters: P 
   
  This package defines an Extension Digit Map Letter that is used to 
  override the shortest possible match behavior for a given entry in a 
  digit map (see [1]). The letter "P" (for partial match override) at 
  the end of a digit map entry instructs the gateway to only consider 
  that entry a match, if the current dial string does not partially 
  match another entry. For example, given the digit map 
   
    ([3-7]11|123xxxxxxx|[1-7]xxxxxxP|8xxxP) 
   
  and a current dial string of "1234567" we would not consider this a 
  match (as the rules in [1] would otherwise imply), however a current 
  dial string of "411" would be considered a match as usual. A current 
  dial string of "8234" would be considered a match, since there is no 
  other partial match.  
   
  Note that the digit map letter "P" is not an event, but simply a 
  syntactic and semantic digit map extension. Thus, the "P" is not 
  included in the list of requested or observed events.  
   
  Support for this package is strongly RECOMMENDED. 
   
2.8.  Signal List Package 
 
  Package Name: SL 
  Version: 0 
   
    --------------------------------------------------------- 
   | Symbol  |   Definition             |  R  | S   Duration | 
   |---------------------------------------------------------| 
   | oc      |  Operation Complete      |  x  |              | 
   | of      |  Operation Failure       |  x  |              | 
   | s(list) |  Signal List             |     | TO  variable | 
     --------------------------------------------------------- 
 
  Operation Complete (oc): 
     This is the standard definition of operation complete from [1]. 
   
  Operation Failure (of): 
     This is the standard definition of operation failure from [1]. 
   
  Signal List(s(<list>)): 
     The <list> contains a comma-separated list of signals to be played 
     out. Each of the signals in <list> MUST be either of type BR or 
     type TO. Semantically, the signal list is still treated as a 
     single parameterized signal of type Time-Out though. The signals 
     in the list are played to completion one after the other in the 
     left to right order specified. The package for each signal in the 

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


                          Basic MGCP Packages             February 2003 

     list must be specified. For example, to play out the DTMF digits 
     123456: 
      
          S: sl/s(d/1,d/2,d/3,d/4,d/5,d/6) 
      
     This will result in the DTMF digits 1, 2, 3, 4, 5 and 6 being 
     played out in order.  
      
     It is illegal to include an OO signal as one of the signals in the 
     list or to request recursive definitions (signal lists within 
     signal lists). If this or any other unsupported signal is 
     included, error code 538 (event/signal parameter error) MUST be 
     returned by the gateway. 
      
     Note that as the gateway plays the ordered list of signals, if it 
     encounters a TO signal with infinite timeout it will continue to 
     play that signal until the Signal List signal is stopped (i.e. 
     other signals later in the list will never be played). 
   
     If the operation complete ("oc") event is requested, it will be 
     detected once, when the last signal in the list has been played 
     out (regardless of whether there are any TO signals in the list). 
     The operation complete event will only report the signal list name 
     itself, i.e. without the parameters supplied as in: 
           
          O:   sl/oc(sl/s) 
      
     Should any of the signals in the signal list result in an error, 
     an operation failure event for the Signal List signal MUST be 
     generated. Only the signal list name will be included, thus it is 
     not possible to determine which of the signals in the signal list 
     actually failed.  
      
     Note that if an event occurs while the "SL/S" signal is playing, 
     the "SL/S" signal is stopped in the following manner: 
      
        * If the signal in the list that was playing at the time the 
           event occurred is of type BR, then the BR signal will be 
           played to completion and no other signals in the list will 
           be played. 
        * If the signal in the list that was playing at the time the 
           event occurred is of type TO, then the TO signal will stop 
           immediately and no other signals in the list will be played. 
   
   
2.9. Media Format Parameter Package 
 
  Package Name: FM 
  Version: 0 
 
  This package provides support for the media format parameter Local 
  Connection Option (LCO). The media format parameter LCO is similar to 
  the "fmtp" attribute in SDP [15] and is applicable to all of the same 
  media formats that the corresponding SDP fmtp attribute could be used 
 
B. Foster, F. Andreasen      Informational                    [Page 35] 


                          Basic MGCP Packages             February 2003 

  with (i.e. media format parameters for any media format MIME type). 
  The media format parameter is encoded as the keyword "fmtp" or "o-
  fmtp" followed by a colon and a quoted string beginning with the 
  media format name (MIME subtype only) followed by a space, followed 
  by the media format parameters associated with that media format. For 
  simplicity, we will use the terms "codec" and "media format" 
  interchangeably in the following. Multiple formats may be indicated 
  by either repeating the "fmtp" local connection option multiple times 
  such as: 
   
    L:a:codec1;codec2, fmtp:"codec1 formatX", fmtp:"codec2 formatY" 
   
  or alternatively by having a single "fmtp" keyword followed by a 
  colon, and a semi-colon separated list of quoted strings for each 
  media format parameter as in: 
   
    L:a:codec1;codec2, fmtp:"codec1 formatX";"codec2 formatY" 
   
  The two formats may be mixed.  
   
  If it is possible for the same codec to be requested with and without 
  the special "fmtp" format, the following could result: 
   
    L:a:codec1;codec1, fmtp:"codec1 formatX" 
   
  However it would not be clear if the fmtp parameter was to be applied 
  to the first or the second occurrence of the codec. The problem with 
  that is, that codec ordering is important (i.e. codecs are listed in 
  preferred order) and the above syntax does not provide a way to 
  indicate if "formatX" is preferred (i.e. associated with the first 
  "codec1") or not (i.e. associated with the second "codec1"). In order 
  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".  
   

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


                          Basic MGCP Packages             February 2003 

  When auditing capabilities, the "fmtp" local connection option MUST 
  be returned with a semi-colon separated list of supported formats 
  and/or multiple independent "fmtp" parameters as in: 
   
     A: a:telephone-event, fmtp:"telephone-event 0-15,32-35",... 
      
     A: a:PCMU;G729, fmtp:"PCMU foo";"PCMU bar", fmtp:"G729 foobar",... 
   
  One example use of the media format parameter LCO is in conjunction 
  with the media format "telephone-event" as defined in RFC 2833 [22]. 
  If the media format "telephone-event" is used without the "fmtp" 
  media format parameter, the DTMF digits (telephone events 0-15 from 
  RFC 2833) are assumed - such practice is however discouraged. On the 
  other hand, the media format parameter LCO MAY be used to specify the 
  exact set of events that are being requested via RFC 2833. Example: 
   
      L: a:PCMU;telephone-event,fmtp:"telephone-event 16" 
   
  indicates that if telephone events are supported at all, then this 
  request is specifically for event 16. 
   
  In another case, the Call Agent may indicate that some format 
  parameters are "required" while others are optional. In the example 
  below telephone events 0-15 are a "must" while telephone events 16, 
  70 and 71 are optional. 
   
       L: a:PCMU;telephone-event, o-fmtp:"telephone-event 16,70,71",  
       fmtp:"telephone-event 0-15" 
   
  If the gateway cannot support telephone events 0-15, it MUST NOT 
  include the "telephone-event" media format in the SDP in its 
  response. On the other hand, if it can support those telephone 
  events, it SHOULD indicate support for those events as well as any of 
  the events 16, 70 and 71 that it supports. 
   
  If a request is made to audit the capabilities of an endpoint and the 
  endpoint supports the "telephone event" media format with events "0-
  16", then the audit would include the following: 
   
      A: a:telephone-event, fmtp: "telephone-event 0-16" 
   
  Another example is the use of redundancy with RFC 2198 [21]. Again, 
  the format of the fmtp string is similar to that used in the SDP 
  except the medea format ("red" in this case) rather than the payload 
  type is used: 
   
     L: a:G729;pcmu;red,fmtp:"red pcmu/g729" 
   
  The corresponding media description in the SDP as part of the 
  connection request acknowledgment might look like: 
   
     m=audio 12345 RTP/AVP 98 18 0 
     a=rtpmap:98 red/8000/1 
     a=fmtp:98 0/18 
 
B. Foster, F. Andreasen      Informational                    [Page 37] 


                          Basic MGCP Packages             February 2003 

   
  If we combine both telephone events and redundancy, an example local 
  connection option might look as follows (carriage return added for 
  formatting reasons here): 
   
     L: a:G729;pcmu;red;telephone-event,fmtp:"red pcmu/g729",  
                                        fmtp: "telephone-event 16" 
   
  Note that we again specify the literal string for the encoding method 
  rather than it's payload type. This is a general principle that 
  should be used with this LocalConnectionOption.  
   
  The corresponding SDP might appear as follows: 
   
     m=audio 12345 RTP/AVP 97 98 18 0 
     a=rtpmap:97 red/8000/1 
     a=fmtp:97 0/18 
     a=rtpmap:98 telephone event 
     a=fmtp:98 16 
   
  Note that the fmtp LCO may be used in any situation where the 
  corresponding SDP attribute may be used. An example of a local 
  connection option that involves a media type other than audio and a 
  "foobar" fmtp parameter: 
   
     L: a:image/tiff, fmtp:"tiff foobar" 
   
  Note that normally local connection options that are associated with 
  a package should have the package prefix included as per the package 
  extension rules in [1]. The "fmtp" and "o-fmtp" LCO in the "FM" 
  package are an exception. The package prefix is not included in the 
  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. 
   

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


                          Basic MGCP Packages             February 2003 

2.10. RTP Package 
   
  Package Name: R 
  Version: 1 
   
   ------------------------------------------------------------- 
  | Symbol  |   Definition                 |   R |   S Duration | 
  |-------------------------------------------------------------| 
  | co1     |   Continuity Tone (single    |   C | TO,C 3 sec.  | 
  |         |     or return tone)          |     |              | 
  | co2     |   Continuity Test (go tone,  |   C | TO,C 3 sec.  | 
  |         |     in dual tone procedures) |     |              | 
  | iu(..)  |   ICMP Unreachable           |   C |              | 
  |         |     Received                 |     |              | 
  | ji(..)  |   Jitter Buffer Size Changed |   C |              | 
  | ma      |   Media Start                |   C |              | 
  | oc      |   Operation Complete         |   x |              | 
  | of      |   Operation Failure          |   x |              | 
  | pl(..)  |   Packet Loss Exceeded       |   C |              | 
  | qa      |   Quality Alert              |   C |              | 
  | rto(..) |   RTP/RTCP Timeout           |   C |              | 
  | sr      |   Sampling Rate Changed      |   C |              | 
  | uc      |   Used Codec Changed         |   C |              | 
   ------------------------------------------------------------- 
 
  Changes in event types: "co1" and "co2" signals changed from OO to 
  TO.  
   
  New events added to this package from the previously unversioned 
  package:  "iu", "rto", "ma". 
   
  Note that default time-out values may be over-ridden by the Call 
  Agent for any Time-Out signal defined in this package by a "to" 
  signal parameter. Refer to section 2 of this document as well as [1] 
  for details. 
   
  The events in this package all refer to media streams (connections), 
  i.e. they cannot be detected on an endpoint. Furthermore, with the 
  exception of the "iu" event, which is defined for any type of media, 
  all other events in this package are defined for RTP media streams 
  only (i.e. if they are used on connections that do not use RTP, the 
  behavior is not defined).  
   
  Signals requested (e.g. "co1" and "co2") must indicate the connection 
  ID (e.g. "S: r/co1@connectionID"). An event may be requested for all 
  existing connections using the "*" wildcard for the connectionID as 
  described in [1]. 
   
  Example: 
       R: r/uc@*    (request to detect uc on all connections) or 
   
       R: r/uc@connectionID   (request to detect uc only on a specific  
       connection) 
   
 
B. Foster, F. Andreasen      Informational                    [Page 39] 


                          Basic MGCP Packages             February 2003 

  An event detected on a connection will include the connectionID, 
  e.g.: 
   
        O: r/uc@connectionID(15) 
 
  Continuity tones (co1 and co2): 
     These are the same as the events defined in the Trunk package, 
     except in this case, they are only played over a network 
     connection and the connectionID MUST be supplied (e.g. "s: 
     r/co1@connectionID"). They can be used in conjunction with the 
     Network LoopBack (netwloop) or Network Continuity Test (netwtest) 
     modes to test the continuity of an RTP circuit. However, in the 
     case of testing IP continuity, a one-tone test is sufficient i.e. 
     generating and detecting "co1" at one end with connection mode in 
     network loopback mode at the other end. Note that the test can 
     also be done using telephone events rather than tones, i.e. event 
     167 in RFC 2833 corresponds to "co1". In this case, connection 
     requests are made with local connection options such as: 
   
            L: a:PCMU;telephone-event,fmtp:"telephone-event 167" 
        
     in order to request support for telephone event 167. If both ends 
     support the event, then the network loopback proceeds as usual 
     except that telephone events corresponding to the co1 tone are 
     sent rather than the co1 tone itself. 
        
  ICMP Unreachable Received (iu): 
     This event indicates that some number of ICMP unreachable packets 
     [19] was received for this connection since an RQNT was received 
     requesting this event. This notification indicates that packets 
     that were sent by the gateway on this connection either did not 
     arrive at their destination or were not accepted (e.g. the port 
     was closed). When this event is requested, a single parameter with 
     a decimal number from 1 to 255 may be included to indicate the 
     number of ICMP un-reachable packets that must occur before the 
     event is notified. If no parameter is supplied, with the request 
     then a default value of 3 is assumed. This is a one-shot event in 
     that once the event occurs, a further request is required in order 
     to re-initiate counting. 
        
     The observed event is parameterized with two parameters: 
        
       * The first parameter is the number of ICMP unreachable packets 
          received (i.e. the same value that was included in the 
          request - or the value 3, if the requested event was not 
          parameterized) 
       * The second parameter is the error code indicated in the ICMP 
          unreachable packet, e.g.: 
      
           0 = net unreachable; 
      
           1 = host unreachable; 
      
           2 = protocol unreachable; 
 
B. Foster, F. Andreasen      Informational                    [Page 40] 


                          Basic MGCP Packages             February 2003 

      
           3 = port unreachable; 
      
           4 = fragmentation needed and DF set; 
      
           5 = source route failed. 
            
           etc. 
          
     An example of a request might be as follows: 
      
        RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 
        X: 0123456789B0 
        R: r/iu@364823(N)(5) 
      
     In this case a notify will occur if 5 ICMP port unreachable 
     packets are received as a result of RTP and/or RTCP packets being 
     sent from this gateway on the connection with connection ID 
     364823. 
      
     The resulting NTFY with observed events might be as follows: 
      
        NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 
        X: 0123456789B0 
        O: r/iu@364823(5,3) 
         
     The first parameter indicates 5 ICMP unreachable packets were 
     received since the RQNT with this request was sent. The second 
     parameter ("3") specifies the reason, which in this case is "port 
     unreachable". 
   
  Jitter Buffer Size Changed (ji): 
     This event is only included here to maintain compatibility with 
     the previous version of this package. This event is used to 
     indicate that the gateway has made an adjustment to the depth of 
     the jitter buffer. The syntax for requesting notification is "ji", 
     which tells the media gateway that the controller wants 
     notification of any jitter buffer size changes. The syntax for 
     notification from the media gateway to the controller is 
     "JI(####)", where the #### is a decimal number from 1 to 65536 
     indicating the new size of the jitter buffer, in milliseconds. 
   
  Media Start (ma): 
     The media start event occurs on a connection when the first valid 
     RTP media packet is received on the connection. This event can be 
     used to synchronize a local signal, e.g. ringback, with the 
     arrival of media from the other party. 
   
     The event is detected on a connection. If no connection is 
     specified, the event applies to all connections for the endpoint, 
     regardless of when the connections are created (i.e. if a 
     connection is not specified, the event will occur when the first 

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


                          Basic MGCP Packages             February 2003 

     valid RTP packet arrives on any one of the connections on that 
     endpoint). 
   
  Operation complete (oc): 
     This is the standard definition of operation complete [1]. 
   
  Operation failure (of): 
     This is the standard definition of operation failure [1].  
      
  Packet Loss Exceeded (pl): 
     Packet loss rate exceeds the threshold of the specified decimal 
     number (with a range of 1 to 100,000) of packets per 100,000 
     packets, where the packet loss number is indicated in parenthesis. 
     For example, PL(10) is a drop rate of 10 in 100,000 packets. This 
     event is requested with a parameter indicating what packet loss 
     rate the Call Agent wishes to be reported. If the packet loss 
     exceeds that value, the event is reported with that same 
     parameter. The event is only reported once when the packet loss 
     threshold is exceeded. Once reported, a following request will re-
     initiate packet loss measurements and report when the threshold is 
     exceeded again.  
   
  Quality alert (qa): 
     The packet loss rate or the combination of delay and jitter 
     exceeded a quality threshold. The quality thresholds for delay, 
     jitter and packet loss rate are provisioned values. 
 
  RTP/RTCP Timeout (rto(<timeout>,st=<start-time>)): 
     This event indicates that neither RTP nor RTCP packets have been 
     received on this connection for a period of time equal to the 
     <timeout> value (in seconds). The timeout value can be supplied as 
     a decimal number from 1 to 65535 in the parameter when the request 
     is made. The <timeout> parameter will be supplied in 
     ObservedEvents when the event is reported - it then simply repeats 
     the value used. If an RTP or RTCP packet is received before the 
     timer expires, then the timer is reset and re-started. The event 
     will only be generated if the timer expires without an RTP or RTCP 
     packet arriving on the specified connection during the specified 
     period of time. Note that if the event is requested without the 
     <timeout> parameter then a default timeout of 60 seconds is 
     assumed. The <timeout> value will still be reported in 
     ObservedEvents even if no timeout value was indicated in the 
     request (the default value will be indicated in that case). This 
     is a one-shot event in that once the event occurs, a further 
     request is required in order to re-initialize the timer. 
      
     Another optional <start-time> parameter may also be included. This 
     is used to indicate when the timer starts. It can have one of the 
     following values: 
        
          * "im" for immediate i.e. the timer starts as soon as the 
            request is received. This is the default. 
          * "ra" to indicate that the timer should start only after an 
            RTCP packet has been received from the other end (i.e. the 
 
B. Foster, F. Andreasen      Informational                    [Page 42] 


                          Basic MGCP Packages             February 2003 

            timer will be initiated when the first RTCP packet is 
            received after the request is made). Note that in the case 
            where the other end does not support RTCP, the timer will 
            never be initiated. 
        
     Note that either the <timeout> or <start-time> may be included in 
     the request, but only the <timeout> value is included in the 
     report. 
      
     An example of a request might be as follows: 
      
        RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 
        X: 0123456789B0 
        R: r/rto@364823(N)(120,st=im) 
      
     In this case a notify will occur if there is a period of time when 
     no RTP or RTCP packets have been received on connection 364823 for 
     120 seconds. 
      
     The resulting NTFY with observed events would be as follows: 
      
        NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 
        X: 0123456789B0 
        O: r/rto@364823(120) 
   
  Sampling Rate Changed (sr): 
     This event is only included here to maintain compatibility with 
     the previous version of this package. This event indicates that 
     the packetization period changed to some decimal number in 
     milliseconds enclosed in parenthesis, as in SR(20). 
 
  Used Codec Changed (uc): 
     This event is only included here to maintain compatibility with 
     the previous version of this package. This event is requested 
     without a parameter but when reported, the hexadecimal payload 
     type is enclosed in parenthesis, as in UC(8), to indicate the 
     codec was changed to PCM A-law. Codec Numbers are specified in RFC 
     1890, or in a new definition of the audio profiles for RTP that 
     replaces this RFC.  
      

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


                          Basic MGCP Packages             February 2003 

2.11.  Resource Reservation Package 
 
  Package Name: RES 
  Version: 0 
   
2.11.1. Description 
 
  The "RES" package provides local connection option support for 
  resource reservations as well as an event to indicate reservation 
  loss. 
   
  A number of LocalConnectionOption parameters are used in doing 
  resource reservations: "reservation request", "reservation 
  direction", "reservation confirmation" and "resource sharing". 
   
  Reservation Request LocalConnectionOption: The gateways can be 
  instructed to perform a reservation on a given connection using RSVP. 
  When a reservation is needed, the Call Agent will specify the 
  reservation profile that should be used, which is either "controlled 
  load" or "guaranteed service". The absence of reservation can be 
  indicated by asking for the "best effort" service, which is the 
  default value for this parameter.  
   
  Whether or not RSVP will be done is dependent on whether the 
  reservation request LocalConnectionOption parameter has been included 
  in a connection request for this connection (with either "controlled 
  load" or "guaranteed service" indicated). If a modify connection 
  (MDCX) request requires a change in the reservation and the 
  "reservation request" parameter is not included in the 
  LocalConnectionOptions but was included in the LocalConnectionOptions 
  for a previous connection request for that connection, then 
  "reservation request" value defaults to its previously saved value 
  for that connection. If a modify connection (MDCX) request explicitly 
  contains a "reservation request", indicating a request for "best 
  effort" for a connection that has an existing reservation, the 
  existing reservation will be torn down. 
   
  Reservation Direction LocalConnectionOption: 
     When reservation has been requested on a connection, the gateway 
     will examine the reservation direction LocalConnectionOption 
     parameter to determine the direction that reservations are 
     required and do the following: 
       
        * Start emitting RSVP "PATH" messages if the reservation 
           direction LocalConnectionOptions parameter specified "send-
           only" or "send-receive". 
       
        * Start emitting RSVP "RESV" messages as soon as it receives 
           "PATH" messages if the reservation direction parameter 
           specified "receive-only" or "send-receive".  
       
     If an RSVP reservation is requested but the reservation direction 
     LocalConnectionOption parameter is missing, the reservation 
     direction defaults to the previously saved value of the 
 
B. Foster, F. Andreasen      Informational                    [Page 44] 


                          Basic MGCP Packages             February 2003 

     reservation direction parameter for that connection. If there was 
     no previous reservation direction parameter for that connection, 
     the value is deduced from the connection mode. That is: 
       
        * Start emitting RSVP "PATH" messages if the connection is in 
           "send-only", "send-receive", "conference", "network loop 
           back" or "network continuity test" mode (if a remote 
           connection descriptor has been received,) 
    
        * Start emitting RSVP "RESV" messages as soon as it receives 
           "PATH"  messages if the connection is in "receive-only", 
           "send-receive",  "conference", "network loop back" or 
           "network continuity test" mode. 
    
  Reservation Confirmation LocalConnectionOption: 
     Another LocalConnectionOption parameter for RSVP reservations is 
     the reservation confirmation parameter, which determines what the 
     resource reservation pre-condition (see [1]) is for acknowledging 
     a successful connection request: 
      
     * If the reservation confirmation parameter is set to "none", the 
       gateway will "Ack" the connection request without waiting for 
       reservation completion. This is the default behavior. 
        
     * If the "reservation confirmation" parameter is set to "send-
       only", the gateway will "Ack" when the PATH message has been 
       sent and the corresponding RESV is received to indicate 
       successful reservation in the send direction. 
        
     * If the "reservation confirmation" parameter is set to "receive-
       only", the gateway will "Ack" when reservation confirm for a 
       reservation has been received. 
        
     * If the reservation confirmation parameter is set to "send-
       receive", the gateway will "Ack" only after the PATH message has 
       been sent and the corresponding RESV has been received for send 
       direction, and reservation confirm has been received for the 
       receive direction. 
      
  Note that: 
        
     Values "receive-only" and "send-receive" are triggers for the 
     gateway to request reservation confirm (RESVCONF) when it sends 
     out the RESV. 
      
     Pre-conditions SHOULD only be added for the direction(s) for which 
     resource reservations have been requested. If a direction is added 
     as a precondition and that direction was not requested in the 
     resource reservation, the direction MUST simply be ignored as a 
     pre-condition. 
      
     In this approach, resource reservation success is the pre-
     condition to final acknowledgement of the connection request. If 
     the reservation fails, the connection request also fails (error 
 
B. Foster, F. Andreasen      Informational                    [Page 45] 


                          Basic MGCP Packages             February 2003 

     code 404 - insufficient bandwidth) - as will any other part of the 
     transaction, e.g. a notification request included as part of the 
     connection request. A typical example of this would be a request 
     to ring the phone and look for off-hook, included with the 
     connection request. If the reservation fails, the phone will not 
     ring. Similarly, if the phone is already off-hook, the command 
     fails and there will be no resource reservation. 
      
     A provisional response SHOULD be provided if confirmation is 
     expected to occur outside the normal retry timers and in fact a 
     provisional response MUST be provided regardless if reservation 
     confirmation parameter has value "send-receive" (without a 
     provisional response, SDP information cannot be returned until the 
     final "Ack" which will not occur until the reservation is 
     complete. This can result in a deadlock since the SDP information 
     typically needs to be passed to the other end in order for it to 
     initiate the RSVP PATH message in the other direction). The SDP 
     information and connectionID MUST be included in both the 
     provisional response and the final response. Note that in order to 
     ensure rapid detection of a lost final response, final responses 
     issued after provisional responses for a transaction SHALL be 
     acknowledged, i.e., they SHALL include an empty "ResponseAck" 
     parameter in the final response (see [1]). 
      
     If the transaction time is outside the expected bounds (time T-
     HIST - see the section on provisional responses in [1]), error 
     code 406 (transaction timeout) SHOULD be returned. 
      
     Also note that if the reservation confirmation parameter is 
     omitted, the value of the reservation confirmation parameter 
     defaults to its previously-saved value. If there is no previously 
     saved value for the reservation confirmation parameter or the 
     reservation confirmation parameter has the value "none", then 
     successful resource reservation is not a pre-condition to 
     providing an acknowledgement to the connection request (i.e. the 
     gateway can "Ack" right away without waiting for the reservation 
     to complete and a provisional response will not be necessary). 
      
  Resource Sharing LocalConnectionOption: 
     It may be possible to share network resources across multiple 
     connections. An example is a call-waiting scenario, where only one 
     connection will ever be active at a time. In a 3-way calling 
     scenario with a similar set of connections, sharing is not 
     possible. Only the Call Agent knows what may be possible, 
     depending on the feature that is being invoked. 
      
     In order to allow the Call Agent to indicate that sharing is 
     possible, a resource sharing LocalConnectionOption parameter is 
     introduced. This parameter can have one of the following values: 
        
        * A value "$" can be specified where $ refers to "this 
           connection". This value is used when doing a create 
           connection and indicates the intent to share resources with 
           this connection. This is an indication to the gateway to use 
 
B. Foster, F. Andreasen      Informational                    [Page 46] 


                          Basic MGCP Packages             February 2003 

           the "Shared Explicit" style of reservation as defined in RFC 
           2205. 
        
        * A connection ID can be specified which indicates that this 
           is a request to share resources with the connection having 
           this connection ID (allowing multiple connections to share 
           resources with the connection indicated)  
        
        * The value can be empty, which indicates a request to no 
           longer share the resources of this connection with other 
           connections 
      
     In the case of a CRCX the default value for the resource sharing 
     local connection option is empty and for an MDCX the default value 
     is its current value. 
   
  The RSVP filters will be deduced from the characteristics of the 
  connection. The RSVP resource profiles will be deduced from the 
  connection's bandwidth and packetization period. 
   
  Note that if RSVP is used with PacketCable Dynamic Quality of Service 
  [24], then the parameters in NCS [25] 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 
 
B. Foster, F. Andreasen      Informational                    [Page 47] 


                          Basic MGCP Packages             February 2003 

      
      * An empty value (i.e. "r-sh:" with no value indicated), 
        indicating a request to no longer share the resources of this 
        connection with other connections 
   
  Note that normally local connection options that are associated with 
  a package have the package prefix included as per the package 
  extension rules in [1]. The local connection options in the "RES" 
  package are exceptions. The package prefix is not included in the 
  case of the "RES" package because it was created before the extension 
  rules in [1] were defined. 
   
2.11.3 Events 
 
  The following events are included as part of the resource reservation 
  package: 
 
    ------------------------------------------------------ 
   | Symbol  | Definition           |   R |   S  Duration | 
   |------------------------------------------------------| 
   |  re     | Resource Error       |   C |               | 
   |  rl     | Resource Lost        |   C |               | 
    ------------------------------------------------------ 
 
  Resource Error (re): 
    This is an indication that an error in the resource reservation 
    occurred during the life of the connection. This event is not 
    requested with a parameter but is reported with a parameter (see 
    possible values below). This event may or may not indicate the 
    permanent loss of the reservation (i.e. any error associated with 
    the reservation whether permanent or temporary will be reported). 
    If requested on an endpoint (without specifying the connection ID), 
    the request refers to all present and future connections on that 
    endpoint. When reported, the connectionID is always supplied along 
    with a reason for the error indicated as a parameter. One of the 
    following possible reasons for loss MUST be included as the 
    parameter when the event is reported: 
   
    - "resverr" is used to indicate that a ResvErr message was 
       received 
    - "patherr" is used to indicate that a PathErr message was 
       received. 
    - "other" 
   
    In addition to a parameter indicating one of the reasons above, 
    additional information on the type of error MAY be included as a 
    second parameter in the form of a quoted string. 
     
    Example report might include: 
     
       O: res/rl@0A3F58(resverr) 
     
    or 
     
 
B. Foster, F. Andreasen      Informational                    [Page 48] 


                          Basic MGCP Packages             February 2003 

       O: res/rl@0A3F58(resverr, "some additional commentary") 
     
    Note that this event will not be reported if an error occurs while 
    a resource reservation is initially being set up (i.e. the event 
    only reported as a result of an error that occurred after the 
    reservation was set up). 
     
  Resource Lost (rl): 
     Loss of reservation during the life of a connection can be 
     reported by using the "rl" event. This event is not requested with 
     a parameter but is reported with a parameter (see below for 
     possible values). If requested on an endpoint (without specifying 
     the connection ID), the request refers to all present and future 
     connections on that endpoint.  
      
     When reported, the connectionID is always supplied along with a 
     reason for the loss indicated as a parameter. One of the following 
     possible reasons for loss MUST be supplied as the parameter when 
     the event is reported: 
      
       - "resvtear" indicating that the reservation loss was indicated 
         by ResvTear message 
       - "pathtear" indicating that the reservation loss was indicated 
         by PathTear message 
       - "other" 
      
     In addition to a parameter indicating one of the reasons above, 
     additional information on the type of error MAY be included as a 
     second parameter in the form of a quoted string. 
      
     Example report might include: 
      
       O: res/rl@0A3F58(ResvTear) 
      
     or 
      
       O: res/rl@0A3F58(ResvTear, "some other commentary") 
      
     Note that this event will not be reported if an error occurs while 
     a resource reservation is initially being set up (i.e. the event 
     is only reported if the reservation was lost after it was 
     initially set up). 
   
 

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


                          Basic MGCP Packages             February 2003 

2.12.  Announcement Server Package 
   
  Package Name: A 
  Version: 1 
   
   --------------------------------------------------------------- 
  | Symbol         | Definition           |   R |  S     Duration | 
  |---------------------------------------------------------------| 
  | ann(url)       | Play an Announcement |     |  TO, C variable | 
  | oc             | Operation Complete   |   x |                 | 
  | of             | Operation Failure    |   x |                 | 
   --------------------------------------------------------------- 
 
  Changes from the previous version: change to conform to standard 
  reporting of operation failure and operation complete events. 
   
  The announcement signal is qualified by a URL name: 
 
      S: ann(http://scripts.example.net/all-lines-busy.au) 
 
  The URL name MAY be followed by a list of initial parameters, 
  separated by commas. However, standard parameters are not included as 
  part of this package definition (Note: use of additional parameters 
  is optional and would result in a proprietary interface). 
   
  The gateway SHOULD support one or more standard URL schemes such as: 
   
        * file, http, ftp (RFC 1738), which indicate where the audio 
           file is located (where to load the file from before playing 
           the audio file on the gateway). 
   
        * RTSP URL (section 3.2 of RFC 2326), which in this case 
           allows the media gateway to directly initiate playing of the 
           announcement via an RTSP server. 
   
  The pre-condition for a successful response (return code of "200") is 
  correct syntax and capability (support is available for this 
  request). Standard MGCP return codes apply in the case of failure. 
  Further indications of failure are provided in the operation failure 
  event as a comment after the name of the failed event in the form of 
  a quoted string. 
   
  If the announcement cannot be played out for a reason determined 
  after a successful response to the request has been provided, an 
  operation failure event will be returned. The failure MAY be 
  explained by some commentary (in the form of a quoted string), as in: 
 
     O: a/of(a/ann,"file not found") 
   
  The "operation complete" event will be detected when the announcement 
  is played out. 
   
    O: a/oc(a/ann) 
 
 
B. Foster, F. Andreasen      Informational                    [Page 50] 


                          Basic MGCP Packages             February 2003 

2.13.  Script Package 
 
  Package Name: Script 
  Version: 1 
 
   ----------------------------------------------------------------- 
  | Symbol       |   Definition              | R |  S  |   Duration | 
  |-----------------------------------------------------------------| 
  | ir(..)        | Intermediate Results/Req.| x |  BR |            | 
  | java(url,...) | Load & Run java script   |   |  TO |   variable | 
  | oc            | operation complete       | x |     |            | 
  | of            | operation failure        | x |     |            | 
  | perl(url,...) | Load & Run perl script   |   |  TO |   variable | 
  | tcl(url,...)  | Load & Run TCL script    |   |  TO |   variable | 
  | vxml(url,...) | Load & Run VXML doc.     |   |  TO |   variable | 
  | xml(url,...)  | Load & Run XML script    |   |  TO |   variable | 
   ----------------------------------------------------------------- 
 
  Changes from the previous version of the package: "vxml" was added as 
  a language type for loading and running VXML documents; change to 
  conform with standard reporting of operation failure and operation 
  complete events; addition of "ir" event. 
   
  The current definition defines keywords for the most common 
  languages. More languages may be defined in later versions of this 
  package. 
   
  The "signal" specifying the scripting language is parameterized with 
  a URL indicating the location of the script. The URL parameter MAY be 
  optionally followed by a comma-separated list of arguments as initial 
  parameters to use in running the script. URL schemes may include file 
  ftp, or http schemes with syntax according to RFC 2396. As an 
  example: 
 
     S: script/vxml(ftp://ftp.example.net/credit-card.vxml,arg1,arg2,  
                                                             ...,argn) 
 
  The argument list "arg1,arg2,...,argn" is passed to the 
  script/document as a list of initial parameters. 
   
  The pre-condition for a successful response (return code of "200") is 
  correct syntax and capability (support is available for this 
  request). Standard MGCP return codes apply in the case of failure. 
  Some further (non-application/script specific) failure indications 
  MAY be provided in the operation failure event as a comment in the 
  form of a quoted string.following the name of the failed event. 
   
  Example 
 
     O: script/of(script/vxml,"file not found") 
      
  The script produces an output, which consists of one or several text 
  strings, separated by commas. This provides the return-status of the 
  script as well as return parameters (if there are any). 
 
B. Foster, F. Andreasen      Informational                    [Page 51] 


                          Basic MGCP Packages             February 2003 

 
     O: script/oc(script/vxml,return-status=<status>,  
                       name1=value1,name2=value2,...) 
 
  where <status> can have one of the values "success" or "failure". 
  This is then followed by output parameters as a comma-separated list 
  of name-value pairs. 
   
  Intermediate Result/Request (ir(<params>)): 
     This provides a way for: 
       * The script to inform the Call Agent of intermediate results 
          (e.g. a case where it is important because of timing concerns 
          to inform the Call Agent prior to operation complete). 
       * The script to request some information from the Call Agent. 
       * The Call Agent to inform the script of some event or 
          information that may be important for the operation of the 
          script (in this case "ir" is used as a signal). 
   
     Parameters (i.e. <params>) SHOULD be a comma-separated list of 
     name-value pairs e.g. ir(name1=value1,name2=value2,..). The Call 
     Agent MAY include event parameters when it requests this event, in 
     which case, the MGCP syntax requirements require that the action 
     be specified (e.g. "R: ir(N)(nam1=value1,name2=value2,..)"). 
      
     If the Call Agent requests "ir" as a signal, at least one 
     parameter MUST be provided. 
      
     When requesting the "ir" signal, the Call Agent MUST also repeat 
     the original script signal. This is in order to be consistent with 
     the semantics of TO signals in MGCP (i.e. if the original "script" 
     signal is not included, then the signal/script will be stopped). 
     The only problem with this is that there is a possible race 
     condition in which a request to send an "ir" signal could occur 
     just as the script stopped. In order to avoid this confusion, the 
     following is RECOMMENDED: when the script signal is included with 
     an "ir" signal, include a parameter (of the script signal) to 
     indicate that this is not a new instance of the script i.e. if 
     there is no script executing at the present time don't start 
     executing a new one. 
      
     The "ir" signal is only associated with an executing script, if 
     none is running when a request for the event/signal is made or if 
     a new script request is not included with the request, then the 
     "ir" signal/event will not be executed (i.e. the "ir" event with 
     its parameters is passed to an existing script for parsing and 
     execution and is considered opaque as far as MGCP as concerned. If 
     no such script exists, response code "800" will be returned, 
     indicating that the script is not executing). 
   
  The following response code is associated with this package: 
   
     Code    Text                 Explanation  
                                    
     800     Script not           Request for "ir" signal or event 
 
B. Foster, F. Andreasen      Informational                    [Page 52] 


                          Basic MGCP Packages             February 2003 

             Executing            but no script is executing at the 
                                  time the request was received. 
   
  Note that package specific error codes include the package name 
  following the error code. For example, if error code 800 occurs in 
  response to a request with a transaction ID of 1001 it would be sent 
  as: 
   
     800 1001 /SCRIPT 
   
   
3.0. IANA Considerations 
 
  The following packages and their versions should be registered with 
  IANA as per the instructions in [1]. 
   
  Package Title         Name     Version  
  -------------         ----     -------    
  Announcement           A        1 
  DTMF                   D        1 
  Digit Map Extension    DM1      0 
  Media Format           FM       0 
  Generic                G        1 
  Handset                H        1 
  Line                   L        1 
  RTP                    R        1 
  Resource Reservation   RES      0 
  Script                 SCRIPT   1 
  Supplementary Tones    SST      0 
  Signal List            SL       0 
  Trunk                  T        1 
   
  The following extension digit map letter should be registered with 
  IANA: 
   
  Package Letter 
  ------- ------ 
    DM1     P 
   
  The following Local Connections should be registered with IANA: 
   
  Field                       Name 
  -------                     ----- 
  Media Format                fmtp 
  Reservation Confirmation    r-cnf 
  Reservation Direction       r-dir 
  Resource Sharing            r-sh 
      
4.0. Security Considerations 
   
  The MGCP packages contained in this document do not require any 
  further security considerations beyond those indicated in the base 
  MGCP specification [1]. 
   
 
B. Foster, F. Andreasen      Informational                    [Page 53] 


                          Basic MGCP Packages             February 2003 

5.0. Acknowledgements 
   
  Special thanks are due to the authors of the original MGCP 1.0 
  specification: Mauricio Arango, Andrew Dugan, Isaac Elliott, 
  Christian Huitema, and Scott Picket. 
   
  Thanks also to the reviewers of this document, including but not 
  limited to: Jerry Kamitses, Sonus Networks; Dave Auerbach, Dan Wing, 
  Cisco Systems; Ed Guy, EMC Software; Martin Wakley, Nortel Networks. 
   
6.0. Normative References 
   
  [1]  F. Andreasen, B. Foster, "Media Gateway Control Protocol (MGCP) 
       Version 1.0", RFC 3435, January 2003 
        
  [2]  Bellcore, "LSSGR: Switching System Generic Requirements for Call 
       Control Using the Integrated Services Digital Network User Part 
       (ISDNUP)", GR-317-CORE, Issue 2, December 1997. 
   
  [3]  ITU-T, "Telephone User Part Signaling Procedures", ITU-T Q.724, 
       November 1988 
   
  [4]  ANSI, "OAM&P - Terminating Test Line Access and Capabilities", 
       T1.207-2000. 
   
  [5]  Bellcore, "Notes on the Network", Special Report SR-2275, Issue 
       3, December 1997. 
   
  [6]  Bellcore, "Call Processing" GR-505-CORE, Issue 1, December 1997. 
   
  [7]  Bellcore, "LSSGR: Signaling for Analog Interfaces", GR-506-CORE, 
       Issue 1, June 1996. 
   
  [8]  ITU-T, "Technical Characteristics of Tones for the Telephone 
       Service", ITU-T E.180, March 1998 
   
  [9]  ITU-T, "Various Tones Used in National Networks", ITU-T E.180, 
       Supplement 2, January 1994 
   
  [10] ITU-T, "Applications of Tones and Recorded Announcements in 
       Telephone Services", ITU-T, E.182, March 1998 
   
  [11] Bellcore, "Call Forwarding Sub-Features FSD-01-02-1450, GR-586, 
       Issue 1, June 2000. 
        
  [12] Bellcore, "CPE Compatibility Considerations for the Voiceband 
       Data Transmission Interface", SR-TSV-002476, December 1992 
   
 
B. Foster, F. Andreasen      Informational                    [Page 54] 


                          Basic MGCP Packages             February 2003 

  [13] Bellcore, "LSSGR: Visual Message Waiting Indicator Generic 
       Requirements (FSD 01-02-2000)", GR-1401, Issue 01, June 2000 
   
  [14] Bellcore, "LSSGR Voiceband Data Transmission Interface", Section 
       6.6, GR-30, Issue 02, December 1998 
   
  [15] Handley, M., Jacobson, V., SDP: Session Description Protocol, 
       RFC 2327, April 1998. 
   
  [16] Bellcore, "LSSGR: Call Waiting, FSD 01-02-1201", GR-571, Issue 
       01, June 2000 
   
  [17] Bellcore, "LSSGR: Verification Connections FSD 25-05-0903", GR-
       531-CORE, Issue 1, June 2000. 
   
  [18] Bellcore, " LSSGR: CLASS Feature: Calling Identity Delivery on 
       Call Waiting, FSD 01-02-1090, GR-575, Issue 01, June 2000 
   
  [19] J. Postel, "Internet Control Message Protocol", RFC 792, 
       September 1981. 
        
  [20] Bellcore, "Class Feature: Screen Editing (FSD 30-28-0000)", GR-
       220, Issue 2, April 2002 
 
7.0. Informative References 
   
  [21] C. Perkins et al, RTP Payload for Redundant Audio Data, RFC 
       2198, September 1997. 
   
  [22] H. Schulzrinne, S. Petrack, "RTP Payload for DTMF Digits, 
       Telephony Tones and Telephony Signals", RFC 2833, May 2000. 
   
  [23] B. Foster, MGCP CAS Packages, RFC 3064, February 2001. 
   
  [24] PacketCableTM, Dynamic Quality if Service Specification, 
       http://www.packetcable.com/specifications.html 
   
  [25] PacketCableTM Network-Based Call Signaling Protocol 
       Specification, http://www.packetcable.com/specifications.html 
        
8.0. Authors' Addresses 
 
  Bill Foster 
  Cisco Systems 
  Phone: +1 250 758 9418 
  EMail: bfoster@cisco.com 
   

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


                          Basic MGCP Packages             February 2003 

  Flemming Andreasen 
  Cisco Systems  
  Edison, NJ 08837  
  EMail: fandreas@cisco.com 
   

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


                          Basic MGCP Packages             February 2003 

9.0. Full Copyright Statement 
 
  Copyright (C) The Internet Society (2002).  All Rights Reserved. 
   
  This document and translations of it may be copied and furnished to 
  others, and derivative works that comment on or otherwise explain it 
  or assist in its implementation may be prepared, copied, published 
  and distributed, in whole or in part, without restriction of any 
  kind, provided that the above copyright notice and this paragraph are 
  included on all such copies and derivative works.  However, this 
  document itself may not be modified in any way, such as by removing 
  the copyright notice or references to the Internet Society or other 
  Internet organizations, except as needed for the purpose of 
  developing Internet standards in which case the procedures for 
  copyrights defined in the Internet Standards process must be 
  followed, or as required to translate it into languages other than 
  English. 
   
  The limited permissions granted above are perpetual and will not be 
  revoked by the Internet Society or its successors or assigns. 
   
  This document and the information contained herein is provided on an 
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
   
Acknowledgement 
   
  Funding for the RFC Editor function is currently provided by the 
  Internet Society. 

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