the default Call Agent port number (2727) is assumed.
* NotifiedEntity is a parameter sent by the Call Agent to the gateway
to set the "notified entity" for the endpoint.
* The "notified entity" for an endpoint is the last value of the
NotifiedEntity parameter received for this endpoint. If no
explicit NotifiedEntity parameter has ever been received, the
"notified entity" defaults to a provisioned value. If no value was
provisioned or an empty NotifiedEntity parameter was provided (both
strongly discouraged) thereby making the "notified entity" empty,
the "notified entity" is set to the source address of the last
non-audit command for the endpoint. Thus auditing will not change
the "notified entity".
* Responses to commands are sent to the source address of the
command, regardless of the current "notified entity". When a
Notify message needs to be piggybacked with the response, the
datagram is still sent to the source address of the new command
received, regardless of the current "notified entity".
The ability for the "notified entity" to resolve to multiple network
addresses, allows a "notified entity" to represent a Call Agent with
multiple physical interfaces on it and/or a logical Call Agent made
up of multiple physical systems. The order of network addresses when
a DNS name resolves to multiple addresses is non-deterministic so
Call Agent fail-over schemes MUST NOT depend on any order (e.g., a
gateway MUST be able to send a "Notify" to any of the resolved
network addresses). On the other hand, the system is likely to be
most efficient if the gateway sends commands to the interface with
which it already has a current association. It is RECOMMENDED that
gateways use the following algorithm to achieve that goal:
* If the "notified entity" resolves to multiple network addresses,
and the source address of the request is one of those addresses,
that network address is the preferred destination address for
commands.
* If on the other hand, the source address of the request is not one
of the resolved addresses, the gateway must choose one of the
resolved addresses for commands.
* If the gateway fails to contact the network address chosen, it MUST
try the alternatives in the resolved list as described in Section
4.3.
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 with a new "notified entity".
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.
Alternatively, the failed Call Agent could simply become the backup
Call Agent.
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 "notified
entity"). If this is not the case, unexpected behavior may occur.
Note that as mentioned earlier, the default "notified entity" is
provisioned and may include both domain name and port. For small
gateways, provisioning may be done on a per endpoint basis. For much
larger gateways, a single provisioning element may be provided for
multiple endpoints or even for the entire gateway itself. In either
case, once the gateway powers up, each endpoint MUST have its own
"notified entity", so provisioned values for an aggregation of
endpoints MUST be copied to the "notified entity" for each endpoint
in the aggregation before operation proceeds. Where possible, the
RestartInProgress command on restart SHOULD be sent to the
provisioned "notified entity" based on an aggregation that allows the
"all of" wild-card to be used. This will reduce the number of
RestartInProgress messages.
Another way of viewing the use of "notified entity" is in terms of
associations between gateways and Call Agents. The "notified entity"
is a means to set up that association, and governs where the gateway
will send commands to. Commands received by the gateway however may
come from any source. The association is initially provisioned with
a provisioned "notified entity", so that on power up
RestartInProgress and persistent events that occur prior to the first
NotificationRequest from Call Agents will be sent to the provisioned
Call Agent. Once a Call Agent makes a request, however it may
include the NotifiedEntity parameter and set up a new association.
Since the "notified entity" persists across calls, the association
remains intact until a new "notified entity" is provided.
4.2 Communicating with Gateways
Endpoint names in gateways include a local name indicating the
specific endpoint and a domain name indicating the host/gateway where
the endpoint resides. Gateways may have several interfaces for
redundancy.
In gateways that have routing capability, the domain name may resolve
to a single network address with internal routing to that address
from any of the gateway's interfaces. In others, the domain name may
resolve to multiple network addresses, one for each interface. In
the latter case, if a Call Agent fails to contact the gateway on one
of the addresses, it MUST try the alternates.
4.3 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 retransmitted. MGCP entities MUST 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 T-HIST seconds, and a list of the transactions that have not yet
finished executing.
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. If a match to a previously responded to
transaction is not found, the transaction identifier of the incoming
command is compared to the list of transactions that have not yet
finished executing. If a match is found, the MGCP entity does not
execute the transaction again, but SHOULD simply send a provisional
response - a final response will be provided when the execution of
the command is complete (see Section 3.5.6 for further detail).
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 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 other 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
retransmissions 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 we will call "Max2". Max2 MUST be
set to a larger value than Max1.
The MGCP retransmission algorithm is illustrated in the Figure below
and explained further in the following:
Command issued: N=0, T=0
|
| +------------ retransmission: N++ <--------------+
| | |
| | if T <= T-Max then |
| | transmission |
| | +-- to new address, <-+<----------------------|--+
| | | N=0 | | |
V V V | | |
+-----------+ | | |
+-->| awaiting |- new Call Agent ->+ +------------+ | |
| | response |--- timer elapsed --->| T > T-Max ?| | |
| +-----------+ +------------+ ^ ^
| | | | | |
| v +-----(yes)-----+ (no) | |
| (response | | | |
| received) | +------------+ | |
| | | | N >= Max1 ?|-(no)>+ |
| v | +------------+ ^ ^
| +--------+ | | | |
+<(no)-| final ?| | (yes) | |
^ +--------+ | | | |
| | | (if first address & N=Max1, | |
| v | or last address & N=Max2 | |
| (yes) | check DNS) | |
| | | | | |
| v V +---------------+ | |
| (end) | |more addresses?|(yes)-|->+
| | +---------------+ |
| | | ^
| | (no) |
| | | |
| | +------------+ |
| | | N >= Max2 ?|(no)--+
| | +------------+
| | |
| | (yes)
| | |
| | +----------------+
| +----------->| T >= 2*T-HIST ?|
| +----------------+
| | |
| (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 require that the gateway always checks for the presence of a new
Call Agent. It can be noticed either by:
- 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 MUST start
retransmitting outstanding commands for the endpoint(s) redirected
to that new Call Agent. Responses to new or old commands are still
transmitted to the source address of the command.
* 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, then retransmissions MUST
cease. If more than 2*T-HIST has elapsed, then the endpoint
becomes disconnected.
* If the number of repetitions for this Call Agent is equal to
"Max1", and its domain name was not resolved recently (e.g., within
the last 5 seconds or otherwise provisioned), and it is not in the
process of being resolved, then the gateway MAY actively query the
domain name server in order to detect the possible change of the
Call Agent interfaces. Note that the first repetition is the
second transmission.
* The gateway may have learned several IP addresses for the call
agent. If the number of repetitions for this IP address is greater
than or equal to "Max1" and lower than "Max2", and there are more
addresses that have not been tried, then the gateway MUST direct
the retransmissions to alternate addresses. Also, receipt of
explicit network notifications such as, e.g., ICMP network, host,
protocol, or port unreachable SHOULD lead the gateway to try
alternate addresses (with due consideration to possible security
issues).
* If there are no more interfaces to try, and the number of
repetitions for this address is Max2, then the gateway SHOULD
contact the DNS one more time to see if any other interfaces have
become available, unless the domain name was resolved recently
(e.g., within the last 5 seconds or otherwise provisioned), or it
is already in the process of being resolved. If there still are no
more interfaces to try, the gateway is then disconnected and MUST
initiate the "disconnected" procedure (see Section 4.4.7).
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
(T) elapsed since the sending of the initial datagram is no greater
than T-MAX. If more than T-MAX time has elapsed, retransmissions
MUST cease. If more than 2*T-HIST time has elapsed, the endpoint
becomes disconnected. The value T-MAX is related to the T-HIST
value: the T-HIST value MUST be greater than or equal to T-MAX plus
the maximum propagation delay in the network.
The default value for T-MAX is 20 seconds. Thus, if the assumed
maximum propagation delay is 10 seconds, then responses to old
transactions would have to be kept for a period of at least 30
seconds. The importance of having the sender and receiver agree on
these values cannot be overstated.
The default value for Max1 is 5 retransmissions and the default value
for Max2 is 7 retransmissions. Both of these values may be altered
by the provisioning process.
The provisioning process MUST be able to disable one or both of the
Max1 and Max2 DNS queries.
4.4 Race Conditions
MGCP deals with race conditions through the notion of a "quarantine
list" and through explicit detection of desynchronization, e.g., for
mismatched hook state due to glare for an endpoint.
MGCP does not assume that the transport mechanism will maintain the
order of commands 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.4.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", the "Quarantine Handling", and the "Detect
Events" list.
When the endpoint is initialized, the requested events list only
consists of persistent events for the endpoint, and the digit map is
assumed empty. At this point, the endpoint MAY use an implicit
NotificationRequest with the reserved RequestIdentifier zero ("0") to
detect and report a persistent event, e.g., off-hook. A pre-existing
off-hook condition MUST here result in the off-hook event being
generated as well.
The endpoint awaits the reception of a NotificationRequest command,
after which the gateway starts observing the endpoint for occurrences
of the events mentioned in the list, including persistent events.
The events are examined as they occur. The action that follows is
determined by the "action" parameter associated with the event in the
list of requested events, and also by the digit map. The events that
are defined as "accumulate" or "accumulate according to digit map"
are accumulated in a list of events, the events that are marked as
"accumulate according to the digit map" will additionally be
accumulated in the "current dial string". This will go on until one
event is encountered that triggers a notification which will be sent
to the current "notified entity".
The gateway, at this point, will transmit the Notify 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 (FIFO)
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 DetectEvents parameter or,
in the absence of the latter, all events that are referred to in the
RequestedEvents, SHALL be detected and quarantined, regardless of the
action associated with the event. Persistent events are here viewed
as implicitly included in RequestedEvents. If the quarantine buffer
reaches the capacity of the endpoint, a Quarantine Buffer Overflow
event (see Appendix B) SHOULD be generated (when this event is
supported, the endpoint MUST ensure it has capacity to include the
event in the quarantine buffer). Excess events will now be
discarded.
The endpoint exits the "notification state" when the response
(whether success or failure) to the Notify command is received. The
Notify command may be retransmitted in the "notification state", as
specified in Section 3.5 and 4. If the endpoint is or becomes
disconnected (see Section 4.3) during this, a response to the Notify
command will never be received. The Notify command is then lost and
hence no longer considered pending, yet the endpoint is still in the
"notification state". Should that occur, completion of the
disconnected procedure specified in Section 4.4.7 SHALL then lead the
endpoint to exit the "notification state".
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 triggering
NotificationRequest command:
If the Call Agent had specified, that it expected at most one
notification in response to the notification request command, then
the gateway SHALL simply keep on accumulating events in the
quarantine buffer until it receives the next notification request
command.
If, however, 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 triggers 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 buffer,
* or it can attempt to empty the quarantine buffer and transmit a
single Notify command reporting several sets of events (in a single
list of observed events) and possibly several dial strings. The
"current 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 buffer.
If the gateway transmits a Notify command, the endpoint will reenter
and remain in the "notification state" until the acknowledgement is
received (as described above). If the gateway does not find a
quarantined event that triggers a Notify command, it places the
endpoint 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 endpoint, including the case where the endpoint is
disconnected. Activating an embedded Notification Request is here
viewed as receiving a new Notification Request as well, except that
the current list of ObservedEvents remains unmodified rather than
being processed again. When a new notification request is received
in the notification state, the gateway SHALL ensure that the pending
Notify is received by the Call Agent prior to a new Notify (note that
a Notify that was lost due to being disconnected, is no longer
considered pending). It does so by using the "piggybacking"
functionality of the protocol. The messages will then be sent in a
single packet to the current "notified entity". The steps involved
are the following:
a) the gateway sends a response to the new notification request.
b) the endpoint is then taken out of the "notification state" without
waiting for the acknowledgement of the pending Notify command.
c) a copy of the unacknowledged Notify command is kept until an
acknowledgement is received. If a timer elapses, the Notify will
be retransmitted.
d) If the gateway has to transmit a new Notify before the previous
Notify(s) is acknowledged, it constructs a packet that piggybacks
a repetition of the old Notify(s) and the new Notify (ordered by
age with the oldest first). This datagram will be sent to the
current "notified entity".
f) Gateways that cannot piggyback several messages in the same
datagram and hence guarantee in-order delivery of two (or more)
Notify's SHALL leave the endpoint in the "notification" state as
long as the last Notify is not acknowledged.
The procedure is illustrated by the following diagram:
+-------------------+
| Processing Events |<--------------------------------------+
+-------------------+ |
| |
Need to send NTFY |
| |
v |
+-------------------+ |
| Outstanding NTFY |---- No -------+ |
| | | |
+-------------------+ v |
| +-----------+ |
Yes | Send NTFY | |
| +-----------+ |
v | |
+--------------------+ v |
| Piggyback new NTFY | +--------------------+ |
| w. old outstanding |---->| Notification State | |
| NTFY(s) | +--------------------+ |
+--------------------+ | | |
new RQNT NTFY response |
received received |
| | |
| v |
| +-------------+ |
| | Step mode ? |- No ->+
| +-------------+ ^
| | |
| Yes |
| | |
| v |
| +---------------+ |
| | Wait for RQNT | |
| +---------------+ |
| | |
| RQNT received |
| | |
| v |
| +---------------+ |
+------>| Apply RQNT and|----->+
| send response |
+---------------+
Gateways may also attempt to deliver the pending Notify prior to a
successful response to the new NotificationRequest by using the
"piggybacking" functionality of the protocol. This was in fact
required behavior in RFC2705, however there are several
complications in doing this, and the benefits are questionable. In
particular, the RFC2705 mechanism did not guarantee in-order
delivery of Notify's and responses to NotificationRequests in
general, and hence Call Agents had to handle out-of-order delivery of
these messages anyway. The change to optional status is thus
backwards compatible while greatly reducing complexity.
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 current dial string is reset
to a null value. Furthermore, when the Notification Request was
received in the "notification state", the list of observed events is
reset to a null value. The subsequent behavior is conditioned by the
value of the QuarantineHandling parameter. The parameter may specify
that quarantined events (and observed events which in this case is
now an empty list), should be discarded, in which case they will be.
If the parameter specifies that the quarantined (and observed) events
are to be processed, the gateway will start processing the list of
quarantined (and observed) events, using the newly received list of
requested events and digit map (if provided). 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 request,
but has not yet detected a notification-triggering events, i.e., the
endpoint is not in the "notification state". The handling of not-
yet-notified events is determined, as with the quarantined events, by
the quarantine handling parameter:
* If the quarantine-handling parameter specifies that quarantined
events shall be ignored, the observed events 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 controlling endpoints in lockstep mode SHOULD provide the
response to a successful Notify message and the new
NotificationRequest in the same datagram using the piggybacking
mechanism.
4.4.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 MUST check the condition of
the endpoint before acknowledging a NotificationRequest. It MUST
return an error:
1. If the gateway is requested to notify an "off-hook" transition
while the phone is already off-hook, (error code 401 - phone off
hook)
2. If the gateway is requested to notify an "on-hook" or "flash hook"
condition while the phone is already on-hook (error code 402 -
phone on hook).
Additionally, individual signal definitions can specify that a signal
will only operate under certain conditions, e.g., ringing may only be
possible if the phone is already off-hook. If such prerequisites
exist for a given signal, the gateway MUST return the error specified
in the signal definition if the prerequisite is not met.
It should be noted, that the condition check is performed at the time
the notification request is received, whereas 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
RequestedEvents 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 MUST simply
continue as if the command had never been received. As all other
transactions, the NotificationRequest MUST operate as an atomic
transaction, thus any changes initiated as a result of the command
MUST 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 thereby enabling the Call Agent to
determine if the Notify command was generated before or after the
gateway received the new NotificationRequest. This is especially
important to avoid deadlocks in "step" mode.
4.4.3 Transactional Semantics
As the potential transaction completion times increase, e.g., due to
external resource reservations, a careful definition of the
transactional semantics becomes increasingly important. In
particular the issue of race conditions, e.g., as it relates to
hook-state, must be defined carefully.
An important point to consider is, that the status of a pre-condition
(e.g., hook-state) may in fact change between the time a transaction
starts and the time it either completes successfully (transaction
commit) or fails. In general, we can say that the successful
execution of a transaction depends on one or more pre-conditions
where the status of one or more of the pre-conditions may change
dynamically between the transaction start and transaction commit.
The simplest semantics for this is simply to require that all pre-
conditions be met from the time the transaction is initiated until
the transaction commits. If any pre-condition is not met before the
completion of the transaction, the transaction will also fail.
As an example, consider a transaction that includes a request for the
"off-hook" event. When the transaction is initiated the phone is
"on-hook" and this pre-condition is therefore met. If the hook-state
changes to "off-hook" before the transaction completes, the pre-
condition is no longer met, and the transaction therefore immediately
fails.
Finally, we need to consider the point in time when a new transaction
takes effect and endpoint processing according to an old transaction
stops. For example, assume that transaction T1 has been executed
successfully and event processing is currently being done according
to transaction T1. Now we receive a new transaction T2 specifying
new event processing (for example a CreateConnection with an
encapsulated NotificationRequest). Since we don't know whether T2
will complete successfully or not, we cannot start processing events
according to T2 until the outcome of T2 is known. While we could
suspend all event processing until the outcome of T2 is known, this
would make for a less responsive system and hence SHOULD NOT be done.
Instead, when a new transaction Ty is received and Ty modifies
processing according to an old transaction Tx, processing according
to Tx SHOULD remain active for as long as possible, until a
successful outcome of Ty is known to occur. If Ty fails, then
processing according to Tx will of course continue as usual. Any
changes incurred by Ty logically takes effect when Ty commits. Thus,
if the endpoint was in the notification state when Ty commits, and Ty
contained a NotificationRequest, the endpoint will be taken out of
the notification state when Ty commits. Note that this is
independent of whether the endpoint was in the notification state
when Ty was initiated. For example, a Notify could be generated due
to processing according to Tx between the start and commit of Ty. If
the commit of Ty leads to the endpoint entering the notification
state, a new NotificationRequest (Tz) is needed to exit the
notification state. This follows from the fact that transaction
execution respects causal order.
Another related issue is the use of wildcards, especially the "all
of" wildcard, which may match more than one endpoint. When a command
is requested, and the endpoint identifier matches more than one
endpoint, transactional semantics still apply. Thus, the command
MUST either succeed for all the endpoints, or it MUST fail for all of
them. A single response is consequently always issued.
4.4.4 Ordering of Commands, and Treatment of Misorder
MGCP does not mandate that the underlying transport protocol
guarantees in-order delivery of commands to a gateway or an endpoint.
This property tends to maximize the timeliness of actions, but it has
a few drawbacks. For example:
* Notify commands may be delayed and arrive at 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 and executed after the new one.
Call Agents that want to guarantee consistent operation of the
endpoints 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 will fail, and an error code MUST be returned (error code
515 - incorrect connection-id, is RECOMMENDED).
4) On a given endpoint, there should normally be only one outstanding
NotificationRequest command at any time. The RequestId parameter
MUST 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 SHOULD NOT 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 requirements associated with both
CreateConnection and NotificationRequest at the same time.
7) AuditEndpoint and AuditConnection are not subject to any
sequencing requirements.
8) RestartInProgress MUST always be the first command sent by an
endpoint as defined by the restart procedure. Any other command
or non-restart response (see Section 4.4.6), except for responses
to auditing, MUST be delivered after this RestartInProgress
command (piggybacking allowed).
9) When multiple messages are piggybacked in a single packet, the
messages are always processed in order.
10) On a given endpoint, there should normally be only one
outstanding EndpointConfiguration command at any time.
Gateways MUST NOT make any assumptions as to whether Call Agents
follow these rules or not. Consequently gateways MUST always respond
to commands, regardless of whether they adhere to the above rules or
not. To ensure consistent operation, gateways SHOULD behave as
specified below when one or more of the above rules are not followed:
* Where a single outstanding command is expected (ModifyConnection,
NotificationRequest, and EndpointConfiguration), but the same
command is received in a new transaction before the old finishes
executing, the gateway SHOULD fail the previous command. This
includes the case where one or more of the commands were
encapsulated. The use of error code 407 (transaction aborted) is
RECOMMENDED.
* If a ModifyConnection command is received for a pending
CreateConnection command, the ModifyConnection command SHOULD
simply be rejected. The use of error code 400 (transient error) is
RECOMMENDED. Note that this situation constitutes a Call Agent
programming error.
* If a DeleteConnection command is received for a pending
CreateConnection or ModifyConnection command, the pending command
MUST be aborted. The use of error code 407 (transaction aborted)
is RECOMMENDED.
Note, that where reception of a new command leads to aborting an old
command, the old command SHOULD be aborted regardless of whether the
new command succeeds or not. For example, if a ModifyConnection
command is aborted by a DeleteConnection command which itself fails
due to an encapsulated NotificationRequest, the ModifyConnection
command is still aborted.
4.4.5 Endpoint Service States
As described earlier, endpoints configured for operation may be
either in-service or out-of-service. The actual service-state of the
endpoint is reflected by the combination of the RestartMethod and
RestartDelay parameters, which are sent with RestartInProgress
commands (Section 2.3.12) and furthermore may be audited in
AuditEndpoint commands (Section 2.3.10).
The service-state of an endpoint affects how it processes a command.
An endpoint in-service MUST process any command received, whereas an
endpoint that is out-of-service MUST reject non-auditing commands,
but SHOULD process auditing commands if possible. For backwards
compatibility, auditing commands for an out-of-service endpoint may
alternatively be rejected as well. Any command rejected due to an
endpoint being out-of-service SHOULD generate error code 501
(endpoint not ready/out-of-service).
Note that (per Section 2.1.2), unless otherwise specified for a
command, endpoint names containing the "any of" wildcard only refer
to endpoints in-service, whereas endpoint names containing the "all
of" wildcard refer to all endpoints, regardless of service state.
The above relationships are illustrated in the table below which
shows the current service-states and gateway processing of commands
as a function of the RestartInProgress command sent and the response
(if any) received to it. The last column also lists (in parentheses)
the RestartMethod to be returned if audited:
------------------------------------------------------------------
| Restart- | Restart- | 2xx | Service- | Response to |
| Method | Delay | received ?| State | new command |
|------------------------------------------------------------------|
| graceful | zero | Yes/No | In | non-audit: 2xx |
| | | | | audit: 2xx |
| | | | | (graceful) |
|-----------+----------+-----------+----------+--------------------|
| graceful | non-zero | Yes/No | In* | non-audit: 2xx |
| | | | | audit: 2xx |
| | | | | (graceful) |
|-----------+----------+-----------+----------+--------------------|
| forced | N/A | Yes/No | Out | non-audit: 501 |
| | | | | audit: 2xx |
| | | | | (forced) |
|-----------+----------+-----------+----------+--------------------|
| restart | zero | No | In | non-audit: 2xx,405*|
| | | | | audit: 2xx |
| | | | | (restart) |
|-----------+----------+-----------+----------+--------------------|
| restart | zero | Yes | In | non-audit: 2xx |
| | | | | audit: 2xx |
| | | | | (restart) |
|-----------+----------+-----------+----------+--------------------|
| restart | non-zero | No | Out* | non-audit: 501* |
| | | | | audit: 2xx |
| | | | | (restart) |
|-----------+----------+-----------+----------+--------------------|
| restart | non-zero | Yes | Out* | non-audit: 501* |
| | | | | audit: 2xx |
| | | | | (restart) |
|-----------+----------+-----------+----------+--------------------|
| discon- | zero/ | No | In | non-audit: 2xx, |
| nected | non-zero | | | audit: 2xx |
| | | | | (disconnected)|
|-----------+----------+-----------+----------+--------------------|
| discon- | zero/ | Yes | In | non-audit: 2xx |
| nected | non-zero | | | audit: 2xx |
| | | | | (restart) |
|-----------+----------+-----------+----------+--------------------|
| cancel- | N/A | Yes/No | In | non-audit: 2xx |
| graceful | | | | audit: 2xx |
| | | | | (restart) |
------------------------------------------------------------------
Notes (*):
* The three service-states marked with "*" will change after the
expiration of the RestartDelay at which time an updated
RestartInProgress command SHOULD be sent.
* If the endpoint returns 2xx when the restart procedure has not yet
completed, then in-order delivery MUST still be satisfied, i.e.,
piggy-backing is to be used. If instead, the command is not
processed, 405 SHOULD be returned.
* Following a "restart" RestartInProgress with a non-zero
RestartDelay, error code 501 is only returned until the endpoint
goes in-service, i.e., until the expiration of the RestartDelay.
4.4.6 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 REQUIRED:
1) When a gateway is powered on, it MUST 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 MUST 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 MUST initiate the restart
procedure.
The restart procedure simply requires the endpoint to guarantee that
the first
* non-audit command, or
* non-restart response (i.e., error codes other than 405, 501, and
520) to a non-audit command
that the Call Agent sees from this endpoint is a "restart"
RestartInProgress command. The endpoint is free to take full
advantage of piggybacking to achieve this. Endpoints that are
considered in-service will have a RestartMethod of "restart", whereas
endpoints considered out-of-service will have a RestartMethod of
"forced" (also see Section 4.4.5). Commands rejected due to an
endpoint not yet having completed the restart procedure SHOULD use
error code 405 (endpoint "restarting").
The restart procedure is complete once a success response has been
received. If an error response is received, the subsequent behavior
depends on the error code in question:
* If the error code indicates a transient error (4xx), then the
restart procedure MUST be initiated again (as a new transaction).
* If the error code is 521, then the endpoint is redirected, and the
restart procedure MUST be initiated again (as a new transaction).
The 521 response MUST have included a NotifiedEntity which then is
the "notified entity" towards which the restart is initiated. If
it did not include a NotifiedEntity, the response is treated as any
other permanent error (see below).
* If the error is any other permanent error (5xx), and the endpoint
is not able to rectify the error, then the endpoint no longer
initiates the restart procedure on its own (until
rebooted/restarted) unless otherwise specified. If a command is
received for the endpoint, the endpoint MUST initiate the restart
procedure again.
Note that if the RestartInProgress is piggybacked with the response
(R) to a command received while restarting, then retransmission of
the RestartInProgress does not require piggybacking of the response
R. However, while the endpoint is restarting, a resend of the
response R does require the RestartInProgress to be piggybacked to
ensure in-order delivery of the two.
Should the gateway enter the "disconnected" state while carrying out
the restart procedure, the disconnected procedure specified in
Section 4.4.7 MUST be carried out, except that a "restart" rather
than "disconnected" message is sent during the procedure.
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. Note that during startup, it is possible for
endpoints to start out as being out-of-service, and then become in-
service as part of the gateway initialization procedure. A gateway
may thus choose to send first a "forced" RestartInProgress for all
its endpoints, and subsequently a "restart" RestartInProgress for the
endpoints that come in-service. Alternatively, the gateway may
simply send "restart" RestartInProgress for only those endpoints that
are in-service, and "forced" RestartInProgress for the specific
endpoints that are out-of-service. Wild-carding MUST still be used
to minimize the number of messages sent though.
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 endpoint and the Call Agent. This simple calculation
shows that the Call Agent is expected to handle 5 to 6 transactions
for each endpoint, every 30 minutes on average, or, to put it
otherwise, about one transaction per endpoint 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 thus 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.4.7 Disconnected Endpoints
In addition to the restart procedure, gateways also have a
"disconnected" procedure, which MUST be initiated when an endpoint
becomes "disconnected" as described in Section 4.3. It should here
be noted, that endpoints can only become disconnected when they
attempt to communicate with the Call Agent. The following steps MUST
be followed by an endpoint that becomes "disconnected":
1. A "disconnected" timer is initialized to a random value, uniformly
distributed between 1 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 for the endpoint 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 for the endpoint, when a
command is received for the endpoint, or when local user activity