RFC 2705
Media Gateway Control Protocol (MGCP) Version 1.0
3.6. Transmission over UDP
MGCP messages are transmitted over UDP. Commands are sent to one of the IP addresses defined in the DNS for the specified endpoint . The responses are sent back to the source address of the commands. When no port is specified for the endpoint, the commands should be sent: * by the Call Agents, to the default MGCP port for gateways, 2427. * by the Gateways, to the default MGCP port for Call Agents, 2727.3.6.1. Providing the At-Most-Once functionality
MGCP messages, being carried over UDP, may be subject to losses. In the absence of a timely response, commands are repeated. Most MGCP commands are not idempotent. The state of the gateway would become
unpredictable if, for example, CreateConnection commands were executed several times. The transmission procedures must thus provide an "At-Most-Once" functionality. MGCP entities are expected to keep in memory a list of the responses that they sent to recent transactions and a list of the transactions that are currently being executed. The transaction identifiers of incoming commands are compared to the transaction identifiers of the recent responses. If a match is found, the MGCP entity does not execute the transaction, but simply repeats the response. The remaining commands will be compared to the list of current transaction. If a match is found, the MGCP entity does not execute the transaction, which is simply ignored. The procedure use a long timer value, noted LONG-TIMER in the following. The timer should be set larger than the maximum duration of a transaction, which should take into account the maximum number of repetitions, the maximum value of the repetition timer and the maximum propagation delay of a packet in the network. A suggested value is 30 seconds. The copy of the responses can be destroyed either LONG-TIMER seconds after the response is issued, or when the gateway (or the call agent) receives a confirmation that the response has been received, through the "Response Acknowledgement attribute". For transactions that are acknowledged through this attribute, the gateway shall keep a copy of the transaction-id for LONG-TIMER seconds after the response is issued, in order to detect and ignore duplicate copies of the transaction request that could be produced by the network.3.6.2. Transaction identifiers and three ways handshake
Transaction identifiers are integer numbers in the range from 0 to 999,999,999. Call-agents may decide to use a specific number space for each of the gateways that they manage, or to use the same number space for all gateways that belong to some arbitrary group. Call agents may decide to share the load of managing a large gateway between several independent processes. These processes will share the same transaction number space. There are multiple possible implementations of this sharing, such as having a centralized allocation of transaction identifiers, or pre-allocating non- overlapping ranges of identifiers to different processes. The implementations must guarantee that unique transaction identifiers are allocated to all transactions that originate from a logical call agent, as defined in the "states, failover and race conditions" section. Gateways can simply detect duplicate transactions by looking at the transaction identifier only.
The Response Acknowledgement Attribute can be found in any command. It carries a set of "confirmed transaction-id ranges." MGCP gateways may choose to delete the copies of the responses to transactions whose id is included in "confirmed transaction-id ranges" received in the Response Confirmation messages. They should silently discard further commands from that Call Agent when the transaction-id falls within these ranges. The "confirmed transaction-id ranges" values shall not be used if more than LONG-TIMER seconds have elapsed since the gateway issued its last response to that call agent, or when a gateway resumes operation. In this situation, commands should be accepted and processed, without any test on the transaction-id. Commands that carry the "Response Acknowledgement attribute" may be transmitted in disorder. The gateway shall retain the union of the "confirmed transaction-id ranges" received in recent commands.3.6.3. Computing retransmission timers
It is the responsibility of the requesting entity to provide suitable time outs for all outstanding commands, and to retry commands when time outs have been exceeded. Furthermore, when repeated commands fail to be acknowledged, it is the responsibility of the requesting entity to seek redundant services and/or clear existing or pending connections. The specification purposely avoids specifying any value for the retransmission timers. These values are typically network dependent. The retransmission timers should normally estimate the timer by measuring the time spent between the sending of a command and the return of a response. One possibility is to use the algorithm implemented in TCP-IP, which uses two variables: * the average acknowledgement delay, AAD, estimated through an exponentially smoothed average of the observed delays, * the average deviation, ADEV, estimated through an exponentially smoothed average of the absolute value of the difference between the observed delay and the current average The retransmission timer, in TCP, is set to the sum of the average delay plus N times the average deviation. In MGCP, the maximum value of the timer should however be bounded, in order to guarantee that no repeated packet will be received by the gateways after LONG-TIMER seconds. A suggested maximum value is 4 seconds.
After any retransmission, the MGCP entity should do the following:
* It should double the estimated value of the average delay, AAD
* It should compute a random value, uniformly distributed between
0.5 AAD and AAD
* It should set the retransmission timer to the sum of that random
value and N times the average deviation.
This procedure has two effects. Because it includes an exponentially
increasing component, it will automatically slow down the stream of
messages in case of congestion. Because it includes a random
component, it will break the potential synchronization between
notifications triggered by the same external event.
3.6.4. Piggy backing
There are cases when a Call Agent will want to send several messages
at the same time to the same gateways. When several MGCP messages
have to be sent in the same UDP packets, they should be separated by
a line of text that contain a single dot, as in for example:
200 2005 OK
DLCX 1244 card23/21@trgw-7.example.net MGCP 1.0
C: A3C47F21456789F0
I: FDE234C8
The piggy-backed messages should be processed exactly has if they had
been received in several simultaneous messages.
3.6.5. Provisional responses
Executing some transactions may require a long time. Long execution
times may interact with the timer based retransmission procedure.
This may result either in an inordinate number of retransmissions, or
in timer values that become too long to be efficient.
Gateways that can predict that a transaction will require a long
execution time may send a provisional response, with response code
100. They should send this response if they receive a repetition of
a transaction that is still being executed.
MGCP entities that receive a provisional response shall switch to a
longer repetition timer for that transaction.
4. States, failover and race conditions.
In order to implement proper call signalling, the Call Agent must keep track of the state of the endpoint, and the gateway must make sure that events are properly notified to the call agent. Special conditions exist when the gateway or the call agent are restarted: the gateway must be redirected to a new call agent during "failover" procedures, the call agent must take special action when the gateway is taken offline, or restarted.4.1. Basic Asumptions
The support of "failover" is based on the following assumptions: * Call Agents are identified by their domain name, not their network addresses, and several addresses can be associated with a domain name. * An endpoint has one NotifiedEntity associated with it any given point in time. * The NotifiedEntity is the last value of the "NotifiedEntity" parameter received for this endpoint (including wild-carded end- point-names). If no explicit "NotifiedEntity" parameter has been received, the "NotifiedEntity" defaults to the provisioned NotifiedEntity value, or if no value was provisioned to the source address of the last command received for the endpoint, * Responses to commands are always sent to the source address of the command, regardless of the NotifiedEntity. * When the "notified entity" refers to a domain name that resolves to multiple IP- address, endpoints are capable of switching between different interfaces on the same logical call agent, however they cannot switch to other (backup) call agent(s) on their own. A backup call agent can however instruct them to switch, either directly or indirectly. * If an entire call agent becomes unavailable, the endpoints managed by that call agent will eventually become "disconnected". The only way for these endpoints to become connected again is either for the failed call agent to become available, or for a backup call agent to contact the affected endpoints. * When a backup call agent has taken over control of a group of endpoints, it is assumed that the failed call agent will communicate and synchronize with the backup call agent in order to
transfer control of the affected endpoints back to the original
call agent (if that's even desired - maybe the failed call agent
should simply become the backup call agent now).
We should note that handover conflict resolution between separate
CA's is not in place - we are relying strictly on the CA's knowing
what they are doing and communicating with each other (although
AuditEndpoint can be used to learn about the current NotifiedEntity).
4.2. Security, Retransmission, and Detection of Lost Associations:
The media gateway control protocol is organized as a set of
transactions, each of which is composed of a command and a response,
commonly referred to as an acknowledgement. The MGCP messages, being
carried over UDP, may be subject to losses. In the absence of a
timely response, commands are repeated. MGCP entities are expected to
keep in memory a list of the responses that they sent to recent
transactions, i.e. a list of all the responses they sent over the
last LONG-TIMER seconds, and a list of the transactions that are
currently being executed.
The transaction identifiers of incoming commands are compared to the
transaction identifiers of the recent responses. If a match is found,
the MGCP entity does not execute the transaction, but simply repeats
the response. The remaining commands will be compared to the list of
current transaction. If a match is found, the MGCP entity does not
execute the transaction, which is simply ignored - a response will be
provided when the execution of the command is complete.
The repetition mechanism is used to guard against four types of
possible errors:
* transmission errors, when for example a packet is lost due to
noise on a line or congestion in a queue,
* component failure, when for example an interface to a call agent
becomes unavailable,
* call agent failure, when for example an entire call agent becomes
unavailable,
* failover, when a new call agent is "taking over" transparently.
The elements should be able to derive from the past history an
estimate of the packet loss rate due to transmission errors. In a
properly configured system, this loss rate should be kept very low,
typically less than 1%. If a call agent or a gateway has to repeat a
message more than a few times, it is very legitimate to assume that
something else than a transmission error is occurring. For example,
given a loss rate of 1%, the probability that 5 consecutive
transmission attempts fail is 1 in 100 billion, an event that should
occur less than once every 10 days for a call agent that processes
1,000 transactions per second. (Indeed, the number of repetition that
is considered excessive should be a function of the prevailing packet
loss rate.) We should note that the "suspicion threshold", which we
will call "Max1", is normally lower than the "disconnection
threshold", which should be set to a larger value.
Command issued: N=0
|
transmission: N++
| +------------ retransmission: N++ -----------+
| | |
| | transmission |
| | +---to new address -+<--------------------|--+
| | | N=0 | | |
V V V | | |
+-----------+ | | |
| awaiting |- new call agent ->+ +------------+ | |
| response |--- timer elapsed --->| N > Max1 ? |-(no)+ |
+-----------+ <----------+ +------------+ ^ |
| | | | | |
| +- wrong key? -+ (yes) | |
| | | |
response received (if N=Max1, | |
| or N=Max2 | |
| check DNS) | |
v | | |
(end) +---------------+ | |
|more addresses?|(yes)|--+
+---------------+ |
| |
(no) |
| |
+------------+ |
| N > Max2 ? |(no)-+
+------------+
|
(yes)
|
v
(disconnected)
A classic retransmission algorithm would simply count the number of
successive repetitions, and conclude that the association is broken
after re-transmitting the packet an excessive number of times
(typically between 7 and 11 times.) In order to account for the
possibility of an undetected or in-progress "failover", we modify the
classic algorithm as follows:
* We request that the gateway always checks for the presence of a
new call agent. It can be noticed either by
- receiving a valid multicast message announcing a failover, or
- receiving a command where the NotifiedEntity points to the new
call agent, or
- receiving a redirection response pointing to a new Call Agent.
If a new call agent is detected, the gateway starts transmitting
outstanding commands to that new agent. Responses to commands are
still transmitted to the source address of the command.
* we request that if the number of repetitions for this Call Agent
is larger than "Max1", that the gateway actively queries the name
server in order to detect the possible change of the call agent
interfaces.
* The gateway may have learned several IP addresses for the call
agent. If the number of repetitions is larger than "Max1" and
lower than "Max2", and there are more interfaces that have not
been tried, then the gateway should direct the retransmissions to
alternate addresses.
* If there are no more interfaces to try, and the number of
repetitions is Max2, then the gateway contacts the DNS one more
time to see if any other interface should have become available.
If not, the gateway is now disconnected.
The procedure will maximize the chances of detecting an ongoing
failover. It poses indeed two very specific problems, the potentially
long delays of a timer based procedure and the risk of confusion
caused by the use of cryptographic protections.
In order to automatically adapt to network load, MGCP specifies
exponentially increasing timers. If the initial timer is set to 200
milliseconds, the loss of a fifth retransmission will be detected
after about 6 seconds. This is probably an acceptable waiting delay
to detect a failover. The repetitions should continue after that
delay not only in order to perhaps overcome a transient connectivity
problem, but also in order to allow some more time for the execution
of a failover - waiting a total delay of 30 seconds is probably
acceptable.
It is however important that the maximum delay of retransmissions be bounded. Prior to any retransmission, it is checked that the time elapsed since the sending of the initial datagram is no greater than T- MAX. If more than T-MAX time has elapsed, the endpoint becomes disconnected. The value T-MAX is related to the LONG-TIMER value: the LONG-TIMER value is obtained by adding to T-MAX the maximum propagation delay in the network. Another potential cause of connection failure would be the reception of a "wrong key" message, sent by a call agent that could not authenticate the command, presumably because it had lost the security parameters of the association. Such messages are actually not authorized in IPSEC, and they should in fact not be taken at face value: an attacker could easily forge "wrong key" messages in order to precipitate the loss of a control connection. The current algorithm ignores these messages, which translates into a strict reliance on timers. The algorithm could in fact be improved, maybe by executing a check with the key server of the call agent after "Max1" repetitions.4.3. Race conditions
MGCP deals with race conditions through the notion of a "quarantine list" and through explicit detection of desynchronization. MGCP does not assume that the transport mechanism will maintain the order of command and responses. This may cause race conditions, that may be obviated through a proper behavior of the call agent. (Note that some race conditions are inherent to distributed systems; they would still occur, even if the commands were transmitted in strict order.) In some cases, many gateways may decide to restart operation at the same time. This may occur, for example, if an area loses power or transmission capability during an earthquake or an ice storm. When power and transmission are reestablished, many gateways may decide to send "RestartInProgress" commands simultaneously, leading to very unstable operation.4.3.1. Quarantine list
MGCP controlled gateways will receive "notification requests" that ask them to watch for a list of "events." The protocol elements that determine the handling of these events are the "Requested Events" list, the "Digit Map" and the "Detect Events" list.
When the endpoint is initialized, the requested events list and the digit map are empty. After reception of a command, the gateway starts observing the endpoint for occurrences of the events mentioned in the list. The events are examined as they occur. The action that follows is determined by the "action" parameter associated to the event in the list of requested events, and also by the digit map. The events that are defined as "accumulate" or "treat according to digit map" are accumulated in a list of events, the events that are marked as "treated according to the digit map" will additionally be accumulated in the dialed string. This will go on until one event is encountered that triggers a Notification to the "notified entity." The gateway, at this point, will transmit the notification command and will place the endpoint in a "notification" state. As long as the endpoint is in this notification state, the events that are to be detected on the endpoint are stored in a "quarantine" buffer for later processing. The events are, in a sense, "quarantined." All events that are specified by the union of the RequestedEvents parameter and the most recently received DetectEvent parameter or, in the absence of the latter, all events that are referred to in the RequestedEvents, should be detected and quarantined, regardless of the action associated to the event. The endpoint exits the "notification state" when the acknowledgement of the Notify command is received. The Notify command may be retransmitted in the "notification state", as specified in section 3.5. When the endpoint exits the "notification state" it resets the list of observed events and the "current dial string" of the endpoint to a null value. Following that point, the behavior of the gateway depends on the value of The QuarantineHandling parameter in the notification request. If the Call Agent specified that it expected at most one notification in response to the notification request command, then the gateway should simply keep on accumulating events in the quarantine list until it receives the next notification request command. If the gateway is authorized to send multiple successive Notify commands, it will proceed as follows. When the gateway exits the "notification state", it resets the list of observed events and the "current dial string" of the endpoint to a null value and starts processing the list of quarantined events, using the already 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 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 RFC 2401, using either the IP Authentication Header, defined in RFC 2402, or the IP Encapsulating Security Payload, defined in RFC 2406. 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 RFC 1890, 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.
(page 124 continued on part 5)
