is detected for the endpoint, the gateway initiates the
"disconnected" procedure for the endpoint - if a disconnected
procedure was already in progress for the endpoint, it is simply
replaced by the new one. Furthermore, in the case of local user
activity, a provisionable "disconnected" minimum waiting delay
(Tdmin) MUST have elapsed since the endpoint became disconnected
or the last time it ended the "disconnected" procedure in order to
limit the rate at which the procedure is performed. If Tdmin has
not passed, the endpoint simply proceeds to step 2 again, without
affecting any disconnected procedure already in progress.
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
(using a new transaction-id).
The "disconnected" procedure is similar to the restart procedure in
that it simply states that the endpoint MUST send a RestartInProgress
command to the Call Agent informing it that the endpoint was
disconnected. Furthermore, the endpoint MUST guarantee that the
first non-audit message (non-audit command or response to non-audit
command) that the Call Agent sees from this endpoint MUST inform the
Call Agent that the endpoint is disconnected (unless the endpoint
goes out-of-service). When a command (C) is received, this is
achieved by sending a piggy-backed datagram with a "disconnected"
RestartInProgress command and the response to command C to the source
address of command C as opposed to the current "notified entity".
This piggy-backed RestartInProgress is not automatically
retransmitted by the endpoint but simply relies on fate-sharing with
the piggy-backed response to guarantee the in-order delivery
requirement. The Call Agent still sends a response to the piggy-
backed RestartInProgress, however, as usual, the response may be
lost. In addition to the piggy-backed RestartInProgress command, a
new "disconnected" procedure is triggered by the command received.
This will lead to a non piggy-backed copy (i.e., same transaction) of
the "disconnected" RestartInProgress command being sent reliably to
the current "notified entity".
When the Call Agent learns that the endpoint is disconnected, the
Call Agent may then for instance decide to audit the endpoint, or
simply clear all connections for the endpoint. Note that each such
"disconnected" procedure will result in a new RestartInProgress
command, which will be subject to the normal retransmission
procedures specified in Section 4.3. At the end of the procedure,
the endpoint may thus still be "disconnected". Should the endpoint
go out-of-service while being disconnected, it SHOULD send a "forced"
RestartInProgress message as described in Section 2.3.12.
The disconnected procedure is complete once a success response has
been received. Error responses are handled similarly to the restart
procedure (Section 4.4.6). If the "disconnected" procedure is to be
initiated again following an error response, the rate-limiting timer
considerations specified above still apply.
Note, that if the RestartInProgress is piggybacked with the response
(R) to a command received while being disconnected, then
retransmission of this particular RestartInProgress does not require
piggybacking of the response R. However, while the endpoint is
disconnected, resending the response R does require the
RestartInProgress to be piggybacked with the response to ensure the
in-order delivery of the two.
If a set of disconnected endpoints have the same "notified entity",
and the set of endpoints can be named with a wildcard, the gateway
MAY replace the individual disconnected procedures with a suitably
wildcarded disconnected procedure instead. In that case, the Restart
Delay for the wildcarded "disconnected" RestartInProgress command
SHALL be the Restart Delay corresponding to the oldest disconnected
procedure replaced. Note that if only a subset of these endpoints
subsequently have their "notified entity" changed and/or are no
longer disconnected, then that wildcarded disconnected procedure can
no longer be used. The remaining individual disconnected procedures
MUST then be resumed again.
A disconnected endpoint may wish to send a command (besides
RestartInProgress) while it is disconnected. Doing so will only
succeed once the Call Agent is reachable again, which raises the
question of what to do with such a command meanwhile. At one
extreme, the endpoint could drop the command right away, however that
would not work very well when the Call Agent was in fact available,
but the endpoint had not yet completed the "disconnected" procedure
(consider for example the case where a NotificationRequest was just
received which immediately resulted in a Notify being generated). To
prevent such scenarios, disconnected endpoints SHALL NOT blindly drop
new commands to be sent for a period of T-MAX seconds after they
receive a non-audit command.
One way of satisfying this requirement is to employ a temporary
buffering of commands to be sent, however in doing so, the endpoint
MUST ensure, that it:
* does not build up a long queue of commands to be sent,
* does not swamp the Call Agent by rapidly sending too many commands
once it is connected again.
Buffering commands for T-MAX seconds and, once the endpoint is
connected again, limiting the rate at which buffered commands are
sent to one outstanding command per endpoint is considered acceptable
(see also Section 4.4.8, especially if using wildcards). If the
endpoint is not connected within T-MAX seconds, but a "disconnected"
procedure is initiated within T-MAX seconds, the endpoint MAY
piggyback the buffered command(s) with that RestartInProgress. Note,
that once a command has been sent, regardless of whether it was
buffered initially, or piggybacked earlier, retransmission of that
command MUST cease T-MAX seconds after the initial send as described
in Section 4.3.
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.
4.4.8 Load Control in General
The previous sections have described several MGCP mechanisms to deal
with congestion and overload, namely:
* the UDP retransmission strategy which adapts to network and call
agent congestion on a per endpoint basis,
* the guidelines on the ordering of commands which limit the number
of commands issued in parallel,
* the restart procedure which prevents flooding in case of a restart
avalanche, and
* the disconnected procedure which prevents flooding in case of a
large number of disconnected endpoints.
It is however still possible for a given set of endpoints, either on
the same or different gateways, to issue one or more commands at a
given point in time. Although it can be argued, that Call Agents
should be sized to handle one message per served endpoint at any
given point in time, this may not always be the case in practice.
Similarly, gateways may not be able to handle a message for all of
its endpoints at any given point in time. In general, such issues
can be dealt with through the use of a credit-based mechanism, or by
monitoring and automatically adapting to the observed behavior. We
opt for the latter approach as follows.
Conceptually, we assume that Call Agents and gateways maintain a
queue of incoming transactions to be executed. Associated with this
transaction queue is a high-water and a low-water mark. Once the
queue length reaches the high-water mark, the entity SHOULD start
issuing 101 provisional responses (transaction queued) until the
queue length drops to the low-water mark. This applies to new
transactions as well as to retransmissions. If the entity is unable
to process any new transactions at this time, it SHOULD return error
code 409 (processing overload).
Furthermore, gateways SHOULD adjust the sending rate of new commands
to a given Call Agent by monitoring the observed response times from
that Call Agent to a *set* of endpoints. If the observed smoothed
average response time suddenly rises significantly over some
threshold, or the gateway receives a 101 (transaction queued) or 409
(overload) response, the gateway SHOULD adjust the sending rate of
new commands to that Call Agent accordingly. The details of the
smoothing average algorithm, the rate adjustments, and the thresholds
involved are for further study, however they MUST be configurable.
Similarly, Call Agents SHOULD adjust the sending rate of new
transactions to a given gateway by monitoring the observed response
times from that gateway for a *set* of endpoints. If the observed
smoothed average response time suddenly rises significantly over some
threshold, or the Call Agent receives a 101 (transaction queued) or
409 (overloaded), the Call Agent SHOULD adjust the sending rate of
new commands to that gateway accordingly. The details of the
smoothing average algorithm, the rate adjustments, and the thresholds
involved are for further study, however they MUST be configurable.
5. Security Requirements
Any entity can send a command to an MGCP endpoint. If unauthorized
entities could use the MGCP, they would be able to set-up
unauthorized calls, or to interfere with authorized calls. We expect
that MGCP messages will always be carried over secure Internet
connections, as defined in the IP security architecture as defined in
RFC2401, using either the IP Authentication Header, defined in RFC
2402, or the IP Encapsulating Security Payload, defined in RFC2406.
The complete MGCP protocol stack would thus include the following
layers:
-------------------------------
| MGCP |
|-------------------------------|
| UDP |
|-------------------------------|
| IP security |
| (authentication or encryption)|
|-------------------------------|
| IP |
|-------------------------------|
| transmission media |
-------------------------------
Adequate protection of the connections will be achieved if the
gateways and the Call Agents only accept messages for which IP
security provided an authentication service. An encryption service
will provide additional protection against eavesdropping, thus
preventing 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 decoded and the signals will be
played on the "line side".
A basic protection against this attack is to only accept packets from
known sources, however this tends to conflict with RTP principles.
This also 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 source address of the egress gateway and pass it to the ingress
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 and 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 not slow down the call set-up,
and provides strong protection against address spoofing.
6. Packages
As described in Section 2.1.6, packages are the preferred way of
extending MGCP. In this section we describe the requirements
associated with defining a package.
A package MUST have a unique package name defined. The package name
MUST be registered with the IANA, unless it starts with the
characters "x-" or "x+" which are reserved for experimental packages.
Please refer to Appendix C for IANA considerations.
A package MUST also have a version defined which is simply a non-
negative integer. The default and initial version of a package is
zero, the next version is one, etc. New package versions MUST be
completely backwards compatible, i.e., a new version of a package
MUST NOT redefine or remove any of the extensions provided in an
earlier version of the package. If such a need arises, a new package
name MUST be used instead.
Packages containing signals of type time-out MAY indicate if the "to"
parameter is supported for all the time-out signals in the package as
well as the default rounding rules associated with these (see Section
3.2.2.4). If no such definition is provided, each time-out signal
SHOULD provide these definitions.
A package defines one or more of the following extensions:
* Actions
* BearerInformation
* ConnectionModes
* ConnectionParameters
* DigitMapLetters
* Events and Signals
* ExtensionParameters
* LocalConnectionOptions
* ReasonCodes
* RestartMethods
* Return codes
For each of the above types of extensions supported by the package,
the package definition MUST contain a description of the extension as
defined in the following sections. Please note, that package
extensions, just like any other extension, MUST adhere to the MGCP
grammar.
6.1 Actions
Extension Actions SHALL include:
* The name and encoding of the extension action.
* If the extension action takes any action parameters, then the name,
encoding, and possible values of those parameters.
* A description of the operation of the extension action.
* A listing of the actions in this specification the extension can be
combined with. If such a listing is not provided, it is assumed
that the extension action cannot be combined with any other action
in this specification.
* If more than one extension action is defined in the package, then a
listing of the actions in the package the extension can be combined
with. If such a listing is not provided, it is assumed that the
extension action cannot be combined with any other action in the
package.
Extension actions defined in two or more different packages SHOULD
NOT be used simultaneously, unless very careful consideration to
their potential interaction and side-effects has been given.
6.2 BearerInformation
BearerInformation extensions SHALL include:
* The name and encoding of the BearerInformation extension.
* The possible values and encoding of those values that can be
assigned to the BearerInformation extension.
* A description of the operation of the BearerInformation extension.
As part of this description the default value (if any) if the
extension is omitted in an EndpointConfiguration command MUST be
defined. It may be necessary to make a distinction between the
default value before and after the initial application of the
parameter, for example if the parameter retains its previous value
once specified, until explicitly altered. If default values are
not described, then the extension parameter simply defaults to
empty in all EndpointConfiguration commands.
Note that the extension SHALL be included in the result for an
AuditEndpoint command auditing the BearerInformation.
6.3 ConnectionModes
Extension Connection Modes SHALL include:
* The name and encoding of the extension connection mode.
* A description of the operation of the extension connection mode.
* A description of the interaction a connection in the extension
connection mode will have with other connections in each of the
modes defined in this specification. If such a description is not
provided, the extension connection mode MUST NOT have any
interaction with other connections on the endpoint.
Extension connection modes SHALL NOT be included in the list of modes
in a response to an AuditEndpoint for Capabilities, since the package
will be reported in the list of packages.
6.4 ConnectionParameters
Extension Connection Parameters SHALL include:
* The name and encoding of the connection parameter extension.
* The possible values and encoding of those values that can be
assigned to the connection parameter extension.
* A description of how those values are derived.
Note that the extension connection parameter MUST be included in the
result for an AuditConnection command auditing the connection
parameters.
6.5 DigitMapLetters
Extension Digit Map Letters SHALL include:
* The name and encoding of the extension digit map letter(s).
* A description of the meaning of the extension digit map letter(s).
Note that extension DigitMapLetters in a digit map do not follow the
normal naming conventions for extensions defined in packages. More
specifically the package name and slash ("/") will not be part of the
extension name, thereby forming a flat and limited name space with
potential name clashing.
Therefore, a package SHALL NOT define a digit map letter extension
whose encoding has already been used in another package. If two
packages have used the same encoding for a digit map letter
extension, and those two packages are supported by the same endpoint,
the result of using that digit map letter extension is undefined.
Note that although an extension DigitMapLetter does not include the
package name prefix and slash ("/") as part of the extension name
within a digit map, the package name prefix and slash are included
when the event code for the event that matched the DigitMapLetter is
reported as an observed event. In other words, the digit map just
define the matching rule(s), but the event is still reported like any
other event.
6.6 Events and Signals
The event/signal definition SHALL include the precise name of the
event/signal (i.e., the code used in MGCP), a plain text definition
of the event/signal, and, when appropriate, the precise definition of
the corresponding events/signals, for example the exact frequencies
of audio signals such as dial tones or DTMF tones.
The package description MUST provide, for each event/signal, the
following information:
* The description of the event/signal and its purpose, which SHOULD
include the actual signal that is generated by the client (e.g., xx
ms FSK tone) as well as the resulting user observed result (e.g.,
Message Waiting light on/off).
The event code used for the event/signal.
* The detailed characteristics of the event/signal, such as for
example frequencies and amplitude of audio signals, modulations and
repetitions. Such details may be country specific.
* The typical and maximum duration of the event/signal if applicable.
* If the signal or event can be applied to a connection (across a
media stream), it MUST be indicated explicitly. If no such
indication is provided, it is assumed that the signal or event
cannot be applied to a connection.
For events, the following MUST be provided as well:
* An indication if the event is persistent. By default, events are
not persistent - defining events as being persistent is discouraged
(see Appendix B for a preferred alternative). Note that persistent
events will automatically trigger a Notify when they occur, unless
the Call Agent explicitly instructed the endpoint otherwise. This
not only violates the normal MGCP model, but also assumes the Call
Agent supports the package in question. Such an assumption is
unlikely to hold in general.
* An indication if there is an auditable event-state associated with
the event. By default, events do not have auditable event-states.
* If event parameters are supported, it MUST be stated explicitly.
The precise syntax and semantics of these MUST then be provided
(subject to the grammar provided in Appendix A). It SHOULD also be
specified whether these parameters apply to RequestedEvents,
ObservedEvents, DetectEvents and EventStates. If not specified
otherwise, it is assumed that:
* they do not apply to RequestedEvents,
* they do apply to ObservedEvents,
* they apply in the same way to DetectEvents as they do to
RequestedEvents for a given event parameter,
* they apply in the same way to EventStates as they do to
ObservedEvents for a given event parameter.
* If the event is expected to be used in digit map matching, it
SHOULD explicitly state so. Note that only events with single
letter or digit parameter codes can do this. See Section 2.1.5 for
further details.
For signals, the following MUST be provided as well:
* The type of signal (OO, TO, BR).
* Time-Out signals SHOULD have an indication of the default time-out
value. In some cases, time-out values may be variable (if
dependent on some action to complete such as out-pulsing digits).
* If signal parameters are supported, it MUST be stated explicitly.
The precise syntax and semantics of these MUST then be provided
(subject to the grammar provided in Appendix A).
* Time-Out signals may also indicate whether the "to" parameter is
supported or not as well as what the rounding rules associated with
them are. If omitted from the signal definition, the package-wide
definition is assumed (see Section 6). If the package definition
did not specify this, rounding rules default to the nearest non-
zero second, whereas support for the "to" parameter defaults to
"no" for package version zero, and "yes" for package versions one
and higher.
The following format is RECOMMENDED for defining events and signals
in conformance with the above:
------------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------|----------------------------|-----|---------------------|
| | | | |
| | | | |
------------------------------------------------------------------
where:
* Symbol indicates the event code used for the event/signal, e.g.,
"hd".
* Definition gives a brief definition of the event/signal
* R contains an "x" if the event can be detected or one or more of
the following symbols:
- "P" if the event is persistent.
- "S" if the events is an event-state that may be audited.
- "C" if the event can be detected on a connection.
* S contains one of the following if it is a signal:
- "OO" if the signal is On/Off signal.
- "TO" if the signal is a Time-Out signal.
- "BR" if the signal is a Brief signal.
* S also contains:
- "C" if the signal can be applied on a connection.
The table SHOULD then be followed by a more comprehensive description
of each event/signal defined.
6.6.1 Default and Reserved Events
All packages that contain Time-Out type signals contain the operation
failure ("of") and operation complete ("oc") events, irrespective of
whether they are provided as part of the package description or not.
These events are needed to support Time-Out signals and cannot be
overridden in packages with Time-Out signals. They MAY be extended
if necessary, however such practice is discouraged.
If a package without Time-Out signals does contain definitions for
the "oc" and "of" events, the event definitions provided in the
package MAY over-ride those indicated here. Such practice is however
discouraged and is purely allowed to avoid potential backwards
compatibility problems.
It is considered good practice to explicitly mention that the two
events are supported in accordance with their default definitions,
which are as follows:
------------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------|----------------------------|-----|---------------------|
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
------------------------------------------------------------------
Operation complete (oc): The operation complete event is generated
when the gateway was asked to apply one or several signals of type TO
on the endpoint or connection, and one or more of those signals
completed without being stopped by the detection of a requested event
such as off-hook transition or dialed digit. The completion report
should carry as a parameter the name of the signal that came to the
end of its live time, as in:
O: G/oc(G/rt)
In this case, the observed event occurred because the "rt" signal in
the "G" package timed out.
If the reported signal was applied on a connection, the parameter
supplied will include the name of the connection as well, as in:
O: G/oc(G/rt@0A3F58)
When the operation complete event is requested, it cannot be
parameterized with any event parameters. When the package name is
omitted (which is discouraged) as part of the signal name, the
default package is assumed.
Operation failure (of): The operation failure event is generated
when the endpoint was asked to apply one or several signals of type
TO on the endpoint or connection, and one or more of those signals
failed prior to timing out. The completion report should carry as a
parameter the name of the signal that failed, as in:
O: G/of(G/rt)
In this case a failure occurred in producing the "rt" signal in the
"G" package.
When the reported signal was applied on a connection, the parameter
supplied will include the name of the connection as well, as in:
O: G/of(G/rt@0A3F58)
When the operation failure event is requested, event parameters can
not be specified. When the package name is omitted (which is
discouraged), the default package name is assumed.
6.7 ExtensionParameters
Extension parameter extensions SHALL include:
* The name and encoding of the extension parameter.
* The possible values and encoding of those values that can be
assigned to the extension parameter.
* For each of the commands defined in this specification, whether the
extension parameter is Mandatory, Optional, or Forbidden in
requests as well as responses. Note that extension parameters
SHOULD NOT normally be mandatory.
* A description of the operation of the extension parameter. As part
of this description the default value (if any) if the extension is
omitted in a command MUST be defined. It may be necessary to make
a distinction between the default value before and after the
initial application of the parameter, for example if the parameter
retains its previous value once specified, until explicitly
altered. If default values are not described, then the extension
parameter simply defaults to empty in all commands.
* Whether the extension can be audited in AuditEndpoint and/or
AuditConnection as well as the values returned. If nothing is
specified, then auditing of the extension parameter can only be
done for AuditEndpoint, and the value returned SHALL be the current
value for the extension. Note that this may be empty.
6.8 LocalConnectionOptions
LocalConnectionOptions extensions SHALL include:
* The name and encoding of the LocalConnectionOptions extension.
* The possible values and encoding of those values that can be
assigned to the LocalConnectionOptions extension.
* A description of the operation of the LocalConnectionOptions
extension. As part of this description the following MUST be
specified:
- The default value (if any) if the extension is omitted in a
CreateConnection command.
- The default value if omitted in a ModifyConnection command. This
may be to simply retain the previous value (if any) or to apply
the default value. If nothing is specified, the current value is
retained if possible.
- If Auditing of capabilities will result in the extension being
returned, then a description to that effect as well as with what
possible values and their encoding (note that the package itself
will always be returned). If nothing is specified, the extension
SHALL NOT be returned when auditing capabilities.
Also note, that the extension MUST be included in the result for an
AuditConnection command auditing the LocalConnectionOptions.
6.9 Reason Codes
Extension reason codes SHALL include:
* The number for the reason code. The number MUST be in the range
800 to 899.
* A description of the extension reason code including the
circumstances that leads to the generation of the reason code.
Those circumstances SHOULD be limited to events caused by another
extension defined in the package to ensure the recipient will be
able to interpret the extension reason code correctly.
Note that the extension reason code may have to be provided in the
result for an AuditEndpoint command auditing the reason code.
6.10 RestartMethods
Extension Restart Methods SHALL include:
* The name and encoding for the restart method.
* A description of the restart method including the circumstances
that leads to the generation of the restart method. Those
circumstances SHOULD be limited to events caused by another
extension defined in the package to ensure the recipient will be
able to interpret the extension restart method correctly.
* An indication of whether the RestartDelay parameter is to be used
with the extension. If nothing is specified, it is assumed that it
is not to be used. In that case, RestartDelay MUST be ignored if
present.
* If the restart method defines a service state, the description MUST
explicitly state and describe this. In that case, the extension
restart method can then be provided in the result for an
AuditEndpoint command auditing the restart method.
6.11 Return Codes
Extension Return Codes SHALL include:
* The number for the extension return code. The number MUST be in
the range 800 to 899.
* A description of the extension return code including the
circumstances that leads to the generation of the extension return
code. Those circumstances SHOULD be limited to events caused by
another extension defined in the package to ensure the recipient
will be able to interpret the extension return code correctly.
7. Versions and Compatibility
7.1 Changes from RFC2705
RFC2705 was issued in October 1999, as the last update of draft
version 0.5. This updated document benefits from further
implementation experience. The main changes from RFC2705 are:
* Contains several clarifications, editorial changes and resolution
of known inconsistencies.
* Firmed up specification language in accordance with RFC2119 and
added RFC2119 conventions section.
* Clarified behavior of mixed wild-carding in endpoint names.
* Deleted naming requirement about having first term identify the
physical gateway when the gateway consists of multiple physical
gateways. Also added recommendations on wild-carding naming usage
from the right only, as well as mixed wildcard usage.
* Clarified that synonymous forms and values for endpoint names are
not freely interchangeable.
* Allowed IPv6 addresses in endpoint names.
* Clarified Digit Map matching rules.
* Added missing semantics for symbols used in digit maps.
* Added Timer T description in Digit Maps.
* Added recommendation to support digit map sizes of at least 2048
bytes per endpoint.
* Clarified use of wildcards in several commands.
* Event and Signal Parameters formally defined for events and
signals.
* Persistent events now allowed in base MGCP protocol.
* Added additional detail on connection wildcards.
* Clarified behavior of loopback, and continuity test connection
modes for mixing and multiple connections in those modes.
* Modified BearerInformation to be conditional optional in the
EndpointConfiguration command.
* Clarified "swap audio" action operation for one specific scenario
and noted that operation for other scenarios is undefined.
* Added recommendation that all implementations support PCMU encoding
for interoperability.
* Changed Bandwidth LocalConnectionOptions value from excluding to
including overhead from the IP layer and up for consistency with
SDP.
* Clarified that mode of second connection in a CreateConnection
command will be set to "send/receive".
* Type of service default changed to zero.
* Additional detail on echo cancellation, silence suppression, and
gain control. Also added recommendation for Call Agents not to
specify handling of echo cancellation and gain control.
* Added requirement for a connection to have a
RemoteConnectionDescriptor in order to use the "network loopback"
and "network continuity test" modes.
* Removed procedures and specification for NAS's (will be provided as
package instead).
* Removed procedures and specification for ATM (will be provided as
package instead).
* Added missing optional NotifiedEntity parameter to the
DeleteConnection (from the Call Agent) MGCI command.
* Added optional new MaxMGCPDatagram RequestedInfo code for
AuditEndpoint to enable auditing of maximum size of MGCP datagrams
supported.
* Added optional new PackageList RequestedInfo code for AuditEndpoint
to enable auditing of packages with a package version number.
PackageList parameter also allowed with return code 518
(unsupported package).
* Added missing attributes in Capabilities.
* Clarified that at the expiration of a non-zero restart delay, an
updated RestartInProgress should be sent. Also clarified that a
new NotifiedEntity can only be returned in response to a
RestartInProgress command.
* Added Response Acknowledgement response (return code 000) and
included in three-way handshake.
* ResponseAck parameter changed to be allowed in all commands.
* Added return codes 101, 405, 406, 407, 409, 410, 503, 504, 505,
506, 507, 508, 509, 533, 534, 535, 536, 537, 538, 539, 540, 541,
and defined return codes in range 800-899 to be package specific
return codes. Additional text provided for some return codes and
additional detail on how to handle unknown return codes added.
* Added reason code 903, 904, 905 and defined reason codes 800-899 to
be package specific reason codes.
* Added section clarifying codec negotiation procedure.
* Clarified that resource reservation parameters in a
ModifyConnection command defaults to the current value used.
* Clarified that connection mode is optional in ModifyConnection
commands.
* Corrected LocalConnectionDescriptor to be optional in response to
CreateConnection commands (in case of failure).
* Clarified that quoted-strings are UTF-8 encoded and
interchangeability of quoted strings and unquoted strings.
* Clarified that Transaction Identifiers are compared as numerical
values.
* Clarified bit-ordering for Type Of Service LocalConnectionOptions.
* Clarified the use of RequestIdentifier zero.
* Added example sections for commands, responses, and some call
flows.
* Corrected usage of and requirements for SDP to be strictly RFC2327
compliant.
* Added requirement that all MGCP implementations must support MGCP
datagrams up to at least 4000 bytes. Also added new section on
Maximum Datagram Size, Fragmentation and reassembly.
* Generalized piggybacking retransmission scheme to only state
underlying requirements to be satisfied.
* Clarified the section on computing retransmission timers.
* Clarified operation of long-running transactions, including
provisional responses, retransmissions and failures.
* Enhanced description of provisional responses and interaction with
three-way handshake.
* Enhanced description of fail-over and the role of "notified
entity". An empty "notified entity" has been allowed, although
strongly discouraged.
* Clarified retransmission procedure and removed "wrong key"
considerations from it. Also fixed inconsistencies between Max1
and Max2 retransmission boundaries and the associated flow diagram.
* Updated domain name resolution for retransmission procedure to
incur less overhead when multiple endpoints are retransmitting.
* Removed requirement for in-order delivery of NotificationRequests
response and Notify commands. Notify commands are still delivered
in-order.
* Clarified that activating an embedded Notification Request does not
clear the list of ObservedEvents.
* Defined interactions between disconnected state and notification
state.
* Added section on transactional semantics.
* Defined gateway behavior when multiple interacting transactions are
received.
* Additional details provided on service states. Clarified
relationship between endpoint service states, restart methods, and
associated processing of commands.
* Clarified operation for transitioning from "restart procedure" to
"disconnected state".
* Allowed auditing commands and responses to bypass the "restart" and
"disconnected" procedures.
* Clarified operation of "disconnected procedure" and in particular
the operation of piggy-backed "disconnected" RestartInProgress
messages.
* Added option to aggregate "disconnected" RestartInProgress messages
under certain conditions to reduce message volume.
* Defined additional behavior for endpoints wishing to send commands
while in the "disconnected" state.
* Added new section on Load Control in General which includes two new
error codes (101 and 409) to handle overload.
* Deleted the "Proposed MoveConnection command".
* Removed packages from protocol specification (will be provided in
separate documents instead).
* Package concept formally extended to be primary extension mechanism
now allowing extensions for the following to be defined in packages
as well:
- BearerInformation
- LocalConnectionOptions
- ExtensionParameters
- Connection Modes
- Actions
- Digit Map Letters
- Connection Parameters
- Restart Methods
- Reason Codes
- Return Codes
* Requirements and suggested format for package definitions added.
* Defined "operation complete" and "operation failure" events to be
automatically present in packages with Time-Out signals.
* Deleted list of differences that were prior to RFC2705.
* Added Base Package to deal with quarantine buffer overflow,
ObservedEvents overflow, embedded NotificationRequest failure, and
to enable events to be requested persistently. A new "Message"
command is included as well.
* IANA registration procedures for packages and other extensions
added.
* Updated grammar to fix known errors and support new extensions in a
backwards compatible manner. Added new (optional) PackageList and
MaxMGCPDatagram for auditing. Changed explicit white space rules
in some productions to make grammar more consistent.
* Connection Mode interaction table added.
* Added additional detail on virtual endpoint naming conventions.
Also added suggested gateway endpoint convention and a "Range
Wildcard" option to the Endpoint Naming Conventions.
8. Security Considerations
Security issues are discussed in section 5.
9. Acknowledgements
Special thanks are due to the authors of the original MGCP 1.0
specification: Mauricio Arango, Andrew Dugan, Isaac Elliott,
Christian Huitema, and Scott Picket.
We also want to thank the many reviewers who provided advice on the
design of SGCP and then MGCP, notably Sankar Ardhanari, Francois
Berard, David Auerbach, Bob Biskner, David Bukovinsky, Charles Eckel,
Mario Edini, Ed Guy, Barry Hoffner, Jerry Kamitses, Oren Kudevitzki,
Rajesh Kumar, Troy Morley, Dave Oran, Jeff Orwick, John Pickens, Lou
Rubin, Chip Sharp, Paul Sijben, Kurt Steinbrenner, Joe Stone, and
Stuart Wray.
The version 0.1 of MGCP was heavily inspired by the "Internet
Protocol Device Control" (IPDC) designed by the Technical Advisory
Committee set up by Level 3 Communications. Whole sets of text were
retrieved from the IP Connection Control protocol, IP Media Control
protocol, and IP Device Management. The authors wish to acknowledge
the contribution to these protocols made by Ilya Akramovich, Bob
Bell, Dan Brendes, Peter Chung, John Clark, Russ Dehlinger, Andrew
Dugan, Isaac Elliott, Cary FitzGerald, Jan Gronski, Tom Hess, Geoff
Jordan, Tony Lam, Shawn Lewis, Dave Mazik, Alan Mikhak, Pete
O'Connell, Scott Pickett, Shyamal Prasad, Eric Presworsky, Paul
Richards, Dale Skran, Louise Spergel, David Sprague, Raj Srinivasan,
Tom Taylor and Michael Thomas.
10. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC1890, January 1996.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC2327, April 1998.
[6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC2974, October 2000.
[7] Rosenberg, J., Camarillo, G., Johnston, A., Peterson, J.,
Sparks, R., Handley, M., Schulzrinne, H. and E. Schooler,
"Session Initiation Protocol (SIP)", RFC3261, June 2002.
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC2326, April 1998.
[9] ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIPTION OF THE ISDN
USER PART OF SIGNALING SYSTEM No. 7", (Malaga-Torremolinos,
1984; modified at Helsinki, 1993).
[10] ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND
SIGNALS OF THE ISDN USER PART OF SIGNALING SYSTEM No. 7",
(MalagaTorremolinos, 1984; modified at Helsinki, 1993).
[11] ITU-T, Recommendation H.323 (02/98), "PACKET-BASED MULTIMEDIA
COMMUNICATIONS SYSTEMS".
[12] ITU-T, Recommendation H.225, "Call Signaling Protocols and Media
Stream Packetization for Packet Based Multimedia Communications
Systems".
[13] ITU-T, Recommendation H.245 (02/98), "CONTROL PROTOCOL FOR
MULTIMEDIA COMMUNICATION".
[14] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[15] Kent, S. and R. Atkinson, "IP Authentication Header", RFC2402,
November 1998.
[16] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC2406, November 1998.
[17] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.
[18] Stevens, W. Richard, "TCP/IP Illustrated, Volume 1, The
Protocols", Addison-Wesley, 1994.
[19] Allman, M., Paxson, V. "On Estimating End-to-End Network Path
Properties", Proc. SIGCOMM'99, 1999.
[20] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[21] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC1122, October 1989.
[22] Bellcore, "LSSGR: Switching System Generic Requirements for Call
Control Using the Integrated Services Digital Network User Part
(ISDNUP)", GR-317-CORE, Issue 2, December 1997.
[23] Narten, T., and Alvestrand H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC2434, October 1998.
Appendix A: Formal Syntax Description of the Protocol
In this section, we provide a formal description of the protocol
syntax, following the "Augmented BNF for Syntax Specifications"
defined in RFC2234. The syntax makes use of the core rules defined
in RFC2234, Section 6.1, which are not included here. Furthermore,
the syntax follows the case-sensitivity rules of RFC2234, i.e., MGCP
is case-insensitive (but SDP is not). It should be noted, that ABNF
does not provide for implicit specification of linear white space and
MGCP messages MUST thus follow the explicit linear white space rules
provided in the grammar below. However, in line with general
robustness principles, implementers are strongly encouraged to
tolerate additional linear white space in messages received.
MGCPMessage = MGCPCommand / MGCPResponse
MGCPCommand = MGCPCommandLine 0*(MGCPParameter) [EOL *SDPinformation]
MGCPCommandLine = MGCPVerb 1*(WSP) transaction-id 1*(WSP)
endpointName 1*(WSP) MGCPversion EOL
MGCPVerb = "EPCF" / "CRCX" / "MDCX" / "DLCX" / "RQNT"
/ "NTFY" / "AUEP" / "AUCX" / "RSIP" / extensionVerb
extensionVerb = ALPHA 3(ALPHA / DIGIT) ; experimental starts with X
transaction-id = 1*9(DIGIT)
endpointName = LocalEndpointName "@" DomainName
LocalEndpointName = LocalNamePart 0*("/" LocalNamePart)
LocalNamePart = AnyName / AllName / NameString
AnyName = "$"
AllName = "*"
NameString = 1*(range-of-allowed-characters)
; VCHAR except "$", "*", "/", "@"
range-of-allowed-characters = %x21-23 / %x25-29 / %x2B-2E
/ %x30-3F / %x41-7E
DomainName = 1*255(ALPHA / DIGIT / "." / "-") ; as defined
/ "#" number ; in