Internet Engineering Task Force M. Arango Internet Draft SUN Microsystems Document: <draft-foster-mgcp-basic-packages-01.txt> A. Dugan Category: Informational I. Elliott Expires: January 2002 Level3 Communications C. Huitema Microsoft S. Pickett Vertical Networks B. Foster F. Andreasen R. Kumar Cisco Systems July 2001 Basic MGCP Packages Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides a basic set of MGCP packages. The generic, line, trunk, handset, RTP, DTMF, announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, six new packages have been added. These are the signal lists, resource reservation, media format, supplementary services tones, country specific tones and digit map extension packages. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Arango et al. Informational [Page 1]
Basic MGCP Packages July 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 | | Country Specific Tone Package | CST | | Digit Map Extension | DM1 | | Signal List Package | SL | | Media Format Package | FM | | RTP Package | R | | Resource Reservation Package | RES | | Announcement Server Package | A | | Script Package | Script | ------------------------------------------- 1.2. Changes to Existing Packages 1.2.1. Change in signal types MGCP 1.0 as defined in RFC 2705 provided some additional clarification on the meaning of OO signals compared to earlier versions of MGCP. This leads to some inconsistency in some of the signal definitions in the accompanying packages. This has been corrected in the packages that are included here by changing some of the signals from type OO to type TO. 1.2.2. Operation Complete and Operation Failure Another change also made to improve consistency and interoperability was to add the "operation complete" and "operation failure" events in packages where there are TO events defined but where the events were not included as part of the package. By definition, all packages that contain Time-Out type signals now contain the operation failure ("of") and operation complete ("oc") events as defined in [1], irrespective of whether they are provided as part of the package description or not. If a package without Time-Out signals does contain definitions for the "oc" and "of" events, the event definitions provided in the package may over-ride those indicated here. Such practice is however discouraged and is purely allowed to avoid potential backwards compatibility problems. Arango et al. Informational [Page 2]
Basic MGCP Packages July 2001 It is considered good practice to explicitly mention that the two events are supported in accordance with their default definitions. If no definition is included in the package, the above syntax and semantics is assumed. Please refer to [1] for additional details on these events. 1.2.3. Package Versions Some of the packages included in this document are new versions of packages that were previously contained in RFC 2705. The base specification [1] provides an optional capability of auditing package versions. Any gateway that implements versioned packages SHOULD also implement this option. 1.2.4. Event Definitions, Aliases and Interoperability Issues Some event definitions or clarifications of previous event definitions have also been added in order to improve interoperability. In some cases events have aliases either in the same or in other packages and a recommendation has been made for the use of alternates by Call Agents for future implementations. For maximum interoperability gateways must still implement these events (in fact they must implement all of the events, signals, etc. in a package). Some events that were previously defined require specific provisioning in both the gateway and the Call Agent in order to allow for interoperability. In those cases, a warning to that affect has been included. 1.2.5. New Events In some cases new events have been added to existing packages. Any changes to existing packages of course have resulted in the version number being updated from unversioned (version 0) to version 1. 1.3. New Packages and Excluded Packages Two packages from RFC 2705 have not been included. These are the "MF" and the "NAS" package. These packages are still valid as are all unversioned (version 0) packages defined in RFC 2705. The reason these packages were not included: * The original MF package had no defined way to outpulse MF digits - so that a separate RFC was developed for MF CAS (RFC 3064). * The "N" package as defined in RFC 2705 was incomplete. A more complete MGCP "NAS" package has been developed and provided as a separate Internet draft. New packages have also been included beyond what was included in the original RFC 2705. The Resource Reservation ("RES") and Media Format ("FM") packages in particular are different from other packages in Arango et al. Informational [Page 3]
Basic MGCP Packages July 2001 this document in that they do not contain events and signals but simply define extra LocalConnectionOptions. This is allowed by the new extension rules in [1]. Future packages of this type should use a packages prefix in front of local connection options ("<package- name>/<Local Connection Option>") so as to avoid name-space problems. However because of the timing of the arrival of these packages relative to updating MGCP 1.0 this was not done for the "RES" and "FM" packages. The resulting new local connection options will be registered with IANA. For future cases where a package prefix is included, only the package name needs to be registered. 2. Packages For those packages that involve MGCP events, the terms "signal" and "event" are used to differentiate a request from a Call Agent to a Media Gateway to apply an event ("signal"), from requesting the detection of an "event" that occurs on the Media Gateway and is "Notified" to the Call Agent. For packages that involve events and signals the tables contain five columns: Symbol: the (package) unique symbol used to identify the event. Definition: a short description of the event. R: an x appears in this column if the event can be requested by the Call Agent. Alternatively, one or more of the following symbols may appear. An "S" is included if the event-state may be audited. A "C" indicates that the event can be detected on a connection, and a "P" indicates the event is persistent. S: if nothing appears in this column for an event, then the event cannot be signaled by the Call Agent. Otherwise, the following symbols identify the type of event: * OO On/Off signal. * TO Time-Out signal. * BR Brief signal. In addition, a "C" will be included if the signal can be generated on a connection. Duration: specifies the duration of TO signals. If a duration is left unspecified then the default timeout will be assumed to be infinite unless explicitly noted in the description of the signal. A duration may also be declared as being variable in a case where signals involve complex sequencing (e.g. scripts or digit out-pulsing) where the amount of time may vary with either processing time or the signaling environment. Arango et al. Informational [Page 4]
Basic MGCP Packages July 2001 Default time-out values may be over-ridden by the Call Agent for any Time-Out event defined in this document by a "to" signal parameter which specifies the timeout value in milliseconds (see [1]). Example: S: sst/cw(to=20000) indicates a timeout value of 20 seconds. In some of the signal definitions below, specific tone definitions are provided even though actual frequencies may vary from country to country. Country variations should be handled by gateway provisioning. 2.1 Generic Media Package Package Name: G Version: 1 The generic media package groups the events and signals that can be observed on several types of endpoints, such as trunk gateway endpoints, access gateway endpoints or residential gateway endpoints. --------------------------------------------------------------- | Symbol | Definition | R | S Duration | |---------------------------------------------------------------| | cf | Confirm tone | | BR | | cg | Congestion tone | | TO infinite | | ft | Fax tone detected | x | | | it | Intercept tone | | TO infinite | | ld | Long duration connection | C | | | mt | Modem detected | x | | | oc | Operation complete | x | | | of | Operation failure | x | | | pt | Preemption tone | | TO infinite | | rt | Ringback tone | C | TO,C 180 seconds| | rbk(###) | Ringback | | TO,C 180 seconds| | pat(###) | Pattern Detected | x | OO | --------------------------------------------------------------- New events added to this package from the previously unversioned package: "oc" Changes: "it" and "pt" signals changed from OO to TO; the ability to detect "rt" over a connection was added. The events are defined as follows: Confirmation Tone (cf): This is also referred to as "positive indication tone" in ITU-T E.182. In North America, Confirmation Tone uses the same frequencies and levels as dial tone (350 and 440 Hertz) but with a cadence of 0.1 second on, 0.1 second off repeated three times. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.4. It is Arango et al. Informational [Page 5]
Basic MGCP Packages July 2001 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). Congestion Tone (cg): Refer to ITU-T E.180 and E.182. This maps to re-order tone in North America (refer to GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7). Fax tone (ft): Indicates that V.21 fax preamble detected. Intercept tone(it): This is a country specific tone as defined in ITU-T, E.180 Supplement 2. Long Duration (ld): The "long duration connection" is detected when a connection has been established for more than some time. The default value is 1 hour, however the provisioning process may change this. The event is detected on a connection. When no connection is specified as part of the request, the event applies to all connections for the endpoint, regardless of when the connections are created. The "all connections" may also be used for this case, and is in fact preferred for consistency. In either case, the name of the connection on which the event was detected will be included when the event is observed, e.g.: G/ld@0A3F58 Modem tones (mt): Indicates V.25 Answer tone with or without phase reversals or V.8 Modified Answer Tone (ANSam) tone with or without phase reversals. Note that this implies the presence of a data call. Also note that despite the name of the event, devices other than modems may generate such tones, e.g. a fax machine. Preemption Tone (pt): This is a country specific tone and is defined in ITU-T, E.180 Supplement 2. Ring back tone (rt): Refer to ITU E.180 and ITU E.182. Also referred to as ringing tone - a tone advising the caller that a connection has been made and that a calling signal is being applied to the called party or service point. In North America this tone is a combination of two AC tones with frequencies of 440 and 480 Hertz and levels of -19 dBm each, to give a combined level of -16 dBm. The cadence for Audible Ring Tone is 2 seconds on followed by 4 seconds off. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.5. This signal can be applied directly to an endpoint or alternatively on a connection using the syntax "rt@connectionID". When the ringback signal is applied to an endpoint, it is considered an error to try and play ring back tones, if the endpoint is considered on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). When the ringback signal is applied to a connection, no such check is to be made. Arango et al. Informational [Page 6]
Basic MGCP Packages July 2001 Note that as specified in [1], signals requested on a connection should 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. Ringback (rbk): is an alias for rt@connectionID and is included here for backwards compatibility only. It is recommended that Call Agents use rt@connectionID instead of rbk(connectionID) for ring-back over a connection for new implementations. Although the ringback signal is applied on a connection, the ringback signal does not support the "@connection" syntax. pat(###): pattern detected. This event requires special provisioning that needs to be agreed on between the Call Agent and media gateway in order to ensure interoperability. It is retained in order to maintain backwards compatibility with version 0 of the "G" package. 2.2. DTMF package Package name: D Version: 1 -------------------------------------------------------------- | Symbol | Definition | R | S Duration | |--------------------------------------------------------------| | 0 | DTMF 0 | x | BR | | 1 | DTMF 1 | x | BR | | 2 | DTMF 2 | x | BR | | 3 | DTMF 3 | x | BR | | 4 | DTMF 4 | x | BR | | 5 | DTMF 5 | x | BR | | 6 | DTMF 6 | x | BR | | 7 | DTMF 7 | x | BR | | 8 | DTMF 8 | x | BR | | 9 | DTMF 9 | x | BR | | # | DTMF # | x | BR | | * | DTMF * | x | BR | | A | DTMF A | x | BR | | B | DTMF B | x | BR | | C | DTMF C | x | BR | | D | DTMF D | x | BR | | L | long duration indicator | x | | | DD(..) | DTMF tone duration | x | TO 3 seconds | | DO(..) | DTMF OO signal | | OO | | X | Wildcard, match | x | | | | any digit 0-9 | | | | oc | operation complete | x | | | of | operation failure | x | | | T | Interdigit timer | x | | -------------------------------------------------------------- Changes from the previous version of the package: events "dd", "do", "oc" were added. Arango et al. Informational [Page 7]
Basic MGCP Packages July 2001 Note that DTMF tones including the DTMF tones wildcard can use the eventRange notation defined in [1] when requesting events, e.g. "D/[0-9](N)". The events are defined as follows: DTMF tones (0-9,*,#,A,B,C,D): Detection and generation of DTMF signals is described in GR-506-CORE - LSSGR: SIGNALING, Section 15. Note that it is considered an error to try and play DTMF tones on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). The events can be specified in a digit map. When requested as a signal, as per GR-506-CORE, section 15, a minimum tone duration of 50 ms will be followed by a minimum interdigit silence period of 45 ms, i.e. if requested in a signal list such as S: sl/s(d/5,d/6,d/7), then interdigit timing requirements will be satisfied. Long Duration Indicator (l): The "long duration indicator" is observed when a DTMF signal is produced for a duration larger than two seconds. In this case, the gateway will detect two successive events: first, when the signal has been recognized, the DTMF signal, and then, 2 seconds later, the long duration signal. DTMF Tone Duration (dd(dg=<tone>,to=<time>)): This event can be used to indicate if/when the specified <tone>, has a duration greater than the <time> value indicated (and is reported once when the duration is exceeded). The value of <tone> can be any of the DTMF tone symbols specified in the DTMF package (including X in the case of events, but not signals). If this parameter is absent, any DTMF tone that occurs will be reported. The parameter <time> is in milli-seconds and may be rounded to the nearest 10 ms by the gateway. The minimum value of <time> that can be requested when requesting an event is 40 ms. When requesting a signal, the minimum value of <time> that can be requested is 50 ms. The maximum value of the <time> that can be requested for either an event or a signal is 60000 ms. If the "to=<time>" parameter is absent when requested as an event, the event will report the full duration of the tone when the tone is completed. When reported as an ObservedEvent, both parameters are always supplied. In this case <tone> is the actual tone detected and <time> is either: * The <time> specified in the request (possibly rounded), or * If the request did not contain a "to=<time>" parameter, the full duration of the tone. When used as a signal, "dd" provides the ability to generate a DTMF tone as a TO signal. When applied as a signal, an additional 50 ms of silence will be tacked onto the end before the operation complete occurs i.e. S: dd(dg=5,to=2500) will play the DTMF tone for the number "5" for 2.5 seconds, followed by 50 ms of silence period. The operation complete (if requested) will be notified after the silence interval occurs. Any value between 50 ms and 60000 ms can be Arango et al. Informational [Page 8]
Basic MGCP Packages July 2001 requested. Gateways generating or detecting the tone may round-off the requested time to the nearest 10 ms. The "dd" event can be used in place of the "l" event in order to detect a digit pressed for longer than 2 seconds. For example, in order to detect if a user presses the long "#" for longer than 2 seconds, a request could be made with the RequestedEvents line "R: d/dd(N)(dg=#,to=2000)". The resulting ObservedEvents line would be "O: d/dd(dg=#,to=2000)". Suppose instead, that the RequestedEvents line contains R: d/[0-9*#],d/dd Suppose the user then pushes the "#" for 2.5 seconds. In this case, two events will be notified: O: d/# when the "#" key is first pressed, and O: d/dd(dg=#,to=2500) when the "#" key is finally depressed. If instead, the Requested event line had contained R: d/dd(N)(to=40),d/dd In that case, almost the same results would be obtained: O: d/dd(dg=#,to=40) after the "#" key is pressed for 40 ms, and O: d/dd(dg=#,to=2500) when the "#" key is finally depressed. DTMF OO signal (do(dg=<tone>,<on-or-off>)): This signal is used to generate a DTMF tone as an on-off signal. The <tone> parameter is any of the symbols for a specific tone in the DTMF package (i.e. "0" to "9", "A", "B", "C", "D", "*", or "#"). The <on-or-off> indicator is "+" for on and "-" for off as usual. The <tone> parameter MUST be supplied, otherwise a return code of 538 - "Event/signal parameter error" will be provided in the response. If the <on-or-off> parameter is missing, the default is to turn the signal on (i.e. "+" is the default). The order of the parameters is not significant since "+" and "-" are reserved characters and are easily distinguished from the <tone> parameter. Operation complete (oc): This is the standard definition of operation complete. Arango et al. Informational [Page 9]
Basic MGCP Packages July 2001 Operation failure (of): This is the standard definition of operation failure. DTMF tones wildcard (X): The DTMF tones wildcard matches any DTMF digit between 0 and 9. The actual event code generated will however be the event code for the digit detected. The DTMF tones wildcard is often used to detect DTMF input to be matched against a digit map. Timer (t): Timer T is a digit input timer that can be used in two ways: * When timer T is used with the accumulate according to digit map action, the timer is not started until the first DTMF tone is entered, and the timer is restarted after each new DTMF tone is entered until either a digit map match or mismatch occurs. In this case, timer T functions as an inter-digit timer as illustrated by: R: D/[0-9T](D) * When timer T is used without the accumulate according to digit map action, the timer is started immediately and simply cancelled (but not restarted) as soon as a DTMF tone is entered. In this case, timer T can be used as an inter-digit timer when overlap sending is used, as in: R: D/[0-9](N), D/T(N) When used with the "accumulate according to digit map" action, timer T takes on one of two values, T-partial or T-critical. When at least one more symbol is required for the "current dial string" to match any one of the patterns in the digit map, timer T takes on the value T-partial, corresponding to partial dial timing. If a timer is all that is required to produce a match, timer T takes on the value T- critical corresponding to critical dial timing. When timer T is used without the accumulate according to digit map action, timer T takes on the value T-critical. The default value for T-partial is 16 seconds and the default value for T-critical is 4 seconds. The provisioning process may alter both of these. If timer T is not used, then inter-digit timing will not be performed. The following examples illustrate this. Consider the digit map: (xxxxxxx|x11T) and assume that DTMF and the timer T is accumulated according to digit map. At the first DTMF input, say "4", timer T is started with a value of T-partial since at least one more symbol is required. If "1" is then input, it leads to a restart of timer T with a value of T-partial again. If "1" is now input again, we have a current dial string of "411" and a timer is now all that is required to produce a match. Hence timer T is now restarted with value T-critical. Arango et al. Informational [Page 10]
Basic MGCP Packages July 2001 Finally, consider the following subtle examples (all assuming DTMF and timer T being accumulated according to digit map): The digit map (1[2-3T].) will match immediately on the input "1" since zero or more matches of the range are specified. The digit map (1[2-3].T) and an input of "1" will lead to timer T being set to T-critical. A digit map of (1[2-3]T.) and an input of "1" will lead to timer T being set to T-partial. Furthermore, upon subsequent input of "2" or "3" a perfect match will trigger immediately since timer T is completely irrelevant. 2.3. Trunk Package Package Name: T Version: 1 ---------------------------------------------------------------- | Symbol | Definition | R | S Duration | |----------------------------------------------------------------| | co1 | Continuity tone (go tone, | x | TO 3 sec. | | | or return tone) | | | | co2 | Continuity test (go tone, | x | TO 3 sec. | | | or return tone in dual tone | | | | | procedures) | | | | lb(##) | Loopback | | OO | | nm | New Milliwatt Tone | x | TO 3 sec | | mm | Newest Milliwatt Tone | x | TO 3 sec | | oc | Operation Complete | x | | | of | report failure | x | | | om | Old Milliwatt Tone | x | TO 3 sec | | qt | Quiet Termination | | TO infinite | | ro | Reorder Tone | x | TO 30 sec. | | sit(##) | Special Information Tone | x | TO 2 sec. | | | | | (see notes) | | tl | Test Line | x | TO infinite | | tp(##) | Test pattern | x | TO 3 sec | | zz | No circuit | x | TO infinite | | as | Answer Supervision | x | BR | | bl | Blocking | | BR | ---------------------------------------------------------------- Arango et al. Informational [Page 11]
Basic MGCP Packages July 2001 New events added to this package from the previously unversioned package: "oc", "mm", "qt", "sit", and "tp", "lb". Changes in event types: "co1", "co2", "lb", "nm", "om", "tl", "zz" signals changed from OO to TO; "as" and "bl" changed form OO to BR. The definition of trunk package events are as follows: Continuity Tone (co1): A tone at 2010 Hz (see section 3.1.1.3 of [13]). When generated as a signal, the frequency of the tone must be within + or - 8 Hz, while the frequency of the tone corresponding to the event must be within + or - 30 Hz. Continuity Test (co2): A tone at 1780 Hz (see section 3.1.1.3 of [13]). When generated as a signal, the frequency of the tone must be within + or - 20 Hz, while the frequency of the tone corresponding to the event must be within + or - 30 Hz. In continuity testing the tone corresponding to the signal at the originating gateway is referred to as the "go" tone and the tone corresponding to the event at that same gateway is referred to as the "return" or "check" tone. Note that generation and notification of continuity tones are done as per continuity test requirements as defined in ITU-T Q.724 as well as by Bellcore GR-317-CORE specifications e.g. the semantics of notification of the return tone is more than that the tone was received, but is an indication that the test has passed. Details are provided in the following paragraphs. The continuity tones represented by co1 and co2 are used when the Call Agent wants to initiate a continuity test. There are two types of tests, single tone and dual tone and in the case of the dual-tone either tone can be sent and the opposite received depending on the trunk interconnections (4-wire or 2-wire) as indicated below: Originating Terminating ============ =========== 4w -------------- 1780 Hz -----------> 2w <------------- 2010 Hz ------------ (transponder) 2w -------------- 2010 Hz -----------> 2w/4w <------------- 1780 Hz ------------ (transponder) 4w -------------- 2010 Hz -----------> 4w <------------- 2010 Hz ------------ (loopback) The Call agent is expected to know, through provisioning information, which test should be applied to a given endpoint. As an example, for a 4-wire to 2-wire connection, the Call Agent might send a request like the following to an originating gateway: Arango et al. Informational [Page 12]
Basic MGCP Packages July 2001 RQNT 1234 ds/ds1-1/17@tgw2.example.net X: AB123FE0 S: t/co1 R: t/co2,t/oc,t/of On a terminating side of a trunk, the call agent may request a continuity test connection (connection mode "conttest") to the terminating gateway as follows: CRCX 3001 ds/ds1-2/4@tgw34.example.net C: 3748ABC364 M: conttest The originating gateway would send the requested "go" tone, and would look for the appropriate "return tone". Once the return tone is received, the originating gateway removes the go tone and checks to see that return tone has been removed within specified performance limits (i.e. GR-246-CORE, T1.113.4, Annex B). When it detects that the test is successful, the gateway will send a notification of the return tone event (Note that notification of the return tone event therefore must not be sent prior to detection of the removal of the return tone). The signals corresponding to the continuity tones are TO signals so that an operation complete event will occur when the signal times out. If a timeout value other than the default is desired, the "to" parameter may be used (e.g. "S: co1(to=2000)"). Note that removal of the go tone by the gateway is determined by continuity test requirements (i.e. it is under control of the gateway) and is not determined by the timout period. If the gateway detects the failure of the continuity test prior to the timeout, an operation failure event will be generated. Otherwise the failure of the continuity test is determined by the failure to receive the return tone event before the timeout occurs (operation complete event). As with TO signals in general, operation complete and operation fail events are parameterized with the name of the signal. In the example above where the go tone is "co1" and the return tone is "co2": * A notification of the "co2" event indicates success ( i.e. "O: t/co2") * A notification of the operation fail event indicates failure prior to timeout (i.e. "O: t/of(t/co1)") and * A notification of the operation complete event, indicates that the return tone was not received properly prior to the occurrence of the timeout (i.e. "O: t/oc(t/co2)") On a terminating end of a trunk, either a "loopback" connection (single tone test) or "conttest" connection (dual tone test) are made. It is up to the termination end to make sure that the return Arango et al. Informational [Page 13]
Basic MGCP Packages July 2001 tone is removed as soon as the go tone disappears. The Call Agent does the removal of "contest" or "loopback" connections at a termination end when the results of the continuity test are obtained. Note that continuity tones in the trunk package are only ever sent to the telephony endpoint. For network-based continuity, there are continuity tones available in the RTP ("R") package. Although a transponder (dual tone) test can be done, a single tone test is generally sufficient in the case of continuity testing across an IP network. Loopback (lb(in=<tone-in>,out=<tone-out>, <+ or ->): This signal is used to provide loopback or transponder functionality independent of connection mode, i.e. this is an alternative way to provide the same functionality as "conttest" and "loopback" connection modes. The <tone-in> and <tone-out> parameters can have values "co1" or "co2" corresponding to the 2010 Hz and 1780 Hz tones associated with those symbols. If these parameters are left out, the value of <tone-in> defaults to 2010 Hz and the value of <tone-out> defaults to 1780 Hz. The provisioning process may alter both of these values (in fact these default values would be incorrect for a test from a 4-wire switch to a 2-wire switch). On detecting <tone-in>, <tone-out> will be generated in return. The tone corresponding to <tone-out> will continue to be generated until either: * The loopback signal is explicitly turned off (e.g. "S: t/lb(-)") or * Removal of the <tone-in> tone is detected. Note that while the loop-back signal is active (regardless of whether a tone is active or not), media from the endpoint will not be forwarded to the packet network (i.e. the loopback signal must be explicitly turned off by the Call Agent in order to allow media to be forwarded to the endpoint). New Milliwatt Tone (nm): 1004 Hz tone - refer to [7] and section 8.2.5 of [6]. Newest milliwatt Tone (mm): 1013.8 Hz - refer to [7]. Old Milliwatt Tone (om): 1000 Hz tone - refer to [7] and section 8.2.5 of [6] Quiet Termination (qt): used in 102 test Trunk. Reference section 6.20.5 [6] as well as [7]. Reorder Tone(ro): This maps to congestion tone in the ITU E.182 specification. In North America, reorder tone is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for reorder tone is 0.25 seconds on followed by 0.25 seconds off, repeating Arango et al. Informational [Page 14]
Basic MGCP Packages July 2001 continuously (until time-out). See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7. Special Information Tone(sit(###)): As described in ITU-T E.180, the special information tone consists of a tone period in which 3 tones are produced followed by a silent period of 1 second (total TO period of approximately 2 seconds). When used as a signal, it must be parameterized with a parameter value from 1 to 7 with the following meaning as defined in SR-2275, section 6.21.2 [6]: ------------------------------------------- | sit(1) | RO' | reorder SIT, intra-LATA | | sit(2) | RO" | reorder SIT, inter-LATA | | sit(3) | NC' | no circuit SIT, intra-LATA | | sit(4) | NC" | no circuit SIT, inter-LATA | | sit(5) | IC | intercept SIT | | sit(6) | VC | vacant code SIT | | sit(7) | IO | ineffective other SIT | ------------------------------------------- When requested as an event, the event must be parameterized with a decimal number from 1 to 7 to indicate which tone the gateway is required to detect. The resulting notification also includes the parameter. Other countries may have one or more special information tones with country specific definitions (refer to ITU-T E.180 supp. 2 [3]). In this case special information tone 1 as defined in [3] is sit(1), special information tone 2 is sit(2) etc. As an example, the Call Agent might make a request such as: RQNT 1234 ds/ds1-1/17@tgw2.example.net X: AB123FE0 R: t/sit(N)(2) If the tone is detected, the resulting notification might appear as follows: NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: AB123FE0 O: t/sit(2) Line Test (tl): 105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0). Refer to section 8.2.5 of [6]. Test Pattern (tp(##)): The tp(##) signal inserts the pattern ## continuously into the channel until the timout period expires. The parameter is provided as a decimal number from 0 to 255. If the parameter is omitted, the default value is decimal 95. In RequestedEvents, the parameter may be supplied to indicate what pattern the Call Agent wishes the gateway to detect. If the parameter Arango et al. Informational [Page 15]
Basic MGCP Packages July 2001 is omitted, the value 95 is assumed. The pattern must be returned in the ObservedEvent (even if the parameter was not requested). A typical use for the test pattern signal is for the test line 108 (digital loopback) test (refer to section 8.2.5 of [6]). At the termination side of a trunk, the Call Agent would request a connection in "loopback" mode, which would do a digital loopback. On the origination side of the trunk, the Call Agent would request that the test pattern be injected into the digital channel, and would check to see that the pattern was returned within the timeout period. As an example, the Call Agent would make the following request on the origination side: RQNT 1234 ds/ds1-1/17@tgw2.example.net X: AB123FE0 S: t/tp R: t/tp, t/oc, t/of In this case the Call Agent will either receive: * An ObservedEvent indicating that the test has passed (i.e. "O:t/op(95)") or * An ObservedEvent indicating that the timeout occurred before the pattern was received (i.e. "O:t/oc(t/tp)"), indicating that the test failed. Of course an operation failure would indicate failure as well. No circuit (zz): This is an alias for Special Information Tone 2, i.e. "sit(2)". Answer Supervision (as): This event is used for off-hook representing "answer" in CAS. An alternative is to use the "answer" event in the appropriate CAS packages [12]. Blocking (bl): This event is used to indicate an incoming off-hook for the purposes of blocking a one-way trunk in CAS trunks. An alternative is the "block" event in the appropriate CAS packages [12]. Arango et al. Informational [Page 16]
Basic MGCP Packages July 2001 2.4. Line Package Package Name: L Version: 1 ---------------------------------------------------------------- |Symbol | Definition | R | S Duration | |----------------------------------------------------------------| |adsi(string) | adsi display | | BR | |aw | Answer tone | x | OO | |bz | Busy tone | | TO 30 sec. | |ci(ti,nu,na) | Caller-id | | BR | |dl | Dial tone | | TO 16 sec. | |e | Error tone | x | TO 2 sec. | |hd | Off hook transition | S | | |hu | On hook transition | S | | |hf | Flash hook | x | | |ht | On Hold Tone | | TO infinite | |lsa | Line Side Answer Sup. | | TO infinite | |mwi | Message waiting ind. | | TO 16 sec. | |oc | operation complete | x | | |of | operation failure | x | | |oi | open interval (LCFO) | | TO 900 ms | |ot | Off hook warning tone | | TO infinite | |rg | Ringing | | TO 180 sec. | |r0, r1, r2, | Distinctive ringing | | TO 180 sec. | |r3, r4, r5, | | | | |r6 or r7 | | | | |ro | Reorder tone | | TO 30 sec. | |rs | Ringsplash | | BR | |sit | Special Information Tone | | TO 2 sec. | | | | | (see notes) | |sl | Stutter dialtone | | TO 16 sec. | |v | Alerting tone | | OO | |vmwi | visual message | | OO | | | waiting indicator | | | |wt | Call Waiting tone | | TO 12 sec | |wt1, wt2, | Alternative call | | TO 12 sec | |wt3, wt4 | waiting tones | | (see notes) | |y | Recorder Warning Tone | | TO infinite | |z | Calling Card Service Tone| | BR | |p | Prompt tone | x | BR | |nbz | Network busy | x | TO infinite | |s(###) | Distinctive tone pattern | x | BR | ---------------------------------------------------------------- New events added to this package from the previously unversioned package: "ht", "oi", and "lsa". Changes in event types: signals "y", "z", changed from OO to TO and BR respectively. Ringing tones were extended to allow for a ring repetition signal parameter. Arango et al. Informational [Page 17]
Basic MGCP Packages July 2001 The description of events and signals in the line package are as follows: ADSI display (adsi): This signal is included here to maintain compatibility with the previous version of this package. The signal is not well-defined and its use is discouraged. Answer tone (aw): This event is included here to maintain compatibility with the previous version of this package. The event is not well-defined and its use is discouraged. Busy tone (bz): Refer to ITU E.180. In North America, station Busy is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for Station Busy Tone is 0.5 seconds on followed by 0.5 seconds off, repeating. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.6. It is considered an error to try and play busy tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Caller Id (ci(time, number, name)): See TR-NWT-001188, GR-30-CORE, and TR-NWT-000031. For backwards compatibility, each of the three fields are optional, however each of the commas will always be included. In accordance with the general MGCP grammar, it is however RECOMMENDED to always include all three fields - an empty quoted string can then be used in lieu of omitting a parameter: The time parameter is coded as "MM/DD/HH/MM", where MM is a two- digit value for Month between 01 and 12, DD is a two-digit value for Day between 1 and 31, and Hour and Minute are two-digit values coded according to military local time, e.g., 00 is midnight, 01 is 1 a.m., and 13 is 1 p.m. The number parameter is coded as an ASCII character string of decimal digits that identify the calling line number. White spaces are permitted if the string is quoted, however they will be ignored. If a quoted-string is provided, the string itself is UTF- 8 encoded (RFC 2279). The name parameter is coded as a string of ASCII characters that identify the calling line name. White spaces are permitted if the string is quoted. If a quoted-string is provided, the string itself is UTF-8 encoded (RFC 2279). A "P" in the number or name field is used to indicate a private number or name, and an "O" is used to indicate an unavailable number or name. The following example illustrates the use of the caller-id signal: S: ci(10/14/17/26, "555 1212", somename) Dial-tone (dl): Refer to the ITU E.180 specification. In North America, dial tone is a combination of two continuous AC tones with frequencies of 350 and 440 Hertz and levels of -13dBm each to give a Arango et al. Informational [Page 18]
Basic MGCP Packages July 2001 combined level of -10 dBm. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.1. It is considered an error to try and play dial-tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Error tone (e): This tone is maintained for backwards compatibility. Tone on-hold (ht): A tone used to reassure a calling subscriber who has been placed on "hold". Refer to ITU-T E.182 [5]. Line Side Answer Supervision (lsa): This provides Reverse Loop Current Feed (RLCF) on the line (refer to GR-506-CORE [5]) and is a way of indicating that the called party has answered for some line- side equipment. Message Waiting Indicator (mwi): Message Waiting indicator tone uses the same frequencies and levels as dial tone (350 and 440 Hertz at - 13dBm each) but with a cadence of 0.1 second on, 0.1 second off repeated 10 times followed by steady application of dial tone. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.3. It is considered an error to try and play message waiting indicator on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Open Interval (oi): This results in a Loop Current Feed Open Signal (LCFO) being applied to the line (refer to GR-506-CORE [5], see also See GR-505-CORE [15], Section 4.5.2.1). This is needed for some customer premises equipment (e.g. certain answering machines) in order to get the equipment to hang up. The default time-out value for this signal is 900 ms. Off-hook warning tone (ot): Off-hook warning tone, also known as receiver Off Hook Tone (ROH Tone). This is the irritating noise a telephone makes when it is not hung up correctly. In North America ROH Tone is generated by combining four tones at frequencies of 1400 Hertz, 2060 Hertz, 2450 Hertz and 2600 Hertz at a cadence of 0.1 second on, 0.1 second off, repeating. GR-506-CORE, Section 17.2.8 contains details about required power levels. It is considered an error to try and play off-hook warning tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Ringing (rg): See GR-506-CORE [5], Section 14. The provisioning process may define the ringing cadence. The ringing signal may be parameterized with the signal parameter "rep" which specifies the maximum number of ringing cycles (repetitions) to apply. The following will apply the ringing signal for up to 6 ringing cycles: S: l/rg(rep=6) If the "rep" parameter is specified, the signal times-out when the number of repetitions are completed (i.e. an operation complete event Arango et al. Informational [Page 19]
Basic MGCP Packages July 2001 can be requested and will occur at the end of the timeout/number of rings) It is considered an error to try and ring a phone that is off hook and an error should consequently be returned when such attempts are made (error code 401 - phone off hook). Distinctive ringing (r0, r1, r2, r3, r4, r5, r6 or r7): See GR-506- CORE - [5], Section 14. Default values for r1 to r5 are as defined for distinctive ringing pattern 1 to 5 in GR-506-CORE. The provisioning process may define the ringing cadence for each of these signals. The distinctive ringing signals may be parameterized with the signal parameter "rep" which specifies the maximum number of ringing cycles (repetitions) to apply. The following will apply the ringing signal for up to 6 ringing cycles: S: l/r1(rep=6) If the "rep" parameter is specified, the signal times-out when the number of repetitions are completed (i.e. an operation complete event can be requested and will occur at the end of the timeout/number of rings) It is considered an error to try and ring a phone that is off hook and an error should consequently be returned when such attempts are made (error code 401 - phone off hook). Reorder Tone (ro): This maps to congestion tone in the ITU E.182 specification. In North America, reorder tone is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for reorder tone is 0.25 seconds on followed by 0.25 seconds off, repeating continuously. Ringsplash (rs): also known as "Reminder ring" is a burst of ringing that may be applied to the physical forwarding line (when idle) to indicate that a call has been forwarded and to remind the user that a CF sub-feature is active. In the US, it is defined to be a 0.5(- 0,+0.1) second burst of power ringing. See Bellcore TR-TSY-000586 - Call Forwarding Sub-features. Special Information Tone (sit): As described in ITU-T E.180, the special information tone (SIT) consists of a tone period in which 3 tones are produced followed by a silent period of 1 second (total TO period of approximately 2 seconds). In North America, multiple SIT tones have been defined (see SR-2275, section 6.21.2 [6]). These tones are available in the trunk package. The particular SIT tone defined here is NC' SIT which corresponds to the signal "t/sit(3)". Stutter Dial tone (sl): Stutter Dial Tone (also called Recall Dial Tone in GR-506-CORE and "special dial tone" in ITU-T E.182) is used to confirm some action and request additional input from the user. An example application is to cancel call-waiting, prior to entering a destination address. Arango et al. Informational [Page 20]
Basic MGCP Packages July 2001 The stutter dial tone signal may be parameterized with the signal parameter "del" which will specify a delay in milliseconds to apply between the confirmation tone and the dial tone. The following will apply stutter dial tone with a delay of 1.5 seconds between the confirmation tone and the dial tone: S: sl(del=1500) It is considered an error to try and play stutter dial tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Alerting Tone (v): a 440 Hz Tone of 2 second duration followed by 1/2 second of tone every 10 seconds. Visual Message Waiting Indicator (vmwi): The transmission of the VMWI messages will conform to the requirements in Section 2.3.2, "On-hook Data Transmission Not Associated with Ringing" in Bellcore TR-H- 000030 and the CPE guidelines in SR-TSV-002476. VMWI messages will only be sent from the gateway to the attached equipment when the line is idle. If new messages arrive while the line is busy, the VMWI indicator message will be delayed until the line goes back to the idle state. If the gateway does a restart (sends a Restart-in- Progress message, the Call Agent must refresh the CPE's visual indicator. See TR-NWT-001401 - Visual Message Waiting Indicator Generic Requirements; and GR- 30-CORE - Voiceband Data Transmission Interface. Call Waiting tone1 (wt, wt1, .., wt4): Refer to ITU E.180. For North American tone definitions refer to GR-506-CORE, Section 14.2. "wt" and "wt1" are both aliases for the default Call Waiting tone which in North America is a 440-Hz tone applied for 300 50 ms. The tone is then repeated once after 10 seconds. These signals are timeout signals with a default timeout value of 12 seconds, which allows the tone to be played twice with a single request. However, there are cases (Requirement R3-73 of GR-575-CORE), where only a single tone is required. In that case, the Call Agent may make the request with a shorter timeout period to eliminate the second tone (e.g. "S: wt(to=1)"). Signals wt2, wt3 and wt4 are alternates that are used for distinctive call-waiting tone patterns. The talking path should be interrupted for a maximum of 400 ms for the application of CW tone. The Call Agent implements the actual call waiting service - see TR-TSY-000571 - Call Waiting. It is considered an error to try and apply call waiting tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). Recorder Warning Tone(y): Refer to ITU E.180 - also Bellcore document SSR75 section 6.20. When recording equipment is used, this tone is connected to the line to inform the distant party that the Arango et al. Informational [Page 21]
Basic MGCP Packages July 2001 conversation is being recorded - typical value used is a 1400 Hz Tone of 0.5 second duration every 15 seconds. Calling Card Service Tone(z): This tone is used to inform the customer that credit card information must be keyed in. Typically it consists of 60 ms of 941 + 1477 Hz (the DTMF #digit) and 940 ms of 350 + 440 Hz (dial tone), decaying exponentially with a time constant of 200 ms. Refer to Bellcore document SR2275, section 6.20. Prompt tone (p): This signal is included here to maintain compatibility with the previous version of this package. The prompt signal is an alias for the calling card service tone ("z"). Future implementations that require this signal should use "z". Network Busy (nbz): This signal is included here to maintain compatibility with the previous version of this package. The "nbz" signal is an alias for re-order tone ("ro"). Future Call Agent implementations that require a network busy signal should use the "ro" signal. Distinctive Tone Pattern (s): This signal is included here to maintain compatibility with the previous version of this package. This event requires special provisioning in the Call Agent and gateway to insure interoperability. Arango et al. Informational [Page 22]
Basic MGCP Packages July 2001 2.5. Handset Emulation Package Package Name: H Version: 1 ---------------------------------------------------------------- |Symbol | Definition | R | S Duration | |----------------------------------------------------------------| |adsi(string) | adsi display | x | BR | |aw | Answer tone | x | OO | |bz | Busy tone | x | TO 30 sec. | |ci(ti,nu,na) | Caller-id | x | BR | |dl | Dial tone | x | TO 16 sec. | |e | Error tone | x | TO 2 sec. | |hd | Off hook transition | S | BR | |hu | On hook transition | S | BR | |hf | Flash hook | x | BR | |ht | Tone on Hold | x | TO infinite | |mwi | Message waiting ind. | x | TO 16 sec. | |oc | operation complete | x | | |ot | Off hook warning tone | x | TO infinite | |of | report failure | x | | |rg | Ringing | x | TO 180 sec. | |r0, r1, r2, | Distinctive ringing | x | TO 180 sec. | |r3, r4, r5, | | | | |r6 or r7 | | | | |ro | Reorder tone | x | TO 30 sec. | |rs | Ringsplash | x | BR | |sl | Stutter dialtone | x | TO 16 sec. | |sit | Sit tone | x | TO 2 sec. | |v | Alerting Tone | x | OO | |vmwi | Vis. Message Waiting Ind.| x | OO | |wt | Call Waiting tone | x | TO 12 sec. | |y | Recorder Warning Tone | x | TO infinite | |z | Calling Card Serv. Tone | x | BR | |p | Prompt tone | x | BR | |nbz | Network Busy | x | TO infinite | |s(###) | Distinctive tone pattern | x | BR | ---------------------------------------------------------------- The handset emulation package is similar to the line package except that events such as "off hook" can be signaled as well as detected. Changes from the original package - are the same changes as were made for the line package plus "hu" and "hd" signal types were changed from OO to BR. Signal definitions are the same as for the line package with the following exceptions: Visual Message Waiting: when requested as an event by the Call Agent, the event is not parameterized. However, a parameter is included when it is reported i.e.: Arango et al. Informational [Page 23]
Basic MGCP Packages July 2001 O: vmwi(+) to indicate message waiting on and O: vmwi(-) to indicate message waiting off 2.6. Supplementary Services Tone Package Package Name: SST Version: 0 ---------------------------------------------------------------- |Symbol | Definition | R | S Duration | |----------------------------------------------------------------| |cd | conference depart | | BR | |cj | conference join | | BR | |cm | comfort tone | | TO infinite | |cw | caller waiting tone | | TO 30 sec. | |ni | negative indication | | TO infinite | |nu | number unobtainable | | TO infinite | |oc | operation complete | x | | |of | operation fail | x | | |pr | payphone recognition | | BR | |pt | pay tone | | BR | ---------------------------------------------------------------- Conference Depart(cd): Tone used to indicate that a participant has left a conference call. The tone characteristics are left to the specific gateway implementation. Conference Join (cj): Tone used to indicate that a party has joined a conference call. The tone characteristics are left to the specific gateway implementation. Comfort Tone (cm): used to indicate that the call is being processed and that the caller should wait. Refer to E.182 [4]. Caller Waiting Tone (cw): not to be confused with call-waiting tone - a tone advising a caller that a called station, though busy, has a call waiting service active. Refer to E.182 [4]. Negative Indication (ni): A tone advising a subscriber that the request for service cannot be accepted. Refer to E.182 [4]. For North America, this maps to re-order tone. Number Unobtainable Tone (nu): Refer to E.180, supplement 2 [3]. This is also referred to as "vacant tone" and maps to "re-order tone" in North America. Pay Phone Recognition (pr): A tone advising an operator that the termination is identified as a payphone. Refer to E.182 [4]. Pay Tone (pt): a tone indicating that payment is required. Refer to E.182 [4]. Arango et al. Informational [Page 24]
Basic MGCP Packages July 2001 2.7. Country Specific Tones Package Name: CST Version: 0 Description: This package provide for additional country specific tones as defined in ITU-T, E.180 supplement 2 [3]. ---------------------------------------------------------------- |Symbol | Definition | R | S Duration | |----------------------------------------------------------------| |ac | acceptance tone | | TO infinite | |bz2,bz3 | other busy tones | | TO infinite | |cf2 | confirmation tone II | | TO infinite | |cg2,cg3 | other congestion tones | | TO infinite | |dl2,dl3 | other dial tones | | TO infinite | |sd1,sd2,sd3 | second dial tones | | TO infinite | |eo | executive over-ride tone | | TO infinite | |es | end of the 3 party serv. | | BR | |fc | facilities tone | | TO infinite | |ll | line lockout | | TO infinite | |nu2 | number unobtainable II | | TO infinite | |oc | operation complete | x | | |of | operation fail | x | | |or | offering tone | | TO infinite | |pr2,pr3,pr4 | payphone recognition | | TO infinite | |qu | queue tone | | TO infinite | |rf | refusal tone | | TO infinite | |ru1,ru2 | route tone | | TO infinite | |rt2,rt3,rt4 | ringing tone | | TO,C inf. | |sa | service activated tone | | TO infinite | |va | valid tone | | TO infinite | |wa1,wa2,wa3 | waiting tone | | TO infinite | |we | warning, end or period | | TO infinite | |wp | warning, PIP tone | | TO infinite | |wr1,wr2 | Warning tone, operator | | TO infinite | ---------------------------------------------------------------- Many of the actual 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: cst/bz(to=30000) indicates a timeout value of 30 seconds. Tones are specified in [3]. Some countries have multiple tones defined for a similar purpose. For those cases, the corresponding mappings to tones defined in ITU-T E.180 supp. 2 are as follows: * busy tone - "busy tone I" is "l/bz"; additional busy tones: * bz2 - busy tone II * bz3 - busy tone III * confirmation tone or confirmation tone I is "g/cf" Arango et al. Informational [Page 25]
Basic MGCP Packages July 2001 * cf2 - confirmation tone II * congestion tone - "congestion tone I" is "g/cg"; additional congestion tones: * cg2 - congestion tone II * cg3 - congestion tone III * dial tone - normal dial tone is "l/dl" - also referred to as "dial-tone I"; additional dial tones: * dl2 - dial tone II * dl3 - dial tone III * second dial tone - up to three are specified: * sd1 - second dial tone I * sd2 - second dial tone II * sd3 - second dial tone III * payphone recognition tone or payphone recognition tone I is "sst/pr"; additional payphone recognition tones defined in this package: * pr2 - payphone recognition tone II * pr3 - payphone recognition tone III * pr4 - payphone recognition tone IV * route tones: * ru1 - rout tone or route tone I * ru2 - route tone II * "rt" ringing tone - "ringing tone I" is "g/rt"; additional ringing tones that use ringing tone in this package: * rt2 - ringing tone II * rt3 - ringing tone III * rt4 - ringing tone iV * "wa" waiting tone: * wa1 - waiting tone or waiting tone I * wa2 - waiting tone II * wa3 - waiting tone III * warning tone, operator intervening: * wr1 - warning tone, operator intervening I * wr2 - warning tone, operator intervening II 2.8. Digit Map Extension Package Name: dm1 Version: 0 Extension Digit Map Letters: P This package defines an Extension Digit Map Letter that is used to override the shortest possible match behavior for a given entry. The letter "P" (for partial match override) at the end of a digit map entry instructs the gateway to only consider this a match, if the current dial string does not partially match another entry. For example, given the digit map ([3-7]11|123xxxxxxx|[1-7]xxxxxxP|8xxxP) and a current dial string of "1234567" we would not consider this a match, however a current dial string of "411" would be considered a match. A current dial string of "8234" would be considered a match, since there is no other partial match. Arango et al. Informational [Page 26]
Basic MGCP Packages July 2001 Note that the "P" is not an event, but simply a syntactic and semantic digit map extension. Thus, the "P" is not included in the list of requested or observed events. Support for this package is strongly recommended. 2.9. Signal List Package Package Name: SL Version: 0 --------------------------------------------------------- | Symbol | Definition | R | S Duration | |---------------------------------------------------------| | s(###) | Signal List | | TO variable | | oc | Operation complete | x | | | of | Operation failure | x | | --------------------------------------------------------- Signal List(s(<list>)): The <list> contains a comma-separated list of signals to be played out. Each of the signals in <list> must be either of type BR or type TO. Semantically, the signal list is still treated as a single parameterized signal of type Time-Out though. The signals in the list are played to completion one after the other in the left to right order specified. The package for each signal in the list must be specified. For example, to play out the DTMF digits 123456: S: sl/s(d/1,d/2,d/3,d/4,d/5,d/6) This will result in the DTMF digits 1, 2, 3, 4, 5 and 6 being played out in order. It is illegal to include an OO signal as one of the signals in the list or to request recursive definitions (signal lists within signal lists). If this or any other unsupported signal is included, error code 538 will be returned by the gateway. Note that as the gateway plays the ordered list of signals, if it encounters a TO signal with infinite timeout it will continue to play that signal until requested to stop playing the "SL/S" signal (i.e. other signals later in the list will never be played). If the operation complete ("oc") event is requested, it will be detected once, when the last signal in the list has been played out (regardless of whether there are any TO signals in the list). The operation complete event will only report the signal list name itself, i.e. without the parameters supplied as in: O: sl/oc(sl/s) Arango et al. Informational [Page 27]
Basic MGCP Packages July 2001 Should any of the signals in the signal list result in an error, an operation failure event will be generated. Only the signal list name will be included, thus it is not possible to determine which signal actually failed. Note that if an event occurs while the "SL/S" signal is playing, the "SL/S" signal is stopped in the following manner: * If the signal in the list that was playing at the time the event occurred is of type BR, then the BR signal will be played to completion and no other signals in the list will be played. * If the signal in the list that was playing at the time the event occurred is of type TO, then the TO signal will stop immediately and no other signals in the list will be played. Operation complete (oc): This is the standard definition of operation complete. Operation failure (of): This is the standard definition of operation failure. 2.10. Media Format Package Package Name: FM Version: 0 This package provides support for the media format Local Connection Option (LCO). The media format LCO has a similar significance to the "fmtp" attribute in SDP [8]. The media format parameter is encoded as the keyword "fmtp" or "o-fmtp" followed by a colon and a quoted string beginning with the codec name followed by a space, followed the format associated with that codec. Multiple media formats may be indicated by either repeating the "fmtp" local connection option multiple times such as: L:a:codec1;codec2, fmtp:"codec1 formatX", fmtp:"codec2 formatY" or alternatively by having a single "fmtp" keyword followed by a colon, and a semi-colon separated list of quoted strings for each media format as in: L:a:codec1;codec2, fmtp:"codec1 formatX";"codec2 formatY" The two formats may be mixed. If it is possible for the same codec to be requested with and without the special "fmtp" format, the following could result: L:a:codec1;codec1, fmtp:"codec1 formatX" however it would not be clear if the fmtp parameter was to be applied to the first or the second occurrence of the codec. The problem with that is, that codec ordering is important (i.e. codecs are listed in preferred order) and the above syntax does not provide a way to Arango et al. Informational [Page 28]
Basic MGCP Packages July 2001 indicate if "formatX" is preferred (i.e. associated with the first "codec1") or not (i.e. associated with the second "codec1"). In order to resolve this dilemma, when the same codec is requested with multiple formats, the codec name in the "fmtp" format string is followed by a colon and an <order> where <order> is a number from one to N for N occurrences of the same codec in the codec list i.e.: L:a:codec1;codec1, fmtp:"codec1:2 formatX" indicates that "formatX" is associated with the second instance of "codec1" in the "a:codec1;codec1" list. If an invalid instance number is supplied (e.g. instance 3 where there are only two instances), then error code 524 - inconsistency in local connection options will be returned. Pre-pending "fmtp" with the string "o-" (i.e. "o-fmtp") indicates that the format is optional. In that case, the gateway may decide not to use the fmtp parameter specified, or only use it in part. If the "fmtp" in an LCO is not optional (i.e. does not have "o-" in front of it), and the LCO value is either not recognized or not supported, then the associated codec is considered "not supported". When auditing capabilities, the "fmtp" local connection option must be returned with a semi-colon separated list of supported formats and/or multiple independent "fmtp" parameters as in: A: a:telephone-event, fmtp:"telephone-event 0-15,32-35",... A: a:PCMU;G729, fmtp:"PCMU foo";"PCMU bar", fmtp:"G729 foobar",... One example use of the media format LCO is in conjunction with the codec "telephone-event" as defined in RFC 2833 [14]. If the codec "telephone-event" is used without the "fmtp" media format parameter, the DTMF digits (telephone events 0-15 from RFC 2833) are assumed - such practice is however discouraged. On the other hand, the media format LCO can be used to specify the exact set of events that are being requested via RFC 2833. Example: L: a:PCMU;telephone-event,fmtp:"telephone-event 16" indicates that if telephone events are supported at all, then this request is specifically for event 16. In another case, the Call Agent may indicate that some format parameters are "required" while others are optional. In the example below telephone events 0-15 are a "must" while telephone events 16, 70 and 71 are optional. L: a:PCMU;telephone-event, o-fmtp:"telephone-event 16,70,71", fmtp:"telephone-event 0-15" If the gateway cannot support telephone events 0-15, it must not include the "telephone-event" codec in the SDP in its response. On Arango et al. Informational [Page 29]
Basic MGCP Packages July 2001 the other hand, if it can support those telephone events, it should indicate support for those events as well as any of the events 16, 70 and 71 that it supports. If a request is made to audit the capabilities of an endpoint and the endpoint supports the "telephone event" codec with events "0-16", then the audit would include the following: A: a:telephone-event, fmtp: "telephone-event 0-16" Another example is the use of redundancy with RFC 2198 [9]. Again, the format of the fmtp string is similar to that used in the SDP except the codec rather than the payload type is used: L: a:G729;pcmu;red,fmtp:"red pcmu/g729" The corresponding media description in the SDP as part of the connection request acknowledgment might look like: m=audio 12345 RTP/AVP 98 18 0 a=rtpmap:98 red/8000/1 a=fmtp:98 0/18 If we combine both telephone events and redundancy, an example local connection option might look as follows: L: a:G729;pcmu;red;telephone-event,fmtp:"red pcmu/g729", fmtp: "telephone-event 16" Note that we again specify the literal string for the encoding method rather than it's payload type. This is a general principle that should be used with this LocalConnectionOption. The corresponding SDP might appear as follows: m=audio 12345 RTP/AVP 97 98 18 0 a=rtpmap:97 red/8000/1 a=fmtp:97 0/18 a=rtpmap:98 telephone event a=fmtp:98 16 Note that normally local connection options that are associated with a package should have the package prefix included as per the package extension rules in [1]. The "fmtp" and "o-fmtp" LCO in the "FM" package are an exception. The package prefix is not included in the case of the "fmtp" and "o-fmtp" local connection options because they were created before the extension rules in [1] were defined. These two LocalConnectionOptions will consequently be registered with IANA. Arango et al. Informational [Page 30]
Basic MGCP Packages July 2001 2.11. RTP Package Package Name: R Version: 1 ------------------------------------------------------------- | Symbol | Definition | R | S Duration | |-------------------------------------------------------------| | iu(..) | ICMP unreachable | C | | | | received | | | | rto(..) | RTP/RTCP timeout | C | | | uc | Used codec changed | C | | | sr | Sampling rate changed | C | | | ji(..) | Jitter buffer size changed | C | | | pl(..) | Packet loss exceeded | C | | | qa | Quality alert | C | | | co1 | Continuity tone (single | C | TO,C 3 sec. | | | or return tone) | | | | co2 | Continuity test (go tone, | C | TO,C 3 sec. | | | in dual tone procedures) | | | | oc | operation complete | C | | | of | operation failure | C | | ------------------------------------------------------------- Changes in event types: "co1" and "co2" signals changed from OO to TO. A direction parameter is also added to the "uc" and "sr" events. New events added to this package from the previously unversioned package: "iu", "rto", "lb". These events all refer to RTP streams (connections), i.e. they can not be detected on an endpoint. Signals requested ("co1" and "co2") must indicate the connection ID (e.g. "S: r/co1@connectionID"). An event may be requested for all existing connections using the "*" wildcard for the connectionID as described in [1]. Example: R: r/uc@* (request to report uc on all connections) or R: r/uc@connectionID (request to report uc only on a specific connection) An event detected on a connection will include the connectionID, e.g.: O: r/uc@connectionID(15) ICMP Unreachable Received (iu): This event indicates that some number of ICMP unreachable packets was received for this connection since an RQNT was received requesting this event. This notification indicates that packets that were sent by the gateway on this connection either did not arrive at their destination or were not accepted (e.g. the port Arango et al. Informational [Page 31]
Basic MGCP Packages July 2001 was closed). When this event is requested, a single parameter with a decimal number from 1 to 255 may be included to indicate the number of ICMP un-reachable packets that must occur before the event is notified. If no parameter is supplied, with the request then a default value of 3 is assumed. This is a one-shot event in that once it the event occurs, a further request is required in order to re-initiate counting. The observed event is parameterized with two parameters: * The first parameter is the number of ICMP unreachable packets received (i.e. the same value that was included in the request - or the value 3, if the requested event was not parameterized) * The second parameter is the error code indicated in the ICMP unreachable packet, e.g.: 0 = net unreachable; 1 = host unreachable; 2 = protocol unreachable; 3 = port unreachable; 4 = fragmentation needed and DF set; 5 = source route failed. etc. An example of a request might be as follows: RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: 0123456789B0 R: r/iu@364823(N)(5) In this case a notify will occur if 5 ICMP port unreachable packets are received as a result of RTP and/or RTCP packets being sent from this gateway on the connection with connection ID 364823. The resulting NTFY with observed events might be as follows: NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: 0123456789B0 O: r/iu@364823(5,3) The first parameter indicates 5 ICMP unreachable packets were received since the RQNT with this request was sent. The second parameter ("3") specifies the reason, which in this case is "port unreachable". Arango et al. Informational [Page 32]
Basic MGCP Packages July 2001 RTP/RTCP Timeout (rto): This event indicates that neither RTP nor RTCP packets have been received on this connection for a period of time equal to the timeout value (in seconds). The timeout value is supplied as a decimal number from 1 to 65535 in the parameter when the request is made. The parameter is also supplied in ObservedEvents when the event is reported - it then simply repeats the value supplied originally. If an RTP or RTCP packet is received before the timer expires, then the timer is reset and re-started. The event will only be generated if the timer expires without an RTP or RTCP packet arriving on the specified connection during the specified period of time. Note that if the event is requested without a parameter then a default timeout of 60 seconds is assumed. This is a one-shot event in that once the event occurs, a further request is required in order to re-initialize the timer. An example of a request might be as follows: RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: 0123456789B0 R: r/rto@364823(N)(120) In this case a notify will occur if there is a period of time when no RTP or RTCP packets have been received on connection 364823 for 120 seconds. The resulting NTFY with observed events would be as follows: NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: 0123456789B0 O: r/rto@364823(120) Used Codec Changed (uc): This event is only included here to maintain compatibility with the previous version of this package. This event is requested without a parameter but when reported, the hexadecimal payload type is enclosed in parenthesis, as in UC(8), to indicate the codec was changed to PCM A-law. Codec Numbers are specified in RFC 1890, or in a new definition of the audio profiles for RTP that replaces this RFC. Sampling Rate Changed (sr): This event is only included here to maintain compatibility with the previous version of this package. This event was meant to indicate that the packetization period changed to some decimal number in milliseconds enclosed in parenthesis, as in SR(20), which would indicate that the sampling rate was changed to 20 milliseconds. Some implementations of media gateways may not allow the sampling rate to be changed upon command from a call agent. Arango et al. Informational [Page 33]
Basic MGCP Packages July 2001 Jitter Buffer Size Changed (ji): This event is only included here to maintain compatibility with the previous version of this package. This event is used to indicate that the gateway has made an adjustment to the depth of the jitter buffer. The syntax for requesting notification is "ji", which tells the media gateway that the controller wants notification of any jitter buffer size changes. The syntax for notification from the media gateway to the controller is "JI(####)", where the #### is a decimal number from 1 to 65536 indicating the new size of the jitter buffer, in milliseconds. Packet Loss Exceeded (pl): Packet loss rate exceeds the threshold of the specified decimal number (with a range of 1 to 100,000) of packets per 100,000 packets, where the packet loss number is indicated in parenthesis. For example, PL(10) is a drop rate of 10 in 100,000 packets. This event is requested with a parameter indicating what packet loss rate the Call Agent wishes to be reported. If the packet loss exceeds that value, the event is reported with that same parameter. The event is only reported once when the packet loss threshold is exceeded. Once reported, a following request will re- initiate packet loss measurements and report when the threshold is exceeded again. Quality alert (qa): The packet loss rate or the combination of delay and jitter exceeded a quality threshold. The quality thresholds for delay, jitter and packet loss rate are provisioned values. Continuity tones (co1 and co2): These are the same as those defined in the Trunk package except in this case they are only played over a network connection and the connectionID must be supplied (e.g. "s: r/co1@connectionID"). They can be used in conjunction with the Network LoopBack (netwloop) or Network Continuity Test (netwtest) modes to test the continuity of an RTP circuit. However, in the case of testing IP continuity, a one tone test is sufficient i.e. generating and detecting "co1" at one end with connection mode in network loopback mode at the other end. Note that the test can also be done using telephone events rather than tones, i.e. event 167 in RFC 2833 corresponds to "co1". In this case, connection requests are made with local connection options such as: L: a:PCMU;telephone-event,fmtp:"telephone-event 167" in order to request support for telephone event 167. If both ends support the event, then the loopback proceeds as usual except that telephone events corresponding to the co1 tone are sent rather than the co1 tone itself. Operation complete (oc): This is the standard definition of operation complete. Operation failure (of): Arango et al. Informational [Page 34]
Basic MGCP Packages July 2001 This is the standard definition of operation failure. 2.12. Resource Reservation Package Package Name: RES Version: 0 2.12.1. Description The "RES" package provides local connection option support for resource reservations as well as an event to indicate reservation loss. A number of LocalConnectionOption parameters are used in doing resource reservations: "reservation request", "reservation direction", "reservation confirmation" and "resource sharing". Reservation Request LocalConnectionOption: The gateways can be instructed to perform a reservation, for example using RSVP, on a given connection. When a reservation is needed, the Call Agent will specify the reservation profile that should be used, which is either "controlled load" or "guaranteed service". The absence of reservation can be indicated by asking for the "best effort" service, which is the default value for this parameter. Whether or not RSVP will be done is dependent on whether the reservation request LocalConnectionOption parameter has been included in a connection request for this connection (with either "controlled load" or "guaranteed service" indicated). If a modify connection (MDCX) request requires a change in the reservation and the "reservation request" parameter is not included in the LocalConnectionOptions but was included in the LocalConnectionOptions for a previous connection request for that connection, then "reservation request" value defaults to its previously saved value for that connection. If a modify connection (MDCX) request explicitly contains a "reservation request", indicating a request for "best effort" for a connection that has an existing reservation, the existing reservation will be torn down. Reservation Direction LocalConnectionOption: When reservation has been requested on a connection, the gateway will examine the reservation direction LocalConnectionOption parameter to determine the direction that reservations are required and do the following: * start emitting RSVP "PATH" messages if the reservation direction LocalConnectionOptions parameter specified "send-only" or "send- receive". * start emitting RSVP "RESV" messages as soon as it receives "PATH" messages if the reservation direction parameter specified "receive-only" or "send-receive". Arango et al. Informational [Page 35]
Basic MGCP Packages July 2001 If an RSVP reservation is requested but the reservation direction LocalConnectionOption parameter is missing, the reservation direction defaults to the previously saved value of the reservation direction parameter for that connection. If there was no previous reservation direction parameter for that connection, the value is deduced from the connection mode. That is: * start emitting RSVP "PATH" messages if the connection is in "send-only", "send-receive", "conference", "network loop back" or "network continuity test" mode (if a remote connection descriptor has been received,) * start emitting RSVP "RESV" messages as soon as it receives "PATH" messages if the connection is in "receive-only", "send- receive", "conference", "network loop back" or "network continuity test" mode. Reservation Confirmation LocalConnectionOption: Another LocalConnectionOption parameter for RSVP reservations is the reservation confirmation parameter which determines what the resource reservation pre-condition is for acknowledging a successful connection request: * If the reservation confirmation parameter is set to "none", the gateway will "Ack" the connection request without waiting for reservation completion. This is the default behavior. * If the "reservation confirmation" parameter is set to "send-only", the gateway will "Ack" when the RESV is received to indicate reservation in the send direction. * If the "reservation confirmation" parameter is set to "receive- only", the gateway will "Ack" when reservation confirm has been received. * If the reservation confirmation parameter is set to "send- receive", the gateway will "Ack" only after RESV has been received for send direction and reservation confirm has been received for the receive direction. Note that: Values "receive-only" and "send-receive" are triggers for the gateway to request reservation confirm when it sends out the RESV. Pre-conditions should only be added for the direction(s) for which resource reservations have been requested. If a direction is added as a precondition and that direction was not requested in the resource reservation, the direction is simply ignored as a pre- condition. In this approach, resource reservation success is the pre- condition to final acknowledgement of the connection request. If Arango et al. Informational [Page 36]
Basic MGCP Packages July 2001 the reservation fails, the connection request also fails (error code 526 - insufficient bandwidth) - as will any other part of the transaction, e.g. a notification request included as part of the connection request. A typical example of this would be a request to ring the phone and look for off-hook, included with the connection request. If the reservation fails, the phone will not ring. Similarly, if the phone is already off-hook, the command fails and there will be no resource reservation. A provisional response should be provided if confirmation is expected to occur outside the normal retry timers and in fact a provisional response must be provided regardless if reservation confirmation parameter has value "send-receive" (without a provisional response, SDP information cannot be returned until the final "Ack" which will not occur until the reservation is complete. This results in a deadlock since the SDP information typically needs to be passed to the other end in order for it to initiate the RSVP PATH in the other direction). The SDP information and connectionID must be included in both the provisional response and the final response. Note that in order to ensure rapid detection of a lost final response, final responses issued after provisional responses for a transaction shall be acknowledged, i.e., they shall include an empty "ResponseAck" parameter in the final response (see [1]). If the transaction time is outside the expected bounds (time T- HIST - see the section on provisional responses in [1]), error code 406 (transaction timeout) should be returned. Also note that if the reservation confirmation parameter is omitted, the value of the reservation confirmation parameter defaults to its previously-saved value. If there is no previously saved value for the reservation confirmation parameter or the reservation confirmation parameter has the value "none", then successful resource reservation is not a pre-condition to providing an acknowledgement to the connection request (i.e. the gateway can "Ack" right away without waiting for the reservation to complete and a provisional response will not be necessary). Resource Sharing LocalConnectionOption: It may be possible to share network resources across multiple connections. An example is a call- waiting scenario, where only one connection will ever be active at a time. In a 3-way calling scenario with a similar set of connections, sharing is not possible. Only the Call Agent knows what may be possible, depending on the feature that is being invoked. In order to allow the Call Agent to indicate that sharing is possible, a resource sharing LocalConnectionOption parameter is introduced. This parameter can have one of the following values: * A value "$" can be specified where $ refers to "this connection". This value is used when doing a create connection and indicates the intent to share resources with this Arango et al. Informational [Page 37]
Basic MGCP Packages July 2001 connection. This is an indication to the gateway to use the shared explicit style of reservation as defined in RFC 2205. * A connection ID can be specified which indicates that this is a request to share resources with the connection having this connection ID (allowing multiple connections to share resources with the connection indicated) * The value can be empty, which indicates a request to no longer share the resources of this connection with other connections In the case of a CRCX the default value for the resource sharing local connection option is empty and for an MDCX the default value is its current value. The RSVP filters will be deduced from the characteristics of the connection. The RSVP resource profiles will be deduced from the connection's bandwidth and packetization period. Note that if RSVP is used with dynamic quality of service [17], then the parameters in NCS [16] would be used instead of the reservation direction, confirmation and reservation sharing parameters described here. 2.12.2. Parameter Encoding The Local Connection Options for the "RES" package consist of the following: * The resource reservation parameter, encoded as the keyword "r", followed by a colon and the value "g" (guaranteed service), "cl" (controlled load) or "be" (best effort). * The reservation direction parameter, encoded as the keyword "r-dir" followed by a colon and the value "sendonly", "recvonly" or "sendrecv". * The reservation confirmation parameter, encoded as the keyword "r-cnf" followed by a colon and the value "none", "sendonly", "recvonly" or "sendrecv". * The resource sharing parameter, encoded as the keyword "r-sh" followed by a colon and either: * the wild-card character "$" indicating this connection, indicating future plans to share resources with this connection (i.e. indicating that a shared explicit style of reservation should be used - see RFC 2205), or * a connection ID, indicating a request to share resources with the connection having the specified connection ID (and all other connections sharing resources with that connection), or Arango et al. Informational [Page 38]
Basic MGCP Packages July 2001 * an empty value, indicating a request to no longer share the resources of this connection with other connections Note that normally local connection options that are associated with a package should have the package prefix included as per the package extension rules in [1]. The local connection options in the "RES" package are exceptions. The package prefix is not included in the case of the "RES" package because it was created before the extension rules in [1] were defined. 2.12.3 Events The following event is included as part of the resource reservation package: ------------------------------------------------------ | Symbol | Definition | R | S Duration | |------------------------------------------------------| | rl | Resource Lost | C | | ------------------------------------------------------ Resource Lost: Loss of reservation during the life of a connection can be reported by using the ôrlö event. If requested on an endpoint (without specifying the connection ID), the request refers to all present and future connections on that endpoint. When reported, the connectionID is always supplied, as in: O: res/rl@0A3F58 Resource lost will also occur if a resource reservation is in progress when the event is requested, and the reservation fails. 2.13. Announcement Server Package Package Name: A Version: 1 ------------------------------------------------------------- | Symbol | Definition | R | S Duration | |-------------------------------------------------------------| | ann(url) | Play an announcement | | TO variable | | oc | operation complete | x | | | of | operation failure | x | | ------------------------------------------------------------- Changes from the previous version: change to conform with standard reporting of operation failure and operation complete events. The announcement action is qualified by a URL name: S: ann(http://scripts.example.net/all-lines-busy.au) Arango et al. Informational [Page 39]
Basic MGCP Packages July 2001 The URL name may be followed by a list of initial parameters, separated by commas. However, standard parameters are not included as part of this package definition (Note: use of additional parameters is optional and would result in a proprietary interface). The gateway should support one or more standard URL schemes such as: * file, http, ftp (RFC 1738), which indicate where the audio file is located (where to load the file from before playing the audio file on the gateway). * RTSP URL (section 3.2 of RFC 2326), which in this case allows the media gateway to directly initiate playing of the announcement via an RTSP server. The pre-condition for a successful response (return code of "200") is correct syntax and capability (support is available for this request). Standard MGCP return codes apply in the case of failure. Further indications of failure are provided in the operation fail event. If the announcement cannot be played out for a reason determined after a successful response to the request as been provided, an operation failure event will be returned. The failure may be explained by a commentary, as in: O: a/of(a/ann(file not found)) The "operation complete" event will be detected when the announcement is played out. O: a/oc(a/ann) Arango et al. Informational [Page 40]
Basic MGCP Packages July 2001 2.14. Script Package Package Name: Script Version: 1 ----------------------------------------------------------------- | Symbol | Definition | R | S | Duration | |-----------------------------------------------------------------| | java(url,...) | Load & Run java script | | TO | variable | | perl(url,...) | Load & Run perl script | | TO | variable | | tcl(url,...) | Load & Run TCL script | | TO | variable | | xml(url,...) | Load & Run XML script | | TO | variable | | vxml(url,...) | Load & Run VXML doc. | | TO | variable | | oc | operation complete | x | | | | of | operation failure | x | | | ----------------------------------------------------------------- Changes from the previous version of the package: "vxml" was added as a language type for loading and running VXML documents; change to conform with standard reporting of operation failure and operation complete events. The current definition defines keywords for the most common languages. More languages may be defined in later versions of this package. The "signal" specifying the scripting language is parameterized with a URL indicating the location of the script. The URL parameter may be optionally followed by a comma-separated list of arguments as initial parameters to use in running the script. URL schemes may include file ftp, or http schemes with syntax according to RFC 2396. As an example: S: script/vxml(ftp://ftp.example.net/credit-card.vxml,arg1,arg2, ...,argn) The argument list "arg1,arg2,...,argn" is passed to the script/document as a list of initial parameters. The pre-condition for a successful response (return code of "200") is correct syntax and capability (support is available for this request). Standard MGCP return codes apply in the case of failure. Some further (non-application/script specific) failure indications are provided in the operation failure event. Example O: script/of(script/vxml(file not found)) The script produces an output, which consists of one or several text strings, separated by commas. This provides the return-status of the script as well as return parameters (if there are any). O: script/oc(script/vxml(return-status=<status>, name1=value1,name2=value2,...)) Arango et al. Informational [Page 41]
Basic MGCP Packages July 2001 where <status> can have one of the values "success" or "failure". This is then followed by output parameters as a comma-separated list of name-value pairs. 3.0 Changes since draft-foster-mgcp-basic-packages-00.txt * Version events were removed in favor of using an audit capability in the base specification. * "do" and "dd" added to the DTMF package * Test pattern signal added to the T package; loopback signal definition added * "oi" and "lsa" added to the line package * Country specific tones where moved into a separate package (the CST package) * Changes to the FM package * ICMP unreachable and RTP/RTCP timeout and loopback events added to the R package * Resource Lost event added to the RSVP "res" package. * Announcement Server and script package updated so that operation fail and operation complete events are consistent with [1]. 4.0. Acknowledgements These packages are an update of the original packages in RFC 2705 along with some new packages. Thanks to a number of people, including but not limited to: Jerry Kamitses, Sonus Networks; Dave Auerbach, Dan Wing, Cisco Systems; Ed Guy, Telcordia Technologies. 5.0. References [1] Arango et al, Media Gateway Control Protocol (MGCP)Version 1.0bis, draft-andreasen-mgcp-rfc2705bis-01.txt [2] Technical Characteristics of Tones for the Telephone Service, ITU-T E.180 [3] Various Tones Used in National Networks, ITU-T E.180, Supplement 2. [4] Applications of Tones and Recorded Announcements in Telephone Services, ITU-T, E.182 [5] LSSGR: Signaling for Analog Interfaces, GR-506-CORE [6] Bellcore, Notes on the Network, Special Report SR-2275 [7] ANSI T1.207-2000, American National Standard for Telecommunications - Operations, Administration, Maintenance, and Provisioning (OAM&P) - Terminating Test Line Capabilities and Access Arrangements. Arango et al. Informational [Page 42]
Basic MGCP Packages July 2001 [8] Handley, M., Jacobson, V., SDP: Session Description Protocol, RFC 2327, April 1998 [9] C. Perkins et al, RTP Payload for Redundant Audio Data, RFC 2198, September 1997 [10] GR-529-CORE, Basic 911 Emergency Service (FSD 15-01-0000) [11] Internet Control Message Protocol, RFC 792. [12] B. Foster, MGCP CAS Packages, RFC 3064 [13] Bellcore, LSSGR: Switching System Generic Requirements for Call Control Using the Integrated Services Digital Network User Part (ISDNUP), GR-317-CORE, Issue 2, December 1997. [14] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, RFC 2833, May 2000 [15] GR-505-CORE, Call Processing [16] GR-531-CORE, LSSGR: Verification Connections, FSD 25-05-0903 6.0. Authors' Addresses Mauricio Arango 901 San Antonio Road, UMPK15-214 Palo Alto, CA 94303 Email: Mauricio.Arango@sun.com Andrew Dugan Level3 Communications 1025 Eldorado Blvd Broomfield, CO 80021 Phone: +1 720 888 2983 EMail: andrew.dugan@level3.com Isaac Elliott Level3 Communications 1025 Eldorado Blvd., Bldg 4000 Broomfield, CO 80021 Phone: +1 720 888 6763 EMail: ike.elliott@level3.com Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: huitema@microsoft.com Arango et al. Informational [Page 43]
Basic MGCP Packages July 2001 Scott Pickett Vertical Networks 1148 East Arques Ave Sunnyvale, CA 94086 Phone: +1 408 585 3200 EMail: ScottP@vertical.com Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837 Phone: +1 732 452 1667 EMail: fandreas@cisco.com Bill Foster Phone: +1 250 758 9418 EMail: bfoster@cisco.com 7.0. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Arango et al. Informational [Page 44]