summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3435.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3435.txt')
-rw-r--r--doc/rfc/rfc3435.txt11763
1 files changed, 11763 insertions, 0 deletions
diff --git a/doc/rfc/rfc3435.txt b/doc/rfc/rfc3435.txt
new file mode 100644
index 0000000..a242795
--- /dev/null
+++ b/doc/rfc/rfc3435.txt
@@ -0,0 +1,11763 @@
+
+
+
+
+
+
+Network Working Group F. Andreasen
+Request for Comments: 3435 B. Foster
+Obsoletes: 2705 Cisco Systems
+Category: Informational January 2003
+
+
+ Media Gateway Control Protocol (MGCP)
+ Version 1.0
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+IESG Note
+
+ This document is being published for the information of the
+ community. It describes a protocol that is currently being deployed
+ in a number of products. Implementers should be aware of RFC 3015,
+ which was developed in the IETF Megaco Working Group and the ITU-T
+ SG16 and which is considered by the IETF and ITU-T to be the
+ standards-based (including reviewed security considerations) way to
+ meet the needs that MGCP was designed to address.
+
+Abstract
+
+ This document describes an application programming interface and a
+ corresponding protocol (MGCP) which is used between elements of a
+ decomposed multimedia gateway. The decomposed multimedia gateway
+ consists of a Call Agent, which contains the call control
+ "intelligence", and a media gateway which contains the media
+ functions, e.g., conversion from TDM voice to Voice over IP.
+
+ Media gateways contain endpoints on which the Call Agent can create,
+ modify and delete connections in order to establish and control media
+ sessions with other multimedia endpoints. Also, the Call Agent can
+ instruct the endpoints to detect certain events and generate signals.
+ The endpoints automatically communicate changes in service state to
+ the Call Agent. Furthermore, the Call Agent can audit endpoints as
+ well as the connections on endpoints.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 1]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The basic and general MGCP protocol is defined in this document,
+ however most media gateways will need to implement one or more MGCP
+ packages, which define extensions to the protocol suitable for use
+ with specific types of media gateways. Such packages are defined in
+ separate documents.
+
+Table of Contents
+
+ 1. Introduction.................................................5
+ 1.1 Relation with the H.323 Standards............................7
+ 1.2 Relation with the IETF Standards.............................8
+ 1.3 Definitions..................................................9
+ 1.4 Conventions used in this Document............................9
+ 2. Media Gateway Control Interface.............................10
+ 2.1 Model and Naming Conventions................................10
+ 2.1.1 Types of Endpoints..........................................10
+ 2.1.2 Endpoint Identifiers........................................14
+ 2.1.3 Calls and Connections.......................................16
+ 2.1.4 Names of Call Agents and Other Entities.....................22
+ 2.1.5 Digit Maps..................................................23
+ 2.1.6 Packages....................................................26
+ 2.1.7 Events and Signals..........................................28
+ 2.2 Usage of SDP................................................33
+ 2.3 Gateway Control Commands....................................33
+ 2.3.1 Overview of Commands........................................33
+ 2.3.2 EndpointConfiguration.......................................36
+ 2.3.3 NotificationRequest.........................................37
+ 2.3.4 Notify......................................................44
+ 2.3.5 CreateConnection............................................46
+ 2.3.6 ModifyConnection............................................52
+ 2.3.7 DeleteConnection (from the Call Agent)......................54
+ 2.3.8 DeleteConnection (from the gateway).........................58
+ 2.3.9 DeleteConnection (multiple connections from the Call Agent) 59
+ 2.3.10 AuditEndpoint...............................................60
+ 2.3.11 AuditConnection.............................................65
+ 2.3.12 RestartInProgress...........................................66
+ 2.4 Return Codes and Error Codes................................69
+ 2.5 Reason Codes................................................74
+ 2.6 Use of Local Connection Options and Connection Descriptors..75
+ 2.7 Resource Reservations.......................................77
+ 3. Media Gateway Control Protocol..............................77
+ 3.1 General Description.........................................78
+ 3.2 Command Header..............................................79
+ 3.2.1 Command Line................................................79
+ 3.2.2 Parameter Lines.............................................82
+ 3.3 Format of response headers.................................101
+ 3.3.1 CreateConnection Response..................................104
+ 3.3.2 ModifyConnection Response..................................105
+
+
+
+Andreasen & Foster Informational [Page 2]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 3.3.3 DeleteConnection Response..................................106
+ 3.3.4 NotificationRequest Response...............................106
+ 3.3.5 Notify Response............................................106
+ 3.3.6 AuditEndpoint Response.....................................106
+ 3.3.7 AuditConnection Response...................................107
+ 3.3.8 RestartInProgress Response.................................108
+ 3.4 Encoding of the Session Description (SDP)..................108
+ 3.4.1 Usage of SDP for an Audio Service..........................110
+ 3.4.2 Usage of SDP for LOCAL Connections.........................110
+ 3.5 Transmission over UDP......................................111
+ 3.5.1 Providing the At-Most-Once Functionality...................112
+ 3.5.2 Transaction Identifiers and Three Ways Handshake...........113
+ 3.5.3 Computing Retransmission Timers............................114
+ 3.5.4 Maximum Datagram Size, Fragmentation and Reassembly........115
+ 3.5.5 Piggybacking...............................................116
+ 3.5.6 Provisional Responses......................................117
+ 4. States, Failover and Race Conditions.......................119
+ 4.1 Failover Assumptions and Highlights........................119
+ 4.2 Communicating with Gateways................................121
+ 4.3 Retransmission, and Detection of Lost Associations:........122
+ 4.4 Race Conditions............................................126
+ 4.4.1 Quarantine List............................................127
+ 4.4.2 Explicit Detection.........................................133
+ 4.4.3 Transactional Semantics....................................134
+ 4.4.4 Ordering of Commands, and Treatment of Misorder............135
+ 4.4.5 Endpoint Service States....................................137
+ 4.4.6 Fighting the Restart Avalanche.............................140
+ 4.4.7 Disconnected Endpoints.....................................143
+ 4.4.8 Load Control in General....................................146
+ 5. Security Requirements......................................147
+ 5.1 Protection of Media Connections............................148
+ 6. Packages...................................................148
+ 6.1 Actions....................................................150
+ 6.2 BearerInformation..........................................150
+ 6.3 ConnectionModes............................................151
+ 6.4 ConnectionParameters.......................................151
+ 6.5 DigitMapLetters............................................151
+ 6.6 Events and Signals.........................................152
+ 6.6.1 Default and Reserved Events................................155
+ 6.7 ExtensionParameters........................................156
+ 6.8 LocalConnectionOptions.....................................157
+ 6.9 Reason Codes...............................................157
+ 6.10 RestartMethods.............................................158
+ 6.11 Return Codes...............................................158
+ 7. Versions and Compatibility.................................158
+ 7.1 Changes from RFC 2705......................................158
+ 8. Security Considerations....................................164
+ 9. Acknowledgments............................................164
+
+
+
+Andreasen & Foster Informational [Page 3]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 10. References.................................................164
+ Appendix A: Formal Syntax Description of the Protocol.............167
+ Appendix B: Base Package..........................................175
+ B.1 Events.....................................................175
+ B.2 Extension Parameters.......................................176
+ B.2.1 PersistentEvents...........................................176
+ B.2.2 NotificationState..........................................177
+ B.3 Verbs......................................................177
+ Appendix C: IANA Considerations...................................179
+ C.1 New MGCP Package Sub-Registry..............................179
+ C.2 New MGCP Package...........................................179
+ C.3 New MGCP LocalConnectionOptions Sub-Registry...............179
+ Appendix D: Mode Interactions.....................................180
+ Appendix E: Endpoint Naming Conventions...........................182
+ E.1 Analog Access Line Endpoints...............................182
+ E.2 Digital Trunks.............................................182
+ E.3 Virtual Endpoints..........................................183
+ E.4 Media Gateway..............................................184
+ E.5 Range Wildcards............................................184
+ Appendix F: Example Command Encodings.............................185
+ F.1 NotificationRequest........................................185
+ F.2 Notify.....................................................186
+ F.3 CreateConnection...........................................186
+ F.4 ModifyConnection...........................................189
+ F.5 DeleteConnection (from the Call Agent).....................189
+ F.6 DeleteConnection (from the gateway)........................190
+ F.7 DeleteConnection (multiple connections
+ from the Call Agent).......................................190
+ F.8 AuditEndpoint..............................................191
+ F.9 AuditConnection............................................192
+ F.10 RestartInProgress..........................................193
+ Appendix G: Example Call Flows....................................194
+ G.1 Restart....................................................195
+ G.1.1 Residential Gateway Restart................................195
+ G.1.2 Call Agent Restart.........................................198
+ G.2 Connection Creation........................................200
+ G.2.1 Residential Gateway to Residential Gateway.................200
+ G.3 Connection Deletion........................................206
+ G.3.1 Residential Gateway to Residential Gateway.................206
+ Authors' Addresses................................................209
+ Full Copyright Statement..........................................210
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 4]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+1. Introduction
+
+ This document describes an abstract application programming interface
+ (MGCI) and a corresponding protocol (MGCP) for controlling media
+ gateways from external call control elements called media gateway
+ controllers or Call Agents. A media gateway is typically a network
+ element that provides conversion between the audio signals carried on
+ telephone circuits and data packets carried over the Internet or over
+ other packet networks. Examples of media gateways are:
+
+ * Trunking gateways, that interface between the telephone network and
+ a Voice over IP network. Such gateways typically manage a large
+ number of digital circuits.
+
+ * Voice over ATM gateways, which operate much the same way as voice
+ over IP trunking gateways, except that they interface to an ATM
+ network.
+
+ * Residential gateways, that provide a traditional analog (RJ11)
+ interface to a Voice over IP network. Examples of residential
+ gateways include cable modem/cable set-top boxes, xDSL devices, and
+ broad-band wireless devices.
+
+ * Access gateways, that provide a traditional analog (RJ11) or
+ digital PBX interface to a Voice over IP network. Examples of
+ access gateways include small-scale voice over IP gateways.
+
+ * Business gateways, that provide a traditional digital PBX interface
+ or an integrated "soft PBX" interface to a Voice over IP network.
+
+ * Network Access Servers, that can attach a "modem" to a telephone
+ circuit and provide data access to the Internet. We expect that in
+ the future, the same gateways will combine Voice over IP services
+ and Network Access services.
+
+ * Circuit switches, or packet switches, which can offer a control
+ interface to an external call control element.
+
+ MGCP assumes a call control architecture where the call control
+ "intelligence" is outside the gateways and handled by external call
+ control elements known as Call Agents. The MGCP assumes that these
+ call control elements, or Call Agents, will synchronize with each
+ other to send coherent commands and responses to the gateways under
+ their control. If this assumption is violated, inconsistent behavior
+ should be expected. MGCP does not define a mechanism for
+ synchronizing Call Agents. MGCP is, in essence, a master/slave
+ protocol, where the gateways are expected to execute commands sent by
+ the Call Agents. In consequence, this document specifies in great
+
+
+
+Andreasen & Foster Informational [Page 5]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ detail the expected behavior of the gateways, but only specifies
+ those parts of a Call Agent implementation, such as timer management,
+ that are mandated for proper operation of the protocol.
+
+ MGCP assumes a connection model where the basic constructs are
+ endpoints and connections. Endpoints are sources and/or sinks of
+ data and can be physical or virtual. Examples of physical endpoints
+ are:
+
+ * An interface on a gateway that terminates a trunk connected to a
+ PSTN switch (e.g., Class 5, Class 4, etc.). A gateway that
+ terminates trunks is called a trunking gateway.
+
+ * An interface on a gateway that terminates an analog POTS connection
+ to a phone, key system, PBX, etc. A gateway that terminates
+ residential POTS lines (to phones) is called a residential gateway.
+
+ An example of a virtual endpoint is an audio source in an audio-
+ content server. Creation of physical endpoints requires hardware
+ installation, while creation of virtual endpoints can be done by
+ software.
+
+ Connections may be either point to point or multipoint. A point to
+ point connection is an association between two endpoints with the
+ purpose of transmitting data between these endpoints. Once this
+ association is established for both endpoints, data transfer between
+ these endpoints can take place. A multipoint connection is
+ established by connecting the endpoint to a multipoint session.
+
+ Connections can be established over several types of bearer networks,
+ for example:
+
+ * Transmission of audio packets using RTP and UDP over an IP network.
+
+ * Transmission of audio packets using AAL2, or another adaptation
+ layer, over an ATM network.
+
+ * Transmission of packets over an internal connection, for example
+ the TDM backplane or the interconnection bus of a gateway. This is
+ used, in particular, for "hairpin" connections, connections that
+ terminate in a gateway but are immediately rerouted over the
+ telephone network.
+
+ For point-to-point connections the endpoints of a connection could be
+ in separate gateways or in the same gateway.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 6]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+1.1 Relation with the H.323 Standards
+
+ MGCP is designed as an internal protocol within a distributed system
+ that appears to the outside as a single VoIP gateway. This system is
+ composed of a Call Agent, that may or may not be distributed over
+ several computer platforms, and of a set of gateways, including at
+ least one "media gateway" that perform the conversion of media
+ signals between circuits and packets, and at least one "signaling
+ gateway" when connecting to an SS7 controlled network. In a typical
+ configuration, this distributed gateway system will interface on one
+ side with one or more telephony (i.e., circuit) switches, and on the
+ other side with H.323 conformant systems, as indicated in the
+ following table:
+
+ ------------------------------------------------------------------
+ | Functional| Phone | Terminating | H.323 conformant |
+ | Plane | switch | Entity | systems |
+ |-----------|------------|-----------------|-----------------------|
+ | Signaling | Signaling | Call agent | Signaling exchanges |
+ | Plane | exchanges | | with the Call Agent |
+ | | through | | through H.225/RAS and|
+ | | SS7/ISUP | | H.225/Q.931. |
+ |-----------|------------|-----------------|-----------------------|
+ | | | | Possible negotiation |
+ | | | | of logical channels |
+ | | | | and transmission |
+ | | | | parameters through |
+ | | | | H.245 with the call |
+ | | | | agent. |
+ |-----------|------------|-----------------|-----------------------|
+ | | | Internal | |
+ | | | synchronization| |
+ | | | through MGCP | |
+ |-----------|------------|-----------------|-----------------------|
+ | Bearer | Connection| Telephony | Transmission of VoIP |
+ | Data | through | gateways | data using RTP |
+ | Transport | high speed| | directly between the |
+ | Plane | trunk | | H.323 station and the|
+ | | groups | | gateway. |
+ ------------------------------------------------------------------
+
+ In the MGCP model, the gateways focus on the audio signal translation
+ function, while the Call Agent handles the call signaling and call
+ processing functions. As a consequence, the Call Agent implements
+ the "signaling" layers of the H.323 standard, and presents itself as
+ an "H.323 Gatekeeper" or as one or more "H.323 Endpoints" to the
+ H.323 systems.
+
+
+
+
+Andreasen & Foster Informational [Page 7]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+1.2 Relation with the IETF Standards
+
+ While H.323 is the recognized standard for VoIP terminals, the IETF
+ has also produced specifications for other types of multi-media
+ applications. These other specifications include:
+
+ * the Session Description Protocol (SDP), RFC 2327
+
+ * the Session Announcement Protocol (SAP), RFC 2974
+
+ * the Session Initiation Protocol (SIP), RFC 3261
+
+ * the Real Time Streaming Protocol (RTSP), RFC 2326.
+
+ The latter three specifications are in fact alternative signaling
+ standards that allow for the transmission of a session description to
+ an interested party. SAP is used by multicast session managers to
+ distribute a multicast session description to a large group of
+ recipients, SIP is used to invite an individual user to take part in
+ a point-to-point or unicast session, RTSP is used to interface a
+ server that provides real time data. In all three cases, the session
+ description is described according to SDP; when audio is transmitted,
+ it is transmitted through the Real-time Transport Protocol, RTP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 8]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The distributed gateway systems and MGCP will enable PSTN telephony
+ users to access sessions set up using SAP, SIP or RTSP. The Call
+ Agent provides for signaling conversion, according to the following
+ table:
+
+ ------------------------------------------------------------------
+ | Functional| Phone | Terminating | IETF conforming systems|
+ | Plane | switch | Entity | |
+ |-----------|------------|---------------|-------------------------|
+ | Signaling | Signaling | Call agent | Signaling exchanges |
+ | Plane | exchanges | | with the Call Agent |
+ | | through | | through SAP, SIP or |
+ | | SS7/ISUP | | RTSP. |
+ |-----------|------------|---------------|-------------------------|
+ | | | | Negotiation of session |
+ | | | | description parameters |
+ | | | | through SDP (telephony |
+ | | | | gateway terminated but |
+ | | | | passed via the call |
+ | | | | agent to and from the |
+ | | | | IETF conforming system)|
+ |-----------|------------|---------------|-------------------------|
+ | | | Internal syn- | |
+ | | | chronization | |
+ | | | through MGCP | |
+ |-----------|------------|---------------|-------------------------|
+ | Bearer | Connection| Telephony | Transmission of VoIP |
+ | Data | through | gateways | data using RTP, |
+ | Transport | high speed| | directly between the |
+ | Plane | trunk | | remote IP end system |
+ | | groups | | and the gateway. |
+ ------------------------------------------------------------------
+
+ The SDP standard has a pivotal status in this architecture. We will
+ see in the following description that we also use it to carry session
+ descriptions in MGCP.
+
+1.3 Definitions
+
+ Trunk: A communication channel between two switching systems, e.g.,
+ a DS0 on a T1 or E1 line.
+
+1.4 Conventions used in this Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED, "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in BCP
+ 14, RFC 2119 [2].
+
+
+
+Andreasen & Foster Informational [Page 9]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+2. Media Gateway Control Interface
+
+ The interface functions provide for connection control and endpoint
+ control. Both use the same system model and the same naming
+ conventions.
+
+2.1 Model and Naming Conventions
+
+ The MGCP assumes a connection model where the basic constructs are
+ endpoints and connections. Connections are grouped in calls. One or
+ more connections can belong to one call. Connections and calls are
+ set up at the initiative of one or more Call Agents.
+
+2.1.1 Types of Endpoints
+
+ In the introduction, we presented several classes of gateways. Such
+ classifications, however, can be misleading. Manufacturers can
+ arbitrarily decide to provide several types of services in a single
+ package. A single product could well, for example, provide some
+ trunk connections to telephony switches, some primary rate
+ connections and some analog line interfaces, thus sharing the
+ characteristics of what we described in the introduction as
+ "trunking", "access" and "residential" gateways. MGCP does not make
+ assumptions about such groupings. We simply assume that media
+ gateways support collections of endpoints. The type of the endpoint
+ determines its functionality. Our analysis, so far, has led us to
+ isolate the following basic endpoint types:
+
+ * Digital channel (DS0),
+
+ * Analog line,
+
+ * Announcement server access point,
+
+ * Interactive Voice Response access point,
+
+ * Conference bridge access point,
+
+ * Packet relay,
+
+ * ATM "trunk side" interface.
+
+ In this section, we will describe the expected behavior of such
+ endpoints.
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 10]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ This list is not final. There may be other types of endpoints
+ defined in the future, for example test endpoints that could be used
+ to check network quality, or frame-relay endpoints that could be used
+ to manage audio channels multiplexed over a frame-relay virtual
+ circuit.
+
+2.1.1.1 Digital Channel (DS0)
+
+ Digital channels provide a 64 Kbps service. Such channels are found
+ in trunk and ISDN interfaces. They are typically part of digital
+ multiplexes, such as T1, E1, T3 or E3 interfaces. Media gateways
+ that support such channels are capable of translating the digital
+ signals received on the channel, which may be encoded according to
+ A-law or mu-law, using either the complete set of 8 bits per sample
+ or only 7 of these bits, into audio packets. When the media gateway
+ also supports a Network Access Server (NAS) service, the gateway
+ shall be capable of receiving either audio-encoded data (modem
+ connection) or binary data (ISDN connection) and convert them into
+ data packets.
+
+ +-------
+ +------------+|
+ (channel) ===|DS0 endpoint| -------- Connections
+ +------------+|
+ +-------
+
+ Media gateways should be able to establish several connections
+ between the endpoint and the packet networks, or between the endpoint
+ and other endpoints in the same gateway. The signals originating
+ from these connections shall be mixed according to the connection
+ "mode", as specified later in this document. The precise number of
+ connections that an endpoint supports is a characteristic of the
+ gateway, and may in fact vary according to the allocation of
+ resources within the gateway.
+
+ In some cases, digital channels are used to carry signaling. This is
+ the case for example for SS7 "F" links, or ISDN "D" channels. Media
+ gateways that support these signaling functions shall be able to send
+ and receive the signaling packets to and from a Call Agent, using the
+ "backhaul" procedures defined by the SIGTRAN working group of the
+ IETF. Digital channels are sometimes used in conjunction with
+ channel associated signaling, such as "MF R2". Media gateways that
+ support these signaling functions shall be able to detect and produce
+ the corresponding signals, such as for example "wink" or "A",
+ according to the event signaling and reporting procedures defined in
+ MGCP.
+
+
+
+
+
+Andreasen & Foster Informational [Page 11]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+2.1.1.2 Analog Line
+
+ Analog lines can be used either as a "client" interface, providing
+ service to a classic telephone unit, or as a "service" interface,
+ allowing the gateway to send and receive analog calls. When the
+ media gateway also supports a NAS service, the gateway shall be
+ capable of receiving audio-encoded data (modem connection) and
+ convert them into data packets.
+
+ +-------
+ +---------------+|
+ (line) ===|analog endpoint| -------- Connections
+ +---------------+|
+ +-------
+
+ Media gateways should be able to establish several connections
+ between the endpoint and the packet networks, or between the endpoint
+ and other endpoints in the same gateway. The audio signals
+ originating from these connections shall be mixed according to the
+ connection "mode", as specified later in this document. The precise
+ number of connections that an endpoint supports is a characteristic
+ of the gateway, and may in fact vary according to the allocation of
+ resources within the gateway. A typical gateway should however be
+ able to support two or three connections per endpoint, in order to
+ support services such as "call waiting" or "three way calling".
+
+2.1.1.3 Announcement Server Access Point
+
+ An announcement server endpoint provides access to an announcement
+ service. Under requests from the Call Agent, the announcement server
+ will "play" a specified announcement. The requests from the Call
+ Agent will follow the event signaling and reporting procedures
+ defined in MGCP.
+
+ +----------------------+
+ | Announcement endpoint| -------- Connection
+ +----------------------+
+
+ A given announcement endpoint is not expected to support more than
+ one connection at a time. If several connections were established to
+ the same endpoint, then the same announcements would be played
+ simultaneously over all the connections.
+
+ Connections to an announcement server are typically one way, or "half
+ duplex" -- the announcement server is not expected to listen to the
+ audio signals from the connection.
+
+
+
+
+
+Andreasen & Foster Informational [Page 12]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+2.1.1.4 Interactive Voice Response Access Point
+
+ An Interactive Voice Response (IVR) endpoint provides access to an
+ IVR service. Under requests from the Call Agent, the IVR server will
+ "play" announcements and tones, and will "listen" to responses, such
+ as DTMF input or voice messages, from the user. The requests from
+ the Call Agent will follow the event signaling and reporting
+ procedures defined in MGCP.
+
+ +-------------+
+ | IVR endpoint| -------- Connection
+ +-------------+
+
+ A given IVR endpoint is not expected to support more than one
+ connection at a time. If several connections were established to the
+ same endpoint, then the same tones and announcements would be played
+ simultaneously over all the connections.
+
+2.1.1.5 Conference Bridge Access Point
+
+ A conference bridge endpoint is used to provide access to a specific
+ conference.
+
+ +-------
+ +--------------------------+|
+ |Conference bridge endpoint| -------- Connections
+ +--------------------------+|
+ +-------
+
+ Media gateways should be able to establish several connections
+ between the endpoint and the packet networks, or between the endpoint
+ and other endpoints in the same gateway. The signals originating
+ from these connections shall be mixed according to the connection
+ "mode", as specified later in this document. The precise number of
+ connections that an endpoint supports is a characteristic of the
+ gateway, and may in fact vary according to the allocation of
+ resources within the gateway.
+
+2.1.1.6 Packet Relay
+
+ A packet relay endpoint is a specific form of conference bridge, that
+ typically only supports two connections. Packets relays can be found
+ in firewalls between a protected and an open network, or in
+ transcoding servers used to provide interoperation between
+ incompatible gateways, for example gateways that do not support
+ compatible compression algorithms, or gateways that operate over
+ different transmission networks such as IP and ATM.
+
+
+
+
+Andreasen & Foster Informational [Page 13]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ +-------
+ +---------------------+ |
+ |Packet relay endpoint| 2 connections
+ +---------------------+ |
+ +-------
+
+2.1.1.7 ATM "trunk side" Interface
+
+ ATM "trunk side" endpoints are typically found when one or several
+ ATM permanent virtual circuits are used as a replacement for the
+ classic "TDM" trunks linking switches. When ATM/AAL2 is used,
+ several trunks or channels are multiplexed on a single virtual
+ circuit; each of these trunks correspond to a single endpoint.
+
+ +-------
+ +------------------+|
+ (channel) = |ATM trunk endpoint| -------- Connections
+ +------------------+|
+ +-------
+
+ Media gateways should be able to establish several connections
+ between the endpoint and the packet networks, or between the endpoint
+ and other endpoints in the same gateway. The signals originating
+ from these connections shall be mixed according to the connection
+ "mode", as specified later in this document. The precise number of
+ connections that an endpoint supports is a characteristic of the
+ gateway, and may in fact vary according to the allocation of
+ resources within the gateway.
+
+2.1.2 Endpoint Identifiers
+
+ Endpoint identifiers have two components that both are case-
+ insensitive:
+
+ * the domain name of the gateway that is managing the endpoint
+
+ * a local name within that gateway
+
+ Endpoint names are of the form:
+
+ local-endpoint-name@domain-name
+
+ where domain-name is an absolute domain-name as defined in RFC 1034
+ and includes a host portion, thus an example domain-name could be:
+
+ mygateway.whatever.net
+
+
+
+
+
+Andreasen & Foster Informational [Page 14]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Also, domain-name may be an IP-address of the form defined for domain
+ name in RFC 821, thus another example could be (see RFC 821 for
+ details):
+
+ [192.168.1.2]
+
+ Both IPv4 and IPv6 addresses can be specified, however use of IP
+ addresses as endpoint identifiers is generally discouraged.
+
+ Note that since the domain name portion is part of the endpoint
+ identifier, different forms or different values referring to the same
+ entity are not freely interchangeable. The most recently supplied
+ form and value MUST always be used.
+
+ The local endpoint name is case-insensitive. The syntax of the local
+ endpoint name is hierarchical, where the least specific component of
+ the name is the leftmost term, and the most specific component is the
+ rightmost term. The precise syntax depends on the type of endpoint
+ being named and MAY start with a term that identifies the endpoint
+ type. In any case, the local endpoint name MUST adhere to the
+ following naming rules:
+
+ 1) The individual terms of the naming path MUST be separated by a
+ single slash ("/", ASCII 2F hex).
+
+ 2) The individual terms are character strings composed of letters,
+ digits or other printable characters, with the exception of
+ characters used as delimiters ("/", "@"), characters used for
+ wildcarding ("*", "$") and white spaces.
+
+ 3) Wild-carding is represented either by an asterisk ("*") or a
+ dollar sign ("$") for the terms of the naming path which are to be
+ wild-carded. Thus, if the full local endpoint name is of the
+ form:
+
+ term1/term2/term3
+
+ then the entity name field looks like this depending on which
+ terms are wild-carded:
+
+ */term2/term3 if term1 is wild-carded
+ term1/*/term3 if term2 is wild-carded
+ term1/term2/* if term3 is wild-carded
+ term1/*/* if term2 and term3 are wild-carded, etc.
+
+ In each of these examples a dollar sign could have appeared
+ instead of an asterisk.
+
+
+
+
+Andreasen & Foster Informational [Page 15]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 4) A term represented by an asterisk ("*") is to be interpreted as:
+ "use ALL values of this term known within the scope of the Media
+ Gateway". Unless specified otherwise, this refers to all
+ endpoints configured for service, regardless of their actual
+ service state, i.e., in-service or out-of-service.
+
+ 5) A term represented by a dollar sign ("$") is to be interpreted as:
+ "use ANY ONE value of this term known within the scope of the
+ Media Gateway". Unless specified otherwise, this only refers to
+ endpoints that are in-service.
+
+ Furthermore, it is RECOMMENDED that Call Agents adhere to the
+ following:
+
+ * Wild-carding should only be done from the right, thus if a term is
+ wild-carded, then all terms to the right of that term should be
+ wild-carded as well.
+
+ * In cases where mixed dollar sign and asterisk wild-cards are used,
+ dollar-signs should only be used from the right, thus if a term had
+ a dollar sign wild-card, all terms to the right of that term should
+ also contain dollar sign wild-cards.
+
+ The description of a specific command may add further criteria for
+ selection within the general rules given above.
+
+ Note, that wild-cards may be applied to more than one term in which
+ case they shall be evaluated from left to right. For example, if we
+ have the endpoint names "a/1", "a/2", "b/1", and "b/2", then "$/*"
+ (which is not recommended) will evaluate to either "a/1, a/2", or
+ "b/1, b/2". However, "*/$" may evaluate to "a/1, b/1", "a/1, b/2",
+ "a/2, b/1", or "a/2, b/2". The use of mixed wild-cards in a command
+ is considered error prone and is consequently discouraged.
+
+ A local name that is composed of only a wildcard character refers to
+ either all (*) or any ($) endpoints within the media gateway.
+
+2.1.3 Calls and Connections
+
+ Connections are created on the Call Agent on each endpoint that will
+ be involved in the "call". In the classic example of a connection
+ between two "DS0" endpoints (EP1 and EP2), the Call Agents
+ controlling the endpoints will establish two connections (C1 and C2):
+
+ +---+ +---+
+ (channel1) ===|EP1|--(C1)--... ...(C2)--|EP2|===(channel2)
+ +---+ +---+
+
+
+
+
+Andreasen & Foster Informational [Page 16]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Each connection will be designated locally by an endpoint unique
+ connection identifier, and will be characterized by connection
+ attributes.
+
+ When the two endpoints are located on gateways that are managed by
+ the same Call Agent, the creation is done via the three following
+ steps:
+
+ 1) The Call Agent asks the first gateway to "create a connection" on
+ the first endpoint. The gateway allocates resources to that
+ connection, and responds to the command by providing a "session
+ description". The session description contains the information
+ necessary for a third party to send packets towards the newly
+ created connection, such as for example IP address, UDP port, and
+ codec parameters.
+
+ 2) The Call Agent then asks the second gateway to "create a
+ connection" on the second endpoint. The command carries the
+ "session description" provided by the first gateway. The gateway
+ allocates resources to that connection, and responds to the
+ command by providing its own "session description".
+
+ 3) The Call Agent then uses a "modify connection" command to provide
+ this second "session description" to the first endpoint. Once
+ this is done, communication can proceed in both directions.
+
+ When the two endpoints are located on gateways that are managed by
+ two different Call Agents, the Call Agents exchange information
+ through a Call-Agent to Call-Agent signaling protocol, e.g., SIP [7],
+ in order to synchronize the creation of the connection on the two
+ endpoints.
+
+ Once a connection has been established, the connection parameters can
+ be modified at any time by a "modify connection" command. The Call
+ Agent may for example instruct the gateway to change the codec used
+ on a connection, or to modify the IP address and UDP port to which
+ data should be sent, if a connection is "redirected".
+
+ The Call Agent removes a connection by sending a "delete connection"
+ command to the gateway. The gateway may also, under some
+ circumstances, inform a gateway that a connection could not be
+ sustained.
+
+ The following diagram provides a view of the states of a connection,
+ as seen from the gateway:
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 17]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Create connection
+ received
+ |
+ V
+ +-------------------+
+ |resource allocation|-(failed)-+
+ +-------------------+ |
+ | (connection refused)
+ (successful)
+ |
+ v
+ +----------->+
+ | |
+ | +-------------------+
+ | | remote session |
+ | | description |----------(yes)--------+
+ | | available ? | |
+ | +-------------------+ |
+ | | |
+ | (no) |
+ | | |
+ | +-----------+ +------+
+ | +--->| half open |------> Delete <-------| open |<----------+
+ | | | (wait) | Connection |(wait)| |
+ | | +-----------+ received +------+ |
+ | | | | | |
+ | | Modify Connection | Modify Connection |
+ | | received | received |
+ | | | | | |
+ | | +--------------------+ | +--------------------+ |
+ | | |assess modification | | |assess modification | |
+ | | +--------------------+ | +--------------------+ |
+ | | | | | | | |
+ | |(failed) (successful) | (failed) (successful) |
+ | | | | | | | |
+ | +<---+ | | +-------------+-------+
+ | | |
+ +<-------------------+ |
+ |
+ +-----------------+
+ | Free connection |
+ | resources. |
+ | Report. |
+ +-----------------+
+ |
+ V
+
+
+
+
+
+Andreasen & Foster Informational [Page 18]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+2.1.3.1 Names of Calls
+
+ One of the attributes of each connection is the "call identifier",
+ which as far as the MGCP protocol is concerned has little semantic
+ meaning, and is mainly retained for backwards compatibility.
+
+ Calls are identified by unique identifiers, independent of the
+ underlying platforms or agents. Call identifiers are hexadecimal
+ strings, which are created by the Call Agent. The maximum length of
+ call identifiers is 32 characters.
+
+ Call identifiers are expected to be unique within the system, or at a
+ minimum, unique within the collection of Call Agents that control the
+ same gateways. From the gateway's perspective, the Call identifier
+ is thus unique. When a Call Agent builds several connections that
+ pertain to the same call, either on the same gateway or in different
+ gateways, these connections that belong to the same call should share
+ the same call-id. This identifier can then be used by accounting or
+ management procedures, which are outside the scope of MGCP.
+
+2.1.3.2 Names of Connections
+
+ Connection identifiers are created by the gateway when it is
+ requested to create a connection. They identify the connection
+ within the context of an endpoint. Connection identifiers are
+ treated in MGCP as hexadecimal strings. The gateway MUST make sure
+ that a proper waiting period, at least 3 minutes, elapses between the
+ end of a connection that used this identifier and its use in a new
+ connection for the same endpoint (gateways MAY decide to use
+ identifiers that are unique within the context of the gateway). The
+ maximum length of a connection identifier is 32 characters.
+
+2.1.3.3 Management of Resources, Attributes of Connections
+
+ Many types of resources will be associated to a connection, such as
+ specific signal processing functions or packetization functions.
+ Generally, these resources fall in two categories:
+
+ 1) Externally visible resources, that affect the format of "the bits
+ on the network" and must be communicated to the second endpoint
+ involved in the connection.
+
+ 2) Internal resources, that determine which signal is being sent over
+ the connection and how the received signals are processed by the
+ endpoint.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 19]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The resources allocated to a connection, and more generally the
+ handling of the connection, are chosen by the gateway under
+ instructions from the Call Agent. The Call Agent will provide these
+ instructions by sending two sets of parameters to the gateway:
+
+ 1) The local directives instruct the gateway on the choice of
+ resources that should be used for a connection,
+
+ 2) When available, the "session description" provided by the other
+ end of the connection (referred to as the remote session
+ description).
+
+ The local directives specify such parameters as the mode of the
+ connection (e.g., send-only, or send-receive), preferred coding or
+ packetization methods, usage of echo cancellation or silence
+ suppression. (A detailed list can be found in the specification of
+ the LocalConnectionOptions parameter of the CreateConnection
+ command.) Depending on the parameter, the Call Agent MAY either
+ specify a value, a range of values, or no value at all. This allows
+ various implementations to implement various levels of control, from
+ a very tight control where the Call Agent specifies minute details of
+ the connection handling to a very loose control where the Call Agent
+ only specifies broad guidelines, such as the maximum bandwidth, and
+ lets the gateway choose the detailed values subject to the
+ guidelines.
+
+ Based on the value of the local directives, the gateway will
+ determine the resources to allocate to the connection. When this is
+ possible, the gateway will choose values that are in line with the
+ remote session description - but there is no absolute requirement
+ that the parameters be exactly the same.
+
+ Once the resources have been allocated, the gateway will compose a
+ "session description" that describes the way it intends to send and
+ receive packets. Note that the session description may in some cases
+ present a range of values. For example, if the gateway is ready to
+ accept one of several compression algorithms, it can provide a list
+ of these accepted algorithms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 20]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Local Directives
+ (from Call Agent 1)
+ |
+ V
+ +-------------+
+ | resource |
+ | allocation |
+ | (gateway 1) |
+ +-------------+
+ | |
+ V |
+ Local |
+ Parameters V
+ | Session
+ | Description Local Directives
+ | | (from Call Agent 2)
+ | +---> Transmission----+ |
+ | (CA to CA) | |
+ | V V
+ | +-------------+
+ | | resource |
+ | | allocation |
+ | | (gateway 2) |
+ | +-------------+
+ | | |
+ | | V
+ | | Local
+ | | Parameters
+ | Session
+ | Description
+ | +---- Transmission<---+
+ | | (CA to CA)
+ V V
+ +-------------+
+ | modification|
+ | (gateway 1) |
+ +-------------+
+ |
+ V
+ Local
+ Parameters
+
+ -- Information flow: local directives & session descriptions --
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 21]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+2.1.3.4 Special Case of Local Connections
+
+ Large gateways include a large number of endpoints which are often of
+ different types. In some networks, we may often have to set-up
+ connections between endpoints that are located within the same
+ gateway. Examples of such connections may be:
+
+ * Connecting a call to an Interactive Voice-Response unit,
+
+ * Connecting a call to a Conferencing unit,
+
+ * Routing a call from one endpoint to another, something often
+ described as a "hairpin" connection.
+
+ Local connections are much simpler to establish than network
+ connections. In most cases, the connection will be established
+ through some local interconnecting device, such as for example a TDM
+ bus.
+
+ When two endpoints are managed by the same gateway, it is possible to
+ specify the connection in a single command that conveys the names of
+ the two endpoints that will be connected. The command is essentially
+ a "Create Connection" command which includes the name of the second
+ endpoint in lieu of the "remote session description".
+
+2.1.4 Names of Call Agents and Other Entities
+
+ The media gateway control protocol has been designed to allow the
+ implementation of redundant Call Agents, for enhanced network
+ reliability. This means that there is no fixed binding between
+ entities and hardware platforms or network interfaces.
+
+ Call Agent names consist of two parts, similar to endpoint names.
+ Semantically, the local portion of the name does not exhibit any
+ internal structure. An example Call Agent name is:
+
+ ca1@ca.whatever.net
+
+ Note that both the local part and the domain name have to be
+ supplied. Nevertheless, implementations are encouraged to accept call
+ agent names consisting of only the domain name.
+
+ Reliability can be improved by using the following procedures:
+
+ * Entities such as endpoints or Call Agents are identified by their
+ domain name, not their network addresses. Several addresses can be
+
+
+
+
+
+Andreasen & Foster Informational [Page 22]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ associated with a domain name. If a command or a response cannot
+ be forwarded to one of the network addresses, implementations MUST
+ retry the transmission using another address.
+
+ * Entities MAY move to another platform. The association between a
+ logical name (domain name) and the actual platform is kept in the
+ domain name service. Call Agents and Gateways MUST keep track of
+ the time-to-live of the record they read from the DNS. They MUST
+ query the DNS to refresh the information if the time to live has
+ expired.
+
+ In addition to the indirection provided by the use of domain names
+ and the DNS, the concept of "notified entity" is central to
+ reliability and fail-over in MGCP. The "notified entity" for an
+ endpoint is the Call Agent currently controlling that endpoint. At
+ any point in time, an endpoint has one, and only one, "notified
+ entity" associated with it. The "notified entity" determines where
+ the endpoint will send commands to; when the endpoint needs to send a
+ command to the Call Agent, it MUST send the command to its current
+ "notified entity". The "notified entity" however does not determine
+ where commands can be received from; any Call Agent can send commands
+ to the endpoint. Please refer to Section 5 for the relevant security
+ considerations.
+
+ Upon startup, the "notified entity" MUST be set to a provisioned
+ value. Most commands sent by the Call Agent include the ability to
+ explicitly name the "notified entity" through the use of a
+ "NotifiedEntity" parameter. The "notified entity" will stay the same
+ until either a new "NotifiedEntity" parameter is received or the
+ endpoint does a warm or cold (power-cycle) restart.
+
+ If a "NotifiedEntity" parameter is sent with an "empty" value, the
+ "notified entity" for the endpoint will be set to empty. If the
+ "notified entity" for an endpoint is empty or has not been set
+ explicitly (neither by a command nor by provisioning), the "notified
+ entity" will then default to the source address (i.e., IP address and
+ UDP port number) of the last successful non-audit command received
+ for the endpoint. Auditing will thus not change the "notified
+ entity". Use of an empty "NotifiedEntity" parameter value is
+ strongly discouraged as it is error prone and eliminates the DNS-
+ based fail-over and reliability mechanisms.
+
+2.1.5 Digit Maps
+
+ The Call Agent can ask the gateway to collect digits dialed by the
+ user. This facility is intended to be used with residential gateways
+ to collect the numbers that a user dials; it can also be used with
+
+
+
+
+Andreasen & Foster Informational [Page 23]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ trunking gateways and access gateways alike, to collect access codes,
+ credit card numbers and other numbers requested by call control
+ services.
+
+ One procedure is for the gateway to notify the Call Agent of each
+ individual dialed digit, as soon as they are dialed. However, such a
+ procedure generates a large number of interactions. It is preferable
+ to accumulate the dialed numbers in a buffer, and to transmit them in
+ a single message.
+
+ The problem with this accumulation approach, however, is that it is
+ hard for the gateway to predict how many numbers it needs to
+ accumulate before transmission. For example, using the phone on our
+ desk, we can dial the following numbers:
+
+ ------------------------------------------------------
+ | 0 | Local operator |
+ | 00 | Long distance operator |
+ | xxxx | Local extension number |
+ | 8xxxxxxx | Local number |
+ | #xxxxxxx | Shortcut to local number at|
+ | | other corporate sites |
+ | *xx | Star services |
+ | 91xxxxxxxxxx | Long distance number |
+ | 9011 + up to 15 digits| International number |
+ ------------------------------------------------------
+
+ The solution to this problem is to have the Call Agent load the
+ gateway with a digit map that may correspond to the dial plan. This
+ digit map is expressed using a syntax derived from the Unix system
+ command, egrep. For example, the dial plan described above results
+ in the following digit map:
+
+ (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
+
+ The formal syntax of the digit map is described by the DigitMap rule
+ in the formal syntax description of the protocol (see Appendix A) -
+ support for basic digit map letters is REQUIRED while support for
+ extension digit map letters is OPTIONAL. A gateway receiving a digit
+ map with an extension digit map letter not supported SHOULD return
+ error code 537 (unknown digit map extension).
+
+ A digit map, according to this syntax, is defined either by a (case
+ insensitive) "string" or by a list of strings. Each string in the
+ list is an alternative numbering scheme, specified either as a set of
+ digits or timers, or as an expression over which the gateway will
+ attempt to find a shortest possible match. The following constructs
+ can be used in each numbering scheme:
+
+
+
+Andreasen & Foster Informational [Page 24]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * Digit: A digit from "0" to "9".
+ * Timer: The symbol "T" matching a timer expiry.
+ * DTMF: A digit, a timer, or one of the symbols "A", "B", "C",
+ "D", "#", or "*". Extensions may be defined.
+ * Wildcard: The symbol "x" which matches any digit ("0" to "9").
+ * Range: One or more DTMF symbols enclosed between square brackets
+ ("[" and "]").
+ * Subrange: Two digits separated by hyphen ("-") which matches any
+ digit between and including the two. The subrange
+ construct can only be used inside a range construct,
+ i.e., between "[" and "]".
+ * Position: A period (".") which matches an arbitrary number,
+ including zero, of occurrences of the preceding
+ construct.
+
+ A gateway that detects events to be matched against a digit map MUST
+ do the following:
+
+ 1) Add the event code as a token to the end of an internal state
+ variable for the endpoint called the "current dial string".
+
+ 2) Apply the current dial string to the digit map table, attempting a
+ match to each expression in the digit map.
+
+ 3) If the result is under-qualified (partially matches at least one
+ entry in the digit map and doesn't completely match another
+ entry), do nothing further.
+
+ If the result matches an entry, or is over-qualified (i.e., no
+ further digits could possibly produce a match), send the list of
+ accumulated events to the Call Agent. A match, in this
+ specification, can be either a "perfect match," exactly matching one
+ of the specified alternatives, or an impossible match, which occurs
+ when the dial string does not match any of the alternatives.
+ Unexpected timers, for example, can cause "impossible matches". Both
+ perfect matches and impossible matches trigger notification of the
+ accumulated digits (which may include other events - see Section
+ 2.3.3).
+
+ The following example illustrates the above. Assume we have the
+ digit map:
+
+ (xxxxxxx|x11)
+
+ and a current dial string of "41". Given the input "1" the current
+ dial string becomes "411". We have a partial match with "xxxxxxx",
+ but a complete match with "x11", and hence we send "411" to the Call
+ Agent.
+
+
+
+Andreasen & Foster Informational [Page 25]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The following digit map example is more subtle:
+
+ (0[12].|00|1[12].1|2x.#)
+
+ Given the input "0", a match will occur immediately since position
+ (".") allows for zero occurrences of the preceding construct. The
+ input "00" can thus never be produced in this digit map.
+
+ Given the input "1", only a partial match exists. The input "12" is
+ also only a partial match, however both "11" and "121" are a match.
+
+ Given the input "2", a partial match exists. A partial match also
+ exists for the input "23", "234", "2345", etc. A full match does not
+ occur here until a "#" is generated, e.g., "2345#". The input "2#"
+ would also have been a match.
+
+ Note that digit maps simply define a way of matching sequences of
+ event codes against a grammar. Although digit maps as defined here
+ are for DTMF input, extension packages can also be defined so that
+ digit maps can be used for other types of input represented by event
+ codes that adhere to the digit map syntax already defined for these
+ event codes (e.g., "1" or "T"). Where such usage is envisioned, the
+ definition of the particular event(s) SHOULD explicitly state that in
+ the package definition.
+
+ Since digit maps are not bounded in size, it is RECOMMENDED that
+ gateways support digit maps up to at least 2048 bytes per endpoint.
+
+2.1.6 Packages
+
+ MGCP is a modular and extensible protocol, however with extensibility
+ comes the need to manage, identify, and name the individual
+ extensions. This is achieved by the concept of packages, which are
+ simply well-defined groupings of extensions. For example, one
+ package may support a certain group of events and signals, e.g.,
+ off-hook and ringing, for analog access lines. Another package may
+ support another group of events and signals for analog access lines
+ or for another type of endpoint such as video. One or more packages
+ may be supported by a given endpoint.
+
+ MGCP allows the following types of extensions to be defined in a
+ package:
+
+ * BearerInformation
+
+ * LocalConnectionOptions
+
+ * ExtensionParameters
+
+
+
+Andreasen & Foster Informational [Page 26]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * ConnectionModes
+
+ * Events
+
+ * Signals
+
+ * Actions
+
+ * DigitMapLetters
+
+ * ConnectionParameters
+
+ * RestartMethods
+
+ * ReasonCodes
+
+ * Return codes
+
+ each of which will be explained in more detail below. The rules for
+ defining each of these extensions in a package are described in
+ Section 6, and the encoding and syntax are defined in Section 3 and
+ Appendix A.
+
+ With the exception of DigitMapLetters, a package defines a separate
+ name space for each type of extension by adding the package name as a
+ prefix to the extension, i.e.:
+
+ package-name/extension
+
+ Thus the package-name is followed by a slash ("/") and the name of
+ the extension.
+
+ An endpoint supporting one or more packages may define one of those
+ packages as the default package for the endpoint. Use of the package
+ name for events and signals in the default package for an endpoint is
+ OPTIONAL, however it is RECOMMENDED to always include the package
+ name. All other extensions, except DigitMapLetter, defined in the
+ package MUST include the package-name when referring to the
+ extension.
+
+ Package names are case insensitive strings of letters, hyphens and
+ digits, with the restriction that hyphens shall never be the first or
+ last character in a name. Examples of package names are "D", "T",
+ and "XYZ". Package names are not case sensitive - names such as
+ "XYZ", "xyz", and "xYz" are equal.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 27]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Package definitions will be provided in other documents and with
+ package names and extensions names registered with IANA. For more
+ details, refer to section 6.
+
+ Implementers can gain experience by using experimental packages. The
+ name of an experimental package MUST start with the two characters
+ "x-"; the IANA SHALL NOT register package names that start with these
+ characters, or the characters "x+", which are reserved. A gateway
+ that receives a command referring to an unsupported package MUST
+ return an error (error code 518 - unsupported package, is
+ RECOMMENDED).
+
+2.1.7 Events and Signals
+
+ The concept of events and signals is central to MGCP. A Call Agent
+ may ask to be notified about certain events occurring in an endpoint
+ (e.g., off-hook events) by including the name of the event in a
+ RequestedEvents parameter (in a NotificationRequest command - see
+ Section 2.3.3).
+
+ A Call Agent may also request certain signals to be applied to an
+ endpoint (e.g., dial-tone) by supplying the name of the event in a
+ SignalRequests parameter.
+
+ Events and signals are grouped in packages, within which they share
+ the same name space which we will refer to as event names in the
+ following. Event names are case insensitive strings of letters,
+ hyphens and digits, with the restriction that hyphens SHALL NOT be
+ the first or last character in a name. Some event codes may need to
+ be parameterized with additional data, which is accomplished by
+ adding the parameters between a set of parentheses. Event names are
+ not case sensitive - values such as "hu", "Hu", "HU" or "hU" are
+ equal.
+
+ Examples of event names can be "hu" (off hook or "hang-up"
+ transition), "hf" (hook-flash) or "0" (the digit zero).
+
+ The package name is OPTIONAL for events in the default package for an
+ endpoint, however it is RECOMMENDED to always include the package
+ name. If the package name is excluded from the event name, the
+ default package name for that endpoint MUST be assumed. For example,
+ for an analog access line which has the line package ("L") as a
+ default with dial-tone ("dl") as one of the events in that package,
+ the following two event names are equal:
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 28]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ L/dl
+
+ and
+
+ dl
+
+ For any other non-default packages that are associated with that
+ endpoint, (such as the generic package for an analog access
+ endpoint-type for example), the package name MUST be included with
+ the event name. Again, unconditional inclusion of the package name
+ is RECOMMENDED.
+
+ Digits, or letters, are supported in some packages, notably "DTMF".
+ Digits and letters are defined by the rules "Digit" and "Letter" in
+ the definition of digit maps. This definition refers to the digits
+ (0 to 9), to the asterisk or star ("*") and orthotrope, number or
+ pound sign ("#"), and to the letters "A", "B", "C" and "D", as well
+ as the timer indication "T". These letters can be combined in "digit
+ string" that represents the keys that a user punched on a dial. In
+ addition, the letter "X" can be used to represent all digits (0 to
+ 9). Also, extensions MAY define use of other letters. The need to
+ easily express the digit strings in earlier versions of the protocol
+ has a consequence on the form of event names:
+
+ An event name that does not denote a digit MUST always contain at
+ least one character that is neither a digit, nor one of the letters
+ A, B, C, D, T or X (such names also MUST NOT just contain the special
+ signs "*", or "#"). Event names consisting of more than one
+ character however may use any of the above.
+
+ A Call Agent may often have to ask a gateway to detect a group of
+ events. Two conventions can be used to denote such groups:
+
+ * The "*" and "all" wildcard conventions (see below) can be used to
+ detect any event belonging to a package, or a given event in many
+ packages, or any event in any package supported by the gateway.
+
+ * The regular expression Range notation can be used to detect a range
+ of digits.
+
+ The star sign (*) can be used as a wildcard instead of a package
+ name, and the keyword "all" can be used as a wildcard instead of an
+ event name:
+
+ * A name such as "foo/all" denotes all events in package "foo".
+
+ * A name such as "*/bar" denotes the event "bar" in any package
+ supported by the gateway.
+
+
+
+Andreasen & Foster Informational [Page 29]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * The name "*/all" denotes all events supported by the endpoint.
+
+ This specification purposely does not define any additional detail
+ for the "all packages" and "all events" wildcards. They provide
+ limited benefits, but introduce significant complexity along with the
+ potential for errors. Their use is consequently strongly
+ discouraged.
+
+ The Call Agent can ask a gateway to detect a set of digits or letters
+ either by individually describing those letters, or by using the
+ "range" notation defined in the syntax of digit strings. For
+ example, the Call Agent can:
+
+ * Use the letter "x" to denote" digits from 0 to 9.
+ * Use the notation "[0-9#]" to denote the digits 0 to 9 and the pound
+ sign.
+
+ The individual event codes are still defined in a package though
+ (e.g., the "DTMF" package).
+
+ Events can by default only be generated and detected on endpoints,
+ however events can be also be defined so they can be generated or
+ detected on connections rather than on the endpoint itself (see
+ Section 6.6). For example, gateways may be asked to provide a
+ ringback tone on a connection. When an event is to be applied on a
+ connection, the name of the connection MUST be added to the name of
+ the event, using an "at" sign (@) as a delimiter, as in:
+
+ G/rt@0A3F58
+
+ where "G" is the name of the package and "rt" is the name of the
+ event. Should the connection be deleted while an event or signal is
+ being detected or applied on it, that particular event detection or
+ signal generation simply stops. Depending on the signal, this may
+ generate a failure (see below).
+
+ The wildcard character "*" (star) can be used to denote "all
+ connections". When this convention is used, the gateway will
+ generate or detect the event on all the connections that are
+ connected to the endpoint. This applies to existing as well as
+ future connections created on the endpoint. An example of this
+ convention could be:
+
+ R/qa@*
+
+ where "R" is the name of the package and "qa" is the name of the
+ event.
+
+
+
+
+Andreasen & Foster Informational [Page 30]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ When processing a command using the "all connections" wildcard, the
+ "*" wildcard character applies to all current and future connections
+ on the endpoint, however it will not be expanded. If a subsequent
+ command either explicitly (e.g., by auditing) or implicitly (e.g., by
+ persistence) refers to such an event, the "*" value will be used.
+ However, when the event is actually observed, that particular
+ occurrence of the event will include the name of the specific
+ connection it occurred on.
+
+ The wildcard character "$" can be used to denote "the current
+ connection". It can only be used by the Call Agent, when the event
+ notification request is "encapsulated" within a connection creation
+ or modification command. When this convention is used, the gateway
+ will generate or detect the event on the connection that is currently
+ being created or modified. An example of this convention is:
+
+ G/rt@$
+
+ When processing a command using the "current connection" wildcard,
+ the "$" wildcard character will be expanded to the value of the
+ current connection. If a subsequent command either explicitly (e.g.,
+ by auditing) or implicitly (e.g., by persistence) refers to such an
+ event, the expanded value will be used. In other words, the "current
+ connection" wildcard is expanded once, which is at the initial
+ processing of the command in which it was explicitly included.
+
+ The connection id, or a wildcard replacement, can be used in
+ conjunction with the "all packages" and "all events" conventions. For
+ example, the notation:
+
+ */all@*
+
+ can be used to designate all events on all current and future
+ connections on the endpoint. However, as mentioned before, the use
+ of the "all packages" and "all events" wildcards are strongly
+ discouraged.
+
+ Signals are divided into different types depending on their behavior:
+
+ * On/off (OO): Once applied, these signals last until they are
+ turned off. This can only happen as the result of a reboot/restart
+ or a new SignalRequests where the signal is explicitly turned off
+ (see later). Signals of type OO are defined to be idempotent, thus
+ multiple requests to turn a given OO signal on (or off) are
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 31]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ perfectly valid and MUST NOT result in any errors. An On/Off
+ signal could be a visual message-waiting indicator (VMWI). Once
+ turned on, it MUST NOT be turned off until explicitly instructed to
+ by the Call Agent, or as a result of an endpoint restart, i.e.,
+ these signals will not turn off as a result of the detection of a
+ requested event.
+
+ * Time-out (TO): Once applied, these signals last until they are
+ either cancelled (by the occurrence of an event or by not being
+ included in a subsequent (possibly empty) list of signals), or a
+ signal-specific period of time has elapsed. A TO signal that times
+ out will generate an "operation complete" event. A TO signal could
+ be "ringback" timing out after 180 seconds. If an event occurs
+ prior to the 180 seconds, the signal will, by default, be stopped
+ (the "Keep signals active" action - see Section 2.3.3 - will
+ override this behavior). If the signal is not stopped, the signal
+ will time out, stop and generate an "operation complete" event,
+ about which the Call Agent may or may not have requested to be
+ notified. If the Call Agent has asked for the "operation complete"
+ event to be notified, the "operation complete" event sent to the
+ Call Agent SHALL include the name(s) of the signal(s) that timed
+ out (note that if parameters were passed to the signal, the
+ parameters will not be reported). If the signal was generated on a
+ connection, the name of the connection SHALL be included as
+ described above. Time-out signals have a default time-out value
+ defined for them, which MAY be altered by the provisioning process.
+ Also, the time-out period may be provided as a parameter to the
+ signal (see Section 3.2.2.4). A value of zero indicates that the
+ time-out period is infinite. A TO signal that fails after being
+ started, but before having generated an "operation complete" event
+ will generate an "operation failure" event which will include the
+ name of the signal that failed. Deletion of a connection with an
+ active TO signal will result in such a failure.
+
+ * Brief (BR): The duration of these signals is normally so short
+ that they stop on their own. If a signal stopping event occurs, or
+ a new SignalRequests is applied, a currently active BR signal will
+ not stop. However, any pending BR signals not yet applied MUST be
+ cancelled (a BR signal becomes pending if a NotificationRequest
+ includes a BR signal, and there is already an active BR signal). As
+ an example, a brief tone could be a DTMF digit. If the DTMF digit
+ "1" is currently being played, and a signal stopping event occurs,
+ the "1" would play to completion. If a request to play DTMF digit
+ "2" arrives before DTMF digit "1" finishes playing, DTMF digit "2"
+ would become pending.
+
+ Signal(s) generated on a connection MUST include the name of that
+ connection.
+
+
+
+Andreasen & Foster Informational [Page 32]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+2.2 Usage of SDP
+
+ The Call Agent uses the MGCP to provide the endpoint with the
+ description of connection parameters such as IP addresses, UDP port
+ and RTP profiles. These descriptions will follow the conventions
+ delineated in the Session Description Protocol which is now an IETF
+ proposed standard, documented in RFC 2327.
+
+2.3 Gateway Control Commands
+
+2.3.1 Overview of Commands
+
+ This section describes the commands of the MGCP. The service
+ consists of connection handling and endpoint handling commands.
+ There are currently nine commands in the protocol:
+
+ * The Call Agent can issue an EndpointConfiguration command to a
+ gateway, instructing the gateway about the coding characteristics
+ expected by the "line-side" of the endpoint.
+
+ * The Call Agent can issue a NotificationRequest command to a
+ gateway, instructing the gateway to watch for specific events such
+ as hook actions or DTMF tones on a specified endpoint.
+
+ * The gateway will then use the Notify command to inform the Call
+ Agent when the requested events occur.
+
+ * The Call Agent can use the CreateConnection command to create a
+ connection that terminates in an "endpoint" inside the gateway.
+
+ * The Call Agent can use the ModifyConnection command to change the
+ parameters associated with a previously established connection.
+
+ * The Call Agent can use the DeleteConnection command to delete an
+ existing connection. The DeleteConnection command may also be used
+ by a gateway to indicate that a connection can no longer be
+ sustained.
+
+ * The Call Agent can use the AuditEndpoint and AuditConnection
+ commands to audit the status of an "endpoint" and any connections
+ associated with it. Network management beyond the capabilities
+ provided by these commands is generally desirable. Such
+ capabilities are expected to be supported by the use of the Simple
+ Network Management Protocol (SNMP) and definition of a MIB which is
+ outside the scope of this specification.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 33]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * The Gateway can use the RestartInProgress command to notify the
+ Call Agent that a group of endpoints managed by the gateway is
+ being taken out-of-service or is being placed back in-service.
+
+ These services allow a controller (normally, the Call Agent) to
+ instruct a gateway on the creation of connections that terminate in
+ an "endpoint" attached to the gateway, and to be informed about
+ events occurring at the endpoint. An endpoint may be for example:
+
+ * A specific trunk circuit, within a trunk group terminating in a
+ gateway,
+
+ * A specific announcement handled by an announcement server.
+
+ Connections are logically grouped into "calls" (the concept of a
+ "call" has however little semantic meaning in MGCP itself). Several
+ connections, that may or may not belong to the same call, can
+ terminate in the same endpoint. Each connection is qualified by a
+ "mode" parameter, which can be set to "send only" (sendonly),
+ "receive only" (recvonly), "send/receive" (sendrecv), "conference"
+ (confrnce), "inactive" (inactive), "loopback", "continuity test"
+ (conttest), "network loop back" (netwloop) or "network continuity
+ test" (netwtest).
+
+ Media generated by the endpoint is sent on connections whose mode is
+ either "send only", "send/receive", or "conference", unless the
+ endpoint has a connection in "loopback" or "continuity test" mode.
+ However, media generated by applying a signal to a connection is
+ always sent on the connection, regardless of the mode.
+
+ The handling of the media streams received on connections is
+ determined by the mode parameters:
+
+ * Media streams received through connections in "receive",
+ "conference" or "send/receive" mode are mixed and sent to the
+ endpoint, unless the endpoint has another connection in "loopback"
+ or "continuity test" mode.
+
+ * Media streams originating from the endpoint are transmitted over
+ all the connections whose mode is "send", "conference" or
+ "send/receive", unless the endpoint has another connection in
+ "loopback" or "continuity test" mode.
+
+ * In addition to being sent to the endpoint, a media stream received
+ through a connection in "conference" mode is forwarded to all the
+ other connections whose mode is "conference". This also applies
+
+
+
+
+
+Andreasen & Foster Informational [Page 34]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ when the endpoint has a connection in "loopback" or "continuity
+ test" mode. The details of this forwarding, e.g., RTP translator
+ or mixer, is outside the scope of this document.
+
+ Note that in order to detect events on a connection, the connection
+ must by default be in one of the modes "receive", "conference",
+ "send/receive", "network loopback" or "network continuity test". The
+ event detection only applies to the incoming media. Connections in
+ "sendonly", "inactive", "loopback", or "continuity test" mode will
+ thus normally not detect any events, although requesting to do so is
+ not considered an error.
+
+ The "loopback" and "continuity test" modes are used during
+ maintenance and continuity test operations. An endpoint may have
+ more than one connection in either "loopback" or "continuity test"
+ mode. As long as there is one connection in that particular mode,
+ and no other connection on the endpoint is placed in a different
+ maintenance or test mode, the maintenance or test operation shall
+ continue undisturbed. There are two flavors of continuity test, one
+ specified by ITU and one used in the US. In the first case, the test
+ is a loopback test. The originating switch will send a tone (the go
+ tone) on the bearer circuit and expects the terminating switch to
+ loopback the tone. If the originating switch sees the same tone
+ returned (the return tone), the COT has passed. If not, the COT has
+ failed. In the second case, the go and return tones are different.
+ The originating switch sends a certain go tone. The terminating
+ switch detects the go tone, it asserts a different return tone in the
+ backwards direction. When the originating switch detects the return
+ tone, the COT is passed. If the originating switch never detects the
+ return tone, the COT has failed.
+
+ If the mode is set to "loopback", the gateway is expected to return
+ the incoming signal from the endpoint back into that same endpoint.
+ This procedure will be used, typically, for testing the continuity of
+ trunk circuits according to the ITU specifications. If the mode is
+ set to "continuity test", the gateway is informed that the other end
+ of the circuit has initiated a continuity test procedure according to
+ the GR specification (see [22]). The gateway will place the circuit
+ in the transponder mode required for dual-tone continuity tests.
+
+ If the mode is set to "network loopback", the audio signals received
+ from the connection will be echoed back on the same connection. The
+ media is not forwarded to the endpoint.
+
+ If the mode is set to "network continuity test", the gateway will
+ process the packets received from the connection according to the
+ transponder mode required for dual-tone continuity test, and send the
+ processed signal back on the connection. The media is not forwarded
+
+
+
+Andreasen & Foster Informational [Page 35]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ to the endpoint. The "network continuity test" mode is included for
+ backwards compatibility only and use of it is discouraged.
+
+2.3.2 EndpointConfiguration
+
+ The EndpointConfiguration command can be used to specify the encoding
+ of the signals that will be received by the endpoint. For example,
+ in certain international telephony configurations, some calls will
+ carry mu-law encoded audio signals, while others will use A-law. The
+ Call Agent can use the EndpointConfiguration command to pass this
+ information to the gateway. The configuration may vary on a call by
+ call basis, but can also be used in the absence of any connection.
+
+ ReturnCode,
+ [PackageList]
+ <-- EndpointConfiguration(EndpointId,
+ [BearerInformation])
+
+ EndpointId is the name of the endpoint(s) in the gateway where
+ EndpointConfiguration executes. The "any of" wildcard convention
+ MUST NOT be used. If the "all of" wildcard convention is used, the
+ command applies to all the endpoints whose name matches the wildcard.
+
+ BearerInformation is a parameter defining the coding of the data sent
+ to and received from the line side. The information is encoded as a
+ list of sub-parameters. The only sub-parameter defined in this
+ version of the specification is the bearer encoding, whose value can
+ be set to "A-law" or "mu-law". The set of sub-parameters may be
+ extended.
+
+ In order to allow for extensibility, while remaining backwards
+ compatible, the BearerInformation parameter is conditionally optional
+ based on the following conditions:
+
+ * if Extension Parameters (vendor, package or other) are not used,
+ the BearerInformation parameter is REQUIRED,
+
+ * otherwise, the BearerInformation parameter is OPTIONAL.
+
+ When omitted, BearerInformation MUST retain its current value.
+
+ ReturnCode is a parameter returned by the gateway. It indicates the
+ outcome of the command and consists of an integer number optionally
+ followed by commentary.
+
+ PackageList is a list of supported packages that MAY be included with
+ error code 518 (unsupported package).
+
+
+
+
+Andreasen & Foster Informational [Page 36]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+2.3.3 NotificationRequest
+
+ The NotificationRequest command is used to request the gateway to
+ send notifications upon the occurrence of specified events in an
+ endpoint. For example, a notification may be requested for when a
+ gateway detects that an endpoint is receiving tones associated with
+ fax communication. The entity receiving this notification may then
+ decide to specify use of a different type of encoding method in the
+ connections bound to this endpoint and instruct the gateway
+ accordingly with a ModifyConnection Command.
+
+ ReturnCode,
+ [PackageList]
+ <-- NotificationRequest(EndpointId,
+ [NotifiedEntity,]
+ [RequestedEvents,]
+ RequestIdentifier,
+ [DigitMap,]
+ [SignalRequests,]
+ [QuarantineHandling,]
+ [DetectEvents,]
+ [encapsulated EndpointConfiguration])
+
+ EndpointId is the identifier for the endpoint(s) in the the gateway
+ where the NotificationRequest executes. The "any of" wildcard MUST
+ NOT be used.
+
+ NotifiedEntity is an optional parameter that specifies a new
+ "notified entity" for the endpoint.
+
+ RequestIdentifier is used to correlate this request with the
+ notifications that it triggers. It will be repeated in the
+ corresponding Notify command.
+
+ RequestedEvents is a list of events, possibly qualified by event
+ parameters (see Section 3.2.2.4), that the gateway is requested to
+ detect and report. Such events may include, for example, fax tones,
+ continuity tones, or on-hook transition. Unless otherwise specified,
+ events are detected on the endpoint, however some events can be
+ detected on a connection. A given event MUST NOT appear more than
+ once in a RequestedEvents. If the parameter is omitted, it defaults
+ to empty.
+
+ To each event is associated one or more actions, which can be:
+
+ * Notify the event immediately, together with the accumulated list of
+ observed events,
+
+
+
+
+Andreasen & Foster Informational [Page 37]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * Swap audio,
+
+ * Accumulate the event in an event buffer, but don't notify yet,
+
+ * Accumulate according to Digit Map,
+
+ * Keep Signal(s) active,
+
+ * Process the Embedded Notification Request,
+
+ * Ignore the event.
+
+ Support for Notify, Accumulate, Keep Signal(s) Active, Embedded
+ Notification Request, and Ignore is REQUIRED. Support for Accumulate
+ according to Digit Map is REQUIRED on any endpoint capable of
+ detecting DTMF. Support for any other action is OPTIONAL. The set
+ of actions can be extended.
+
+ A given action can by default be specified for any event, although
+ some actions will not make sense for all events. For example, an
+ off-hook event with the Accumulate according to Digit Map action is
+ valid, but will of course immediately trigger a digit map mismatch
+ when the off-hook event occurs. Needless to say, such practice is
+ discouraged.
+
+ Some actions can be combined as shown in the table below, where "Y"
+ means the two actions can be combined, and "N" means they cannot:
+
+ --------------------------------------------------------------
+ | | Notif | Swap | Accum | AccDi | KeSiA | EmbNo | Ignor |
+ |--------------------------------------------------------------|
+ | Notif | N | Y | N | N | Y | Y* | N |
+ | Swap | - | N | Y | N | N | N | Y |
+ | Accum | - | - | N | N | Y | Y | N |
+ | AccDi | - | - | - | N | Y | N | N |
+ | KeSiA | - | - | - | - | N | Y | Y |
+ | EmbNo | - | - | - | - | - | N | N |
+ | Ignor | - | - | - | - | - | - | N |
+ --------------------------------------------------------------
+
+ Note (*): The "Embedded Notification Request" can only be
+ combined with "Notify", if the gateway is allowed to issue more
+ than one Notify command per Notification request (see below and
+ Section 4.4.1).
+
+ If no action is specified, the Notify action will be applied. If one
+ or more actions are specified, only those actions apply. When two or
+ more actions are specified, each action MUST be combinable with all
+
+
+
+Andreasen & Foster Informational [Page 38]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ the other actions as defined by the table above - the individual
+ actions are assumed to occur simultaneously.
+
+ If a client receives a request with an invalid or unsupported action
+ or an illegal combination of actions, it MUST return an error to the
+ Call Agent (error code 523 - unknown or illegal combination of
+ actions, is RECOMMENDED).
+
+ In addition to the RequestedEvents parameter specified in the
+ command, some MGCP packages may contain "persistent events" (this is
+ generally discouraged though - see Appendix B for an alternative).
+ Persistent events in a given package are always detected on an
+ endpoint that implements that package. If a persistent event is not
+ included in the list of RequestedEvents, and the event occurs, the
+ event will be detected anyway and processed like all other events, as
+ if the persistent event had been requested with a Notify action. A
+ NotificationRequest MUST still be in place for a persistent event to
+ trigger a Notify though. Thus, informally, persistent events can be
+ viewed as always being implicitly included in the list of
+ RequestedEvents with an action to Notify, although no glare
+ detection, etc., will be performed.
+
+ Non-persistent events are those events that need to be explicitly
+ included in the RequestedEvents list. The (possibly empty) list of
+ requested events completely replaces the previous list of requested
+ events. In addition to the persistent events, only the events
+ specified in the requested events list will be detected by the
+ endpoint. If a persistent event is included in the RequestedEvents
+ list, the action specified will replace the default action associated
+ with the event for the life of the RequestedEvents list, after which
+ the default action is restored. For example, if "off-hook"was a
+ persistent event, the "Ignore off-hook" action was specified, and a
+ new request without any off-hook instructions were received, the
+ default "Notify off-hook" operation would be restored.
+
+ The gateway will detect the union of the persistent events and the
+ requested events. If an event is not included in either list, it
+ will be ignored.
+
+ The Call Agent can send a NotificationRequest with an empty (or
+ omitted) RequestedEvents list to the gateway. The Call Agent can do
+ so, for example, to a gateway when it does not want to collect any
+ more DTMF digits. However, persistent events will still be detected
+ and notified.
+
+ The Swap Audio action can be used when a gateway handles more than
+ one connection on an endpoint. This will be the case for call
+ waiting, and possibly other feature scenarios. In order to avoid the
+
+
+
+Andreasen & Foster Informational [Page 39]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ round-trip to the Call Agent when just changing which connection is
+ attached to the audio functions of the endpoint, the
+ NotificationRequest can map an event (usually hook flash, but could
+ be some other event) to a local swap audio function, which selects
+ the "next" connection in a round robin fashion. If there is only one
+ connection, this action is effectively a no-op. If there are more
+ than two connections, the order is undefined. If the endpoint has
+ exactly two connections, one of which is "inactive", the other of
+ which is in "send/receive" mode, then swap audio will attempt to make
+ the "send/receive" connection "inactive", and vice versa. This
+ specification intentionally does not provide any additional detail on
+ the swap audio action.
+
+ If signal(s) are desired to start when an event being looked for
+ occurs, the "Embedded NotificationRequest" action can be used. The
+ embedded NotificationRequest may include a new list of
+ RequestedEvents, SignalRequests and a new digit map as well. The
+ semantics of the embedded NotificationRequest is as if a new
+ NotificationRequest was just received with the same NotifiedEntity,
+ RequestIdentifier, QuarantineHandling and DetectEvents. When the
+ "Embedded NotificationRequest" is activated, the "current dial
+ string" will be cleared; however the list of observed events and the
+ quarantine buffer will be unaffected (if combined with a Notify, the
+ Notify will clear the list of observed events though - see Section
+ 4.4.1). Note, that the Embedded NotificationRequest action does not
+ accumulate the triggering event, however it can be combined with the
+ Accumulate action to achieve that. If the Embedded
+ NotificationRequest fails, an Embedded NotificationRequest failure
+ event SHOULD be generated (see Appendix B).
+
+ MGCP implementations SHALL be able to support at least one level of
+ embedding. An embedded NotificationRequest that respects this
+ limitation MUST NOT contain another Embedded NotificationRequest.
+
+ DigitMap is an optional parameter that allows the Call Agent to
+ provision the endpoint with a digit map according to which digits
+ will be accumulated. If this optional parameter is absent, the
+ previously defined value is retained. This parameter MUST be
+ defined, either explicitly or through a previous command, if the
+ RequestedEvents parameter contains a request to "accumulate according
+ to the digit map". The collection of these digits will result in a
+ digit string. The digit string is initialized to a null string upon
+ reception of the NotificationRequest, so that a subsequent
+ notification only returns the digits that were collected after this
+ request. Digits that were accumulated according to the digit map are
+ reported as any other accumulated event, in the order in which they
+ occur. It is therefore possible that other events accumulated are
+
+
+
+
+Andreasen & Foster Informational [Page 40]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ found in between the list of digits. If the gateway is requested to
+ "accumulate according to digit map" and the gateway currently does
+ not have a digit map for the endpoint in question, the gateway MUST
+ return an error (error code 519 - endpoint does not have a digit map,
+ is RECOMMENDED).
+
+ SignalRequests is an optional parameter that contains the set of
+ signals that the gateway is asked to apply. When omitted, it
+ defaults to empty. When multiple signals are specified, the signals
+ MUST be applied in parallel. Unless otherwise specified, signals are
+ applied to the endpoint. However some signals can be applied to a
+ connection. Signals are identified by their name, which is an event
+ name, and may be qualified by signal parameters (see Section
+ 3.2.2.4). The following are examples of signals:
+
+ * Ringing,
+
+ * Busy tone,
+
+ * Call waiting tone,
+
+ * Off hook warning tone,
+
+ * Ringback tones on a connection.
+
+ Names and descriptions of signals are defined in the appropriate
+ package.
+
+ Signals are, by default, applied to endpoints. If a signal applied
+ to an endpoint results in the generation of a media stream (audio,
+ video, etc.), then by default the media stream MUST NOT be forwarded
+ on any connection associated with that endpoint, regardless of the
+ mode of the connection. For example, if a call-waiting tone is
+ applied to an endpoint involved in an active call, only the party
+ using the endpoint in question will hear the call-waiting tone.
+ However, individual signals may define a different behavior.
+
+ When a signal is applied to a connection that has received a
+ RemoteConnectionDescriptor, the media stream generated by that signal
+ will be forwarded on the connection regardless of the current mode of
+ the connection (including loopback and continuity test). If a
+ RemoteConnectionDescriptor has not been received, the gateway MUST
+ return an error (error code 527 - missing RemoteConnectionDescriptor,
+ is RECOMMENDED). Note that this restriction does not apply to
+ detecting events on a connection.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 41]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ When a (possibly empty) list of signal(s) is supplied, this list
+ completely replaces the current list of active time-out signals.
+ Currently active time-out signals that are not provided in the new
+ list MUST be stopped and the new signal(s) provided will now become
+ active. Currently active time-out signals that are provided in the
+ new list of signals MUST remain active without interruption, thus the
+ timer for such time-out signals will not be affected. Consequently,
+ there is currently no way to restart the timer for a currently active
+ time-out signal without turning the signal off first. If the time-
+ out signal is parameterized, the original set of parameters MUST
+ remain in effect, regardless of what values are provided
+ subsequently. A given signal MUST NOT appear more than once in a
+ SignalRequests. Note that applying a signal S to an endpoint,
+ connection C1 and connection C2, constitutes three different and
+ independent signals.
+
+ The action triggered by the SignalRequests is synchronized with the
+ collection of events specified in the RequestedEvents parameter. For
+ example, if the NotificationRequest mandates "ringing" and the
+ RequestedEvents asks to look for an "off-hook" event, the ringing
+ SHALL stop as soon as the gateway detects an off-hook event. The
+ formal definition is that the generation of all "Time Out" signals
+ SHALL stop as soon as one of the requested events is detected, unless
+ the "Keep signals active" action is associated to the detected event.
+ The RequestedEvents and SignalRequests may refer to the same event
+ definitions. In one case, the gateway is asked to detect the
+ occurrence of the event, and in the other case it is asked to
+ generate it. The specific events and signals that a given endpoint
+ can detect or perform are determined by the list of packages that are
+ supported by that endpoint. Each package specifies a list of events
+ and signals that can be detected or performed. A gateway that is
+ requested to detect or perform an event belonging to a package that
+ is not supported by the specified endpoint MUST return an error
+ (error code 518 - unsupported or unknown package, is RECOMMENDED).
+ When the event name is not qualified by a package name, the default
+ package name for the endpoint is assumed. If the event name is not
+ registered in this default package, the gateway MUST return an error
+ (error code 522 - no such event or signal, is RECOMMENDED).
+
+ The Call Agent can send a NotificationRequest whose requested signal
+ list is empty. It will do so for example when a time-out signal(s)
+ should stop.
+
+ If signal(s) are desired to start as soon as a "looked-for" event
+ occurs, the "Embedded NotificationRequest" action can be used. The
+ embedded NotificationRequest may include a new list of
+ RequestedEvents, SignalRequests and a new Digit Map as well. The
+ embedded NotificationRequest action allows the Call Agent to set up a
+
+
+
+Andreasen & Foster Informational [Page 42]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ "mini-script" to be processed by the gateway immediately following
+ the detection of the associated event. Any SignalRequests specified
+ in the embedded NotificationRequest will start immediately.
+ Considerable care must be taken to prevent discrepancies between the
+ Call Agent and the gateway. However, long-term discrepancies should
+ not occur as a new SignalRequests completely replaces the old list of
+ active time-out signals, and BR-type signals always stop on their
+ own. Limiting the number of On/Off-type signals is encouraged. It
+ is considered good practice for a Call Agent to occasionally turn on
+ all On/Off signals that should be on, and turn off all On/Off signals
+ that should be off.
+
+ The Ignore action can be used to ignore an event, e.g., to prevent a
+ persistent event from being notified. However, the synchronization
+ between the event and an active time-out signal will still occur by
+ default (e.g., a time-out dial-tone signal will stop when an off-hook
+ occurs even if off-hook was a requested event with action "Ignore").
+ To prevent this synchronization from happening, the "Keep Signal(s)
+ Active" action will have to be specified as well.
+
+ The optional QuarantineHandling parameter specifies the handling of
+ "quarantine" events, i.e., events that have been detected by the
+ gateway before the arrival of this NotificationRequest command, but
+ have not yet been notified to the Call Agent. The parameter provides
+ a set of handling options (see Section 4.4.1 for details):
+
+ * whether the quarantined events should be processed or discarded
+ (the default is to process them).
+
+ * whether the gateway is expected to generate at most one
+ notification (step by step), or multiple notifications (loop), in
+ response to this request (the default is at most one).
+
+ When the parameter is absent, the default value is assumed.
+
+ We should note that the quarantine-handling parameter also governs
+ the handling of events that were detected and processed but not yet
+ notified when the command is received.
+
+ DetectEvents is an optional parameter, possibly qualified by event
+ parameters, that specifies a list of events that the gateway is
+ requested to detect during the quarantine period. When this
+ parameter is absent, the events to be detected in the quarantine
+ period are those listed in the last received DetectEvents list. In
+ addition, the gateway will also detect persistent events and the
+ events specified in the RequestedEvents list, including those for
+ which the "ignore" action is specified.
+
+
+
+
+Andreasen & Foster Informational [Page 43]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Some events and signals, such as the in-line ringback or the quality
+ alert, are performed or detected on connections terminating in the
+ endpoint rather than on the endpoint itself. The structure of the
+ event names (see Section 2.1.7) allows the Call Agent to specify the
+ connection(s) on which the events should be performed or detected.
+
+ The NotificationRequest command may carry an encapsulated
+ EndpointConfiguration command, that will apply to the same
+ endpoint(s). When this command is present, the parameters of the
+ EndpointConfiguration command are included with the normal parameters
+ of the NotificationRequest, with the exception of the EndpointId,
+ which is not replicated.
+
+ The encapsulated EndpointConfiguration command shares the fate of the
+ NotificationRequest command. If the NotificationRequest is rejected,
+ the EndpointConfiguration is not executed.
+
+ ReturnCode is a parameter returned by the gateway. It indicates the
+ outcome of the command and consists of an integer number optionally
+ followed by commentary.
+
+ PackageList is a list of supported packages that MAY be included with
+ error code 518 (unsupported package).
+
+2.3.4 Notify
+
+ Notifications with the observed events are sent by the gateway via
+ the Notify command when a triggering event occurs.
+
+ ReturnCode,
+ [PackageList]
+ <-- Notify(EndpointId,
+ [NotifiedEntity,]
+ RequestIdentifier,
+ ObservedEvents)
+
+ EndpointId is the name for the endpoint in the gateway which is
+ issuing the Notify command. The identifier MUST be a fully qualified
+ endpoint identifier, including the domain name of the gateway. The
+ local part of the name MUST NOT use any of the wildcard conventions.
+
+ NotifiedEntity is a parameter that identifies the entity which
+ requested the notification. This parameter is equal to the
+ NotifiedEntity parameter of the NotificationRequest that triggered
+ this notification. The parameter is absent if there was no such
+ parameter in the triggering request. Regardless of the value of the
+ NotifiedEntity parameter, the notification MUST be sent to the
+ current "notified entity" for the endpoint.
+
+
+
+Andreasen & Foster Informational [Page 44]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ RequestIdentifier is a parameter that repeats the RequestIdentifier
+ parameter of the NotificationRequest that triggered this
+ notification. It is used to correlate this notification with the
+ request that triggered it. Persistent events will be viewed here as
+ if they had been included in the last NotificationRequest. An
+ implicit NotificationRequest MAY be in place right after restart -
+ the RequestIdentifier used for it will be zero ("0") - see Section
+ 4.4.1 for details.
+
+ ObservedEvents is a list of events that the gateway detected and
+ accumulated. A single notification may report a list of events that
+ will be reported in the order in which they were detected (FIFO).
+
+ The list will only contain the identification of events that were
+ requested in the RequestedEvents parameter of the triggering
+ NotificationRequest. It will contain the events that were either
+ accumulated (but not notified) or treated according to digit map (but
+ no match yet), and the final event that triggered the notification or
+ provided a final match in the digit map. It should be noted that
+ digits MUST be added to the list of observed events as they are
+ accumulated, irrespective of whether they are accumulated according
+ to the digit map or not. For example, if a user enters the digits
+ "1234" and some event E is accumulated between the digits "3" and "4"
+ being entered, the list of observed events would be "1, 2, 3, E, 4".
+ Events that were detected on a connection SHALL include the name of
+ that connection as in "R/qa@0A3F58" (see Section 2.1.7).
+
+ If the list of ObservedEvents reaches the capacity of the endpoint,
+ an ObservedEvents Full event (see Appendix B) SHOULD be generated
+ (the endpoint shall ensure it has capacity to include this event in
+ the list of ObservedEvents). If the ObservedEvents Full event is not
+ used to trigger a Notify, event processing continues as before
+ (including digit map matching); however, the subsequent events will
+ not be included in the list of ObservedEvents.
+
+ ReturnCode is a parameter returned by the Call Agent. It indicates
+ the outcome of the command and consists of an integer number
+ optionally followed by commentary.
+
+ PackageList is a list of supported packages that MAY be included with
+ error code 518 (unsupported package).
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 45]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+2.3.5 CreateConnection
+
+ This command is used to create a connection between two endpoints.
+
+ ReturnCode,
+ [ConnectionId,]
+ [SpecificEndPointId,]
+ [LocalConnectionDescriptor,]
+ [SecondEndPointId,]
+ [SecondConnectionId,]
+ [PackageList]
+ <-- CreateConnection(CallId,
+ EndpointId,
+ [NotifiedEntity,]
+ [LocalConnectionOptions,]
+ Mode,
+ [{RemoteConnectionDescriptor |
+ SecondEndpointId}, ]
+ [Encapsulated NotificationRequest,]
+ [Encapsulated EndpointConfiguration])
+
+ A connection is defined by its endpoints. The input parameters in
+ CreateConnection provide the data necessary to build a gateway's
+ "view" of a connection.
+
+ CallId is a parameter that identifies the call (or session) to which
+ this connection belongs. This parameter SHOULD, at a minimum, be
+ unique within the collection of Call Agents that control the same
+ gateways. Connections that belong to the same call SHOULD share the
+ same call-id. The call-id has little semantic meaning in the
+ protocol; however it can be used to identify calls for reporting and
+ accounting purposes. It does not affect the handling of connections
+ by the gateway.
+
+ EndpointId is the identifier for the connection endpoint in the
+ gateway where CreateConnection executes. The EndpointId can be
+ fully-specified by assigning a value to the parameter EndpointId in
+ the function call or it may be under-specified by using the "any of"
+ wildcard convention. If the endpoint is underspecified, the endpoint
+ identifier SHALL be assigned by the gateway and its complete value
+ returned in the SpecificEndPointId parameter of the response. When
+ the "any of" wildcard is used, the endpoint assigned MUST be in-
+ service and MUST NOT already have any connections on it. If no such
+ endpoint is available, error code 410 (no endpoint available) SHOULD
+ be returned. The "all of" wildcard MUST NOT be used.
+
+ The NotifiedEntity is an optional parameter that specifies a new
+ "notified entity" for the endpoint.
+
+
+
+Andreasen & Foster Informational [Page 46]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ LocalConnectionOptions is an optional structure used by the Call
+ Agent to direct the handling of the connection by the gateway. The
+ fields contained in a LocalConnectionOptions structure may include
+ one or more of the following (each field MUST NOT be supplied more
+ than once):
+
+ * Codec compression algorithm: One or more codecs, listed in order
+ of preference. For interoperability, it is RECOMMENDED to support
+ G.711 mu-law encoding ("PCMU"). See Section 2.6 for details on the
+ codec selection process.
+
+ * Packetization period: A single millisecond value or a range may be
+ specified. The packetization period SHOULD NOT contradict the
+ specification of the codec compression algorithm. If a codec is
+ specified that has a frame size which is inconsistent with the
+ packetization period, and that codec is selected, the gateway is
+ authorized to use a packetization period that is consistent with
+ the frame size even if it is different from that specified. In so
+ doing, the gateway SHOULD choose a non-zero packetization period as
+ close to that specified as possible. If a packetization period is
+ not specified, the endpoint SHOULD use the default packetization
+ period(s) for the codec(s) selected.
+
+ * Bandwidth: The allowable bandwidth, i.e., payload plus any header
+ overhead from the transport layer and up, e.g., IP, UDP, and RTP.
+ The bandwidth specification SHOULD NOT contradict the specification
+ of codec compression algorithm or packetization period. If a codec
+ is specified, then the gateway is authorized to use it, even if it
+ results in the usage of a larger bandwidth than specified. Any
+ discrepancy between the bandwidth and codec specification will not
+ be reported as an error.
+
+ * Type of Service: This indicates the class of service to be used
+ for this connection. When the Type of Service is not specified,
+ the gateway SHALL use a default value of zero unless provisioned
+ otherwise.
+
+ * Usage of echo cancellation: By default, the telephony gateways
+ always perform echo cancellation on the endpoint. However, it may
+ be necessary, for some calls, to turn off these operations. The
+ echo cancellation parameter can have two values, "on" (when the
+ echo cancellation is requested) and "off" (when it is turned off).
+ The parameter is optional. If the parameter is omitted when
+ creating a connection and there are no other connections on the
+ endpoint, the endpoint SHALL apply echo cancellation initially. If
+ the parameter is omitted when creating a connection and there are
+ existing connections on the endpoint, echo cancellation is
+ unchanged. The endpoint SHOULD subsequently enable or disable echo
+
+
+
+Andreasen & Foster Informational [Page 47]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ cancellation when voiceband data is detected - see e.g., ITU-T
+ recommendation V.8, V.25, and G.168. Following termination of
+ voiceband data, the handling of echo cancellation SHALL then revert
+ to the current value of the echo cancellation parameter. It is
+ RECOMMENDED that echo cancellation handling is left to the gateway
+ rather than having this parameter specified by the Call Agent.
+
+ * Silence Suppression: The telephony gateways may perform voice
+ activity detection, and avoid sending packets during periods of
+ silence. However, it is necessary, for example for modem calls, to
+ turn off this detection. The silence suppression parameter can
+ have two values, "on" (when the detection is requested) and "off"
+ (when it is not requested). The default is "off" (unless
+ provisioned otherwise). Upon detecting voiceband data, the
+ endpoint SHOULD disable silence suppression. Following termination
+ of voiceband data, the handling of silence suppression SHALL then
+ revert to the current value of the silence suppression parameter.
+
+ * Gain Control: The telephony gateways may perform gain control on
+ the endpoint, in order to adapt the level of the signal. However,
+ it is necessary, for example for some modem calls, to turn off this
+ function. The gain control parameter may either be specified as
+ "automatic", or as an explicit number of decibels of gain. The
+ gain specified will be added to media sent out over the endpoint
+ (as opposed to the connection) and subtracted from media received
+ on the endpoint. The parameter is optional. When there are no
+ other connections on the endpoint, and the parameter is omitted,
+ the default is to not perform gain control (unless provisioned
+ otherwise), which is equivalent to specifying a gain of 0 decibels.
+ If there are other connections on the endpoint, and the parameter
+ is omitted, gain control is unchanged. Upon detecting voiceband
+ data, the endpoint SHOULD disable gain control if needed.
+ Following termination of voiceband data, the handling of gain
+ control SHALL then revert to the current value of the gain control
+ parameter. It should be noted, that handling of gain control is
+ normally best left to the gateway and hence use of this parameter
+ is NOT RECOMMENDED.
+
+ * RTP security: The Call agent can request the gateway to enable
+ encryption of the audio Packets. It does so by providing a key
+ specification, as specified in RFC 2327. By default, encryption is
+ not performed.
+
+ * Network Type: The Call Agent may instruct the gateway to prepare
+ the connection on a specified type of network. If absent, the
+ value is based on the network type of the gateway being used.
+
+
+
+
+
+Andreasen & Foster Informational [Page 48]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * Resource reservation: The Call Agent may instruct the gateway to
+ use network resource reservation for the connection. See Section
+ 2.7 for details.
+
+ The Call Agent specifies the relevant fields it cares about in the
+ command and leaves the rest to the discretion of the gateway. For
+ those of the above parameters that were not explicitly included, the
+ gateway SHOULD use the default values if possible. For a detailed
+ list of local connection options included with this specification
+ refer to section 3.2.2.10. The set of local connection options can
+ be extended.
+
+ The Mode indicates the mode of operation for this side of the
+ connection. The basic modes are "send", "receive", "send/receive",
+ "conference", "inactive", "loopback", "continuity test", "network
+ loop back" and "network continuity test". The expected handling of
+ these modes is specified in the introduction of the "Gateway Control
+ Commands", Section 2.3. Note that signals applied to a connection do
+ not follow the connection mode. Some endpoints may not be capable of
+ supporting all modes. If the command specifies a mode that the
+ endpoint does not support, an error SHALL be returned (error 517 -
+ unsupported mode, is RECOMMENDED). Also, if a connection has not yet
+ received a RemoteConnectionDescriptor, an error MUST be returned if
+ the connection is attempted to be placed in any of the modes "send
+ only", "send/receive", "conference", "network loopback", "network
+ continuity test", or if a signal (as opposed to detecting an event)
+ is to be applied to the connection (error code 527 - missing
+ RemoteConnectionDescriptor, is RECOMMENDED). The set of modes can be
+ extended.
+
+ The gateway returns a ConnectionId, that uniquely identifies the
+ connection within the endpoint, and a LocalConnectionDescriptor,
+ which is a session description that contains information about the
+ connection, e.g., IP address and port for the media, as defined in
+ SDP.
+
+ The SpecificEndPointId is an optional parameter that identifies the
+ responding endpoint. It is returned when the EndpointId argument
+ referred to an "any of" wildcard name and the command succeeded.
+ When a SpecificEndPointId is returned, the Call Agent SHALL use it as
+ the EndpointId value in successive commands referring to this
+ connection.
+
+ The SecondEndpointId can be used instead of the
+ RemoteConnectionDescriptor to establish a connection between two
+ endpoints located on the same gateway. The connection is by
+ definition a local connection. The SecondEndpointId can be fully-
+ specified by assigning a value to the parameter SecondEndpointId in
+
+
+
+Andreasen & Foster Informational [Page 49]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ the function call or it may be under-specified by using the "any of"
+ wildcard convention. If the SecondEndpointId is underspecified, the
+ second endpoint identifier will be assigned by the gateway and its
+ complete value returned in the SecondEndPointId parameter of the
+ response.
+
+ When a SecondEndpointId is specified, the command really creates two
+ connections that can be manipulated separately through
+ ModifyConnection and DeleteConnection commands. In addition to the
+ ConnectionId and LocalConnectionDescriptor for the first connection,
+ the response to the creation provides a SecondConnectionId parameter
+ that identifies the second connection. The second connection is
+ established in "send/receive" mode.
+
+ After receiving a "CreateConnection" request that did not include a
+ RemoteConnectionDescriptor parameter, a gateway is in an ambiguous
+ situation. Because it has exported a LocalConnectionDescriptor
+ parameter, it can potentially receive packets. Because it has not
+ yet received the RemoteConnectionDescriptor parameter of the other
+ gateway, it does not know whether the packets that it receives have
+ been authorized by the Call Agent. It must thus navigate between two
+ risks, i.e., clipping some important announcements or listening to
+ insane data. The behavior of the gateway is determined by the value
+ of the Mode parameter:
+
+ * If the mode was set to ReceiveOnly, the gateway MUST accept the
+ media and transmit them through the endpoint.
+
+ * If the mode was set to Inactive, Loopback, or Continuity Test, the
+ gateway MUST NOT transmit the media through to the endpoint.
+
+ Note that the mode values SendReceive, Conference, SendOnly, Network
+ Loopback and Network Continuity Test do not make sense in this
+ situation. They MUST be treated as errors, and the command MUST be
+ rejected (error code 527 - missing RemoteConnectionDescriptor, is
+ RECOMMENDED).
+
+ The command may optionally contain an encapsulated Notification
+ Request command, which applies to the EndpointId, in which case a
+ RequestIdentifier parameter MUST be present, as well as, optionally,
+ other parameters of the NotificationRequest with the exception of the
+ EndpointId, which is not replicated. The encapsulated
+ NotificationRequest is executed simultaneously with the creation of
+ the connection. For example, when the Call Agent wants to initiate a
+ call to a residential gateway, it could:
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 50]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * ask the residential gateway to prepare a connection, in order to be
+ sure that the user can start speaking as soon as the phone goes off
+ hook,
+
+ * ask the residential gateway to start ringing,
+
+ * ask the residential gateway to notify the Call Agent when the phone
+ goes off-hook.
+
+ This can be accomplished in a single CreateConnection command, by
+ also transmitting the RequestedEvents parameters for the off-hook
+ event, and the SignalRequests parameter for the ringing signal.
+
+ When these parameters are present, the creation and the
+ NotificationRequest MUST be synchronized, which means that both MUST
+ be accepted, or both MUST be refused. In our example, the
+ CreateConnection may be refused if the gateway does not have
+ sufficient resources, or cannot get adequate resources from the local
+ network access, and the off-hook NotificationRequest can be refused
+ in the glare condition, if the user is already off-hook. In this
+ example, the phone must not ring if the connection cannot be
+ established, and the connection must not be established if the user
+ is already off-hook.
+
+ The NotifiedEntity parameter, if present, defines the new "notified
+ entity" for the endpoint.
+
+ The command may carry an encapsulated EndpointConfiguration command,
+ which applies to the EndpointId. When this command is present, the
+ parameters of the EndpointConfiguration command are included with the
+ normal parameters of the CreateConnection with the exception of the
+ EndpointId, which is not replicated. The EndpointConfiguration
+ command may be encapsulated together with an encapsulated
+ NotificationRequest command. Note that both of these apply to the
+ EndpointId only.
+
+ The encapsulated EndpointConfiguration command shares the fate of the
+ CreateConnection command. If the CreateConnection is rejected, the
+ EndpointConfiguration is not executed.
+
+ ReturnCode is a parameter returned by the gateway. It indicates the
+ outcome of the command and consists of an integer number optionally
+ followed by commentary.
+
+ PackageList is a list of supported packages that MAY be included with
+ error code 518 (unsupported package).
+
+
+
+
+
+Andreasen & Foster Informational [Page 51]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+2.3.6 ModifyConnection
+
+ This command is used to modify the characteristics of a gateway's
+ "view" of a connection. This "view" of the call includes both the
+ local connection descriptor as well as the remote connection
+ descriptor.
+
+ ReturnCode,
+ [LocalConnectionDescriptor,]
+ [PackageList]
+ <-- ModifyConnection(CallId,
+ EndpointId,
+ ConnectionId,
+ [NotifiedEntity,]
+ [LocalConnectionOptions,]
+ [Mode,]
+ [RemoteConnectionDescriptor,]
+ [Encapsulated NotificationRequest,]
+ [Encapsulated EndpointConfiguration])
+
+ The parameters used are the same as in the CreateConnection command,
+ with the addition of a ConnectionId that identifies the connection
+ within the endpoint. This parameter was returned by the
+ CreateConnection command, in addition to the local connection
+ descriptor. It uniquely identifies the connection within the context
+ of the endpoint. The CallId used when the connection was created
+ MUST be included as well.
+
+ The EndpointId MUST be a fully qualified endpoint identifier. The
+ local name MUST NOT use the wildcard conventions.
+
+ The ModifyConnection command can be used to affect parameters of a
+ connection in the following ways:
+
+ * Provide information about the other end of the connection, through
+ the RemoteConnectionDescriptor. If the parameter is omitted, it
+ retains its current value.
+
+ * Activate or deactivate the connection, by changing the value of the
+ Mode parameter. This can occur at any time during the connection,
+ with arbitrary parameter values. If the parameter is omitted, it
+ retains its current value.
+
+ * Change the parameters of the connection through the
+ LocalConnectionOptions, for example by switching to a different
+ coding scheme, changing the packetization period, or modifying the
+ handling of echo cancellation. If one or more
+ LocalConnectionOptions parameters are omitted, then the gateway
+
+
+
+Andreasen & Foster Informational [Page 52]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ SHOULD refrain from changing that parameter from its current value,
+ unless another parameter necessitating such a change is explicitly
+ provided. For example, a codec change might require a change in
+ silence suppression. Note that if a RemoteConnectionDescriptor is
+ supplied, then only the LocalConnectionOptions actually supplied
+ with the ModifyConnection command will affect the codec negotiation
+ (as described in Section 2.6).
+
+ Connections can only be fully activated if the
+ RemoteConnectionDescriptor has been provided to the gateway. The
+ receive-only mode, however, can be activated without the provision of
+ this descriptor.
+
+ The command will only return a LocalConnectionDescriptor if the local
+ connection parameters, such as RTP ports, were modified. Thus, if,
+ for example, only the mode of the connection is changed, a
+ LocalConnectionDescriptor will not be returned. Note however, that
+ inclusion of LocalConnectionOptions in the command is not a
+ prerequisite for local connection parameter changes to occur. If a
+ connection parameter is omitted, e.g., silence suppression, the old
+ value of that parameter will be retained if possible. If a parameter
+ change necessitates a change in one or more unspecified parameters,
+ the gateway is free to choose suitable values for the unspecified
+ parameters that must change. This can for instance happen if the
+ packetization period was not specified. If the new codec supported
+ the old packetization period, the value of this parameter would not
+ change, as a change would not be necessary. However, if it did not
+ support the old packetization period, it would choose a suitable
+ value.
+
+ The command may optionally contain an encapsulated Notification
+ Request command, in which case a RequestIdentifier parameter MUST be
+ present, as well as, optionally, other parameters of the
+ NotificationRequest with the exception of the EndpointId, which is
+ not replicated. The encapsulated NotificationRequest is executed
+ simultaneously with the modification of the connection. For example,
+ when a connection is accepted, the calling gateway should be
+ instructed to place the circuit in send-receive mode and to stop
+ providing ringing tones. This can be accomplished in a single
+ ModifyConnection command, by also transmitting the RequestedEvents
+ parameters, for the on-hook event, and an empty SignalRequests
+ parameter, to stop the provision of ringing tones.
+
+ When these parameters are present, the modification and the
+ NotificationRequest MUST be synchronized, which means that both MUST
+ be accepted, or both MUST be refused.
+
+
+
+
+
+Andreasen & Foster Informational [Page 53]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The NotifiedEntity parameter, if present, defines the new "notified
+ entity" for the endpoint.
+
+ The command may carry an encapsulated EndpointConfiguration command,
+ that will apply to the same endpoint. When this command is present,
+ the parameters of the EndpointConfiguration command are included with
+ the normal parameters of the ModifyConnection with the exception of
+ the EndpointId, which is not replicated. The EndpointConfiguration
+ command may be encapsulated together with an encapsulated
+ NotificationRequest command.
+
+ The encapsulated EndpointConfiguration command shares the fate of the
+ ModifyConnection command. If the ModifyConnection is rejected, the
+ EndpointConfiguration is not executed.
+
+ ReturnCode is a parameter returned by the gateway. It indicates the
+ outcome of the command and consists of an integer number optionally
+ followed by commentary.
+
+ PackageList is a list of supported packages that MAY be included with
+ error code 518 (unsupported package).
+
+2.3.7 DeleteConnection (from the Call Agent)
+
+ This command is used to terminate a connection. As a side effect, it
+ collects statistics on the execution of the connection.
+
+ ReturnCode,
+ ConnectionParameters,
+ [PackageList]
+ <-- DeleteConnection(CallId,
+ EndpointId,
+ ConnectionId,
+ [NotifiedEntity,]
+ [Encapsulated NotificationRequest,]
+ [Encapsulated EndpointConfiguration])
+
+ The endpoint identifier, in this form of the DeleteConnection
+ command, SHALL be fully qualified. Wildcard conventions SHALL NOT be
+ used.
+
+ The ConnectionId identifies the connection to be deleted. The CallId
+ used when the connection was created is included as well.
+
+ The NotifiedEntity parameter, if present, defines the new "notified
+ entity" for the endpoint.
+
+
+
+
+
+Andreasen & Foster Informational [Page 54]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ In the case of IP multicast, connections can be deleted individually
+ and independently. However, in the unicast case where a connection
+ has two ends, a DeleteConnection command has to be sent to both
+ gateways involved in the connection. After the connection has been
+ deleted, media streams previously supported by the connection are no
+ longer available. Any media packets received for the old connection
+ are simply discarded and no new media packets for the stream are
+ sent.
+
+ After the connection has been deleted, any loopback that has been
+ requested for the connection must be cancelled (unless the endpoint
+ has another connection requesting loopback).
+
+ In response to the DeleteConnection command, the gateway returns a
+ list of connection parameters that describe statistics for the
+ connection.
+
+ When the connection was for an Internet media stream, these
+ parameters are:
+
+ Number of packets sent:
+
+ The total number of media packets transmitted by the sender since
+ starting transmission on this connection. In the case of RTP, the
+ count is not reset if the sender changes its synchronization
+ source identifier (SSRC, as defined in RTP), for example as a
+ result of a ModifyConnection command. The value is zero if the
+ connection was always set in "receive only" mode and no signals
+ were applied to the connection.
+
+ Number of octets sent:
+
+ The total number of payload octets (i.e., not including header or
+ padding) transmitted in media packets by the sender since starting
+ transmission on this connection. In the case of RTP, the count is
+ not reset if the sender changes its SSRC identifier, for example
+ as a result of a ModifyConnection command. The value is zero if
+ the connection was always set in "receive only" mode and no
+ signals were applied to the connection.
+
+ Number of packets received:
+
+ The total number of media packets received by the sender since
+ starting reception on this connection. In the case of RTP, the
+ count includes packets received from different SSRC, if the sender
+ used several values. The value is zero if the connection was
+ always set in "send only" mode.
+
+
+
+
+Andreasen & Foster Informational [Page 55]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Number of octets received:
+
+ The total number of payload octets (i.e., not including header,
+ e.g., RTP, or padding) transmitted in media packets by the sender
+ since starting transmission on this connection. In the case of
+ RTP, the count includes packets received from different SSRC, if
+ the sender used several values. The value is zero if the
+ connection was always set in "send only" mode.
+
+ Number of packets lost:
+
+ The total number of media packets that have been lost since the
+ beginning of reception. This number is defined to be the number
+ of packets expected less the number of packets actually received,
+ where the number of packets received includes any which are late
+ or duplicates. For RTP, the count includes packets received from
+ different SSRC, if the sender used several values. Thus packets
+ that arrive late are not counted as lost, and the loss may be
+ negative if there are duplicates. The count includes packets
+ received from different SSRC, if the sender used several values.
+ The number of packets expected is defined to be the extended last
+ sequence number received, as defined next, less the initial
+ sequence number received. The count includes packets received
+ from different SSRC, if the sender used several values. The value
+ is zero if the connection was always set in "send only" mode.
+
+ Interarrival jitter:
+
+ An estimate of the statistical variance of the media packet
+ interarrival time measured in milliseconds and expressed as an
+ unsigned integer. For RTP, the interarrival jitter J is defined
+ to be the mean deviation (smoothed absolute value) of the
+ difference D in packet spacing at the receiver compared to the
+ sender for a pair of packets. Detailed computation algorithms are
+ found in RFC 1889. The count includes packets received from
+ different SSRC, if the sender used several values. The value is
+ zero if the connection was always set in "send only" mode.
+
+ Average transmission delay:
+
+ An estimate of the network latency, expressed in milliseconds. For
+ RTP, this is the average value of the difference between the NTP
+ timestamp indicated by the senders of the RTCP messages and the
+ NTP timestamp of the receivers, measured when the messages are
+ received. The average is obtained by summing all the estimates,
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 56]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ then dividing by the number of RTCP messages that have been
+ received. When the gateway's clock is not synchronized by NTP,
+ the latency value can be computed as one half of the round trip
+ delay, as measured through RTCP. When the gateway cannot compute
+ the one way delay or the round trip delay, the parameter conveys a
+ null value.
+
+ For a detailed definition of these variables, refer to RFC 1889.
+
+ When the connection was set up over a LOCAL interconnect, the meaning
+ of these parameters is defined as follows:
+
+ Number of packets sent:
+ Not significant - MAY be omitted.
+
+ Number of octets sent:
+ The total number of payload octets transmitted over the local
+ connection.
+
+ Number of packets received:
+ Not significant - MAY be omitted.
+
+ Number of octets received:
+ The total number of payload octets received over the connection.
+
+ Number of packets lost:
+ Not significant - MAY be omitted. A value of zero is assumed.
+
+ Interarrival jitter:
+ Not significant - MAY be omitted. A value of zero is assumed.
+
+ Average transmission delay:
+ Not significant - MAY be omitted. A value of zero is assumed.
+
+ The set of connection parameters can be extended. Also, the meaning
+ may be further defined by other types of networks which MAY
+ furthermore elect to not return all, or even any, of the above
+ specified parameters.
+
+ The command may optionally contain an encapsulated Notification
+ Request command, in which case a RequestIdentifier parameter MUST be
+ present, as well as, optionally, other parameters of the
+ NotificationRequest with the exception of the EndpointId, which is
+ not replicated. The encapsulated NotificationRequest is executed
+ simultaneously with the deletion of the connection. For example,
+ when a user hang-up is notified, the gateway should be instructed to
+ delete the connection and to start looking for an off-hook event.
+
+
+
+
+Andreasen & Foster Informational [Page 57]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ This can be accomplished in a single DeleteConnection command, by
+ also transmitting the RequestedEvents parameters, for the off-hook
+ event, and an empty SignalRequests parameter.
+
+ When these parameters are present, the DeleteConnection and the
+ NotificationRequest must be synchronized, which means that both MUST
+ be accepted, or both MUST be refused.
+
+ The command may carry an encapsulated EndpointConfiguration command,
+ that will apply to the same endpoint. When this command is present,
+ the parameters of the EndpointConfiguration command are included with
+ the normal parameters of the DeleteConnection with the exception of
+ the EndpointId, which is not replicated. The EndpointConfiguration
+ command may be encapsulated together with an encapsulated
+ NotificationRequest command.
+
+ The encapsulated EndpointConfiguration command shares the fate of the
+ DeleteConnection command. If the DeleteConnection is rejected, the
+ EndpointConfiguration is not executed.
+
+ ReturnCode is a parameter returned by the gateway. It indicates the
+ outcome of the command and consists of an integer number optionally
+ followed by commentary.
+
+ PackageList is a list of supported packages that MAY be included with
+ error code 518 (unsupported package).
+
+2.3.8 DeleteConnection (from the gateway)
+
+ In some rare circumstances, a gateway may have to clear a connection,
+ for example because it has lost the resource associated with the
+ connection, or because it has detected that the endpoint no longer is
+ capable or willing to send or receive media. The gateway may then
+ terminate the connection by using a variant of the DeleteConnection
+ command:
+
+ ReturnCode,
+ [PackageList]
+ <-- DeleteConnection(CallId,
+ EndpointId,
+ ConnectionId,
+ ReasonCode,
+ Connection-parameters)
+
+ The EndpointId, in this form of the DeleteConnection command, MUST be
+ fully qualified. Wildcard conventions MUST NOT be used.
+
+
+
+
+
+Andreasen & Foster Informational [Page 58]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The ReasonCode is a text string starting with a numeric reason code
+ and optionally followed by a descriptive text string. The reason
+ code indicates the cause of the DeleteConnection. A list of reason
+ codes can be found in Section 2.5.
+
+ In addition to the call, endpoint and connection identifiers, the
+ gateway will also send the connection parameters that would have been
+ returned to the Call Agent in response to a DeleteConnection command.
+
+ ReturnCode is a parameter returned by the Call Agent. It indicates
+ the outcome of the command and consists of an integer number
+ optionally followed by commentary.
+
+ PackageList is a list of supported packages that MAY be included with
+ error code 518 (unsupported package).
+
+ Note that use of this command is generally discouraged and should
+ only be done as a last resort. If a connection can be sustained,
+ deletion of it should be left to the discretion of the Call Agent
+ which is in a far better position to make intelligent decisions in
+ this area.
+
+2.3.9 DeleteConnection (multiple connections from the Call Agent)
+
+ A variation of the DeleteConnection function can be used by the Call
+ Agent to delete multiple connections at the same time. Note that
+ encapsulating other commands with this variation of the
+ DeleteConnection command is not permitted. The command can be used
+ to delete all connections that relate to a Call for an endpoint:
+
+ ReturnCode,
+ [PackageList]
+ <-- DeleteConnection(CallId,
+ EndpointId)
+
+ The EndpointId, in this form of the DeleteConnection command, MUST
+ NOT use the "any of" wildcard. All connections for the endpoint(s)
+ with the CallId specified will be deleted. Note that the command
+ will still succeed if there were no connections with the CallId
+ specified, as long as the EndpointId was valid. However, if the
+ EndpointId is invalid, the command will fail. The command does not
+ return any individual statistics or call parameters.
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 59]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ It can also be used to delete all connections that terminate in a
+ given endpoint:
+
+ ReturnCode,
+ [PackageList]
+ <-- DeleteConnection(EndpointId)
+
+ The EndpointId, in this form of the DeleteConnection command, MUST
+ NOT use the "any of" wildcard. Again, the command succeeds even if
+ there were no connections on the endpoint(s).
+
+ Finally, Call Agents can take advantage of the hierarchical structure
+ of endpoint names to delete all the connections that belong to a
+ group of endpoints. In this case, the "local name" component of the
+ EndpointId will be specified using the "all of" wildcarding
+ convention. The "any of" convention SHALL NOT be used. For example,
+ if endpoint names are structured as the combination of a physical
+ interface name and a circuit number, as in "X35V3+A4/13", the Call
+ Agent may replace the circuit number by the "all of" wild card
+ character "*", as in "X35V3+A4/*". This "wildcard" command instructs
+ the gateway to delete all the connections that were attached to
+ circuits connected to the physical interface "X35V3+A4".
+
+ After all the connections have been deleted, any loopback that has
+ been requested for the connections MUST be cancelled by the gateway.
+
+ This command does not return any individual statistics or call
+ parameters.
+
+ ReturnCode is a parameter returned by the gateway. It indicates the
+ outcome of the command and consists of an integer number optionally
+ followed by commentary.
+
+ PackageList is a list of supported packages that MAY be included with
+ error code 518 (unsupported package).
+
+2.3.10 AuditEndpoint
+
+ The AuditEndPoint command can be used by the Call Agent to find out
+ the status of a given endpoint.
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 60]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ ReturnCode,
+ EndPointIdList,|{
+ [RequestedEvents,]
+ [QuarantineHandling,]
+ [DigitMap,]
+ [SignalRequests,]
+ [RequestIdentifier,]
+ [NotifiedEntity,]
+ [ConnectionIdentifiers,]
+ [DetectEvents,]
+ [ObservedEvents,]
+ [EventStates,]
+ [BearerInformation,]
+ [RestartMethod,]
+ [RestartDelay,]
+ [ReasonCode,]
+ [MaxMGCPDatagram,]
+ [Capabilities]}
+ [PackageList]
+ <-- AuditEndPoint(EndpointId,
+ [RequestedInfo])
+
+ The EndpointId identifies the endpoint(s) being audited. The "any
+ of" wildcard convention MUST NOT be used.
+
+ The EndpointId identifies the endpoint(s) being audited. The "all
+ of" wildcard convention can be used to start auditing of a group of
+ endpoints (regardless of their service-state). If this convention is
+ used, the gateway SHALL return the list of endpoint identifiers that
+ match the wildcard in the EndPointIdList parameter, which is simply
+ one or more SpecificEndpointIds (each supplied separately). In the
+ case where the "all of" wildcard is used, RequestedInfo SHOULD NOT be
+ included (if it is included, it MUST be ignored). Note that the use
+ of the "all of" wildcard can potentially generate a large
+ EndPointIdList. If the resulting EndPointIdList is considered too
+ large, the gateway returns an error (error code 533 - response too
+ large, is RECOMMENDED).
+
+ When a non-wildcard EndpointId is specified, the (possibly empty)
+ RequestedInfo parameter describes the information that is requested
+ for the EndpointId specified. The following endpoint info can be
+ audited with this command:
+
+ RequestedEvents, DigitMap, SignalRequests, RequestIdentifier,
+ QuarantineHandling, NotifiedEntity, ConnectionIdentifiers,
+ DetectEvents, ObservedEvents, EventStates, BearerInformation,
+ RestartMethod, RestartDelay, ReasonCode, PackageList,
+ MaxMGCPDatagram, and Capabilities.
+
+
+
+Andreasen & Foster Informational [Page 61]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The list may be extended by extension parameters. The response will
+ in turn include information about each of the items for which
+ auditing info was requested. Supported parameters with empty values
+ MUST always be returned. However, if an endpoint is queried about a
+ parameter it does not understand, the endpoint MUST NOT generate an
+ error; instead the parameter MUST be omitted from the response:
+
+ * RequestedEvents: The current value of RequestedEvents the endpoint
+ is using including the action(s) and event parameters associated
+ with each event - if no actions are included, the default action is
+ assumed. Persistent events are included in the list. If an embedded
+ NotificationRequest is active, the RequestedEvents will reflect the
+ events requested in the embedded NotificationRequest, not any
+ surrounding RequestedEvents (whether embedded or not).
+
+ * DigitMap: The digit map the endpoint is currently using. The
+ parameter will be empty if the endpoint does not have a digit map.
+
+ * SignalRequests: A list of the; Time-Out signals that are currently
+ active, On/Off signals that are currently "on" for the endpoint
+ (with or without parameter), and any pending Brief signals. Time-
+ Out signals that have timed-out, and currently playing Brief
+ signals are not included. Any signal parameters included in the
+ original SignalRequests will be included.
+
+ * RequestIdentifier: The RequestIdentifier for the last
+ NotificationRequest received by this endpoint (includes
+ NotificationRequests encapsulated in other commands). If no
+ NotificationRequest has been received since reboot/restart, the
+ value zero will be returned.
+
+ * QuarantineHandling: The QuarantineHandling for the last
+ NotificationRequest received by this endpoint. If
+ QuarantineHandling was not included, or no notification request has
+ been received, the default values will be returned.
+
+ * DetectEvents: The value of the most recently received DetectEvents
+ parameter plus any persistent events implemented by the endpoint.
+ If no DetectEvents parameter has been received, the (possibly
+ empty) list only includes persistent events.
+
+ * NotifiedEntity: The current "notified entity" for the endpoint.
+
+ * ConnectionIdentifiers: The list of ConnectionIdentifiers for all
+ connections that currently exist for the specified endpoint.
+
+ * ObservedEvents: The current list of observed events for the
+ endpoint.
+
+
+
+Andreasen & Foster Informational [Page 62]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * EventStates: For events that have auditable states associated with
+ them, the event corresponding to the state the endpoint is in,
+ e.g., off-hook if the endpoint is off-hook. Note that the
+ definition of the individual events will state if the event in
+ question has an auditable state associated with it.
+
+ * BearerInformation: The value of the last received
+ BearerInformation parameter for this endpoint (this includes the
+ case where BearerInformation was provisioned). The parameter will
+ be empty if the endpoint has not received a BearerInformation
+ parameter and a value was also not provisioned.
+
+ * RestartMethod: "restart" if the endpoint is in-service and
+ operation is normal, or if the endpoint is in the process of
+ becoming in-service (a non-zero RestartDelay will indicate the
+ latter). Otherwise, the value of the restart method parameter in
+ the last RestartInProgress command issued (or should have been
+ issued) by the endpoint. Note that a "disconnected" endpoint will
+ thus only report "disconnected" as long as it actually is
+ disconnected, and "restart" will be reported once it is no longer
+ disconnected. Similarly, "cancel-graceful" will not be reported,
+ but "graceful" might (see Section 4.4.5 for further details).
+
+ * RestartDelay: The value of the restart delay parameter if a
+ RestartInProgress command was to be issued by the endpoint at the
+ time of this response, or zero if the command would not include
+ this parameter.
+
+ * ReasonCode: The value of the ReasonCode parameter in the last
+ RestartInProgress or DeleteConnection command issued by the gateway
+ for the endpoint, or the special value 000 if the endpoint's state
+ is normal.
+
+ * PackageList: The packages supported by the endpoint including
+ package version numbers. For backwards compatibility, support for
+ the parameter is OPTIONAL although implementations with package
+ versions higher than zero SHOULD support it.
+
+ * MaxMGCPDatagram: The maximum size of an MGCP datagram in bytes
+ that can be received by the endpoint (see Section 3.5.4). The
+ value excludes any lower layer overhead. For backwards
+ compatibility, support for this parameter is OPTIONAL. The default
+ maximum MGCP datagram size SHOULD be assumed if a value is not
+ returned.
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 63]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * Capabilities: The capabilities for the endpoint similar to the
+ LocalConnectionOptions parameter and including packages and
+ connection modes. Extensions MAY be included as well. If any
+ unknown capabilities are reported, they MUST simply be ignored. If
+ there is a need to specify that some parameters, such as e.g.,
+ silence suppression, are only compatible with some codecs, then the
+ gateway MUST return several capability sets, each of which may
+ include:
+
+ - Compression Algorithm: A list of supported codecs. The rest of
+ the parameters in the capability set will apply to all codecs
+ specified in this list.
+
+ - Packetization Period: A single value or a range may be
+ specified.
+
+ - Bandwidth: A single value or a range corresponding to the range
+ for packetization periods may be specified (assuming no silence
+ suppression).
+
+ - Echo Cancellation: Whether echo cancellation is supported or not
+ for the endpoint.
+
+ - Silence Suppression: Whether silence suppression is supported or
+ not.
+
+ - Gain Control: Whether gain control is supported or not.
+
+ - Type of Service: Whether type of service is supported or not.
+
+ - Resource Reservation: Whether resource reservation is supported
+ or not.
+
+ - Security: Whether media encryption is supported or not.
+
+ - Type of network: The type(s) of network supported.
+
+ - Packages: A list of packages supported. The first package in
+ the list will be the default package.
+
+ - Modes: A list of supported connection modes.
+
+ The Call Agent may then decide to use the AuditConnection command to
+ obtain further information about the connections.
+
+ If no info was requested and the EndpointId refers to a valid
+ endpoint (in-service or not), the gateway simply returns a positive
+ acknowledgement.
+
+
+
+Andreasen & Foster Informational [Page 64]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ ReturnCode is a parameter returned by the gateway. It indicates the
+ outcome of the command and consists of an integer number optionally
+ followed by commentary.
+
+ Note that PackageList MAY also be included with error code 518
+ (unsupported package).
+
+2.3.11 AuditConnection
+
+ The AuditConnection command can be used by the Call Agent to retrieve
+ the parameters attached to a connection.
+
+ ReturnCode,
+ [CallId,]
+ [NotifiedEntity,]
+ [LocalConnectionOptions,]
+ [Mode,]
+ [RemoteConnectionDescriptor,]
+ [LocalConnectionDescriptor,]
+ [ConnectionParameters,]
+ [PackageList]
+ <-- AuditConnection(EndpointId,
+ ConnectionId,
+ RequestedInfo)
+
+ The EndpointId parameter specifies the endpoint that handles the
+ connection. The wildcard conventions SHALL NOT be used.
+
+ The ConnectionId parameter is the identifier of the audited
+ connection, within the context of the specified endpoint.
+
+ The (possibly empty) RequestedInfo describes the information that is
+ requested for the ConnectionId within the EndpointId specified. The
+ following connection info can be audited with this command:
+
+ CallId, NotifiedEntity, LocalConnectionOptions, Mode,
+ RemoteConnectionDescriptor, LocalConnectionDescriptor,
+ ConnectionParameters
+
+ The AuditConnection response will in turn include information about
+ each of the items auditing info was requested for:
+
+ * CallId, the CallId for the call the connection belongs to.
+
+ * NotifiedEntity, the current "notified entity" for the Connection.
+ Note this is the same as the "notified entity" for the endpoint
+ (included here for backwards compatibility).
+
+
+
+
+Andreasen & Foster Informational [Page 65]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * LocalConnectionOptions, the most recent LocalConnectionOptions
+ parameters that was actually supplied for the connection (omitting
+ LocalConnectionOptions from a command thus does not change this
+ value). Note that default parameters omitted from the most recent
+ LocalConnectionOptions will not be included.
+ LocalConnectionOptions that retain their value across
+ ModifyConnection commands and which have been included in a
+ previous command for the connection are also included, regardless
+ of whether they were supplied in the most recent
+ LocalConnectionOptions or not.
+
+ * Mode, the current mode of the connection.
+
+ * RemoteConnectionDescriptor, the RemoteConnectionDescriptor that was
+ supplied to the gateway for the connection.
+
+ * LocalConnectionDescriptor, the LocalConnectionDescriptor the
+ gateway supplied for the connection.
+
+ * ConnectionParameters, the current values of the connection
+ parameters for the connection.
+
+ If no info was requested and the EndpointId is valid, the gateway
+ simply checks that the connection exists, and if so returns a
+ positive acknowledgement. Note, that by definition, the endpoint
+ must be in-service for this to happen, as out-of-service endpoints do
+ not have any connections.
+
+ ReturnCode is a parameter returned by the gateway. It indicates the
+ outcome of the command and consists of an integer number optionally
+ followed by commentary.
+
+ PackageList is a list of supported packages that MAY be included with
+ error code 518 (unsupported package).
+
+2.3.12 RestartInProgress
+
+ The RestartInProgress command is used by the gateway to signal that
+ an endpoint, or a group of endpoints, is put in-service or out-of-
+ service.
+
+ ReturnCode,
+ [NotifiedEntity,]
+ [PackageList]
+ <-- RestartInProgress(EndPointId,
+ RestartMethod,
+ [RestartDelay,]
+ [ReasonCode])
+
+
+
+Andreasen & Foster Informational [Page 66]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The EndPointId identifies the endpoint(s) that are put in-service or
+ out-of-service. The "all of" wildcard convention may be used to
+ apply the command to a group of endpoints managed by the same Call
+ Agent, such as for example all endpoints that are attached to a
+ specified interface, or even all endpoints that are attached to a
+ given gateway. The "any of" wildcard convention SHALL NOT be used.
+
+ The RestartMethod parameter specifies the type of restart. The
+ following values have been defined:
+
+ * A "graceful" restart method indicates that the specified endpoints
+ will be taken out-of-service after the specified delay. The
+ established connections are not yet affected, but the Call Agent
+ SHOULD refrain from establishing new connections, and SHOULD try to
+ gracefully tear down the existing connections.
+
+ * A "forced" restart method indicates that the specified endpoints
+ are taken abruptly out-of-service. The established connections, if
+ any, are lost.
+
+ * A "restart" method indicates that service will be restored on the
+ endpoints after the specified "restart delay", i.e., the endpoints
+ will be in-service. The endpoints are in their clean default state
+ and there are no connections that are currently established on the
+ endpoints.
+
+ * A "disconnected" method indicates that the endpoint has become
+ disconnected and is now trying to establish connectivity (see
+ Section 4.4.7). The "restart delay" specifies the number of
+ seconds the endpoint has been disconnected. Established
+ connections are not affected.
+
+ * A "cancel-graceful" method indicates that a gateway is canceling a
+ previously issued "graceful" restart command. The endpoints are
+ still in-service.
+
+ The list of restart methods may be extended.
+
+ The optional "restart delay" parameter is expressed as a number of
+ seconds. If the number is absent, the delay value MUST be considered
+ null (i.e., zero). In the case of the "graceful" method, a null
+ delay indicates that the Call Agent SHOULD simply wait for the
+ natural termination of the existing connections, without establishing
+ new connections. The restart delay is always considered null in the
+ case of the "forced" and "cancel-graceful" methods, and hence the
+ "restart delay" parameter MUST NOT be used with these restart
+ methods. When the gateway sends a "restart" or "graceful"
+
+
+
+
+Andreasen & Foster Informational [Page 67]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ RestartInProgress message with a non-zero restart delay, the gateway
+ SHOULD send an updated RestartInProgress message after the "restart
+ delay" has passed.
+
+ A restart delay of null for the "restart" method indicates that
+ service has already been restored. This typically will occur after
+ gateway startup/reboot. To mitigate the effects of a gateway IP
+ address change as a result of a re-boot, the Call Agent MAY wish to
+ either flush its DNS cache for the gateway's domain name or resolve
+ the gateway's domain name by querying the DNS regardless of the TTL
+ of a current DNS resource record for the restarted gateway.
+
+ The optional reason code parameter indicates the cause of the
+ restart.
+
+ Gateways SHOULD send a "graceful" or "forced" RestartInProgress
+ message (for the relevant endpoints) as a courtesy to the Call Agent
+ when they are taken out-of-service, e.g., by being shutdown, or taken
+ out-of-service by a network management system, however the Call Agent
+ cannot rely on always receiving such a message. Gateways MUST send a
+ "restart" RestartInProgress message (for the relevant endpoints) with
+ a null delay to their Call Agent when they are back in-service
+ according to the restart procedure specified in Section 4.4.6 - Call
+ Agents can rely on receiving this message. Also, gateways MUST send
+ a "disconnected" RestartInProgress message (for the relevant
+ endpoints) to their current "notified entity" according to the
+ "disconnected" procedure specified in Section 4.4.7.
+
+ The RestartInProgress message will be sent to the current "notified
+ entity" for the EndpointId in question. It is expected that a
+ default Call Agent, i.e., "notified entity", has been provisioned so
+ that after a reboot/restart, the default Call Agent will always be
+ the "notified entity" for the endpoint. Gateways SHOULD 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.
+
+ ReturnCode is a parameter returned by the Call Agent. It indicates
+ the outcome of the command and consists of an integer number
+ optionally followed by commentary.
+
+ A NotifiedEntity may additionally be returned with the response to
+ the RestartInProgress from the Call Agent - this SHOULD normally only
+ be done in response to "restart" or "disconnected" (see also Section
+ 4.4.6 and 4.4.7):
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 68]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * If the response indicated success (return code 200 - transaction
+ executed), the restart in question completed successfully, and the
+ NotifiedEntity returned is the new "notified entity" for the
+ endpoint(s).
+
+ * If the response from the Call Agent indicated an error, the restart
+ in question did not complete successfully. If a NotifiedEntity
+ parameter was included in the response returned, it specifies a new
+ "notified entity" for the endpoint(s), which MUST be used when
+ retrying the restart in question (as a new transaction). This
+ SHOULD only be done with error code 521 (endpoint redirected).
+
+ Note that the above behavior for returning a NotifiedEntity in the
+ response is only defined for RestartInProgress responses and SHOULD
+ NOT be done for responses to other commands. Any other behavior is
+ undefined.
+
+ PackageList is a list of supported packages that MAY be included with
+ error code 518 (unsupported package).
+
+2.4 Return Codes and Error Codes
+
+ All MGCP commands are acknowledged. The acknowledgment carries a
+ return code, which indicates the status of the command. The return
+ code is an integer number, for which the following ranges of values
+ have been defined:
+
+ * values between 000 and 099 indicate a response acknowledgement
+
+ * values between 100 and 199 indicate a provisional response
+
+ * values between 200 and 299 indicate a successful completion
+
+ * values between 400 and 499 indicate a transient error
+
+ * values between 500 and 599 indicate a permanent error
+
+ * values between 800 and 899 are package specific response codes.
+
+ A broad description of transient errors (4XX error codes) versus
+ permanent errors (5XX error codes) is as follows:
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 69]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * If a Call Agent receives a transient error, there is the
+ expectation of the possibility that a future similar request will
+ be honored by the endpoint. In some cases, this may require some
+ state change in the environment of the endpoint (e.g., hook state
+ as in the case of error codes 401 or 402; resource availability as
+ in the case of error code 403, or bandwidth availability as in the
+ case of error code 404).
+
+ * Permanent errors (error codes 500 to 599) indicate one or more
+ permanent conditions either due to protocol error or
+ incompatibility between the endpoint and the Call Agent, or because
+ of some error condition over which the Call Agent has no control.
+ Examples are protocol errors, requests for endpoint capabilities
+ that do not exist, errors on interfaces associated with the
+ endpoint, missing or incorrect information in the request or any
+ number of other conditions which will simply not disappear with
+ time.
+
+ The values that have been already defined are the following:
+
+ 000 Response Acknowledgement.
+
+ 100 The transaction is currently being executed. An actual
+ completion message will follow later.
+
+ 101 The transaction has been queued for execution. An actual
+ completion message will follow later.
+
+ 200 The requested transaction was executed normally. This return
+ code can be used for a successful response to any command.
+
+ 250 The connection was deleted. This return code can only be used
+ for a successful response to a DeleteConnection command.
+
+ 400 The transaction could not be executed, due to some unspecified
+ transient error.
+
+ 401 The phone is already off hook.
+
+ 402 The phone is already on hook.
+
+ 403 The transaction could not be executed, because the endpoint does
+ not have sufficient resources at this time.
+
+ 404 Insufficient bandwidth at this time.
+
+ 405 The transaction could not be executed, because the endpoint is
+ "restarting".
+
+
+
+Andreasen & Foster Informational [Page 70]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 406 Transaction time-out. The transaction did not complete in a
+ reasonable period of time and has been aborted.
+
+ 407 Transaction aborted. The transaction was aborted by some
+ external action, e.g., a ModifyConnection command aborted by a
+ DeleteConnection command.
+
+ 409 The transaction could not be executed because of internal
+ overload.
+
+ 410 No endpoint available. A valid "any of" wildcard was used,
+ however there was no endpoint available to satisfy the request.
+
+ 500 The transaction could not be executed, because the endpoint is
+ unknown.
+
+ 501 The transaction could not be executed, because the endpoint is
+ not ready. This includes the case where the endpoint is out-of-
+ service.
+
+ 502 The transaction could not be executed, because the endpoint does
+ not have sufficient resources (permanent condition).
+
+ 503 "All of" wildcard too complicated.
+
+ 504 Unknown or unsupported command.
+
+ 505 Unsupported RemoteConnectionDescriptor. This SHOULD be used when
+ one or more mandatory parameters or values in the
+ RemoteConnectionDescriptor is not supported.
+
+ 506 Unable to satisfy both LocalConnectionOptions and
+ RemoteConnectionDescriptor. This SHOULD be used when the
+ LocalConnectionOptions and RemoteConnectionDescriptor contain one
+ or more mandatory parameters or values that conflict with each
+ other and/or cannot be supported at the same time (except for
+ codec negotiation failure - see error code 534).
+
+ 507 Unsupported functionality. Some unspecified functionality
+ required to carry out the command is not supported. Note that
+ several other error codes have been defined for specific areas of
+ unsupported functionality (e.g. 508, 511, etc.), and this error
+ code SHOULD only be used if there is no other more specific error
+ code for the unsupported functionality.
+
+ 508 Unknown or unsupported quarantine handling.
+
+
+
+
+
+Andreasen & Foster Informational [Page 71]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 509 Error in RemoteConnectionDescriptor. This SHOULD be used when
+ there is a syntax or semantic error in the
+ RemoteConnectionDescriptor.
+
+ 510 The transaction could not be executed, because some unspecified
+ protocol error was detected. Automatic recovery from such an
+ error will be very difficult, and hence this code SHOULD only be
+ used as a last resort.
+
+ 511 The transaction could not be executed, because the command
+ contained an unrecognized extension. This code SHOULD be used
+ for unsupported critical parameter extensions ("X+").
+
+ 512 The transaction could not be executed, because the gateway is not
+ equipped to detect one of the requested events.
+
+ 513 The transaction could not be executed, because the gateway is not
+ equipped to generate one of the requested signals.
+
+ 514 The transaction could not be executed, because the gateway cannot
+ send the specified announcement.
+
+ 515 The transaction refers to an incorrect connection-id (may have
+ been already deleted).
+
+ 516 The transaction refers to an unknown call-id, or the call-id
+ supplied is incorrect (e.g., connection-id not associated with
+ this call-id).
+
+ 517 Unsupported or invalid mode.
+
+ 518 Unsupported or unknown package. It is RECOMMENDED to include a
+ PackageList parameter with the list of supported packages in the
+ response, especially if the response is generated by the Call
+ Agent.
+
+ 519 Endpoint does not have a digit map.
+
+ 520 The transaction could not be executed, because the endpoint is
+ "restarting". In most cases this would be a transient error, in
+ which case, error code 405 SHOULD be used instead. The error
+ code is only included here for backwards compatibility.
+
+ 521 Endpoint redirected to another Call Agent. The associated
+ redirection behavior is only well-defined when this response is
+ issued for a RestartInProgress command.
+
+
+
+
+
+Andreasen & Foster Informational [Page 72]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 522 No such event or signal. The request referred to an event or
+ signal that is not defined in the relevant package (which could
+ be the default package).
+
+ 523 Unknown action or illegal combination of actions.
+
+ 524 Internal inconsistency in LocalConnectionOptions.
+
+ 525 Unknown extension in LocalConnectionOptions. This code SHOULD be
+ used for unsupported mandatory vendor extensions ("x+").
+
+ 526 Insufficient bandwidth. In cases where this is a transient
+ error, error code 404 SHOULD be used instead.
+
+ 527 Missing RemoteConnectionDescriptor.
+
+ 528 Incompatible protocol version.
+
+ 529 Internal hardware failure.
+
+ 530 CAS signaling protocol error.
+
+ 531 Failure of a grouping of trunks (e.g., facility failure).
+
+ 532 Unsupported value(s) in LocalConnectionOptions.
+
+ 533 Response too large.
+
+ 534 Codec negotiation failure.
+
+ 535 Packetization period not supported.
+
+ 536 Unknown or unsupported RestartMethod.
+
+ 537 Unknown or unsupported digit map extension.
+
+ 538 Event/signal parameter error (e.g., missing, erroneous,
+ unsupported, unknown, etc.).
+
+ 539 Invalid or unsupported command parameter. This code SHOULD only
+ be used when the parameter is neither a package or vendor
+ extension parameter.
+
+ 540 Per endpoint connection limit exceeded.
+
+ 541 Invalid or unsupported LocalConnectionOptions. This code SHOULD
+ only be used when the LocalConnectionOptions is neither a package
+ nor a vendor extension LocalConnectionOptions.
+
+
+
+Andreasen & Foster Informational [Page 73]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The set of return codes may be extended in a future version of the
+ protocol. Implementations that receive an unknown or unsupported
+ return code SHOULD treat the return code as follows:
+
+ * Unknown 0xx code treated as 000.
+
+ * Unknown 1xx code treated as 100.
+
+ * Unknown 2xx code treated as 200.
+
+ * Unknown 3xx code treated as 521.
+
+ * Unknown 4xx code treated as 400.
+
+ * Unknown 5xx-9xx code treated as 510.
+
+2.5 Reason Codes
+
+ Reason codes are used by the gateway when deleting a connection to
+ inform the Call Agent about the reason for deleting the connection.
+ They may also be used in a RestartInProgress command to inform the
+ Call Agent of the reason for the RestartInProgress.
+
+ The reason code is an integer number, and the following values have
+ been defined:
+
+ 000 Endpoint state is normal (this code is only used in response to
+ audit requests).
+
+ 900 Endpoint malfunctioning.
+
+ 901 Endpoint taken out-of-service.
+
+ 902 Loss of lower layer connectivity (e.g., downstream sync).
+
+ 903 QoS resource reservation was lost.
+
+ 904 Manual intervention.
+
+ 905 Facility failure (e.g., DS-0 failure).
+
+ The set of reason codes can be extended.
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 74]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+2.6 Use of Local Connection Options and Connection Descriptors
+
+ As indicated previously, the normal sequence in setting up a bi-
+ directional connection involves at least 3 steps:
+
+ 1) The Call Agent asks the first gateway to "create a connection" on
+ an endpoint. The gateway allocates resources to that connection,
+ and responds to the command by providing a "session description"
+ (referred to as its LocalConnectionDescriptor). The session
+ description contains the information necessary for another party
+ to send packets towards the newly created connection.
+
+ 2) The Call Agent then asks the second gateway to "create a
+ connection" on an endpoint. The command carries the "session
+ description" provided by the first gateway (now referred to as the
+ RemoteConnectionDescriptor). The gateway allocates resources to
+ that connection, and responds to the command by providing its own
+ "session description" (LocalConnectionDescriptor).
+
+ 3) The Call Agent uses a "modify connection" command to provide this
+ second "session description" (now referred to as the
+ RemoteConnectionDescriptor ) to the first endpoint. Once this is
+ done, communication can proceed in both directions.
+
+ When the Call Agent issues a Create or Modify Connection command,
+ there are thus three parameters that determine the media supported by
+ that connection:
+
+ * LocalConnectionOptions: Supplied by the Call Agent to control the
+ media parameters used by the gateway for the connection. When
+ supplied, the gateway MUST conform to these media parameters until
+ either the connection is deleted, or a ModifyConnection command
+ with new media parameters (LocalConnectionOptions or
+ RemoteConnectionDescriptor) is received.
+
+ * RemoteConnectionDescriptor: Supplied by the Call Agent to convey
+ the media parameters supported by the other side of the connection.
+ When supplied, the gateway MUST conform to these media parameters
+ until either the connection is deleted, or a ModifyConnection
+ command with new media parameters (LocalConnectionOptions or
+ RemoteConnectionDescriptor) is received.
+
+ * LocalConnectionDescriptor: Supplied by the gateway to the Call
+ Agent to convey the media parameters it supports for the
+ connection. When supplied, the gateway MUST honor the media
+ parameters until either the connection is deleted, or the gateway
+ issues a new LocalConnectionDescriptor for that connection.
+
+
+
+
+Andreasen & Foster Informational [Page 75]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ In determining which codec(s) to provide in the
+ LocalConnectionDescriptor, there are three lists of codecs that a
+ gateway needs to consider:
+
+ * A list of codecs allowed by the LocalConnectionOptions in the
+ current command (either explicitly by encoding method or implicitly
+ by bandwidth and/or packetization period).
+
+ * A list of codecs in the RemoteConnectionDescriptor in the current
+ command.
+
+ * An internal list of codecs that the gateway can support for the
+ connection. A gateway MAY support one or more codecs for a given
+ connection.
+
+ Codec selection (including all relevant media parameters) can then be
+ described by the following steps:
+
+ 1. An approved list of codecs is formed by taking the intersection of
+ the internal list of codecs and codecs allowed by the
+ LocalConnectionOptions. If LocalConnectionOptions were not
+ provided in the current command, the approved list of codecs thus
+ contains the internal list of codecs.
+
+ 2. If the approved list of codecs is empty, a codec negotiation
+ failure has occurred and an error response is generated (error
+ code 534 - codec negotiation failure, is RECOMMENDED).
+
+ 3. Otherwise, a negotiated list of codecs is formed by taking the
+ intersection of the approved list of codecs and codecs allowed by
+ the RemoteConnectionDescriptor. If a RemoteConnectionDescriptor
+ was not provided in the current command, the negotiated list of
+ codecs thus contains the approved list of codecs.
+
+ 4. If the negotiated list of codecs is empty, a codec negotiation
+ failure has occurred and an error response is generated (error
+ code 534 - codec negotiation failure, is RECOMMENDED).
+
+ 5. Otherwise, codec negotiation has succeeded, and the negotiated
+ list of codecs is returned in the LocalConnectionDescriptor.
+
+ Note that both LocalConnectionOptions and the
+ RemoteConnectionDescriptor can contain a list of codecs ordered by
+ preference. When both are supplied in the current command, the
+ gateway MUST adhere to the preferences provided in the
+ LocalConnectionOptions.
+
+
+
+
+
+Andreasen & Foster Informational [Page 76]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+2.7 Resource Reservations
+
+ The gateways can be instructed to perform a reservation, for example
+ using RSVP, on a given connection. When a reservation is needed, the
+ call agent will specify the reservation profile to 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 of this parameter in a CreateConnection
+ command. For a ModifyConnection command, the default is simply to
+ retain the current value. When reservation has been asked on a
+ connection, the gateway will:
+
+ * 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 suitable 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.
+
+ The RSVP filters will be deduced from the characteristics of the
+ connection. The RSVP resource profiles will be deduced from the
+ connection's codecs, bandwidth and packetization period.
+
+3. Media Gateway Control Protocol
+
+ The Media Gateway Control Protocol (MGCP) implements the media
+ gateway control interface as a set of transactions. The transactions
+ are composed of a command and a mandatory response. There are nine
+ commands:
+
+ * EndpointConfiguration
+
+ * CreateConnection
+
+ * ModifyConnection
+
+ * DeleteConnection
+
+ * NotificationRequest
+
+ * Notify
+
+ * AuditEndpoint
+
+ * AuditConnection
+
+
+
+Andreasen & Foster Informational [Page 77]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * RestartInProgress
+
+ The first five commands are sent by the Call Agent to a gateway. The
+ Notify command is sent by the gateway to the Call Agent. The gateway
+ may also send a DeleteConnection as defined in Section 2.3.8. The
+ Call Agent may send either of the Audit commands to the gateway, and
+ the gateway may send a RestartInProgress command to the Call Agent.
+
+3.1 General Description
+
+ All commands are composed of a Command header, optionally followed by
+ a session description.
+
+ All responses are composed of a Response header, optionally followed
+ by session description information.
+
+ Headers and session descriptions are encoded as a set of text lines,
+ separated by a carriage return and line feed character (or,
+ optionally, a single line-feed character). The session descriptions
+ are preceded by an empty line.
+
+ MGCP uses a transaction identifier to correlate commands and
+ responses. The transaction identifier is encoded as a component of
+ the command header and repeated as a component of the response header
+ (see sections 3.2.1.2 and 3.3).
+
+ Note that an ABNF grammar for MGCP is provided in Appendix A.
+ Commands and responses SHALL be encoded in accordance with the
+ grammar, which, per RFC 2234, is case-insensitive except for the SDP
+ part. Similarly, implementations SHALL be capable of decoding
+ commands and responses that follow the grammar. Additionally, it is
+ RECOMMENDED that implementations tolerate additional linear white
+ space.
+
+ Some productions allow for use of quoted strings, which can be
+ necessary to avoid syntax problems. Where the quoted string form is
+ used, the contents will be UTF-8 encoded [20], and the actual value
+ provided is the unquoted string (UTF-8 encoded). Where both a quoted
+ and unquoted string form is allowed, either form can be used provided
+ it does not otherwise violate the grammar.
+
+ In the following, we provide additional detail on the format of MGCP
+ commands and responses.
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 78]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+3.2 Command Header
+
+ The command header is composed of:
+
+ * A command line, identifying the requested action or verb, the
+ transaction identifier, the endpoint towards which the action is
+ requested, and the MGCP protocol version,
+
+ * A set of zero or more parameter lines, composed of a parameter
+ name followed by a parameter value.
+
+ Unless otherwise noted or dictated by other referenced standards
+ (e.g., SDP), each component in the command header is case
+ insensitive. This goes for verbs as well as parameters and values,
+ and hence all comparisons MUST treat upper and lower case as well as
+ combinations of these as being equal.
+
+3.2.1 Command Line
+
+ The command line is composed of:
+
+ * The name of the requested verb,
+
+ * The identification of the transaction,
+
+ * The name of the endpoint(s) that are to execute the command (in
+ notifications or restarts, the name of the endpoint(s) that is
+ issuing the command),
+
+ * The protocol version.
+
+ These four items are encoded as strings of printable ASCII
+ characters, separated by white spaces, i.e., the ASCII space (0x20)
+ or tabulation (0x09) characters. It is RECOMMENDED to use exactly
+ one ASCII space separator. However, MGCP entities MUST be able to
+ parse messages with additional white space characters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 79]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+3.2.1.1 Coding of the Requested Verb
+
+ The verbs that can be requested are encoded as four letter upper or
+ lower case ASCII codes (comparisons SHALL be case insensitive) as
+ defined in the following table:
+
+ -----------------------------
+ | Verb | Code |
+ |----------------------|------|
+ | EndpointConfiguration| EPCF |
+ | CreateConnection | CRCX |
+ | ModifyConnection | MDCX |
+ | DeleteConnection | DLCX |
+ | NotificationRequest | RQNT |
+ | Notify | NTFY |
+ | AuditEndpoint | AUEP |
+ | AuditConnection | AUCX |
+ | RestartInProgress | RSIP |
+ -----------------------------
+
+ The transaction identifier is encoded as a string of up to 9 decimal
+ digits. In the command line, it immediately follows the coding of
+ the verb.
+
+ New verbs may be defined in further versions of the protocol. It may
+ be necessary, for experimentation purposes, to use new verbs before
+ they are sanctioned in a published version of this protocol.
+ Experimental verbs MUST be identified by a four letter code starting
+ with the letter X, such as for example XPER.
+
+3.2.1.2 Transaction Identifiers
+
+ MGCP uses a transaction identifier to correlate commands and
+ responses. A gateway supports two separate transaction identifier
+ name spaces:
+
+ * a transaction identifier name space for sending transactions, and
+
+ * a transaction identifier name space for receiving transactions.
+
+ At a minimum, transaction identifiers for commands sent to a given
+ gateway MUST be unique for the maximum lifetime of the transactions
+ within the collection of Call Agents that control that gateway.
+ Thus, regardless of the sending Call Agent, gateways can always
+ detect duplicate transactions by simply examining the transaction
+ identifier. The coordination of these transaction identifiers
+ between Call Agents is outside the scope of this specification
+ though.
+
+
+
+Andreasen & Foster Informational [Page 80]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Transaction identifiers for all commands sent from a given gateway
+ MUST be unique for the maximum lifetime of the transactions
+ regardless of which Call Agent the command is sent to. Thus, a Call
+ Agent can always detect a duplicate transaction from a gateway by the
+ combination of the domain-name of the endpoint and the transaction
+ identifier.
+
+ The transaction identifier is encoded as a string of up to nine
+ decimal digits. In the command lines, it immediately follows the
+ coding of the verb.
+
+ Transaction identifiers have values between 1 and 999,999,999 (both
+ included). Transaction identifiers SHOULD NOT use any leading
+ zeroes, although equality is based on numerical value, i.e., leading
+ zeroes are ignored. An MGCP entity MUST NOT reuse a transaction
+ identifier more quickly than three minutes after completion of the
+ previous command in which the identifier was used.
+
+3.2.1.3 Coding of the Endpoint Identifiers and Entity Names
+
+ The endpoint identifiers and entity names are encoded as case
+ insensitive e-mail addresses, as defined in RFC 821, although with
+ some syntactic restrictions on the local part of the name.
+ Furthermore, both the local endpoint name part and the domain name
+ part can each be up to 255 characters. In these addresses, the
+ domain name identifies the system where the endpoint is attached,
+ while the left side identifies a specific endpoint or entity on that
+ system.
+
+ Examples of such addresses are:
+
+ ------------------------------------------------------------------
+ | hrd4/56@gw23.example.net | Circuit number 56 in |
+ | | interface "hrd4" of the Gateway |
+ | | 23 of the "Example" network |
+ | Call-agent@ca.example.net | Call Agent for the |
+ | | "example" network |
+ | Busy-signal@ann12.example.net| The "busy signal" virtual |
+ | | endpoint in the announcement |
+ | | server number 12. |
+ ------------------------------------------------------------------
+
+ The name of a notified entity is expressed with the same syntax, with
+ the possible addition of a port number as in:
+
+ Call-agent@ca.example.net:5234
+
+
+
+
+
+Andreasen & Foster Informational [Page 81]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ In case the port number is omitted from the notified entity, the
+ default MGCP Call Agent port (2727) MUST be used.
+
+3.2.1.4 Coding of the Protocol Version
+
+ The protocol version is coded as the keyword MGCP followed by a white
+ space and the version number, and optionally followed by a profile
+ name. The version number is composed of a major version, coded by a
+ decimal number, a dot, and a minor version number, coded as a decimal
+ number. The version described in this document is version 1.0.
+
+ The profile name, if present, is represented by white-space separated
+ strings of visible (printable) characters extending to the end of the
+ line. Profile names may be defined for user communities who want to
+ apply restrictions or other profiling to MGCP.
+
+ In the initial messages, the version will be coded as:
+
+ MGCP 1.0
+
+ An entity that receives a command with a protocol version it does not
+ support, MUST respond with an error (error code 528 - incompatible
+ protocol version, is RECOMMENDED). Note that this applies to
+ unsupported profiles as well.
+
+3.2.2 Parameter Lines
+
+ Parameter lines are composed of a parameter name, which in most cases
+ is composed of one or two characters, followed by a colon, optional
+ white space(s) and the parameter value. The parameters that can be
+ present in commands are defined in the following table:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 82]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ ------------------------------------------------------------------
+ |Parameter name | Code | Parameter value |
+ |----------------------|------|------------------------------------|
+ |BearerInformation | B | See description (3.2.2.1). |
+ |CallId | C | See description (3.2.2.2). |
+ |Capabilities | A | See description (3.2.2.3). |
+ |ConnectionId | I | See description (3.2.2.5). |
+ |ConnectionMode | M | See description (3.2.2.6). |
+ |ConnectionParameters | P | See description (3.2.2.7). |
+ |DetectEvents | T | See description (3.2.2.8). |
+ |DigitMap | D | A text encoding of a digit map. |
+ |EventStates | ES | See description (3.2.2.9). |
+ |LocalConnectionOptions| L | See description (3.2.2.10). |
+ |MaxMGCPDatagram | MD | See description (3.2.2.11). |
+ |NotifiedEntity | N | An identifier, in RFC 821 format, |
+ | | | composed of an arbitrary string |
+ | | | and of the domain name of the |
+ | | | requesting entity, possibly com- |
+ | | | pleted by a port number, as in: |
+ | | | Call-agent@ca.example.net:5234 |
+ | | | See also Section 3.2.1.3. |
+ |ObservedEvents | O | See description (3.2.2.12). |
+ |PackageList | PL | See description (3.2.2.13). |
+ |QuarantineHandling | Q | See description (3.2.2.14). |
+ |ReasonCode | E | A string with a 3 digit integer |
+ | | | optionally followed by a set of |
+ | | | arbitrary characters (3.2.2.15). |
+ |RequestedEvents | R | See description (3.2.2.16). |
+ |RequestedInfo | F | See description (3.2.2.17). |
+ |RequestIdentifier | X | See description (3.2.2.18). |
+ |ResponseAck | K | See description (3.2.2.19). |
+ |RestartDelay | RD | A number of seconds, encoded as |
+ | | | a decimal number. |
+ |RestartMethod | RM | See description (3.2.2.20). |
+ |SecondConnectionId | I2 | Connection Id. |
+ |SecondEndpointId | Z2 | Endpoint Id. |
+ |SignalRequests | S | See description (3.2.2.21). |
+ |SpecificEndPointId | Z | An identifier, in RFC 821 format, |
+ | | | composed of an arbitrary string, |
+ | | | followed by an "@" followed by |
+ | | | the domain name of the gateway to |
+ | | | which this endpoint is attached. |
+ | | | See also Section 3.2.1.3. |
+ |----------------------|------|------------------------------------|
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 83]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ |RemoteConnection- | RC | Session Description. |
+ | Descriptor | | |
+ |LocalConnection- | LC | Session Description. |
+ | Descriptor | | |
+ ------------------------------------------------------------------
+
+ The parameters are not necessarily present in all commands. The
+ following table provides the association between parameters and
+ commands. The letter M stands for mandatory, O for optional and F
+ for forbidden. Unless otherwise specified, a parameter MUST NOT be
+ present more than once.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 84]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ ------------------------------------------------------------------
+ | Parameter name | EP | CR | MD | DL | RQ | NT | AU | AU | RS |
+ | | CF | CX | CX | CX | NT | FY | EP | CX | IP |
+ |---------------------|----|----|----|----|----|----|----|----|----|
+ | BearerInformation | O*| O | O | O | O | F | F | F | F |
+ | CallId | F | M | M | O | F | F | F | F | F |
+ | Capabilities | F | F | F | F | F | F | F | F | F |
+ | ConnectionId | F | F | M | O | F | F | F | M | F |
+ | ConnectionMode | F | M | O | F | F | F | F | F | F |
+ | Connection- | F | F | F | O*| F | F | F | F | F |
+ | Parameters | | | | | | | | | |
+ | DetectEvents | F | O | O | O | O | F | F | F | F |
+ | DigitMap | F | O | O | O | O | F | F | F | F |
+ | EventStates | F | F | F | F | F | F | F | F | F |
+ | LocalConnection- | F | O | O | F | F | F | F | F | F |
+ | Options | | | | | | | | | |
+ | MaxMGCPDatagram | F | F | F | F | F | F | F | F | F |
+ | NotifiedEntity | F | O | O | O | O | O | F | F | F |
+ | ObservedEvents | F | F | F | F | F | M | F | F | F |
+ | PackageList | F | F | F | F | F | F | F | F | F |
+ | QuarantineHandling | F | O | O | O | O | F | F | F | F |
+ | ReasonCode | F | F | F | O | F | F | F | F | O |
+ | RequestedEvents | F | O | O | O | O*| F | F | F | F |
+ | RequestIdentifier | F | O*| O*| O*| M | M | F | F | F |
+ | RequestedInfo | F | F | F | F | F | F | O | M | F |
+ | ResponseAck | O | O | O | O | O | O | O | O | O |
+ | RestartDelay | F | F | F | F | F | F | F | F | O |
+ | RestartMethod | F | F | F | F | F | F | F | F | M |
+ | SecondConnectionId | F | F | F | F | F | F | F | F | F |
+ | SecondEndpointId | F | O | F | F | F | F | F | F | F |
+ | SignalRequests | F | O | O | O | O*| F | F | F | F |
+ | SpecificEndpointId | F | F | F | F | F | F | F | F | F |
+ |---------------------|----|----|----|----|----|----|----|----|----|
+ | RemoteConnection- | F | O | O | F | F | F | F | F | F |
+ | Descriptor | | | | | | | | | |
+ | LocalConnection- | F | F | F | F | F | F | F | F | F |
+ | Descriptor | | | | | | | | | |
+ ------------------------------------------------------------------
+
+ Notes (*):
+
+ * The BearerInformation parameter is only conditionally optional as
+ explained in Section 2.3.2.
+
+ * The RequestIdentifier parameter is optional in connection creation,
+ modification and deletion commands, however it becomes REQUIRED if
+ the command contains an encapsulated notification request.
+
+
+
+
+Andreasen & Foster Informational [Page 85]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * The RequestedEvents and SignalRequests parameters are optional in
+ the NotificationRequest. If these parameters are omitted the
+ corresponding lists will be considered empty.
+
+ * The ConnectionParameters parameter is only valid in a
+ DeleteConnection request sent by the gateway.
+
+ The set of parameters can be extended in two different ways:
+
+ * Package Extension Parameters (preferred)
+
+ * Vendor Extension Parameters
+
+ Package Extension Parameters are defined in packages which provides
+ the following benefits:
+
+ * a registration mechanism (IANA) for the package name.
+
+ * a separate name space for the parameters.
+
+ * a convenient grouping of the extensions.
+
+ * a simple way to determine support for them through auditing.
+
+ The package extension mechanism is the preferred extension method.
+
+ Vendor extension parameters can be used if implementers need to
+ experiment with new parameters, for example when developing a new
+ application of MGCP. Vendor extension parameters MUST be identified
+ by names that start with the string "X-" or "X+", such as for
+ example:
+
+ X-Flower: Daisy
+
+ Parameter names that start with "X+" are critical parameter
+ extensions. An MGCP entity that receives a critical parameter
+ extension that it cannot understand MUST refuse to execute the
+ command. It SHOULD respond with error code 511 (unrecognized
+ extension).
+
+ Parameter names that start with "X-" are non-critical parameter
+ extensions. An MGCP entity that receives a non-critical parameter
+ extension that it cannot understand MUST simply ignore that
+ parameter.
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 86]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Note that vendor extension parameters use an unmanaged name space,
+ which implies a potential for name clashing. Vendors are
+ consequently encouraged to include some vendor specific string, e.g.,
+ vendor name, in their vendor extensions.
+
+3.2.2.1 BearerInformation
+
+ The values of the bearer information are encoded as a comma separated
+ list of attributes, which are represented by an attribute name, and
+ possibly followed by a colon and an attribute value.
+
+ The only attribute that is defined is the "encoding" (code "e")
+ attribute, which MUST have one of the values "A" (A-law) or "mu"
+ (mu-law).
+
+ An example of bearer information encoding is:
+
+ B: e:mu
+
+ The set of bearer information attributes may be extended through
+ packages.
+
+3.2.2.2 CallId
+
+ The Call Identifier is encoded as a hexadecimal string, at most 32
+ characters in length. Call Identifiers are compared as strings
+ rather than numerical values.
+
+3.2.2.3 Capabilities
+
+ Capabilities inform the Call Agent about endpoints' capabilities when
+ audited. The encoding of capabilities is based on the Local
+ Connection Options encoding for the parameters that are common to
+ both, although a different parameter line code is used ("A"). In
+ addition, capabilities can also contain a list of supported packages,
+ and a list of supported modes.
+
+ The parameters used are:
+
+ A list of supported codecs.
+ The following parameters will apply to all codecs specified in
+ this list. If there is a need to specify that some parameters,
+ such as e.g., silence suppression, are only compatible with some
+ codecs, then the gateway will return several Capability
+ parameters; one for each set of codecs.
+
+ Packetization Period:
+ A range may be specified.
+
+
+
+Andreasen & Foster Informational [Page 87]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Bandwidth:
+ A range corresponding to the range for packetization periods may
+ be specified (assuming no silence suppression). If absent, the
+ values will be deduced from the codec type.
+
+ Echo Cancellation:
+ "on" if echo cancellation is supported, "off" otherwise. The
+ default is support.
+
+ Silence Suppression:
+ "on" if silence suppression is supported for this codec, "off"
+ otherwise. The default is support.
+
+ Gain Control:
+ "0" if gain control is not supported, all other values indicate
+ support for gain control. The default is support.
+
+ Type of Service:
+ The value "0" indicates no support for type of service, all other
+ values indicate support for type of service. The default is
+ support.
+
+ Resource Reservation Service:
+ The parameter indicates the reservation services that are
+ supported, in addition to best effort. The value "g" is encoded
+ when the gateway supports both the guaranteed and the controlled
+ load service, "cl" when only the controlled load service is
+ supported. The default is "best effort".
+
+ Encryption Key:
+ Encoding any value indicates support for encryption. Default is
+ no support which is implied by omitting the parameter.
+
+ Type of network:
+ The keyword "nt", followed by a colon and a semicolon separated
+ list of supported network types. This parameter is optional.
+
+ Packages:
+ The packages supported by the endpoint encoded as the keyword "v",
+ followed by a colon and a character string. If a list of values
+ is specified, these values will be separated by a semicolon. The
+ first value specified will be the default package for the
+ endpoint.
+
+ Modes:
+ The modes supported by this endpoint encoded as the keyword "m",
+ followed by a colon and a semicolon-separated list of supported
+ connection modes for this endpoint.
+
+
+
+Andreasen & Foster Informational [Page 88]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Lack of support for a capability can also be indicated by excluding
+ the parameter from the capability set.
+
+ An example capability is:
+
+ A: a:PCMU;G728, p:10-100, e:on, s:off, t:1, v:L,
+ m:sendonly;recvonly;sendrecv;inactive
+
+ The carriage return above is included for formatting reasons only and
+ is not permissible in a real implementation.
+
+ If multiple capabilities are to be returned, each will be returned as
+ a separate capability line.
+
+ Since Local Connection Options can be extended, the list of
+ capability parameters can also be extended. Individual extensions
+ may define how they are reported as capabilities. If no such
+ definition is provided, the following defaults apply:
+
+ * Package Extension attributes: The individual attributes are not
+ reported. Instead, the name of the package is simply reported in
+ the list of supported packages.
+
+ * Vendor Extension attributes: The name of the attribute is reported
+ without any value.
+
+ * Other Extension attributes: The name of the attribute is reported
+ without any value.
+
+3.2.2.4 Coding of Event Names
+
+ Event names are composed of an optional package name, separated by a
+ slash (/) from the name of the actual event (see Section 2.1.7). The
+ wildcard character star ("*") can be use to refer to all packages.
+ The event name can optionally be followed by an at sign (@) and the
+ identifier of a connection (possibly using a wildcard) on which the
+ event should be observed. Event names are used in the
+ RequestedEvents, SignalRequests, ObservedEvents, DetectEvents, and
+ EventStates parameters.
+
+ Events and signals may be qualified by parameters defined for the
+ event/signal. Such parameters may be enclosed in double-quotes (in
+ fact, some parameters MUST be enclosed in double-quotes due to
+ syntactic restrictions) in which case they are UTF-8 encoded [20].
+
+ The parameter name "!" (exclamation point) is reserved for future use
+ for both events and signals.
+
+
+
+
+Andreasen & Foster Informational [Page 89]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Each signal has one of the following signal-types associated with it:
+ On/Off (OO), Time-out (TO), or Brief (BR). (These signal types are
+ specified in the package definitions, and are not present in the
+ messages.) On/Off signals can be parameterized with a "+" to turn the
+ signal on, or a "-" to turn the signal off. If an on/off signal is
+ not parameterized, the signal is turned on. Both of the following
+ will turn the vmwi signal (from the line package "L") on:
+
+ L/vmwi(+)
+ L/vmwi
+
+ In addition to "!", "+" and "-", the signal parameter "to" is
+ reserved as well. It can be used with Time-Out signals to override
+ the default time-out value for the current request. A decimal value
+ in milliseconds will be supplied. The individual signal and/or
+ package definition SHOULD indicate if this parameter is supported for
+ one or more TO signals in the package. If not indicated, TO signals
+ in package version zero are assumed to not support it, whereas TO
+ signals in package versions one or higher are assumed to support it.
+ By default, a supplied time-out value MAY be rounded to the nearest
+ non-zero value divisible by 1000, i.e., whole second. The individual
+ signal and/or package definition may define other rounding rules. All
+ new package and TO signal definitions are strongly encouraged to
+ support the "to" signal parameter.
+
+ The following example illustrates how the "to" parameter can be used
+ to apply a signal for 6 seconds:
+
+ L/rg(to=6000)
+ L/rg(to(6000))
+
+ The following are examples of event names:
+
+ -----------------------------------------------------------
+ | L/hu | on-hook transition, in the line package |
+ | F/0 | digit 0 in the MF package |
+ | hf | Hook-flash, assuming that the line package|
+ | | is the default package for the endpoint. |
+ | G/rt@0A3F58 | Ring back signal on connection "0A3F58" |
+ -----------------------------------------------------------
+
+ In addition, the range and wildcard notation of events can be used,
+ instead of individual names, in the RequestedEvents and DetectEvents
+ parameters. The event code "all" is reserved and refers to all
+ events or signals in a package. The star sign ("*") can be used to
+ denote "all connections", and the dollar sign ("$") can be used to
+ denote the "current" connection (see Section 2.1.7 for details).
+
+
+
+
+Andreasen & Foster Informational [Page 90]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The following are examples of such notations:
+
+ ---------------------------------------------------------
+ | M/[0-9] | Digits 0 to 9 in the MF package. |
+ | hf | Hook-flash, assuming that the line package|
+ | | is a default package for the endpoint. |
+ | [0-9*#A-D]| All digits and letters in the DTMF |
+ | | packages (default for endpoint). |
+ | T/all | All events in the trunk package. |
+ | R/qa@* | The quality alert event on all |
+ | | connections. |
+ | G/rt@$ | Ringback on current connection. |
+ ---------------------------------------------------------
+
+3.2.2.5 ConnectionId
+
+ The Connection Identifier is encoded as a hexadecimal string, at most
+ 32 characters in length. Connection Identifiers are compared as
+ strings rather than numerical values.
+
+3.2.2.6 ConnectionMode
+
+ The connection mode describes the mode of operation of the
+ connection. The possible values are:
+
+ --------------------------------------------------------
+ | Mode | Meaning |
+ |-------------|------------------------------------------|
+ | M: sendonly | The gateway should only send packets |
+ | M: recvonly | The gateway should only receive packets |
+ | M: sendrecv | The gateway should send |
+ | | and receive packets |
+ | M: confrnce | The gateway should place |
+ | | the connection in conference mode |
+ | M: inactive | The gateway should neither |
+ | | send nor receive packets |
+ | M: loopback | The gateway should place |
+ | | the circuit in loopback mode. |
+ | M: conttest | The gateway should place |
+ | | the circuit in test mode. |
+ | M: netwloop | The gateway should place |
+ | | the connection in network loopback mode.|
+ | M: netwtest | The gateway should place the connection |
+ | | in network continuity test mode. |
+ --------------------------------------------------------
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 91]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Note that irrespective of the connection mode, signals applied to the
+ connection will still result in packets being sent (see Section
+ 2.3.1).
+
+ The set of connection modes can be extended through packages.
+
+3.2.2.7 ConnectionParameters
+
+ Connection parameters are encoded as a string of type and value
+ pairs, where the type is either a two-letter identifier of the
+ parameter or an extension type, and the value a decimal integer.
+ Types are separated from value by an '=' sign. Parameters are
+ separated from each other by a comma. Connection parameter values
+ can contain up to nine digits. If the maximum value is reached, the
+ counter is no longer updated, i.e., it doesn't wrap or overflow.
+
+ The connection parameter types are specified in the following table:
+
+ -----------------------------------------------------------------
+ | Connection parameter| Code | Connection parameter |
+ | name | | value |
+ |---------------------|------|------------------------------------|
+ | Packets sent | PS | The number of packets that |
+ | | | were sent on the connection. |
+ | Octets sent | OS | The number of octets that |
+ | | | were sent on the connection. |
+ | Packets received | PR | The number of packets that |
+ | | | were received on the connection. |
+ | Octets received | OR | The number of octets that |
+ | | | were received on the connection. |
+ | Packets lost | PL | The number of packets that |
+ | | | were lost on the connection |
+ | | | as deduced from gaps in the |
+ | | | RTP sequence number. |
+ | Jitter | JI | The average inter-packet arrival |
+ | | | jitter, in milliseconds, |
+ | | | expressed as an integer number. |
+ | Latency | LA | Average latency, in milliseconds, |
+ | | | expressed as an integer number. |
+ -----------------------------------------------------------------
+
+ The set of connection parameters can be extended in two different
+ ways:
+
+ * Package Extension Parameters (preferred)
+
+ * Vendor Extension Parameters
+
+
+
+
+Andreasen & Foster Informational [Page 92]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Package Extension Connection Parameters are defined in packages which
+ provides the following benefits:
+
+ * A registration mechanism (IANA) for the package name.
+
+ * A separate name space for the parameters.
+
+ * A convenient grouping of the extensions.
+
+ * A simple way to determine support for them through auditing.
+
+ The package extension mechanism is the preferred extension method.
+
+ Vendor extension parameters names are composed of the string "X-"
+ followed by a two or more letters extension parameter name.
+
+ Call agents that receive unrecognized package or vendor connection
+ parameter extensions SHALL silently ignore these parameters.
+
+ An example of connection parameter encoding is:
+
+ P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
+
+3.2.2.8 DetectEvents
+
+ The DetectEvents parameter is encoded as a comma separated list of
+ events (see Section 3.2.2.4), such as for example:
+
+ T: L/hu,L/hd,L/hf,D/[0-9#*]
+
+ It should be noted, that no actions can be associated with the
+ events, however event parameters may be provided.
+
+3.2.2.9 EventStates
+
+ The EventStates parameter is encoded as a comma separated list of
+ events (see Section 3.2.2.4), such as for example:
+
+ ES: L/hu
+
+ It should be noted, that no actions can be associated with the
+ events, however event parameters may be provided.
+
+3.2.2.10 LocalConnectionOptions
+
+ The local connection options describe the operational parameters that
+ the Call Agent provides to the gateway in connection handling
+ commands. These include:
+
+
+
+Andreasen & Foster Informational [Page 93]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * The allowed codec(s), encoded as the keyword "a", followed by a
+ colon and a character string. If the Call Agent specifies a list
+ of values, these values will be separated by a semicolon. For RTP,
+ audio codecs SHALL be specified by using encoding names defined in
+ the RTP AV Profile [4] or its replacement, or by encoding names
+ registered with the IANA. Non-audio media registered as a MIME
+ type MUST use the "<MIME type>/<MIME subtype>" form, as in
+ "image/t38".
+
+ * The packetization period in milliseconds, encoded as the keyword
+ "p", followed by a colon and a decimal number. If the Call Agent
+ specifies a range of values, the range will be specified as two
+ decimal numbers separated by a hyphen (as specified for the "ptime"
+ parameter for SDP).
+
+ * The bandwidth in kilobits per second (1000 bits per second),
+ encoded as the keyword "b", followed by a colon and a decimal
+ number. If the Call Agent specifies a range of values, the range
+ will be specified as two decimal numbers separated by a hyphen.
+
+ * The type of service parameter, encoded as the keyword "t", followed
+ by a colon and the value encoded as two hexadecimal digits. When
+ the connection is transmitted over an IP network, the parameters
+ encode the 8-bit type of service value parameter of the IP header
+ (a.k.a. DiffServ field). The left-most "bit" in the parameter
+ corresponds to the least significant bit in the IP header.
+
+ * The echo cancellation parameter, encoded as the keyword "e",
+ followed by a colon and the value "on" or "off".
+
+ * The gain control parameter, encoded as the keyword "gc", followed
+ by a colon and a value which can be either the keyword "auto" or a
+ decimal number (positive or negative) representing the number of
+ decibels of gain.
+
+ * The silence suppression parameter, encoded as the keyword "s",
+ followed by a colon and the value "on" or "off".
+
+ * 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 encryption key, encoded as the keyword "k" followed by a colon
+ and a key specification, as defined for the parameter "K" in SDP
+ (RFC 2327).
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 94]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * The type of network, encoded as the keyword "nt" followed by a
+ colon and the type of network encoded as the keyword "IN"
+ (internet), "ATM", "LOCAL" (for a local connection), or possibly
+ another type of network registered with the IANA as per SDP (RFC
+ 2327).
+
+ * 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 encoding of the first three attributes, when they are present,
+ will be compatible with the SDP and RTP profiles. Note that each of
+ the attributes is optional. When several attributes are present,
+ they are separated by a comma.
+
+ Examples of local connection options are:
+
+ L: p:10, a:PCMU
+ L: p:10, a:G726-32
+ L: p:10-20, b:64
+ L: b:32-64, e:off
+
+ The set of Local Connection Options attributes can be extended in
+ three different ways:
+
+ * Package Extension attributes (preferred)
+
+ * Vendor Extension attributes
+
+ * Other Extension attributes
+
+ Package Extension Local Connection Options attributes are defined in
+ packages which provides the following benefits:
+
+ * A registration mechanism (IANA) for the package name.
+
+ * A separate name space for the attributes.
+
+ * A convenient grouping of the extensions.
+
+ * A simple way to determine support for them through auditing.
+
+ The package extension mechanism is the preferred extension method.
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 95]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Vendor extension attributes are composed of an attribute name, and
+ possibly followed by a colon and an attribute value. The attribute
+ name MUST start with the two characters "x+", for a mandatory
+ extension, or "x-", for a non-mandatory extension. If a gateway
+ receives a mandatory extension attribute that it does not recognize,
+ it MUST reject the command (error code 525 - unknown extension in
+ LocalConnectionOptions, is RECOMMENDED).
+
+ Note that vendor extension attributes use an unmanaged name space,
+ which implies a potential for name clashing. Vendors are
+ consequently encouraged to include some vendor specific string, e.g.,
+ vendor name, in their vendor extensions.
+
+ Finally, for backwards compatibility with some existing
+ implementations, MGCP allows for other extension attributes as well
+ (see grammar in Appendix A). Note however, that these attribute
+ extensions do not provide the package extension attribute benefits.
+ Use of this mechanism for new extensions is discouraged.
+
+3.2.2.11 MaxMGCPDatagram
+
+ The MaxMGCPDatagram can only be used for auditing, i.e., it is a
+ valid RequestedInfo code and can be provided as a response parameter.
+
+ In responses, the MaxMGCPDatagram value is encoded as a string of up
+ to nine decimal digits -- leading zeroes are not permitted. The
+ following example illustrates the use of this parameter:
+
+ MD: 8100
+
+3.2.2.12 ObservedEvents
+
+ The observed events parameter provides the list of events that have
+ been observed. The event codes are the same as those used in the
+ NotificationRequest. Events that have been accumulated according to
+ the digit map may be grouped in a single string, however such
+ practice is discouraged; they SHOULD be reported as lists of isolated
+ events if other events were detected during the digit accumulation.
+ Examples of observed events are:
+
+ O: L/hu
+ O: D/8295555T
+ O: D/8,D/2,D/9,D/5,D/5,L/hf,D/5,D/5,D/T
+ O: L/hf, L/hf, L/hu
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 96]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+3.2.2.13 PackageList
+
+ The Package List can only be used for auditing, i.e., it is a valid
+ RequestedInfo code and can be provided as a response parameter.
+
+ The response parameter will consist of a comma separated list of
+ packages supported. The first package returned in the list is the
+ default package. Each package in the list consists of the package
+ name followed by a colon, and the highest version number of the
+ package supported.
+
+ An example of a package list is:
+
+ PL: L:1,G:1,D:0,FOO:2,T:1
+
+ Note that for backwards compatibility, support for this parameter is
+ OPTIONAL.
+
+3.2.2.14 QuarantineHandling
+
+ The quarantine handling parameter contains a list of comma separated
+ keywords:
+
+ * The keyword "process" or "discard" to indicate the treatment of
+ quarantined and observed events. If neither "process" or "discard"
+ is present, "process" is assumed.
+
+ * The keyword "step" or "loop" to indicate whether at most one
+ notification per NotificationRequest is allowed, or whether
+ multiple notifications per NotificationRequest are allowed. If
+ neither "step" nor "loop" is present, "step" is assumed.
+
+ The following values are valid examples:
+
+ Q: loop
+ Q: process
+ Q: loop,discard
+
+3.2.2.15 ReasonCode
+
+ Reason codes are three-digit numeric values. The reason code is
+ optionally followed by a white space and commentary, e.g.:
+
+ E: 900 Endpoint malfunctioning
+
+ A list of reason codes can be found in Section 2.5.
+
+ The set of reason codes can be extended through packages.
+
+
+
+Andreasen & Foster Informational [Page 97]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+3.2.2.16 RequestedEvents
+
+ The RequestedEvents parameter provides the list of events that are
+ requested. The event codes are described in Section 3.2.2.4.
+
+ Each event can be qualified by a requested action, or by a list of
+ actions. The actions, when specified, are encoded as a list of
+ keywords, enclosed in parenthesis and separated by commas. The codes
+ for the various actions are:
+
+ -------------------------------------
+ | Action | Code |
+ |------------------------------|------|
+ | Notify immediately | N |
+ | Accumulate | A |
+ | Treat according to digit map | D |
+ | Swap | S |
+ | Ignore | I |
+ | Keep Signal(s) active | K |
+ | Embedded Notification Request| E |
+ -------------------------------------
+
+ When no action is specified, the default action is to notify the
+ event. This means that, for example, ft and ft(N) are equivalent.
+ Events that are not listed are ignored (unless they are persistent).
+
+ The digit-map action SHOULD only be specified for the digits, letters
+ and interdigit timers in packages that define the encoding of digits,
+ letters, and timers (including extension digit map letters).
+
+ The requested events list is encoded on a single line, with
+ event/action groups separated by commas. Examples of RequestedEvents
+ encodings are:
+
+ R: L/hu(N), L/hf(S,N)
+ R: L/hu(N), D/[0-9#T](D)
+
+ In the case of the "Embedded Notification Request" action, the
+ embedded notification request parameters are encoded as a list of up
+ to three parameter groups separated by commas. Each group starts by
+ a one letter identifier, followed by a list of parameters enclosed
+ between parentheses. The first optional parameter group, identified
+ by the letter "R", is the value of the embedded RequestedEvents
+ parameter. The second optional group, identified by the letter "S",
+ is the embedded value of the SignalRequests parameter. The third
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 98]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ optional group, identified by the letter "D", is the embedded value
+ of the DigitMap. (Note that some existing implementations and
+ profiles may encode these three components in a different order.
+ Implementers are encouraged to accept such encodings, but they SHOULD
+ NOT generate them.)
+
+ If the RequestedEvents parameter is not present, the parameter will
+ be set to a null value. If the SignalRequests parameter is not
+ present, the parameter will be set to a null value. If the DigitMap
+ is absent, the current value MUST be used. The following are valid
+ examples of embedded requests:
+
+ R: L/hd(E(R(D/[0-9#T](D),L/hu(N)),S(L/dl),D([0-9].[#T])))
+ R: L/hd(E(R(D/[0-9#T](D),L/hu(N)),S(L/dl)))
+
+ Some events can be qualified by additional event parameters. Such
+ event parameters will be separated by commas and enclosed within
+ parentheses. Event parameters may be enclosed in double-quotes (in
+ fact, some event parameters MUST be enclosed in double-quotes due to
+ syntactic restrictions), in which case the quoted string itself is
+ UTF-8 encoded. Please refer to Section 3.2.2.4 for additional detail
+ on event parameters.
+
+ The following example shows the foobar event with an event parameter
+ "epar":
+
+ R: X/foobar(N)(epar=2)
+
+ Notice that the Action was included even though it is the default
+ Notify action - this is required by the grammar.
+
+3.2.2.17 RequestedInfo
+
+ The RequestedInfo parameter contains a comma separated list of
+ parameter codes, as defined in Section 3.2.2. For example, if one
+ wants to audit the value of the NotifiedEntity, RequestIdentifier,
+ RequestedEvents, SignalRequests, DigitMap, QuarantineHandling and
+ DetectEvents parameters, the value of the RequestedInfo parameter
+ will be:
+
+ F: N,X,R,S,D,Q,T
+
+ Note that extension parameters in general can be audited as well.
+ The individual extension will define the auditing operation.
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 99]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The capabilities request, in the AuditEndPoint command, is encoded by
+ the parameter code "A", as in:
+
+ F: A
+
+3.2.2.18 RequestIdentifier
+
+ The request identifier correlates a Notify command with the
+ NotificationRequest that triggered it. A RequestIdentifier is a
+ hexadecimal string, at most 32 characters in length.
+ RequestIdentifiers are compared as strings rather than numerical
+ value. The string "0" is reserved for reporting of persistent events
+ in the case where a NotificationRequest has not yet been received
+ after restart.
+
+3.2.2.19 ResponseAck
+
+ The response acknowledgement parameter is used to manage the "at-
+ most-once" facility described in Section 3.5. It contains a comma
+ separated list of "confirmed transaction-id ranges".
+
+ Each "confirmed transaction-id range" is composed of either one
+ decimal number, when the range includes exactly one transaction, or
+ two decimal numbers separated by a single hyphen, describing the
+ lower and higher transaction identifiers included in the range.
+
+ An example of a response acknowledgement is:
+
+ K: 6234-6255, 6257, 19030-19044
+
+3.2.2.20 RestartMethod
+
+ The RestartMethod parameter is encoded as one of the keywords
+ "graceful", "forced", "restart", "disconnected" or "cancel-graceful"
+ as for example:
+
+ RM: restart
+
+ The set of restart methods can be extended through packages.
+
+3.2.2.21 SignalRequests
+
+ The SignalRequests parameter provides the name of the signal(s) that
+ have been requested. Each signal is identified by a name, as
+ described in Section 3.2.2.4.
+
+ Some signals, such as for example announcement or ADSI display, can
+ be qualified by additional parameters, e.g.:
+
+
+
+Andreasen & Foster Informational [Page 100]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * the name and parameters of the announcement,
+
+ * the string that should be displayed.
+
+ Such parameters will be separated by commas and enclosed within
+ parenthesis, as in:
+
+ S: L/adsi("123456 Francois Gerard")
+ S: A/ann(http://ann.example.net/no-such-number.au, 1234567)
+
+ When a quoted-string is provided, the string itself is UTF-8 encoded
+ [20].
+
+ When several signals are requested, their codes are separated by a
+ comma, as in:
+
+ S: L/adsi("123456 Your friend"), L/rg
+
+ Please refer to Section 3.2.2.4 for additional detail on signal
+ parameters.
+
+3.3 Format of response headers
+
+ The response header is composed of a response line, optionally
+ followed by headers that encode the response parameters.
+
+ An example of a response header could be:
+
+ 200 1203 OK
+
+ The response line starts with the response code, which is a three
+ digit numeric value. The code is followed by a white space, and the
+ transaction identifier. Response codes defined in packages (8xx) are
+ followed by white space, a slash ("/") and the package name. All
+ response codes may furthermore be followed by optional commentary
+ preceded by a white space.
+
+ The following table describes the parameters whose presence is
+ mandatory or optional in a response header, as a function of the
+ command that triggered the response. The letter M stands for
+ mandatory, O for optional and F for forbidden. Unless otherwise
+ specified, a parameter MUST NOT be present more than once. Note that
+ the table only reflects the default for responses that have not
+ defined any other behavior. If a response is received with a
+ parameter that is either not understood or marked as forbidden, the
+ offending parameter(s) MUST simply be ignored.
+
+
+
+
+
+Andreasen & Foster Informational [Page 101]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ ------------------------------------------------------------------
+ | Parameter name | EP | CR | MD | DL | RQ | NT | AU | AU | RS |
+ | | CF | CX | CX | CX | NT | FY | EP | CX | IP |
+ |---------------------|----|----|----|----|----|----|----|----|----|
+ | BearerInformation | F | F | F | F | F | F | O | F | F |
+ | CallId | F | F | F | F | F | F | F | O | F |
+ | Capabilities | F | F | F | F | F | F | O*| F | F |
+ | ConnectionId | F | O*| F | F | F | F | O*| F | F |
+ | ConnectionMode | F | F | F | F | F | F | F | O | F |
+ | Connection- | F | F | F | O*| F | F | F | O | F |
+ | Parameters | | | | | | | | | |
+ | DetectEvents | F | F | F | F | F | F | O | F | F |
+ | DigitMap | F | F | F | F | F | F | O | F | F |
+ | EventStates | F | F | F | F | F | F | O | F | F |
+ | LocalConnection- | F | F | F | F | F | F | F | O | F |
+ | Options | | | | | | | | | |
+ | MaxMGCPDatagram | F | F | F | F | F | F | O | F | F |
+ | NotifiedEntity | F | F | F | F | F | F | O | O | O |
+ | ObservedEvents | F | F | F | F | F | F | O | F | F |
+ | QuarantineHandling | F | F | F | F | F | F | O | F | F |
+ | PackageList | O*| O*| O*| O*| O*| O*| O | O*| O*|
+ | ReasonCode | F | F | F | F | F | F | O | F | F |
+ | RequestIdentifier | F | F | F | F | F | F | O | F | F |
+ | ResponseAck | O*| O*| O*| O*| O*| O*| O*| O*| O*|
+ | RestartDelay | F | F | F | F | F | F | O | F | F |
+ | RestartMethod | F | F | F | F | F | F | O | F | F |
+ | RequestedEvents | F | F | F | F | F | F | O | F | F |
+ | RequestedInfo | F | F | F | F | F | F | F | F | F |
+ | SecondConnectionId | F | O | F | F | F | F | F | F | F |
+ | SecondEndpointId | F | O | F | F | F | F | F | F | F |
+ | SignalRequests | F | F | F | F | F | F | O | F | F |
+ | SpecificEndpointId | F | O | F | F | F | F | O*| F | F |
+ |---------------------|----|----|----|----|----|----|----|----|----|
+ | LocalConnection- | F | O*| O | F | F | F | F | O*| F |
+ | Descriptor | | | | | | | | | |
+ | RemoteConnection- | F | F | F | F | F | F | F | O*| F |
+ | Descriptor | | | | | | | | | |
+ ------------------------------------------------------------------
+
+ Notes (*):
+
+ * The PackageList parameter is only allowed with return code 518
+ (unsupported package), except for AuditEndpoint, where it may also
+ be returned if audited.
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 102]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * The ResponseAck parameter MUST NOT be used with any other responses
+ than a final response issued after a provisional response for the
+ transaction in question. In that case, the presence of the
+ ResponseAck parameter SHOULD trigger a Response Acknowledgement -
+ any ResponseAck values provided will be ignored.
+
+ * In the case of a CreateConnection message, the response line is
+ followed by a Connection-Id parameter and a
+ LocalConnectionDescriptor. It may also be followed a Specific-
+ Endpoint-Id parameter, if the creation request was sent to a
+ wildcarded Endpoint-Id. The connection-Id and
+ LocalConnectionDescriptor parameter are marked as optional in the
+ Table. In fact, they are mandatory with all positive responses,
+ when a connection was created, and forbidden when the response is
+ negative, and no connection was created.
+
+ * A LocalConnectionDescriptor MUST be transmitted with a positive
+ response (code 200) to a CreateConnection. It MUST also be
+ transmitted in response to a ModifyConnection command, if the
+ modification resulted in a modification of the session parameters.
+ The LocalConnectionDescriptor is encoded as a "session
+ description", as defined in section 3.4. It is separated from the
+ response header by an empty line.
+
+ * Connection-Parameters are only valid in a response to a non-
+ wildcarded DeleteConnection command sent by the Call Agent.
+
+ * Multiple ConnectionId, SpecificEndpointId, and Capabilities
+ parameters may be present in the response to an AuditEndpoint
+ command.
+
+ * When several session descriptors are encoded in the same response,
+ they are encoded one after each other, separated by an empty line.
+ This is the case for example when the response to an audit
+ connection request carries both a local session description and a
+ remote session description, as in:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 103]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 200 1203 OK
+ C: A3C47F21456789F0
+ N: [128.96.41.12]
+ L: p:10, a:PCMU;G726-32
+ M: sendrecv
+ P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48
+
+ v=0
+ o=- 25678 753849 IN IP4 128.96.41.1
+ s=-
+ c=IN IP4 128.96.41.1
+ t=0 0
+ m=audio 1296 RTP/AVP 0
+
+ v=0
+ o=- 33343 346463 IN IP4 128.96.63.25
+ s=-
+ c=IN IP4 128.96.63.25
+ t=0 0
+ m=audio 1296 RTP/AVP 0 96
+ a=rtpmap:96 G726-32/8000
+
+ In this example, according to the SDP syntax, each description
+ starts with a "version" line, (v=...). The local description is
+ always transmitted before the remote description. If a connection
+ descriptor is requested, but it does not exist for the connection
+ audited, that connection descriptor will appear with the SDP
+ protocol version field only.
+
+ The response parameters are described for each of the commands in the
+ following.
+
+3.3.1 CreateConnection Response
+
+ In the case of a CreateConnection message, the response line is
+ followed by a Connection-Id parameter with a successful response
+ (code 200). A LocalConnectionDescriptor is furthermore transmitted
+ with a positive response. The LocalConnectionDescriptor is encoded
+ as a "session description", as defined by SDP (RFC 2327). It is
+ separated from the response header by an empty line, e.g.:
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 104]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 200 1204 OK
+ I: FDE234C8
+
+ v=0
+ o=- 25678 753849 IN IP4 128.96.41.1
+ s=-
+ c=IN IP4 128.96.41.1
+ t=0 0
+ m=audio 3456 RTP/AVP 96
+ a=rtpmap:96 G726-32/8000
+
+ When a provisional response has been issued previously, the final
+ response SHOULD furthermore contain the Response Acknowledgement
+ parameter (final responses issued by entities adhering to this
+ specification will include the parameter, but older RFC 2705
+ implementations MAY not):
+
+ 200 1204 OK
+ K:
+ I: FDE234C8
+
+ v=0
+ o=- 25678 753849 IN IP4 128.96.41.1
+ s=-
+ c=IN IP4 128.96.41.1
+ t=0 0
+ m=audio 3456 RTP/AVP 96
+ a=rtpmap:96 G726-32/8000
+
+ The final response SHOULD then be acknowledged by a Response
+ Acknowledgement:
+
+ 000 1204
+
+3.3.2 ModifyConnection Response
+
+ In the case of a successful ModifyConnection message, the response
+ line is followed by a LocalConnectionDescriptor, if the modification
+ resulted in a modification of the session parameters (e.g., changing
+ only the mode of a connection does not alter the session parameters).
+ The LocalConnectionDescriptor is encoded as a "session description",
+ as defined by SDP. It is separated from the response header by an
+ empty line.
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 105]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 200 1207 OK
+
+ v=0
+ o=- 25678 753849 IN IP4 128.96.41.1
+ s=-
+ c=IN IP4 128.96.41.1
+ t=0 0
+ m=audio 3456 RTP/AVP 0
+
+ When a provisional response has been issued previously, the final
+ response SHOULD furthermore contain the Response Acknowledgement
+ parameter as in:
+
+ 200 1207 OK
+ K:
+
+ The final response SHOULD then be acknowledged by a Response
+ Acknowledgement:
+
+ 000 1207 OK
+
+3.3.3 DeleteConnection Response
+
+ Depending on the variant of the DeleteConnection message, the
+ response line may be followed by a Connection Parameters parameter
+ line, as defined in Section 3.2.2.7.
+
+ 250 1210 OK
+ P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
+
+3.3.4 NotificationRequest Response
+
+ A successful NotificationRequest response does not include any
+ additional response parameters.
+
+3.3.5 Notify Response
+
+ A successful Notify response does not include any additional response
+ parameters.
+
+3.3.6 AuditEndpoint Response
+
+ In the case of a successful AuditEndPoint the response line may be
+ followed by information for each of the parameters requested - each
+ parameter will appear on a separate line. Parameters for which no
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 106]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ value currently exists, e.g., digit map, will still be provided but
+ with an empty value. Each local endpoint name "expanded" by a
+ wildcard character will appear on a separate line using the
+ "SpecificEndPointId" parameter code, e.g.:
+
+ 200 1200 OK
+ Z: aaln/1@rgw.whatever.net
+ Z: aaln/2@rgw.whatever.net
+
+ When connection identifiers are audited and multiple connections
+ exist on the endpoint, a comma-separated list of connection
+ identifiers SHOULD be returned as in:
+
+ 200 1200 OK
+ I: FDE234C8, DFE233D1
+
+ Alternatively, multiple connection id parameter lines may be returned
+ - the two forms should not be mixed although doing so does not
+ constitute an error.
+
+ When capabilities are audited, the response may include multiple
+ capabilities parameter lines as in:
+
+ 200 1200 OK
+ A: a:PCMU;G728, p:10-100, e:on, s:off, t:1, v:L,
+ m:sendonly;recvonly;sendrecv;inactive
+ A: a:G729, p:30-90, e:on, s:on, t:1, v:L,
+ m:sendonly;recvonly;sendrecv;inactive;confrnce
+
+ Note: The carriage return for Capabilities shown above is present
+ for formatting reasons only. It is not permissible in a real command
+ encoding.
+
+3.3.7 AuditConnection Response
+
+ In the case of a successful AuditConnection, the response may be
+ followed by information for each of the parameters requested.
+ Parameters for which no value currently exists will still be
+ provided. Connection descriptors will always appear last and each
+ will be preceded by an empty line, as for example:
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 107]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 200 1203 OK
+ C: A3C47F21456789F0
+ N: [128.96.41.12]
+ L: p:10, a:PCMU;G728
+ M: sendrecv
+ P: PS=622, OS=31172, PR=390, OR=22561, PL=5, JI=29, LA=50
+
+ v=0
+ o=- 4723891 7428910 IN IP4 128.96.63.25
+ s=-
+ c=IN IP4 128.96.63.25
+ t=0 0
+ m=audio 1296 RTP/AVP 96
+ a=rtpmap:96 G726-32/8000
+
+ If both a local and a remote connection descriptor are provided, the
+ local connection descriptor will be the first of the two. If a
+ connection descriptor is requested, but it does not exist for the
+ connection audited, that connection descriptor will appear with the
+ SDP protocol version field only ("v=0"), as for example:
+
+ 200 1203 OK
+
+ v=0
+
+3.3.8 RestartInProgress Response
+
+ A successful RestartInProgress response may include a NotifiedEntity
+ parameter, but otherwise does not include any additional response
+ parameters.
+
+ Also, a 521 response to a RestartInProgress MUST include a
+ NotifiedEntity parameter with the name of another Call Agent to
+ contact when the first Call Agent redirects the endpoint to another
+ Call Agent as in:
+
+ 521 1204 Redirect
+ N: CA-1@whatever.net
+
+3.4 Encoding of the Session Description (SDP)
+
+ The session description (SDP) is encoded in conformance with the
+ session description protocol, SDP. MGCP implementations are REQUIRED
+ to be fully capable of parsing any conformant SDP message, and MUST
+ send session descriptions that strictly conform to the SDP standard.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 108]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The general description and explanation of SDP parameters can be
+ found in RFC 2327 (or its successor). In particular, it should be
+ noted that the
+
+ * Origin ("o="),
+
+ * Session Name ("s="), and
+
+ * Time active ("t=")
+
+ are all mandatory in RFC 2327. While they are of little use to MGCP,
+ they MUST be provided in conformance with RFC 2327 nevertheless. The
+ following suggests values to be used for each of the fields, however
+ the reader is encouraged to consult RFC 2327 (or its successor) for
+ details:
+
+ Origin
+ o = <username> <session id> <version> <network type> <address type>
+ <address>
+
+ * The username SHOULD be set to hyphen ("-").
+
+ * The session id is RECOMMENDED to be an NTP timestamp as suggested
+ in RFC 2327.
+
+ * The version is a version number that MUST increment with each
+ change to the SDP. A counter initialized to zero or an NTP
+ timestamp as suggested in RFC 2327 is RECOMMENDED.
+
+ * The network type defines the type of network. For RTP sessions the
+ network type SHOULD be "IN".
+
+ * The address type defines the type of address. For RTP sessions the
+ address type SHOULD be "IP4" (or "IP6").
+
+ * The address SHOULD be the same address as provided in the
+ connection information ("c=") field.
+
+ Session Name
+ s = <session name>
+
+ The session name should be hyphen ("-").
+
+ Time active
+ t = <start time> <stop time>
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 109]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * The start time may be set to zero.
+
+ * The stop time should be set to zero.
+
+ Each of the three fields can be ignored upon reception.
+
+ To further accommodate the extensibility principles of MGCP,
+ implementations are ENCOURAGED to support the PINT "a=require"
+ attribute - please refer to RFC 2848 for further details.
+
+ The usage of SDP actually depends on the type of session that is
+ being established. Below we describe usage of SDP for an audio
+ service using the RTP/AVP profile [4], or the LOCAL interconnect
+ defined in this document. In case of any conflicts between what is
+ described below and SDP (RFC 2327 or its successor), the SDP
+ specification takes precedence.
+
+3.4.1 Usage of SDP for an Audio Service
+
+ In a telephony gateway, we only have to describe sessions that use
+ exactly one media, audio. The usage of SDP for this is
+ straightforward and described in detail in RFC 2327.
+
+ The following is an example of an RFC 2327 conformant session
+ description for an audio connection:
+
+ v=0
+ o=- A7453949499 0 IN IP4 128.96.41.1
+ s=-
+ c=IN IP4 128.96.41.1
+ t=0 0
+ m=audio 3456 RTP/AVP 0 96
+ a=rtpmap:96 G726-32/8000
+
+3.4.2 Usage of SDP for LOCAL Connections
+
+ When MGCP is used to set up internal connections within a single
+ gateway, the SDP format is used to encode the parameters of that
+ connection. The connection and media parameters will be used as
+ follows:
+
+ * The connection parameter (c=) will specify that the connection is
+ local, using the keyword "LOCAL" as network type, the keyword "EPN"
+ (endpoint name) as address type, and the local name of the endpoint
+ as the connection-address.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 110]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * The "m=audio" parameter will specify a port number, which will
+ always be set to 0, the type of protocol, always set to the keyword
+ LOCAL, and the type of encoding, using the same conventions used
+ for the RTP AVP profile (RTP payload numbers). The type of
+ encoding should normally be set to 0 (PCMU).
+
+ A session-level attribute identifying the connection MAY furthermore
+ be present. This enables endpoints to support multiple LOCAL
+ connections. Use of this attribute is OPTIONAL and indeed
+ unnecessary for endpoints that only support a single LOCAL
+ connection. The attribute is defined as follows:
+
+ a=MGCPlocalcx:<ConnectionID>
+ The MGCP Local Connection attribute is a session level only case-
+ insensitive attribute that identifies the MGCP LOCAL connection,
+ on the endpoint identified in the connection information, to which
+ the SDP applies. The ConnectionId is a hexadecimal string
+ containing at most 32 characters. The ConnectionId itself is
+ case-insensitive. The MGCP Local Connection attribute is not
+ subject to the charset attribute.
+
+ An example of a LOCAL session description could be:
+
+ v=0
+ o=- A7453949499 0 LOCAL EPN X35V3+A4/13
+ s=-
+ c=LOCAL EPN X35V3+A4/13
+ t=0 0
+ a=MGCPlocalcx:FDE234C8
+ m=audio 0 LOCAL 0
+
+ Note that the MGCP Local Connection attribute is specified at the
+ session level and that it could have been omitted in case only a
+ single LOCAL connection per endpoint is supported.
+
+3.5 Transmission over UDP
+
+ MGCP messages are transmitted over UDP. Commands are sent to one of
+ the IP addresses defined in the DNS for the specified endpoint. The
+ responses are sent back to the source address (i.e., IP address and
+ UDP port number) of the commands - the response may or may not arrive
+ from the same address as the command was sent to.
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 111]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ When no port is specified for the endpoint, the commands MUST by
+ default be sent:
+
+ * by the Call Agents, to the default MGCP port for gateways, 2427.
+
+ * by the Gateways, to the default MGCP port for Call Agents, 2727.
+
+3.5.1 Providing the At-Most-Once Functionality
+
+ MGCP messages, being carried over UDP, may be subject to losses. In
+ the absence of a timely response, commands are retransmitted. Most
+ MGCP commands are not idempotent. The state of the gateway would
+ become unpredictable if, for example, CreateConnection commands were
+ executed several times. The transmission procedures MUST thus
+ provide an "at-most-once" functionality.
+
+ MGCP entities are expected to keep in memory a list of the responses
+ that they sent to recent transactions, and a list of the transactions
+ that are currently being executed. The numerical value of
+ 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 again, but
+ simply resends the response. The remaining commands will be compared
+ to the list of current transactions, i.e., transactions received
+ previously which have not yet finished executing. If a match is
+ found, the MGCP entity does not execute the transaction again, but a
+ provisional response (Section 3.5.5) SHOULD be issued to acknowledge
+ receipt of the command.
+
+ The procedure uses a long timer value, noted T-HIST in the following.
+ The timer MUST be set larger than the maximum duration of a
+ transaction, which MUST take into account the maximum number of
+ repetitions, the maximum value of the repetition timer and the
+ maximum propagation delay of a packet in the network. A suggested
+ value is 30 seconds.
+
+ The copy of the responses MAY be destroyed either T-HIST seconds
+ after the response is issued, or when the gateway (or the Call Agent)
+ receives a confirmation that the response has been received, through
+ the "Response Acknowledgement". For transactions that are
+ acknowledged through this attribute, the gateway SHALL keep a copy of
+ the transaction-id (as opposed to the entire transaction response)
+ for T-HIST seconds after the response is issued, in order to detect
+ and ignore duplicate copies of the transaction request that could be
+ produced by the network.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 112]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+3.5.2 Transaction Identifiers and Three Ways Handshake
+
+ Transaction identifiers are integer numbers in the range from 1 to
+ 999,999,999 (both included). Call-agents may decide to use a
+ specific number space for each of the gateways that they manage, or
+ to use the same number space for all gateways that belong to some
+ arbitrary group. Call agents may decide to share the load of
+ managing a large gateway between several independent processes.
+ These processes MUST then share the transaction number space. There
+ are multiple possible implementations of this sharing, such as having
+ a centralized allocation of transaction identifiers, or pre-
+ allocating non-overlapping ranges of identifiers to different
+ processes. The implementations MUST guarantee that unique
+ transaction identifiers are allocated to all transactions that
+ originate from a logical call agent, as defined in Section 4.
+ Gateways can simply detect duplicate transactions by looking at the
+ transaction identifier only.
+
+ The Response Acknowledgement Attribute can be found in any command.
+ It carries a set of "confirmed transaction-id ranges" for final
+ responses received - provisional responses MUST NOT be confirmed. A
+ given response SHOULD NOT be confirmed in two separate messages.
+
+ MGCP entities MAY choose to delete the copies of the responses (but
+ not the transaction-id) to transactions whose id is included in
+ "confirmed transaction-id ranges" received in the Response
+ Confirmation messages (command or response). They SHOULD then
+ silently discard further commands from that entity when the
+ transaction-id falls within these ranges, and the response was issued
+ less than T-HIST seconds ago.
+
+ Entities MUST exercise due caution when acknowledging responses. In
+ particular, a response SHOULD only be acknowledged if the response
+ acknowledgement is sent to the same entity as the corresponding
+ command (i.e., the command whose response is being acknowledged) was
+ sent to.
+
+ Likewise, entities SHOULD NOT blindly accept a response
+ acknowledgement for a given response. However it is considered safe
+ to accept a response acknowledgement for a given response, when that
+ response acknowledgement is sent by the same entity as the command
+ that generated that response.
+
+ It should be noted, that use of response acknowledgments in commands
+ (as opposed to the Response Acknowledgement response following a
+ provisional response) is OPTIONAL. The benefit of using it is that
+ it reduces overall memory consumption. However, in order to avoid
+ large messages, implementations SHOULD NOT generate large response
+
+
+
+Andreasen & Foster Informational [Page 113]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ acknowledgement lists. One strategy is to manage responses to
+ commands on a per endpoint basis. A command for an endpoint can
+ confirm a response to an older command for that same endpoint.
+ Responses to commands with wildcarded endpoint names can be confirmed
+ selectively with due consideration to message sizes, or alternatively
+ simply not be acknowledged (unless the response explicitly required a
+ Response Acknowledgement). Care must be taken to not confirm the
+ same response twice or a response that is more than T-HIST seconds
+ old.
+
+ The "confirmed transaction-id ranges" values SHALL NOT be used if
+ more than T-HIST seconds have elapsed since the entity issued its
+ last response to the other entity, or when an entity resumes
+ operation. In this situation, commands MUST be accepted and
+ processed, without any test on the transaction-id.
+
+ Commands that carry the "Response Acknowledgement attribute" may be
+ transmitted in disorder. The union of the "confirmed transaction-id
+ ranges" received in recent messages SHALL be retained.
+
+3.5.3 Computing Retransmission Timers
+
+ It is the responsibility of the requesting entity to provide suitable
+ time outs for all outstanding commands, and to retry commands when
+ time outs have been exceeded. Furthermore, when repeated commands
+ fail to be acknowledged, it is the responsibility of the requesting
+ entity to seek redundant services and/or clear existing or pending
+ associations.
+
+ The specification purposely avoids specifying any value for the
+ retransmission timers. These values are typically network dependent.
+ The retransmission timers SHOULD normally estimate the timer by
+ measuring the time spent between the sending of a command and the
+ return of the first response to the command. At a minimum, a
+ retransmission strategy involving exponential backoff MUST be
+ implemented. One possibility is to use the algorithm implemented in
+ TCP/IP, which uses two variables:
+
+ * the average acknowledgement delay, AAD, estimated through an
+ exponentially smoothed average of the observed delays,
+
+ * the average deviation, ADEV, estimated through an exponentially
+ smoothed average of the absolute value of the difference between
+ the observed delay and the current average.
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 114]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The retransmission timer, RTO, in TCP, is set to the sum of the
+ average delay plus N times the average deviation, where N is a
+ constant. In MGCP, the maximum value of the timer SHOULD however be
+ bounded, in order to guarantee that no repeated packet will be
+ received by the gateways after T-HIST seconds. A suggested maximum
+ value for RTO (RTO-MAX) is 4 seconds. Implementers SHOULD consider
+ bounding the minimum value of this timer as well [19].
+
+ After any retransmission, the MGCP entity SHOULD do the following:
+
+ * It should double the estimated value of the acknowledgement delay
+ for this transaction, T-DELAY.
+
+ * It should compute a random value, uniformly distributed between 0.5
+ T-DELAY and T-DELAY.
+
+ * It should set the retransmission timer (RTO) to the minimum of:
+ - the sum of that random value and N times the average deviation,
+ - RTO-MAX.
+
+ This procedure has two effects. Because it includes an exponentially
+ increasing component, it will automatically slow down the stream of
+ messages in case of congestion. Because it includes a random
+ component, it will break the potential synchronization between
+ notifications triggered by the same external event.
+
+ Note that the estimators AAD and ADEV SHOULD NOT be updated for
+ transactions that involve retransmissions. Also, the first new
+ transmission following a successful retransmission SHOULD use the RTO
+ for that last retransmission. If this transmission succeeds without
+ any retransmissions, the AAD and ADEV estimators are updated and RTO
+ is determined as usual again. See, e.g., [18] for further details.
+
+3.5.4 Maximum Datagram Size, Fragmentation and Reassembly
+
+ MGCP messages being transmitted over UDP rely on IP for fragmentation
+ and reassembly of large datagrams. The maximum theoretical size of
+ an IP datagram is 65535 bytes. With a 20-byte IP header and an 8-
+ byte UDP header, this leaves us with a maximum theoretical MGCP
+ message size of 65507 bytes when using UDP.
+
+ However, IP does not require a host to receive IP datagrams larger
+ than 576 bytes [21], which would provide an unacceptably small MGCP
+ message size. Consequently, MGCP mandates that implementations MUST
+ support MGCP datagrams up to at least 4000 bytes, which requires the
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 115]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ corresponding IP fragmentation and reassembly to be supported. Note,
+ that the 4000 byte limit applies to the MGCP level. Lower layer
+ overhead will require support for IP datagrams that are larger than
+ this: UDP and IP overhead will be at least 28 bytes, and, e.g., use
+ of IPSec will add additional overhead.
+
+ It should be noted, that the above applies to both Call Agents and
+ endpoints. Call Agents can audit endpoints to determine if they
+ support larger MGCP datagrams than specified above. Endpoints do
+ currently not have a similar capability to determine if a Call Agent
+ supports larger MGCP datagram sizes.
+
+3.5.5 Piggybacking
+
+ There are cases when a Call Agent will want to send several messages
+ at the same time to the same gateways, and vice versa. When several
+ MGCP messages have to be sent in the same datagram, they MUST be
+ separated by a line of text that contains a single dot, as in for
+ example:
+
+ 200 2005 OK
+ .
+ DLCX 1244 card23/21@tgw-7.example.net MGCP 1.0
+ C: A3C47F21456789F0
+ I: FDE234C8
+
+ The piggybacked messages MUST be processed exactly as if they had
+ been received one at a time in several separate datagrams. Each
+ message in the datagram MUST be processed to completion and in order
+ starting with the first message, and each command MUST be responded
+ to. Errors encountered in a message that was piggybacked MUST NOT
+ affect any of the other messages received in that datagram - each
+ message is processed on its own.
+
+ Piggybacking can be used to achieve two things:
+
+ * Guaranteed in-order delivery and processing of messages.
+
+ * Fate sharing of message delivery.
+
+ When piggybacking is used to guarantee in-order delivery of messages,
+ entities MUST ensure that this in-order delivery property is retained
+ on retransmissions of the individual messages. An example of this is
+ when multiple Notify's are sent using piggybacking (as described in
+ Section 4.4.1).
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 116]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Fate sharing of message delivery ensures that either all the messages
+ are delivered, or none of them are delivered. When piggybacking is
+ used to guarantee this fate-sharing, entities MUST also ensure that
+ this property is retained upon retransmission. For example, upon
+ receiving a Notify from an endpoint operating in lockstep mode, the
+ Call Agent may wish to send the response and a new
+ NotificationRequest command in a single datagram to ensure message
+ delivery fate-sharing of the two.
+
+3.5.6 Provisional Responses
+
+ Executing some transactions may require a long time. Long execution
+ times may interact with the timer based retransmission procedure.
+
+ This may result either in an inordinate number of retransmissions, or
+ in timer values that become too long to be efficient.
+
+ Gateways (and Call Agents) that can predict that a transaction will
+ require a long execution time SHOULD send a provisional response with
+ response code 100. As a guideline, a transaction that requires
+ external communication to complete, e.g., network resource
+ reservation, SHOULD issue a provisional response. Furthermore
+ entities SHOULD send a provisional response if they receive a
+ repetition of a transaction that has not yet finished executing.
+
+ Gateways (or Call Agents) that start building up queues of
+ transactions to be executed may send a provisional response with
+ response code 101 to indicate this (see Section 4.4.8 for further
+ details).
+
+ Pure transactional semantics would imply, that provisional responses
+ SHOULD NOT return any other information than the fact that the
+ transaction is currently executing, however an optimistic approach
+ allowing some information to be returned enables a reduction in the
+ delay that would otherwise be incurred in the system.
+
+ In order to reduce the delay in the system, it is RECOMMENDED to
+ include a connection identifier and session description in a 100
+ provisional response to the CreateConnection command. If a session
+ description would be returned by the ModifyConnection command, the
+ session description SHOULD be included in the provisional response
+ here as well. If the transaction completes successfully, the
+ information returned in the provisional response MUST be repeated in
+ the final response. It is considered a protocol error not to repeat
+ this information or to change any of the previously supplied
+ information in a successful response. If the transaction fails, an
+ error code is returned - the information returned previously is no
+ longer valid.
+
+
+
+Andreasen & Foster Informational [Page 117]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ A currently executing CreateConnection or ModifyConnection
+ transaction MUST be cancelled if a DeleteConnection command for the
+ endpoint is received. In that case, a final response for the
+ cancelled transaction SHOULD still be returned automatically (error
+ code 407 - transaction aborted, is RECOMMENDED), and a final response
+ for the cancelled transaction MUST be returned if a retransmission of
+ the cancelled transaction is detected (see also Section 4.4.4).
+
+ MGCP entities that receive a provisional response SHALL switch to a
+ longer repetition timer (LONGTRAN-TIMER) for that transaction. The
+ purpose of this timer is primarily to detect processing failures.
+ The default value of LONGTRAN-TIMER is 5 seconds, however the
+ provisioning process may alter this. Note, that retransmissions MUST
+ still satisfy the timing requirements specified in Section 3.5.1 and
+ 3.5.3. Consequently LONGTRAN-TIMER MUST be smaller than T-HIST (it
+ should in fact be considerably smaller). Also, entities MUST NOT let
+ a transaction run forever. A transaction that is timed out by the
+ entity SHOULD return error code 406 (transaction time-out). Per the
+ definition of T-HIST (Section 3.5.1), the maximum transaction
+ execution time is smaller than T-HIST (in a network with low delay,
+ it can reasonably safely be approximated as T-HIST minus T-MAX), and
+ a final response should be received no more than T-HIST seconds after
+ the command was sent initially. Nevertheless, entities SHOULD wait
+ for 2*T-HIST seconds before giving up on receiving a final response.
+ Retransmission of the command MUST still cease after T-MAX seconds
+ though. If a response is not received, the outcome of the
+ transaction is not known. If the entity sending the command was a
+ gateway, it now becomes "disconnected" and SHALL initiate the
+ "disconnected" procedure (see Section 4.4.7).
+
+ When the transaction finishes execution, the final response is sent
+ and the by now obsolete provisional response is deleted. In order to
+ ensure rapid detection of a lost final response, final responses
+ issued after provisional responses for a transaction SHOULD be
+ acknowledged (unfortunately older RFC 2705 implementations may not do
+ this, which is the only reason it is not an absolute requirement).
+
+ The endpoint SHOULD therefore include an empty "ResponseAck"
+ parameter in those, and only those, final responses. The presence of
+ the "ResponseAck" parameter in the final response SHOULD trigger a
+ "Response Acknowledgement" response to be sent back to the endpoint.
+ The Response Acknowledgement" response will then include the
+ transaction-id of the response it acknowledges in the response
+ header. Note that, for backwards compatibility, entities cannot
+ depend on receiving such a "response acknowledgement", however it is
+ strongly RECOMMENDED to support this behavior, as excessive delays in
+ case of packet loss as well as excessive retransmissions may occur
+ otherwise.
+
+
+
+Andreasen & Foster Informational [Page 118]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Receipt of a "Response Acknowledgement" response is subject to the
+ same time-out and retransmission strategies and procedures as
+ responses to commands, i.e., the sender of the final response will
+ retransmit it if a "Response Acknowledgement" is not received in
+ time. For backwards compatibility, failure to receive a "response
+ acknowledgement" SHOULD NOT affect the roundtrip time estimates for
+ subsequent commands, and furthermore MUST NOT lead to the endpoint
+ becoming "disconnected". The "Response Acknowledgment" response is
+ never acknowledged.
+
+4. States, Failover and Race Conditions
+
+ In order to implement proper call signaling, the Call Agent must keep
+ track of the state of the endpoint, and the gateway must make sure
+ that events are properly notified to the Call Agent. Special
+ conditions exist when the gateway or the Call Agent are restarted:
+ the gateway must be redirected to a new Call Agent during "failover"
+ procedures, the Call Agent must take special action when the gateway
+ is taken offline, or restarted.
+
+4.1 Failover Assumptions and Highlights
+
+ The following protocol highlights are important to understanding Call
+ Agent fail-over mechanisms:
+
+ * Call Agents are identified by their domain name (and optional
+ port), not their network addresses, and several addresses can be
+ associated with a domain name.
+
+ * An endpoint has one and only one Call Agent associated with it at
+ any given point in time. The Call Agent associated with an
+ endpoint is the current value of the "notified entity". The
+ "notified entity" determines where the gateway will send it's
+ commands. If the "notified entity" does not include a port number,
+ 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".
+
+
+
+Andreasen & Foster Informational [Page 119]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * 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.
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 120]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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.
+
+
+
+
+
+Andreasen & Foster Informational [Page 121]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+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
+
+
+
+Andreasen & Foster Informational [Page 122]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 123]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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)
+
+
+
+
+
+Andreasen & Foster Informational [Page 124]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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).
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 125]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * 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.
+
+
+
+
+
+Andreasen & Foster Informational [Page 126]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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)
+
+
+
+Andreasen & Foster Informational [Page 127]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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:
+
+
+
+
+Andreasen & Foster Informational [Page 128]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * 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".
+
+
+
+Andreasen & Foster Informational [Page 129]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 130]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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 |
+ +---------------+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 131]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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 RFC 2705, however there are several
+ complications in doing this, and the benefits are questionable. In
+ particular, the RFC 2705 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.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 132]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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.
+
+
+
+Andreasen & Foster Informational [Page 133]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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
+
+
+
+Andreasen & Foster Informational [Page 134]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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.
+
+
+
+Andreasen & Foster Informational [Page 135]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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:
+
+
+
+Andreasen & Foster Informational [Page 136]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * 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.
+
+
+
+Andreasen & Foster Informational [Page 137]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 138]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ ------------------------------------------------------------------
+ | 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) |
+ ------------------------------------------------------------------
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 139]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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
+
+
+
+
+
+Andreasen & Foster Informational [Page 140]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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
+
+
+
+Andreasen & Foster Informational [Page 141]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 142]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+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
+ 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"
+
+
+
+Andreasen & Foster Informational [Page 143]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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.
+
+
+
+Andreasen & Foster Informational [Page 144]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 145]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+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.
+
+
+
+
+Andreasen & Foster Informational [Page 146]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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
+ RFC 2401, using either the IP Authentication Header, defined in RFC
+ 2402, or the IP Encapsulating Security Payload, defined in RFC 2406.
+ The complete MGCP protocol stack would thus include the following
+ layers:
+
+ -------------------------------
+ | MGCP |
+ |-------------------------------|
+ | UDP |
+ |-------------------------------|
+ | IP security |
+ | (authentication or encryption)|
+ |-------------------------------|
+ | IP |
+ |-------------------------------|
+ | transmission media |
+ -------------------------------
+
+ Adequate protection of the connections will be achieved if the
+ gateways and the Call Agents only accept messages for which IP
+ security provided an authentication service. An encryption service
+ will provide additional protection against eavesdropping, thus
+ 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.
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 147]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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.
+
+
+
+
+Andreasen & Foster Informational [Page 148]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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.
+
+
+
+Andreasen & Foster Informational [Page 149]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+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.
+
+
+
+
+Andreasen & Foster Informational [Page 150]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+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.
+
+
+
+
+
+Andreasen & Foster Informational [Page 151]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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
+
+
+
+Andreasen & Foster Informational [Page 152]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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-
+
+
+
+Andreasen & Foster Informational [Page 153]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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.
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 154]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+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.
+
+
+
+Andreasen & Foster Informational [Page 155]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ 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.
+
+
+
+Andreasen & Foster Informational [Page 156]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+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.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 157]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+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 RFC 2705
+
+ RFC 2705 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 RFC 2705 are:
+
+ * Contains several clarifications, editorial changes and resolution
+ of known inconsistencies.
+
+ * Firmed up specification language in accordance with RFC 2119 and
+ added RFC 2119 conventions section.
+
+
+
+Andreasen & Foster Informational [Page 158]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * 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".
+
+
+
+Andreasen & Foster Informational [Page 159]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * 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.
+
+
+
+Andreasen & Foster Informational [Page 160]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * 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 RFC 2327
+ 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.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 161]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * 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".
+
+
+
+
+
+Andreasen & Foster Informational [Page 162]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * 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 RFC 2705.
+
+ * 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.
+
+
+
+Andreasen & Foster Informational [Page 163]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * 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, RFC 2026, October 1996.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", RFC
+ 1889, January 1996.
+
+
+
+
+
+Andreasen & Foster Informational [Page 164]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ [4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
+ with Minimal Control", RFC 1890, January 1996.
+
+ [5] Handley, M. and V. Jacobson, "SDP: Session Description
+ Protocol", RFC 2327, April 1998.
+
+ [6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
+ Protocol", RFC 2974, October 2000.
+
+ [7] Rosenberg, J., Camarillo, G., Johnston, A., Peterson, J.,
+ Sparks, R., Handley, M., Schulzrinne, H. and E. Schooler,
+ "Session Initiation Protocol (SIP)", RFC 3261, June 2002.
+
+ [8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
+ Protocol (RTSP)", RFC 2326, 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", RFC 2401, November 1998.
+
+ [15] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
+ November 1998.
+
+ [16] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
+ (ESP)", RFC 2406, November 1998.
+
+ [17] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [18] Stevens, W. Richard, "TCP/IP Illustrated, Volume 1, The
+ Protocols", Addison-Wesley, 1994.
+
+
+
+Andreasen & Foster Informational [Page 165]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ [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, RFC 1122, 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", RFC 2434, October 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 166]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+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 RFC 2234. The syntax makes use of the core rules defined
+ in RFC 2234, Section 6.1, which are not included here. Furthermore,
+ the syntax follows the case-sensitivity rules of RFC 2234, 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 RFC 821
+ / "[" IPv4address / IPv6address "]" ; see RFC 2373
+
+; Rewritten to ABNF from RFC 821
+number = 1*DIGIT
+
+;From RFC 2373
+IPv6address = hexpart [ ":" IPv4address ]
+IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
+
+
+
+Andreasen & Foster Informational [Page 167]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+; this production, while occurring in RFC2373, is not referenced
+; IPv6prefix = hexpart "/" 1*2DIGIT
+hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
+hexseq = hex4 *( ":" hex4)
+hex4 = 1*4HEXDIG
+
+MGCPversion = "MGCP" 1*(WSP) 1*(DIGIT) "." 1*(DIGIT)
+ [1*(WSP) ProfileName]
+ProfileName = VCHAR *( WSP / VCHAR)
+
+MGCPParameter = ParameterValue EOL
+
+; Check infoCode if more parameter values defined
+; Most optional values can only be omitted when auditing
+ParameterValue = ("K" ":" 0*(WSP) [ResponseAck])
+ / ("B" ":" 0*(WSP) [BearerInformation])
+ / ("C" ":" 0*(WSP) CallId)
+ / ("I" ":" 0*(WSP) [ConnectionId])
+ / ("N" ":" 0*(WSP) [NotifiedEntity])
+ / ("X" ":" 0*(WSP) [RequestIdentifier])
+ / ("L" ":" 0*(WSP) [LocalConnectionOptions])
+ / ("M" ":" 0*(WSP) ConnectionMode)
+ / ("R" ":" 0*(WSP) [RequestedEvents])
+ / ("S" ":" 0*(WSP) [SignalRequests])
+ / ("D" ":" 0*(WSP) [DigitMap])
+ / ("O" ":" 0*(WSP) [ObservedEvents])
+ / ("P" ":" 0*(WSP) [ConnectionParameters])
+ / ("E" ":" 0*(WSP) ReasonCode)
+ / ("Z" ":" 0*(WSP) [SpecificEndpointID])
+ / ("Z2" ":" 0*(WSP) SecondEndpointID)
+ / ("I2" ":" 0*(WSP) SecondConnectionID)
+ / ("F" ":" 0*(WSP) [RequestedInfo])
+ / ("Q" ":" 0*(WSP) QuarantineHandling)
+ / ("T" ":" 0*(WSP) [DetectEvents])
+ / ("RM" ":" 0*(WSP) RestartMethod)
+ / ("RD" ":" 0*(WSP) RestartDelay)
+ / ("A" ":" 0*(WSP) [Capabilities])
+ / ("ES" ":" 0*(WSP) [EventStates])
+ / ("PL" ":" 0*(WSP) [PackageList]) ; Auditing only
+ / ("MD" ":" 0*(WSP) MaxMGCPDatagram) ; Auditing only
+ / (extensionParameter ":" 0*(WSP) [parameterString])
+
+; A final response may include an empty ResponseAck
+ResponseAck = confirmedTransactionIdRange
+ *( "," 0*(WSP) confirmedTransactionIdRange )
+
+confirmedTransactionIdRange = transaction-id ["-" transaction-id]
+
+
+
+
+Andreasen & Foster Informational [Page 168]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+BearerInformation = BearerAttribute 0*("," 0*(WSP) BearerAttribute)
+BearerAttribute = ("e" ":" BearerEncoding)
+ / (BearerExtensionName [":" BearerExtensionValue])
+BearerExtensionName = PackageLCOExtensionName
+BearerExtensionValue = LocalOptionExtensionValue
+BearerEncoding = "A" / "mu"
+
+CallId = 1*32(HEXDIG)
+
+; The audit request response may include a list of identifiers
+ConnectionId = 1*32(HEXDIG) 0*("," 0*(WSP) 1*32(HEXDIG))
+SecondConnectionID = ConnectionId
+
+NotifiedEntity = [LocalName "@"] DomainName [":" portNumber]
+LocalName = LocalEndpointName ; No internal structure
+
+portNumber = 1*5(DIGIT)
+
+RequestIdentifier = 1*32(HEXDIG)
+
+LocalConnectionOptions = LocalOptionValue 0*(WSP)
+ 0*("," 0*(WSP) LocalOptionValue 0*(WSP))
+LocalOptionValue = ("p" ":" packetizationPeriod)
+ / ("a" ":" compressionAlgorithm)
+ / ("b" ":" bandwidth)
+ / ("e" ":" echoCancellation)
+ / ("gc" ":" gainControl)
+ / ("s" ":" silenceSuppression)
+ / ("t" ":" typeOfService)
+ / ("r" ":" resourceReservation)
+ / ("k" ":" encryptiondata)
+ / ("nt" ":" ( typeOfNetwork /
+ supportedTypeOfNetwork))
+ / (LocalOptionExtensionName
+ [":" LocalOptionExtensionValue])
+
+Capabilities = CapabilityValue 0*(WSP)
+ 0*("," 0*(WSP) CapabilityValue 0*(WSP))
+CapabilityValue = LocalOptionValue
+ / ("v" ":" supportedPackages)
+ / ("m" ":" supportedModes)
+
+PackageList = pkgNameAndVers 0*("," pkgNameAndVers)
+pkgNameAndVers = packageName ":" packageVersion
+packageVersion = 1*(DIGIT)
+
+packetizationPeriod = 1*4(DIGIT) ["-" 1*4(DIGIT)]
+compressionAlgorithm = algorithmName 0*(";" algorithmName)
+
+
+
+Andreasen & Foster Informational [Page 169]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+algorithmName = 1*(SuitableLCOCharacter)
+bandwidth = 1*4(DIGIT) ["-" 1*4(DIGIT)]
+echoCancellation = "on" / "off"
+gainControl = "auto" / ["-"] 1*4(DIGIT)
+silenceSuppression = "on" / "off"
+typeOfService = 1*2(HEXDIG) ; 1 hex only for capabilities
+resourceReservation = "g" / "cl" / "be"
+
+;encryption parameters are coded as in SDP (RFC 2327)
+;NOTE: encryption key may contain an algorithm as specified in RFC 1890
+encryptiondata = ( "clear" ":" encryptionKey )
+ / ( "base64" ":" encodedEncryptionKey )
+ / ( "uri" ":" URItoObtainKey )
+ / ( "prompt" ) ; defined in SDP, not usable in MGCP!
+
+encryptionKey = 1*(SuitableLCOCharacter) / quotedString
+; See RFC 2045
+encodedEncryptionKey = 1*(ALPHA / DIGIT / "+" / "/" / "=")
+URItoObtainKey = 1*(SuitableLCOCharacter) / quotedString
+
+typeOfNetwork = "IN" / "ATM" / "LOCAL" / OtherTypeOfNetwork
+; Registered with IANA - see RFC 2327
+OtherTypeOfNetwork = 1*(SuitableLCOCharacter)
+supportedTypeOfNetwork = typeOfNetwork *(";" typeOfNetwork)
+
+supportedModes = ConnectionMode 0*(";" ConnectionMode)
+
+supportedPackages = packageName 0*(";" packageName)
+
+packageName = 1*(ALPHA / DIGIT / HYPHEN) ; Hyphen neither first or last
+
+LocalOptionExtensionName = VendorLCOExtensionName
+ / PackageLCOExtensionName
+ / OtherLCOExtensionName
+VendorLCOExtensionName = "x" ("+"/"-") 1*32(SuitableExtLCOCharacter)
+PackageLCOExtensionName = packageName "/"
+ 1*32(SuitablePkgExtLCOCharacter)
+; must not start with "x-" or "x+"
+OtherLCOExtensionName = 1*32(SuitableExtLCOCharacter)
+
+LocalOptionExtensionValue = (1*(SuitableExtLCOValChar)
+ / quotedString)
+ *(";" (1*(SuitableExtLCOValChar)
+ / quotedString))
+
+;Note: No "data" mode.
+ConnectionMode = "sendonly" / "recvonly" / "sendrecv"
+ / "confrnce" / "inactive" / "loopback"
+
+
+
+Andreasen & Foster Informational [Page 170]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ / "conttest" / "netwloop" / "netwtest"
+ / ExtensionConnectionMode
+ExtensionConnectionMode = PkgExtConnectionMode
+PkgExtConnectionMode = packageName "/" 1*(ALPHA / DIGIT)
+
+RequestedEvents = requestedEvent 0*("," 0*(WSP) requestedEvent)
+requestedEvent = (eventName ["(" requestedActions ")"])
+ / (eventName "(" requestedActions ")"
+ "(" eventParameters ")" )
+eventName = [(packageName / "*") "/"]
+ (eventId / "all" / eventRange
+ / "*" / "#") ; for DTMF
+ ["@" (ConnectionId / "$" / "*")]
+eventId = 1*(ALPHA / DIGIT / HYPHEN) ; Hyphen neither first nor last
+eventRange = "[" 1*(DigitMapLetter / (DIGIT "-" DIGIT) /
+ (DTMFLetter "-" DTMFLetter)) "]"
+DTMFLetter = "A" / "B" / "C" / "D"
+
+requestedActions = requestedAction 0*("," 0*(WSP) requestedAction)
+requestedAction = "N" / "A" / "D" / "S" / "I" / "K"
+ / "E" "(" EmbeddedRequest ")"
+ / ExtensionAction
+ExtensionAction = PackageExtAction
+PackageExtAction = packageName "/" Action ["(" ActionParameters ")"]
+Action = 1*ALPHA
+ActionParameters = eventParameters ; May contain actions
+
+;NOTE: Should tolerate different order when receiving, e.g., for NCS.
+EmbeddedRequest = ( "R" "(" EmbeddedRequestList ")"
+ ["," 0*(WSP) "S" "(" EmbeddedSignalRequest ")"]
+ ["," 0*(WSP) "D" "(" EmbeddedDigitMap ")"] )
+ / ( "S" "(" EmbeddedSignalRequest ")"
+ ["," 0*(WSP) "D" "(" EmbeddedDigitMap ")"] )
+ / ( "D" "(" EmbeddedDigitMap ")" )
+
+EmbeddedRequestList = RequestedEvents
+EmbeddedSignalRequest = SignalRequests
+EmbeddedDigitMap = DigitMap
+
+SignalRequests = SignalRequest 0*("," 0*(WSP) SignalRequest )
+SignalRequest = eventName [ "(" eventParameters ")" ]
+
+eventParameters = eventParameter 0*("," 0*(WSP) eventParameter)
+eventParameter = eventParameterValue
+ / eventParameterName "=" eventParameter
+ / eventParameterName "(" eventParameters ")"
+eventParameterString = 1*(SuitableEventParamCharacter)
+eventParameterName = eventParameterString
+
+
+
+Andreasen & Foster Informational [Page 171]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+eventParameterValue = eventParameterString / quotedString
+
+DigitMap = DigitString / "(" DigitStringList ")"
+DigitStringList = DigitString 0*( "|" DigitString )
+DigitString = 1*(DigitStringElement)
+DigitStringElement = DigitPosition ["."]
+DigitPosition = DigitMapLetter / DigitMapRange
+; NOTE "X" is now included
+DigitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / "T"
+ / "X" / ExtensionDigitMapLetter
+ExtensionDigitMapLetter = "E" / "F" / "G" / "H" / "I" / "J" / "K"
+ / "L" / "M" / "N" / "O" / "P" / "Q" / "R"
+ / "S" / "U" / "V" / "W" / "Y" / "Z"
+; NOTE "[x]" is now allowed
+DigitMapRange = "[" 1*DigitLetter "]"
+DigitLetter = *((DIGIT "-" DIGIT) / DigitMapLetter)
+
+ObservedEvents = SignalRequests
+
+EventStates = SignalRequests
+
+ConnectionParameters = ConnectionParameter
+ 0*( "," 0*(WSP) ConnectionParameter )
+
+ConnectionParameter = ( "PS" "=" packetsSent )
+ / ( "OS" "=" octetsSent )
+ / ( "PR" "=" packetsReceived )
+ / ( "OR" "=" octetsReceived )
+ / ( "PL" "=" packetsLost )
+ / ( "JI" "=" jitter )
+ / ( "LA" "=" averageLatency )
+ / ( ConnectionParameterExtensionName
+ "=" ConnectionParameterExtensionValue )
+packetsSent = 1*9(DIGIT)
+octetsSent = 1*9(DIGIT)
+packetsReceived = 1*9(DIGIT)
+octetsReceived = 1*9(DIGIT)
+packetsLost = 1*9(DIGIT)
+jitter = 1*9(DIGIT)
+averageLatency = 1*9(DIGIT)
+
+ConnectionParameterExtensionName = VendorCPExtensionName
+ / PackageCPExtensionName
+VendorCPExtensionName = "X" "-" 2*ALPHA
+PackageCPExtensionName = packageName "/" CPName
+CPName = 1*(ALPHA / DIGIT / HYPHEN)
+ConnectionParameterExtensionValue = 1*9(DIGIT)
+
+
+
+
+Andreasen & Foster Informational [Page 172]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+MaxMGCPDatagram = 1*9(DIGIT)
+
+ReasonCode = 3DIGIT
+ [1*(WSP) "/" packageName] ; Only for 8xx
+ [WSP 1*(%x20-7E)]
+
+SpecificEndpointID = endpointName
+SecondEndpointID = endpointName
+
+RequestedInfo = infoCode 0*("," 0*(WSP) infoCode)
+
+infoCode = "B" / "C" / "I" / "N" / "X" / "L" / "M" / "R" / "S"
+ / "D" / "O" / "P" / "E" / "Z" / "Q" / "T" / "RC" / "LC"
+ / "A" / "ES" / "RM" / "RD" / "PL" / "MD" / extensionParameter
+
+QuarantineHandling = loopControl / processControl
+ / (loopControl "," 0*(WSP) processControl )
+loopControl = "step" / "loop"
+processControl = "process" / "discard"
+
+DetectEvents = SignalRequests
+
+RestartMethod = "graceful" / "forced" / "restart" / "disconnected"
+ / "cancel-graceful" / extensionRestartMethod
+extensionRestartMethod = PackageExtensionRM
+PackageExtensionRM = packageName "/" 1*32(ALPHA / DIGIT / HYPHEN)
+RestartDelay = 1*6(DIGIT)
+
+extensionParameter = VendorExtensionParameter
+ / PackageExtensionParameter
+ / OtherExtensionParameter
+VendorExtensionParameter = "X" ("-"/"+") 1*6(ALPHA / DIGIT)
+PackageExtensionParameter = packageName "/"
+ 1*32(ALPHA / DIGIT / HYPHEN)
+; must not start with "x-" or x+"
+OtherExtensionParameter = 1*32(ALPHA / DIGIT / HYPHEN)
+
+;If first character is a double-quote, then it is a quoted-string
+parameterString = (%x21 / %x23-7F) *(%x20-7F) ; first and last must not
+ ; be white space
+ / quotedString
+
+MGCPResponse = MGCPResponseLine 0*(MGCPParameter)
+ *2(EOL *SDPinformation)
+
+MGCPResponseLine = responseCode 1*(WSP) transaction-id
+ [1*(WSP) "/" packageName] ; Only for 8xx
+ [WSP responseString] EOL
+
+
+
+Andreasen & Foster Informational [Page 173]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+responseCode = 3DIGIT
+responseString = *(%x20-7E)
+
+SuitablePkgExtLCOCharacter = SuitableLCOCharacter
+
+SuitableExtLCOCharacter = DIGIT / ALPHA / "+" / "-" / "_" / "&"
+ / "!" / "'" / "|" / "=" / "#" / "?"
+ / "." / "$" / "*" / "@" / "[" / "]"
+ / "^" / "`" / "{" / "}" / "~"
+
+SuitableLCOCharacter = SuitableExtLCOCharacter / "/"
+
+SuitableExtLCOValChar = SuitableLCOCharacter / ":"
+
+; VCHAR except """, "(", ")", ",", and "="
+SuitableEventParamCharacter = %x21 / %x23-27 / %x2A-2B
+ / %x2D-3C / %x3E-7E
+
+; NOTE: UTF8 encoded
+quotedString = DQUOTE 0*(quoteEscape / quoteChar) DQUOTE
+quoteEscape = DQUOTE DQUOTE
+quoteChar = (%x00-21 / %x23-FF)
+
+EOL = CRLF / LF
+
+HYPHEN = "-"
+
+; See RFC 2327 for proper SDP grammar instead.
+SDPinformation = SDPLine CRLF *(SDPLine CRLF) ; see RFC 2327
+SDPLine = 1*(%x01-09 / %x0B / %x0C / %x0E-FF) ; for proper def.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 174]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+Appendix B: Base Package
+
+ Package name: B
+ Version: 0
+
+ The MGCP specification defines a base package which contains a set of
+ events and extension parameters that are of general use to the
+ protocol. Although not required, it is highly RECOMMENDED to support
+ this package as it provides important functionality for the base
+ protocol.
+
+B.1 Events
+
+ The table below lists the events:
+
+ ------------------------------------------------------------------
+ | Symbol | Definition | R | S Duration |
+ |---------|----------------------------|-----|---------------------|
+ | enf(##) | embedded RQNT failure | x | |
+ | oef | observed events full | x | |
+ | qbo | quarantine buffer overflow | x | |
+ ------------------------------------------------------------------
+
+ The events are defined as follows:
+
+ Embedded NotificationRequest failure (enf):
+ The Embedded NotificationRequest Failure (enf) event is generated
+ when an embedded Notification Request failure occurs. When the
+ event is requested, it should be as part of the Embedded
+ NotificationRequest itself. When the event is reported, it may be
+ parameterized with an error code (see Section 2.4) detailing the
+ error that occurred. When requested, it cannot be parameterized.
+
+ Observed events full (oef):
+ The event is generated when the endpoint is unable to accumulate
+ any more events in the list of ObservedEvents. If this event
+ occurs, and it is not used to trigger a Notify, subsequent events
+ that should have been added to the list will be lost.
+
+ Quarantine buffer overflow (qbo):
+ The event is generated when the quarantine buffer overflows and one
+ or more events have been lost.
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 175]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+B.2 Extension Parameters
+
+B.2.1 PersistentEvents
+
+ PersistentEvents: A list of events that the gateway is requested to
+ detect and report persistently. The parameter is optional but can be
+ provided in any command where the DetectEvents parameter can be
+ provided. The initial default value of the parameter is empty. When
+ the parameter is omitted from a command, it retains its current
+ value. When the parameter is provided, it completely replaces the
+ current value. Providing an event in this list, is similar (but
+ preferable) to defining that particular event as being persistent.
+ The current list of PersistentEvents will implicitly apply to the
+ current as well as subsequent NotificationRequests, however no glare
+ detection etc. will be performed (similarly to DetectEvents). If an
+ event provided in this list is included in a RequestedEvents list,
+ the action and event parameters used in the RequestedEvents will
+ replace the action and event parameters associated with the event in
+ the PersistentEvents list for the life of the RequestedEvents list,
+ after which the PersistentEvents action and event parameters are
+ restored. Events with event states requested through this parameter
+ will be included in the list of EventStates if audited.
+
+ PersistentEvents can also be used to detect events on connections.
+ Use of the "all connections" wildcard is straightforward, whereas
+ using PersistentEvents with one or more specific connections must be
+ considered carefully. Once the connection in question is deleted, a
+ subsequent NotificationRequest without a new PersistentEvents value
+ will fail (error code 515 - incorrect connection-id, is RECOMMENDED),
+ as it implicitly refers to the deleted connection.
+
+ The parameter generates the relevant error codes from the base
+ protocol, e.g., error code 512 if an unknown event is specified.
+
+ The PersistentEvents parameter can be audited, in which case it will
+ return its current value. Auditing of RequestedEvents is not
+ affected by this extension, i.e., events specified in this list are
+ not automatically reported when auditing RequestedEvents.
+
+ The parameter name for PersistentEvents is "PR" and it is defined by
+ the production:
+
+ PersistentEvents = "PR" ":" 0*WSP [RequestedEvents]
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 176]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The following example illustrates the use of the parameter:
+
+ B/PR: L/hd(N), L/hf(N), L/hu(N), B/enf, B/oef, B/qbo
+
+ which instructs the endpoint to persistently detect and report off-
+ hook, hook-flash, and on-hook. It also instructs the endpoint to
+ persistently detect and report Embedded Notification Request failure,
+ Observed events full, and Quarantine buffer overflow.
+
+B.2.2 NotificationState
+
+ NotificationState is a RequestedInfo parameter that can be audited
+ with the AuditEndpoint command. It can be used to determine if the
+ endpoint is in the notification state or not.
+
+ The parameter is forbidden in any command. In responses, it is a
+ valid response parameter for AuditEndpoint only.
+
+ It is defined by the following grammar:
+
+ NotificationState = "NS" ":" 0*WSP NotificationStateValue
+ NotificationStateValue = "ns" / "ls" / "o"
+
+ It is requested as part of auditing by including the parameter code
+ in RequestedInfo, as in:
+
+ F: B/NS
+
+ The response parameter will contain the value "ns" if the endpoint is
+ in the "notification state", the value "ls" if the endpoint is in the
+ "lockstep state" (i.e., waiting for an RQNT after a response to a
+ NTFY has been received when operating in "step" mode), or the value
+ "o" otherwise, as for example:
+
+ B/NS: ns
+
+B.3 Verbs
+
+ MGCP packages are not intended to define new commands, however an
+ exception is made in this case in order to add an important general
+ capability currently missing, namely the ability for the gateway to
+ send a generic message to the Call Agent.
+
+ The definition of the new command is:
+
+ ReturnCode
+ <-- Message(EndpointId
+ [, ...])
+
+
+
+Andreasen & Foster Informational [Page 177]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ EndpointId is the name for the endpoint(s) in the gateway which is
+ issuing the Message command. The identifier MUST be a fully
+ qualified endpoint identifier, including the domain name of the
+ gateway. The local part of the endpoint name MUST NOT use the "any
+ of" wildcard.
+
+ The only parameter specified in the definition of the Message command
+ is the EndpointId, however, it is envisioned that extensions will
+ define additional parameters to be used with the Message command.
+ Such extensions MUST NOT alter or otherwise interfere with the normal
+ operation of the basic MGCP protocol. They may however define
+ additional capabilities above and beyond that provided by the basic
+ MGCP protocol. For example, an extension to enable the gateway to
+ audit the packages supported by the Call Agent could be defined,
+ whereas using the Message command as an alternative way of reporting
+ observed events would be illegal, as that would alter the normal MGCP
+ protocol behavior.
+
+ In order to not interfere with normal MGCP operation, lack of a
+ response to the Message command MUST NOT lead the endpoint to become
+ disconnected. The endpoint(s) MUST be prepared to handle this
+ transparently and continue normal processing unaffected.
+
+ If the endpoint(s) receive a response indicating that the Call Agent
+ does not support the Message command, the endpoint(s) MUST NOT send a
+ Message command again until the current "notified entity" has
+ changed. Similarly, if the endpoint(s) receive a response indicating
+ that the Call Agent does not support one or more parameters in the
+ Message command, the endpoint(s) MUST NOT send a Message command with
+ those parameters again until the current "notified entity" has
+ changed.
+
+ The Message command is encoded as MESG, as shown in the following
+ example:
+
+ MESG 1200 aaln/1@rgw.whatever.net MGCP 1.0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 178]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+Appendix C: IANA Considerations
+
+C.1 New MGCP Package Sub-Registry
+
+ The IANA has established a new sub-registry for MGCP packages under
+ http://www.iana.org/assignments/mgcp-packages.
+
+ Packages can be registered with the IANA according to the following
+ procedure:
+
+ The package MUST have a unique string name which MUST NOT start with
+ the two characters "x-" or "x+".
+
+ The package title, name, and version (zero assumed by default) MUST
+ be registered with IANA as well as a reference to the document that
+ describes the package. The document MUST have a stable URL and MUST
+ be contained on a public web server.
+
+ Packages may define one or more Extension Digit Map Letters, however
+ these are taken from a limited and flat name space. To prevent name
+ clashing, IANA SHALL NOT register a package that defines an Extension
+ Digit Map Letter already defined in another package registered by
+ IANA. To ease this task, such packages SHALL contain the line
+ "Extension Digit Map Letters: " followed by a list of the Extension
+ Digit Map Letters defined in the package at the beginning of the
+ package definition.
+
+ A contact name, e-mail and postal address for the package MUST be
+ provided. The contact information SHALL be updated by the defining
+ organization as necessary.
+
+ Finally, prior to registering a package, the IANA MUST have a
+ designated expert [23] review the package. The expert reviewer will
+ send e-mail to the IANA on the overall review determination.
+
+C.2 New MGCP Package
+
+ This document defines a new MGCP Base Package in Appendix B, which
+ has been registered by IANA.
+
+C.3 New MGCP LocalConnectionOptions Sub-Registry
+
+ The IANA has established a new sub-registry for MGCP
+ LocalConnectionOptions under http://www.iana.org/assignments/mgcp-
+ localconnectionoptions.
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 179]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Packages are the preferred extension mechanism, however for backwards
+ compatibility, local connection options beyond those provided in this
+ specification can be registered with IANA. Each such local
+ connection option MUST have a unique string name which MUST NOT start
+ with "x-" or "x+". The local connection option field name and
+ encoding name MUST be registered with IANA as well as a reference to
+ the document that describes the local connection option. The
+ document MUST have a stable URL and MUST be contained on a public web
+ server.
+
+ A contact name, e-mail and postal address for the local connection
+ option MUST be provided. The contact information SHALL be updated by
+ the defining organization as necessary.
+
+ Finally, prior to registering a LocalConnectionOption, the IANA MUST
+ have a designated expert [23] review the LocalConnectionOption. The
+ expert reviewer will send e-mail to the IANA on the overall review
+ determination.
+
+Appendix D: Mode Interactions
+
+ An MGCP endpoint can establish one or more media streams. These
+ streams are either incoming (from a remote endpoint) or outgoing
+ (generated at the handset microphone). The "connection mode"
+ parameter establishes the direction and generation of these streams.
+ When there is only one connection to an endpoint, the mapping of
+ these streams is straightforward; the handset plays the incoming
+ stream over the handset speaker and generates the outgoing stream
+ from the handset microphone signal, depending on the mode parameter.
+
+ However, when several connections are established to an endpoint,
+ there can be many incoming and outgoing streams. Depending on the
+ connection mode used, these streams may interact differently with
+ each other and the streams going to/from the handset.
+
+ The table below describes how different connections SHALL be mixed
+ when one or more connections are concurrently "active". An active
+ connection is here defined as a connection that is in one of the
+ following modes:
+
+ * "send/receive"
+ * "send only"
+ * "receive only"
+ * "conference"
+
+ Connections in "network loopback", "network continuity test", or
+ "inactive" modes are not affected by connections in the "active"
+ modes. The Table uses the following conventions:
+
+
+
+Andreasen & Foster Informational [Page 180]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ * Ai is the incoming media stream from Connection A
+ * Bi is the incoming media stream from Connection B
+ * Hi is the incoming media stream from the Handset Microphone
+ * Ao is the outgoing media stream to Connection A
+ * Bo is the outgoing media stream to Connection B
+ * Ho is the outgoing media stream to the Handset earpiece
+ * NA indicates no stream whatsoever (assuming there are no signals
+ applied on the connection)
+
+ "netw" in the following table indicates either "netwloop" or
+ "netwtest" mode.
+
+ -------------------------------------------------------------
+ | | Connection A Mode |
+ | |-----------------------------------------------------
+ | |sendonly|recvonly|sendrecv|confrnce|inactive| netw |
+ |-------|-----------------------------------------------------|
+ | |Send | Ao=Hi | Ao=NA | Ao=Hi | Ao=Hi | Ao=NA | Ao=Ai |
+ |C|only | Bo=Hi | Bo=Hi | Bo=Hi | Bo=Hi | Bo=Hi | Bo=Hi |
+ |o| | Ho=NA | Ho=Ai | Ho=Ai | Ho=Ai | Ho=NA | Ho=NA |
+ |n|-----------------------------------------------------------
+ |n|recv | |Ao=NA |Ao=Hi |Ao=Hi | Ao=NA | Ao=Ai |
+ |e|only | |Bo=NA |Bo=NA |Bo=NA | Bo=NA | Bo=NA |
+ |c| | |Ho=Ai+Bi|Ho=Ai+Bi|Ho=Ai+Bi| Ho=Bi | Ho=Bi |
+ |t|-----------------------------------------------------------|
+ |i|send | | |Ao=Hi |Ao=Hi | Ao=NA | Ao=Ai |
+ |o|recv | | |Bo=Hi |Bo=Hi | Bo=Hi | Bo=Hi |
+ |n| | | |Ho=Ai+Bi|Ho=Ai+Bi| Ho=Bi | Ho=Bi |
+ | |-----------------------------------------------------------|
+ |B|conf | | | |Ao=Hi+Bi| Ao=NA | Ao=Ai |
+ | |rnce | | | |Bo=Hi+Ai| Bo=Hi | Bo=Hi |
+ |M| | | | |Ho=Ai+Bi| Ho=Bi | Ho=Bi |
+ |o|-----------------------------------------------------------|
+ |d|Inac | | | | | Ao=NA | Ao=Ai |
+ |e|tive | | | | | Bo=NA | Bo=NA |
+ | | | | | | | Ho=NA | Ho=NA |
+ | |-----------------------------------------------------------|
+ | |netw | | | | | | Ao=Ai |
+ | | | | | | | | Bo=Bi |
+ | | | | | | | | Ho=NA |
+ -------------------------------------------------------------
+
+ If there are three or more "active" connections they will still
+ interact as defined in the table above with the outgoing media
+ streams mixed for each interaction (union of all streams). If
+ internal resources are used up and the streams cannot be mixed, the
+ gateway MUST return an error (error code 403 or 502, not enough
+ resources, are RECOMMENDED).
+
+
+
+Andreasen & Foster Informational [Page 181]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+Appendix E: Endpoint Naming Conventions
+
+ The following sections provide some RECOMMENDED endpoint naming
+ conventions.
+
+E.1 Analog Access Line Endpoints
+
+ The string "aaln", should be used as the first term in a local
+ endpoint name for analog access line endpoints. Terms following
+ "aaln" should follow the physical hierarchy of the gateway so that if
+ the gateway has a number of RJ11 ports, the local endpoint name could
+ look like the following:
+
+ aaln/#
+
+ where "#" is the number of the analog line (RJ11 port) on the
+ gateway.
+
+ On the other hand, the gateway may have a number of physical plug-in
+ units, each of which contain some number of RJ11 ports, in which
+ case, the local endpoint name might look like the following:
+
+ aaln/<unit #>/#
+
+ where <unit #> is the number of the plug in unit in the gateway and
+ "#" is the number of the analog line (RJ11 port) on that unit.
+ Leading zeroes MUST NOT be used in any of the numbers ("#") above.
+
+E.2 Digital Trunks
+
+ The string "ds" should be used for the first term of digital
+ endpoints with a naming convention that follows the physical and
+ digital hierarchy such as:
+
+ ds/<unit-type1>-<unit #>/<unit-type2>-<unit #>/.../<channel #>
+
+ where: <unit-type> identifies the particular hierarchy level. Some
+ example values of <unit-type> are: "s", "su", "oc3", "ds3", "e3",
+ "ds2", "e2", "ds1", "e1" where "s" indicates a slot number and "su"
+ indicates a sub-unit within a slot. Leading zeroes MUST NOT be used
+ in any of the numbers ("#") above.
+
+ The <unit #> is a decimal number which is used to reference a
+ particular instance of a <unit-type> at that level of the hierarchy.
+ The number of levels and naming of those levels is based on the
+ physical hierarchy within the media gateway.
+
+
+
+
+
+Andreasen & Foster Informational [Page 182]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+E.3 Virtual Endpoints
+
+ Another type of endpoint is one that is not associated with a
+ physical interface (such as an analog or digital endpoint). This
+ type of endpoint is called a virtual endpoint and is often used to
+ represent some DSP resources that gives the endpoint some capability.
+ Examples are announcement, IVR or conference bridge devices. These
+ devices may have multiple instances of DSP functions so that a
+ possible naming convention is:
+
+ <virtual-endpoint-type>/<endpoint-#>
+
+ where <virtual-endpoint-type> may be some string representing the
+ type of endpoint (such as "ann" for announcement server or "cnf" for
+ conference server) and <endpoint-#> would identify a particular
+ virtual endpoint within the device. Leading zeroes MUST NOT be used
+ in the number ("#") above. If the physical hierarchy of the server
+ includes plug-in DSP cards, another level of hierarchy in the local
+ endpoint name may be used to describe the plug in unit.
+
+ A virtual endpoint may be created as the result of using the "any of"
+ wildcard. Similarly, a virtual endpoint may cease to exist once the
+ last connection on the virtual endpoint is deleted. The definition
+ of the virtual endpoint MUST detail both of these aspects.
+
+ When a <virtual-endpoint-type> creates and deletes virtual endpoints
+ automatically, there will be cases where no virtual endpoints exist
+ at the time a RestartInProgress command is to be issued. In such
+ cases, the gateway SHOULD simply use the "all of" wildcard in lieu of
+ any specific <endpoint-#> as in, e.g.:
+
+ ann/*@mygateway.whatever.net
+
+ If the RestartInProgress command refers to all endpoints in the
+ gateway (virtual or not), the <virtual-endpoint-id> can be omitted as
+ in, e.g.:
+
+ *@mygateway.whatever.net
+
+ Commands received by the gateway will still have to refer to an
+ actual endpoint (possibly created by that command by use of the "any
+ of" wildcard) in order for the command to be processed though.
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 183]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+E.4 Media Gateway
+
+ MGCP only defines operation on endpoints in a media gateway. It may
+ be beneficial to define an endpoint that represents the gateway
+ itself as opposed to the endpoints managed by the gateway.
+ Implementations that wish to do so should use the local endpoint name
+ "mg" (for media gateway) as in:
+
+ mg@mygateway.whatever.net
+
+ Note that defining such an endpoint does not change any of the
+ protocol semantics, i.e., the "mg" endpoint and other endpoints
+ (e.g., digital trunks) in the gateway are still independent endpoints
+ and MUST be treated as such. For example, RestartInProgress commands
+ MUST still be issued for all endpoints in the gateway as usual.
+
+E.5 Range Wildcards
+
+ As described in Section 2.1.2, the MGCP endpoint naming scheme
+ defines the "all of" and "any of" wildcards for the individual terms
+ in a local endpoint name. While the "all of" wildcard is very useful
+ for reducing the number of messages, it can by definition only be
+ used when we wish to refer to all instances of a given term in the
+ local endpoint name. Furthermore, in the case where a command is to
+ be sent by the gateway to the Call Agent, the "all of" wildcard can
+ only be used if all of the endpoints named by it have the same
+ "notified entity". Implementations that prefer a finer-grained
+ wildcarding scheme can use the range wildcarding scheme described
+ here.
+
+ A range wildcard is defined as follows:
+
+ RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]"
+ NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ]
+
+ Note that white space is not permitted. Also, since range wildcards
+ use the character "[" to indicate the start of a range, the "["
+ character MUST NOT be used in endpoint names that use range
+ wildcards. The length of a range wildcard SHOULD be bounded to a
+ reasonably small value, e.g., 128 characters.
+
+ Range wildcards can be used anywhere an "all of" wildcard can be
+ used. The semantics are identical for the endpoints named. However,
+ it MUST be noted, that use of the range wildcarding scheme requires
+ support on both the gateway and the Call Agent. Therefore, a gateway
+ MUST NOT assume that it's Call Agent supports range wildcarding and
+ vice versa. In practice, this typically means that both the gateway
+ and Call Agent will need to be provisioned consistently in order to
+
+
+
+Andreasen & Foster Informational [Page 184]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ use range wildcards. Also, if a gateway or Call Agent using range
+ wildcards receives an error response that could indicate a possible
+ endpoint naming problem, they MUST be able to automatically revert to
+ not using range wildcards.
+
+ The following examples illustrates the use of range wildcards:
+
+ ds/ds1-1/[1-12]
+ ds/ds1-1/[1,3,20-24]
+ ds/ds1-[1-2]/*
+ ds/ds3-1/[1-96]
+
+ The following example illustrates how to use it in a command:
+
+ RSIP 1204 ds/ds3-1/[1-96]@tgw-18.whatever.net MGCP 1.0
+ RM: restart
+ RD: 0
+
+Appendix F: Example Command Encodings
+
+ This appendix provides examples of commands and responses shown with
+ the actual encoding used. Examples are provided for each command.
+ All commentary shown in the commands and responses is optional.
+
+F.1 NotificationRequest
+
+ The first example illustrates a NotificationRequest that will ring a
+ phone and look for an off-hook event:
+
+ RQNT 1201 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ N: ca@ca1.whatever.net:5678
+ X: 0123456789AC
+ R: l/hd(N)
+ S: l/rg
+
+ The response indicates that the transaction was successful:
+
+ 200 1201 OK
+
+ The second example illustrates a NotificationRequest that will look
+ for and accumulate an off-hook event, and then provide dial-tone and
+ accumulate digits according to the digit map provided. The "notified
+ entity" is set to "ca@ca1.whatever.net:5678", and since the
+ SignalRequests parameter is empty (it could have been omitted as
+ well), all currently active TO signals will be stopped. All events
+ in the quarantine buffer will be processed, and the list of events to
+ detect in the "notification" state will include fax tones in addition
+ to the "requested events" and persistent events:
+
+
+
+Andreasen & Foster Informational [Page 185]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ RQNT 1202 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ N: ca@ca1.whatever.net:5678
+ X: 0123456789AC
+ R: L/hd(A, E(S(L/dl),R(L/oc, L/hu, D/[0-9#*T](D))))
+ D: (0T|00T|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
+ S:
+ Q: process
+ T: G/ft
+
+ The response indicates that the transaction was successful:
+
+ 200 1202 OK
+
+F.2 Notify
+
+ The example below illustrates a Notify message that notifies an off-
+ hook event followed by a 12-digit number beginning with "91". A
+ transaction identifier correlating the Notify with the
+ NotificationRequest it results from is included. The command is sent
+ to the current "notified entity", which typically will be the actual
+ value supplied in the NotifiedEntity parameter, i.e.,
+ "ca@ca1.whatever.net:5678" - a failover situation could have changed
+ this:
+
+ NTFY 2002 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ N: ca@ca1.whatever.net:5678
+ X: 0123456789AC
+ O: L/hd,D/9,D/1,D/2,D/0,D/1,D/8,D/2,D/9,D/4,D/2,D/6,D/6
+
+ The Notify response indicates that the transaction was successful:
+
+ 200 2002 OK
+
+F.3 CreateConnection
+
+ The first example illustrates a CreateConnection command to create a
+ connection on the endpoint specified. The connection will be part of
+ the specified CallId. The LocalConnectionOptions specify that G.711
+ mu-law will be the codec used and the packetization period will be 10
+ ms. The connection mode will be "receive only":
+
+ CRCX 1204 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ C: A3C47F21456789F0
+ L: p:10, a:PCMU
+ M: recvonly
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 186]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The response indicates that the transaction was successful, and a
+ connection identifier for the newly created connection is therefore
+ included. A session description for the new connection is included
+ as well - note that it is preceded by an empty line.
+
+ 200 1204 OK
+ I: FDE234C8
+
+ v=0
+ o=- 25678 753849 IN IP4 128.96.41.1
+ s=-
+ c=IN IP4 128.96.41.1
+ t=0 0
+ m=audio 3456 RTP/AVP 0
+
+ The second example illustrates a CreateConnection command containing
+ a notification request and a RemoteConnectionDescriptor:
+
+ CRCX 1205 aaln/1@rgw-2569.whatever.net MGCP 1.0
+ C: A3C47F21456789F0
+ L: p:10, a:PCMU
+ M: sendrecv
+ X: 0123456789AD
+ R: L/hd
+ S: L/rg
+
+ v=0
+ o=- 25678 753849 IN IP4 128.96.41.1
+ s=-
+ c=IN IP4 128.96.41.1
+ t=0 0
+ m=audio 3456 RTP/AVP 0
+
+ The response indicates that the transaction failed, because the phone
+ was already off-hook. Consequently, neither a connection-id nor a
+ session description is returned:
+
+ 401 1205 Phone off-hook
+
+ Our third example illustrates the use of the provisional response and
+ the three-way handshake. We create another connection and
+ acknowledge the previous response received by using the response
+ acknowledgement parameter:
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 187]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ CRCX 1206 aaln/1@rgw-2569.whatever.net MGCP 1.0
+ K: 1205
+ C: A3C47F21456789F0
+ L: p:10, a:PCMU
+ M: inactive
+
+ v=0
+ o=- 25678 753849 IN IP4 128.96.41.1
+ s=-
+ c=IN IP4 128.96.41.1
+ t=0 0
+ m=audio 3456 RTP/AVP 0
+
+ A provisional response is returned initially:
+
+ 100 1206 Pending
+ I: DFE233D1
+
+ v=0
+ o=- 4723891 7428910 IN IP4 128.96.63.25
+ s=-
+ c=IN IP4 128.96.63.25
+ t=0 0
+ m=audio 3456 RTP/AVP 0
+
+ A little later, the final response is received:
+
+ 200 1206 OK
+ K:
+ I: DFE233D1
+
+ v=0
+ o=- 4723891 7428910 IN IP4 128.96.63.25
+ s=-
+ c=IN IP4 128.96.63.25
+ t=0 0
+ m=audio 3456 RTP/AVP 0
+
+ The Call Agent acknowledges the final response as requested:
+
+ 000 1206
+
+ and the transaction is complete.
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 188]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+F.4 ModifyConnection
+
+ The first example shows a ModifyConnection command that simply sets
+ the connection mode of a connection to "send/receive" - the "notified
+ entity" is set as well:
+
+ MDCX 1209 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ C: A3C47F21456789F0
+ I: FDE234C8
+ N: ca@ca1.whatever.net
+ M: sendrecv
+
+ The response indicates that the transaction was successful:
+
+ 200 1209 OK
+
+ In the second example, we pass a session description and include a
+ notification request with the ModifyConnection command. The endpoint
+ will start playing ring-back tones to the user:
+
+ MDCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ C: A3C47F21456789F0
+ I: FDE234C8
+ M: recvonly
+ X: 0123456789AE
+ R: L/hu
+ S: G/rt
+
+ v=0
+ o=- 4723891 7428910 IN IP4 128.96.63.25
+ s=-
+ c=IN IP4 128.96.63.25
+ t=0 0
+ m=audio 3456 RTP/AVP 0
+
+ The response indicates that the transaction was successful:
+
+ 200 1206 OK
+
+F.5 DeleteConnection (from the Call Agent)
+
+ In this example, the Call Agent simply instructs the gateway to
+ delete the connection "FDE234C8" on the endpoint specified:
+
+ DLCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ C: A3C47F21456789F0
+ I: FDE234C8
+
+
+
+
+Andreasen & Foster Informational [Page 189]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The response indicates success, and that the connection was deleted.
+ Connection parameters for the connection are therefore included as
+ well:
+
+ 250 1210 OK
+ P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
+
+F.6 DeleteConnection (from the gateway)
+
+ In this example, the gateway sends a DeleteConnection command to the
+ Call Agent to instruct it that a connection on the specified endpoint
+ has been deleted. The ReasonCode specifies the reason for the
+ deletion, and Connection Parameters for the connection are provided
+ as well:
+
+ DLCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ C: A3C47F21456789F0
+ I: FDE234C8
+ E: 900 - Hardware error
+ P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
+
+ The Call Agent sends a success response to the gateway:
+
+ 200 1210 OK
+
+F.7 DeleteConnection (multiple connections from the Call Agent)
+
+ In the first example, the Call Agent instructs the gateway to delete
+ all connections related to call "A3C47F21456789F0" on the specified
+ endpoint:
+
+ DLCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ C: A3C47F21456789F0
+
+ The response indicates success and that the connection(s) were
+ deleted:
+
+ 250 1210 OK
+
+ In the second example, the Call Agent instructs the gateway to delete
+ all connections related to all of the endpoints specified:
+
+ DLCX 1210 aaln/*@rgw-2567.whatever.net MGCP 1.0
+
+ The response indicates success:
+
+ 250 1210 OK
+
+
+
+
+Andreasen & Foster Informational [Page 190]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+F.8 AuditEndpoint
+
+ In the first example, the Call Agent wants to learn what endpoints
+ are present on the gateway specified, hence the use of the "all of"
+ wild-card for the local portion of the endpoint-name:
+
+ AUEP 1200 *@rgw-2567.whatever.net MGCP 1.0
+
+ The gateway indicates success and includes a list of endpoint names:
+
+ 200 1200 OK
+ Z: aaln/1@rgw-2567.whatever.net
+ Z: aaln/2@rgw-2567.whatever.net
+
+ In the second example, the capabilities of one of the endpoints is
+ requested:
+
+ AUEP 1201 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ F: A
+
+ The response indicates success and the capabilities as well. Two
+ codecs are supported, however with different capabilities.
+ Consequently two separate capability sets are returned:
+
+ 200 1201 OK
+ A: a:PCMU, p:10-100, e:on, s:off, v:L;S, m:sendonly;
+ recvonly;sendrecv;inactive;netwloop;netwtest
+ A: a:G729, p:30-90, e:on, s:on, v:L;S, m:sendonly;
+ recvonly;sendrecv;inactive;confrnce;netwloop
+
+ Note that the carriage return in the Capabilities lines are shown for
+ formatting reasons only - they are not permissible in a real
+ implementation.
+
+ In the third example, the Call Agent audits several types of
+ information for the endpoint:
+
+ AUEP 2002 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ F: R,D,S,X,N,I,T,O,ES
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 191]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The response indicates success:
+
+ 200 2002 OK
+ R: L/hu,L/oc(N),D/[0-9](N)
+ D:
+ S: L/vmwi(+)
+ X: 0123456789B1
+ N: [128.96.41.12]
+ I: 32F345E2
+ T: G/ft
+ O: L/hd,D/9,D/1,D/2
+ ES: L/hd
+
+ The list of requested events contains three events. Where no package
+ name is specified, the default package is assumed. The same goes for
+ actions, so the default action - Notify - must therefore be assumed
+ for the "L/hu" event. The omission of a value for the "digit map"
+ means the endpoint currently does not have a digit map. There are
+ currently no active time-out signals, however the OO signal "vmwi" is
+ currently on and is consequently included - in this case it was
+ parameterized, however the parameter could have been excluded. The
+ current "notified entity" refers to an IP-address and only a single
+ connection exists for the endpoint. The current value of
+ DetectEvents is "G/ft", and the list of ObservedEvents contains the
+ four events specified. Finally, the event-states audited reveals
+ that the phone was off-hook at the time the transaction was
+ processed.
+
+F.9 AuditConnection
+
+ The first example shows an AuditConnection command where we audit the
+ CallId, NotifiedEntity, LocalConnectionOptions, Connection Mode,
+ LocalConnectionDescriptor, and the Connection Parameters:
+
+ AUCX 2003 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ I: 32F345E2
+ F: C,N,L,M,LC,P
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 192]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The response indicates success and includes information for the
+ RequestedInfo:
+
+ 200 2003 OK
+ C: A3C47F21456789F0
+ N: ca@ca1.whatever.net
+ L: p:10, a:PCMU
+ M: sendrecv
+ P: PS=395, OS=22850, PR=615, OR=30937, PL=7, JI=26, LA=47
+
+ v=0
+ o=- 4723891 7428910 IN IP4 128.96.63.25
+ s=-
+ c=IN IP4 128.96.63.25
+ t=0 0
+ m=audio 1296 RTP/AVP 0
+
+ In the second example, we request to audit RemoteConnectionDescriptor
+ and LocalConnectionDescriptor:
+
+ AUCX 1203 aaln/2@rgw-2567.whatever.net MGCP 1.0
+ I: FDE234C8
+ F: RC,LC
+
+ The response indicates success, and includes information for the
+ RequestedInfo. In this case, no RemoteConnectionDescriptor exists,
+ hence only the protocol version field is included for the
+ RemoteConnectionDescriptor:
+
+ 200 1203 OK
+
+ v=0
+ o=- 4723891 7428910 IN IP4 128.96.63.25
+ s=-
+ c=IN IP4 128.96.63.25
+ t=0 0
+ m=audio 1296 RTP/AVP 0
+
+ v=0
+
+F.10 RestartInProgress
+
+ The first example illustrates a RestartInProgress message sent by an
+ gateway to inform the Call Agent that the specified endpoint will be
+ taken out-of-service in 300 seconds:
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 193]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ RSIP 1200 aaln/1@rgw-2567.whatever.net MGCP 1.0
+ RM: graceful
+ RD: 300
+
+ The Call Agent's response indicates that the transaction was
+ successful:
+
+ 200 1200 OK
+
+ In the second example, the RestartInProgress message sent by the
+ gateway informs the Call Agent, that all of the gateway's endpoints
+ are being placed in-service in 0 seconds, i.e., they are currently in
+ service. The restart delay could have been omitted as well:
+
+ RSIP 1204 *@rgw-2567.whatever.net MGCP 1.0
+ RM: restart
+ RD: 0
+
+ The Call Agent's response indicates success, and furthermore provides
+ the endpoints in question with a new "notified entity":
+
+ 200 1204 OK
+ N: CA-1@whatever.net
+
+ Alternatively, the command could have failed with a new "notified
+ entity" as in:
+
+ 521 1204 OK
+ N: CA-1@whatever.net
+
+ In that case, the command would then have to be retried in order to
+ satisfy the "restart procedure", this time going to Call Agent "CA-
+ 1@whatever.net".
+
+Appendix G: Example Call Flows
+
+ The message flow tables in this section use the following
+ abbreviations:
+
+ * rgw = Residential Gateway
+
+ * ca = Call Agent
+
+ * n+ = step 'n' is repeated one or more times
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 194]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Note that any use of upper and lower case within the text of the
+ messages is to aid readability and is not in any way a requirement.
+ The only requirement involving case is to be case insensitive at all
+ times.
+
+G.1 Restart
+
+G.1.1 Residential Gateway Restart
+
+ The following table shows a message sequence that might occur when a
+ call agent (ca) is contacted by two independent residential gateways
+ (rgw1 and rgw2) which have restarted.
+
+ Table F.1: Residential Gateway Restart
+
+ ---------------------------------------------------------------------
+|step#| usr1 | rgw1 | ca | rgw2 | usr2 |
+|=====|============|============|============|============|===========|
+| 1 | | rsip -> | | | |
+| | | | <- ack | | |
+|-----|------------|------------|------------|------------|-----------|
+| 2 | | | <- auep | | |
+| | | ack -> | | | |
+|-----|------------|------------|------------|------------|-----------|
+| 3+ | | | <- rqnt | | |
+| | | ack -> | | | |
+|-----|------------|------------|------------|------------|-----------|
+| 4 | | | | <- rsip | |
+| | | | ack -> | | |
+|-----|------------|------------|------------|------------|-----------|
+| 5 | | | auep -> | | |
+| | | | | <- ack | |
+|-----|------------|------------|------------|------------|-----------|
+| 6+ | | | rqnt -> | | |
+| | | | | <- ack | |
+ ---------------------------------------------------------------------
+
+ Step 1 - RestartInProgress (rsip) from rgw1 to ca
+
+ rgw1 uses DNS to determine the domain name of ca and send to the
+ default port of 2727. The command consists of the following:
+
+ rsip 1 *@rgw1.whatever.net mgcp 1.0
+ rm: restart
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 195]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The "*" is used to inform ca that all endpoints of rgw1 are being
+ restarted, and "restart" is specified as the restart method. The
+ Call Agent "ca" acknowledges the command with an acknowledgement
+ message containing the transaction-id (in this case 1) for the
+ command. It sends the acknowledgement to rgw1 using the same port
+ specified as the source port for the rsip. If none was indicated, it
+ uses the default port of 2727.
+
+ 200 1 ok
+
+ A response code is mandatory. In this case, "200", indicates "the
+ requested transaction was executed normally". The response string is
+ optional. In this case, "ok" is included as an additional
+ description.
+
+ Step 2 - AuditEndpoint (auep) from ca to rgw1
+
+ The command consists of the following:
+
+ auep 153 *@rgw1.whatever.net mgcp 1.0
+
+ The "*" is used to request audit information from rgw1 of all its
+ endpoints. rgw1 acknowledges the command with an acknowledgement
+ message containing the transaction-id (in this case 153) of the
+ command, and it includes a list of its endpoints. In this example,
+ rgw1 has two endpoints, aaln/1 and aaln/2.
+
+ 200 153 ok
+ Z: aaln/1@rgw1.whatever.net
+ Z: aaln/2@rgw1.whatever.net
+
+ Once it has the list of endpoint ids, ca may send individual
+ AuditEndpoint commands in which the "*" is replaced by the id of the
+ given endpoint. As its response, rgw1 would replace the endpoint id
+ list returned in the example with the info requested for the
+ endpoint. This optional message exchange is not shown in this
+ example.
+
+ Step 3 - NotificationRequest (rqnt) from ca to each endpoint of rgw1
+
+ In this case, ca sends two rqnts, one for aaln/1:
+
+ rqnt 154 aaln/1@rgw1.whatever.net mgcp 1.0
+ r: l/hd(n)
+ x: 3456789a0
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 196]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ and a second for aaln/2:
+
+ rqnt 155 aaln/2@rgw1.whatever.net mgcp 1.0
+ r: l/hd(n)
+ x: 3456789a1
+
+ Note that in the requested events parameter line, the event is fully
+ specified as "l/hd", i.e., with the package name, in order to avoid
+ any potential ambiguity. This is the recommended behavior. For the
+ sake of clarity, the action, which in this case is to Notify, is
+ explicitly specified by including the "(n)". If no action is
+ specified, Notify is assumed as the default regardless of the event.
+ If any other action is desired, it must be stated explicitly.
+
+ The expected response from rgw1 to these requests is an
+ acknowledgement from aaln/1 as follows:
+
+ 200 154 ok
+
+ and from aaln/2:
+
+ 200 155 ok
+
+ Step 4 RestartInProgress (rsip) from rgw2 to ca
+
+ rsip 0 *@rgw2.whatever.net mgcp 1.0
+ rm: restart
+
+ followed by the acknowledgement from ca:
+
+ 200 0 ok
+
+ Step 5 - AuditEndpoint (auep) from ca to rgw2
+
+ auep 156 *@rgw2.whatever.net mgcp 1.0
+
+ followed by an acknowledgement from rgw2:
+
+ 200 156 ok
+ z: aaln/1@rgw2.whatever.net
+ z: aaln/2@rgw2.whatever.net
+
+ Step 6 - NotificationRequest (rqnt) from ca to each endpoint of rgw2
+
+ rqnt 157 aaln/1@rgw2.whatever.net mgcp 1.0
+ r: l/hd(n)
+ x: 3456789a2
+
+
+
+
+Andreasen & Foster Informational [Page 197]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ followed by:
+
+ rqnt 158 aaln/2@rgw2.whatever.net mgcp 1.0
+ r: l/hd(n)
+ x: 3456789a3
+
+ with rgw2 acknowledging for aaln/1:
+
+ 200 157 ok
+
+ and for aaln/2:
+
+ 200 158 ok
+
+G.1.2 Call Agent Restart
+
+ The following table shows the message sequence which occurs when a
+ call agent (ca) restarts. How it determines the address information
+ of the gateways, in this case rgw1 and rgw2, is not covered in this
+ document. For interoperability, it is RECOMMENDED to provide the
+ ability to configure the call agent to send AUEP (*) to specific
+ addresses and ports.
+
+ Table F.2: Residential Gateway Restart
+
+ ---------------------------------------------------------------------
+| # | usr1 | rgw1 | ca | rgw2 | usr2 |
+|===|=============|============|============|============|============|
+| 1 | | | <- auep | | |
+| | | ack -> | | | |
+|---|-------------|------------|------------|------------|------------|
+| 2+| | | <- rqnt | | |
+| | | ack -> | | | |
+|---|-------------|------------|------------|------------|------------|
+| 3 | | | auep -> | | |
+| | | | | <- ack | |
+|---|-------------|------------|------------|------------|------------|
+| 4+| | | rqnt -> | | |
+| | | | | <- ack | |
+ ---------------------------------------------------------------------
+
+ Step 1 - AuditEndpoint (auep) from ca to rgw1
+
+ The command consists of the following:
+
+ auep 0 *@rgw1.whatever.net mgcp 1.0
+
+
+
+
+
+Andreasen & Foster Informational [Page 198]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ The "*" is used to request audit information from rgw1 of all its
+ endpoints. rgw1 acknowledges the command with an acknowledgement
+ message containing the transaction id (in this case 0) of the
+ command, and it includes a list of its endpoints. In this example,
+ rgw1 has two endpoints, aaln/1 and aaln/2.
+
+ 200 0 ok
+ z: aaln/1@rgw1.whatever.net
+ z: aaln/2@rgw1.whatever.net
+
+ Once it has the list of endpoint ids, ca may send individual
+ AuditEndpoint commands in which the "*" is replaced by the id of the
+ given endpoint. As its response, rgw1 would replace the endpoint id
+ list returned in the example with the info requested for the
+ endpoint. This optional message exchange is not shown in this
+ example.
+
+ Step 2 - NotificationRequest (rqnt) off-hook from ca to rgw1
+
+ In this case, ca sends two rqnts, one for aaln/1:
+
+ rqnt 1 aaln/1@rgw1.whatever.net mgcp 1.0
+ r: l/hd(n)
+ x: 234567890
+
+ and a second for aaln/2:
+
+ rqnt 2 aaln/2@rgw1.whatever.net mgcp 1.0
+ r: l/hd(n)
+ x: 234567891
+
+ The expected response from rgw1 to these requests is an
+ acknowledgement from aaln/1 as follows:
+
+ 200 1 ok
+
+ and from aaln/2:
+
+ 200 2 ok
+
+ Step 3 - AuditEndpoint (auep) from ca to rgw2
+
+ auep 3 *@rgw2.whatever.net mgcp 1.0
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 199]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ followed by an acknowledgement from rgw2:
+
+ 200 3 ok
+ z: aaln/1@rgw2.whatever.net
+ z: aaln/2@rgw2.whatever.net
+
+ Step 4 - NotificationRequest (rqnt) from ca to each endpoint of rgw2
+
+ rqnt 4 aaln/1@rgw2.whatever.net mgcp 1.0
+ r: l/hd(n)
+ x: 234567892
+
+ followed by:
+
+ rqnt 5 aaln/2@rgw2.whatever.net mgcp 1.0
+ r: l/hd(n)
+ x: 234567893
+
+ with rgw2 acknowledging for aaln/1:
+
+ 200 4 ok
+
+ and for aaln/2:
+
+ 200 5 ok
+G.2 Connection Creation
+
+G.2.1 Residential Gateway to Residential Gateway
+
+ The following table shows the message sequence which occurs when a
+ user (usr1) makes a call through a residential gateway (rgw1) to a
+ user served by another residential gateway (rgw2). This example
+ illustrates the communication between the residential gateways and
+ the call agent (ca) only. The local name of the endpoints in this
+ example is aaln/1 for both gateways, and references within the
+ description of the steps to rgw1 and rgw2 can be assumed to refer to
+ aaln/1 of rgw1 and aaln/1 of rgw2. Note that this is only an example
+ and is not the only legal call scenario.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 200]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Table F.3: Residential Gateway Connection Creation
+
+ ---------------------------------------------------------------------
+| # | usr1 | rgw1 | ca | rgw2 | usr2 |
+|===|=============|============|============|============|============|
+| 1 | offhook -> | ntfy -> | | | |
+| | | | <- ack | | |
+|---|-------------|------------|------------|------------|------------|
+| 2 | <- dialtone | | <- rqnt | | |
+| | | ack -> | | | |
+|---|-------------|------------|------------|------------|------------|
+| 3 | digits -> | ntfy -> | | | |
+| | | | <- ack | | |
+|---|-------------|------------|------------|------------|------------|
+| 4 | | | <- rqnt | | |
+| | | ack -> | | | |
+|---|-------------|------------|------------|------------|------------|
+| 5 | <- recvonly | | <- crcx | | |
+| | | ack -> | | | |
+|---|-------------|------------|------------|------------|------------|
+| 6 | | | crcx -> | | sendrcv -> |
+| | | | | <- ack | |
+|---|-------------|------------|------------|------------|------------|
+| 7 | <- recvonly | | <- mdcx | | |
+| | | ack -> | | | |
+|---|-------------|------------|------------|------------|------------|
+| 8 | <- ringback | | <- rqnt | | |
+| | | ack -> | | | |
+|---|-------------|------------|------------|------------|------------|
+| 9 | | | rqnt -> | | ringing -> |
+| | | | | <- ack | |
+|---|-------------|------------|------------|------------|------------|
+|10 | | | | <- ntfy | <- offhook |
+| | | | ack -> | | |
+|---|-------------|------------|------------|------------|------------|
+|11 | | | rqnt -> | | |
+| | | | | <- ack | |
+|---|-------------|------------|------------|------------|------------|
+|12 | | | <- rqnt | | |
+| | | ack -> | | | |
+|---|-------------|------------|------------|------------|------------|
+|13 | <- sendrcv | | <- mdcx | | |
+| | | ack -> | | | |
+ ---------------------------------------------------------------------
+
+ Step 1 - Notify (ntfy) offhook from rgw1 to ca
+
+
+
+
+
+Andreasen & Foster Informational [Page 201]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ This ntfy is the result of usr1 going offhook and assumes ca had
+ previously sent an rqnt with RequestId "445678944" to rgw1 requesting
+ notification in the event of an offhook:
+
+ ntfy 12 aaln/1@rgw1.whatever.net mgcp 1.0
+ o: l/hd
+ x: 445678944
+
+ Acknowledgement from ca:
+
+ 200 12 ok
+
+ Step 2 - Request Notification (rqnt) for digits from ca to rgw1
+
+ Request rgw1 to notify if on-hook and collect digits according to the
+ digit map, and to provide dialtone:
+
+ rqnt 1057 aaln/1@rgw1.whatever.net mgcp 1.0
+ r: l/hu(n), d/[0-9#*T](d)
+ s: l/dl
+ x: 445678945
+ d: 5xxx
+
+ Acknowledgement from rgw1:
+
+ 200 1057 ok
+
+ Step 3 - Notify (ntfy) digits from rgw1 to ca
+
+ ntfy 13 aaln/1@rgw1.whatever.net mgcp 1.0
+ o: d/5, d/0, d/0, d/1
+ x: 445678945
+
+ Acknowledgement from ca:
+
+ 200 13 ok
+
+ Step 4 - Request Notification (rqnt) from ca to rgw1
+
+ Request rgw1 to notify in the event of an on-hook transition:
+
+ rqnt 1058 aaln/1@rgw1.whatever.net mgcp 1.0
+ r: l/hu(n)
+ x: 445678946
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 202]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Acknowledgement from rgw1:
+
+ 200 1058 ok
+
+ Step 5 - Create Connection (crcx) from ca to rgw1
+
+ Request a new connection on rgw1 with the specified local connection
+ options, including 20 msec as the packetization period, G.711 mu-law
+ as the codec, and receive only as the mode:
+
+ crcx 1059 aaln/1@rgw1.whatever.net mgcp 1.0
+ c: 9876543210abcdef
+ l: p:20, a:PCMU
+ m: recvonly
+
+ Acknowledgement from rgw1 that a new connection, "456789fedcba5", has
+ been created, followed by a blank line and then the SDP parameters:
+
+ 200 1059 ok
+ i: 456789fedcba5
+
+ v=0
+ o=- 23456789 98765432 IN IP4 192.168.5.7
+ s=-
+ c=IN IP4 192.168.5.7
+ t=0 0
+ m=audio 6058 RTP/AVP 0
+
+ Step 6 - Create Connection (crcx) from ca to rgw2
+
+ Request a new connection on rgw2. The request includes the session
+ description returned by rgw1 such that a two way connection can be
+ initiated:
+
+ crcx 2052 aaln/1@rgw2.whatever.net mgcp 1.0
+ c: 9876543210abcdef
+ l: p:20, a:PCMU
+ m: sendrecv
+
+ v=0
+ o=- 23456789 98765432 IN IP4 192.168.5.7
+ s=-
+ c=IN IP4 192.168.5.7
+ t=0 0
+ m=audio 6058 RTP/AVP 0
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 203]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Acknowledgement from rgw2 that a new connection, "67890af54c9", has
+ been created; followed by a blank line and then the SDP parameters:
+
+ 200 2052 ok
+ i: 67890af54c9
+
+ v=0
+ o=- 23456889 98865432 IN IP4 192.168.5.8
+ s=-
+ c=IN IP4 192.168.5.8
+ t=0 0
+ m=audio 6166 RTP/AVP 0
+
+ Step 7 - Modify Connection (mdcx) from ca to rgw1
+
+ Request rgw1 to modify the existing connection, "456789fedcba5", to
+ use the session description returned by rgw2 establishing a half
+ duplex connection which, though not used in this example, could be
+ used to provide usr1 with in band ringback tone, announcements, etc:
+
+ mdcx 1060 aaln/1@rgw1.whatever.net mgcp 1.0
+ c: 9876543210abcdef
+ i: 456789fedcba5
+ l: p:20, a:PCMU
+ M: recvonly
+
+ v=0
+ o=- 23456889 98865432 IN IP4 192.168.5.8
+ s=-
+ c=IN IP4 192.168.5.8
+ t=0 0
+ m=audio 6166 RTP/AVP 0
+
+ Acknowledgement from rgw1:
+
+ 200 1060 ok
+
+ Step 8 - Request Notification (rqnt) from ca for rgw1 to provide
+ ringback
+
+ Request rgw1 to notify in the event of an on-hook transition, and
+ also to provide ringback tone:
+
+ rqnt 1061 aaln/1@rgw1.whatever.net mgcp 1.0
+ r: l/hu(n)
+ s: g/rt
+ x: 445678947
+
+
+
+
+Andreasen & Foster Informational [Page 204]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Acknowledgement from rgw1:
+
+ 200 1061 ok
+
+ Step 9 - Request Notification (rqnt) from ca to rgw2 to provide
+ ringing
+
+ Request rgw2 to continue to look for offhook and provide ringing:
+
+ rqnt 2053 aaln/1@rgw2.whatever.net mgcp 1.0
+ r: l/hd(n)
+ s: l/rg
+ x: 445678948
+
+ Acknowledgement from rgw2:
+
+ 200 2053 ok
+
+ Step 10 - Notify (ntfy) offhook from rgw2 to ca
+
+ ntfy 27 aaln/1@rgw2.whatever.net mgcp 1.0
+ o: l/hd
+ x: 445678948
+
+ Acknowledgement from ca:
+
+ 200 27 ok
+
+ Step 11 - Request Notification (rqnt) of on-hook from ca to rgw2
+
+ rqnt 2054 aaln/1@rgw2.whatever.net mgcp 1.0
+ r: l/hu(n)
+ x: 445678949
+
+ Acknowledgement from rgw2:
+
+ 200 2054 ok
+
+ Step 12 - Request Notification (rqnt) of on-hook from ca to rgw1
+
+ rqnt 1062 aaln/1@rgw1.whatever.net mgcp 1.0
+ r: l/hu(n)
+ x: 445678950
+
+ Acknowledgement from rgw1:
+
+ 200 1062 ok
+
+
+
+
+Andreasen & Foster Informational [Page 205]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Step 13 - Modify Connection (mdcx) from ca to rgw1
+
+ Request rgw1 to modify the existing connection, "456789fedcba5", to
+ sendrecv such that a full duplex connection is initiated:
+
+ mdcx 1063 aaln/1@rgw1.whatever.net mgcp 1.0
+ c: 9876543210abcdef
+ i: 456789fedcba5
+ m: sendrecv
+
+ Acknowledgement from rgw1:
+
+ 200 1063 ok
+
+G.3 Connection Deletion
+
+G.3.1 Residential Gateway to Residential Gateway
+
+ The following table shows the message sequence which occurs when a
+ user (usr2) initiates the deletion of an existing connection on a
+ residential gateway (rgw2) with a user served by another residential
+ gateway (rgw1). This example illustrates the communication between
+ the residential gateways and the call agent (ca) only. The local
+ name of the endpoints in this example is aaln/1 for both gateways,
+ and references within the description of the steps to rgw1 and rgw2
+ can be assumed to refer to aaln/1 of rgw1 and aaln/1 of rgw2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 206]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Table F.4: Residential Gateway Connection Deletion
+
+ ---------------------------------------------------------------------
+| # | usr1 | rgw1 | ca | rgw2 | usr2 |
+|===|=============|============|============|============|============|
+| 1 | | | | <- ntfy | <- on-hook |
+| | | | ack -> | | |
+|---|-------------|------------|------------|------------|------------|
+| 2 | | | dlcx -> | | |
+| | | | | <- ack | |
+|---|-------------|------------|------------|------------|------------|
+| 3 | | | <- dlcx | | |
+| | | ack -> | | | |
+|---|-------------|------------|------------|------------|------------|
+| 4 | | | rqnt -> | | |
+| | | | | <- ack | |
+|---|-------------|------------|------------|------------|------------|
+| 5 | on-hook -> | ntfy -> | | | |
+| | | | <- ack | | |
+|---|-------------|------------|------------|------------|------------|
+| 6 | | | <- rqnt | | |
+| | | ack -> | | | |
+ ---------------------------------------------------------------------
+
+ Step 1 - Notify (ntfy) offhook from rgw1 to ca
+
+ This ntfy is the result of usr2 going on-hook and assumes that ca had
+ previously sent an rqnt to rgw2 requesting notification in the event
+ of an on-hook (see end of Connection Creation sequence):
+
+ ntfy 28 aaln/1@rgw2.whatever.net mgcp 1.0
+ o: l/hu
+ x: 445678949
+
+ Acknowledgement from ca:
+
+ 200 28 ok
+
+ Step 2 - Delete Connection (dlcx) from ca to rgw2
+
+ Requests rgw2 to delete the connection "67890af54c9":
+
+ dlcx 2055 aaln/1@rgw1.whatever.net mgcp 1.0
+ c: 9876543210abcdef
+ i: 67890af54c9
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 207]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+ Acknowledgement from rgw2. Note the response code of "250" meaning
+ "the connection was deleted":
+
+ 250 2055 ok
+
+ Step 3 - Delete Connection (dlcx) from ca to rgw1
+
+ Requests rgw1 to delete the connection "456789fedcba5":
+
+ dlcx 1064 aaln/1@rgw1.whatever.net mgcp 1.0
+ c: 9876543210abcdef
+ i: 456789fedcba5
+
+ Acknowledgement from rgw1:
+
+ 250 1064 ok
+
+ Step 4 - NotificationRequest (rqnt) from ca to rgw2
+
+ Requests rgw2 to notify ca in the event of an offhook transition:
+
+ rqnt 2056 aaln/1@rgw2.whatever.net mgcp 1.0
+ r: l/hd(n)
+ x: 445678951
+
+ Acknowledgement from rgw2:
+
+ 200 2056 ok
+
+ Step 5 - Notify (ntfy) on-hook from rgw1 to ca
+
+ Notify ca that usr1 at rgw1 went back on-hook:
+
+ ntfy 15 aaln/1@rgw1.whatever.net mgcp 1.0
+ o: l/hu
+ x: 445678950
+
+ Acknowledgement from ca:
+
+ 200 15 ok
+
+ Step 6 - NotificationRequest (rqnt) offhook from ca to rgw1
+
+ Requests rgw1 to notify ca in the event of an offhook transition:
+
+ rqnt 1065 aaln/1@rgw1.whatever.net mgcp 1.0
+ r: l/hd(n)
+ x: 445678952
+
+
+
+Andreasen & Foster Informational [Page 208]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+
+ Acknowledgement from rgw1:
+
+ 200 1065 ok
+
+Authors' Addresses
+
+ Flemming Andreasen
+ Cisco Systems
+ 499 Thornall Street, 8th Floor
+ Edison, NJ 08837
+
+ EMail: fandreas@cisco.com
+
+
+ Bill Foster
+ Cisco Systems
+ 771 Alder Drive
+ Milpitas, CA 95035
+
+ EMail: bfoster@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 209]
+
+RFC 3435 MGCP 1.0 January 2003
+
+
+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 assigns.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andreasen & Foster Informational [Page 210]
+