RFC 3660
Basic Media Gateway Control Protocol (MGCP) Packages
2.10. RTP Package
Package Name: R Version: 1 ------------------------------------------------------------- | Symbol | Definition | R | S Duration | |-------------------------------------------------------------| | co1 | Continuity Tone (single | C | TO,C 3 sec. | | | or return tone) | | | | co2 | Continuity Test (go tone, | C | TO,C 3 sec. | | | in dual tone procedures) | | | | iu(..) | ICMP Unreachable | C | | | | Received | | | | ji(..) | Jitter Buffer Size Changed | C | | | ma | Media Start | C | | | oc | Operation Complete | x | | | of | Operation Failure | x | | | pl(..) | Packet Loss Exceeded | C | | | qa | Quality Alert | C | | | rto(..) | RTP/RTCP Timeout | C | | | sr | Sampling Rate Changed | C | | | uc | Used Codec Changed | C | | ------------------------------------------------------------- Changes in event types: "co1" and "co2" signals changed from OO to TO. New events added to this package from the previously unversioned package: "iu", "rto", "ma". Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details. The events in this package all refer to media streams (connections), i.e., they cannot be detected on an endpoint. Furthermore, with the exception of the "iu" event, which is defined for any type of media, all other events in this package are defined for RTP media streams only (i.e., if they are used on connections that do not use RTP, the behavior is not defined). Signals requested (e.g., "co1" and "co2") must indicate the connection ID (e.g., "S: r/co1@connectionID"). An event may be requested for all existing connections using the "*" wildcard for the connectionID as described in [1].
Example:
R: r/uc@* (request to detect uc on all connections) or
R: r/uc@connectionID (request to detect uc only on a specific
connection)
An event detected on a connection will include the connectionID,
e.g.:
O: r/uc@connectionID(15)
Continuity tones (co1 and co2):
These are the same as the events defined in the Trunk package,
except in this case, they are only played over a network
connection and the connectionID MUST be supplied (e.g., "s:
r/co1@connectionID"). They can be used in conjunction with the
Network LoopBack (netwloop) or Network Continuity Test (netwtest)
modes to test the continuity of an RTP circuit. However, in the
case of testing IP continuity, a one-tone test is sufficient i.e.,
generating and detecting "co1" at one end, with connection mode in
network loopback mode at the other end. Note that the test can
also be done using telephone events rather than tones, i.e., event
167 in RFC 2833 [33] corresponds to "co1". In this case,
connection requests are made with local connection options such
as:
L: a:PCMU;telephone-event,fmtp:"telephone-event 167"
in order to request support for telephone event 167. If both ends
support the event, then the network loopback proceeds as usual,
except that telephone events corresponding to the co1 tone are
sent, as opposed to the co1 tone itself.
ICMP Unreachable Received (iu):
This event indicates that some number of ICMP unreachable packets
[19] was received for this connection since an RQNT was received
requesting this event. This notification indicates that packets
that were sent by the gateway on this connection either did not
arrive at their destination or were not accepted (e.g., the port
was closed). When this event is requested, a single parameter
with a decimal number from 1 to 255 may be included to indicate
the number of ICMP un-reachable packets that must occur before the
event is notified. If no parameter is supplied, with the request
then a default value of 3 is assumed. This is a one-shot event in
that once the event occurs, a further request is required in order
to re-initiate counting.
The observed event is parameterized with two parameters:
* The first parameter is the number of ICMP unreachable
packets received (i.e., the same value that was included in
the request - or the value 3, if the requested event was not
parameterized)
* The second parameter is the error code indicated in the ICMP
unreachable packet, e.g.:
0 = net unreachable;
1 = host unreachable;
2 = protocol unreachable;
3 = port unreachable;
4 = fragmentation needed and DF set;
5 = source route failed.
etc.
An example of a request might be as follows:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
R: r/iu@364823(N)(5)
In this case, a notify will occur if 5 ICMP port unreachable
packets are received as a result of RTP and/or RTCP packets being
sent from this gateway on the connection with connection ID
364823.
The resulting NTFY with observed events might be as follows:
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: r/iu@364823(5,3)
The first parameter indicates 5 ICMP unreachable packets were
received since the RQNT with this request was sent. The second
parameter ("3") specifies the reason, which in this case, is "port
unreachable".
Jitter Buffer Size Changed (ji):
This event is only included here to maintain compatibility with
the previous version of this package. This event is used to
indicate that the gateway has made an adjustment to the depth of
the jitter buffer. 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 a decimal number from 1 to 65536,
indicating the new size of the jitter buffer in milliseconds.
Media Start (ma):
The media start event occurs on a connection when the first valid
RTP media packet is received on the connection. This event can be
used to synchronize a local signal, e.g., ringback, with the
arrival of media from the other party.
The event is detected on a connection. If no connection is
specified, the event applies to all connections for the endpoint,
regardless of when the connections are created (i.e., if a
connection is not specified, the event will occur when the first
valid RTP packet arrives on any one of the connections on that
endpoint).
Operation complete (oc):
This is the standard definition of operation complete [1].
Operation failure (of):
This is the standard definition of operation failure [1].
Packet Loss Exceeded (pl):
Packet loss rate exceeds the threshold of the specified decimal
number (with a range of 1 to 100,000) of packets per 100,000
packets, where the packet loss number is indicated in parenthesis.
For example, PL(10) is a drop rate of 10 in 100,000 packets. This
event is requested with a parameter indicating at what packet loss
rate the Call Agent wishes to be reported. If the packet loss
exceeds that value, the event is reported with that same
parameter. The event is only reported once when the packet loss
threshold is exceeded. Once reported, a following request will
re-initiate packet loss measurements and report when the threshold
is exceeded again.
Quality alert (qa):
The packet loss rate or the combination of delay and jitter
exceeding a quality threshold. The quality thresholds for delay,
jitter and packet loss rate are provisioned values.
RTP/RTCP Timeout (rto(<timeout>,st=<start-time>)):
This event indicates that neither RTP nor RTCP packets have been
received on this connection for a period of time equal to the
<timeout> value (in seconds). The timeout value can be supplied
as a decimal number from 1 to 65535 in the parameter when the
request is made. The <timeout> parameter will be supplied in
ObservedEvents when the event is reported - it then simply repeats
the value used. If an RTP or RTCP packet is received before the
timer expires, then the timer is reset and re-started. The event
will only be generated if the timer expires without an RTP or RTCP
packet arriving on the specified connection during the specified
period of time. Note that if the event is requested without the
<timeout> parameter, then a default timeout of 60 seconds is
assumed. The <timeout> value will still be reported in
ObservedEvents, even if no timeout value was indicated in the
request (the default value will be indicated in that case). This
is a one-shot event in that once the event occurs, a further
request is required in order to re-initialize the timer.
Another optional <start-time> parameter may also be included.
This is used to indicate when the timer starts. It can have one
of the following values:
* "im" for immediate i.e., the timer starts as soon as the
request is received. This is the default.
* "ra" to indicate that the timer should start only after an
RTCP packet has been received from the other end (i.e., the
timer will be initiated when the first RTCP packet is
received after the request is made). Note that in the case
where the other end does not support RTCP, the timer will
never be initiated.
Note that either the <timeout> or <start-time> may be included in
the request, but only the <timeout> value is included in the
report.
An example of a request might be as follows:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
R: r/rto@364823(N)(120,st=im)
In this case, a notify will occur if there is a period of time
when no RTP or RTCP packets have been received on connection
364823 for 120 seconds.
The resulting NTFY with observed events would be as follows:
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: r/rto@364823(120)
Sampling Rate Changed (sr):
This event is only included here to maintain compatibility with
the previous version of this package. This event indicates that
the packetization period changed to some decimal number in
milliseconds enclosed in parenthesis, as in SR(20).
Used Codec Changed (uc):
This event is only included here to maintain compatibility with
the previous version of this package. This event is requested
without a parameter, but when reported, the hexadecimal payload
type is enclosed in parenthesis, as in UC(8), to indicate the
codec was changed to PCM A-law. Codec Numbers are specified in
RFC 3551 [26], or in a new definition of the audio profiles for
RTP that replaces this RFC.
2.11. Resource Reservation Package
Package Name: RES
Version: 0
2.11.1. Description
The "RES" package provides local connection option support for
resource reservations as well as an event to indicate reservation
loss.
A number of LocalConnectionOption parameters are used in doing
resource reservations: "reservation request", "reservation
direction", "reservation confirmation" and "resource sharing".
Reservation Request LocalConnectionOption: The gateways can be
instructed to perform a reservation on a given connection using RSVP.
When a reservation is needed, the Call Agent will specify the
reservation profile that should be used, which is either "controlled
load" or "guaranteed service". The absence of reservation can be
indicated by asking for the "best effort" service, which is the
default value for this parameter.
Whether or not RSVP will be done is dependent on whether the
reservation request LocalConnectionOption parameter has been included
in a connection request for this connection (with either "controlled
load" or "guaranteed service" indicated). If a modify connection
(MDCX) request requires a change in the reservation and the
"reservation request" parameter is not included in the
LocalConnectionOptions, but was included in the
LocalConnectionOptions for a previous connection request for that
connection, then the "reservation request" value defaults to its
previously saved value for that connection. If a modify connection
(MDCX) request explicitly contains a "reservation request",
indicating a request for "best effort" for a connection that has an
existing reservation, the existing reservation will be torn down.
Reservation Direction LocalConnectionOption:
When reservation has been requested on a connection, the gateway
will examine the reservation direction LocalConnectionOption
parameter to determine the direction that the reservations require
and do the following:
* Start emitting RSVP "PATH" messages if the reservation
direction LocalConnectionOptions parameter specified "send-
only" or "send-receive".
* Start emitting RSVP "RESV" messages as soon as it receives
"PATH" messages if the reservation direction parameter
specified "receive-only" or "send-receive".
If an RSVP reservation is requested, but the reservation direction
LocalConnectionOption parameter is missing, the reservation
direction defaults to the previously saved value of the
reservation direction parameter for that connection. If there was
no previous reservation direction parameter for that connection,
the value is deduced from the connection mode. That is:
* Start emitting RSVP "PATH" messages if the connection is in
"send-only", "send-receive", "conference", "network loop
back" or "network continuity test" mode (if a remote
connection descriptor has been received).
* Start emitting RSVP "RESV" messages as soon as it receives
"PATH" messages if the connection is in "receive-only",
"send-receive", "conference", "network loop back" or
"network continuity test" mode.
Reservation Confirmation LocalConnectionOption:
Another LocalConnectionOption parameter for RSVP reservations is
the reservation confirmation parameter, which determines what the
resource reservation pre-condition (see [1]) is for acknowledging
a successful connection request:
* If the reservation confirmation parameter is set to "none",
the gateway will "Ack" the connection request without
waiting for reservation completion. This is the default
behavior.
* If the "reservation confirmation" parameter is set to
"send-only", the gateway will "Ack" when the PATH message
has been sent and the corresponding RESV is received to
indicate successful reservation in the send direction.
* If the "reservation confirmation" parameter is set to
"receive-only", the gateway will "Ack" when reservation
confirm for a reservation has been received.
* If the reservation confirmation parameter is set to "send-
receive", the gateway will "Ack" only after the PATH message
has been sent and the corresponding RESV has been received
for send direction, and reservation confirm has been
received for the receive direction.
Note that:
Values "receive-only" and "send-receive" are triggers for the
gateway to request reservation confirm (RESVCONF) when it sends
out the RESV.
Pre-conditions SHOULD only be added for the direction(s) for which
resource reservations have been requested. If a direction is
added as a pre-condition, and that direction was not requested in
the resource reservation, the direction MUST simply be ignored as
a pre-condition.
In this approach, resource reservation success is the pre-
condition to final acknowledgement of the connection request. If
the reservation fails, the connection request also fails (error
code 404 - insufficient bandwidth) - as will any other part of the
transaction, e.g., a notification request included as part of the
connection request. A typical example of this would be a request
to ring the phone and look for off-hook, included with the
connection request. If the reservation fails, the phone will not
ring. Similarly, if the phone is already off-hook, the command
fails and there will be no resource reservation.
A provisional response SHOULD be provided if confirmation is
expected to occur outside the normal retry timers and in fact a
provisional response MUST be provided if the reservation
confirmation parameter has value "send-receive" (without a
provisional response, SDP information cannot be returned until the
final "Ack" which will not occur until the reservation is
complete. This can result in a deadlock since the SDP information
typically needs to be passed to the other end in order for it to
initiate the RSVP PATH message in the other direction). The SDP
information and connectionID MUST be included in both the
provisional response and the final response. Note that in order
to ensure rapid detection of a lost final response, final
responses issued after provisional responses for a transaction
SHALL be acknowledged, i.e., they SHALL include an empty
"ResponseAck" parameter in the final response (see [1]).
If the transaction time is outside the expected bounds (time
T-HIST - see the section on provisional responses in [1]), error
code 406 (transaction timeout) SHOULD be returned.
Also note that if the reservation confirmation parameter is
omitted, the value of the reservation confirmation parameter
defaults to its previously saved value. If there is no previously
saved value for the reservation confirmation parameter, or the
reservation confirmation parameter has the value "none", then
successful resource reservation is not a pre-condition to
providing an acknowledgement to the connection request (i.e., the
gateway can "Ack" right away without waiting for the reservation
to complete and a provisional response will not be necessary).
Resource Sharing LocalConnectionOption:
It may be possible to share network resources across multiple
connections. An example is a call-waiting scenario, where only
one connection will ever be active at a time. In a 3-way calling
scenario with a similar set of connections, sharing is not
possible. Only the Call Agent knows what may be possible,
depending on the feature that is being invoked.
In order to allow the Call Agent to indicate that sharing is
possible, a resource sharing LocalConnectionOption parameter is
introduced. This parameter can have one of the following values:
* A value "$" can be specified where $ refers to "this
connection". This value is used when doing a create
connection and indicates the intent to share resources with
this connection.
* A connection ID can be specified which indicates that this
is a request to share resources with the connection having
this connection ID (allowing multiple connections to share
resources with the connection indicated).
* The value can be empty, which indicates a request to no
longer share the resources of this connection with other
connections.
In the case of a CRCX, the default value for the resource sharing
local connection option is empty, and for an MDCX, the default
value is its current value.
The RSVP filters will be deduced from the characteristics of the
connection. The RSVP resource profiles will be deduced from the
connection's bandwidth and packetization period.
Note that if RSVP is used with PacketCable Dynamic Quality of Service
[35], then the parameters in NCS [36] would be used instead of the
reservation direction, confirmation and reservation sharing
parameters described here.
2.11.2. Parameter Encoding
The Local Connection Options for the "RES" package consist of the
following:
* The resource reservation parameter, encoded as the keyword "r",
followed by a colon and the value "g" (guaranteed service),
"cl" (controlled load) or "be" (best effort).
* The reservation direction parameter, encoded as the keyword
"r-dir" followed by a colon and the value "sendonly",
"recvonly" or "sendrecv".
* The reservation confirmation parameter, encoded as the keyword
"r-cnf" followed by a colon and the value "none", "sendonly",
"recvonly" or "sendrecv".
* The resource sharing parameter, encoded as the keyword "r-sh"
followed by a colon and either:
* The wild-card character "$" indicating this connection,
indicating future plans to share resources with this
connection, or
* A connection ID, indicating a request to share resources
with the connection having the specified connection ID
(and all other connections sharing resources with that
connection), or
* An empty value (i.e., "r-sh:" with no value indicated),
indicating a request to no longer share the resources of
this connection with other connections
Note that normally local connection options that are associated with
a package have the package prefix included as per the package
extension rules in [1]. The local connection options in the "RES"
package are exceptions. The package prefix is not included in the
case of the "RES" package because it was created before the extension
rules in [1] were defined.
2.11.3. Events
The following events are included as part of the resource reservation
package:
------------------------------------------------------
| Symbol | Definition | R | S Duration |
|------------------------------------------------------|
| re | Resource Error | C | |
| rl | Resource Lost | C | |
------------------------------------------------------
Resource Error (re):
This is an indication that an error in the resource reservation
occurred during the life of the connection. This event is not
requested with a parameter, but is reported with a parameter (see
possible values below). This event may or may not indicate the
permanent loss of the reservation (i.e., any error associated with
the reservation whether permanent or temporary will be reported).
If requested on an endpoint (without specifying the connection
ID), the request refers to all present and future connections on
that endpoint. When reported, the connectionID is always supplied
along with a reason for the error indicated as a parameter. One
of the following possible reasons for loss MUST be included as the
parameter when the event is reported:
- "resverr" is used to indicate that a ResvErr message was
received.
- "patherr" is used to indicate that a PathErr message was
received.
- "other"
In addition to a parameter indicating one of the reasons above,
additional information on the type of error MAY be included as a
second parameter in the form of a quoted string.
Example report might include:
O: res/rl@0A3F58(resverr)
or
O: res/rl@0A3F58(resverr, "some additional commentary")
Note that this event will not be reported if an error occurs while
a resource reservation is initially being set up (i.e., the event
was only reported as a result of an error that occurred after the
reservation was set up).
Resource Lost (rl):
Loss of reservation during the life of a connection can be
reported by using the "rl" event. This event is not requested
with a parameter, but is reported with a parameter (see below for
possible values). If requested on an endpoint (without specifying
the connection ID), the request refers to all present and future
connections on that endpoint.
When reported, the connectionID is always supplied along with a
reason for the loss indicated as a parameter. One of the
following possible reasons for loss MUST be supplied as the
parameter when the event is reported:
- "resvtear" indicating that the reservation loss was
indicated by ResvTear message.
- "pathtear" indicating that the reservation loss was
indicated by PathTear message.
- "other"
In addition to a parameter indicating one of the reasons above,
additional information on the type of error MAY be included as a
second parameter in the form of a quoted string.
Example report might include:
O: res/rl@0A3F58(ResvTear)
or
O: res/rl@0A3F58(ResvTear, "some other commentary")
Note that this event will not be reported if an error occurs while
a resource reservation is initially being set up (i.e., the event
is only reported if the reservation was lost after it was
initially set up).
2.12. Announcement Server Package
Package Name: A
Version: 1
---------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------------------------------------------------------------|
| ann(url) | Play an Announcement | | TO, C variable |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
---------------------------------------------------------------
Changes from the previous version: change to conform to standard
reporting of operation failure and operation complete events.
The announcement signal is qualified by a URL name:
S: ann(http://scripts.example.net/all-lines-busy.au)
The URL name MAY be followed by a list of initial parameters,
separated by commas. However, standard parameters are not included
as part of this package definition (Note: use of additional
parameters is optional and would result in a proprietary interface).
The gateway SHOULD support one or more standard URL schemes such as:
* file, http, ftp (RFC 1738 [28]), which indicate where the audio
file is located (where to load the file from before playing the
audio file on the gateway).
* RTSP URL (section 3.2 of RFC 2326 [29]), which in this case
allows the media gateway to directly initiate playing of the
announcement via an RTSP server.
The pre-condition for a successful response (return code of "200") is
correct syntax and capability (support is available for this
request). Standard MGCP return codes apply in the case of failure.
Further indications of failure are provided in the operation failure
event as a comment after the name of the failed event in the form of
a quoted string.
If the announcement cannot be played out for a reason determined
after a successful response to the request has been provided, an
operation failure event will be returned. The failure MAY be
explained by some commentary (in the form of a quoted string), as in:
O: a/of(a/ann,"file not found")
The "operation complete" event will be detected when the announcement
is played out.
O: a/oc(a/ann)
2.13. Script Package
Package Name: Script
Version: 1
-----------------------------------------------------------------
| Symbol | Definition | R | S | Duration |
|-----------------------------------------------------------------|
| ir(..) | Intermediate Results/Req.| x | BR | |
| java(url,...) | Load & Run java script | | TO | variable |
| oc | operation complete | x | | |
| of | operation failure | x | | |
| perl(url,...) | Load & Run perl script | | TO | variable |
| tcl(url,...) | Load & Run TCL script | | TO | variable |
| vxml(url,...) | Load & Run VXML doc. | | TO | variable |
| xml(url,...) | Load & Run XML script | | TO | variable |
-----------------------------------------------------------------
Changes from the previous version of the package: "vxml" was added as
a language type for loading and running VXML documents; change to
conform with standard reporting of operation failure and operation
complete events; addition of "ir" event.
The current definition defines keywords for the most common
languages. More languages may be defined in later versions of this
package.
The "signal" specifying the scripting language is parameterized with
a URL indicating the location of the script. The URL parameter MAY
be optionally followed by a comma-separated list of arguments as
initial parameters to use in running the script. URL schemes may
include file ftp, or http schemes with syntax according to RFC 2396
[30]. As an example:
S: script/vxml(ftp://ftp.example.net/credit-card.vxml,arg1,arg2,
...,argn)
The argument list "arg1,arg2,...,argn" is passed to the
script/document as a list of initial parameters.
The pre-condition for a successful response (return code of "200") is
correct syntax and capability (support is available for this
request). Standard MGCP return codes apply in the case of failure.
Some further (non-application/script specific) failure indications
MAY be provided in the operation failure event as a comment in the
form of a quoted string following the name of the failed event.
Example
O: script/of(script/vxml,"file not found")
The script produces an output, which consists of one or several text
strings, separated by commas. This provides the return-status of the
script as well as return parameters (if there are any)
O: script/oc(script/vxml,return-status=<status>,
name1=value1,name2=value2,...)
where <status> can have one of the values "success" or "failure".
This is then followed by output parameters as a comma-separated list
of name-value pairs.
Intermediate Result/Request (ir(<params>)):
This provides a way for:
* The script to inform the Call Agent of intermediate results
(e.g., a case where it is important because of timing
concerns to inform the Call Agent prior to operation
complete).
* The script to request some information from the Call Agent.
* The Call Agent to inform the script of some event or
information that may be important for the operation of the
script (in this case "ir" is used as a signal).
Parameters (i.e., <params>) SHOULD be a comma-separated list of
name-value pairs e.g., ir(name1=value1,name2=value2,..). The Call
Agent MAY include event parameters when it requests this event, in
which case, the MGCP syntax requirements require that the action
be specified (e.g., "R: ir(N)(nam1=value1,name2=value2,..)").
If the Call Agent requests "ir" as a signal, at least one
parameter MUST be provided.
When requesting the "ir" signal, the Call Agent MUST also repeat
the original script signal. This is in order to be consistent
with the semantics of TO signals in MGCP (i.e., if the original
"script" signal is not included, then the signal/script will be
stopped). The only problem with this is that there is a possible
race condition in which a request to send an "ir" signal could
occur just as the script stopped. In order to avoid this
confusion, the following is RECOMMENDED: when the script signal is
included with an "ir" signal, include a parameter (of the script
signal) to indicate that this is not a new instance of the script
i.e., if there is no script executing at the present time do not
start executing a new one.
The "ir" signal is only associated with an executing script. If
none are running when a request for the event/signal is made, or
if a new script request is not included with the request, then the
"ir" signal/event will not be executed (i.e., the "ir" event with
its parameters is passed to an existing script for parsing and
execution and is considered opaque as far as MGCP as concerned.
If no such script exists, response code "800" will be returned,
indicating that the script is not executing).
The following response code is associated with this package:
Code Text Explanation
800 Script not Request for "ir" signal or event
Executing but no script is executing at the
time the request was received.
Note that package specific error codes include the package name
following the error code. For example, if error code 800 occurs
in response to a request with a transaction ID of 1001, it would
be sent as:
800 1001 /SCRIPT
3. IANA Considerations
The following packages and their versions have been registered with IANA as per the instructions in [1]. Package Title Name Version ------------- ---- ------- Announcement A 1 DTMF D 1 Digit Map Extension DM1 0 Media Format FM 0 Generic G 1 Handset H 1 Line L 1 RTP R 1 Resource Reservation RES 0 Script SCRIPT 1 Supplementary Tones SST 0 Signal List SL 0 Trunk T 1 The following extension digit map letter has been registered with IANA: Package Letter ------- ------ DM1 P The following Local Connections have been registered with IANA: Field Name ------- ----- Media Format fmtp Reservation Confirmation r-cnf Reservation Direction r-dir Resource Sharing r-sh4. Security Considerations
The MGCP packages contained in this document do not require any further security considerations beyond those indicated in the base MGCP specification [1].5. 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.
Thanks also to the reviewers of this document, including but not limited to: Jerry Kamitses, Sonus Networks; Dave Auerbach, Dan Wing, Cisco Systems; Ed Guy, EMC Software; Martin Wakley, Nortel Networks.6. References
6.1. Normative References
[1] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003. [2] 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. [3] ITU-T, "Telephone User Part Signaling Procedures", ITU-T Q.724, November 1988. [4] ANSI, "OAM&P - Terminating Test Line Access and Capabilities", T1.207-2000. [5] Bellcore, "Notes on the Network", Special Report SR-2275, Issue 3, December 1997. [6] Bellcore, "Call Processing" GR-505-CORE, Issue 1, December 1997. [7] Bellcore, "LSSGR: Signaling for Analog Interfaces", GR-506-CORE, Issue 1, June 1996. [8] ITU-T, "Technical Characteristics of Tones for the Telephone Service", ITU-T E.180, March 1998. [9] ITU-T, "Various Tones Used in National Networks", ITU-T E.180, Supplement 2, January 1994. [10] ITU-T, "Applications of Tones and Recorded Announcements in Telephone Services", ITU-T E.182, March 1998. [11] Bellcore, "Call Forwarding Sub-Features FSD-01-02-1450, GR-586, Issue 1, June 2000. [12] Bellcore, "CPE Compatibility Considerations for the Voiceband Data Transmission Interface", SR-TSV-002476, December 1992. [13] Bellcore, "LSSGR: Visual Message Waiting Indicator Generic Requirements (FSD 01-02-2000)", GR-1401, Issue 01, June 2000.
[14] Bellcore, "LSSGR Voiceband Data Transmission Interface", Section 6.6, GR-30-CORE, Issue 02, December 1998. [15] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [16] Bellcore, "LSSGR: Call Waiting, FSD 01-02-1201", GR-571, Issue 01, June 2000. [17] Bellcore, "LSSGR: Verification Connections FSD 25-05-0903", GR- 531-CORE, Issue 1, June 2000. [18] Bellcore, " LSSGR: CLASS Feature: Calling Identity Delivery on Call Waiting, FSD 01-02-1090, GR-575, Issue 01, June 2000. [19] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [20] Bellcore, "Class Feature: Screen Editing (FSD 30-28-0000)", GR- 220, Issue 2, April 2002. [21] ITU-T, "Procedure for document facsimile transmission in the general switched telephone network", ITU-T T.30, April 1999. [22] ITU-T, "300 bits per second duplex modem standardized for use in the general switched telephone network", ITU-T V.21, November 1988. [23] Telcordia Technologies, "Telcordia Technologies Specification of Signaling System Number 7", GR-246-CORE, Issue 7, December 2002. [24] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Name Delivery Generic Requirements (FSD 01-02-1070)", GR-1188, Issue 02, December 2000. [25] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Number Delivery (FSD 01-02-1051)", GR-31, Issue 01, June 2000. [26] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. [27] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [28] Berners-Lee, T., Masinter, L. and M. McCahill, Eds., "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[29] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [30] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [31] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.6.2. Informative References
[32] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997. [33] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [34] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001. [35] PacketCableTM, Dynamic Quality if Service Specification, http://www.packetcable.com/downloads/specs/PKT-SP-DQOS-I07- 030815.pdf [36] PacketCableTM Network-Based Call Signaling Protocol http://www.packetcable.com/downloads/specs/PKT-SP-EC-MGCP-I08- 030728.pdf [37] Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, Eds., "Gateway Control Protocol Version 1", RFC 3525, June 2003. [38] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999.
7. Authors' Addresses
Bill Foster Cisco Systems Phone: +1 250 758 9418 EMail: bfoster@cisco.com Flemming Andreasen Cisco Systems Edison, NJ 08837 EMail: fandreas@cisco.com
8. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.