Internet Engineering Task Force M. Arango Internet Draft SUN Microsystems Document: A. Dugan Category: Informational I. Elliott Expires: February 2002 Level3 Communications C. Huitema Microsoft S. Pickett Vertical Networks B. Foster F. Andreasen R. Kumar Cisco Systems August 2001 Basic MGCP Packages Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides a basic set of MGCP packages. The generic, line, trunk, handset, RTP, DTMF, announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages have been added. These are the signal lists, resource reservation, media format, supplementary services tones and digit map extension packages. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Arango et al. Informational [Page 1] Basic MGCP Packages August 2001 1. Introduction 1.1. List of Packages This document provides a basic set of packages for MGCP. Included are the following packages: ------------------------------------------- | Package | name | |-------------------------------------------| | Generic Media Package | G | | DTMF package | D | | Trunk Package | T | | Line Package | L | | Handset Package | H | | Supplementary Services Package | SST | | Digit Map Extension | DM1 | | Signal List Package | SL | | Media Format Package | FM | | RTP Package | R | | Resource Reservation Package | RES | | Announcement Server Package | A | | Script Package | Script | ------------------------------------------- 1.2. Changes to Existing Packages 1.2.1. Change in signal types MGCP 1.0 as defined in RFC 2705 provided some additional clarification on the meaning of OO signals compared to earlier versions of MGCP. This leads to some inconsistency in some of the signal definitions in the accompanying packages. This has been corrected in the packages that are included here by changing some of the signals from type OO to type TO. 1.2.2. Operation Complete and Operation Failure Another change also made to improve consistency and interoperability was to add the "operation complete" and "operation failure" events in packages where there are TO events defined but where the events were not included as part of the package. By definition, all packages that contain Time-Out type signals now contain the operation failure ("of") and operation complete ("oc") events as defined in [1], irrespective of whether they are provided as part of the package description or not. If a package without Time-Out signals does contain definitions for the "oc" and "of" events, the event definitions provided in the package may over-ride those indicated here. Such practice is however discouraged and is purely allowed to avoid potential backwards compatibility problems. Arango et al. Informational [Page 2] Basic MGCP Packages August 2001 It is considered good practice to explicitly mention that these two events are supported in accordance with their default definitions. If no definition is included in the package, the above syntax and semantics is assumed. Please refer to [1] for additional details on these events. 1.2.3. Package Versions Some of the packages included in this document are new versions of packages that were previously contained in RFC 2705. The base specification [1] provides an optional capability of auditing package versions. Any gateway that implements versioned packages SHOULD also implement this option. 1.2.4. Event Definitions, Aliases and Interoperability Issues Some event definitions or clarifications of previous event definitions have also been added in order to improve interoperability. In some cases events have aliases either in the same or in other packages and a recommendation has been made for the use of alternates by Call Agents for future implementations. For maximum interoperability gateways must still implement these events (in fact they must implement all of the events, signals, etc. in a package). Some events that were previously defined require specific provisioning in both the gateway and the Call Agent in order to allow for interoperability. In those cases, a warning to that affect has been included. 1.2.5. New Events In some cases new events have been added to existing packages. Any changes to existing packages of course have resulted in the version number being updated from unversioned (version 0) to version 1. 1.3. New Packages and Excluded Packages Two packages from RFC 2705 have not been included. These are the "MF" and the "NAS" package. These packages are still valid as are all unversioned (version 0) packages defined in RFC 2705. The reason these packages were not included: * The original MF package had no defined way to outpulse MF digits - so that a separate RFC was developed for MF CAS (RFC 3064). * The "N" package as defined in RFC 2705 was incomplete. A more complete MGCP "NAS" package has been developed and provided as a separate Internet draft. New packages have also been included beyond what was included in the original RFC 2705. The Resource Reservation ("RES") and Media Format ("FM") packages in particular are different from other packages in Arango et al. Informational [Page 3] Basic MGCP Packages August 2001 this document in that they do not contain events and signals but simply define extra LocalConnectionOptions. This is allowed by the new extension rules in [1]. Future packages of this type should use a packages prefix in front of local connection options ("/") so as to avoid name-space problems. However because of the timing of the arrival of these packages relative to updating MGCP 1.0 this was not done for the "RES" and "FM" packages. The resulting new local connection options will be registered with IANA. For future cases where a package prefix is included, only the package name needs to be registered. 2. Packages For those packages that involve MGCP events, the terms "signal" and "event" are used to differentiate a request from a Call Agent to a Media Gateway to apply an event ("signal"), from requesting the detection of an "event" that occurs on the Media Gateway and is "Notified" to the Call Agent. For packages that involve events and signals the tables contain five columns: Symbol: the (package) unique symbol used to identify the event. Definition: a short description of the event. R: an x appears in this column if the event can be requested by the Call Agent. Alternatively, one or more of the following symbols may appear. An "S" is included if the event-state may be audited. A "C" indicates that the event can be detected on a connection, and a "P" indicates the event is persistent. S: if nothing appears in this column for an event, then the event cannot be signaled by the Call Agent. Otherwise, the following symbols identify the type of event: * OO On/Off signal. * TO Time-Out signal. * BR Brief signal. In addition, a "C" will be included if the signal can be generated on a connection. Duration: specifies the duration of TO signals. If a duration is left unspecified then the default timeout will be assumed to be infinite unless explicitly noted in the description of the signal. A duration may also be declared as being variable in a case where signals involve complex sequencing (e.g. scripts or digit out-pulsing) where the amount of time may vary with either processing time or the signaling environment. Arango et al. Informational [Page 4] Basic MGCP Packages August 2001 Default time-out values may be over-ridden by the Call Agent for any Time-Out event defined in this document by a "to" signal parameter which specifies the timeout value in milliseconds (see [1]). Example: S: sst/cw(to=20000) indicates a timeout value of 20 seconds. In some of the signal definitions below, specific tone definitions are provided even though actual frequencies may vary from country to country. Country variations should be handled by gateway provisioning. 2.1. Generic Media Package Package Name: G Version: 1 The generic media package groups the events and signals that can be observed on several types of endpoints, such as trunk gateway endpoints, access gateway endpoints or residential gateway endpoints. --------------------------------------------------------------- | Symbol | Definition | R | S Duration | |---------------------------------------------------------------| | cf | Confirm tone | | BR | | cg | Congestion tone | | TO infinite | | ft | Fax tone detected | x | | | it | Intercept tone | | TO infinite | | ld | Long duration connection | C | | | mt | Modem detected | x | | | oc | Operation complete | x | | | of | Operation failure | x | | | pt | Preemption tone | | TO infinite | | rt | Ringback tone | | TO,C 180 seconds| | rbk(###) | Ringback | | TO,C 180 seconds| | pat(###) | Pattern Detected | x | OO | --------------------------------------------------------------- New events added to this package from the previously unversioned package: "oc" Changes: "it" and "pt" signals changed from OO to TO. The events are defined as follows: Confirmation Tone (cf): This is also referred to as "positive indication tone" in ITU-T E.182. In North America, Confirmation Tone uses the same frequencies and levels as dial tone (350 and 440 Hertz) but with a cadence of 0.1 second on, 0.1 second off repeated three times. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.4. It is considered an error to try and play confirmation tone on a phone that Arango et al. Informational [Page 5] Basic MGCP Packages August 2001 is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Congestion Tone (cg): Refer to ITU-T E.180 and E.182. This maps to re-order tone in North America (refer to GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7). Fax tone (ft): Indicates that V.21 fax preamble detected. Intercept tone(it): This is a country specific tone as defined in ITU-T, E.180 Supplement 2. Long Duration (ld): The "long duration connection" is detected when a connection has been established for more than some time. The default value is 1 hour, however the provisioning process may change this. The event is detected on a connection. When no connection is specified as part of the request, the event applies to all connections for the endpoint, regardless of when the connections are created. The "all connections" may also be used for this case, and is in fact preferred for consistency. In either case, the name of the connection on which the event was detected will be included when the event is observed, e.g.: G/ld@0A3F58 Modem tones (mt): Indicates V.25 Answer tone with or without phase reversals or V.8 Modified Answer Tone (ANSam) tone with or without phase reversals. Note that this implies the presence of a data call. Also note that despite the name of the event, devices other than modems may generate such tones, e.g. a fax machine. Preemption Tone (pt): This is a country specific tone and is defined in ITU-T, E.180 Supplement 2. Ring back tone (rt): Refer to ITU E.180 and ITU E.182. Also referred to as ringing tone - a tone advising the caller that a connection has been made and that a calling signal is being applied to the called party or service point. In North America this tone is a combination of two AC tones with frequencies of 440 and 480 Hertz and levels of -19 dBm each, to give a combined level of -16 dBm. The cadence for Audible Ring Tone is 2 seconds on followed by 4 seconds off. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.5. This signal can be applied directly to an endpoint or alternatively on a connection using the syntax "rt@connectionID". When the ringback signal is applied to an endpoint, it is considered an error to try and play ring back tones, if the endpoint is considered on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). When the ringback signal is applied to a connection, no such check is to be made. Note that as specified in [1], signals requested on a connection should be played regardless of the connection mode. For example, in a Arango et al. Informational [Page 6] Basic MGCP Packages August 2001 call-waiting situation, ringback tone may be played on a connection in "inactive" mode. Ringback (rbk): is an alias for rt@connectionID and is included here for backwards compatibility only. It is recommended that Call Agents use rt@connectionID instead of rbk(connectionID) for ring-back over a connection for new implementations. Although the ringback signal is applied on a connection, the ringback signal does not support the "@connection" syntax. pat(###): pattern detected. This event requires special provisioning that needs to be agreed on between the Call Agent and media gateway in order to ensure interoperability. It is retained in order to maintain backwards compatibility with version 0 of the "G" package. 2.2. DTMF package Package name: D Version: 1 -------------------------------------------------------------- | Symbol | Definition | R | S Duration | |--------------------------------------------------------------| | 0 | DTMF 0 | x | BR | | 1 | DTMF 1 | x | BR | | 2 | DTMF 2 | x | BR | | 3 | DTMF 3 | x | BR | | 4 | DTMF 4 | x | BR | | 5 | DTMF 5 | x | BR | | 6 | DTMF 6 | x | BR | | 7 | DTMF 7 | x | BR | | 8 | DTMF 8 | x | BR | | 9 | DTMF 9 | x | BR | | # | DTMF # | x | BR | | * | DTMF * | x | BR | | A | DTMF A | x | BR | | B | DTMF B | x | BR | | C | DTMF C | x | BR | | D | DTMF D | x | BR | | L | long duration indicator | x | | | DD(..) | DTMF tone duration | x | TO 3 seconds | | DO(..) | DTMF OO signal | | OO | | X | Wildcard, match | x | | | | any digit 0-9 | | | | oc | operation complete | x | | | of | operation failure | x | | | T | Interdigit timer | x | | -------------------------------------------------------------- Changes from the previous version of the package: events "dd", "do", "oc" were added. Arango et al. Informational [Page 7] Basic MGCP Packages August 2001 Note that DTMF tones including the DTMF tones wildcard can use the eventRange notation defined in [1] when requesting events, e.g. "D/[0-9](N)". The events are defined as follows: DTMF tones (0-9,*,#,A,B,C,D): Detection and generation of DTMF signals is described in GR-506-CORE - LSSGR: SIGNALING, Section 15. Note that it is considered an error to try and play DTMF tones on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). The events can be specified in a digit map. When requested as a signal, as per GR-506-CORE, section 15, a minimum tone duration of 50 ms will be followed by a minimum interdigit silence period of 45 ms, i.e. if requested in a signal list such as S: sl/s(d/5,d/6,d/7), then interdigit timing requirements will be satisfied. Long Duration Indicator (l): The "long duration indicator" is observed when a DTMF signal is produced for a duration larger than two seconds. In this case, the gateway will detect two successive events: first, when the signal has been recognized, the DTMF signal, and then, 2 seconds later, the long duration signal. DTMF Tone Duration (dd(dg=,to=