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