list of requested events and digit map. When processing these events,
the gateway may encounter an event which requires a Notify command to
be sent. If that is the case, the gateway can adopt one of the two
following behaviors:
* it can immediately transmit a Notify command that will report all
events that were accumulated in the list of observed events until
the triggering event, included, leaving the unprocessed events in
the quarantine list,
* or it can attempt to empty the quarantined list and transmit a
single Notify command reporting several sets of events and
possibly several dial strings. The dial string is reset to a null
value after each triggering event. The events that follow the last
triggering event are left in the quarantine list.
If the gateway transmits a Notify command, the end point will remain
in the "notification state" until the acknowledgement is received. If
the gateway does not find a quarantined event that requests a Notify
command, it places the end point in a normal state. Events are then
processed as they come, in exactly the same way as if a Notification
Request command had just been received.
A gateway may receive at any time a new Notification Request command
for the end point. When a new notification request is received in the
notification state, the gateway shall ensure that the pending
notification is received by the Call Agent prior to a successful
response to the new NotificationRequest. It does so by using the
"piggy-backing" functionality of the protocol. The messages will then
be sent in a single packetto the source of the new
NotificationRequest, regardless of respectively the source and
"notified entity" for the old and new command. The steps involved are
the following:
a) the gateway builds a message that carries in a single packet a
repetition of the old pending Notify command and the
acknowledgement of the new notification request.
b) the endpoint is then taken out of the "notification state" without
waiting for the acknowledgement of the notification command.
c) a copy of the unacknowledged Notify command command is kept until
an acknowledgement is received. If a timer elapses, the
notification will be repeated, in a packet that will also carry a
repetition of the acknowledgement of the notification request.
d) if the acknowledgement is lost, the Call Agent will retransmit the
Notification Request. The gateway will reply to this repetition
by retransmitting in a single packet the unacknowledged Notify and
the acknowledgement of the notification request.
e) if the gateway has to transmit a Notify before the previous Notify
is acknowledged, it should construct a packet that piggybacks a
repetition of the old Notify, a repetition of the acknowledgement
of the last notification request and the new Notify.
f) Gateways that cannot piggyback several packets in the same message
should elect to leave the endpoint in the "notification" state as
long as the last notification is not acknowledged.
After receiving the Notification Request command, the requested
events list and digit map (if a new one was provided) are replaced by
the newly received parameters, and the list of observed events and
accumulated dial string are reset to a null value. The behavior is
conditioned by the value of the QuarantineHandling parameter. The
parameter may specify that quarantined events, or previously observed
events, should be discarded, in which case they will be. If the
parameter specifies that the quarantined events should be processed,
the gateway will start processing the list of quarantined events or
previously observed events, using the newly received list of
requested events and digit map. When processing these events, the
gateway may encounter an event which requires a Notify command to be
sent. If that is the case, the gateway will immediately transmit a
Notify command that will report all events that were accumulated in
the list of observed events until the triggering event, included,
leaving the unprocessed events in the quarantine buffer, and will
enter the "notification state".
A new notification request may be received while the gateway has
accumulated events according to the previous notification requests,
but has not yet detected a notification-triggering events. The
handling of not-yet-notified events is determined, as with the
quarantined events, by the quarantine handling parameters:
* If the quarantine-handling parameter specifies that quarantined
events shall be ignored, the observed event list is simply reset.
* If the quarantine-handling parameter specifies that quarantined
events shall be processed, the observed event list is transferred
to the quarantined event list. The observed event list is then
reset, and the quarantined event list is processed.
Call Agents SHOULD provide the response to a successful Notify
message and the new NotificationRequest in the same datagram using
the piggy-backing mechanism.
4.3.2. Explicit detection
A key element of the state of several endpoints is the position of
the hook. A race condition may occur when the user decides to go
off-hook before the Call Agent has the time to ask the gateway to
notify an off hook event (the "glare" condition well known in
telephony), or if the user goes on-hook before the Call Agent has the
time to request the event's notification.
To avoid this race condition, the gateway should check the condition
of the endpoint before acknowledging a NotificationRequest. It should
return an error:
1- If the gateway is requested to notify an "off hook" transition
while the phone is already off hook,
2- If the gateway is requested to notify an "on hook" or "flash hook"
condition while the phone is already on hook.
It should be noted, that the condition check is performed at the time
the notification request is received, where as the actual event that
caused the current condition may have either been reported, or
ignored earlier, or it may currently be quarantined.
The other state variables of the gateway, such as the list of
RequestedEvent or list of requested signals, are entirely replaced
after each successful NotificationRequest, which prevents any long
term discrepancy between the Call Agent and the gateway.
When a NotificationRequest is unsuccessful, whether it is included in
a connection-handling command or not, the gateway will simply
continue as if the command had never been received. As all other
transactions, the NotificationRequest should operate as an atomic
transaction, thus any changes initiated as a result of the command
should be reverted.
Another race condition may occur when a Notify is issued shortly
before the reception by the gateway of a NotificationRequest. The
RequestIdentifier is used to correlate Notify commands with
NotificationRequest commands.
4.3.3. Ordering of commands, and treatment of disorder
MGCP does not mandate that the underlying transport protocol
guarantees the sequencing of commands sent to a gateway or an
endpoint. This property tends to maximize the timeliness of actions,
but it has a few draw backs. For example:
* Notify commands may be delayed and arrive to the call agent after
the transmission of a new Notification Request command,
* If a new NotificationRequest is transmitted before a previous one
is acknowledged, there is no guarantee that the previous one will
not be received in second position.
Call Agents that want to guarantee consistent operation of the end
points can use the following rules:
1) When a gateway handles several endpoints, commands pertaining to
the different endpoints can be sent in parallel, for example
following a model where each endpoint is controlled by its own
process or its own thread.
2) When several connections are created on the same endpoint,
commands pertaining to different connections can be sent in
parallel.
3) On a given connection, there should normally be only one
outstanding command (create or modify). However, a
DeleteConnection command can be issued at any time. In
consequence, a gateway may sometimes receive a ModifyConnection
command that applies to a previously deleted connection. Such
commands should be ignored, and an error code should be returned.
4) On a given endpoint, there should normally be only one outstanding
NotificationRequest command at any time. The RequestId parameter
should be used to correlate Notify commands with the triggering
notification request.
5) In some cases, an implicitly or explicitly wildcarded
DeleteConnection command that applies to a group of endpoints can
step in front of a pending CreateConnection command. The Call
Agent should individually delete all connections whose completion
was pending at the time of the global DeleteConnection command.
Also, new CreateConnection commands for endpoints named by the
wild-carding cannot be sent until the wild-carded DeleteConnection
command is acknowledged.
6) When commands are embedded within each other, sequencing
requirements for all commands must be adhered to. For example a
Create Connection command with a Notification Request in it must
adhere to the sequencing for CreateConnection and
NotificationRequest at the same time.
7) AuditEndpoint and AuditConnection is not subject to any
sequencing.
8) RestartInProgress must always be the first command sent by an
endpoint as defined by the restart procedure. Any other command or
response must be delivered after this RestartInProgress command
(piggy-backing allowed).
9) When multiple messages are piggy-backed in a single packet, the
messages are always processed in order.
These rules do not affect the gateway, which should always respond to
commands.
4.3.4. Fighting the restart avalanche
Let's suppose that a large number of gateways are powered on
simultaneously. If they were to all initiate a RestartInProgress
transaction, the call agent would very likely be swamped, leading to
message losses and network congestion during the critical period of
service restoration. In order to prevent such avalanches, the
following behavior is suggested:
1) When a gateway is powered on, it should initiate a restart timer
to a random value, uniformly distributed between 0 and a maximum
waiting delay (MWD). Care should be taken to avoid synchronicity
of the random number generation between multiple gateways that
would use the same algorithm.
2) The gateway should then wait for either the end of this timer, the
reception of a command from the call agent, or the detection of a
local user activity, such as for example an off-hook transition on
a residential gateway.
3) When the timer elapses, when a command is received, or when an
activity is detected, the gateway should initiate the restart
procedure.
The restart procedure simply requires the endpoint to guarantee that
the first message (command or response) that the Call Agent sees from
this endpoint is a RestartInProgress message informing the Call Agent
about the restart. The endpoint is free to take full advantage of
piggy-backing to achieve this.
It is expected that each endpoint in a gateway will have a
provisionable Call Agent, i.e., "notified entity", to direct the
initial restart message towards. When the collection of endpoints in
a gateway is managed by more than one Call Agent, the above procedure
must be performed for each collection of endpoints managed by a given
Call Agent. The gateway MUST take full advantage of wild-carding to
minimize the number of RestartInProgress messages generated when
multiple endpoints in a gateway restart and the endpoints are managed
by the same Call Agent.
The value of MWD is a configuration parameter that depends on the
type of the gateway. The following ]reasoning can be used to
determine the value of this delay on residential gateways.
Call agents are typically dimensioned to handle the peak hour traffic
load, during which, in average, 10% of the lines will be busy,
placing calls whose average duration is typically 3 minutes. The
processing of a call typically involves 5 to 6 MGCP transactions
between each end point and the call agent. This simple calculation
shows that the call agent is expected to handle 5 to 6 transactions
for each end point, every 30 minutes on average, or, to put it
otherwise, about one transaction per end point every 5 to 6 minutes
on average. This suggest that a reasonable value of MWD for a
residential gateway would be 10 to 12 minutes. In the absence of
explicit configuration, residential gateways should adopt a value of
600 seconds for MWD.
The same reasoning suggests that the value of MWD should be much
shorter for trunking gateways or for business gateways, because they
handle a large number of endpoints, and also because the usage rate
of these endpoints is much higher than 10% during the peak busy hour,
a typical value being 60%. These endpoints, during the peak hour,
are this expected to contribute about one transaction per minute to
the call agent load. A reasonable algorithm is to make the value of
MWD per "trunk" endpoint six times shorter than the MWD per
residential gateway, and also inversely proportional to the number of
endpoints that are being restarted. for example MWD should be set to
2.5 seconds for a gateway that handles a T1 line, or to 60
milliseconds for a gateway that handles a T3 line.
4.3.5. Disconnected Endpoints
In addition to the restart procedure, gateways also have a
"disconnected" procedure, which is initiated when an endpoint becomes
"disconnected" as described in Section 3.4.2. It should here be
noted, that endpoints can only become disconnected when they attempt
to communicate with the Call Agent. The following steps are followed
by an endpoint that becomes "disconnected":
1. A "disconnected" timer is initialized to a random value, uniformly
distributed between 0 and a provisionable "disconnected" initial
waiting delay (Tdinit), e.g., 15 seconds. Care MUST be taken to
avoid synchronicity of the random number generation between
multiple gateways and endpoints that would use the same algorithm.
2. The gateway then waits for either the end of this timer, the
reception of a command from the call agent, or the detection of a
local user activity for the endpoint, such as for example an off-
hook transition.
3. When the "disconnected" timer elapses, when a command is received,
or when a local user activity is detected, the gateway initiates
the "disconnected" procedure for the endpoint. In the case of
local user activity, a provisionable "disconnected" minimum
waiting delay (Tdmin) must furthermore have elapsed since the
gateway became disconnected or the last time it initiated the
"disconnected" procedure in order to limit the rate at which the
procedure is performed.
4. If the "disconnected" procedure still left the endpoint
disconnected, the "disconnected" timer is then doubled, subject to
a provisionable "disconnected" maximum waiting delay (Tdmax),
e.g., 600 seconds, and the gateway proceeds with step 2 again.
The "disconnected" procedure is similar to the restart procedure in
that it now simply states that the endpoint MUST send a
RestartInProgress command to the Call Agent informing it that the
endpoint was disconnected and furthermore guarantee that the first
message (command or response) that the Call Agent now sees from this
endpoint MUST be this RestartInProgress command. The endpoint MUST
take full advantage of piggy-backing in achieving this. The Call
Agent may then for instance decide to audit the endpoint, or simply
clear all connections for the endpoint.
This specification purposely does not specify any additional behavior
for a disconnected endpoint. Vendors MAY for instance choose to
provide silence, play reorder tone, or even enable a downloaded wav
file to be played.
The default value for Tdinit is 15 seconds, the default value for
Tdmin, is 15 seconds, and the default value for Tdmax is 600 seconds.
5. Security requirements
If unauthorized entities could use the MGCP, they would be able to
set-up unauthorized calls, or to interfere with authorized calls. We
expect that MGCP messages will always be carried over secure Internet
connections, as defined in the IP security architecture as defined in
RFC2401, using either the IP Authentication Header, defined in RFC
2402, or the IP Encapsulating Security Payload, defined in RFC2406.
The complete MGCP protocol stack would thus include the following
layers:
________________________________
| MGCP |
|_______________________________|
| UDP |
|_______________________________|
| IP security |
| (authentication or encryption)|
|_______________________________|
| IP |
|_______________________________|
| transmission media |
|_______________________________|
Adequate protection of the connections will be achieved if the
gateways and the Call Agents only accept messages for which IP
security provided an authentication service. An encryption service
will provide additional protection against eavesdropping, thus
forbidding third parties from monitoring the connections set up by a
given endpoint
The encryption service will also be requested if the session
descriptions are used to carry session keys, as defined in SDP.
These procedures do not necessarily protect against denial of service
attacks by misbehaving gateways or misbehaving call agents. However,
they will provide an identification of these misbehaving entities,
which should then be deprived of their authorization through
maintenance procedures.
5.1. Protection of media connections
MGCP allows call agent to provide gateways with "session keys" that
can be used to encrypt the audio messages, protecting against
eavesdropping.
A specific problem of packet networks is "uncontrolled barge-in."
This attack can be performed by directing media packets to the IP
address and UDP port used by a connection. If no protection is
implemented, the packets will be decompressed and the signals will be
played on the "line side".
A basic protection against this attack is to only accept packets from
known sources, checking for example that the IP source address and
UDP source port match the values announced in the "remote session
description." But this has two inconveniences: it slows down
connection establishment and it can be fooled by source spoofing:
* To enable the address-based protection, the call agent must obtain
the remote session description of the e-gress gateway and pass it
to the in-gress gateway. This requires at least one network round
trip, and leaves us with a dilemma: either allow the call to
proceed without waiting for the round trip to complete, and risk
for example "clipping" a remote announcement, or wait for the full
round trip and settle for slower call-set-up procedures.
* Source spoofing is only effective if the attacker can obtain valid
pairs of source destination addresses and ports, for example by
listening to a fraction of the traffic. To fight source spoofing,
one could try to control all access points to the network. But
this is in practice very hard to achieve.
An alternative to checking the source address is to encrypt and
authenticate the packets, using a secret key that is conveyed during
the call set-up procedure. This will no slow down the call set-up,
and provides strong protection against address spoofing.
6. Event packages and end point types
This section provides an initial definition of packages and event
names. More packages can be defined in additional documents.
6.1. Basic packages
The list of basic packages includes the following:
_________________________________________
| Package | name |
|______________________________|_________|
| Generic Media Package | G |
| DTMF package | D |
| MF Package | M |
| Trunk Package | T |
| Line Package | L |
| Handset Package | H |
| RTP Package | R |
| Network Access Server Package| N |
| Announcement Server Package | A |
| Script Package | Script|
|______________________________|_________|
In the tables of events for each package, there are five columns:
Symbol: the unique symbol used for the event
Definition: a short description of the event
R: an x appears in this column is the event can be Requested by
the call agent.
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. The signal is turned on until commanded by the
call agent to turn it off, and vice versa.
TO Timeout signal. The signal lasts for a given duration unless
it is superseded by a new signal.
BR Brief signal. The event has a short, known duration.
Duration: specifies the duration of TO signals.
6.1.1. Generic Media Package
Package Name: G
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 |
|__________|____________________________|_____|______________________|
| mt | Modem detected | x | |
| ft | Fax tone detected | x | |
| ld | Long duration connection | x | |
| pat(###) | Pattern ### detected | x | OO |
| rt | Ringback tone | | TO |
| rbk(###) | ring back on connection | | TO 180 seconds |
| cf | Confirm tone | | BR |
| cg | Network Congestion tone | | TO |
| it | Intercept tone | | OO |
| pt | Preemption tone | | OO |
| of | report failure | x | |
|__________|____________________________|_____|______________________|
The signals are defined as follows:
The pattern definition can be used for specific algorithms such as
answering machine detection, tone detection, and the like.
Ring back tone (rt)
an Audible Ring Tone, 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.
Ring back on connection
A ring back tone, applied to the connection whose identifier is
passed as a parameter.
The "long duration connection" is detected when a connection has been
established for more than 1 hour.
6.1.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 | 2 seconds|
| X | Wildcard, match | x | |
| | any digit 0-9 | | |
| T | Interdigit timer | x | 4 seconds|
| of | report failure | x | |
|________|___________________________|_____|___________________|
The "interdigit timer" T is a digit input timer that can be used in
two ways:
* When timer T is used with a digit map, the timer is not started
until the first digit is entered, and the timer is restarted after
each new digit is entered until either a digit map match or
mismatch occurs. In this case, timer T functions as an inter-digit
timer.
* When timer T is used without a digit map, 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
interdigit timer when overlap sending is used.
When used with a digit map, timer T takes on one of two values,
T(partial) or T(critical). When at least one more digit is
required for the digit string to match any 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 timing. When timer T is used without a digit map, 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.
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.
6.1.3. MF Package
Package Name: M
________________________________________________________
| Symbol | Definition | R | S Duration |
|________|____________________|_____|___________________|
| 0 | MF 0 | x | BR |
| 1 | MF 1 | x | BR |
| 2 | MF 2 | x | BR |
| 3 | MF 3 | x | BR |
| 4 | MF 4 | x | BR |
| 5 | MF 5 | x | BR |
| 6 | MF 6 | x | BR |
| 7 | MF 7 | x | BR |
| 8 | MF 8 | x | BR |
| 9 | MF 9 | x | BR |
| X | Wildcard, match | x | |
| | any digit 0-9 | | |
| T | Interdigit timer | x | 4 seconds|
| K0 | MF K0 or KP | x | BR |
| K1 | MF K1 | x | BR |
| K2 | MF K2 | x | BR |
| S0 | MF S0 or ST | x | BR |
| S1 | MF S1 | x | BR |
| S2 | MF S2 | x | BR |
| S3 | MF S3 | x | BR |
| wk | Wink | x | BR |
| wko | Wink off | x | BR |
| is | Incoming seizure | x | OO |
| rs | Return seizure | x | OO |
| us | Unseize circuit | x | OO |
| of | report failure | x | |
|________|____________________|_____|___________________|
The definition of the MF package events is as follows:
Wink
A transition from unseized to seized to unseized trunk states
within a specified period. Typical seizure period is 100-350
msec.)
Incoming seizure
Incoming indication of call attempt.
Return seizure:
Seizure in response to outgoing seizure.
Unseize circuit:
Unseizure of a circuit at the end of a call.
Wink off:
A signal used in operator services trunks. A transition from
seized to unseized to seized trunk states within a specified
period of 100-350 ms. (To be checked)
6.1.4. Trunk Package
Package Name: T
_____________________________________________________________________
| Symbol | Definition | R | S Duration |
|________|________________________________|_____|____________________|
| co1 | Continuity tone (single tone,| x | OO |
| | or return tone) | | |
| co2 | Continuity test (go tone, | x | OO |
| | in dual tone procedures) | | |
| lb | Loopback | | OO |
| om | Old Milliwatt Tone (1000 Hz) | x | OO |
| nm | New Milliwatt Tone (1004 Hz) | x | OO |
| tl | Test Line | x | OO |
| zz | No circuit | x | OO |
| as | Answer Supervision | x | OO |
| ro | Reorder Tone | x | TO 30 seconds|
| of | report failure | x | |
| bl | Blocking | | OO |
|________|________________________________|_____|____________________|
The definition of the trunk package signal events is as follows:
Continuity Tone (co1):
A tone at 2010 + or - 30 Hz.
Continuity Test (co2):
A tone at the 1780 + or - 30 Hz.
Milliwatt Tones:
Old Milliwatt Tone (1000 Hz), New Milliwatt Tone (1004 Hz)
Line Test:
105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0
+ or -- 0.5dB).
No circuit:
(that annoying tri-tone, low to high)
Answer Supervision:
Reorder Tone:
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.
See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7.
Blocking:
The call agent can place the circuit in a blocked state by
applying the "bl(+)" signal to the endpoint. It can unblock it by
applying the "bl(-)" signal.
The continuity tones are used when the call agent wants to initiate a
continuity test. There are two types of tests, single tone and dual
tone. 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 epx-t1/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:
RQNT 1234 epx-t1/17@tgw2.example.net
X: AB123FE0
S: co2
R: co1
The gateway would send the requested signal, and in both cases would
look for the return of the 2010 Hz tone (co1). When it detects that
tone, it will send the corresponding notification.
The tones are of type OO: the gateway will keep sending them until it
receives a new notification request.
6.1.5. Line Package
Package Name: L
________________________________________________________________________
|Symbol | Definition | R | S Duration |
|_____________|______________________________|_____|___________________|
|adsi(string) | adsi display | | BR |
|vmwi | visual message | | OO |
| | waiting indicator | | |
|hd | Off hook transition | x | |
|hu | On hook transition | x | |
|hf | Flash hook | x | |
|aw | Answer tone | x | OO |
|bz | Busy tone | | TO 30 seconds |
|ci(ti,nu,na) | Caller-id | | BR |
|wt | Call Waiting tone | | TO 30 seconds |
|wt1, wt2, | Alternative call | | |
|wt3, wt4 | waiting tones | | |
|dl | Dial tone | | TO 16 seconds |
|mwi | Message waiting ind. | | TO 16 seconds |
|nbz | Network busy | x | OO |
| | (fast cycle busy) | | |
|ro | Reorder tone | | TO 30 seconds |
|rg | Ringing | | TO 180 seconds|
|r0, r1, r2, | Distinctive ringing | | TO 180 seconds|
|r3, r4, r5, | | | |
|r6 or r7 | | | |
|rs | Ringsplash | | BR |
|p | Prompt tone | x | BR |
|e | Error tone | x | BR |
|sl | Stutter dialtone | | TO 16 seconds |
|v | Alerting Tone | | OO |
|y | Recorder Warning Tone | | OO |
|sit | SIT tone | | |
|z | Calling Card Service Tone | | OO |
|oc | Report on completion | x | |
|ot | Off hook warning tone | | TO indefinite |
|s(###) | Distinctive tone pattern | x | BR |
|of | report failure | x | |
|_____________|______________________________|_____|___________________|
The definition of the tones is as follows:
Dial tone:
A combined 350 + 440 Hz tone.
Visual Message Waiting Indicator
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 TR-H-000030 and the CPE guidelines in
SR-TSV-002476. VMWI messages will only be sent from the SPCS 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. The CA should periodically refresh the
CPE's visual indicator. See TR-NWT-001401 - Visual Message Waiting
Indicator Generic Requirements; and GR- 30-CORE - Voiceband Data
Transmission Interface.
Message waiting Indicator
See GR-506-CORE, 17.2.3.
Alerting Tone:
a 440 Hz Tone of 2 second duration followed by 1/2 second of tone
every 10 seconds.
Ring splash
Ringsplash, 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 subfeature is active. In the US, it is defined to be a
0.5(-0,+0.1) second burst of power ringing. See TR-TSY-000586 -
Call Forwarding Subfeatures.
Call waiting tone
Call Waiting tone is defined in GR-506-CORE, 14.2. Call Waiting
feature is defined in TR-TSY-000571. By defining "wt" as a TO
signal you are really defining the feature which seems wrong to me
(given the spirit of MGCP), hence the definition of "wt" as a BR
signal in ECS, per GR-506-CORE. Also, it turns out that there is
actually four different call waiting tone patterns (see GR-506-
CORE, 14.2) so we have wt1, wt2, wt3, wt4.
Caller Id (ci(time, number, name)):
The caller-id event carries three parameters, the time of the
call, the calling number and the calling name. Each of the three
fields are optional, however each of the commas will always be
included. See TR-NWT-001188, GR-30-CORE, and TR-NWT-000031.
Recorder Warning Tone:
1400 Hz of Tone of 0.5 second duration every 15 seconds.
SIT tone:
used for indicating a line is out of service.
Calling Card Service Tone:
60 ms of 941 + 1477 Hz and 940 ms of 350 + 440 Hz (dial tone),
decaying exponentially with a time constant of 200 ms.
Distinctive tone pattern:
where ### is any number between 000 and 999, inclusive. Can be
used for distinctive ringing, customized dial tone, etc.
Report on completion
The report on completion event is detected when the gateway was
asked to perform one or several signals of type TO on the
endpoint, and when these signals were 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
parameter the name of the signal that came to the end of its live
time, as in:
O: L/oc(L/dl)
Ring back on connection
A ring back tone, applied to the connection wghose identifier is
passed as a parameter.
We should note that many of these definitions vary from country to
country. The frequencies listed above are the one in use in North
America. There is a need to accommodate different tone sets in
different countries, and there is still an ongoing debate on the best
way to meet that requirement:
* One solution is to define different event packages specifying for
example the German dialtone as "L-DE/DL".
* Another solution is to use a management interface to specify on an
endpoint basis which frequency shall be associated to what tone.
6.1.6. Handset emulation package
Package Name: H
________________________________________________________________________
|Symbol | Definition | R | S Duration |
|_____________|______________________________|_____|___________________|
|adsi(string) | adsi display | x | BR |
|tdd | | | |
|vmwi | | | |
|hd | Off hook transition | x | OO |
|hu | On hook transition | x | OO |
|hf | Flash hook | x | BR |
|aw | Answer tone | x | OO |
|bz | Busy tone | x | OO |
|wt | Call Waiting tone | x | TO 30 seconds |
|dl | Dial tone (350 + 440 Hz) | x | TO 120 seconds|
|nbz | Network busy | x | OO |
| | (fast cycle busy) | | |
|rg | Ringing | x | TO 30 seconds |
|r0, r1, r2, | Distinctive ringing | x | TO 30 seconds |
|r3, r4, r5, | | | |
|r6 or r7 | | | |
|p | Prompt tone | x | BR |
|e | Error tone | x | BR |
|sdl | Stutter dialtone | x | TO 16 seconds |
|v | Alerting Tone | x | OO |
|y | Recorder Warning Tone | x | OO |
|t | SIT tone | x | |
|z | Calling Card Service Tone | x | OO |
|oc | Report on completion | x | |
|ot | Off hook warning tone | x | OO |
|s(###) | Distinctive tone pattern | x | BR |
|of | report failure | x | |
|_____________|______________________________|_____|___________________|
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.
6.1.7. RTP Package
Package Name: R
____________________________________________________________________
| 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 tone,| x | OO |
| | or return tone) | | |
| co2 | Continuity test (go tone, | x | OO |
| | in dual tone procedures) | | |
| of | report failure | x | |
|_________|________________________________|_____|__________________|
Codec Changed:
Codec changed to hexadecimal codec number enclosed in parenthesis,
as in UC(15), to indicate the codec was changed to PCM mu-law.
Codec Numbers are specified in RFC1890, or in a new definition of
the audio profiles for RTP that replaces this RFC. Some
implementations of media gateways may not allow the codec to be
changed upon command from the call agent. codec changed to codec
hexadecimal ##.
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. Some implementations of media
gateways may not allow the sampling rate to be changed upon
command from a call agent.
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 accomodate 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.
The continuity tones are the same as those defined in the Trunk
package. They can be use in conjunction with the Network LoopBack or
Network Continuity Test modes to test the continuity of an RTP
circuit.
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.
6.1.8. Network Access Server Package
Package Name: N
____________________________________________________________
| Symbol | Definition | R | S Duration|
|________|__________________________|_____|_________________|
| pa | Packet arrival | x | |
| cbk | Call back request | x | |
| cl | Carrier lost | x | |
| au | Authorization succeeded| x | |
| ax | Authorization denied | x | |
| of | Report failure | x | |
|________|__________________________|_____|_________________|
The packet arrival event is used to notify that at least one packet
was recently sent to an Internet address that is observed by an
endpoint. The event report includes the Internet address, in
standard ASCII encoding, between parenthesis:
O: pa(192.96.41.1)
The call back event is used to notify that a call back has been
requested during the initial phase of a data connection. The event
report includes the identification of the user that should be called
back, between parenthesis:
O: cbk(user25)
6.1.9. 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)
6.1.10. 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|
| 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.
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)
The failure report may also return a string, as in:
O: script/oc(21223456794567,9738234567)
The definition of the script environment and the specific actions in
that environment are for further study.
6.2. Basic endpoint types and profiles
We define the following basic endpoint types and profiles:
* Trunk gateway (ISUP)
* Trunk gateway (MF)
* Network Access Server (NAS)
* Combined NAS/VOIP gateway
* Access Gateway
* Residential Gateway
* Announcement servers
These gateways are supposed to implement the following packages
___________________________________________________________
| Gateway | Supported packages |
|____________________________|_____________________________|
| Trunk gateway (ISUP) | GM, DTMF, TK, RTP |
| Trunk gateway (MF) | GM, MF, DTMF, TK, RTP |
| Network Access Server (NAS)| GM, MF, TK, NAS |
| Combined NAS/VOIP gateway | GM, MF, DTMF, TK, NAS, RTP|
| Access Gateway (VOIP) | GM, DTMF, MF, RTP |
| Access Gateway (VOIP+NAS) | GM, DTMF, MF, NAS, RTP |
| Residential Gateway | GM, DTMF, Line, RTP |
| Announcement Server | ANN, RTP |
|____________________________|_____________________________|
Advanced announcement servers may also support the Script package.
Advanced trunking servers may support the ANN package, the Script
package, and in some cases the Line and Handset package as well.
7. Versions and compatibility
7.1. Differences between version 1.0 and draft 0.5
Draft 0-5 was issued in February 1999, as the last update of draft
version 0.1. Version 1.0 benefits from implementation experience, and
also aligns as much as possible with the CableLabs' NCS project. The
main differences between the February draft and version 1.0 are:
* Specified more clearly that the encoding of three
LocalConnectionOptions parameters, Encoding Method, Packetization
Period and Bandwidth, shall follow the conventions laid out in
SDP.
* Specified how the quarantine handling parameter governs the
handling of detected but not yet specified events.
* Specified that unexpected timers or digits should trigger
transmission of the dialed string.
* Removed the digit map syntax description from section 2.1.5 (it
was redundant with section 3.4.)
* Corrected miscellaneous bugs in the formal syntax description.
* Aligned specification of commands with the CableLabs NCS
specification. This mostly affects the AuditEndpoint and
RestartInProgress commands.
* Aligned the handling of retransmission with the CableLabs NCS
specification.
* Added the provisional response return code and corresponding
behavior description.
* Added an optional reason code parameter to restart in progress.
* Added the possibility to audit the restart method, restart delay
and reason code.
7.2. Differences between draft-04 and draft-05
Differences are minor: corrected the copyright statement, and
corrected a bug in the formal description.
7.3. Differences between draft-03 and draft-04
Draft 04 corrects a number of minor editing mistakes that were
pointed out during the review of draft 03, issued on February 1.
7.4. Differences between draft-02 and draft-03
The main differences between draft-02, issued in January 22 1998, and
draft 03 are:
* Introduced a discussion on endpoint types,
* Introduced a discussion of the connection set-up procedure, and of
the role of connection parameters,
* Introduced a notation of the connection identifier within event
names,
* Documented the extension procedure for the LocalConnectionOptions
parameter and for the ConnectionParameters parameter,
* Introduced a three-way handshake procedure, using a ResponseAck
parameter, in order to allow gateways to delete copies of old
responses without waiting for a 30 seconds timer,
* Expanded the security section to include a discussion of
"uncontrolled barge-in."
* Propsed a "create two connections" command, as an appendix.
7.5. Differences between draft-01 and draft-02
The main differences between draft-01, issued in November 1998, and
draft 02 are:
* Added an ABNF description of the protocol.
* Specification of an EndpointConfiguration command,
* Addition of a "two endpoints" mode in the create connection
command,
* Modification of the package wildcards from "$/$" to "*/all" at the
Request of early implementors,
* Revision of some package definitions to better align with external
specifications.
* Addition of a specification for the handling of "failover."
* Revision of the section on race conditions.
7.6. The making of MGCP from IPDC and SGCP
MGCP version 0.1 results from the fusion of the SGCP and IPDC
proposals.
7.7. Changes between MGCP and initial versions of SGCP
MGCP version 0.1 (which subsumes SGCP version 1.2) introduces the
following changes from SGCP version 1.1:
* Protocol name changed to MGCP.
* Introduce a formal wildcarding structure in the name of endpoints,
inspired from IPDC, and detailed the usage of wildcard names in
each operation.
* Naming scheme for events, introducing a package structure inspired
from IPDC.
* New operations for audit endpoint, audit connection (requested by
the Cablelabs) and restart (inspired from IPDC).
* New parameter to control the behavior of the notification request.
* Improved text on the detection and handling of race conditions.
* Syntax modification for event reporting, to incorporate package
names.
* Definition of basic event packages (inspired from IPDC).