RFC 3660
Basic Media Gateway Control Protocol (MGCP) Packages
Network Working Group B. Foster Request for Comments: 3660 F. Andreasen Updates: 2705 Cisco Systems Category: Informational December 2003 Basic Media Gateway Control Protocol (MGCP) Packages Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. IESG Note This document is being published for the information of the community. It describes a non-IETF protocol that is currently being deployed in a number of products. Implementers should be aware of RFC 3525 [37], which was developed in the IETF Megaco Working Group and the ITU-T SG16, and is considered by the IETF and ITU-T to be the standards-based (including reviewed security considerations) way to meet the needs that MGCP was designed to address. The IETF Megaco Working Group and the ITU-T Study Group 16 are developing extensions to RFC 3525 [37] that for functions of the type in addressed in this document.Abstract
This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (Dual Tone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. List of Packages . . . . . . . . . . . . . . . . . . . . 3 1.2. Changes to Existing RFC 2705 Packages. . . . . . . . . . 3 1.2.1. Change in Signal Types . . . . . . . . . . . . . 3 1.2.2. Operation Complete and Operation Failure . . . . 3 1.2.3. Package Versions . . . . . . . . . . . . . . . . 4 1.2.4. Event Definitions, Aliases and Interoperability Issues . . . . . . . . . . . . . . . . . . . . . 4 1.2.5. New Events . . . . . . . . . . . . . . . . . . . 5 1.3. New Packages and Excluded Packages . . . . . . . . . . . 5 2. Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Generic Media Package. . . . . . . . . . . . . . . . . . 7 2.2. DTMF Package . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Trunk Package. . . . . . . . . . . . . . . . . . . . . . 16 2.4. Line Package . . . . . . . . . . . . . . . . . . . . . . 24 2.5. Handset Emulation Package. . . . . . . . . . . . . . . . 33 2.6. Supplementary Services Tone Package. . . . . . . . . . . 36 2.7. Digit Map Extension. . . . . . . . . . . . . . . . . . . 37 2.8. Signal List Package. . . . . . . . . . . . . . . . . . . 38 2.9. Media Format Parameter Package . . . . . . . . . . . . . 39 2.10. RTP Package. . . . . . . . . . . . . . . . . . . . . . . 43 2.11. Resource Reservation Package . . . . . . . . . . . . . . 48 2.11.1. Description. . . . . . . . . . . . . . . . . . . 48 2.11.2. Parameter Encoding . . . . . . . . . . . . . . . 52 2.11.3. Events . . . . . . . . . . . . . . . . . . . . . 53 2.12. Announcement Server Package. . . . . . . . . . . . . . . 55 2.13. Script Package . . . . . . . . . . . . . . . . . . . . . 56 3. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 59 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.1. Normative References . . . . . . . . . . . . . . . . . . 60 6.2. Informative References . . . . . . . . . . . . . . . . . 62 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 63 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 641. Introduction
This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF, announcement server and script packages are updates of packages from RFC 2705 [38] with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [31].1.1. List of Packages
The basic set of packages specified in this document is for use with MGCP 1.0 as defined in [1]. Included are the following packages: ------------------------------------------- | Package | Name | |-------------------------------------------| | Generic Media Package | G | | DTMF package | D | | Trunk Package | T | | Line Package | L | | Handset Package | H | | Supplementary Services Package | SST | | Digit Map Extension | DM1 | | Signal List Package | SL | | Media Format Package | FM | | RTP Package | R | | Resource Reservation Package | RES | | Announcement Server Package | A | | Script Package | Script | -------------------------------------------1.2. Changes to Existing RFC 2705 Packages
1.2.1. Change in signal types
MGCP 1.0, as defined in RFC 2705 [38] (and now updated in [1]), provided some additional clarification on the meaning of On-Off (OO) signals compared to earlier versions of MGCP. This lead to some inconsistency in some of the signal definitions in the accompanying packages in RFC 2705 [38]. This has been corrected in the packages that are included here by changing some of the signals from type On- Off to type Time-Out (TO).1.2.2. Operation Complete and Operation Failure
Another change made to improve consistency and interoperability was to add the "operation complete" and "operation failure" events in packages where there are TO signals defined, but where the "operation complete" and "operation failure" events were not previously included as part of the package. By definition, all packages that contain
Time-Out type signals now contain the "operation failure" ("of") and
"operation complete" ("oc") events as defined in [1], irrespective of
whether they are provided as part of the package description or not.
If a package without Time-Out signals contains definitions for the
"oc" and "of" events, the event definitions provided in the package
may over-ride those indicated here. Such practice is however
discouraged and is purely allowed to avoid potential backwards
compatibility problems.
It is considered good practice to explicitly mention that the "oc"
and "of" events are supported in accordance with their default
definitions. If no definition is included in the package, the
default syntax and semantics are assumed.
Please refer to [1] for additional details on these events.
1.2.3. Package Versions
The generic, line, trunk, handset, RTP, DTMF, announcement server and
script packages included in this document are new versions of
packages that were previously contained in RFC 2705 [38]. The
updated base MGCP 1.0 specification [1] provides an optional
capability of auditing package versions. Any gateway that implements
versioned packages SHOULD also implement this option.
1.2.4. Event Definitions, Aliases and Interoperability Issues
Some event definitions or clarifications of previous event
definitions have also been added in order to improve
interoperability.
In some cases, events have aliases either in the same or in other
packages and a recommendation has been made for the use of alternates
by Call Agents for future implementations. For maximum
interoperability, gateways MUST still implement these events (in fact
they MUST always implement all of the events, signals, etc. in a
package).
Some events that were previously defined require specific
provisioning in both the gateway and the Call Agent in order to allow
for interoperability. In those cases, a warning to that affect has
been included.
1.2.5. New Events
In some cases, new events have been added to existing packages. Any changes to existing packages of course have resulted in the package version number being updated from unversioned (version 0) to version 1.1.3. New Packages and Excluded Packages
Two packages from RFC 2705 [38] have not been included. These are the "MF" and the "NAS" packages. These packages are still valid as are all unversioned (version 0) packages defined in RFC 2705 [38]. The reason these packages were not included are: * The original MF package had no defined way to outpulse MF digits so that MF CAS is now provided by other packages (i.e., the "MS", "MO" and "MD" packages) in a separate document. * The "N" package, as defined in RFC 2705 [38], was incomplete. A new MGCP "NAS" package has been developed and provided in a separate document. New packages have also been included beyond what was included in RFC 2705 [38]. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages. The Resource Reservation ("RES") and Media Format ("FM") packages in particular are different from other packages in this document in that they contain new LocalConnectionOptions. This is allowed by the new extension rules in [1]. Future packages of this type MUST use a packages prefix in front of local connection options ("<package- name>/<Local Connection Option>") so as to avoid name-space problems. However because of the timing of the arrival of these packages relative to updating MGCP 1.0, this was not done for the "RES" and "FM" packages. The resulting new local connection options have been registered with IANA. For future cases where a package prefix is included, only the package name needs to be registered.2. Packages
For those packages that involve MGCP events, the terms "signal" and "event" are used to differentiate a request from a Call Agent to a Media Gateway to apply an event ("signal"), from the request for the detection of an "event" that occurs on the Media Gateway and is "Notified" to the Call Agent.
For packages that involve events and signals, the tables contain five
columns:
Symbol: the (package) unique symbol used to identify the event.
Definition: a short description of the event.
R: an x appears in this column if the event can be requested by
the Call Agent. Alternatively, one or more of the following
symbols may appear. An "S" is included if the event-state may be
audited. A "C" indicates that the event can be detected on a
connection, and a "P" indicates the event is persistent.
S: if nothing appears in this column for an event, then the event
cannot be signaled by the Call Agent. Otherwise, the following
symbols identify the type of event:
* OO On/Off signal
* TO Time-Out signal.
* BR Brief signal.
In addition, a "C" will be included if the signal can be generated
on a connection.
Duration: specifies the default duration of TO signals. If a
duration is left unspecified, then the default timeout will be
assumed to be infinite, unless explicitly noted in the description
of the signal. A duration may also be declared as being variable
in a case where signals involve complex sequencing (e.g., scripts
or digit out-pulsing) where the amount of time may vary with
either processing time or the signaling environment.
Default time-out values may be over-ridden by the Call Agent for any
Time-Out event defined in this document (with the exception of those
that have a default value of "variable") by a "to" signal parameter
which specifies the timeout value in milliseconds (see [1]). The
following example indicates a timeout value of 20 seconds:
S: sst/cw(to=20000)
As indicated in [1]: by default, a supplied time-out value MAY be
rounded to the nearest non-zero value divisible by 1000, i.e., whole
second. However, individual signal definitions within a package may
define other rounding rules.
Note that Time-Out signals that involve other parameters still allow
the use of the "to" signal parameter e.g.:
S: T/sit(1,to=3000)
The order of the "to" parameter relative to the other parameters is
not important.
Note: as per [1], On-Off (OO) signals are parameterized with "+"
(meaning turn on) or "-" (meaning turn off). If the parameter is
missing, the default is to turn on the signal. Unlike Time-Out
signals, On-Off signals do not stop when an event occurs.
Other than the "to" parameter for Time-out (TO) signals and the "+"
and "-" for On-Off (OO) signals, signals and events in the packages
in this document do not have parameters unless explicitly indicated
in the description of the event for that package.
In some of the signal definitions below, specific tone definitions
are provided even though actual frequencies may vary from country to
country.
2.1. Generic Media Package
Package Name: G
Version: 1
The generic media package groups the events and signals that can be
observed on several types of endpoints, such as trunk gateway
endpoints, access gateway endpoints or residential gateway endpoints.
---------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------------------------------------------------------------|
| cf | Confirm Tone | | BR |
| cg | Congestion Tone | | TO infinite |
| ft | Fax Tone | x | |
| it | Intercept Tone | | TO infinite |
| ld | Long Duration Connection | C | |
| mt | Modem Tone | x | |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| pat(###) | Pattern Detected | x | OO |
| pt | Preemption Tone | | TO infinite |
| rbk(...) | Ringback | | TO,C 180 seconds|
| rt | Ringback Tone | | TO,C 180 seconds|
---------------------------------------------------------------
New events added to this package from the previously unversioned package: "oc" Changes: "it" and "pt" signals changed from OO to TO. Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details. The events and signals are defined as follows: Confirmation Tone (cf): This is also referred to as "positive indication tone" in ITU-T E.182. In North America, Confirmation Tone uses the same frequencies and levels as dial tone (350 and 440 Hertz) but with a cadence of 0.1 second on, 0.1 second off, repeated three times. See GR-506-CORE [7] Section 17.2.4. It is considered an error to try and play confirmation tone on a phone that is on-hook and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook). Congestion Tone (cg): Refer to ITU-T E.180 [8] and E.182 [10]. This maps to re-order tone in North America (refer to GR-506-CORE [7] Section 17.2.7). Fax Tone (ft): The fax tone event is generated whenever a fax call is detected by the presence of V.21 fax preamble. The fax tone event SHOULD also be generated when the T.30 CNG tone is detected. See ITU-T Recommendations T.30 [21] and V.21 [22]. Intercept Tone(it): This is a country specific tone as defined in ITU-T E.180 Supplement 2 [9]. Long Duration Connection (ld): The "long duration connection" is detected when a connection has been established for more than a provisioned amount of time. The default value is 1 hour. This event is detected on a connection. When no connection is specified as part of the request, the event applies to all connections for the endpoint, regardless of when the connections are created. The "all connections" wildcard (see [1]) may also be used for this case, and is in fact preferred for consistency. In
either case, the name of the connection on which the event was
detected will be included when the event is observed, e.g.:
G/ld@0A3F58
Modem Tone (mt):
Indicates V.25 Answer tone (ANS) with or without phase reversals
or V.8 Modified Answer Tone (ANSam) tone with or without phase
reversals. Note that this implies the presence of a data call.
Also note that despite the name of the event, devices other than
modems may generate such tones, e.g., a fax machine.
Operation Complete (oc):
The standard definition of operation complete [1].
Operation Failure (of):
The standard definition of operation failure [1].
Pattern Detected (pat(###)):
This event requires special provisioning that needs to be agreed
on between the Call Agent and media gateway in order to ensure
interoperability. It is retained in order to maintain backwards
compatibility with version 0 of the "G" package. This event MUST
be parameterized with a decimal numeric value from 0 to 999
specifying the pattern to detect. When reported, the pattern is
also included as a parameter.
Preemption Tone (pt):
This is a country specific tone and is defined in ITU-T E.180
Supplement 2 [9].
Ringback (rbk(connectionID)):
This is an alias for "rt@connectionID" and is included here for
backwards compatibility only. It is recommended that Call Agents
use "rt@connectionID" instead of "rbk(connectionID)" for ring-back
over a connection for new implementations. Although the ringback
signal is applied on a connection, the "rbk" signal does not
support the "@connection" syntax. When the signal is requested,
it MUST be parameterized with a connection-ID or a connection-ID
wildcard as specified in [1].
Ringback Tone (rt):
Refer to ITU-T E.180 [8] and ITU-T E.182 [10]. Also referred to
as ringing tone - a tone advising the caller that a connection has
been made and that a calling signal is being applied to the called
party or service point. In North America, this tone is a
combination of two AC tones with frequencies of 440 and 480 Hertz
and levels of -19 dBm each, to give a combined level of -16 dBm.
The cadence for Audible Ring Tone is 2 seconds on, followed by 4
seconds off. See GR-506-CORE [7] - LSSGR: SIGNALING, Section
17.2.5.
This signal can be applied directly to an endpoint or
alternatively on a connection using the syntax "rt@connectionID".
When the ringback signal is applied to an endpoint, it is
considered an error to try and play ringback tone if the endpoint
is considered on-hook, and an error MUST consequently be returned
when such attempts are made (error code 402 - phone on-hook).
When the ringback signal is applied to a connection, no such check
is to be made.
Note that as specified in [1], signals requested on a connection
MUST be played regardless of the connection mode. For example, in
a call-waiting situation, ringback tone may be played on a
connection in "inactive" mode.
2.2. DTMF package
Package name: D Version: 1 -------------------------------------------------------------- | Symbol | Definition | R | S Duration | |--------------------------------------------------------------| | 0 | DTMF 0 | x | BR | | 1 | DTMF 1 | x | BR | | 2 | DTMF 2 | x | BR | | 3 | DTMF 3 | x | BR | | 4 | DTMF 4 | x | BR | | 5 | DTMF 5 | x | BR | | 6 | DTMF 6 | x | BR | | 7 | DTMF 7 | x | BR | | 8 | DTMF 8 | x | BR | | 9 | DTMF 9 | x | BR | | # | DTMF # | x | BR | | * | DTMF * | x | BR | | A | DTMF A | x | BR | | B | DTMF B | x | BR | | C | DTMF C | x | BR | | D | DTMF D | x | BR | | DD(..) | DTMF Tone Duration | x | TO 3 seconds | | DO(..) | DTMF OO Signal | | OO | | L | Long Duration Indicator | x | | | oc | Operation Complete | x | | | of | Operation Failure | x | | | T | Interdigit Timer | x | TO 16 seconds | | X | DTMF Tones Wildcard, | x | | | | match any digit 0-9 | | | -------------------------------------------------------------- Changes from the previous version of the package: events "dd", "do", "oc" were added. Note that DTMF tones including the DTMF tones wildcard can use the eventRange notation defined in [1] when requesting events, e.g., "D/[0-9](N)". Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details.
The events are defined as follows:
DTMF tones (0-9,#,*,A,B,C,D):
Detection and generation of DTMF tones is described in GR-506-CORE
[7] - LSSGR: SIGNALING, Section 15. Note that it is considered an
error to try and play DTMF tones on a phone that is on-hook and an
error MUST consequently be returned when such attempts are made
(error code 402 - phone on-hook). The event codes can be
specified in a digit map. When requested as a signal, as per
GR-506-CORE [7], section 15, a minimum tone duration of 50 ms will
be followed by a minimum interdigit silence period of 45 ms, i.e.,
if requested in a signal list such as "S: sl/s(d/5,d/6,d/7)", then
interdigit timing requirements will be satisfied.
Note that some types of endpoints, such as announcement endpoints,
MAY allow detection and/or generation of a DTMF tone over a
connection. However, this requires consistent provisioning
between the Call Agent and announcement server (it is not required
in order to be compliant with the DTMF package).
DTMF Tone Duration (dd(dg=<tone>,to=<time>,su=<TrueOrFalse>)):
This event can be used to indicate if/when the specified <tone>
has a duration greater than the <time> value indicated (and is
reported once the duration is exceeded). The parameters can be
supplied in any order. The value of <tone> can be any of the DTMF
tone symbols (without including the package name) specified in the
DTMF package (including X in the case of events, but not signals).
If this parameter is absent, any DTMF tone that occurs will be
reported. The parameter <time> is in milli-seconds and may be
rounded to the nearest 10 ms by the gateway. The minimum value of
<time> that can be requested when requesting an event is 40 ms.
When requesting a signal, the minimum value of <time> that can be
requested is 50 ms. The maximum value of <time> that can be
requested for either an event or a signal is 60000 ms. If the
"to=<time>" parameter is absent when requested as an event, the
event will report the full duration (up to 60000 ms) of the tone
when the tone is completed. When reported as an ObservedEvent,
both parameters are always supplied. In this case, <tone> is the
actual tone detected and <time> is either:
* The <time> specified in the request (possibly rounded), or
* If the request did not contain a "to=<time>" parameter, the
full duration of the tone.
The parameter "su" MAY be included when this is requested as an
event (but is not reported). This parameter is used to indicate
whether or not the DTMF digits requested should be suppressed
in-band when it is requested. Possible values are "true",
indicating that in-band DTMF should be suppressed and "false"
indicating that DTMF should continue to be passed in-band. The
default value of the parameter, if missing, is "false". The "su"
parameter MUST NOT be included when requesting "D/dd" as a signal.
When used as a signal, "dd" provides the ability to generate a
DTMF tone as a TO signal. When applied as a signal, an additional
50 ms of silence will be tacked onto the end before the operation
complete occurs, i.e., "S: dd(dg=5,to=2500)" will play the DTMF
tone for the number "5" for 2.5 seconds, followed by 50 ms of
silence period. The operation complete (if requested) will be
notified after the silence interval occurs. Any value from 50 ms
to 60000 ms can be requested. Gateways generating or detecting
the tone may round off the requested time to the nearest 10 ms.
The "dd" event can be used in place of the "long duration" event
in order to detect a digit pressed for longer than 2 seconds. For
example, in order to detect if a user presses the long "#" for
longer than 2 seconds, a request could be made with the
RequestedEvents line "R: d/dd(N)(dg=#,to=2000)". The resulting
ObservedEvents line would be "O: d/dd(dg=#,to=2000)".
Suppose instead, that the RequestedEvents line contains
R: d/[0-9*#],d/dd
Suppose the user then pushes the "#" for 2.5 seconds. In this
case, two events will be notified:
O: d/#
when the "#" key is first pressed, and
O: d/dd(dg=#,to=2500)
when the "#" key is finally released.
DTMF OO Signal (do(dg=<tone>,<on-or-off>)):
This signal is used to generate a DTMF tone as an on-off signal.
The <tone> parameter is any of the symbols for a specific tone in
the DTMF package (i.e., "0" to "9", "A", "B", "C", "D", "*", or
"#"). The <on-or-off> indicator is "+" for on and "-" for off as
per [1]. The <tone> parameter MUST be supplied, otherwise a
return code of 538 - "Event/signal parameter error" will be
provided in the response. If the <on-or-off> parameter is
missing, the default is to turn the signal on as usual (i.e., "+"
is the default). The order of the parameters is not significant
since "+" and "-" are reserved characters and are easily
distinguished from the <tone> parameter.
Long Duration Indicator (l):
The "long duration indicator" is observed when a DTMF signal is
produced for a duration larger than two seconds. In this case,
the gateway will detect two successive events: first, when the
signal has been recognized, the DTMF signal, and then, 2 seconds
later, the long duration signal.
Operation Complete (oc):
This is the standard definition of operation complete [1].
Operation Failure (of):
This is the standard definition of operation failure [1].
Timer (t):
Timer T can be used as an event or as a time-out (TO) signal. As
a signal, its only behavior is the normal characteristics of a
"TO" signal as defined in [1] (i.e., if no event occurs before the
time-out, an operation complete event will be generated).
As an event, Timer T is a digit input timer that can be used in
two ways:
* When timer T is used with the accumulate according to digit
map action, the timer is not started until the first DTMF
tone is entered, and the timer is restarted after each new
DTMF tone is entered until either a digit map match or
mismatch occurs. In this case, timer T functions as an
inter-digit timer as illustrated by:
R: D/[0-9T](D)
* When timer T is used without the "accumulate according to
digit map" action, the timer is started immediately and
simply cancelled (but not restarted) as soon as a DTMF tone
is entered. In this case, timer T can be used as an inter-
digit timer when overlap sending is used, as in:
R: D/[0-9](N), D/T(N)
When used with the "accumulate according to digit map" action,
timer T takes on one of two values, T-partial or T-critical. When
at least one more symbol is required for the "current dial string"
to match any one of the patterns in the digit map, timer T takes
on the value T-partial, corresponding to partial dial timing. If
a timer is all that is required to produce a match, timer T takes
on the value T-critical corresponding to critical dial timing.
When timer T is used without the "accumulate according to digit
map" action, timer T takes on the value T-critical. The default
value for T-partial is 16 seconds and the default value for
T-critical is 4 seconds. The provisioning process may alter both
of these. If timer T is not used, then inter-digit timing will
not be performed.
The following examples illustrate this. Consider the digit map:
(xxxxxxx|x11T)
and assume that DTMF and the timer T is accumulated according to
digit map. At the first DTMF input, say "4", timer T is started
with a value of T-partial since at least one more symbol is
required. If "1" is then input, it leads to a restart of timer T
with a value of T-partial again. If "1" is now input again, we
have a current dial string of "411" and a timer is now all that is
required to produce a match. Hence timer T is now restarted with
value T-critical.
Finally, consider the following subtle examples (all assuming DTMF
and timer T being accumulated according to digit map):
The digit map
(1[2-3T].)
will match immediately on the input "1" since zero or more matches
of the range are specified.
The digit map
(1[2-3].T)
and an input of "1" will lead to timer T being set to T-critical.
A digit map of
(1[2-3]T.)
and an input of "1" will lead to timer T being set to T-partial.
Furthermore, upon subsequent input of "2" or "3" a perfect match
will be triggered immediately since timer T is completely
irrelevant.
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.
(page 16 continued on part 2)
