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.
2.3. Trunk Package
Package Name: T
Version: 1
----------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|----------------------------------------------------------------|
| as | Answer Supervision | x | BR |
| bl | Blocking | | BR |
| bz | Busy | | TO 30 sec. |
| co1 | Continuity Tone (go tone, | x | TO 3 sec. |
| | or return tone) | | |
| co2 | Continuity Test (go tone, | x | TO 3 sec. |
| | or return tone in dual tone | | |
| | procedures) | | |
| ct(...) | Continuity Transponder | | OO |
| lb | Loopback | | OO |
| nm | New Milliwatt Tone | x | TO 3 sec |
| mm | Newest Milliwatt Tone | x | TO 3 sec |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| om | Old Milliwatt Tone | x | TO 3 sec |
| pst | Permanent Signal Tone | | TO infinite |
| qt | Quiet Termination | | TO infinite |
| ro | Reorder Tone | x | TO 30 sec. |
| sit(#) | Special Information Tone | x | TO 2 sec. |
| | | | (see notes) |
| tl | Test Line | x | TO infinite |
| tp(###) | Test Pattern | x | TO 3 sec |
| zz | No Circuit | x | TO 2 sec |
----------------------------------------------------------------
New events added to this package from the previously unversioned
package: "bz", "ct", "mm", "oc", "pst", "qt", "sit", and "tp".
Changes in event types: "co1", "co2", "nm", "om", "tl", "zz" signals
changed from OO to TO; "as" and "bl" changed from OO to BR.
Note that default time-out values may be over-ridden by the Call
Agent for any Time-Out signal defined in this package by a "to"
signal parameter. Refer to section 2 of this document, as well as
[1] for details.
The definition of the trunk package events are as follows:
Answer Supervision (as):
This event is used to indicate the occurrence answer supervision.
In most cases, it is a result of a steady off-hook in response to
a call request. This event is included for backwards
compatibility with the previous version of the package. The
preferred alternative is to use the "answer" event in the
appropriate CAS packages [34] (Note: check the details on the use
of "answer" in the particular CAS package; in most cases "answer"
as an event is an indication of a steady off-hook regardless of
whether or not it is an indication of answer supervision). For
details on when answer supervision is appropriate refer to [5].
Blocking (bl):
This event is used to indicate an incoming off-hook for the
purposes of blocking a one-way trunk in CAS trunks. This event is
included for backwards compatibility with the previous version of
the package. The preferred alternative is the "block" event in
the appropriate CAS packages [34].
Busy Tone (bz):
Refer to ITU-T E.180 [8]. In North America, station Busy is a
combination of two AC tones with frequencies of 480 and 620 Hertz
and levels of -24 dBm each, to give a combined level of -21 dBm.
The cadence for Station Busy Tone is 0.5 seconds on, followed by
0.5 seconds off, then repeating. See GR-506-CORE [7]- LSSGR:
SIGNALING, Section 17.2.6.
Continuity Tone (co1):
A tone at 2010 Hz (see section 3.1.1.3 of [2]). When generated as
a signal, the frequency of the tone must be within + or - 8 Hz,
while the frequency of the tone corresponding to the event must be
within + or - 30 Hz.
Continuity Test (co2):
A tone at 1780 Hz (see section 3.1.1.3 of [2]). When generated as
a signal, the frequency of the tone must be within + or - 20 Hz,
while the frequency of the tone corresponding to the event must be
within + or - 30 Hz.
In continuity testing the tone corresponding to the signal at the
originating gateway is referred to as the "go" tone, and the tone
corresponding to the event at that same gateway is referred to as
the "return" or "check" tone.
Note that generation and notification of continuity tones are done
as per continuity test requirements as defined in ITU-T Q.724 [3],
as well as by Bellcore GR-317-CORE [2] specifications, i.e., the
semantics of notification of the return tone is more than that the
tone was received, but is an indication that the test has passed.
Details are provided in the following paragraphs.
The continuity tones represented by co1 and co2 are used when the
Call Agent wants to initiate a continuity test. There are two
types of tests, single tone and dual tone; In the case of the dual
tone, either tone can be sent and the opposite received depending
on the trunk interconnections (4-wire or 2-wire) as indicated
below:
Originating Terminating
============ ===========
4w -------------- 1780 Hz -----------> 2w
<------------- 2010 Hz ------------ (transponder)
2w -------------- 2010 Hz -----------> 2w/4w
<------------- 1780 Hz ------------ (transponder)
4w -------------- 2010 Hz -----------> 4w
<------------- 2010 Hz ------------ (loopback)
The Call agent is expected to know, through provisioning
information, which test should be applied to a given endpoint. As
an example, for a 4-wire to 2-wire connection, the Call Agent
might send a request like the following to an originating gateway:
RQNT 1234 ds/ds1-1/17@tgw2.example.net
X: AB123FE0
S: t/co1
R: t/co2,t/oc,t/of
On a terminating side of a trunk, the call agent may request a
continuity test connection (connection mode "conttest") to the
terminating gateway as follows:
CRCX 3001 ds/ds1-2/4@tgw34.example.net
C: 3748ABC364
M: conttest
Alternatively, rather than using a connection mode, the "T/ct"
signal can be used (see description of this signal further below):
RQNT 3001 ds/ds1-2/4@tgw34.example.net
X: 1233472
S: t/ct(in=co1,out=co2,+)
The originating gateway would send the requested "go" tone, and
would look for the appropriate "return tone". Once the return
tone is received, the originating gateway removes the go tone and
checks to see that the return tone has been removed within the
specified performance limits (i.e., GR-246-CORE, T1.113.4, Annex B
[23]). When it detects that the test is successful, the gateway