As per Relevance of the word requested, we have this rfc below:
Network Working Group M.
Request for Comments: 2705 RSL
Category: Informational A.
I.
Level3
C.
S.
Vertical
October 1999
Media Gateway Control Protocol (MGCP
Version 1.0
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
IESG NOTE
This document is being published for the information of
community. It describes a protocol that is currently being
in a number of products. Implementers should be aware
developments in the IETF Megaco Working Group and ITF-T SG16 who
currently working on a potential successor to this protocol
This document describes an application programming interface and
corresponding protocol (MGCP) for controlling Voice over IP (VoIP
Gateways from external call control elements. MGCP assumes a
control architecture where the call control "intelligence" is
the gateways and handled by external call control elements
The document is structured in 6 main sections
* The introduction presents the basic assumptions and the
to other protocols such as H.323, RTSP, SAP or SIP
Arango, et al. Informational [Page 1]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
* The interface section presents a conceptual overview of the MGCP
presenting the naming conventions, the usage of the
description protocol SDP, and the procedures that compose MGCP
Notifications Request, Notification, Create Connection,
Connection, Delete Connection, AuditEndpoint, AuditConnection
RestartInProgress
* The protocol description section presents the MGCP encodings
which are based on simple text formats, and the
procedure over UDP
* The security section presents the security requirement of MGCP
and its usage of IP security services (IPSEC).
* The event packages section provides an initial definition
packages and event names
* The description of the changes made in combining SGCP 1.1 and
to create MGCP 1.0.
Table of
1. Introduction .............................................. 5
1.1. Relation with the H.323 standards .................... 7
1.2. Relation with the IETF standards ..................... 8
1.3. Definitions .......................................... 9
2. Media Gateway Control Interface ........................... 9
2.1. Model and naming conventions. ........................ 10
2.1.1. Types of endpoints .............................. 10
2.1.1.1. Digital channel (DS0) ...................... 11
2.1.1.2. Analog line ................................ 11
2.1.1.3. Annoucement server access point ............ 12
2.1.1.4. Interactive Voice Response access point .... 12
2.1.1.5. Conference bridge access point ............. 13
2.1.1.6. Packet relay ............................... 13
2.1.1.7. Wiretap access point ....................... 14
2.1.1.8. ATM "trunk side" interface. ................ 14
2.1.2. Endpoint identifiers ............................ 15
2.1.3. Calls and connections ........................... 17
2.1.3.1. Names of calls ............................. 20
2.1.3.2. Names of connections ....................... 20
2.1.3.3. Management of resources, attributes of ..... 20
2.1.3.4. Special case of local connections .......... 23
2.1.4. Names of Call Agents and other entities ......... 23
2.1.5. Digit maps ...................................... 24
2.1.6. Names of events ................................. 26
2.2. Usage of SDP ......................................... 29
2.3. Gateway Control Commands ............................. 30
Arango, et al. Informational [Page 2]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
2.3.1. EndpointConfiguration ........................... 32
2.3.2. NotificationRequest ............................. 33
2.3.3. CreateConnection ................................ 38
2.3.4. ModifyConnection ................................ 44
2.3.5. DeleteConnection (from the Call Agent) .......... 46
2.3.6. DeleteConnection (from the VoIP gateway) ........ 51
2.3.7. DeleteConnection (multiple connections, from the 51
2.3.8. Audit Endpoint .................................. 52
2.3.9. Audit Connection ................................ 55
2.3.10. Restart in progress ............................ 56
2.4. Return codes and error codes. ........................ 58
2.5. Reason Codes ......................................... 61
3. Media Gateway Control Protocol ............................ 61
3.1. General description .................................. 62
3.2. Command Header ....................................... 62
3.2.1. Command line .................................... 62
3.2.1.1. Coding of the requested verb ............... 63
3.2.1.2. Transaction Identifiers .................... 63
3.2.1.3. Coding of the endpoint identifiers and ..... 64
3.2.1.4. Coding of the protocol version ............. 65
3.2.2. Parameter lines ................................. 65
3.2.2.1. Response Acknowledgement ................... 68
3.2.2.2. Local connection options ................... 68
3.2.2.3. Capabilities ............................... 70
3.2.2.4. Connection parameters ...................... 71
3.2.2.5. Reason Codes ............................... 72
3.2.2.6. Connection mode ............................ 73
3.2.2.7. Coding of event names ...................... 73
3.2.2.8. RequestedEvents ............................ 74
3.2.2.9. SignalRequests ............................. 76
3.2.2.10. ObservedEvent ............................. 76
3.2.2.11. RequestedInfo ............................. 76
3.2.2.12. QuarantineHandling ........................ 77
3.2.2.13. DetectEvents .............................. 77
3.2.2.14. EventStates ............................... 77
3.2.2.15. RestartMethod ............................. 78
3.2.2.16. Bearer Information ........................ 78
3.3. Format of response headers ........................... 78
3.4. Formal syntax description of the protocol ............ 81
3.5. Encoding of the session description .................. 86
3.5.1. Usage of SDP for an audio service ............... 86
3.5.2. Usage of SDP in a network access service ........ 87
3.5.3. Usage of SDP for ATM connections ................ 90
3.5.4. Usage of SDP for local connections .............. 91
3.6. Transmission over UDP ................................ 91
3.6.1. Providing the At-Most-Once functionality ........ 91
3.6.2. Transaction identifiers and three ways handshake. 92
3.6.3. Computing retransmission timers ................. 93
Arango, et al. Informational [Page 3]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
3.6.4. Piggy backing ................................... 94
3.6.5. Provisional responses ........................... 94
4. States, failover and race conditions. ..................... 95
4.1. Basic Asumptions ..................................... 95
4.2. Security, Retransmission, and Detection of Lost ...... 96
4.3. Race conditions ...................................... 99
4.3.1. Quarantine list ................................. 99
4.3.2. Explicit detection ..............................103
4.3.3. Ordering of commands, and treatment of disorder .104
4.3.4. Fighting the restart avalanche ..................105
4.3.5. Disconnected Endpoints ..........................107
1. A "disconnected" timer is initialized to a random value, .107
2. The gateway then waits for either the end of this timer, .107
3. When the "disconnected" timer elapses, when a command is .107
4. If the "disconnected" procedure still left the endpoint ..107
5. Security requirements .....................................108
5.1. Protection of media connections ......................109
6. Event packages and end point types ........................109
6.1. Basic packages .......................................110
6.1.1. Generic Media Package ...........................110
6.1.2. DTMF package ....................................112
6.1.3. MF Package ......................................113
6.1.4. Trunk Package ...................................114
6.1.5. Line Package ....................................116
6.1.6. Handset emulation package .......................119
6.1.7. RTP Package .....................................120
6.1.8. Network Access Server Package ...................121
6.1.9. Announcement Server Package .....................122
6.1.10. Script Package .................................122
6.2. Basic endpoint types and profiles ....................123
7. Versions and compatibility ................................124
7.1. Differences between version 1.0 and draft 0.5 ........124
7.2. Differences between draft-04 and draft-05 ............125
7.3. Differences between draft-03 and draft-04 ............125
7.4. Differences between draft-02 and draft-03 ............125
7.5. Differences between draft-01 and draft-02 ............126
7.6. The making of MGCP from IPDC and SGCP ................126
7.7. Changes between MGCP and initial versions of SGCP ....126
8. Security Considerations ...................................128
9. Acknowledgements ..........................................128
10. References ................................................129
11. Authors' Addresses ........................................130
12. Appendix A: Proposed "MoveConnection" command .............132
12.1. Proposed syntax modification ........................133
13. Full Copyright Statement ..................................134
Arango, et al. Informational [Page 4]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
1.
This document describes an abstract application programming
and a corresponding protocol (MGCP) for controlling
Gateways from external call control elements called media
controllers or call agents. A telephony gateway is a network
that provides conversion between the audio signals carried
telephone circuits and data packets carried over the Internet or
other packet networks. Example of gateways are
* Trunking gateways, that interface between the telephone
and a Voice over IP network. Such gateways typically manage
large number of digital circuits
* Voice over ATM gateways, which operate much the same way as
over IP trunking gateways, except that they interface to an
network
* Residential gateways, that provide a traditional analog (RJ11)
interface to a Voice over IP network. Examples of
gateways include cable modem/cable set-top boxes, xDSL devices
broad-band wireless
* Access gateways, that provide a traditional analog (RJ11)
digital PBX interface to a Voice over IP network. Examples
access gateways include small-scale voice over IP gateways
* Business gateways, that provide a traditional digital
interface or an integrated "soft PBX" interface to a Voice over
network
* Network Access Servers, that can attach a "modem" to a
circuit and provide data access to the Internet. We expect that
in the future, the same gateways will combine Voice over
services and Network Access services
* Circuit switches, or packet switches, which can offer a
interface to an external call control element
MGCP assumes a call control architecture where the call
"intelligence" is outside the gateways and handled by external
control elements. The MGCP assumes that these call control elements
or Call Agents, will synchronize with each other to send
commands to the gateways under their control. MGCP does not define
mechanism for synchronizing Call Agents. MGCP is, in essence,
master/slave protocol, where the gateways are expected to
commands sent by the Call Agents. In consequence, this
specifies in great detail the expected behavior of the gateways,
Arango, et al. Informational [Page 5]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
only specify those parts of a call agent implementation, such
timer management, that are mandated for proper operation of
protocol
MGCP assumes a connection model where the basic constructs
endpoints and connections. Endpoints are sources or sinks of data
could be physical or virtual. Examples of physical endpoints are
* An interface on a gateway that terminates a trunk connected to
PSTN switch (e.g., Class 5, Class 4, etc.). A gateway
terminates trunks is called a trunk gateway
* An interface on a gateway that terminates an analog
connection to a phone, key system, PBX, etc. A gateway
terminates residential POTS lines (to phones) is called
residential gateway
An example of a virtual endpoint is an audio source in an audio
content server. Creation of physical endpoints requires
installation, while creation of virtual endpoints can be done
software
Connections may be either point to point or multipoint. A point
point connection is an association between two endpoints with
purpose of transmitting data between these endpoints. Once
association is established for both endpoints, data transfer
these endpoints can take place. A multipoint connection
established by connecting the endpoint to a multipoint session
Connections can be established over several types of bearer networks
* Transmission of audio packets using RTP and UDP over a TCP/
network
* Transmission of audio packets using AAL2, or another
layer, over an ATM network
* Transmission of packets over an internal connection, for
the TDM backplane or the interconnection bus of a gateway. This
used, in particular, for "hairpin" connections, connections
terminate in a gateway but are immediately rerouted over
telephone network
For point-to-point connections the endpoints of a connection could
in separate gateways or in the same gateway
Arango, et al. Informational [Page 6]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
1.1. Relation with the H.323
MGCP is designed as an internal protocol within a distributed
that appears to the outside as a single VoIP gateway. This system
composed of a Call Agent, that may or may not be distributed
several computer platforms, and of a set of gateways, including
least one "media gateway" that perform the conversion of
signals between circuits and packets, and at least one "
gateway" when connecting to an SS7 controlled network. In a
configuration, this distributed gateway system will interface on
side with one or more telephony (i.e. circuit) switches, and on
other side with H.323 conformant systems, as indicated in
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
function, while the Call Agent handles the signaling and
processing functions. As a consequence, the Call Agent implements
"signaling" layers of the H.323 standard, and presents itself as
"H.323 Gatekeeper" or as one or more "H.323 Endpoints" to the H.323
systems
Arango, et al. Informational [Page 7]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
1.2. Relation with the IETF
While H.323 is the recognized standard for VoIP terminals, the
has also produced specifications for other types of multi-
applications. These other specifications include
* the Session Description Protocol (SDP), RFC 2327,
* the Session Announcement Protocol (SAP),
* the Session Initiation Protocol (SIP),
* the Real Time Streaming Protocol (RTSP), RFC 2326.
The latter three specifications are in fact alternative
standards that allow for the transmission of a session description
an interested party. SAP is used by multicast session managers
distribute a multicast session description to a large group
recipients, SIP is used to invite an individual user to take part
a point-to-point or unicast session, RTSP is used to interface
server that provides real time data. In all three cases, the
description is described according to SDP; when audio is transmitted
it is transmitted through the Real-time Transport Protocol, RTP
The distributed gateway systems and MGCP will enable PSTN
users to access sessions set up using SAP, SIP or RTSP. The
Agent provides for signaling conversion, according to the
table
Arango, et al. Informational [Page 8]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
_____________________________________________________________________
| 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 | |
| | | synchronization| |
| | | 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
see in the following description that we also use it to carry
descriptions in MGCP
1.3.
Trunk: A communication channel between two switching systems. E.g.,
DS0 on a T1 or E1 line
2. Media Gateway Control
The interface functions provide for connection control and
control. Both use the same system model and the same
conventions
Arango, et al. Informational [Page 9]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
2.1. Model and naming
The MGCP assumes a connection model where the basic constructs
endpoints and connections. Connections are grouped in calls. One
more connections can belong to one call. Connections and calls
set up at the initiative of one or several Call Agents
2.1.1. Types of
In the introduction, we presented several classes of gateways.
classifications, however, can be misleading. Manufacturers
arbitrarily decide to provide several types of services in a
packaging. A single product could well, for example, provide
trunk connections to telephony switches, some primary
connections and some analog line interfaces, thus sharing
characteristics of what we described in the introduction
"trunking", "access" and "residential" gateways. MGCP does not
assumptions about such groupings. We simply assume that
gateways support collections of endpoints. The type of the
determines its functionalities. Our analysis, so far, has led us
isolate the following basic endpoint types
* Digital channel (DS0),
* Analog line
* Annoucement server access point
* Interactive Voice Response access point
* Conference bridge access point
* Packet relay
* Wiretap access point
* ATM "trunk side" interface
In this section, we will develop the expected behavior of such
points
This list is not limitative. There may be other types of
defined in the future, for example test endpoint that could be
to check network quality, or frame-relay endpoints that could be
to managed audio channels multiplexed over a frame-relay
circuit
Arango, et al. Informational [Page 10]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
2.1.1.1. Digital channel (DS0)
Digital channels provide an 8Khz*8bit service. Such channels
found in trunk and ISDN interfaces. They are typically part
digital multiplexes, such as T1, E1, T3 or E3 interfaces.
gateways that support such channels are capable of translating
digital signals received on the channel, which may be
according to A or mu-law, using either the complete set of 8 bits
only 7 of these bits, into audio packets. When the media
also supports a NAS service, the gateway shall be capable
receiving either audio-encoded data (modem connection) or binary
(ISDN connection) and convert them into data packets
+-------
+------------+|
(channel) ===|DS0 endpoint| --------
+------------+|
+-------
Media gateways should be able to establish several
between the endpoint and the packet networks, or between the
and other endpoints in the same gateway. The signals
from these connections shall be mixed according to the
"mode", as specified later in this document. The precise number
connections that an endpoint support is a characteristic of
gateway, and may in fact vary according with the allocation
resource within the gateway
In some cases, digital channels are used to carry signalling.
is the case for example of SS7 "F" links, or ISDN "D" channels
Media gateways that support these signalling functions shall be
to send and receive the signalling packets to and from a call agent
using the "back haul" procedures defined by the SIGTRAN working
of the IETF. Digital channels are sometimes used in conjunction
channel associated signalling, such as "MF R2". Media gateways
support these signalling functions shall be able to detect
produce the corresponding signals, such as for example "wink" or "A",
according to the event signalling and reporting procedures defined
MGCP
2.1.1.2. Analog
Analog lines can be used either as a "client" interface,
service to a classic telephone unit, or as a "service" interface
allowing the gateway to send and receive analog calls. When
media gateway also supports a NAS service, the gateway shall
capable of receiving audio-encoded data (modem connection)
convert them into data packets
Arango, et al. Informational [Page 11]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
+-------
+---------------+|
(line) ===|analog endpoint| --------
+---------------+|
+-------
Media gateways should be able to establish several
between the endpoint and the packet networks, or between the
and other endpoints in the same gateway. The audio
originating from these connections shall be mixed according to
connection "mode", as specified later in this document. The
number of connections that an endpoint support is a characteristic
the gateway, and may in fact vary according with the allocation
resource within the gateway. A typical gateway should however
able to support two or three connections per endpoint, in order
provide services such as "call waiting" or "three ways calling".
2.1.1.3. Annoucement server access
An announcement server endpoint provides acces to an
service. Under requests from the call agent, the announcement
will "play" a specified announcement. The requests from the
agent will follow the event signalling and reporting
defined in MGCP
+----------------------+
| Announcement endpoint| --------
+----------------------+
A given announcement endpoint is not supposed to support more
one connection at a time. If several connections were established
the same endpoint, then the same announcements would be
simultaneously over all the connections
Connections to an announcement server are typically oneway, or "
duplex" -- the announcement server is not expected to listen
audio signals from the connection
2.1.1.4. Interactive Voice Response access
An Interactive Voice Response (IVR) endpoint provides acces to an
service. Under requests from the call agent, the IVR server
"play" announcements and tones, and will "listen" to responses
the user. The requests from the call agent will follow the
signalling and reporting procedures defined in MGCP
Arango, et al. Informational [Page 12]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
+-------------+
| IVR endpoint| --------
+-------------+
A given IVR endpoint is not supposed to support more than
connection at a time. If several connections were established to
same endpoint, then the same tones and announcements would be
simultaneously over all the connections
2.1.1.5. Conference bridge access
A conference bridge endpoint is used to provide access to a
conference
+-------
+--------------------------+|
|Conference bridge endpoint| --------
+--------------------------+|
+-------
Media gateways should be able to establish several
between the endpoint and the packet networks, or between the
and other endpoints in the same gateway. The signals
from these connections shall be mixed according to the
"mode", as specified later in this document. The precise number
connections that an endpoint support is a characteristic of
gateway, and may in fact vary according with the allocation
resource within the gateway
2.1.1.6. Packet
A packet relay endpoint is a specific form of conference bridge,
typically only supports two connections. Packets relays can be
in firewalls between a protected and an open network, or
transcoding servers used to provide interoperation
incompatible gateways, for example gateways that do not
compatible compression algorithms, or gateways that operate
different transmission networks such as IP and ATM
+-------
+---------------------+ |
|Packet relay endpoint| 2
+---------------------+ |
+-------
Arango, et al. Informational [Page 13]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
2.1.1.7. Wiretap access
A wiretap access point provides access to a wiretap service
providing either a recording or a life playback of a connection
+-----------------+
| Wiretap endpoint| --------
+-----------------+
A given wiretap endpoint is not supposed to support more than
connection at a time. If several connections were established to
same endpoint, then the recording or playback would mix the
signals received on this connections
Connections to an wiretap endpoint are typically oneway, or "
duplex" -- the wiretap server is not expected to signal its
in a call
2.1.1.8. ATM "trunk side" interface
ATM "trunk side" endpoints are typically found when one or
ATM permanent virtual circuits are used as a replacement for
classic "TDM" trunks linking switches. When ATM/AAL2 is used
several trunks or channels are multiplexed on a single
circuit; each of these trunks correspond to a single endpoint
+-------
+------------------+|
(channel) = |ATM trunk endpoint| --------
+------------------+|
+-------
Media gateways should be able to establish several
between the endpoint and the packet networks, or between the
and other endpoints in the same gateway. The signals
from these connections shall be mixed according to the
"mode", as specified later in this document. The precise number
connections that an endpoint support is a characteristic of
gateway, and may in fact vary according with the allocation
resource within the gateway
Arango, et al. Informational [Page 14]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
2.1.2. Endpoint
Endpoints identifiers have two components that both are
insensitive
* the domain name of the gateway that is managing the endpoint
* a local name within that gateway
The syntax of the local name depends on the type of endpoint
named. However, the local name for each of these types is
hierarchical, beginning with a term which identifies the
gateway containing the given endpoint and ending in a term
specifies the individual endpoint concerned. With this in mind,
following rules for construction and interpretation of the
Name field for these entity types MUST be supported
1) The individual terms of the naming path MUST be separated by
single slash ("/", ASCII 2F hex).
2) The individual terms are character strings composed of letters
digits or other printable characters, with the exception
characters used as delimitors ("/", "@"), characters used
wildcarding ("*", "$") and white spaces
3) Wild-carding is represented either by an asterisk ("*") or
dollar sign ("$") for the terms of the naming path which are to
wild-carded. Thus, if the full naming path looks
term1/term2/term
then the Entity Name field looks like this depending on
terms are wild-carded
*/term2/term3 if term1 is wild-
term1/*/term3 if term2 is wild-
term1/term2/* if term3 is wild-
term1/*/* if term2 and term3 are wild-carded
etc
In each of these examples a dollar sign could have
instead of an asterisk
Arango, et al. Informational [Page 15]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
4) A term represented by an asterisk is to be interpreted as: "
ALL values of this term known within the scope of the
Gateway". A term represented by a dollar sign is to
interpreted as: "use ANY ONE value of this term known within
scope of the Media Gateway". The description of a
command may add further criteria for selection within the
rules given here
If the Media Gateway controls multiple physical gateways, the
term of the naming MUST identify the physical gateway containing
desired entity. If the Media Gateway controls only a single
gateway, the first term of the naming string MAY identify
physical gateway, depending on local practice. A local name that
composed of only a wildcard character refers to either all (*) or
($) endpoints within the media gateway
In the case of trunking gateways, endpoints are trunk
linking a gateway to a telephone switch. These circuits are
grouped into a digital multiplex, that is connected to the gateway
a physical interface. Such circuits are named in three contexts
* In the ISUP protocol, trunks are grouped into trunk groups
identified by the SS7 point codes of the switches that the
connects. Circuits within a trunk group are identified by
circuit number (CIC in ISUP).
* In the gateway configuration files, physical interfaces
typically identified by the name of the interface, an
text string. When the interface multiplexes several circuits
individual circuits are typically identified by a circuit number
* In MGCP, the endpoints are identified by an endpoint identifier
The Call Agents use configuration databases to map ranges of
numbers within an ISUP trunk group to corresponding ranges
circuits in a multiplex connected to a gateway through a
interface. The gateway will be identified, in MGCP, by a domain name
The local name will be structured to encode both the name of
physical interface, for example X35V3+A4, and the circuit
within the multiplex connected to the interface, for example 13.
circuit number will be separated from the name of the interface by
fraction bar, as in
X35V3+A4/13
Arango, et al. Informational [Page 16]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Other types of endpoints will use different conventions. For example
in gateways were physical interfaces by construction only control
circuit, the circuit number will be omitted. The exact syntax of
names should be specified in the corresponding server specification
2.1.3. Calls and
Connections are created on the call agent on each endpoint that
be involved in the "call." In the classic example of a
between two "DS0" endpoints (EP1 and EP2), the call
controlling the end points will establish two connections (C1
C2):
+---+ +---+
(channel1) ===|EP1|--(C1)--... ...(C2)--|EP2|===(channel2)
+---+ +---+
Each connection will be designated locally by a
identifier, and will be characterized by connection attributes
When the two endpoints are located on gateways that are managed
the same call agent, the creation is done via the three
steps
1) The call agent asks the first gateway to "create a connection"
the first endpoint. The gateway allocates resources to
connection, and respond to the command by providing a "
description." The session description contains the
necessary for a third party to send packets towards the
created connection, such as for example IP address, UDP port,
packetization parameters
2) The call agent then asks the second gateway to "create
connection" on the second endpoint. The command carries
"session description" provided by the first gateway. The
allocates resources to that connection, and respond to the
by providing its own "session description."
3) The call agent uses a "modify connection" command to provide
second "session description" to the first endpoint. Once this
done, communication can proceed in both directions
When the two endpoints are located on gateways that are managed
the different call agents, these two call agents shall
information through a call-agent to call-agent signalling protocol
in order to synchronize the creation of the connection on the
endpoints
Arango, et al. Informational [Page 17]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Once established, the connection parameters can be modified at
time by a "modify connection" command. The call agent may
example instruct the gateway to change the compression algorithm
on a connection, or to modify the IP address and UDP port to
data should be sent, if a connection is "redirected."
The call agent removes a connection by sending to the gateway
"delete connection" command. The gateway may also, under
circumstances, inform a gateway that a connection could not
sustained
The following diagram provides a view of the states of a connection
as seen from the gateway
Arango, et al. Informational [Page 18]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Create
|
+-------------------+
|resource allocation|-(failed)-+
+-------------------+ |
| (connection refused
(successful
|
+----------->+
| |
| +-------------------+
| | 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. |
+-----------------+
|
Arango, et al. Informational [Page 19]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
2.1.3.1. Names of
One of the attributes of each connection is the "call identifier."
Calls are identified by unique identifiers, independent of
underlying platforms or agents. These identifiers are created by
Call Agent. They are treated in MGCP as unstructured octet strings
Call identifiers are expected to be unique within the system, or at
minimum, unique within the collection of Call Agents that control
same gateways. When a Call Agent builds several connections
pertain to the same call, either on the same gateway or in
gateways, these connections that belong to the same call share
same call-id. This identifier can then be used by accounting
management procedures, which are outside the scope of MGCP
2.1.3.2. Names of
Connection identifiers are created by the gateway when it
requested to create a connection. They identify the connection
the context of an endpoint. They are treated in MGCP as
octet strings. The gateway should make sure that a proper
period, at least 3 minutes, elapses between the end of a
that used this identifier and its use in a new connection for
same endpoint. (Gateways may decide to use identifiers that
unique within the context of the gateway.)
2.1.3.3. Management of resources, attributes of
Many types of resources will be associated to a connection, such
specific signal processing functions or packetization functions
Generally, these resources fall in two categories
1) Externally visible resources, that affect the format of "the
on the network" and must be communicated to the second
involved in the connection
2) Internal resources, that determine which signal is being sent
the connection and how the received signals are processed by
endpoint
The resources allocated to a connection, and more generally
handling of the connection, are chosen by the gateway
instructions from the call agent. The call agent will provide
instructions by sending two set of parameters to the gateway
1) The local directives instruct the gateway on the choice
resources that should be used for a connection
Arango, et al. Informational [Page 20]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
2) When available, the "session description" provided by the
end of the connection
The local directives specify such parameters as the mode of
connection (e.g. send only, send-receive), preferred coding
packetization methods, usage of echo cancellation or
suppression. (A detailed list can be found in the specification
the LocalConnectionOptions parameter of the
command.) For each of these parameters, the call agent can
specify a value, a range of value, or no value at all. This
various implementations to implement various level of control, from
very tight control where the call agent specifies minute details
the connection handling to a very loose control where the call
only specifies broad guidelines, such as the maximum bandwidth,
let the gateway choose the detailed values
Based on the value of the local directives, the gateway
determine the resources allocated to the connection. When this
possible, the gateway will choose values that are in line with
remote session description - but there is no absolute
that the parameters be exactly the same
Once the resource have been allocated, the gateway will compose
"session description" that describes the way it intends to
packets. Note that the session description may in some cases
a range of values. For example, if the gateway is ready to
one of several compression algorithm, it can provide a list of
accepted algorithms
Arango, et al. Informational [Page 21]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Local
(from call agent 1)
|
+-------------+
| resources |
| allocation |
| (gateway 1) |
+-------------+
| |
V |
Local |
Parameters
|
| Description Local
| | (from call agent 2)
| +---> Transmission----+ |
| (CA to CA) | |
| V
| +-------------+
| | resources |
| | allocation |
| | (gateway 2) |
| +-------------+
| | |
| |
| |
| |
|
|
| +---- Transmission<---+
| | (CA to CA
V
+-------------+
| modification
| (gateway 1) |
+-------------+
|
-- Information flow: local directives & session descriptions --
Arango, et al. Informational [Page 22]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
2.1.3.4. Special case of local
Large gateways include a large number of endpoints which are often
different types. In some networks, we may often have to set-
connections between endpoints that are located within the
gateway. Examples of such connections may be
* Connecting a trunk line to a wiretap device
* Connecting a call to an Interactive Voice-Response unit
* Connecting a call to a Conferencing unit
* Routing a call from on endpoint to another, something
described as a "hairpin" connection
Local connections are much simpler to establish than
connections. In most cases, the connection will be
through some local interconnecting device, such as for example a
bus
When two endpoints are managed by the same gateway, it is possible
specify the connection in a single command that conveys the name
the two endpoints that will be connected. The command is
a "Create Connection" command which includes the name of the
endpoint in lieu of the "remote session description."
2.1.4. Names of Call Agents and other
The media gateway control protocol has been designed to allow
implementation of redundant Call Agents, for enhanced
reliability. This means that there is no fixed binding
entities and hardware platforms or network interfaces
Reliability can be improved by the following precautions
* Entities such as endpoints or Call Agents are identified by
domain name, not their network addresses. Several addresses can
associated with a domain name. If a command or a response
be forwarded to one of the network addresses,
should retry the transmission using another address
* Entities may move to another platform. The association between
logical name (domain name) and the actual platform are kept in
domain name service. Call Agents and Gateways should keep track
the time-to-live of the record they read from the DNS. They
query the DNS to refresh the information if the time to live
expired
Arango, et al. Informational [Page 23]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
In addition to the indirection provided by the use of domain
and the DNS, the concept of "notified entity" is central
reliability and fail-over in MGCP. The "notified entity" for
endpoint is the Call Agent currently controlling that endpoint.
any point in time, an endpoint has one, and only one, "
entity" associated with it, and when the endpoint needs to send
command to the Call Agent, it MUST send the command to the
"notified entity" for which endpoint(s) the command pertains.
startup, the "notified entity" MUST be set to a provisioned value
Most commands sent by the Call Agent include the ability
explicitly name the "notified entity" through the use of
"NotifiedEntity" parameter. The "notified entity" will stay the
until either a new "NotifiedEntity" parameter is received or
endpoint reboots. If the "notified entity" for an endpoint is
or has not been set explicitly, the "notified entity" will
default to the source address of the last connection handling
or notification request received for the endpoint. Auditing will
not change the "notified entity."
2.1.5. Digit
The Call Agent can ask the gateway to collect digits dialed by
user. This facility is intended to be used with residential
to collect the numbers that a user dials; it may also be used
trunking gateways and access gateways alike, to collect the
codes, credit card numbers and other numbers requested by
control services
An alternative procedure is for the gateway to notify the Call
of the dialed digits, as soon as they are dialed. However, such
procedure generates a large number of interactions. It is
to accumulate the dialed numbers in a buffer, and to transmit them
a single message
The problem with this accumulation approach, however, is that it
hard for the gateway to predict how many numbers it needs
accumulate before transmission. For example, using the phone on
desk, we can dial the following numbers
Arango, et al. Informational [Page 24]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
_______________________________________________________
| 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 load the gateway with a digit
that correspond to the dial plan. This digit map is expressed using
syntax derived from the Unix system command, egrep. For example,
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
in the formal syntax description of the protocol (section 3.4).
Digit-Map, according to this syntax, is defined either by a "string
or by a list of strings. Each string in the list is an
numbering scheme, specified either as a set of digits or timers,
as regular expression. A gateway that detects digits, letters
timers will
1) Add the event parameter code as a token to the end of an
state variable called the "current dial string
2) Apply the current dial string to the digit map table, attempting
match to each regular expression in the Digit Map in lexical
3) If the result is under-qualified (partially matches at least
entry in the digit map), do nothing further
If the result matches, or is over-qualified (i.e. no further
could possibly produce a match), send the current digit string to
Call Agent. A match, in this specification, can be either a "
match," exactly matching one of the specified alternatives, or
impossible match, which occur when the dial string does not match
of the alternative. Unexpected timers, for example, can
"impossible matches." Both perfect matches and impossible
trigger notification of the accumulated digits
Digit maps are provided to the gateway by the Call Agent,
the Call Agent instructs the gateway to listen for digits
Arango, et al. Informational [Page 25]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
2.1.6. Names of
The concept of events and signals is central to MGCP. A Call
may ask to be notified about certain events occurring in an endpoint
e.g. off-hook events, and a call agent may request certain
to be applied to an endpoint, e.g. dial-tone
Events and signals are grouped in packages within which they
the same namespace which we will refer to as event names in
following. Packages are groupings of the events and
supported by a particular type of endpoint. For instance, one
may support a certain group of events and signals for analog
lines, and another package may support another group of events
signals for video lines. One or more packages may exist for a
endpoint-type
Event names are case insensitive and are composed of two
parts, a package name and an event name. Both names are strings
letters, hyphens and digits, with the restriction that hyphens
never be the first or last characters in a name. Package or
names are not case sensitive - values such as "hu", "Hu", "HU"
"hU" should be considered equal
Examples of package names are "D" (DTMF), "M" (MF), "T" (Trunk)
"L" (Line). Examples of event names can be "hu" (off hook or "hang
up" transition), "hf" (flash hook) or "0" (the digit zero).
In textual representations, the package name, when present,
separated from the event name by a slash ("/"). The package name
in fact optional. Each endpoint-type has a default package
with it, and if the package name is excluded from the event name,
default package name for that endpoint-type is assumed. For example
for an analog access line, the following two event names are equal
l/dl dial-tone in the line package for an analog access line
dl dial-tone in the line package (default) for an analog
line
This document defines a basic set of package names and event names
Additional package names and event names can be registered with
IANA. A package definition shall define the name of the package,
the definition of each event belonging to the package. The
definition shall include the precise name of the event (i.e.,
code used in MGCP), a plain text definition of the event, and,
appropriate, the precise definition of the corresponding signals,
example the exact frequencies of audio signal such as dial tones
DTMF tones
Arango, et al. Informational [Page 26]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
In addition, implementers can gain experience by using
packages. The names of experimental packages must start with the
characters "x-"; the IANA shall not register package names that
with these characters
Digits, or letters, are supported in many packages, notably "DTMF
and "MF". Digits and letters are defined by the rules "Digit"
"Letter" in the definition of digit maps. This definition refers
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
"digit string" that represent the keys that a user punched on a dial
In addition, the letter "X" can be used to represent all digits,
the sign "$" can be used in wildcard notations. The need to
express the digit strings has a consequence on the form of
names
An event name that does not denote a digit should always contain
least one character that is neither a digit, nor one of the
A, B, C, D, T or X. (Such names should not contain the
signs "*", "#", "/" or "$".)
A Call Agent may often have to ask a gateway to detect a group
events. Two conventions can be used to denote such groups
* The wildcard convention can be used to detect any event
to a package, or a given event in many packages, or event
event in any package supported by the gateway
* The regular expression Range notation can be used to detect
range of digits
The star sign (*) can be used as a wildcard instead of a
name, and the keyword "all" can be used as a wildcard instead of
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
supported by the
The names "*" or "*/all" denote all events supported by
gate way
The call agent can ask a gateway to detect a set of digits or
either by individually describing those letters, or by using
"range" notation defined in the syntax of digit strings. For example
the call agent can
Arango, et al. Informational [Page 27]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
Use the letter "x" to denote "any letter or digit."
Use the notation "[0-9#]" to denote the digits 0 to 9 and the
sign
In some cases, Call Agents will request the gateway to generate
detect events on connections rather than on the end point itself
For example, gateways may be asked to provide a ringback tone on
connection. When an event shall be applied on a connection, the
of the connection is added to the name of the event, using an "at
sign (@) as a delimiter, as in
G/rt@0A3F58
The wildcard character "*" (star) can be used to denote "
connections". When this convention is used, the gateway will
or detect the event on all the connections that are connected to
endpoint. An example of this convention could be
R/qa@*
The wildcard character "$" can be used to denote "the
connection." It should only be used by the call agent, when the
notification request is "encapsulated" within a command creation
modification command. When this convention is used, the gateway
generate or detect the event on the connection that is
being created or modified. An example of this convention is
G/rt@$
The connection id, or a wildcard replacement, can be used
conjunction with the "all packages" and "all events" conventions
For example, the notation
*/all@*
can be used to designate all events on all connections
Events and signals are described in packages. The package
must provide, for each events, the following informations
* The description of the event and its purpose, which should
the actual signal that is generated by the client (i.e., xx ms
tone) as well as the resulting user observed result (i.e.,
light on/off).
* The detailed characteristics of the event, such as for
frequencies and amplitude of audio signals, modulations
repetitions
Arango, et al. Informational [Page 28]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
* The typical and maximum duration of the event
Signals are divided into different types depending on their behavior
* On/off (OO) Once applied, these signals last forever until
are turned off. This may happen either as the result of an
or a new SignalRequests (see later).
* Time-out (TO) Once applied, these signals last until they
either turned off (by an event or SignalRequests) or a
specific period of time has elapsed. Depending on
specifications, a signal that times out may generate an "
complete" event
* Brief (BR) The duration of these signals is so short, that
stop on their own. If an event occurs the signal will not stop
however if a new SignalRequests is applied, the signal will stop
(Note: this point should be debated. One could make a case
events such as strings of DTMF digits should in fact be allowed
complete.)
TO signals are normally used to alert the endpoints' users,
signal them that they are expected to perform a specific action
such as hang down the phone (ringing). Transmission of
signals should typically be interrupted as soon as the first
the requested events has been produced
Package descriptions should describe, for all signals, their
(OO, TO, BR). They should also describe the maximum duration
the TO signals
2.2. Usage of
The Call Agent uses the MGCP to provision the gateways with
description of connection parameters such as IP addresses, UDP
and RTP profiles. These descriptions will follow the
delineated in the Session Description Protocol which is now an
proposed standard, documented in RFC 2327.
SDP allows for description of multimedia conferences. This
limits SDP usage to the setting of audio circuits and data
circuits. The initial session descriptions contain the
of exactly one media, of type "audio" for audio connections, "nas
for data access
Arango, et al. Informational [Page 29]
RFC 2705 Media Gateway Control Protocol (MGCP) October 1999
2.3. Gateway Control
This section describes the commands of the MGCP. The service
of connection handling and endpoint handling commands. There are
commands in the protocol
* The Call Agent can issue an EndpointConfiguration command to
gateway, instructing the gateway about the coding
expected by the "line-side" of the endpoint
* The Call Agent can issue a NotificationRequest command to
gateway, instructing the gateway to watch for specific events
as hook actions or DTMF tones on a specified endpoint .
* The gateway will then use the Notify command to inform the
Agent when the requested events occur
* The Call Agent can use the CreateConnection command to create
connection that terminates in an "endpoint" inside the gateway
* The Call Agent can use the ModifyConnection command to change
parameters associated to a previously established connection
* The Call Agent can use the DeleteConnection command to delete
existing connection. The DeleteConnection command may also be
by a gateway to indicate that a connection can no longer
sustained
* The Call Agent can use the AuditEndpoint and
