diff options
Diffstat (limited to 'doc/rfc/rfc3660.txt')
| -rw-r--r-- | doc/rfc/rfc3660.txt | 3587 |
1 files changed, 3587 insertions, 0 deletions
diff --git a/doc/rfc/rfc3660.txt b/doc/rfc/rfc3660.txt new file mode 100644 index 0000000..1f8ceb4 --- /dev/null +++ b/doc/rfc/rfc3660.txt @@ -0,0 +1,3587 @@ + + + + + + +Network Working Group B. Foster +Request for Comments: 3660 F. Andreasen +Updates: 2705 Cisco Systems +Category: Informational December 2003 + + + Basic Media Gateway Control Protocol (MGCP) Packages + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +IESG Note + + This document is being published for the information of the + community. It describes a non-IETF protocol that is currently being + deployed in a number of products. Implementers should be aware of + RFC 3525 [37], which was developed in the IETF Megaco Working Group + and the ITU-T SG16, and is considered by the IETF and ITU-T to be the + standards-based (including reviewed security considerations) way to + meet the needs that MGCP was designed to address. The IETF Megaco + Working Group and the ITU-T Study Group 16 are developing extensions + to RFC 3525 [37] that for functions of the type in addressed in this + document. + +Abstract + + This document provides a basic set of Media Gateway Control Protocol + (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (Dual + Tone Multifrequency), announcement server and script packages are + updates of packages from RFC 2705 with additional explanation and in + some cases new versions of these packages. In addition to these, + five new packages are defined here. These are the signal list, + resource reservation, media format, supplementary services and digit + map extension packages. + + + + + + + + + + +Foster & Andreasen Informational [Page 1] + +RFC 3660 Basic MGCP Packages December 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. List of Packages . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Changes to Existing RFC 2705 Packages. . . . . . . . . . 3 + 1.2.1. Change in Signal Types . . . . . . . . . . . . . 3 + 1.2.2. Operation Complete and Operation Failure . . . . 3 + 1.2.3. Package Versions . . . . . . . . . . . . . . . . 4 + 1.2.4. Event Definitions, Aliases and Interoperability + Issues . . . . . . . . . . . . . . . . . . . . . 4 + 1.2.5. New Events . . . . . . . . . . . . . . . . . . . 5 + 1.3. New Packages and Excluded Packages . . . . . . . . . . . 5 + 2. Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Generic Media Package. . . . . . . . . . . . . . . . . . 7 + 2.2. DTMF Package . . . . . . . . . . . . . . . . . . . . . . 11 + 2.3. Trunk Package. . . . . . . . . . . . . . . . . . . . . . 16 + 2.4. Line Package . . . . . . . . . . . . . . . . . . . . . . 24 + 2.5. Handset Emulation Package. . . . . . . . . . . . . . . . 33 + 2.6. Supplementary Services Tone Package. . . . . . . . . . . 36 + 2.7. Digit Map Extension. . . . . . . . . . . . . . . . . . . 37 + 2.8. Signal List Package. . . . . . . . . . . . . . . . . . . 38 + 2.9. Media Format Parameter Package . . . . . . . . . . . . . 39 + 2.10. RTP Package. . . . . . . . . . . . . . . . . . . . . . . 43 + 2.11. Resource Reservation Package . . . . . . . . . . . . . . 48 + 2.11.1. Description. . . . . . . . . . . . . . . . . . . 48 + 2.11.2. Parameter Encoding . . . . . . . . . . . . . . . 52 + 2.11.3. Events . . . . . . . . . . . . . . . . . . . . . 53 + 2.12. Announcement Server Package. . . . . . . . . . . . . . . 55 + 2.13. Script Package . . . . . . . . . . . . . . . . . . . . . 56 + 3. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 59 + 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 59 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 60 + 6.2. Informative References . . . . . . . . . . . . . . . . . 62 + 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 63 + 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 64 + +1. Introduction + + This document provides a basic set of Media Gateway Control Protocol + (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF, + announcement server and script packages are updates of packages from + RFC 2705 [38] with additional explanation and in some cases new + versions of these packages. In addition to these, five new packages + are defined here. These are the signal list, resource reservation, + media format, supplementary services and digit map extension + packages. + + + +Foster & Andreasen Informational [Page 2] + +RFC 3660 Basic MGCP Packages December 2003 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [31]. + +1.1. List of Packages + + The basic set of packages specified in this document is for use with + MGCP 1.0 as defined in [1]. Included are the following packages: + + ------------------------------------------- + | Package | Name | + |-------------------------------------------| + | Generic Media Package | G | + | DTMF package | D | + | Trunk Package | T | + | Line Package | L | + | Handset Package | H | + | Supplementary Services Package | SST | + | Digit Map Extension | DM1 | + | Signal List Package | SL | + | Media Format Package | FM | + | RTP Package | R | + | Resource Reservation Package | RES | + | Announcement Server Package | A | + | Script Package | Script | + ------------------------------------------- + +1.2. Changes to Existing RFC 2705 Packages + +1.2.1. Change in signal types + + MGCP 1.0, as defined in RFC 2705 [38] (and now updated in [1]), + provided some additional clarification on the meaning of On-Off (OO) + signals compared to earlier versions of MGCP. This lead to some + inconsistency in some of the signal definitions in the accompanying + packages in RFC 2705 [38]. This has been corrected in the packages + that are included here by changing some of the signals from type On- + Off to type Time-Out (TO). + +1.2.2. Operation Complete and Operation Failure + + Another change made to improve consistency and interoperability was + to add the "operation complete" and "operation failure" events in + packages where there are TO signals defined, but where the "operation + complete" and "operation failure" events were not previously included + as part of the package. By definition, all packages that contain + + + + + +Foster & Andreasen Informational [Page 3] + +RFC 3660 Basic MGCP Packages December 2003 + + + Time-Out type signals now contain the "operation failure" ("of") and + "operation complete" ("oc") events as defined in [1], irrespective of + whether they are provided as part of the package description or not. + + If a package without Time-Out signals contains definitions for the + "oc" and "of" events, the event definitions provided in the package + may over-ride those indicated here. Such practice is however + discouraged and is purely allowed to avoid potential backwards + compatibility problems. + + It is considered good practice to explicitly mention that the "oc" + and "of" events are supported in accordance with their default + definitions. If no definition is included in the package, the + default syntax and semantics are assumed. + + Please refer to [1] for additional details on these events. + +1.2.3. Package Versions + + The generic, line, trunk, handset, RTP, DTMF, announcement server and + script packages included in this document are new versions of + packages that were previously contained in RFC 2705 [38]. The + updated base MGCP 1.0 specification [1] provides an optional + capability of auditing package versions. Any gateway that implements + versioned packages SHOULD also implement this option. + +1.2.4. Event Definitions, Aliases and Interoperability Issues + + Some event definitions or clarifications of previous event + definitions have also been added in order to improve + interoperability. + + In some cases, events have aliases either in the same or in other + packages and a recommendation has been made for the use of alternates + by Call Agents for future implementations. For maximum + interoperability, gateways MUST still implement these events (in fact + they MUST always implement all of the events, signals, etc. in a + package). + + Some events that were previously defined require specific + provisioning in both the gateway and the Call Agent in order to allow + for interoperability. In those cases, a warning to that affect has + been included. + + + + + + + + +Foster & Andreasen Informational [Page 4] + +RFC 3660 Basic MGCP Packages December 2003 + + +1.2.5. New Events + + In some cases, new events have been added to existing packages. Any + changes to existing packages of course have resulted in the package + version number being updated from unversioned (version 0) to version + 1. + +1.3. New Packages and Excluded Packages + + Two packages from RFC 2705 [38] have not been included. These are + the "MF" and the "NAS" packages. These packages are still valid as + are all unversioned (version 0) packages defined in RFC 2705 [38]. + The reason these packages were not included are: + + * The original MF package had no defined way to outpulse MF + digits so that MF CAS is now provided by other packages (i.e., + the "MS", "MO" and "MD" packages) in a separate document. + + * The "N" package, as defined in RFC 2705 [38], was incomplete. + A new MGCP "NAS" package has been developed and provided in a + separate document. + + New packages have also been included beyond what was included in RFC + 2705 [38]. These are the signal list, resource reservation, media + format, supplementary services and digit map extension packages. The + Resource Reservation ("RES") and Media Format ("FM") packages in + particular are different from other packages in this document in that + they contain new LocalConnectionOptions. This is allowed by the new + extension rules in [1]. Future packages of this type MUST use a + packages prefix in front of local connection options ("<package- + name>/<Local Connection Option>") so as to avoid name-space problems. + However because of the timing of the arrival of these packages + relative to updating MGCP 1.0, this was not done for the "RES" and + "FM" packages. The resulting new local connection options have been + registered with IANA. For future cases where a package prefix is + included, only the package name needs to be registered. + +2. Packages + + For those packages that involve MGCP events, the terms "signal" and + "event" are used to differentiate a request from a Call Agent to a + Media Gateway to apply an event ("signal"), from the request for the + detection of an "event" that occurs on the Media Gateway and is + "Notified" to the Call Agent. + + + + + + + +Foster & Andreasen Informational [Page 5] + +RFC 3660 Basic MGCP Packages December 2003 + + + For packages that involve events and signals, the tables contain five + columns: + + Symbol: the (package) unique symbol used to identify the event. + + Definition: a short description of the event. + + R: an x appears in this column if the event can be requested by + the Call Agent. Alternatively, one or more of the following + symbols may appear. An "S" is included if the event-state may be + audited. A "C" indicates that the event can be detected on a + connection, and a "P" indicates the event is persistent. + + S: if nothing appears in this column for an event, then the event + cannot be signaled by the Call Agent. Otherwise, the following + symbols identify the type of event: + + * OO On/Off signal + + * TO Time-Out signal. + + * BR Brief signal. + + In addition, a "C" will be included if the signal can be generated + on a connection. + + Duration: specifies the default duration of TO signals. If a + duration is left unspecified, then the default timeout will be + assumed to be infinite, unless explicitly noted in the description + of the signal. A duration may also be declared as being variable + in a case where signals involve complex sequencing (e.g., scripts + or digit out-pulsing) where the amount of time may vary with + either processing time or the signaling environment. + + Default time-out values may be over-ridden by the Call Agent for any + Time-Out event defined in this document (with the exception of those + that have a default value of "variable") by a "to" signal parameter + which specifies the timeout value in milliseconds (see [1]). The + following example indicates a timeout value of 20 seconds: + + S: sst/cw(to=20000) + + As indicated in [1]: by default, a supplied time-out value MAY be + rounded to the nearest non-zero value divisible by 1000, i.e., whole + second. However, individual signal definitions within a package may + define other rounding rules. + + + + + +Foster & Andreasen Informational [Page 6] + +RFC 3660 Basic MGCP Packages December 2003 + + + Note that Time-Out signals that involve other parameters still allow + the use of the "to" signal parameter e.g.: + + S: T/sit(1,to=3000) + + The order of the "to" parameter relative to the other parameters is + not important. + + Note: as per [1], On-Off (OO) signals are parameterized with "+" + (meaning turn on) or "-" (meaning turn off). If the parameter is + missing, the default is to turn on the signal. Unlike Time-Out + signals, On-Off signals do not stop when an event occurs. + + Other than the "to" parameter for Time-out (TO) signals and the "+" + and "-" for On-Off (OO) signals, signals and events in the packages + in this document do not have parameters unless explicitly indicated + in the description of the event for that package. + + In some of the signal definitions below, specific tone definitions + are provided even though actual frequencies may vary from country to + country. + +2.1. Generic Media Package + + Package Name: G + Version: 1 + + The generic media package groups the events and signals that can be + observed on several types of endpoints, such as trunk gateway + endpoints, access gateway endpoints or residential gateway endpoints. + + --------------------------------------------------------------- + | Symbol | Definition | R | S Duration | + |---------------------------------------------------------------| + | cf | Confirm Tone | | BR | + | cg | Congestion Tone | | TO infinite | + | ft | Fax Tone | x | | + | it | Intercept Tone | | TO infinite | + | ld | Long Duration Connection | C | | + | mt | Modem Tone | x | | + | oc | Operation Complete | x | | + | of | Operation Failure | x | | + | pat(###) | Pattern Detected | x | OO | + | pt | Preemption Tone | | TO infinite | + | rbk(...) | Ringback | | TO,C 180 seconds| + | rt | Ringback Tone | | TO,C 180 seconds| + --------------------------------------------------------------- + + + + +Foster & Andreasen Informational [Page 7] + +RFC 3660 Basic MGCP Packages December 2003 + + + New events added to this package from the previously unversioned + package: "oc" + + Changes: "it" and "pt" signals changed from OO to TO. + + Note that default time-out values may be over-ridden by the Call + Agent for any Time-Out signal defined in this package by a "to" + signal parameter. Refer to section 2 of this document, as well as + [1] for details. + + The events and signals are defined as follows: + + Confirmation Tone (cf): + This is also referred to as "positive indication tone" in ITU-T + E.182. In North America, Confirmation Tone uses the same + frequencies and levels as dial tone (350 and 440 Hertz) but with a + cadence of 0.1 second on, 0.1 second off, repeated three times. + See GR-506-CORE [7] Section 17.2.4. It is considered an error to + try and play confirmation tone on a phone that is on-hook and an + error MUST consequently be returned when such attempts are made + (error code 402 - phone on-hook). + + Congestion Tone (cg): + Refer to ITU-T E.180 [8] and E.182 [10]. This maps to re-order + tone in North America (refer to GR-506-CORE [7] Section 17.2.7). + + Fax Tone (ft): + The fax tone event is generated whenever a fax call is detected by + the presence of V.21 fax preamble. The fax tone event SHOULD also + be generated when the T.30 CNG tone is detected. See ITU-T + Recommendations T.30 [21] and V.21 [22]. + + Intercept Tone(it): + This is a country specific tone as defined in ITU-T E.180 + Supplement 2 [9]. + + Long Duration Connection (ld): + The "long duration connection" is detected when a connection has + been established for more than a provisioned amount of time. The + default value is 1 hour. + + This event is detected on a connection. When no connection is + specified as part of the request, the event applies to all + connections for the endpoint, regardless of when the connections + are created. The "all connections" wildcard (see [1]) may also be + used for this case, and is in fact preferred for consistency. In + + + + + +Foster & Andreasen Informational [Page 8] + +RFC 3660 Basic MGCP Packages December 2003 + + + either case, the name of the connection on which the event was + detected will be included when the event is observed, e.g.: + + G/ld@0A3F58 + + Modem Tone (mt): + Indicates V.25 Answer tone (ANS) with or without phase reversals + or V.8 Modified Answer Tone (ANSam) tone with or without phase + reversals. Note that this implies the presence of a data call. + Also note that despite the name of the event, devices other than + modems may generate such tones, e.g., a fax machine. + + Operation Complete (oc): + The standard definition of operation complete [1]. + + Operation Failure (of): + The standard definition of operation failure [1]. + + Pattern Detected (pat(###)): + This event requires special provisioning that needs to be agreed + on between the Call Agent and media gateway in order to ensure + interoperability. It is retained in order to maintain backwards + compatibility with version 0 of the "G" package. This event MUST + be parameterized with a decimal numeric value from 0 to 999 + specifying the pattern to detect. When reported, the pattern is + also included as a parameter. + + Preemption Tone (pt): + This is a country specific tone and is defined in ITU-T E.180 + Supplement 2 [9]. + + Ringback (rbk(connectionID)): + This is an alias for "rt@connectionID" and is included here for + backwards compatibility only. It is recommended that Call Agents + use "rt@connectionID" instead of "rbk(connectionID)" for ring-back + over a connection for new implementations. Although the ringback + signal is applied on a connection, the "rbk" signal does not + support the "@connection" syntax. When the signal is requested, + it MUST be parameterized with a connection-ID or a connection-ID + wildcard as specified in [1]. + + Ringback Tone (rt): + Refer to ITU-T E.180 [8] and ITU-T E.182 [10]. Also referred to + as ringing tone - a tone advising the caller that a connection has + been made and that a calling signal is being applied to the called + party or service point. In North America, this tone is a + combination of two AC tones with frequencies of 440 and 480 Hertz + and levels of -19 dBm each, to give a combined level of -16 dBm. + + + +Foster & Andreasen Informational [Page 9] + +RFC 3660 Basic MGCP Packages December 2003 + + + The cadence for Audible Ring Tone is 2 seconds on, followed by 4 + seconds off. See GR-506-CORE [7] - LSSGR: SIGNALING, Section + 17.2.5. + + This signal can be applied directly to an endpoint or + alternatively on a connection using the syntax "rt@connectionID". + When the ringback signal is applied to an endpoint, it is + considered an error to try and play ringback tone if the endpoint + is considered on-hook, and an error MUST consequently be returned + when such attempts are made (error code 402 - phone on-hook). + When the ringback signal is applied to a connection, no such check + is to be made. + + Note that as specified in [1], signals requested on a connection + MUST be played regardless of the connection mode. For example, in + a call-waiting situation, ringback tone may be played on a + connection in "inactive" mode. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Foster & Andreasen Informational [Page 10] + +RFC 3660 Basic MGCP Packages December 2003 + + +2.2. DTMF package + + Package name: D + Version: 1 + + -------------------------------------------------------------- + | Symbol | Definition | R | S Duration | + |--------------------------------------------------------------| + | 0 | DTMF 0 | x | BR | + | 1 | DTMF 1 | x | BR | + | 2 | DTMF 2 | x | BR | + | 3 | DTMF 3 | x | BR | + | 4 | DTMF 4 | x | BR | + | 5 | DTMF 5 | x | BR | + | 6 | DTMF 6 | x | BR | + | 7 | DTMF 7 | x | BR | + | 8 | DTMF 8 | x | BR | + | 9 | DTMF 9 | x | BR | + | # | DTMF # | x | BR | + | * | DTMF * | x | BR | + | A | DTMF A | x | BR | + | B | DTMF B | x | BR | + | C | DTMF C | x | BR | + | D | DTMF D | x | BR | + | DD(..) | DTMF Tone Duration | x | TO 3 seconds | + | DO(..) | DTMF OO Signal | | OO | + | L | Long Duration Indicator | x | | + | oc | Operation Complete | x | | + | of | Operation Failure | x | | + | T | Interdigit Timer | x | TO 16 seconds | + | X | DTMF Tones Wildcard, | x | | + | | match any digit 0-9 | | | + -------------------------------------------------------------- + + Changes from the previous version of the package: events "dd", "do", + "oc" were added. + + Note that DTMF tones including the DTMF tones wildcard can use the + eventRange notation defined in [1] when requesting events, e.g., + "D/[0-9](N)". + + Note that default time-out values may be over-ridden by the Call + Agent for any Time-Out signal defined in this package by a "to" + signal parameter. Refer to section 2 of this document, as well as + [1] for details. + + + + + + +Foster & Andreasen Informational [Page 11] + +RFC 3660 Basic MGCP Packages December 2003 + + + The events are defined as follows: + + DTMF tones (0-9,#,*,A,B,C,D): + Detection and generation of DTMF tones is described in GR-506-CORE + [7] - LSSGR: SIGNALING, Section 15. Note that it is considered an + error to try and play DTMF tones on a phone that is on-hook and an + error MUST consequently be returned when such attempts are made + (error code 402 - phone on-hook). The event codes can be + specified in a digit map. When requested as a signal, as per + GR-506-CORE [7], section 15, a minimum tone duration of 50 ms will + be followed by a minimum interdigit silence period of 45 ms, i.e., + if requested in a signal list such as "S: sl/s(d/5,d/6,d/7)", then + interdigit timing requirements will be satisfied. + + Note that some types of endpoints, such as announcement endpoints, + MAY allow detection and/or generation of a DTMF tone over a + connection. However, this requires consistent provisioning + between the Call Agent and announcement server (it is not required + in order to be compliant with the DTMF package). + + DTMF Tone Duration (dd(dg=<tone>,to=<time>,su=<TrueOrFalse>)): + This event can be used to indicate if/when the specified <tone> + has a duration greater than the <time> value indicated (and is + reported once the duration is exceeded). The parameters can be + supplied in any order. The value of <tone> can be any of the DTMF + tone symbols (without including the package name) specified in the + DTMF package (including X in the case of events, but not signals). + If this parameter is absent, any DTMF tone that occurs will be + reported. The parameter <time> is in milli-seconds and may be + rounded to the nearest 10 ms by the gateway. The minimum value of + <time> that can be requested when requesting an event is 40 ms. + When requesting a signal, the minimum value of <time> that can be + requested is 50 ms. The maximum value of <time> that can be + requested for either an event or a signal is 60000 ms. If the + "to=<time>" parameter is absent when requested as an event, the + event will report the full duration (up to 60000 ms) of the tone + when the tone is completed. When reported as an ObservedEvent, + both parameters are always supplied. In this case, <tone> is the + actual tone detected and <time> is either: + + * The <time> specified in the request (possibly rounded), or + + * If the request did not contain a "to=<time>" parameter, the + full duration of the tone. + + The parameter "su" MAY be included when this is requested as an + event (but is not reported). This parameter is used to indicate + whether or not the DTMF digits requested should be suppressed + + + +Foster & Andreasen Informational [Page 12] + +RFC 3660 Basic MGCP Packages December 2003 + + + in-band when it is requested. Possible values are "true", + indicating that in-band DTMF should be suppressed and "false" + indicating that DTMF should continue to be passed in-band. The + default value of the parameter, if missing, is "false". The "su" + parameter MUST NOT be included when requesting "D/dd" as a signal. + + When used as a signal, "dd" provides the ability to generate a + DTMF tone as a TO signal. When applied as a signal, an additional + 50 ms of silence will be tacked onto the end before the operation + complete occurs, i.e., "S: dd(dg=5,to=2500)" will play the DTMF + tone for the number "5" for 2.5 seconds, followed by 50 ms of + silence period. The operation complete (if requested) will be + notified after the silence interval occurs. Any value from 50 ms + to 60000 ms can be requested. Gateways generating or detecting + the tone may round off the requested time to the nearest 10 ms. + + The "dd" event can be used in place of the "long duration" event + in order to detect a digit pressed for longer than 2 seconds. For + example, in order to detect if a user presses the long "#" for + longer than 2 seconds, a request could be made with the + RequestedEvents line "R: d/dd(N)(dg=#,to=2000)". The resulting + ObservedEvents line would be "O: d/dd(dg=#,to=2000)". + + Suppose instead, that the RequestedEvents line contains + + R: d/[0-9*#],d/dd + + Suppose the user then pushes the "#" for 2.5 seconds. In this + case, two events will be notified: + + O: d/# + + when the "#" key is first pressed, and + + O: d/dd(dg=#,to=2500) + + when the "#" key is finally released. + + DTMF OO Signal (do(dg=<tone>,<on-or-off>)): + This signal is used to generate a DTMF tone as an on-off signal. + The <tone> parameter is any of the symbols for a specific tone in + the DTMF package (i.e., "0" to "9", "A", "B", "C", "D", "*", or + "#"). The <on-or-off> indicator is "+" for on and "-" for off as + per [1]. The <tone> parameter MUST be supplied, otherwise a + return code of 538 - "Event/signal parameter error" will be + provided in the response. If the <on-or-off> parameter is + missing, the default is to turn the signal on as usual (i.e., "+" + is the default). The order of the parameters is not significant + + + +Foster & Andreasen Informational [Page 13] + +RFC 3660 Basic MGCP Packages December 2003 + + + since "+" and "-" are reserved characters and are easily + distinguished from the <tone> parameter. + + Long Duration Indicator (l): + The "long duration indicator" is observed when a DTMF signal is + produced for a duration larger than two seconds. In this case, + the gateway will detect two successive events: first, when the + signal has been recognized, the DTMF signal, and then, 2 seconds + later, the long duration signal. + + Operation Complete (oc): + This is the standard definition of operation complete [1]. + + Operation Failure (of): + This is the standard definition of operation failure [1]. + + Timer (t): + Timer T can be used as an event or as a time-out (TO) signal. As + a signal, its only behavior is the normal characteristics of a + "TO" signal as defined in [1] (i.e., if no event occurs before the + time-out, an operation complete event will be generated). + + As an event, Timer T is a digit input timer that can be used in + two ways: + + * When timer T is used with the accumulate according to digit + map action, the timer is not started until the first DTMF + tone is entered, and the timer is restarted after each new + DTMF tone is entered until either a digit map match or + mismatch occurs. In this case, timer T functions as an + inter-digit timer as illustrated by: + + R: D/[0-9T](D) + + * When timer T is used without the "accumulate according to + digit map" action, the timer is started immediately and + simply cancelled (but not restarted) as soon as a DTMF tone + is entered. In this case, timer T can be used as an inter- + digit timer when overlap sending is used, as in: + + R: D/[0-9](N), D/T(N) + + When used with the "accumulate according to digit map" action, + timer T takes on one of two values, T-partial or T-critical. When + at least one more symbol is required for the "current dial string" + to match any one of the patterns in the digit map, timer T takes + on the value T-partial, corresponding to partial dial timing. If + a timer is all that is required to produce a match, timer T takes + + + +Foster & Andreasen Informational [Page 14] + +RFC 3660 Basic MGCP Packages December 2003 + + + on the value T-critical corresponding to critical dial timing. + When timer T is used without the "accumulate according to digit + map" action, timer T takes on the value T-critical. The default + value for T-partial is 16 seconds and the default value for + T-critical is 4 seconds. The provisioning process may alter both + of these. If timer T is not used, then inter-digit timing will + not be performed. + + The following examples illustrate this. Consider the digit map: + + (xxxxxxx|x11T) + + and assume that DTMF and the timer T is accumulated according to + digit map. At the first DTMF input, say "4", timer T is started + with a value of T-partial since at least one more symbol is + required. If "1" is then input, it leads to a restart of timer T + with a value of T-partial again. If "1" is now input again, we + have a current dial string of "411" and a timer is now all that is + required to produce a match. Hence timer T is now restarted with + value T-critical. + + Finally, consider the following subtle examples (all assuming DTMF + and timer T being accumulated according to digit map): + + The digit map + + (1[2-3T].) + + will match immediately on the input "1" since zero or more matches + of the range are specified. + + The digit map + + (1[2-3].T) + + and an input of "1" will lead to timer T being set to T-critical. + + A digit map of + + (1[2-3]T.) + + and an input of "1" will lead to timer T being set to T-partial. + Furthermore, upon subsequent input of "2" or "3" a perfect match + will be triggered immediately since timer T is completely + irrelevant. + + + + + + +Foster & Andreasen Informational [Page 15] + +RFC 3660 Basic MGCP Packages December 2003 + + + DTMF Tones Wildcard (X): + The DTMF tones wildcard matches any DTMF digit between 0 and 9. + The actual event code generated will however be the event code for + the digit detected. The DTMF tones wildcard is often used to + detect DTMF input to be matched against a digit map. + +2.3. Trunk Package + + Package Name: T + Version: 1 + + ---------------------------------------------------------------- + | Symbol | Definition | R | S Duration | + |----------------------------------------------------------------| + | as | Answer Supervision | x | BR | + | bl | Blocking | | BR | + | bz | Busy | | TO 30 sec. | + | co1 | Continuity Tone (go tone, | x | TO 3 sec. | + | | or return tone) | | | + | co2 | Continuity Test (go tone, | x | TO 3 sec. | + | | or return tone in dual tone | | | + | | procedures) | | | + | ct(...) | Continuity Transponder | | OO | + | lb | Loopback | | OO | + | nm | New Milliwatt Tone | x | TO 3 sec | + | mm | Newest Milliwatt Tone | x | TO 3 sec | + | oc | Operation Complete | x | | + | of | Operation Failure | x | | + | om | Old Milliwatt Tone | x | TO 3 sec | + | pst | Permanent Signal Tone | | TO infinite | + | qt | Quiet Termination | | TO infinite | + | ro | Reorder Tone | x | TO 30 sec. | + | sit(#) | Special Information Tone | x | TO 2 sec. | + | | | | (see notes) | + | tl | Test Line | x | TO infinite | + | tp(###) | Test Pattern | x | TO 3 sec | + | zz | No Circuit | x | TO 2 sec | + ---------------------------------------------------------------- + + New events added to this package from the previously unversioned + package: "bz", "ct", "mm", "oc", "pst", "qt", "sit", and "tp". + + Changes in event types: "co1", "co2", "nm", "om", "tl", "zz" signals + changed from OO to TO; "as" and "bl" changed from OO to BR. + + + + + + + +Foster & Andreasen Informational [Page 16] + +RFC 3660 Basic MGCP Packages December 2003 + + + Note that default time-out values may be over-ridden by the Call + Agent for any Time-Out signal defined in this package by a "to" + signal parameter. Refer to section 2 of this document, as well as + [1] for details. + + The definition of the trunk package events are as follows: + + Answer Supervision (as): + This event is used to indicate the occurrence answer supervision. + In most cases, it is a result of a steady off-hook in response to + a call request. This event is included for backwards + compatibility with the previous version of the package. The + preferred alternative is to use the "answer" event in the + appropriate CAS packages [34] (Note: check the details on the use + of "answer" in the particular CAS package; in most cases "answer" + as an event is an indication of a steady off-hook regardless of + whether or not it is an indication of answer supervision). For + details on when answer supervision is appropriate refer to [5]. + + Blocking (bl): + This event is used to indicate an incoming off-hook for the + purposes of blocking a one-way trunk in CAS trunks. This event is + included for backwards compatibility with the previous version of + the package. The preferred alternative is the "block" event in + the appropriate CAS packages [34]. + + Busy Tone (bz): + Refer to ITU-T E.180 [8]. In North America, station Busy is a + combination of two AC tones with frequencies of 480 and 620 Hertz + and levels of -24 dBm each, to give a combined level of -21 dBm. + The cadence for Station Busy Tone is 0.5 seconds on, followed by + 0.5 seconds off, then repeating. See GR-506-CORE [7]- LSSGR: + SIGNALING, Section 17.2.6. + + Continuity Tone (co1): + A tone at 2010 Hz (see section 3.1.1.3 of [2]). When generated as + a signal, the frequency of the tone must be within + or - 8 Hz, + while the frequency of the tone corresponding to the event must be + within + or - 30 Hz. + + Continuity Test (co2): + A tone at 1780 Hz (see section 3.1.1.3 of [2]). When generated as + a signal, the frequency of the tone must be within + or - 20 Hz, + while the frequency of the tone corresponding to the event must be + within + or - 30 Hz. + + In continuity testing the tone corresponding to the signal at the + originating gateway is referred to as the "go" tone, and the tone + + + +Foster & Andreasen Informational [Page 17] + +RFC 3660 Basic MGCP Packages December 2003 + + + corresponding to the event at that same gateway is referred to as + the "return" or "check" tone. + + Note that generation and notification of continuity tones are done + as per continuity test requirements as defined in ITU-T Q.724 [3], + as well as by Bellcore GR-317-CORE [2] specifications, i.e., the + semantics of notification of the return tone is more than that the + tone was received, but is an indication that the test has passed. + Details are provided in the following paragraphs. + + The continuity tones represented by co1 and co2 are used when the + Call Agent wants to initiate a continuity test. There are two + types of tests, single tone and dual tone; In the case of the dual + tone, either tone can be sent and the opposite received depending + on the trunk interconnections (4-wire or 2-wire) as indicated + below: + + Originating Terminating + ============ =========== + + 4w -------------- 1780 Hz -----------> 2w + <------------- 2010 Hz ------------ (transponder) + + 2w -------------- 2010 Hz -----------> 2w/4w + <------------- 1780 Hz ------------ (transponder) + + 4w -------------- 2010 Hz -----------> 4w + <------------- 2010 Hz ------------ (loopback) + + The Call agent is expected to know, through provisioning + information, which test should be applied to a given endpoint. As + an example, for a 4-wire to 2-wire connection, the Call Agent + might send a request like the following to an originating gateway: + + RQNT 1234 ds/ds1-1/17@tgw2.example.net + X: AB123FE0 + S: t/co1 + R: t/co2,t/oc,t/of + + On a terminating side of a trunk, the call agent may request a + continuity test connection (connection mode "conttest") to the + terminating gateway as follows: + + CRCX 3001 ds/ds1-2/4@tgw34.example.net + C: 3748ABC364 + M: conttest + + + + + +Foster & Andreasen Informational [Page 18] + +RFC 3660 Basic MGCP Packages December 2003 + + + Alternatively, rather than using a connection mode, the "T/ct" + signal can be used (see description of this signal further below): + + RQNT 3001 ds/ds1-2/4@tgw34.example.net + X: 1233472 + S: t/ct(in=co1,out=co2,+) + + The originating gateway would send the requested "go" tone, and + would look for the appropriate "return tone". Once the return + tone is received, the originating gateway removes the go tone and + checks to see that the return tone has been removed within the + specified performance limits (i.e., GR-246-CORE, T1.113.4, Annex B + [23]). When it detects that the test is successful, the gateway + will send a notification of the return tone event (Note that + notification of the return tone event therefore must not be sent + prior to detection of the removal of the return tone). + + The "T/co1" and "T/co2" signals are TO signals so that an + operation complete event will occur when the signal times out. If + a timeout value other than the default is desired, the "to" + parameter may be used (e.g., "S: T/co1(to=2000)"). + + If the gateway detects the failure of the continuity test prior to + the timeout, an operation failure event will be generated. + Otherwise, the failure of the continuity test is determined by the + failure to receive the return tone event before the timeout occurs + (operation complete event). As with TO signals in general, + operation complete and operation fail events are parameterized + with the name of the signal. + + In the example above where the go tone is "co1" and the return + tone is "co2": + + * A notification of the "co2" event indicates success (i.e., + "O: t/co2"). + + * A notification of the operation failure event indicates + failure prior to timeout (i.e., "O: t/of(t/co1)"). + + * A notification of the operation complete event indicates + that the return tone was not received properly prior to the + occurrence of the timeout (i.e., "O: t/oc(t/co2)"). + + On a terminating end of a trunk, either a "loopback" connection + (single tone test) or "conttest" connection (dual tone test) is + made (or alternatively the "T/lb" or "T/ct" signals are + requested). It is up to the termination end to make sure that the + return tone is removed as soon as the go tone disappears. The + + + +Foster & Andreasen Informational [Page 19] + +RFC 3660 Basic MGCP Packages December 2003 + + + Call Agent requests the removal of "contest" or "loopback" + connections (or "T/lb" or "T/ct" signals) at a termination end + when the results of the continuity test are obtained. + + When "conttest" is used, the endpoint is provisioned as to which + transponder test is being performed (2010 Hz received and 1780 Hz + sent or vice versa). In the case of the corresponding "T/ct" + signal, the Call Agent can specify which tone is received and sent + as parameters. + + Note that continuity tones in the trunk package are only ever sent + to the telephony endpoint. For network-based continuity, there + are continuity tones available in the RTP ("R") package. Although + a transponder (dual tone) test can be done, a single tone test is + generally sufficient in the case of continuity testing across an + IP network. + + Continuity Transponder(ct(in=<tone-in>,out=<tone-out>, <+ or ->)): + This signal is used to provide transponder functionality + independent of the connection mode, i.e., this is an alternative + way to provide the same functionality as the "conttest" connection + mode. The parameters can be provided in any order. The <tone-in> + and <tone-out> parameters can have values "co1" or "co2", + corresponding to the 2010 Hz and 1780 Hz tones associated with + those symbols. If one of the tones is "co1", then the other must + be "co2" and vice versa (i.e., <tone-in> and <tone-out> must have + different values; if loopback is required, then the "lb" signal in + this package or "loopback" connection mode should be used). + + On detecting <tone-in>, <tone-out> will be generated in return. + The tone corresponding to <tone-out> will continue to be generated + until either: + + * The signal is explicitly turned off (e.g., "S: t/ct(-)") or + + * Removal of the <tone-in> tone is detected. + + Note that while the signal is active (regardless of whether a tone + is active or not), media from the endpoint will not be forwarded + to or from the packet network (i.e., the continuity transponder + signal must be explicitly turned off by the Call Agent in order to + resume passing media between the packet network and the endpoint). + + Loopback (lb): + This signal is used to provide loopback functionality independent + of the connection mode, i.e., this is an alternative way to + provide the same functionality as "loopback" connection mode. + + + + +Foster & Andreasen Informational [Page 20] + +RFC 3660 Basic MGCP Packages December 2003 + + + Note that while the loop-back signal is active (regardless of + whether a tone is active or not), media from the endpoint will not + be forwarded to or from the packet network (i.e., the loopback + signal must be explicitly turned off by the Call Agent in order to + resume passing media between the packet network and the endpoint). + + New Milliwatt Tone (nm): + 1004 Hz tone - refer to [4] and section 8.2.5 of [5]. + + Newest Milliwatt Tone (mm): + 1013.8 Hz - refer to [4]. + + Operation Complete (oc): + This is the standard definition of operation complete [1]. + + Operation Failure (of): + This is the standard definition of operation failure [1]. + + Old Milliwatt Tone (om): + 1000 Hz tone - refer to [4] and section 8.2.5 of [5]. + + Permanent Signal Tone (pst): + In North America, this tone is applied to a busy line + verify/operator interrupt under specific circumstances as + described in [17]. + + Quiet Termination (qt): + Quiet Termination is used in a 102 trunk test. Reference section + 6.20.5 [5] as well as [4]. + + Reorder Tone(ro): + This maps to congestion tone in the ITU-T E.182 specification. In + North America, reorder tone is a combination of two AC tones with + frequencies of 480 and 620 Hertz and levels of -24 dBm each, to + give a combined level of -21 dBm. The cadence for reorder tone is + 0.25 seconds on, followed by 0.25 seconds off, repeating + continuously (until time-out). See GR-506-CORE [7], Section + 17.2.7. + + Special Information Tone(sit(#)): + As described in ITU-T E.180 [8], the special information tone + consists of a tone period in which 3 tones are produced followed + by a silent period of 1 second (total TO period of approximately 2 + seconds). When used as a signal, it MUST be parameterized with a + parameter value from 1 to 7, with the following meaning as defined + in SR-2275, section 6.21.2 of [5]. + + + + + +Foster & Andreasen Informational [Page 21] + +RFC 3660 Basic MGCP Packages December 2003 + + + ------------------------------------------- + | sit(1) | RO' | reorder SIT, intra-LATA | + | sit(2) | RO" | reorder SIT, inter-LATA | + | sit(3) | NC' | no circuit SIT, intra-LATA | + | sit(4) | NC" | no circuit SIT, inter-LATA | + | sit(5) | IC | intercept SIT | + | sit(6) | VC | vacant code SIT | + | sit(7) | IO | ineffective other SIT | + ------------------------------------------- + + When requested as an event, the event MUST be parameterized with a + decimal number from 1 to 7 to indicate which tone the gateway is + required to detect. The resulting notification also includes the + parameter. Other countries may have one or more special + information tones with country specific definitions (refer to + ITU-T E.180 supp. 2 [9]). In this case, special information tone + 1 as defined in [9] is sit(1), special information tone 2 is + sit(2) etc. + + As an example, the Call Agent might make a request such as: + + RQNT 1234 ds/ds1-1/17@tgw2.example.net + X: AB123FE0 + R: t/sit(N)(2) + + If the tone is detected, the resulting notification might appear + as follows: + + NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 + X: AB123FE0 + O: t/sit(2) + + Test Line (tl): + 105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 + dBm0). Refer to section 8.2.5 of [5]. + + Test Pattern (tp(###)): + The tp(###) signal inserts the pattern ### continuously into the + channel until the timeout period expires. The parameter is + provided as a decimal number from 0 to 255. If the parameter is + omitted, the default value is decimal 95. + + In RequestedEvents, the parameter MAY be supplied to indicate what + pattern the Call Agent wishes the gateway to detect. If the + parameter is omitted, the value 95 is assumed. The pattern MUST + be returned in the ObservedEvent (even if the parameter was not + requested). + + + + +Foster & Andreasen Informational [Page 22] + +RFC 3660 Basic MGCP Packages December 2003 + + + A typical use for the test pattern signal is for the test line 108 + (digital loopback) test (refer to section 8.2.5 of [5]). At the + termination side of a trunk, the Call Agent would request a + connection in "loopback" mode, which would do a digital loopback. + On the origination side of the trunk, the Call Agent would request + that the test pattern be injected into the digital channel, and + would check to see that the pattern was returned within the + timeout period. As an example, the Call Agent would make the + following request on the origination side: + + RQNT 1234 ds/ds1-1/17@tgw2.example.net + X: AB123FE0 + S: t/tp + R: t/tp, t/oc, t/of + + In this case the Call Agent will either receive: + + * An ObservedEvent indicating that the test has passed (i.e., + "O:t/op(95)") or + + * An ObservedEvent indicating that the timeout occurred before + the pattern was received (i.e., "O:t/oc(t/tp)"), indicating + that the test failed. Of course an operation failure would + indicate failure as well. + + No Circuit (zz): + This is an alias for Special Information Tone 2, i.e., "sit(2)". + + + + + + + + + + + + + + + + + + + + + + + + +Foster & Andreasen Informational [Page 23] + +RFC 3660 Basic MGCP Packages December 2003 + + +2.4. Line Package + + Package Name: L + Version: 1 + + ---------------------------------------------------------------- + |Symbol | Definition | R | S Duration | + |----------------------------------------------------------------| + |adsi(string) | ADSI Display | | BR | + |aw | Answer Tone | x | OO | + |bz | Busy Tone | | TO 30 sec. | + |ci(ti,nu,na) | Caller-id | | BR | + |dl | Dial Tone | | TO 16 sec. | + |e | Error Tone | x | TO 2 sec. | + |hd | Off-hook Transition | S | | + |hf | Flash-hook | x | | + |ht | On Hold Tone | | OO | + |hu | On-hook Transition | S | | + |lsa | Line Side Answer Sup. | | OO | + |mwi | Message Waiting ind. | | TO 16 sec. | + |nbz | Network busy | x | TO infinite | + |oc | Operation Complete | x | | + |of | Operation Failure | x | | + |osi | Network Disconnect | | TO 900 ms | + |ot | Off-hook Warning Tone | | TO infinite | + |p | Prompt Tone | x | BR | + |rg | Ringing | | TO 180 sec. | + |r0, r1, r2, | Distinctive Ringing | | TO 180 sec. | + |r3, r4, r5, | | | | + |r6 or r7 | | | | + |ro | Reorder Tone | | TO 30 sec. | + |rs | Ringsplash | | BR | + |s(###) | Distinctive Tone Pattern | x | BR | + |sit(#) | Special Information Tone | | TO 2 sec. | + | | | | (see notes) | + |sl | Stutter Dial Tone | | TO 16 sec. | + |v | Alerting Tone | | OO | + |vmwi | Visual Message | | OO | + | | Waiting Indicator | | | + |wt | Call Waiting Tone | | TO 12 sec | + |wt1, wt2, | Alternative Call | | TO 12 sec | + |wt3, wt4 | Waiting Tones | | (see notes) | + |y | Recorder Warning Tone | | TO infinite | + |z | Calling Card Service Tone| | BR | + ---------------------------------------------------------------- + + New events added to this package from the previously unversioned + package: "ht", "osi", and "lsa". + + + +Foster & Andreasen Informational [Page 24] + +RFC 3660 Basic MGCP Packages December 2003 + + + Changes in event types: signals "y", "z", changed from OO to TO and + BR respectively. Ringing tones were extended to allow for a ring + repetition signal parameter. + + Note that default time-out values may be over-ridden by the Call + Agent for any Time-Out signal defined in this package by a "to" + signal parameter. Refer to section 2 of this document, as well as + [1] for details. + + The description of events and signals in the line package are as + follows: + + ADSI Display (adsi): + This signal is included here to maintain compatibility with the + previous version of this package. The signal is not well-defined + and its use is discouraged. + + Answer Tone (aw): + This event is included here to maintain compatibility with the + previous version of this package. The event is not well-defined + and its use is discouraged. + + Busy Tone (bz): + Refer to ITU-T E.180 [8]. In North America, station Busy is a + combination of two AC tones with frequencies of 480 and 620 Hertz + and levels of -24 dBm each, to give a combined level of -21 dBm. + The cadence for Station Busy Tone is 0.5 seconds on followed by + 0.5 seconds off, repeating. See GR-506-CORE [7], Section 17.2.6. + It is considered an error to try and play busy tone on a phone + that is on-hook and an error MUST consequently be returned when + such attempts are made (error code 402 - phone on-hook). + + Caller-id (ci(time, number, name)): + See GR-1188 [24], GR-30-CORE [14], and GR-31 [25]. For backwards + compatibility, each of the three fields are optional, but each of + the commas will always be included. In accordance with the + general MGCP grammar, it is RECOMMENDED to always include all + three fields - an empty quoted string can then be used in lieu of + omitting a parameter: + + The time parameter is coded as "MM/DD/HH/MM", where MM is a two- + digit decimal value for a Month between 01 and 12, DD is a two- + digit value for a Day between 01 and 31, and Hour and Minute are + two-digit values coded according to military local time, e.g., 00 + is midnight, 01 is 1 a.m., and 13 is 1 p.m. (Note: two digits + MUST always be provided for each of the values of month, day, + hour, minutes e.g., the month of January is indicated by the two + digits "01" rather than just "1"). + + + +Foster & Andreasen Informational [Page 25] + +RFC 3660 Basic MGCP Packages December 2003 + + + The number parameter is coded as an ASCII character string of + decimal digits that identify the calling line number. White + spaces are permitted if the string is quoted, but they will be + ignored. If a quoted-string is provided, the string itself is + UTF-8 encoded (RFC 2279) as usual for signal parameters. + + The name parameter is coded as a string of ASCII characters that + identify the calling line name. White spaces are permitted if the + string is quoted. If a quoted-string is provided, the string + itself is UTF-8 encoded (RFC 2279). + + A "P" in the number or name field is used to indicate a private + number or name, and an "O" is used to indicate an unavailable + number or name. Other letters MAY be used to provide additional + clarification as per provider or vendor specifications. + + The following example illustrates the use of the caller-id signal: + + S: l/ci(09/14/17/26, "555 1212", "John Doe") + + An example indicating that the name and number are private: + + S: l/ci(09/14/17/26,P,P) + + Dial Tone (dl): + Refer to the ITU-T E.180 [8] specification. In North America, + dial tone is a combination of two continuous AC tones with + frequencies of 350 and 440 Hertz and levels of -13dBm each, to + give a combined level of -10 dBm. See GR-506-CORE [7] - LSSGR: + SIGNALING, Section 17.2.1. It is considered an error to try and + play dial-tone on a phone that is on-hook and an error MUST + consequently be returned when such attempts are made (error code + 402 - phone on-hook). + + Error Tone (e): + This tone is maintained for backwards compatibility. The tone is + not well defined and its use is discouraged. + + Off-hook Transition (hd): + See GR-506-CORE [7], Section 12. It is considered an error to try + and request off-hook on a phone that is off-hook and an error MUST + consequently be returned when such attempts are made (error code + 401 - phone off-hook). + + + + + + + + +Foster & Andreasen Informational [Page 26] + +RFC 3660 Basic MGCP Packages December 2003 + + + Flash Hook (hf): + See GR-506-CORE [7], Section 12. It is considered an error to try + and request flash hook on a phone that is on-hook and an error + MUST consequently be returned when such attempts are made (error + code 402 - phone on-hook). + + Tone On Hold (ht): + A tone used to reassure a calling subscriber who has been placed + on "hold". Refer to ITU-T E.182 [10]. + + On-hook Transition (hu): + See GR-506-CORE [7], Section 12. The timing for the on-hook + signal is for flash response enabled, unless provisioned + otherwise. It is considered an error to try and request flash + hook on a phone that is on-hook and an error MUST consequently be + returned when such attempts are made (error code 402 - phone on- + hook). + + Line Side Answer Supervision (lsa): + This provides Reverse Loop Current Feed (RLCF) on the line (refer + to GR-506-CORE [7]) and is a way of indicating that the called + party has answered for some line-side equipment. + + Message Waiting Indicator (mwi): + Message Waiting indicator tone uses the same frequencies and + levels as dial tone (350 and 440 Hertz at -13dBm each), but with a + cadence of 0.1 second on, 0.1 second off, repeated 10 times, + followed by steady application of dial tone. See GR-506-CORE [7], + Section 17.2.3. It is considered an error to try and play + message-waiting indicator on a phone that is on-hook and an error + MUST consequently be returned when such attempts are made (error + code 402 - phone on-hook). + + Network Busy (nbz): + This is included here to maintain compatibility with the previous + version of this package. The "nbz" signal is an alias for re- + order tone signal("ro"). Future Call Agent implementations that + require a network busy signal should use the "ro" signal. It is + also recommended that future Call Agents not request to be + notified of the "nbz" event (a network busy event is generally not + required in a line package; hence, "ro" is only a signal, not an + event). + + Operation Complete (oc): + This is the standard definition of operation complete [1]. + + Operation Failure (of): + This is the standard definition of operation failure [1]. + + + +Foster & Andreasen Informational [Page 27] + +RFC 3660 Basic MGCP Packages December 2003 + + + Network Disconnect (osi): + Network Disconnect indicates that the far-end party has + disconnected. The signal that is sent on the line is provisioned + in the media gateway since it may vary from country to country. + In North America, this signal is an open switch interval which + results in a Loop Current Feed Open Signal (LCFO) being applied to + the line (refer to GR-506-CORE [7], see also See GR-505-CORE [6], + Section 4.5.2.1). The default time-out value for this signal is + 900 ms. + + Off-hook Warning Tone (ot): + Off-hook warning tone, also known as receiver Off-Hook Tone (ROH + Tone). This is the irritating noise a telephone makes when it is + not hung up correctly. In North America, ROH Tone is generated by + combining four tones at frequencies of 1400 Hertz, 2060 Hertz, + 2450 Hertz and 2600 Hertz, at a cadence of 0.1 second on, 0.1 + second off, then repeating. GR-506-CORE [7], Section 17.2.8 + contains details about required power levels. It is considered an + error to try and play off-hook warning tone on a phone that is + on-hook, and an error MUST consequently be returned when such + attempts are made (error code 402 - phone on-hook). + + Prompt Tone (p): + The definition of the prompt tone and its use may be found in + requirement GR-220 [20]. The tone in GR-220 (requirement "R3-170" + or GR-220) is a 300 ms burst of a 400 Hz tone. + + Ringing (rg): + See GR-506-CORE [7], Section 14. The provisioning process may + define the ringing cadence. The ringing signal may be + parameterized with the signal parameter "rep" which specifies the + maximum number of ringing cycles (repetitions) to apply. The + value for "rep" is specified in decimal and can have any value + from 1 to 255. The following will apply the ringing signal for up + to 6 ringing cycles: + + S: l/rg(rep=6) + + If the "rep" parameter is specified, the signal times-out when the + number of repetitions are completed (i.e., an operation complete + event can be requested and will occur at the end of the + timeout/number of rings). + + If the "rep" parameter is supplied, then any timeout ("to") value + that is included will be ignored, i.e.: + + S: l/rg(rep=6,to=12000) + + + + +Foster & Andreasen Informational [Page 28] + +RFC 3660 Basic MGCP Packages December 2003 + + + will be treated the same as the previous example where the + parameter "to=12000" was not included. Of course, if the "to" + parameter is included without the "rep", it will be acted upon + i.e.: + + S: l/rg(to=12000) + + will ring for 12 seconds. + + It is considered an error to try and ring a phone that is off-hook + and an error MUST consequently be returned when such attempts are + made (error code 401 - phone off-hook). + + Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7): + See GR-506-CORE [7], Section 14. Default values for r1 to r5 are + as defined for distinctive ringing pattern 1 to 5 in GR-506-CORE + [7]. The default values for r0, r6 and r7 are normal ringing + (i.e., the same cadence "rg"). The provisioning process may + define the ringing cadence for each of these signals. The + distinctive ringing signals may be parameterized with the signal + parameter "rep" which specifies the maximum number of ringing + cycles (repetitions) to apply. The value for "rep" is specified + in decimal and can have any value from 1 to 255. + + The following will apply the ringing signal for up to 6 ringing + cycles: + + S: l/r1(rep=6) + + If the "rep" parameter is specified, the signal times-out when the + number of repetitions are completed (i.e., an operation complete + event can be requested and will occur at the end of the + timeout/number of rings) + + If the "rep" parameter is supplied, then any timeout ("to") value + that is included will be ignored, i.e.: + + S: l/r1(rep=6,to=12000) + + will be treated the same as the previous example where the + parameter "to=12000" was not included. Of course, if the "to" + parameter is included without the "rep", it will be acted upon + i.e.: + + S: l/r1(to=12000) + + will ring for 12 seconds. + + + + +Foster & Andreasen Informational [Page 29] + +RFC 3660 Basic MGCP Packages December 2003 + + + It is considered an error to try and ring a phone that is off-hook + and an error MUST consequently be returned when such attempts are + made (error code 401 - phone off-hook). + + Reorder Tone (ro): + This maps to congestion tone in the ITU-T E.182 [10] + specification. In North America, reorder tone is a combination of + two AC tones with frequencies of 480 and 620 Hertz, and levels of + -24 dBm each, to give a combined level of -21 dBm. The cadence + for reorder tone is 0.25 seconds on, followed by 0.25 seconds off, + repeating continuously. + + Ringsplash (rs): + Also known as "Reminder ring", this tone is a burst of ringing + that may be applied to the physical forwarding line (when idle) to + indicate that a call has been forwarded and to remind the user + that a Call Forward sub-feature is active. In the US, it is + defined to be a 0.5(-0,+0.1) second burst of power ringing (see + [11]). + + Distinctive Tone Pattern (s(###)): + This is used to signal or detect a tone pattern defined by the + parameter where the parameter may have a value from 0 to 999. + When specified as an event, the parameter MUST be included. The + parameter will also be included when the event is reported. This + event (the definition of tones associated with each parameter + value) requires special provisioning in the Call Agent and gateway + to insure interoperability. This signal is included here to + maintain compatibility with the previous version of this package. + + Special Information Tone(sit(#)): + As described in ITU-T E.180 [8], the special information tone + consists of a tone period in which 3 tones are produced, followed + by a silent period of 1 second (total TO period of approximately 2 + seconds). It MAY be parameterized with a parameter value from 1 + to 7, with the following meaning as defined in SR-2275, section + 6.21.2 [5]: + + ------------------------------------------- + | sit(1) | RO' | reorder SIT, intra-LATA | + | sit(2) | RO" | reorder SIT, inter-LATA | + | sit(3) | NC' | no circuit SIT, intra-LATA | + | sit(4) | NC" | no circuit SIT, inter-LATA | + | sit(5) | IC | intercept SIT | + | sit(6) | VC | vacant code SIT | + | sit(7) | IO | ineffective other SIT | + ------------------------------------------- + + + + +Foster & Andreasen Informational [Page 30] + +RFC 3660 Basic MGCP Packages December 2003 + + + If the parameter is left out, the NC' SIT tone that corresponds to + the signal "L/sit(3)" is assumed. + + Other countries may have one or more special information tones + with country specific definitions (refer to ITU-T E.180 supp. 2 + [9]). In this case, special information tone 1 as defined in [9] + is sit(1), special information tone 2 is sit(2) etc. + + Stutter Dial Tone (sl): + Stutter Dial Tone (also called Recall Dial Tone in GR-506-CORE [7] + and "special dial tone" in ITU-T E.182 [10]) is used to confirm + some action and request additional input from the user. An + example application is to cancel call-waiting, prior to entering a + destination address. + + The stutter dial tone signal may be parameterized with the signal + parameter "del", which will specify a delay in milliseconds to + apply between the confirmation tone and the dial tone. The + parameter can have any value from 0 to 10000 ms, rounded to the + nearest non-zero value divisible by 100 (i.e., tenth of a second). + The following will apply stutter dial tone with a delay of 1.5 + seconds between the confirmation tone and the dial tone: + + S: l/sl(del=1500) + + It is considered an error to try and play stutter dial tone on a + phone that is on-hook and an error MUST consequently be returned + when such attempts are made (error code 402 - phone on-hook). + + Alerting Tone (v): + A 440 Hz Tone of a 2 second duration, followed by a 1/2 second of + tone every 10 seconds. This event is included for backwards + compatibility with the previous version of the package. + + Visual Message Waiting Indicator (vmwi): + The transmission of the VMWI messages will conform to the + requirements in [13] and the CPE guidelines in [12]. Refer also + to section 6.6 of GR-30-CORE [14]. VMWI messages will only be + sent from the gateway to the attached equipment when the line is + idle. If new messages arrive while the line is busy, the VMWI + indicator message will be delayed until the line goes back to the + idle state. After the gateway restarts, the state of the signal + will be "off", and hence the Call Agent MUST refresh the CPE's + visual indicator if it is supposed to be "on". + + + + + + + +Foster & Andreasen Informational [Page 31] + +RFC 3660 Basic MGCP Packages December 2003 + + + Alternative Call Waiting Tones (wt, wt1, .., wt4): + Refer to ITU-T E.180 [8]. For North American tone definitions, + refer to GR-506-CORE [7], Section 14.2. "wt" and "wt1" are both + aliases for the default Call Waiting tone, which in North America, + is a 440-Hz tone applied for 300 plus or minus 50 ms. The tone is + then repeated once after 10 seconds. + + These signals are timeout signals with a default timeout value of + 12 seconds, which allows the tone to be played twice with a single + request (refer to GR-571-CORE [16]). However, there are cases + (Requirement R3-73 of GR-575-CORE [18]), in which only a single + tone is required. In that case, the Call Agent may make the + request with a shorter timeout period to eliminate the second tone + (e.g., "S: wt(to=2000)" - which stops the signal after 2 seconds + so that the second tone will not occur). + + Signals wt2, wt3 and wt4 are alternates that are used for + distinctive call-waiting tone patterns (refer to GR-506-CORE, + Section 14.2 [7]. It is considered an error to try and apply + call-waiting tone on a phone that is on-hook and an error MUST + consequently be returned when such attempts are made (error code + 402 - phone on-hook). + + Recorder Warning Tone(y): + Refer to ITU-T E.180 [8] - also Bellcore document SR-2275 [5] + section 6.20. When recording equipment is used, this tone is + connected to the line to inform the distant party that the + conversation is being recorded - typical value used is a 1400 Hz + Tone of a 0.5 second duration every 15 seconds. + + Calling Card Service Tone(z): + This tone is used to inform the customer that credit card + information must be keyed in. Typically, it consists of 60 ms of + 941 + 1477 Hz (the DTMF #digit) and 940 ms of 350 + 440 Hz (dial + tone), decaying exponentially with a time constant of 200 ms. + Refer to Bellcore document SR-2275 [5], section 6.20. + + + + + + + + + + + + + + + +Foster & Andreasen Informational [Page 32] + +RFC 3660 Basic MGCP Packages December 2003 + + +2.5. Handset Emulation Package + + Package Name: H + Version: 1 + + ---------------------------------------------------------------- + |Symbol | Definition | R | S Duration | + |----------------------------------------------------------------| + |adsi(string) | ADSI Display | x | BR | + |aw | Answer Tone | x | OO | + |bz | Busy Tone | x | TO 30 sec. | + |ci(ti,nu,na) | Caller-id | x | BR | + |dl | Dial Tone | x | TO 16 sec. | + |e | Error Tone | x | TO 2 sec. | + |hd | Off-hook Transition | S | BR | + |hu | On-hook Transition | S | BR | + |hf | Flash Hook | x | BR | + |ht | Tone On Hold | x | OO | + |lsa | Line Side Answer Sup. | x | OO | + |mwi | Message Waiting Ind. | x | TO 16 sec. | + |nbz | Network Busy | x | TO infinite | + |oc | Operation Complete | x | | + |ot | Off-hook Warning Tone | x | TO infinite | + |of | Operation Failure | x | | + |osi | Network Disconnect | x | TO 900 ms | + |p | Prompt Tone | x | BR | + |rg | Ringing | x | TO 180 sec. | + |r0, r1, r2, | Distinctive Ringing | x | TO 180 sec. | + |r3, r4, r5, | | | | + |r6 or r7 | | | | + |ro | Reorder Tone | x | TO 30 sec. | + |rs | Ringsplash | x | BR | + |s(###) | Distinctive Tone Pattern | x | BR | + |sit(#) | Sit Tone | x | TO 2 sec. | + |sl | Stutter Dial Tone | x | TO 16 sec. | + |v | Alerting Tone | x | OO | + |vmwi | Vis. Message Waiting Ind.| x | OO | + |wt | Call Waiting tone | x | TO 12 sec. | + |wt1, wt2, | Alternative Call | x | TO 12 sec | + |wt3, wt4 | Waiting Tones | | (see notes) | + |y | Recorder Warning Tone | x | TO infinite | + |z | Calling Card Serv. Tone | x | BR | + ---------------------------------------------------------------- + + The handset emulation package is similar to the line package except + that events such as "off-hook" can be signaled as well as detected. + + + + + +Foster & Andreasen Informational [Page 33] + +RFC 3660 Basic MGCP Packages December 2003 + + + Changes from the original package - are the same changes as were made + for the line package, plus "hu" and "hd" signal types were changed + from OO to BR. + + Event definitions are the same as for the line package with the + following exceptions: + + ASDI: + When requested as an event by the Call Agent, the event is not + parameterized. However, the parameter is included when the event + is reported. + + Caller-id: + When requested as an event by the Call Agent, the event MUST not + be parameterized. However, parameters are included when the event + is reported i.e.: + + O: l/ci(09/14/17/26,"555 1212","John Doe") + + Line Side Answer Supervision: + When requested as an event by the Call Agent, it indicates when + the reverse loop current feed (RLCF) was turned on and off. The + event is not parameterized when it is requested. However, a + parameter is included when it is reported i.e.: + + O: l/lsa(+) to indicate RLCF was turned on + O: l/lsa(-) to indicate RLCF was turned off + + Ringing (rg): + When requested as an event, the Call Agent may optionally include + the rep parameter indicating a request to report after some number + of rings e.g.: + + RQNT 1234 aaln/1@rgw2.example.net + X: AB123FE0 + R: h/rg(N)(rep=3) + + The resulting notification after the number of rings is detected + includes the parameter again: + + NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 + X: AB123FE0 + O: h/rg(rep=3) + + If the parameter is not included in the request, it is also not + included in the report. In that case, the event is reported as + soon as ringing is detected. + + + + +Foster & Andreasen Informational [Page 34] + +RFC 3660 Basic MGCP Packages December 2003 + + + Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7): + As with the "rg" event, if the "rep" parameter is included when + one of these is requested as an event, it is also reported. If it + is not requested with the parameter, then the parameter is also + not included in the report. In that case, the event is reported + as soon as ringing with the requested cadence is detected. + + Stutter Dial Tone (sl): + Stutter Dial Tone MUST not be parameterized when requested as an + event. However, the "del" parameter is reported. + + RQNT 1234 aaln/1@rgw2.example.net + X: AB123FE0 + R: h/sl + + The resulting notification indicates the delay between the + confirmation tone and the dial tone: + + NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 + X: AB123FE0 + O: h/sl(del=1500) + + As with the signal, the report indicates the delay rounded to the + nearest 100 ms. + + Visual Message Waiting: + When requested as an event by the Call Agent, it indicates when + the visual message waiting indicator was turned on and off. The + event is not parameterized when it is requested. However, a + parameter is included when it is reported i.e.: + + O: l/vmwi(+) to indicate message waiting turned on + O: l/vmwi(-) to indicate message waiting turned off + + Note that: + + * All TO signals in the handset package can include a "to" + parameter when requested as a signal. + + * However, requests to be notified about these events MUST NOT + include the "to" parameter, i.e., the "to" parameter is not + valid in RequestedEvents. + + + + + + + + + +Foster & Andreasen Informational [Page 35] + +RFC 3660 Basic MGCP Packages December 2003 + + +2.6. Supplementary Services Tone Package + + Package Name: SST + Version: 0 + + --------------------------------------------------------------- + |Symbol | Definition | R | S Duration | + |---------------------------------------------------------------| + |cd | Conference Depart | | BR | + |cj | Conference Join | | BR | + |cm | Comfort Tone | | TO infinite | + |cw | Caller Waiting Tone | | TO 30 sec. | + |ht | On Hold Tone | | OO | + |ni | Negative Indication | | TO infinite | + |nu | Number Unobtainable | | TO infinite | + |oc | Operation Complete | x | | + |of | Operation Failure | x | | + |pr | Pay Phone Recognition | | BR | + |pt | Pay Tone | | BR | + ---------------------------------------------------------------- + + Note that default time-out values may be over-ridden by the Call + Agent for any Time-Out signal defined in this package by a "to" + signal parameter. Refer to section 2 of this document, as well as + [1] for details. + + The events in this package are defined as follows: + + Conference Depart(cd): + Tone used to indicate that a participant has left a conference + call. The tone characteristics are left to the specific gateway + implementation. + + Conference Join (cj): + Tone used to indicate that a party has joined a conference call. + The tone characteristics are left to the specific gateway + implementation. + + Comfort Tone (cm): + Comfort Tone is used to indicate that the call is being processed + and that the caller should wait. Refer to ITU-T E.182 [10]. + + Caller Waiting Tone (cw): + Not to be confused with a call-waiting tone, this is a tone + advising a caller that a called station, though busy, has a call + waiting service active. Refer to ITU-T E.182 [10]. + + + + + +Foster & Andreasen Informational [Page 36] + +RFC 3660 Basic MGCP Packages December 2003 + + + Tone on-hold (ht): + A tone used to reassure a calling subscriber who has been placed + on "hold". Refer to ITU-T E.182 [10]. + + Negative Indication (ni): + A tone advising a subscriber that the request for service cannot + be accepted. Refer to ITU-T E.182 [10]. For North America, this + maps to the re-order tone (see GR-506-CORE [7], Section 17.2.7). + + Number Unobtainable Tone (nu): + Refer to ITU-T E.180, supplement 2 [9]. This is also referred to + as "vacant tone" and maps to a "re-order tone" in North America + (see GR-506-CORE [7], Section 17.2.7). + + Operation Complete (oc): + The standard definition of operation complete [1]. + + Operation Failure (of): + The standard definition of operation failure [1]. + + Pay Phone Recognition (pr): + A tone advising an operator that the endpoint is identified as a + payphone. Refer to ITU-T E.182 [10]. + + Pay Tone (pt): + A tone indicating that payment is required. Refer to ITU-T E.182 + [10]. + +2.7. Digit Map Extension + + Package Name: dm1 ("dm" followed by the number "1") + Version: 0 + Extension Digit Map Letters: P + + This package defines an Extension Digit Map Letter that is used to + override the shortest possible match behavior for a given entry in a + digit map (see [1]). The letter "P" (for partial match override), at + the end of a digit map entry, instructs the gateway to only consider + that entry a match if the current dial string does not partially + match another entry. For example, given the digit map + + ([3-7]11|123xxxxxxx|[1-7]xxxxxxP|8xxxP) + + and a current dial string of "1234567", we would not consider this a + match (as the rules in [1] would otherwise imply); however a current + dial string of "411" would be considered a match as usual. A current + dial string of "8234" would be considered a match since there is no + other partial match. + + + +Foster & Andreasen Informational [Page 37] + +RFC 3660 Basic MGCP Packages December 2003 + + + Note that the digit map letter "P" is not an event, but simply a + syntactic and semantic digit map extension. Thus, the "P" is not + included in the list of requested or observed events. + + Support for this package is strongly RECOMMENDED. + +2.8. Signal List Package + + Package Name: SL + Version: 0 + + --------------------------------------------------------- + | Symbol | Definition | R | S Duration | + |---------------------------------------------------------| + | oc | Operation Complete | x | | + | of | Operation Failure | x | | + | s(list) | Signal List | | TO variable | + --------------------------------------------------------- + + Operation Complete (oc): + This is the standard definition of operation complete from [1]. + + Operation Failure (of): + This is the standard definition of operation failure from [1]. + + Signal List(s(<list>)): + The <list> contains a comma-separated list of signals to be played + out. Each of the signals in <list> MUST be either of type BR or + type TO. Semantically, the signal list is still treated as a + single parameterized signal of type Time-Out though. The signals + in the list are played to completion one after the other in the + left to right order specified. The package for each signal in the + list must be specified. For example, to play out the DTMF digits + 123456: + + S: sl/s(d/1,d/2,d/3,d/4,d/5,d/6) + + This will result in the DTMF digits 1, 2, 3, 4, 5 and 6 being + played out in order. + + It is illegal to include an OO signal as one of the signals in the + list or to request recursive definitions (signal lists within + signal lists). If this or any other unsupported signal is + included, error code 538 (event/signal parameter error) MUST be + returned by the gateway. + + + + + + +Foster & Andreasen Informational [Page 38] + +RFC 3660 Basic MGCP Packages December 2003 + + + Note that as the gateway plays the ordered list of signals, if it + encounters a TO signal with an infinite timeout, it will continue + to play that signal until the Signal List signal is stopped (i.e., + other signals later in the list will never be played). + + If the operation complete ("oc") event is requested, it will be + detected once, when the last signal in the list has been played + out (regardless of whether there are any TO signals in the list). + The operation complete event will only report the signal list name + itself, i.e., without the parameters supplied as in: + + O: sl/oc(sl/s) + + Should any of the signals in the signal list result in an error, + an operation failure event for the Signal List signal MUST be + generated. Only the signal list name will be included, thus it is + not possible to determine which of the signals in the signal list + actually failed. + + Note that if an event occurs while the "SL/S" signal is playing, + the "SL/S" signal is stopped in the following manner: + + * If the signal in the list that was playing at the time the + event occurred is of type BR, then the BR signal will be + played to completion and no other signals in the list will + be played. + + * If the signal in the list that was playing at the time the + event occurred is of type TO, then the TO signal will stop + immediately and no other signals in the list will be played. + +2.9. Media Format Parameter Package + + Package Name: FM + Version: 0 + + This package provides support for the media format parameter Local + Connection Option (LCO). The media format parameter LCO is similar + to the "fmtp" attribute in SDP [15] and is applicable to all of the + same media formats that the corresponding SDP fmtp attribute could be + used with (i.e., media format parameters for any media format MIME + type). The media format parameter is encoded as the keyword "fmtp" + or "o-fmtp", followed by a colon and a quoted string beginning with + the media format name (MIME subtype only) followed by a space, + followed by the media format parameters associated with that media + format. For simplicity, we will use the terms "codec" and "media + + + + + +Foster & Andreasen Informational [Page 39] + +RFC 3660 Basic MGCP Packages December 2003 + + + format" interchangeably in the following. Multiple formats may be + indicated by either repeating the "fmtp" local connection option + multiple times, such as: + + L:a:codec1;codec2, fmtp:"codec1 formatX", fmtp:"codec2 formatY" + + or alternatively by having a single "fmtp" keyword followed by a + colon, and a semi-colon separated list of quoted strings for each + media format parameter, as in: + + L:a:codec1;codec2, fmtp:"codec1 formatX";"codec2 formatY" + + The two formats may be mixed. + + If it is possible for the same codec to be requested with and without + the special "fmtp" format, the following could result: + + L:a:codec1;codec1, fmtp:"codec1 formatX" + + However, it would not be clear if the fmtp parameter was to be + applied to the first or the second occurrence of the codec. The + problem with that is, that codec ordering is important (i.e., codecs + are listed in preferred order), and the above syntax does not provide + a way to indicate if "formatX" is preferred (i.e., associated with + the first "codec1") or not (i.e., associated with the second + "codec1"). In order to resolve this dilemma, when the same codec is + requested with multiple formats, the codec name in the "fmtp" format + string is followed by a colon and an <order>, where <order> is a + number from one to N for N occurrences of the same codec in the codec + list i.e.: + + L:a:codec1;codec1, fmtp:"codec1:2 formatX" + + indicates that "formatX" is associated with the second instance of + "codec1" in the "a:codec1;codec1" list. If an invalid instance + number is supplied (e.g., instance 3 where there are only two + instances), then error code 524 - inconsistency in local connection + options will be returned. + + Pre-pending "fmtp" with the string "o-" (i.e., "o-fmtp") indicates + that the format is optional. In that case, the gateway may decide + not to use the fmtp parameter specified, or only use it in part. + + If the "fmtp" in an LCO is not optional (i.e., does not have "o-" in + front of it), and the LCO value is either not recognized or not + supported, then the associated codec is considered "not supported". + + + + + +Foster & Andreasen Informational [Page 40] + +RFC 3660 Basic MGCP Packages December 2003 + + + When auditing capabilities, the "fmtp" local connection option MUST + be returned with a semi-colon separated list of supported formats + and/or multiple independent "fmtp" parameters as in: + + A: a:telephone-event, fmtp:"telephone-event 0-15,32-35",... + + A: a:PCMU;G729, fmtp:"PCMU foo";"PCMU bar", fmtp:"G729 foobar",... + + One example uses the media format parameter LCO in conjunction with + the media format "telephone-event", as defined in RFC 2833 [33]. If + the media format "telephone-event" is used without the "fmtp" media + format parameter, the DTMF digits (telephone events 0-15 from RFC + 2833 [33]) are assumed - such practice is however discouraged. On + the other hand, the media format parameter LCO MAY be used to specify + the exact set of events that are being requested via RFC 2833 [33]. + Example: + + L: a:PCMU;telephone-event,fmtp:"telephone-event 16" + + indicates that if telephone events are supported at all, then this + request is specifically for event 16. + + In another case, the Call Agent may indicate that some format + parameters are "required", while others are optional. In the example + below, telephone events 0-15 are a "must", while telephone events 16, + 70 and 71 are optional. + + L: a:PCMU;telephone-event, o-fmtp:"telephone-event 16,70,71", + fmtp:"telephone-event 0-15" + + If the gateway cannot support telephone events 0-15, it MUST NOT + include the "telephone-event" media format in the SDP in its + response. On the other hand, if it can support those telephone + events, it SHOULD indicate support for those events, as well as any + of the events 16, 70 and 71 that it supports. + + If a request is made to audit the capabilities of an endpoint, and + the endpoint supports the "telephone event" media format with events + "0-16", then the audit would include the following: + + A: a:telephone-event, fmtp: "telephone-event 0-16" + + Another example is the use of redundancy with RFC 2198 [32]. Again, + the format of the fmtp string is similar to that used in the SDP + except that the literal string ("red" in this case) is used rather + than the payload type: + + L: a:G729;pcmu;red,fmtp:"red pcmu/g729" + + + +Foster & Andreasen Informational [Page 41] + +RFC 3660 Basic MGCP Packages December 2003 + + + The corresponding media description in the SDP as part of the + connection request acknowledgment might look like: + + m=audio 12345 RTP/AVP 98 18 0 + a=rtpmap:98 red/8000/1 + a=fmtp:98 0/18 + + If we combine both telephone events and redundancy, an example local + connection option might look as follows (carriage return added for + formatting reasons here): + + L: a:G729;pcmu;red;telephone-event,fmtp:"red pcmu/g729", + fmtp: "telephone-event 16" + + Note that we again specify the literal string for the encoding method + rather than its payload type. This is a general principle that + should be used with this LocalConnectionOption. + + The corresponding SDP might appear as follows: + + m=audio 12345 RTP/AVP 97 98 18 0 + a=rtpmap:97 red/8000/1 + a=fmtp:97 0/18 + a=rtpmap:98 telephone event + a=fmtp:98 16 + + Note that the fmtp LCO may be used in any situation where the + corresponding SDP attribute may be used. An example of a local + connection option that involves a media type other than audio and a + "foobar" fmtp parameter: + + L: a:image/tiff, fmtp:"tiff foobar" + + Note that normally local connection options that are associated with + a package should have the package prefix included as per the package + extension rules in [1]. The "fmtp" and "o-fmtp" LCO in the "FM" + package are an exception. The package prefix is not included in the + case of the "fmtp" and "o-fmtp" local connection options because they + were created before the extension rules in [1] were defined. + + These two LocalConnectionOptions have been registered with IANA. + + + + + + + + + + +Foster & Andreasen Informational [Page 42] + +RFC 3660 Basic MGCP Packages December 2003 + + +2.10. RTP Package + + Package Name: R + Version: 1 + + ------------------------------------------------------------- + | Symbol | Definition | R | S Duration | + |-------------------------------------------------------------| + | co1 | Continuity Tone (single | C | TO,C 3 sec. | + | | or return tone) | | | + | co2 | Continuity Test (go tone, | C | TO,C 3 sec. | + | | in dual tone procedures) | | | + | iu(..) | ICMP Unreachable | C | | + | | Received | | | + | ji(..) | Jitter Buffer Size Changed | C | | + | ma | Media Start | C | | + | oc | Operation Complete | x | | + | of | Operation Failure | x | | + | pl(..) | Packet Loss Exceeded | C | | + | qa | Quality Alert | C | | + | rto(..) | RTP/RTCP Timeout | C | | + | sr | Sampling Rate Changed | C | | + | uc | Used Codec Changed | C | | + ------------------------------------------------------------- + + Changes in event types: "co1" and "co2" signals changed from OO to + TO. + + New events added to this package from the previously unversioned + package: "iu", "rto", "ma". + + Note that default time-out values may be over-ridden by the Call + Agent for any Time-Out signal defined in this package by a "to" + signal parameter. Refer to section 2 of this document, as well as + [1] for details. + + The events in this package all refer to media streams (connections), + i.e., they cannot be detected on an endpoint. Furthermore, with the + exception of the "iu" event, which is defined for any type of media, + all other events in this package are defined for RTP media streams + only (i.e., if they are used on connections that do not use RTP, the + behavior is not defined). + + Signals requested (e.g., "co1" and "co2") must indicate the + connection ID (e.g., "S: r/co1@connectionID"). An event may be + requested for all existing connections using the "*" wildcard for the + connectionID as described in [1]. + + + + +Foster & Andreasen Informational [Page 43] + +RFC 3660 Basic MGCP Packages December 2003 + + + Example: + + R: r/uc@* (request to detect uc on all connections) or + + R: r/uc@connectionID (request to detect uc only on a specific + connection) + + An event detected on a connection will include the connectionID, + e.g.: + + O: r/uc@connectionID(15) + + Continuity tones (co1 and co2): + These are the same as the events defined in the Trunk package, + except in this case, they are only played over a network + connection and the connectionID MUST be supplied (e.g., "s: + r/co1@connectionID"). They can be used in conjunction with the + Network LoopBack (netwloop) or Network Continuity Test (netwtest) + modes to test the continuity of an RTP circuit. However, in the + case of testing IP continuity, a one-tone test is sufficient i.e., + generating and detecting "co1" at one end, with connection mode in + network loopback mode at the other end. Note that the test can + also be done using telephone events rather than tones, i.e., event + 167 in RFC 2833 [33] corresponds to "co1". In this case, + connection requests are made with local connection options such + as: + + L: a:PCMU;telephone-event,fmtp:"telephone-event 167" + + in order to request support for telephone event 167. If both ends + support the event, then the network loopback proceeds as usual, + except that telephone events corresponding to the co1 tone are + sent, as opposed to the co1 tone itself. + + ICMP Unreachable Received (iu): + This event indicates that some number of ICMP unreachable packets + [19] was received for this connection since an RQNT was received + requesting this event. This notification indicates that packets + that were sent by the gateway on this connection either did not + arrive at their destination or were not accepted (e.g., the port + was closed). When this event is requested, a single parameter + with a decimal number from 1 to 255 may be included to indicate + the number of ICMP un-reachable packets that must occur before the + event is notified. If no parameter is supplied, with the request + then a default value of 3 is assumed. This is a one-shot event in + that once the event occurs, a further request is required in order + to re-initiate counting. + + + + +Foster & Andreasen Informational [Page 44] + +RFC 3660 Basic MGCP Packages December 2003 + + + The observed event is parameterized with two parameters: + + * The first parameter is the number of ICMP unreachable + packets received (i.e., the same value that was included in + the request - or the value 3, if the requested event was not + parameterized) + + * The second parameter is the error code indicated in the ICMP + unreachable packet, e.g.: + + 0 = net unreachable; + + 1 = host unreachable; + + 2 = protocol unreachable; + + 3 = port unreachable; + + 4 = fragmentation needed and DF set; + + 5 = source route failed. + + etc. + + An example of a request might be as follows: + + RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 + X: 0123456789B0 + R: r/iu@364823(N)(5) + + In this case, a notify will occur if 5 ICMP port unreachable + packets are received as a result of RTP and/or RTCP packets being + sent from this gateway on the connection with connection ID + 364823. + + The resulting NTFY with observed events might be as follows: + + NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 + X: 0123456789B0 + O: r/iu@364823(5,3) + + The first parameter indicates 5 ICMP unreachable packets were + received since the RQNT with this request was sent. The second + parameter ("3") specifies the reason, which in this case, is "port + unreachable". + + + + + + +Foster & Andreasen Informational [Page 45] + +RFC 3660 Basic MGCP Packages December 2003 + + + Jitter Buffer Size Changed (ji): + This event is only included here to maintain compatibility with + the previous version of this package. This event is used to + indicate that the gateway has made an adjustment to the depth of + the jitter buffer. The syntax for requesting notification is + "ji", which tells the media gateway that the controller wants + notification of any jitter buffer size changes. The syntax for + notification from the media gateway to the controller is + "JI(####)", where the #### is a decimal number from 1 to 65536, + indicating the new size of the jitter buffer in milliseconds. + + Media Start (ma): + The media start event occurs on a connection when the first valid + RTP media packet is received on the connection. This event can be + used to synchronize a local signal, e.g., ringback, with the + arrival of media from the other party. + + The event is detected on a connection. If no connection is + specified, the event applies to all connections for the endpoint, + regardless of when the connections are created (i.e., if a + connection is not specified, the event will occur when the first + valid RTP packet arrives on any one of the connections on that + endpoint). + + Operation complete (oc): + This is the standard definition of operation complete [1]. + + Operation failure (of): + This is the standard definition of operation failure [1]. + + Packet Loss Exceeded (pl): + Packet loss rate exceeds the threshold of the specified decimal + number (with a range of 1 to 100,000) of packets per 100,000 + packets, where the packet loss number is indicated in parenthesis. + For example, PL(10) is a drop rate of 10 in 100,000 packets. This + event is requested with a parameter indicating at what packet loss + rate the Call Agent wishes to be reported. If the packet loss + exceeds that value, the event is reported with that same + parameter. The event is only reported once when the packet loss + threshold is exceeded. Once reported, a following request will + re-initiate packet loss measurements and report when the threshold + is exceeded again. + + Quality alert (qa): + The packet loss rate or the combination of delay and jitter + exceeding a quality threshold. The quality thresholds for delay, + jitter and packet loss rate are provisioned values. + + + + +Foster & Andreasen Informational [Page 46] + +RFC 3660 Basic MGCP Packages December 2003 + + + RTP/RTCP Timeout (rto(<timeout>,st=<start-time>)): + This event indicates that neither RTP nor RTCP packets have been + received on this connection for a period of time equal to the + <timeout> value (in seconds). The timeout value can be supplied + as a decimal number from 1 to 65535 in the parameter when the + request is made. The <timeout> parameter will be supplied in + ObservedEvents when the event is reported - it then simply repeats + the value used. If an RTP or RTCP packet is received before the + timer expires, then the timer is reset and re-started. The event + will only be generated if the timer expires without an RTP or RTCP + packet arriving on the specified connection during the specified + period of time. Note that if the event is requested without the + <timeout> parameter, then a default timeout of 60 seconds is + assumed. The <timeout> value will still be reported in + ObservedEvents, even if no timeout value was indicated in the + request (the default value will be indicated in that case). This + is a one-shot event in that once the event occurs, a further + request is required in order to re-initialize the timer. + + Another optional <start-time> parameter may also be included. + This is used to indicate when the timer starts. It can have one + of the following values: + + * "im" for immediate i.e., the timer starts as soon as the + request is received. This is the default. + + * "ra" to indicate that the timer should start only after an + RTCP packet has been received from the other end (i.e., the + timer will be initiated when the first RTCP packet is + received after the request is made). Note that in the case + where the other end does not support RTCP, the timer will + never be initiated. + + Note that either the <timeout> or <start-time> may be included in + the request, but only the <timeout> value is included in the + report. + + An example of a request might be as follows: + + RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 + X: 0123456789B0 + R: r/rto@364823(N)(120,st=im) + + In this case, a notify will occur if there is a period of time + when no RTP or RTCP packets have been received on connection + 364823 for 120 seconds. + + + + + +Foster & Andreasen Informational [Page 47] + +RFC 3660 Basic MGCP Packages December 2003 + + + The resulting NTFY with observed events would be as follows: + + NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 + X: 0123456789B0 + O: r/rto@364823(120) + + Sampling Rate Changed (sr): + This event is only included here to maintain compatibility with + the previous version of this package. This event indicates that + the packetization period changed to some decimal number in + milliseconds enclosed in parenthesis, as in SR(20). + + Used Codec Changed (uc): + This event is only included here to maintain compatibility with + the previous version of this package. This event is requested + without a parameter, but when reported, the hexadecimal payload + type is enclosed in parenthesis, as in UC(8), to indicate the + codec was changed to PCM A-law. Codec Numbers are specified in + RFC 3551 [26], or in a new definition of the audio profiles for + RTP that replaces this RFC. + +2.11. Resource Reservation Package + + Package Name: RES + Version: 0 + +2.11.1. Description + + The "RES" package provides local connection option support for + resource reservations as well as an event to indicate reservation + loss. + + A number of LocalConnectionOption parameters are used in doing + resource reservations: "reservation request", "reservation + direction", "reservation confirmation" and "resource sharing". + + Reservation Request LocalConnectionOption: The gateways can be + instructed to perform a reservation on a given connection using RSVP. + When a reservation is needed, the Call Agent will specify the + reservation profile that should be used, which is either "controlled + load" or "guaranteed service". The absence of reservation can be + indicated by asking for the "best effort" service, which is the + default value for this parameter. + + Whether or not RSVP will be done is dependent on whether the + reservation request LocalConnectionOption parameter has been included + in a connection request for this connection (with either "controlled + load" or "guaranteed service" indicated). If a modify connection + + + +Foster & Andreasen Informational [Page 48] + +RFC 3660 Basic MGCP Packages December 2003 + + + (MDCX) request requires a change in the reservation and the + "reservation request" parameter is not included in the + LocalConnectionOptions, but was included in the + LocalConnectionOptions for a previous connection request for that + connection, then the "reservation request" value defaults to its + previously saved value for that connection. If a modify connection + (MDCX) request explicitly contains a "reservation request", + indicating a request for "best effort" for a connection that has an + existing reservation, the existing reservation will be torn down. + + Reservation Direction LocalConnectionOption: + When reservation has been requested on a connection, the gateway + will examine the reservation direction LocalConnectionOption + parameter to determine the direction that the reservations require + and do the following: + + * Start emitting RSVP "PATH" messages if the reservation + direction LocalConnectionOptions parameter specified "send- + only" or "send-receive". + + * Start emitting RSVP "RESV" messages as soon as it receives + "PATH" messages if the reservation direction parameter + specified "receive-only" or "send-receive". + + If an RSVP reservation is requested, but the reservation direction + LocalConnectionOption parameter is missing, the reservation + direction defaults to the previously saved value of the + reservation direction parameter for that connection. If there was + no previous reservation direction parameter for that connection, + the value is deduced from the connection mode. That is: + + * Start emitting RSVP "PATH" messages if the connection is in + "send-only", "send-receive", "conference", "network loop + back" or "network continuity test" mode (if a remote + connection descriptor has been received). + + * Start emitting RSVP "RESV" messages as soon as it receives + "PATH" messages if the connection is in "receive-only", + "send-receive", "conference", "network loop back" or + "network continuity test" mode. + + Reservation Confirmation LocalConnectionOption: + Another LocalConnectionOption parameter for RSVP reservations is + the reservation confirmation parameter, which determines what the + resource reservation pre-condition (see [1]) is for acknowledging + a successful connection request: + + + + + +Foster & Andreasen Informational [Page 49] + +RFC 3660 Basic MGCP Packages December 2003 + + + * If the reservation confirmation parameter is set to "none", + the gateway will "Ack" the connection request without + waiting for reservation completion. This is the default + behavior. + + * If the "reservation confirmation" parameter is set to + "send-only", the gateway will "Ack" when the PATH message + has been sent and the corresponding RESV is received to + indicate successful reservation in the send direction. + + * If the "reservation confirmation" parameter is set to + "receive-only", the gateway will "Ack" when reservation + confirm for a reservation has been received. + + * If the reservation confirmation parameter is set to "send- + receive", the gateway will "Ack" only after the PATH message + has been sent and the corresponding RESV has been received + for send direction, and reservation confirm has been + received for the receive direction. + + Note that: + + Values "receive-only" and "send-receive" are triggers for the + gateway to request reservation confirm (RESVCONF) when it sends + out the RESV. + + Pre-conditions SHOULD only be added for the direction(s) for which + resource reservations have been requested. If a direction is + added as a pre-condition, and that direction was not requested in + the resource reservation, the direction MUST simply be ignored as + a pre-condition. + + In this approach, resource reservation success is the pre- + condition to final acknowledgement of the connection request. If + the reservation fails, the connection request also fails (error + code 404 - insufficient bandwidth) - as will any other part of the + transaction, e.g., a notification request included as part of the + connection request. A typical example of this would be a request + to ring the phone and look for off-hook, included with the + connection request. If the reservation fails, the phone will not + ring. Similarly, if the phone is already off-hook, the command + fails and there will be no resource reservation. + + A provisional response SHOULD be provided if confirmation is + expected to occur outside the normal retry timers and in fact a + provisional response MUST be provided if the reservation + confirmation parameter has value "send-receive" (without a + provisional response, SDP information cannot be returned until the + + + +Foster & Andreasen Informational [Page 50] + +RFC 3660 Basic MGCP Packages December 2003 + + + final "Ack" which will not occur until the reservation is + complete. This can result in a deadlock since the SDP information + typically needs to be passed to the other end in order for it to + initiate the RSVP PATH message in the other direction). The SDP + information and connectionID MUST be included in both the + provisional response and the final response. Note that in order + to ensure rapid detection of a lost final response, final + responses issued after provisional responses for a transaction + SHALL be acknowledged, i.e., they SHALL include an empty + "ResponseAck" parameter in the final response (see [1]). + + If the transaction time is outside the expected bounds (time + T-HIST - see the section on provisional responses in [1]), error + code 406 (transaction timeout) SHOULD be returned. + + Also note that if the reservation confirmation parameter is + omitted, the value of the reservation confirmation parameter + defaults to its previously saved value. If there is no previously + saved value for the reservation confirmation parameter, or the + reservation confirmation parameter has the value "none", then + successful resource reservation is not a pre-condition to + providing an acknowledgement to the connection request (i.e., the + gateway can "Ack" right away without waiting for the reservation + to complete and a provisional response will not be necessary). + + Resource Sharing LocalConnectionOption: + It may be possible to share network resources across multiple + connections. An example is a call-waiting scenario, where only + one connection will ever be active at a time. In a 3-way calling + scenario with a similar set of connections, sharing is not + possible. Only the Call Agent knows what may be possible, + depending on the feature that is being invoked. + + In order to allow the Call Agent to indicate that sharing is + possible, a resource sharing LocalConnectionOption parameter is + introduced. This parameter can have one of the following values: + + * A value "$" can be specified where $ refers to "this + connection". This value is used when doing a create + connection and indicates the intent to share resources with + this connection. + + * A connection ID can be specified which indicates that this + is a request to share resources with the connection having + this connection ID (allowing multiple connections to share + resources with the connection indicated). + + + + + +Foster & Andreasen Informational [Page 51] + +RFC 3660 Basic MGCP Packages December 2003 + + + * The value can be empty, which indicates a request to no + longer share the resources of this connection with other + connections. + + In the case of a CRCX, the default value for the resource sharing + local connection option is empty, and for an MDCX, the default + value is its current value. + + The RSVP filters will be deduced from the characteristics of the + connection. The RSVP resource profiles will be deduced from the + connection's bandwidth and packetization period. + + Note that if RSVP is used with PacketCable Dynamic Quality of Service + [35], then the parameters in NCS [36] would be used instead of the + reservation direction, confirmation and reservation sharing + parameters described here. + +2.11.2. Parameter Encoding + + The Local Connection Options for the "RES" package consist of the + following: + + * The resource reservation parameter, encoded as the keyword "r", + followed by a colon and the value "g" (guaranteed service), + "cl" (controlled load) or "be" (best effort). + + * The reservation direction parameter, encoded as the keyword + "r-dir" followed by a colon and the value "sendonly", + "recvonly" or "sendrecv". + + * The reservation confirmation parameter, encoded as the keyword + "r-cnf" followed by a colon and the value "none", "sendonly", + "recvonly" or "sendrecv". + + * The resource sharing parameter, encoded as the keyword "r-sh" + followed by a colon and either: + + * The wild-card character "$" indicating this connection, + indicating future plans to share resources with this + connection, or + + * A connection ID, indicating a request to share resources + with the connection having the specified connection ID + (and all other connections sharing resources with that + connection), or + + + + + + +Foster & Andreasen Informational [Page 52] + +RFC 3660 Basic MGCP Packages December 2003 + + + * An empty value (i.e., "r-sh:" with no value indicated), + indicating a request to no longer share the resources of + this connection with other connections + + Note that normally local connection options that are associated with + a package have the package prefix included as per the package + extension rules in [1]. The local connection options in the "RES" + package are exceptions. The package prefix is not included in the + case of the "RES" package because it was created before the extension + rules in [1] were defined. + +2.11.3. Events + + The following events are included as part of the resource reservation + package: + + ------------------------------------------------------ + | Symbol | Definition | R | S Duration | + |------------------------------------------------------| + | re | Resource Error | C | | + | rl | Resource Lost | C | | + ------------------------------------------------------ + + Resource Error (re): + This is an indication that an error in the resource reservation + occurred during the life of the connection. This event is not + requested with a parameter, but is reported with a parameter (see + possible values below). This event may or may not indicate the + permanent loss of the reservation (i.e., any error associated with + the reservation whether permanent or temporary will be reported). + If requested on an endpoint (without specifying the connection + ID), the request refers to all present and future connections on + that endpoint. When reported, the connectionID is always supplied + along with a reason for the error indicated as a parameter. One + of the following possible reasons for loss MUST be included as the + parameter when the event is reported: + + - "resverr" is used to indicate that a ResvErr message was + received. + + - "patherr" is used to indicate that a PathErr message was + received. + + - "other" + + In addition to a parameter indicating one of the reasons above, + additional information on the type of error MAY be included as a + second parameter in the form of a quoted string. + + + +Foster & Andreasen Informational [Page 53] + +RFC 3660 Basic MGCP Packages December 2003 + + + Example report might include: + + O: res/rl@0A3F58(resverr) + + or + + O: res/rl@0A3F58(resverr, "some additional commentary") + + Note that this event will not be reported if an error occurs while + a resource reservation is initially being set up (i.e., the event + was only reported as a result of an error that occurred after the + reservation was set up). + + Resource Lost (rl): + Loss of reservation during the life of a connection can be + reported by using the "rl" event. This event is not requested + with a parameter, but is reported with a parameter (see below for + possible values). If requested on an endpoint (without specifying + the connection ID), the request refers to all present and future + connections on that endpoint. + + When reported, the connectionID is always supplied along with a + reason for the loss indicated as a parameter. One of the + following possible reasons for loss MUST be supplied as the + parameter when the event is reported: + + - "resvtear" indicating that the reservation loss was + indicated by ResvTear message. + + - "pathtear" indicating that the reservation loss was + indicated by PathTear message. + + - "other" + + In addition to a parameter indicating one of the reasons above, + additional information on the type of error MAY be included as a + second parameter in the form of a quoted string. + + Example report might include: + + O: res/rl@0A3F58(ResvTear) + + or + + O: res/rl@0A3F58(ResvTear, "some other commentary") + + + + + + +Foster & Andreasen Informational [Page 54] + +RFC 3660 Basic MGCP Packages December 2003 + + + Note that this event will not be reported if an error occurs while + a resource reservation is initially being set up (i.e., the event + is only reported if the reservation was lost after it was + initially set up). + +2.12. Announcement Server Package + + Package Name: A + Version: 1 + + --------------------------------------------------------------- + | Symbol | Definition | R | S Duration | + |---------------------------------------------------------------| + | ann(url) | Play an Announcement | | TO, C variable | + | oc | Operation Complete | x | | + | of | Operation Failure | x | | + --------------------------------------------------------------- + + Changes from the previous version: change to conform to standard + reporting of operation failure and operation complete events. + + The announcement signal is qualified by a URL name: + + S: ann(http://scripts.example.net/all-lines-busy.au) + + The URL name MAY be followed by a list of initial parameters, + separated by commas. However, standard parameters are not included + as part of this package definition (Note: use of additional + parameters is optional and would result in a proprietary interface). + + The gateway SHOULD support one or more standard URL schemes such as: + + * file, http, ftp (RFC 1738 [28]), which indicate where the audio + file is located (where to load the file from before playing the + audio file on the gateway). + + * RTSP URL (section 3.2 of RFC 2326 [29]), which in this case + allows the media gateway to directly initiate playing of the + announcement via an RTSP server. + + The pre-condition for a successful response (return code of "200") is + correct syntax and capability (support is available for this + request). Standard MGCP return codes apply in the case of failure. + Further indications of failure are provided in the operation failure + event as a comment after the name of the failed event in the form of + a quoted string. + + + + + +Foster & Andreasen Informational [Page 55] + +RFC 3660 Basic MGCP Packages December 2003 + + + If the announcement cannot be played out for a reason determined + after a successful response to the request has been provided, an + operation failure event will be returned. The failure MAY be + explained by some commentary (in the form of a quoted string), as in: + + O: a/of(a/ann,"file not found") + + The "operation complete" event will be detected when the announcement + is played out. + + O: a/oc(a/ann) + +2.13. Script Package + + Package Name: Script + Version: 1 + + ----------------------------------------------------------------- + | Symbol | Definition | R | S | Duration | + |-----------------------------------------------------------------| + | ir(..) | Intermediate Results/Req.| x | BR | | + | java(url,...) | Load & Run java script | | TO | variable | + | oc | operation complete | x | | | + | of | operation failure | x | | | + | perl(url,...) | Load & Run perl script | | TO | variable | + | tcl(url,...) | Load & Run TCL script | | TO | variable | + | vxml(url,...) | Load & Run VXML doc. | | TO | variable | + | xml(url,...) | Load & Run XML script | | TO | variable | + ----------------------------------------------------------------- + + Changes from the previous version of the package: "vxml" was added as + a language type for loading and running VXML documents; change to + conform with standard reporting of operation failure and operation + complete events; addition of "ir" event. + + The current definition defines keywords for the most common + languages. More languages may be defined in later versions of this + package. + + The "signal" specifying the scripting language is parameterized with + a URL indicating the location of the script. The URL parameter MAY + be optionally followed by a comma-separated list of arguments as + initial parameters to use in running the script. URL schemes may + include file ftp, or http schemes with syntax according to RFC 2396 + [30]. As an example: + + S: script/vxml(ftp://ftp.example.net/credit-card.vxml,arg1,arg2, + ...,argn) + + + +Foster & Andreasen Informational [Page 56] + +RFC 3660 Basic MGCP Packages December 2003 + + + The argument list "arg1,arg2,...,argn" is passed to the + script/document as a list of initial parameters. + + The pre-condition for a successful response (return code of "200") is + correct syntax and capability (support is available for this + request). Standard MGCP return codes apply in the case of failure. + Some further (non-application/script specific) failure indications + MAY be provided in the operation failure event as a comment in the + form of a quoted string following the name of the failed event. + + Example + + O: script/of(script/vxml,"file not found") + + The script produces an output, which consists of one or several text + strings, separated by commas. This provides the return-status of the + script as well as return parameters (if there are any) + + O: script/oc(script/vxml,return-status=<status>, + name1=value1,name2=value2,...) + + where <status> can have one of the values "success" or "failure". + This is then followed by output parameters as a comma-separated list + of name-value pairs. + + Intermediate Result/Request (ir(<params>)): + This provides a way for: + + * The script to inform the Call Agent of intermediate results + (e.g., a case where it is important because of timing + concerns to inform the Call Agent prior to operation + complete). + + * The script to request some information from the Call Agent. + + * The Call Agent to inform the script of some event or + information that may be important for the operation of the + script (in this case "ir" is used as a signal). + + Parameters (i.e., <params>) SHOULD be a comma-separated list of + name-value pairs e.g., ir(name1=value1,name2=value2,..). The Call + Agent MAY include event parameters when it requests this event, in + which case, the MGCP syntax requirements require that the action + be specified (e.g., "R: ir(N)(nam1=value1,name2=value2,..)"). + + If the Call Agent requests "ir" as a signal, at least one + parameter MUST be provided. + + + + +Foster & Andreasen Informational [Page 57] + +RFC 3660 Basic MGCP Packages December 2003 + + + When requesting the "ir" signal, the Call Agent MUST also repeat + the original script signal. This is in order to be consistent + with the semantics of TO signals in MGCP (i.e., if the original + "script" signal is not included, then the signal/script will be + stopped). The only problem with this is that there is a possible + race condition in which a request to send an "ir" signal could + occur just as the script stopped. In order to avoid this + confusion, the following is RECOMMENDED: when the script signal is + included with an "ir" signal, include a parameter (of the script + signal) to indicate that this is not a new instance of the script + i.e., if there is no script executing at the present time do not + start executing a new one. + + The "ir" signal is only associated with an executing script. If + none are running when a request for the event/signal is made, or + if a new script request is not included with the request, then the + "ir" signal/event will not be executed (i.e., the "ir" event with + its parameters is passed to an existing script for parsing and + execution and is considered opaque as far as MGCP as concerned. + If no such script exists, response code "800" will be returned, + indicating that the script is not executing). + + The following response code is associated with this package: + + Code Text Explanation + + 800 Script not Request for "ir" signal or event + Executing but no script is executing at the + time the request was received. + + Note that package specific error codes include the package name + following the error code. For example, if error code 800 occurs + in response to a request with a transaction ID of 1001, it would + be sent as: + + 800 1001 /SCRIPT + + + + + + + + + + + + + + + +Foster & Andreasen Informational [Page 58] + +RFC 3660 Basic MGCP Packages December 2003 + + +3. IANA Considerations + + The following packages and their versions have been registered with + IANA as per the instructions in [1]. + + Package Title Name Version + ------------- ---- ------- + Announcement A 1 + DTMF D 1 + Digit Map Extension DM1 0 + Media Format FM 0 + Generic G 1 + Handset H 1 + Line L 1 + RTP R 1 + Resource Reservation RES 0 + Script SCRIPT 1 + Supplementary Tones SST 0 + Signal List SL 0 + Trunk T 1 + + The following extension digit map letter has been registered with + IANA: + + Package Letter + ------- ------ + DM1 P + + The following Local Connections have been registered with IANA: + + Field Name + ------- ----- + Media Format fmtp + Reservation Confirmation r-cnf + Reservation Direction r-dir + Resource Sharing r-sh + +4. Security Considerations + + The MGCP packages contained in this document do not require any + further security considerations beyond those indicated in the base + MGCP specification [1]. + +5. Acknowledgements + + Special thanks are due to the authors of the original MGCP 1.0 + specification: Mauricio Arango, Andrew Dugan, Isaac Elliott, + Christian Huitema, and Scott Picket. + + + +Foster & Andreasen Informational [Page 59] + +RFC 3660 Basic MGCP Packages December 2003 + + + Thanks also to the reviewers of this document, including but not + limited to: Jerry Kamitses, Sonus Networks; Dave Auerbach, Dan Wing, + Cisco Systems; Ed Guy, EMC Software; Martin Wakley, Nortel Networks. + +6. References + +6.1. Normative References + + [1] Andreasen, F. and B. Foster, "Media Gateway Control Protocol + (MGCP) Version 1.0", RFC 3435, January 2003. + + [2] Bellcore, "LSSGR: Switching System Generic Requirements for Call + Control Using the Integrated Services Digital Network User Part + (ISDNUP)", GR-317-CORE, Issue 2, December 1997. + + [3] ITU-T, "Telephone User Part Signaling Procedures", ITU-T Q.724, + November 1988. + + [4] ANSI, "OAM&P - Terminating Test Line Access and Capabilities", + T1.207-2000. + + [5] Bellcore, "Notes on the Network", Special Report SR-2275, Issue + 3, December 1997. + + [6] Bellcore, "Call Processing" GR-505-CORE, Issue 1, December 1997. + + [7] Bellcore, "LSSGR: Signaling for Analog Interfaces", GR-506-CORE, + Issue 1, June 1996. + + [8] ITU-T, "Technical Characteristics of Tones for the Telephone + Service", ITU-T E.180, March 1998. + + [9] ITU-T, "Various Tones Used in National Networks", ITU-T E.180, + Supplement 2, January 1994. + + [10] ITU-T, "Applications of Tones and Recorded Announcements in + Telephone Services", ITU-T E.182, March 1998. + + [11] Bellcore, "Call Forwarding Sub-Features FSD-01-02-1450, GR-586, + Issue 1, June 2000. + + [12] Bellcore, "CPE Compatibility Considerations for the Voiceband + Data Transmission Interface", SR-TSV-002476, December 1992. + + [13] Bellcore, "LSSGR: Visual Message Waiting Indicator Generic + Requirements (FSD 01-02-2000)", GR-1401, Issue 01, June 2000. + + + + + +Foster & Andreasen Informational [Page 60] + +RFC 3660 Basic MGCP Packages December 2003 + + + [14] Bellcore, "LSSGR Voiceband Data Transmission Interface", Section + 6.6, GR-30-CORE, Issue 02, December 1998. + + [15] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [16] Bellcore, "LSSGR: Call Waiting, FSD 01-02-1201", GR-571, Issue + 01, June 2000. + + [17] Bellcore, "LSSGR: Verification Connections FSD 25-05-0903", GR- + 531-CORE, Issue 1, June 2000. + + [18] Bellcore, " LSSGR: CLASS Feature: Calling Identity Delivery on + Call Waiting, FSD 01-02-1090, GR-575, Issue 01, June 2000. + + [19] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, + September 1981. + + [20] Bellcore, "Class Feature: Screen Editing (FSD 30-28-0000)", GR- + 220, Issue 2, April 2002. + + [21] ITU-T, "Procedure for document facsimile transmission in the + general switched telephone network", ITU-T T.30, April 1999. + + [22] ITU-T, "300 bits per second duplex modem standardized for use in + the general switched telephone network", ITU-T V.21, November + 1988. + + [23] Telcordia Technologies, "Telcordia Technologies Specification of + Signaling System Number 7", GR-246-CORE, Issue 7, December 2002. + + [24] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Name + Delivery Generic Requirements (FSD 01-02-1070)", GR-1188, Issue + 02, December 2000. + + [25] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Number + Delivery (FSD 01-02-1051)", GR-31, Issue 01, June 2000. + + [26] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video + Conferences with Minimal Control", RFC 3551, July 2003. + + [27] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, + "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional + Specification", RFC 2205, September 1997. + + [28] Berners-Lee, T., Masinter, L. and M. McCahill, Eds., "Uniform + Resource Locators (URL)", RFC 1738, December 1994. + + + + +Foster & Andreasen Informational [Page 61] + +RFC 3660 Basic MGCP Packages December 2003 + + + [29] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming + Protocol (RTSP)", RFC 2326, April 1998. + + [30] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [31] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +6.2. Informative References + + [32] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., + Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload + for Redundant Audio Data", RFC 2198, September 1997. + + [33] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, + Telephony Tones and Telephony Signals", RFC 2833, May 2000. + + [34] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001. + + [35] PacketCableTM, Dynamic Quality if Service Specification, + http://www.packetcable.com/downloads/specs/PKT-SP-DQOS-I07- + 030815.pdf + + [36] PacketCableTM Network-Based Call Signaling Protocol + http://www.packetcable.com/downloads/specs/PKT-SP-EC-MGCP-I08- + 030728.pdf + + [37] Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, Eds., + "Gateway Control Protocol Version 1", RFC 3525, June 2003. + + [38] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, + "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, + October 1999. + + + + + + + + + + + + + + + + + +Foster & Andreasen Informational [Page 62] + +RFC 3660 Basic MGCP Packages December 2003 + + +7. Authors' Addresses + + Bill Foster + Cisco Systems + + Phone: +1 250 758 9418 + EMail: bfoster@cisco.com + + + Flemming Andreasen + Cisco Systems + Edison, NJ 08837 + + EMail: fandreas@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Foster & Andreasen Informational [Page 63] + +RFC 3660 Basic MGCP Packages December 2003 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Foster & Andreasen Informational [Page 64] + |