Media Gateway Control Protocol
The Media Gateway Control Protocol (MGCP) is a text-based, client-server protocol designed to enable external call control elements, known as Call Agents, to manage and control media gateways in decomposed multimedia telephony systems, particularly for Voice over IP (VoIP) applications where media conversion occurs between circuit-switched networks and packet-based networks.[1] It facilitates the creation, modification, and deletion of connections on gateway endpoints, event detection, signal generation, and auditing of endpoint and connection states, assuming a master-slave architecture where gateways execute commands from Call Agents without independent call intelligence.[1] Originally specified in 1999 and revised in 2003, MGCP supports telephony services like trunking and residential gateways by separating signaling from media handling to enhance scalability and flexibility in IP networks.[2][1] In MGCP's architecture, the Media Gateway (MG) acts as the client, handling media mapping, transcoding, and termination functions for endpoints such as DS0 channels, analog lines, or RTP ports, while the Media Gateway Controller (MGC) or Call Agent serves as the server, issuing commands to orchestrate call processing, resource allocation, and quality-of-service mechanisms across potentially dissimilar networks like switched circuit networks (SCN) and IP/ATM packet networks.[3][1] Endpoints represent specific terminations on the MG where media streams enter or exit, and connections link these endpoints to enable bidirectional media flow in modes such as sendonly, recvonly, or sendrecv.[3] This decomposition allows for centralized control intelligence outside the gateways, supporting applications like VoIP trunking and multimedia sessions while ensuring interoperability through standardized resource reservation and event processing.[3] The protocol operates via transaction-based commands and responses transmitted over UDP (default port 2427 for gateways, 2727 for Call Agents), with optional TCP support, using transaction identifiers for correlation and retransmission handling via timers like T-HIST (30 seconds) and T-MAX (20 seconds).[1] Core commands include CreateConnection (CRCX) for establishing connections with Session Description Protocol (SDP) descriptors, ModifyConnection (MDCX) for parameter adjustments like codec changes, DeleteConnection (DLCX) for termination and statistics retrieval, NotificationRequest (RQNT) for event monitoring (e.g., DTMF detection via digit maps and quarantine buffers), Notify (NTFY) for reporting detected events, and audit commands like AuditEndpoint (AUEP) and AuditConnection (AUCX) for status queries.[1] Additional features encompass wildcarding for bulk endpoint addressing, package extensions for gateway-specific capabilities (e.g., basic package 'B' per RFC 3660), and security via IP Authentication Header or Encapsulating Security Payload.[1][4] MGCP's standards are primarily defined in RFC 3435 (obsoleting RFC 2705), which outlines the protocol version 1.0, alongside RFC 2805 for architecture and requirements, and companion documents like RFC 3660 for basic packages covering generic, line, trunk, and RTP functionalities.[1][2][3] While MGCP remains influential for its simplicity and extensibility in legacy VoIP deployments, it has been largely superseded in modern systems by the more feature-rich Megaco/H.248 protocol (RFC 3015), though MGCP continues to underpin certain packet telephony interfaces due to its lightweight design.[1]Introduction
Definition and Purpose
The Media Gateway Control Protocol (MGCP) is a text-based, application-layer protocol operating at OSI Layer 7, designed for signaling and call control between media gateway controllers (MGCs) and media gateways (MGs).[1] It implements a set of transactions that enable MGCs to manage MG resources, including the detection of events on endpoints and the notification of the MGC when such events occur.[1] As a master-slave protocol, MGCP positions the MGC as the master, issuing commands that the MG, acting as the slave, must execute without significant independent decision-making.[1] The primary purpose of MGCP is to provide centralized control over media gateways, facilitating the conversion of media streams between traditional Public Switched Telephone Network (PSTN) formats and Internet Protocol (IP) networks in voice over IP (VoIP) and hybrid telecommunications environments.[1] It supports the creation, modification, and deletion of connections on MG endpoints to establish, maintain, and terminate voice or multimedia sessions, while also allowing for the auditing of endpoint and connection states.[1] This architecture separates call control intelligence from media handling, enabling scalable deployment in distributed systems where MGs focus solely on media translation and transport.[5] MGCP offers key benefits through its straightforward master-slave model, which simplifies implementation by minimizing the intelligence required in gateways and promoting ease of integration into broader VoIP architectures.[1] It accommodates multiple endpoints per gateway, allowing efficient resource management for residential, trunking, or access gateways without the need for complex peer-to-peer negotiations.[5] Developed collaboratively by Bellcore (now Telcordia Technologies), Level 3 Communications, and Cisco Systems, MGCP was introduced in 1998 as a successor to earlier protocols like the Simple Gateway Control Protocol (SGCP) and Internet Protocol Device Control (IPDC), combining their features into a unified framework.[5]Historical Development
The Media Gateway Control Protocol (MGCP) originated in late 1998 through the merger of two competing proposals: the Simple Gateway Control Protocol (SGCP), developed by Bellcore (now Telcordia Technologies) and Cisco Systems, and the Internet Protocol Device Control (IPDC), advanced by Level 3 Communications.[6] This collaboration among key industry players sought to consolidate fragmented efforts in gateway control signaling for emerging Voice over IP (VoIP) networks.[7] The resulting protocol, initially termed MGCP version 0.1, built upon SGCP's foundational structure while incorporating IPDC's device control elements, marking a shift toward a master-slave architecture for media gateway management.[8] MGCP was specifically designed to overcome the scalability and complexity challenges of peer-to-peer protocols like H.323 in early VoIP deployments, where centralized control of gateways interfacing with the Public Switched Telephone Network (PSTN) was essential for reliable call handling.[2] The protocol's development emphasized simplicity and extensibility, enabling call agents to decompose multimedia sessions into basic media gateway functions without the overhead of full peer negotiation.[2] Primary contributors included Mauricio Arango (initially from Bellcore), Andrew Dugan and Isaac Elliott (Level 3 Communications), Christian Huitema (Telcordia Technologies), and Scott Pickett (Vertical Networks), whose expertise in telecommunications and IP networking shaped the initial drafts.[2] The first public specification, MGCP version 1.0, appeared as RFC 2705 in October 1999, published by the Internet Engineering Task Force (IETF) as an informational document outlining the protocol's application programming interface and text-based messaging for VoIP gateway control.[2] This milestone facilitated early adoption in hybrid VoIP-PSTN environments. In January 2003, RFC 3435 obsoleted RFC 2705, incorporating errata corrections, clarifications on endpoint behavior, and refinements to wildcarding and event handling mechanisms.[1] Further evolution occurred in December 2003 with the release of RFC 3660, which standardized a core set of MGCP packages for generic, line, trunk, and other endpoint types, and RFC 3661, which specified return code usage along with practical examples to guide implementations. These updates enhanced interoperability without altering the protocol's fundamental design. Subsequent involvement by the IETF Megaco Working Group contributed to broader media gateway standardization efforts, though MGCP maintained its independent trajectory as a lightweight alternative.[2]Architecture
Core Components
The Media Gateway (MG) serves as the primary endpoint device in the MGCP architecture, responsible for converting media streams between traditional telephony networks, such as the Public Switched Telephone Network (PSTN) using time-division multiplexing (TDM), and packet-based IP networks, typically employing protocols like Real-time Transport Protocol (RTP) over User Datagram Protocol (UDP).[9] It handles media translation tasks, including encoding and decoding audio signals with codecs such as PCMU, and supports multiple concurrent sessions by managing various types of interfaces, from analog lines to digital trunks.[9] MGs operate under external control, executing instructions to establish, monitor, and terminate media connections without inherent call intelligence.[10] The Media Gateway Controller (MGC), also known as a Call Agent, functions as the central control entity that provides the signaling and call processing logic for one or more MGs.[11] It issues commands to MGs for session setup, ongoing monitoring of endpoint states, and teardown, while synchronizing with other network elements to manage call flows.[11] In this master-slave relationship, the MGC implements higher-level protocols like H.323 or Session Initiation Protocol (SIP) and acts as an intermediary for signaling conversion, ensuring coordinated operation across the network.[12] Endpoints represent the logical or physical terminations on an MG where media streams originate or terminate, functioning as sources or sinks of data.[13] These can include physical interfaces such as analog telephone lines, digital channels on trunks, or virtual resources like conference bridges and RTP streams.[13] Endpoints detect events (e.g., off-hook detection) and generate signals as directed, enabling the MG to report status changes and process media under MGC guidance.[13] They are uniquely named within the MG, such as "aaln/" for analog lines, to facilitate precise control.[14] MGCP supports redundancy through the ability of MGs to interact with multiple MGCs, allowing failover to maintain service continuity.[15] Each endpoint is associated with a primary MGC via the "NotifiedEntity" parameter, which can be provisioned statically or set dynamically during operations like restarts.[16] In case of failure, the MG elects a new primary controller using mechanisms such as responses in restart procedures, where a random timer (between 0 and a maximum wait delay, e.g., 600 seconds for residential gateways) prevents synchronized overloads, doubling up to a maximum during disconnections until reconnection.[15] Domain Name System (DNS) resolution further enables retrying transmissions to alternative MGC addresses.[15] In the context of PSTN-IP interworking, MGs perform the essential media processing by converting TDM-based signals to IP packets and vice versa, ensuring compatibility between circuit-switched and packet-switched domains.[12] Meanwhile, MGCs manage the associated signaling logic, translating protocols like SS7/ISDN User Part (ISUP) to IP-based equivalents such as SIP or H.323, with endpoints bridging the media terminations.[12] This division allows for scalable decomposition of gateway functions, where media handling is offloaded to distributed MGs and control is centralized in MGCs.[10] The MGC issues commands to MGs to orchestrate these processes, as detailed in subsequent sections on protocol interactions.[17]Interaction Model
The Media Gateway Control Protocol (MGCP) employs a master-slave paradigm in which the Media Gateway Controller (MGC), also known as the Call Agent, functions as the master, issuing commands to control the Media Gateway (MG), which operates as the slave.[18] In this model, the MGC holds centralized authority over session establishment and management, while the MG executes these directives without initiating connections or sessions independently; each endpoint within the MG is associated with only one MGC at any given time.[19] This hierarchical structure ensures efficient decomposition of multimedia gateway functions, separating call control from media processing.[10] Communication in MGCP follows a unidirectional command flow from the MGC to the MG for creating, modifying, or deleting connections, complemented by asynchronous reports from the MG to notify the MGC of detected events or state changes.[20] The MG does not proactively drive session logic but responds to MGC instructions and buffers events as directed, enabling the MGC to maintain oversight of endpoint states.[12] To support redundancy and fault tolerance, MGCP accommodates multiple MGCs, with the MG configurable to switch between them via domain name identifiers or the "notified entity" parameter.[21] During transitions, the MG enters a quarantine mode to buffer pending events, isolating them until synchronization with the new MGC is achieved, followed by handover procedures that redirect control without disrupting ongoing sessions.[15] The protocol's transaction-based model ensures reliability despite operating over the unreliable User Datagram Protocol (UDP), using unique transaction identifiers (integers from 1 to 999,999,999) to track and correlate requests and responses.[12] This approach incorporates a three-way handshake mechanism and retransmissions with exponential backoff timers (initial 200 ms, doubling up to 4 seconds) to handle packet loss, with transactions timing out after T-MAX (20 seconds).[22] For failure handling, MGCP includes the Restart in Progress (RSIP) procedure, which the MG uses to inform the MGC of reboots, service disruptions, or failover events, allowing graceful state recovery and preventing restart avalanches through randomized timers.[23] In cases of MGC failure, the MG detects lost associations via history timers (default T-HIST of 30 seconds) and initiates reconnection to an alternate controller.[15]Protocol Specification
Message Format
Media Gateway Control Protocol (MGCP) messages are text-based and case-insensitive, encoded in UTF-8, consisting of a mandatory command line followed by zero or more header lines, an optional session description (such as using SDP for media parameters), and terminated by a carriage return and line feed (CRLF) or line feed (LF).[24] Each message component is separated by lines, with the session description, if present, following an empty line after the headers.[24] The command line initiates every MGCP message and follows the format<verb> <transaction identifier> <endpoint identifier> MGCP <version>, where components are separated by whitespace.[25] The verb is a four-letter code specifying the action, the transaction identifier is a unique numeric value up to nine decimal digits (ranging from 1 to 999,999,999) assigned by the sender to correlate requests and responses, and the endpoint identifier is a case-insensitive, email-like address in the form local endpoint name@domain name that specifies the target media gateway endpoint.[26] The protocol version, such as "MGCP 1.0", is mandatory and indicates the specification compliance.[25]
Headers appear after the command line as optional key-value pairs in the format <code>: <value>, providing additional context like call identifiers or notified entities.[22] Common headers include the call identifier (C:) for associating connections within a call, the connection identifier (I:) for specific connections, and the notified entity (N:) specifying the call agent to receive asynchronous notifications in the form call agent name@[domain](/page/domain):[port](/page/port).[22] These headers are case-insensitive and separated by colons, with values that may include additional parameters.
MGCP messages are primarily transported over UDP, with default ports of 2427 for media gateways and 2727 for media gateway controllers, though TCP is also supported for reliability in certain scenarios.[27] The protocol lacks built-in reliability mechanisms over UDP, relying instead on transaction identifiers to enforce at-most-once delivery through retransmission timers that start at 500 milliseconds and double up to a maximum of 4 seconds, with a 30-second history for tracking.[27]
A representative example of a command line in an MGCP message is CRCX 1234 ds/[email protected] MGCP 1.0, which might be followed by headers such as C: 1 and M: sendrecv to indicate a call context and media mode.[28]
Error responses in MGCP use three-digit numeric codes prefixed with the transaction identifier to indicate command status, categorized into provisional responses (100-199, such as 100 Trying for ongoing processing) and final responses.[29] Success is denoted by codes 200-299 (e.g., 200 OK), transient failures by 400-499 (e.g., 400 Bad Request for syntax errors), and permanent failures by 500-599 (e.g., 500 Unknown endpoint or 527 Missing remote connection descriptor).[29] These codes may include optional explanatory text, ensuring precise feedback without altering the textual message structure.[29]
| Code Range | Category | Examples |
|---|---|---|
| 100-199 | Provisional | 100 Trying |
| 200-299 | Success | 200 OK |
| 400-499 | Transient Failure | 400 Bad Request, 401 Phone off-hook |
| 500-599 | Permanent Failure | 500 Unknown endpoint, 527 Missing RemoteConnectionDescriptor |
Commands and Responses
The Media Gateway Control Protocol (MGCP) employs a command-response model where the Media Gateway Controller (MGC) issues imperative commands to the Media Gateway (MG) to manage endpoints and connections, and the MG responds with status codes indicating success or failure.[12] There are nine core commands, each identified by a four-letter verb acronym, designed to handle connection lifecycle, endpoint auditing, and configuration in a decomposed VoIP architecture.[12] Commands are encoded in text-based messages following a structured format, with each command tied to a unique transaction identifier for reliable exchange over UDP.[30] The CreateConnection (CRCX) command establishes a new bidirectional or unidirectional connection on a specified endpoint, allocating media resources and specifying parameters such as connection mode (e.g., sendonly, recvonly, sendrecv, inactive, loopback, contsrc, netwloop), local connection options (e.g., codecs, packetization period), and remote session description for SDP negotiation.[31] Upon execution, the MG returns a connection identifier and a local connection descriptor containing details like IP address and port for media streams.[31] The ModifyConnection (MDCX) command alters an existing connection's parameters, such as updating the mode, codec preferences, or remote endpoint details, without tearing down the connection; it may return an updated local descriptor if session parameters change.[32] The DeleteConnection (DLCX) command terminates a connection, freeing associated resources on the MG, and optionally requests connection statistics like packet counts or jitter; it can be initiated by either the MGC or MG.[33] The NotificationRequest (RQNT) command arms an endpoint to detect and report specific events, providing a list of requested events, a request identifier for correlation, and optional digit maps or signals to generate; it also specifies quarantine handling to manage overlapping requests.[34] In response to detected events, the MG issues a Notify (NTFY) command to the MGC, including the endpoint identifier, request identifier, and observed events list for asynchronous reporting.[35] Auditing capabilities are provided by AuditEndpoint (AUEP), which queries the overall state of an endpoint, including active connections, supported capabilities, and service state, and AuditConnection (AUCX), which retrieves details for a specific connection, such as mode, call ID, and parameters.[36][37] Configuration and maintenance commands include EndpointConfiguration (EPCF), which sets endpoint properties like audio encoding (e.g., mu-law or A-law) and bearer information for signal handling, and RestartInProgress (RSIP), which the MG sends to indicate endpoint restarts or service state changes (e.g., forced, restart, or disconnected), optionally specifying delay and reason.[38][39] From the MG's perspective, commands are stateless, meaning the MG executes them without retaining call or transaction state beyond immediate processing, while the MGC maintains the full state of all connections and endpoints to ensure synchronization.[18][27] Responses to commands follow a standardized format with a three-digit return code and optional reason phrase, sent back to the command's source address.[29] Success codes include 200 for general success and 250 for acknowledged deletion with parameters; provisional responses like 100 indicate partial processing, while errors range from 400-series transient failures (e.g., 401 for endpoint locked) to 500-series permanent errors (e.g., 501 for endpoint unknown or 510 for unsupported package).[40] Transaction handling uses unique 32-bit identifiers (1 to 999,999,999) per command, with separate namespaces for MGC-to-MG and MG-to-MGC directions; reliability over UDP is achieved via a three-way handshake involving provisional responses and acknowledgments, with retransmissions timed at 500 ms initially and doubling up to 4 seconds, ensuring at-most-once delivery.[41][42]Events and Signals
In the Media Gateway Control Protocol (MGCP), events represent conditions or occurrences detected by media gateways at endpoints, such as a telephone going off-hook or the detection of dialed digits.[1] These events are requested by the media gateway controller through the Notification Request (RQNT) command, allowing the controller to specify which conditions should trigger reporting from the gateway.[1] For instance, off-hook detection (hd) in the line package signals the start of a call, while digit dialing events in the DTMF package capture user input like numbers or symbols.[1] Events are defined within standardized packages, such as the basic call package for line supervision, ensuring modular and extensible handling across different endpoint types.[1] Signals, in contrast, are actions initiated by the media gateway to generate media outputs at endpoints, including tones, announcements, or other auditory prompts.[1] These are also specified in the RQNT command, often with optional duration parameters to control playback length, such as applying a ringback tone until an event occurs or a timeout elapses.[1] Examples include the dial tone to prompt user input or a busy tone to indicate call failure, which are applied in parallel without interfering with ongoing event detection unless explicitly configured otherwise.[1] Like events, signals are organized into packages, promoting consistency in telephony signaling across gateways.[1] To prevent conflicts during signal playback, MGCP employs a quarantine mode that buffers events detected at endpoints.[1] In this mode, events occurring before or during an RQNT processing are held in a first-in, first-out queue, avoiding premature notifications that could disrupt active signals like tone generation.[1] The controller can instruct the gateway to process or discard these buffered events upon RQNT acknowledgment, with overflow in the buffer triggering a specific quarantine buffer overflow (qbo) event if the queue capacity is exceeded.[1] This mechanism ensures reliable event handling in dynamic call scenarios, such as when a user dials during an announcement.[1] The notification model in MGCP restricts media gateways to sending Notify (NTFY) messages only for events explicitly requested in an RQNT, enabling precise control over reporting.[1] Notifications include the sequence of detected events in the order they occurred, supporting accumulation for patterns like digit maps.[1] Wildcards facilitate scalability, allowing requests for all events in a package (using "*") or across endpoint groups, which is useful for managing multiple lines or connections atomically.[1] This model, detailed further in the commands and responses section, underpins MGCP's master-slave architecture by minimizing unnecessary traffic.[1]Extensions and Packages
Defined Packages
In the Media Gateway Control Protocol (MGCP), packages serve as modular extensions that define sets of related events, signals, and parameters, enabling gateways to report conditions or apply stimuli in a standardized manner across diverse endpoint types.[1] These packages promote interoperability by allowing call agents to reference specific capabilities without embedding full definitions in every command, with each package identified by a unique alphabetic abbreviation (e.g., "G" for the Generic package) and version number.[43] By grouping functionality thematically, packages support extensibility while maintaining a core protocol structure, as outlined in the MGCP specification.[44] The Base package (B), version 0, provides foundational events for operation handling and buffer management, including "oc" for operation complete and "of" for operation failure, which are essential for protocol operations.[44] Similarly, the DTMF package (D), version 1, handles digit collection through events like "D/0" to "D/9" for individual tones and signals for generation, often used in interactive voice response scenarios.[45] The RTP package (R), version 1, addresses media stream handling with events such as "rto" for RTP/RTCP timeouts and "pl" for packet loss thresholds, facilitating quality monitoring in real-time communications.[46] The Announcement package (A), version 1, supports variable playback of audio files or tones, with signals like "ann(url)" to initiate announcements from specified sources, commonly applied in gateways with integrated media servers.[47] Packages are invoked in commands via notation combining the package abbreviation, signal/event type, and parameters (e.g., "ce/D/0" to notify the end of digit "0" detection in a Request or Notify message).[24] The IANA maintains a registry of over 40 defined MGCP packages, with core ones standardized in RFC 3435 and RFC 3660 to ensure vendor interoperability; additional packages extend functionality for specialized use cases like fax or ATM.[48] Examples include the Line package (L), version 1, which defines supervision events like "hd" and "hu" for line-side endpoints with added signals such as "rg" for ringing.[49]| Package Abbreviation | Name | Key Events/Signals | Primary Use |
|---|---|---|---|
| B | Base | oc (operation complete), of (operation failure) | Generic operations |
| D | DTMF | D/0-D/9 (digit detection), brief tone signals | Digit collection and generation |
| G | Generic | oc (operation complete), of (operation failure), rt (ringback) | Common media and error handling |
| L | Line | hd, hu, rg (ringing), bz (busy tone) | Line-side telephony states |
| R | RTP | rto (timeout), pl (packet loss), ma (media start) | Stream quality and RTP events |
| A | Announcement | ann(url) (play audio) | Media playback control |