Internet Engineering Task Force M. Arango Internet Draft SUN Microsystems Document: A. Dugan Category: Informational I. Elliott Expires: June 2001 Level3 Communications C. Huitema Microsoft S. Pickett Vertical Networks B. Foster F. Andreasen Cisco Systems January 2001 Basic MGCP Packages Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides a basic set of MGCP packages. The generic, line, trunk, handset, RTP, DTMF, announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases with a new version event. In addition to these, four new packages have been added. These are the signal lists, resource reservation, media format, supplementary services and digit map extension packages. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Arango et al. Informational [Page 1] Basic MGCP Packages January 2001 1. Introduction 1.1. List of Packages This document provides a basic set of packages for MGCP. Included are the following packages: ------------------------------------------- | Package | name | |-------------------------------------------| | Generic Media Package | G | | DTMF package | D | | Trunk Package | T | | Line Package | L | | Handset Package | H | | Supplementary Services Package | SST | | Digit Map Extension | DM1 | | Signal List Package | SL | | Media Format Package | FM | | RTP Package | R | | Resource Reservation Package | RES | | Announcement Server Package | A | | Script Package | Script | ------------------------------------------- 1.2. Changes to Existing Packages 1.2.1. Change in signal types MGCP 1.0 provided some additional clarification on the meaning of OO signals. This lead to some inconsistency in signal definitions in some of the packages. This has been corrected in the packages that are included here by changing some of the signals from type OO to type TO. 1.2.2. Operation Complete and Operation Fail Another change also made to improve inconsistency and interoperability was to add the "operation complete" event in packages where there were TO events defined but where the operation complete event was to included as part of the package. MGCP defines the use of operation complete and operation fail events as they relate to TO signals in the following way: 1.2.2.1. Operation Complete Event Operation complete (oc): The operation complete event is generated when the gateway was asked to apply one or several signals of type TO on the endpoint, and one or more of those signals completed without being stopped by the detection of a requested event such as off-hook transition or dialed digit. The completion report may carry as a parameter the name of the signal that came to the end of its live time, as in: O: G/oc(G/rt) Arango et al. Informational [Page 2] Basic MGCP Packages January 2001 When the reported signal was applied on a connection, the parameter supplied will include the name of the connection as well, as in: O: G/oc(G/rt@0A3F58) When the operation complete event is requested, it cannot be parameterized with any event parameters. When the package name is omitted, the default package name is assumed. 1.2.2.2. Operation Fail Event Operation failure (of): In general, the operation failure event may be generated when the endpoint was asked to apply one or several signals of type TO on the endpoint, and one or more of those signals failed prior to timing out. The completion report may carry as a parameter the name of the signal that failed, as in: O: G/of(G/rt) When the reported signal was applied on a connection, the parameter supplied will include the name of the connection as well, as in: O: G/of(G/rt@0A3F58) When the operation failure event is requested, event parameters can not be specified. When the package name is omitted, the default package name is assumed. 1.2.2.3. Over-riding the Meaning of "oc" and "of" events The above are the recommended definitions for "operation complete" and "operation fail" events for all packages. However, specific packages may re-define the syntax and symantics of these events. If no definition is included in the package, the above syntax and semantics is assumed. 1.2.3. Package Version For packages where changes have been made, a version event has been added so that you can distinguish between these and earlier versions of the same package. A description of this event is as follows: Version (ver): This is a one-shot event in the sense that when requested in a Notification Request, the gateway will send an immediate Notify with observed event ver(), where in the version of the package. If the gateway does not support the versioned package it will respond with a "nack" (error code 512 - not equipped to detect requested event). In other words, the Call Agent can distinguish between versioned and previously unversioned packages by requesting to be notified about the "ver" event for a package. If it receives error code 512, that indicates that the gateway does not support the versioned package and Arango et al. Informational [Page 3] Basic MGCP Packages January 2001 the previous unversioned package is supported instead. Note however, that if the Call Agent receives a return code of 518, it simply indicates that the gateway does not support the package. 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 should still implement these events (and in fact should implement all of the events in a package). Some events that were previously defined require specific provisioning in both the gateway and the Call Agent in order to allow for interoperability. In those cases, a warning to that affect has been included. 1.2.5. New Events In some cases new events have been added to existing packages. 1.3. New Packages and Excluded Packages New packages have been included beyond what was included in the original RFC 2705. The "RES" and "FM" packages in particular are different from other packages in this document in that it does not contain events and signals but a new set of Local Connection Options instead. This is allowed in the new extension rules in [1]. Future packages of this type should use a packages prefix in front of local connection options ("package-name"/"Local Connection Option") so as to avoid name-space problems. However because of the timing of the arrival of this package relative to updating MGCP 1.0 this was not done for the "RES" and "FM" packages. The resulting new local connection options will be registered with IANA. For future cases where a package prefix is included, only the package name needs to be registered. Arango et al. Informational [Page 4] Basic MGCP Packages January 2001 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 ("signal") from an "event" that occurs on the Media Gateway and is "Notified" to the Call Agent. For packages that involve events and signals the tables of contain five columns: Symbol: the unique symbol used for 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, an "S" may be included if the event-state may be audited. A "C" indicates that the event can be detected on a connection. S: if nothing appears in this column for an event, then the event cannot be signaled on command by the Call Agent. Otherwise, the following symbols identify the type of event: OO On/Off signal. TO Timeout signal. BR Brief signal. Duration: specifies the duration of TO signals. If a duration is left unspecified then the default timeout will be assumed to infinite. 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. In some of the signal definitions below, specific tone definitions are provided even though actual frequencies may vary from country to country. Country variations should be handled by gateway provisioning. Arango et al. Informational [Page 5] Basic MGCP Packages January 2001 2.1 Generic Media Package Package Name: G Version: 1 The generic media package group the events and signals that can be observed on several types of endpoints, such as trunking gateways, access gateways or residential gateways. --------------------------------------------------------------- | Symbol | Definition | R | S Duration | |---------------------------------------------------------------| | cf | Confirm tone | | BR | | cg | Network Congestion tone | | TO | | ft | Fax tone detected | x | | | it | Intercept tone | | TO | | ld | Long duration connection | C | | | mt | Modem detected | x | | | oc | Operation Complete | x | | | of | Operation Fail | x | | | pt | Preemption tone | | TO | | rt | Ringback tone | | TO 180 seconds| | vbd | Onset of voiceband data | C | | | vbdt | Termination of vbd mode | C | | | ver | package version | x | | |---------------------------------------------------------------| | rbk(###) | ! Note | | TO 180 seconds| | pat(###) | ! Note | x | OO | --------------------------------------------------------------- ! Note: Ringback (rbk): is an alias for rt@connectionID. It is recommended that Call Agents use rt@connectionID instead of rbk(connectionID) for ring-back over a connection for new implementations. pat(###): pattern detected. Special provisioning needs to be agreed on between the Call Agent and media gateway in order to ensure interoperability. New events added to this package from the previously unversioned package: "oc", "vbd", "vbdt" and "ver". Changes in event types: "it" and "pt" signals changed from OO to TO. The events are defined as follows: Confirmation tone (cf): Confirmation Tone uses the same frequencies and levels as dial tone (350 and 440 Hertz ) but with a cadence of 0.1 second on, 0.1 second off repeated three times. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.4. It is considered an error to try and play confirmation tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Arango et al. Informational [Page 6] Basic MGCP Packages January 2001 Congestion Tone (cg): Refer to ITU E.180 and E.182. This is also referred to as re-order tone or fast busy (or network busy) tone. For North America see GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7. Note that it is considered an error to try and play reorder tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Fax tone (ft): Indicates V.21 fax preamble detected. Intercept tone(it): This is a country specific tone as defined in ITU-T, E.180 Supplement 2. (for the intercept special information tone, use "sit(5)" in the trunk package instead). Long Duration (ld): The "long duration connection" is detected when a connection has been established for more than some time (default value 1 hour). The event may be detected on a connection. When no connection is specified, the event applies to all connections for the endpoint, regardless of when the connections are created. Modem tones (mt): Indicates 2100 Hz (ANS) or 2100 Hz (ANSam) tone with or without phase reversal. Preemption Tone (pt): This is a country specific tone and is defined in ITU-T, E.180 Supplement 2. Ring back tone (rt): Refer to ITU E.180 and ITU E.182. Also referred to as ringing tone - a tone advising the caller that a connection has been made and that a calling signal is being applied to a telephone number or service point. In North America this tone is a combination of two AC tones with frequencies of 440 and 480 Hertz and levels of - 19 dBm each, to give a combined level of -16 dBm. The cadence for Audible Ring Tone is 2 seconds on followed by 4 seconds off. See GR- 506-CORE - LSSGR: SIGNALING, Section 17.2.5. This signal can be applied directly to an endpoint or alternatively on a connection using the syntax rt@connectionID. When the ringback signal is applied to an endpoint, it is considered an error to try and play ring back tones, if the endpoint is considered on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). When the ringback signal is applied to a connection, no such check is to be made. Voice-Band Data (vbd): A "vbd@connectionID" event indicating successful switch to voiceband data. This is a connection event as opposed to an endpoint event and is indexed by connection_ID. The event "vbd" stands for onset of voiceband data. Voice-Band Data Termination (vbdt): A "vbdt@connectionID" event indicating a failed attempt to switch to voiceband data or a switch from voiceband data to the voice mode. This is a connection event as opposed to an endpoint event and is indexed by connection_ID. The event "vbdt" stands for termination of voiceband data mode and is Arango et al. Informational [Page 7] Basic MGCP Packages January 2001 used to indicate either a failed attempt to switch to voiceband data or a switch from a voiceband data mode to a voice mode. 2.2. DTMF package Package name: D ------------------------------------------------------------- | Symbol | Definition | R | S Duration | |-------------------------------------------------------------| | 0 | DTMF 0 | x | BR | | 1 | DTMF 1 | x | BR | | 2 | DTMF 2 | x | BR | | 3 | DTMF 3 | x | BR | | 4 | DTMF 4 | x | BR | | 5 | DTMF 5 | x | BR | | 6 | DTMF 6 | x | BR | | 7 | DTMF 7 | x | BR | | 8 | DTMF 8 | x | BR | | 9 | DTMF 9 | x | BR | | # | DTMF # | x | BR | | * | DTMF * | x | BR | | A | DTMF A | x | BR | | B | DTMF B | x | BR | | C | DTMF C | x | BR | | D | DTMF D | x | BR | | L | long duration indicator | x | | | X | Wildcard, match | x | | | | any digit 0-9 | | | | of | operation fail | x | | | T | Interdigit timer | x | | ------------------------------------------------------------- There are no changes to this package from that defined in RFC 2705. The events are defined as follows: DTMF tones (0-9,*,#,A, B,C,D): Detection and generation of DTMF signals is described in GR-506-CORE - LSSGR: SIGNALING, Section 15. Note that it is considered an error to try and play DTMF tones on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Long duration Indicator (l): The "long duration indicator" is observed when a DTMF signal is produced for a duration larger than two seconds. In this case, the gateway will detect two successive events: first, when the signal has been recognized, the DTMF signal, and then, 2 seconds later, the long duration signal. DTMF tones wildcard (X): The DTMF tones wildcard matches any DTMF digit between 0 and 9. Timer (t): Refer to the base MGCP specification [1] for a detailed discussion of the use of Timer T with a the "accumulate according to Arango et al. Informational [Page 8] Basic MGCP Packages January 2001 digit map" action. When timer T is used with the "Notify" action, timer T takes on the value T-critical as described in the base MGCP specification, and the timer is started immediately and simply cancelled (but not restarted) as soon as a digit is entered. In this case, timer T can be used as an inter-digit timer when overlap sending is used, e.g.: R: [0-9](N), T(N) Operation failure (of): This operation failure event is kept here for backwards compatibility with existing implementations. There are no specific reasons defined for this package for operation failure. The circumstances under which such an event may (or may not) be triggered is left to implementations. If such an event occurs within the DTMF package it is not parameterized i.e.: O: d/of 2.3. Trunk Package Package Name: T Version: 1 ---------------------------------------------------------------- | Symbol | Definition | R | S Duration | |-------------------------------------------------- -------------| | co1 | Continuity tone (single tone,| x | TO | | | or return tone) | | | | co2 | Continuity test (go tone, | x | TO | | | in dual tone procedures) | | | | nm | New Milliwatt Tone | x | TO | | mm | Newest Milliwatt Tone | x | TO | | oc | Operation Complete | x | | | of | report failure | x | | | om | Old Milliwatt Tone | x | TO | | qt | Quiet Termination | | TO | | ro | Reorder Tone | x | TO 30 sec. | | sit(###) | Special Information Tone | | BR | | tl | Test Line | x | TO | | ver | package version | x | | | zz | No circuit | x | TO | |----------------------------------------------------------------| | as | ! Note | x | OO | | bl | ! Note | | OO | | lb | ! Note | | OO | ---------------------------------------------------------------- ! Note: It is recommended that future implementations of Call Agents make use of alternatives to using these events: Answer Supervision (as): This event is used for off-hook representing "answer" in CAS. Arango et al. Informational [Page 9] Basic MGCP Packages January 2001 Blocking (bl): This event is used to indicate an incoming off-hook for the purposes of blocking a one-way trunk in CAS trunks. Loopback (lb): In the case of "loopback", alternatives for using a this signal are to use the loopback connection mode or to use an embedded event as described below for continuity testing. New events added to this package from the previously unversioned package: "oc", "nm", "qt", "sit" and "ver". Changes in event types: "co1", "co2", "nm", "om", "tl", "zz" signals changed from OO to TO. The definition of trunk package events are as follows: Continuity Tone (co1): A tone at 2010 + or - 30 Hz Continuity Test (co2): A tone at the 1780 + or - 30 Hz. Continuity testing requirements are defined in ITU-T Q.724 as well as by Bellcore GR-317-CORE specifications. The continuity tones represented by co1 and co2 are used when the Call Agent wants to initiate a continuity test. There are two types of tests, single tone and dual tone and in the case of the dual-tone either tone can be sent and the opposite received depending on the trunk interconnections (4-wire or 2-wire). This is indicated below: Originating Terminating ============ =========== 4w -------------- 1780+/-20 Hz -----------> 2w <------------- 2010+/-08 Hz ------------ (transponder) 2w -------------- 2010+/-30 Hz -----------> 2w/4w <------------- 1780+/-20 Hz ------------ (transponder) 4w -------------- 2010+/-08 Hz -----------> 4w <------------- 2010+/-08 Hz ------------ (loopback) The Call agent is expected to know, through provisioning information, which test should be applied to a given endpoint. For example, the Call Agent that wants to initiate a single frequency test will send to the gateway a command of the form: RQNT 1234 ds/ds1-1/17@tgw2.example.net X: AB123FE0 S: co1 R: co1 If it wanted instead to initiate a dual-tone test, it would send the command: Arango et al. Informational [Page 10] Basic MGCP Packages January 2001 RQNT 1234 ds/ds1-1/17@tgw2.example.net X: AB123FE0 S: co2 R: co1 depending on the type of trunk interconnect. The gateway would send the requested signal, and in both examples would look for the return of the appropriate tone. When it detects that tone, it will send the corresponding notification. Failure of the continuity test is indicated by a failure to receive the return tone within some period of time. The timer must be implemented within the Call Agent (i.e. failure to receive a notification before a timer in the Call Agent times out) unless support for timeout is available in the gateway. The "to" signal to override the duration is not mandatory for the "T" package. However, some gateways may support this capability, with "oc" indicating when the timeout occurs. On the terminating end of the trunk where the loop-back or transponder has to be performed, there are two approaches that can be used: 1. Use "loopback" connection mode for the single tone or "conttest" connection mode for the dual tone tests. In the case of "conttest", the gateway must be able to handle both transponder cases (receive "co1" and return "co2" or the opposite) either by provisioning the gateway for the particular transponding mode that "conttest" represents or by having the capability in the gateway of doing it "on-the-fly". 2. Use an embedded request that does effectively the same thing. As an example, in the case of the loopback test, do an RQNT with: R: co1(E(S(co1))) Note that continuity tones are only ever sent to the telephony endpoint. For network-based continuity, "co1" and "co2" tones are available in the RTP ("R") package. New Milliwatt Tone (nm): 1004 Hz tone - refer to [7] and [8]. Newest milliwatt Tone (mm): 1013.8 Hz - refer to [7] and [8]. Old Milliwatt Tone (om): 1000 Hz tone Quiet Termination (qt): used in 102 test Trunk. Reference section 6.20.5 [6] as well as [7] and [8]. Reorder Tone(ro): Also referred to as congestion tone (see ITU E.180 and E.182 specifications). 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 Station Busy Tone is 0.25 seconds on followed by 0.25 Arango et al. Informational [Page 11] Basic MGCP Packages January 2001 seconds off, repeating continuously. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7. Special Information Tone(sit(###)):The parameter values range from 1 to 7. In North America they have the following meaning as defined in SR-2275, section 6.21.2 [6] as follows: ------------------------------------------- | 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 | ------------------------------------------- In countries where there is only a single SIT tone defined, then only sit(1) is used and that has the country specific value (refer to [3]). Line Test (tl): 105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0 + or -- 0.5dB). No circuit Special Information Tone (zz): This is an alias for "sit(2)". Version (ver): This is a one-shot event. When requested in a Notification Request, the gateway will send an immediate Notify with observed event ver(), where in this case has the value "1". If the gateway does not support the versioned package it will respond with a "nack" (error code 512 - not equipped to detect requested event). Arango et al. Informational [Page 12] Basic MGCP Packages January 2001 2.4. Line Package Package Name: L Version: 1 ---------------------------------------------------------------- |Symbol | Definition | R | S Duration | |----------------------------------------------------------------| |adsi(string) | adsi display | | BR | |aw | Answer tone | x | OO | |bz | Busy tone | | TO 30 sec. | |ci(ti,nu,na) | Caller-id | | BR | |dl | Dial tone | | TO 16 sec. | |e | Error tone | x | BR | |hd | Off hook transition | S | | |hu | On hook transition | S | | |hf | Flash hook | x | | |ht | Tone on Hold | | TO | |mwi | Message waiting ind. | | TO 16 sec. | |oc | Report on completion | x | | |of | report failure | x | | |ot | Off hook warning tone | | TO | |rg | Ringing | | TO 180 sec. | |r0, r1, r2, | Distinctive ringing | | TO 180 sec. | |r3, r4, r5, | | | | |r6 or r7 | | | | |ro | Reorder tone | | TO 30 sec. | |rs | Ringsplash | | BR | |sit | SIT tone | | | |sl | Stutter dialtone | | TO 16 sec. | |v | Alerting tone | | OO | |ver | package version | x | | |vmwi | visual message | | OO | | | waiting indicator | | | |wt | Call Waiting tone | | TO 30 sec | |wt1, wt2, | Alternative call | | TO 30 sec | |wt3, wt4 | waiting tones | | (see notes) | |y | Recorder Warning Tone | | TO | |z | Calling Card Service Tone| | TO | |----------------------------------------------------------------| |p | ! Note | x | BR | |nbz | ! Note | x | OO | |s(###) | ! Note | x | BR | ---------------------------------------------------------------- ! Note: Prompt tone (p): alias calling card service tone ("z"). Future implementations should use "z". Network Busy (nbz): The "nbz" signal is an alias for re-order tone ("ro"). Future implementations should use the "ro" signal. Arango et al. Informational [Page 13] Basic MGCP Packages January 2001 Distinctive Tone Pattern (s): May require special provisioning in the Call Agent and gateway to insure interoperability. New events added to this package from the previously unversioned package: "ht and "ver". Changes in event types: signals "y", z", changed from OO to TO. The description of events and signals in the line package are as follows: ADSI display (adsi): This is a parameterized signal - adsi(string). Note that white spaces are permitted if the string is quoted. See GR- 1273-CORE - ANALOG DISPLAY SERVICES INTERFACE (ADSI) SPCS/SERVER GENERIC REQUIREMENTS (A MODULE OF ADSI, FR-12) Answer tone (aw): The V.25 ANS tone (with or without phase reversals). Busy tone (bz): Refer to ITU E.180. In North America, station Busy is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for Station Busy Tone is 0.5 seconds on followed by 0.5 seconds off, repeating. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.6. It is considered an error to try and play busy tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Caller Id (ci(time, number, name)): See TR-NWT-001188, GR-30-CORE, and TR-NWT-000031. Each of the three fields are optional, however each of the commas will always be included. The time parameter is coded as "MM/DD/HH/MM", where MM is a two- digit value for Month between 01 and 12, DD is a two-digit value for Day between 1 and 31, and Hour and Minute are two-digit values coded according to military local time, e.g., 00 is midnight, 01 is 1 a.m., and 13 is 1 p.m. The number parameter is coded as an ASCII character string of decimal digits that identify the calling line number. White spaces are permitted if the string is quoted, however they will be ignored. 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. A "P" in the number or name field is used to indicate a private number or name, and an "O" is used to indicate an unavailable number or name. The following example illustrates the use of the caller-id signal: S: ci(10/14/17/26, "555 1212", somename) Arango et al. Informational [Page 14] Basic MGCP Packages January 2001 Dial-tone (dl): Refer to the ITU E.180 specification. In North America, dial tone is a combination of two continuous AC tones with frequencies of 350 and 440 Hertz and levels of -13dBm each to give a combined level of -10 dBm. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.1. It is considered an error to try and play dial-tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Error tone (e): alias for "t/sit(6)" (vacant code SIT). Tone on-hold (ht): A tone used to reassure a calling subscriber who has been placed on "hold". Refer to ITU-T E.182 [5]. Message Waiting Indicator (mwi): Message Waiting indicator tone uses the same frequencies and levels as dial tone (350 and 440 Hertz at - 13dBm each) but with a cadence of 0.1 second on, 0.1 second off repeated 10 times followed by steady application of dial tone. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.3. It is considered an error to try and play message waiting indicator on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Off-hook warning tone (ot): Receiver Off Hook Tone (ROH Tone) is the irritating noise a telephone makes when it is not hung up correctly. ROH Tone is generated by combining four tones at frequencies of 1400 Hertz, 2060 Hertz, 2450 Hertz and 2600 Hertz at a cadence of 0.1 second on, 0.1 second off, repeating. GR-506-CORE, Section 17.2.8 contains details about required power levels. It is considered an error to try and play off-hook warning tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Ringing (rg): See GR-506-CORE [5], Section 14. The provisioning process may define the ringing cadence. It is considered an error to try and ring a phone that is off hook and an error should consequently be returned when such attempts are made (error code 401 - phone off hook). Distinctive ringing (r0, r1, r2, r3, r4, r5, r6 or r7): See GR-506- CORE - [5], Section 14. Default values for r1 to r5 are as defined for distinctive ringing pattern 1 to 5 as defined in GR-506-CORE. The provisioning process may define the ringing cadence for each of these signals. It is considered an error to try and ring a phone that is off hook and an error should consequently be returned when such attempts are made (error code 401 - phone off hook). Reorder Tone (ro): Also referred to as congestion tone (see ITU-T E.180 [2] and GR-506-CORE [5] Section 17.2.7.). 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 Station Busy Tone is 0.25 seconds on followed by 0.25 seconds off, repeating continuously. Arango et al. Informational [Page 15] Basic MGCP Packages January 2001 Ringsplash (rs): also known as "Reminder ring" is a burst of ringing that may be applied to the physical forwarding line (when idle) to indicate that a call has been forwarded and to remind the user that a CF sub-feature is active. In the US, it is defined to be a 0.5(- 0,+0.1) second burst of power ringing. See Bellcore TR-TSY-000586 - Call Forwarding Sub-features. SIT tone (sit): The special information tone is provided for cases in which neither the busy nor the congestion tone can give the required information to the calling subscriber in the case of call failure. Refer to ITU_T E.180 for details. Stutter Dial tone (sl): Stutter Dial Tone (also called Recall Dial Tone) is used to confirm some action and request additional digits from the user. An example application is to cancel call-waiting, prior to entering a destination address. It is generated by supplying Confirmation Tone, followed by continuous Dial Tone. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.2. 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. It is considered an error to try and play stutter dial tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Alerting Tone (v): a 440 Hz Tone of 2 second duration followed by 1/2 second of tone every 10 seconds. Visual Message Waiting Indicator (vmwi): The transmission of the VMWI messages will conform to the requirements in Section 2.3.2, "On-hook Data Transmission Not Associated with Ringing" in Bellcore TR-H- 000030 and the CPE guidelines in SR-TSV-002476. VMWI messages will only be sent from the gateway to the attached equipment when the line is idle. If new messages arrive while the line is busy, the VMWI indicator message will be delayed until the line goes back to the idle state. If the gateway does a restart (sends a Restart-in- Progress message, the Call Agent should refresh the CPE's visual indicator. See TR-NWT-001401 - Visual Message Waiting Indicator Generic Requirements; and GR- 30-CORE - Voiceband Data Transmission Interface. Call Waiting tone1 (wt, wt1, .., wt4): Refer to ITU E.180. For North American tone definitions refer to GR-506-CORE, Section 14.2. "wt" and "wt1" are both aliases for the default Call Waiting tone which in North America is a 440-Hz tone applied for 300 ± 50 ms. In North America the call-waiting tone is repeated once after 8-10 seconds. These signals are timeout signals. The default timeout value shown in the table is 30 seconds. In North America, the gateway should play two call-waiting tones separated by 8-10 seconds. This allows the Call Agent to send a single request. Signals wt2, wt3 and wt4 are alternates that are used for distinctive call-waiting tone patterns. The talking path should be interrupted Arango et al. Informational [Page 16] Basic MGCP Packages January 2001 for a maximum of 400 ms for the application of CW tone. The Call Agent implements the actual call waiting service - see TR-TSY-000571 - Call Waiting. It is considered an error to try and apply call waiting tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Recorder Warning Tone(y): Refer to ITU E.180 - also Bellcore document SSR75 section 6.20. When recording equipment is used, this tone is connected to the line to inform the distant party that the conversation is being recorded - typical value us 1400 Hz Tone of 0.5 second duration every 15 seconds. Calling Card Service Tone(z): This tone is used to inform the customer that credit card information must be keyed in. Typically it consists of 60 ms of 941 + 1477 Hz (the DTMF #digit) and 940 ms of 350 + 440 Hz (dial tone), decaying exponentially with a time constant of 200 ms. Refer to Bellcore document SR2275, section 6.20. Arango et al. Informational [Page 17] Basic MGCP Packages January 2001 2.5. Handset Emulation Package Package Name: H Version: 1 ---------------------------------------------------------------- |Symbol | Definition | R | S Duration | |----------------------------------------------------------------| |adsi(string) | adsi display | x | BR | |aw | Answer tone | x | OO | |bz | Busy tone | x | TO 30 sec. | |ci(ti,nu,na) | Caller-id | x | BR | |dl | Dial tone | x | TO 16 sec. | |e | Error tone | x | BR | |hd | Off hook transition | S | BR | |hu | On hook transition | S | BR | |hf | Flash hook | x | BR | |ht | Tone on Hold | x | TO | |mwi | Message waiting ind. | x | TO 16 sec. | |oc | Report on completion | x | | |ot | Off hook warning tone | x | TO | |of | report failure | x | | |rg | Ringing | x | TO 180 sec. | |r0, r1, r2, | Distinctive ringing | x | TO 180 sec. | |r3, r4, r5, | | | | |r6 or r7 | | | | |ro | Reorder tone | x | TO 30 sec. | |rs | Ringsplash | x | BR | |wt | Call Waiting tone | x | TO 30 sec. | |sit | SIT tone | x | | |sl | Stutter dialtone | x | TO 16 sec. | |v | Alerting Tone | x | OO | |ver | package version | x | | |vmwi | Vis. Message Waiting Ind.| x | OO | |y | Recorder Warning Tone | x | TO | |z | Calling Card Serv. Tone | x | TO | |----------------------------------------------------------------| |p | ! Note | x | BR | |nbz | ! Note | x | TO | |s(###) | ! Note | x | BR | ---------------------------------------------------------------- ! Note: Refer to the line package. The handset emulation package is an extension of the line package, to be used when the gateway is capable of emulating a handset. The difference with the line package is that events such as "off hook" can be signalled as well as detected. Changes from the original package - are the same changes as were made for the line package plus "hu" and "hd" signal types were changed from OO to BR. Arango et al. Informational [Page 18] Basic MGCP Packages January 2001 2.6. Supplementary Services Tone Package Package Name: SST Version: 1 ---------------------------------------------------------------- |Symbol | Definition | R | S Duration | |----------------------------------------------------------------| |ac | acceptance tone | | TO | |bz2 | busy tone 2 | | TO | |cd | conference depart | | BR | |cg2 | congestion tone 2 | | TO | |cj | conference join | | BR | |cm | comfort tone | | TO | |cw | caller waiting tone | | TO 30 sec. | |dlp | dial-tone PABX | | TO | |eo | executive over-ride tone | | TO | |es | end of the 3 party serv. | | BR | |fc | facilities tone | | TO | |in | intrusion tone | | TO | |ll | line lockout | | TO | |ni | negative indication | | TO | |nu | number unobtainable | | TO | |oc | operation complete | x | | |of | operation fail | x | | |or | offering tone | | TO | |pi | positive indication tone | | TO | |pr | payphone recognition | | BR | |pst | permanent signal tone | | TO | |pt | pay tone | | BR | |qu | queue tone | | TO | |rf | refusal tone | | TO | |ru | route tone | | TO | |sa | service activated tone | | TO | |va | valid tone | | TO | |ver | package version | x | | |wa | waiting tone | | TO | |wre | End of Period warning | | TO | ---------------------------------------------------------------- Many of the default values for duration are not specified (default value is infinite). Default values may be over-ridden by the Call Agent in this package by a "to" signal parameter which specifies the timeout value in milliseconds. Example: S: sst/bz2(to=30000) indicates a timeout value of 30 seconds. Acceptance Tone(ac): Refer to E.180, supplement 2 [3]. Busy Tone 2 (bz2): Refer to E.180, supplement 2 [3]. Arango et al. Informational [Page 19] Basic MGCP Packages January 2001 Conference Depart(cd): Tone used to indicate that a participant has left a conference call. Congestion Tone 2 (cg2): Refer to E.180, supplement 2 [3]. Conference Join (cj): Tone used to indicate that a party has joined a conference call. Comfort Tone (cm): used to indicate that the call is being processed and that the caller should wait. Refer to E.182 [4]. Caller Waiting Tone (cw): not to be confused with call-waiting tone - a tone advising a caller that a called station, though busy, has a call waiting service active. Refer to E.182 [4]. Dial-tone PABX (dlp): Refer to E.180, supplement 2 [3]. Executive Over-ride tone (eo): Refer to E.180, supplement 2 [3]. End of Three Party Service Tone (es): Refer to E.180, supplement 2 [3]. Facilities Tone (fc): Refer to E.180, supplement 2 [3]. Intrusion Tone (in): Tone indicating that the privacy of the conversation has been breached (e.g. by an operator). Refer to E.180, supplement 2 [3]. Line Lock-out Tone (ll): Refer to E.180, supplement 2 [3]. Negative Indication (ni): A tone advising a subscriber that the request for service cannot be accepted. Refer to E.182 [4]. Number Unobtainable Tone (nu): Refer to E.180, supplement 2 [3]. Offering Tone (or): Refer to E.180, supplement 2 [3]. Positive Indication Tone (pi): A tone telling a subscriber controlling a supplementary service that the control procedure has been successfully completed and accepted. Refer to E.182 [4]. Pay Phone Recognition (pr): A tone advising an operator that the termination to is identified as a payphone. Refer to E.182 [4]. Permanent Signal Tone (pst): Refer to E.180, supplement 2 [3]. Pay Tone (pt): a tone indicating that payment is required. Refer to E.182 [4]. Queue Tone (qu): Refer to E.180, supplement 2 [3]. Refusal Tone (rf): Refer to E.180, supplement 2 [3]. Route Tone (ru): Refer to E.180, supplement 2 [3]. Arango et al. Informational [Page 20] Basic MGCP Packages January 2001 Service Activated Tone (sa): Refer to E.180, supplement 2 [3]. Valid Tone (va): Refer to E.180, supplement 2 [3]. Version event (ver): ver(), where in this case has the value "1". If the gateway does not support the versioned package it will respond with a "nack" (error code 512 - not equipped to detect requested event). Waiting Tone (wa): Refer to E.180, supplement 2 [3]. Warning Tone - end of period (wre): Refer to E.180, supplement 2 [3]. 2.7. Digit Map Extension Package Name: dm1 This package defines a digit map extension that is used to override the shortest possible match behavior for a given entry. The letter "P" (for partial match override) at the end of a digit map entry instructs the gateway to only consider this a match, if the current dial string does not partially match another entry. For example, given the digit map ([3-7]11|123xxxxxxx|[1-7]xxxxxxP) and a current dial string of "1234567" we would not consider this a match, however a current dial string of "411" would be considered a match. Support for the partial match override optional, but strongly suggested. 2.8. Signal List Package Package Name: SL --------------------------------------------------------- | Symbol | Definition | R | S Duration | |---------------------------------------------------------| | s(###) | Signal List | | TO variable | | oc | Operation Complete | x | | | of | Report failure | x | | --------------------------------------------------------- Signal List(s()): The is a comma-separated list of signals to be played out. Each of the signals in must be either of type BR or type TO. Signals are played to completion one after the other in the order specified. The package for each signal in the list must be specified. For example, to play out the DTMF digits 123456: S: sl/s(d/1,d/2,d/3,d/4,d/5,d/6) Arango et al. Informational [Page 21] Basic MGCP Packages January 2001 This will result in the DTMF digits 1, 2, 3, 4, 5 and 6 being played out in order. If the operation complete ("oc") event is requested, it will occur once, when the last signal in the list has been played out. 2.9. Media Format Package Package Name: FM This package provides support for the media format Local Connection Option. The media format local connection option has a similar significance to the "fmtp" attribute in SDP [9]. The media format parameter is encoded as the keyword "fmtp" followed by a colon followed by a quoted string. Multiple media formats may be indicated by either repeating the local connection option multiple times such as: fmtp:"format 1", fmtp:"format 2" or alternatively by having a single "fmtp" keyword followed by a colon, then strings for each media format separated by semi-colons e.g.: fmtp:"format 1";"format 2" In the case of this particular local connection option, if a value is not recognized, the connection request is not rejected as a result. The reason is that the media format local connection option is usually associated with a codec and if the codec is not recognized, the behavior is to ignore rather than reject. As such media formats associated with codecs that are ignored because they are not recognized should also be ignored. If, however, the parameter is recognized but not supported, then the request must be rejected. One example of this is the use of the media format local connection option when used in conjunction with the codec "telephone-event" as defined in RFC 2833. If the codec "telephone-event" is used without the "fmtp" media format parameter, the DTMF digits (telephone events 0-15 from RFC 2833). On the other hand, the media format local connection option can be used to specify the exact set of events that are being requested via RFC 2833. Example: L: a:PCMU;telephone-event,fmtp:"telephone-event 16" indicates that if telephone events are supported at all, then this request is specifically for event 16. 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" local connection option in the "FM" package is an exception. The package prefix is not included in the case of the "FMTP" local connection option because it was created before the extension rules in [1] were defined. Arango et al. Informational [Page 22] Basic MGCP Packages January 2001 2.10. RTP Package Package Name: R Version: 1 ------------------------------------------------------------- | Symbol | Definition | R | S Duration | |-------------------------------------------------------------| | uc(###) | Used codec changed | x | | | sr(###) | Sampling rate changed | x | | | ji(###) | Jitter buffer size changed | x | | | pl(###) | Packet loss exceeded | x | | | qa | Quality alert | x | | | co1 | Continuity tone (single | x | TO | | | or return tone) | | | | co2 | Continuity test (go tone, | x | TO | | | in dual tone procedures) | | | | of | report failure | x | | |ver | package version | x | | ------------------------------------------------------------- Changes in event types: "co1" and "co2" signals changed from OO to TO. New events added to this package from the previously unversioned package: "ver". These events all refer to RTP streams (connections). Signals requested ("co1" and "co2") must indicate the connection ID (e.g. "S: r/co1@connectionID"). may be requested without the connection ID if the event is applicable to all connections. Example: R: r/uc (request to report uc on all connections) or R: r/uc@connectionID (request to report uc only on a specific connection) An event may be reported with or without the connectionID if there is only one connection e.g.: O: r/uc(15) or if there is more than one connection, it must include the connectionID e.g.: O: r/uc@connectionID(15) Codec Changed: Codec changed to payload type enclosed in parenthesis, as in UC(15), to indicate the codec was changed to G.728. Payload types are specified in RFC 1890, or in a new definition of the audio profiles for RTP that replaces this RFC. Arango et al. Informational [Page 23] Basic MGCP Packages January 2001 Sampling Rate Changed: Sampling rate changed to decimal number in milliseconds enclosed in parenthesis, as in SR(20), to indicate the sampling rate was changed to 20 milliseconds. Jitter Buffer Size Changed: When the media gateway has the ability to automatically adjust the depth of the jitter buffer for received RTP streams, it is useful for the media gateway controller to receive notification that the media gateway has automatically increased its jitter buffer size to accommodate increased or decreased variability in network latency. 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 the new size of the jitter buffer, in milliseconds. Packet Loss Exceeded: Packet loss rate exceed the threshold of the specified decimal number of packets per 100,000 packets, where the packet loss number is contained in parenthesis. For example, PL(10) indicates packets are being dropped at a rate of 1 in 10,000 packets. Quality alert: The packet loss rate or the combination of delay and jitter exceed a specified quality threshold. Continuity tones (co1 and co2): These are the same as those defined in the Trunk package except in this case they are only played over a network connection and the connectionID should be supplied (e.g. "s: r/co1@connectionID"). They can be use in conjunction with the Network LoopBack (netwloop) or Network Continuity Test (netwtest) modes to test the continuity of an RTP circuit. Alternatively, an embedded request could be used e.g. for doing a loopback: R: co1@connID(E(S(co1@connID))) Operation failure (of): The "operation failure" code can be used to report problems such as the loss of underlying connectivity. The observed event can include as parameter the reason code of the failure. Note that the more common approach is for the gateway to send an autonomous delete connection command to the Call Agent and include a reason code as to why it was unable to continue to support the connection. Version (ver): This is a one-shot event. When requested in a Notification Request, the gateway will send an immediate Notify with observed event ver(), where in this case has the value "1". If the gateway does not support the versioned package it will respond with a "nack" (error code 512 - not equipped to detect requested event). Arango et al. Informational [Page 24] Basic MGCP Packages January 2001 2.11. Resource Reservation Package Package Name: RES 2.11.1. Description The "RES" package provides local connection option support for resource reservations. A number of LocalConnectionOption parameters are used in doing resource reservations: "reservation request", "reservation direction", "reservation confirmation" and "resource sharing". Reservation Request LocalConnectionOption: The gateways can be instructed to perform a reservation, for example using RSVP, on a given connection. When a reservation is needed, the Call Agent will specify the reservation profile that should be used, which is either "controlled load" or "guaranteed service." The absence of reservation can be indicated by asking for the "best effort" service, which is the default value for this parameter. Whether or not RSVP will be done is dependent on whether the reservation request LocalConnectionOption parameter has been included in a connection request for this connection (with either "controlled load" or "guaranteed service" indicated). If a modify connection (MDCX) request requires a change in the reservation and the "reservation request" parameter is not included in the LocalConnectionOptions but was included in the LocalConnectionOptions for a previous connection request for that connection, then "reservation request" value defaults to its previously saved value for that connection. If a modify connection (MDCX) request contains a "reservation request", indicating a request for "best effort" for a connection that has an existing reservation, the reservation will be torn down. Reservation Direction LocalConnectionOption: When reservation has been asked on a connection, the gateway will examine the reservation direction LocalConnectionOption parameter to determine the direction that reservations are required and do the following: * start emitting RSVP "PATH" messages if the reservation direction LocalConnectionOptions parameter is in "send-only" or "send- receive" modes. * start emitting RSVP "RESV" messages as soon as it receives "PATH" messages if the reservation direction parameter is in "receive- only" or "send-receive" modes. 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: Arango et al. Informational [Page 25] Basic MGCP Packages January 2001 * 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 pre- condition is for acknowledging a successful connection request: * If the reservation confirmation parameter is to "none", The gateway will "Ack" the connection request without waiting for reservation completion. * If the "reservation confirmation" parameter is set to "send-only", the gateway will "Ack " when the RESV is received to indicate reservation in the send direction. * If the "reservation confirmation" parameter is set to "receive- only", the gateway will "Ack" when reservation confirm has been receive * If the reservation confirmation parameter is to "send-receive", the gateway will "Ack" only after RESV has been received for send direction and reservation confirm has been received for the receive direction. Note that: Values "receive-only" and "send-receive" are triggers for the gateway to request reservation confirm when it sends out the RESV. Pre-conditions should only be added for the direction(s) for which resource reservations have been requested. If a direction is added as a precondition and that direction was not requested in the resource reservation, the direction is simply ignored as a pre- condition. In this approach, resource reservation success is the pre- condition to final acknowledgement of the connection request. If the reservation fails, the connection request also fails (error code 526 - insufficient bandwidth) - as will any notification request included as part of the connection request. A typical example of this would be a request to ring the phone, included with the connection request. If the reservation fails, the phone will not ring. Arango et al. Informational [Page 26] Basic MGCP Packages January 2001 A provisional response should be provided if confirmation is expected to occur outside the normal retry timers and in fact a provisional response must be provided regardless if reservation confirmation parameter has value "send-receive" (Without a provisional response, SDP information cannot be returned until the final "Ack" which will not occur until the reservation is complete. This results in a deadlock since the SDP information typically needs to be passed to the other end in order for it to initiate the RSVP PATH in the other direction). The SDP information and connectionID must be included in both the provisional response and the final response. In order to ensure rapid detection of a lost final response, it is recommended that final responses issued after provisional responses for a transaction be acknowledged i.e. include an empty "ResponseAck" parameter in the final response. 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 provisional response will not be necessary). Resource Sharing LocalConnectionOption: It may be possible to share 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 indicates possible future plans 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 be share resources with the connection indicated) * The value can be empty, which indicates a request to no longer share the resources of this connection with other connections 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. Arango et al. Informational [Page 27] Basic MGCP Packages January 2001 Note that if RSVP is used with dynamic quality of service [17], then the parameters in NCS [16] would be used instead of the reservation direction, confirmation and reservation sharing parameters described here. 2.11.2. Parameter Encoding The Local Connection Options for the "RES" package consist of the following: * The resource reservation parameter, encoded as the keyword "r", followed by a colon and the value "g" (guaranteed service), "cl" (controlled load) or "be" (best effort). * The reservation direction parameter, encoded as the keyword "r-dir" followed by a colon and the value "sendonly", "recvonly" or "sendrecv". * The reservation confirmation parameter, encoded as the keyword "r-cnf" followed by a colon and the value "none", "sendonly", "recvonly" or "sendrecv". * The resource sharing parameter, encoded as the keyword "r-sh" followed by a colon and either: * the wild-card character "$" indicating this connection, indicating future plans to share resources with this connection, or * a connection ID, indicating a request to share resources with the connection having the specified connection ID (and all other connections sharing resources with that connection), or * an empty value, indicating a request to no longer share the resources of this connection with other connections Note that normally local connection options that are associated with a package should have the package prefix included as per the package extension rules in [1]. The local connection options in the "RES" package are exceptions. The package prefix is not included in the case of the "RES" package because it was created before the extension rules in [1] were defined. Arango et al. Informational [Page 28] Basic MGCP Packages January 2001 2.12. Announcement Server Package Package Name: A ------------------------------------------------------------- | Symbol | Definition | R | S Duration | |-------------------------------------------------------------| | ann(url,parms) | Play an announcement | | TO variable | | oc | Report on completion | x | | | of | Report failure | x | | ------------------------------------------------------------- The announcement action is qualified by an URL name and by a set of initial parameters as in for example: S: ann(http://scripts.example.net/all-lines-busy.au) The "operation complete" event will be detected when the announcement is played out. If the announcement cannot be played out, an operation failure event can be returned. The failure may be explained by a commentary, as in: O: A/of(file not found) 2.13. Script Package Package Name: Script ------------------------------------------------------------- | Symbol | Definition | R | S | Duration | |-------------------------------------------------------------| | java(url) | Load a java script | | TO | variable | | perl(url) | Load a perl script | | TO | variable | | tcl(url) | Load a TCL script | | TO | variable | | xml(url) | Load an XML script | | TO | variable | | vxml(url) | Load a VXML script | | TO | variable | | oc | Report on completion | x | | | | of | Report failure | x | | | ------------------------------------------------------------- The "language" action define is qualified by an URL name and by a set of initial parameters as in for example: S: script/java(http://scripts.example.net/credit- card.java,long,1234) The current definition defines keywords for the most common languages. More languages may be defined in further version of this documents. For each language, an API specification will describe how the scripts can issue local "notificationRequest" commands, and receive the corresponding notifications. Arango et al. Informational [Page 29] Basic MGCP Packages January 2001 The script produces an output which consists of one or several text string, separated by commas. The text string are reported as a commentary in the report on completion, as in for example: O: script/oc(21223456794567,9738234567) 3.0. Acknowledgements These packages are an update of the original packages in RFC 2705 along with some new packages. Thanks to a number of people, including but not limited to: Jerry Kamitses, Sonus Networks; Dave Auerbach, Cisco Systems; Ed Guy, Telcordia Technologies. Arango et al. Informational [Page 30] Basic MGCP Packages January 2001 4.0. References [1} Arango et al, Media Gateway Control Protocol (MGCP)Version 1.0bis, draft-andreasen-mgcp-rfc2705bis-00.txt [2] Technical Characteristics of Tones for the Telephone Service, ITU-T E.180 [3] Various Tones Used in National Networks, ITU-T E.180, Supplement 2. [4] Applications of Tones and Recorded Announcements in Telephone Services, ITU-T, E.182 [5] LSSGR: Signaling for Analog Interfaces, GR-506-CORE [6] Bellcore Notes on the Network, Special Report SR-2275 [7] ANSI T1.207-1989, American National Standard for Telecommunications - Operations, Administration, Maintenance, and Provisioning (OAM&P) - Terminating Test Line Capabilities and Access Arrangements. [8] ANSI T1.207a-1995 Supplement to ANSI T1.207.1989(R1995), American National Standard for Telecommunications - Operations, Administration, Maintenance, and Provisioning (OAM&P) - Terminating Test Line Capabilities and Access Arrangements (expanded test line capabilities). [9] Handley, M, Jacobson, V., SDP: Session Description Protocol, RFC 2327, April 1998 5.0. Authors' Addresses Mauricio Arango 901 San Antonio Road, UMPK15-214 Palo Alto, CA 94303 Email: Mauricio.Arango@sun.com Andrew Dugan Level3 Communications 1025 Eldorado Blvd Broomfield, CO 80021 Phone: +1 720 888 2983 EMail: andrew.dugan@level3.com Isaac Elliott Level3 Communications 1025 Eldorado Blvd., Bldg 4000 Broomfield, CO 80021 Arango et al. Informational [Page 31] Basic MGCP Packages January 2001 Phone: +1 720 888 6763 EMail: ike.elliott@level3.com Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: huitema@microsoft.com Scott Pickett Vertical Networks 1148 East Arques Ave Sunnyvale, CA 94086 Phone: +1 408 585 3200 EMail: ScottP@vertical.com Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837 Phone: +1 732 452 1667 EMail: fandreas@cisco.com Bill Foster Cisco Systems 170 West Tasman Dr San Jose, CA 95134 Phone: +1 408 527 8791 EMail: bfoster@cisco.com 6.0. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Arango et al. Informational [Page 32] Basic MGCP Packages January 2001 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Arango et al. Informational [Page 33]