What is MGCP?
The media gateway controller protocol (MGCP) is specified in draft-huitema-MGCP-v0r1-00.txt and was released in November 1998 just prior to the IETF meeting in Orlando where it was debated in the MEGACO working group.
MGCP is designed to interface a media gateway controller and media gateway. The protocol is text based3 and supports a centralized call model. The media gateway controller is called call agent in MGCP terminology and the media gateways can be either different types of VoIP gateways (residential, trunking, corporate, etc.), network access servers or even voice over ATM gateways. The protocol is being built to serve gateways from 1 (a multimedia terminal adapter to connect an analogue phone to IP) to 100 000+ ports (class 4 or 5 switches). In the MGCP connection model the ‘atoms’ are endpoints (just like in H.323 and SIP) and connections (this is not the case in H.323 and SIP) that are ‘virtually’ connected (just like within a switch).
Only signaling and media planes are covered by the current MGCP draft. Both management and services planes have not been specified yet.
The protocol is based on SGCP version 1.1 (sgcp.bellcore.com) with CableLabs extensions and IPDC version 1.0. From the last protocol MGCP imports mainly the notion of event packages, a few new operations and some name changes. The end of the MGCP document describes in detail the changes made from SGCP v.1.1 and IPDC and incorporated in MGCP.
MGCP is a master/slave protocol. It uses other protocols to fulfill its requirements, such as the session description protocol which is used to describe the media aspects of the phone call. In its principle, MGCP is very close to the proprietary protocols of switch manufacturers that convey information back and forth between call control points (this terminology is not a ‘standard’ one used in intelligent network documents. IN does not define a standard interface between CCF and SSF) and service switching points.
This principle (in the context of MGCP) clearly places the intelligence on a physically separate element – the media gateway controller and not on the hardware endpoint, the media converter. But unlike the switch architecture as specified in IN documents where the call control remains close to the actual hardware endpoints, in the MGCP architecture the call control functionality is no longer attached to the media part.
Initially the protocol was designed to support only constant capabilities (for example, same codecs). But market needs and an ever-increasing number of requirements pushed the authors to consider adding dynamic capabilities, such as codec negotiation, a feature built in H.323. H.323 endpoints can negotiate their capabilities through H.245 messages and can even change one or more of their capabilities while the conversation is taking place. The origins of MGCP, known and published as SGCP, tried to avoid such dynamic features in order to keep SGCP as ‘simple’ as possible and be a competitive alternative to H.323. The addition of such functionalities and the expected addition of multimedia features will undoubtedly increase the complexity of MGCP.
In MGCP the session description protocol (see Chapter 2) is used to describe formally various parameters to enable establishment of connections between endpoints. MGCP does not use the multimedia features of SDP, such as the description of multiparty multimedia conferences. MGCP is not designed to support multimedia calls like H.323 or SIP does. It is nevertheless expected that this functionality will be added very soon (see requirements section). One of the other nice features of SDP is its flexibility and extensibility. New information elements can be added easily and registered to IANA. For a while, the use of Extensible Markup Language (XML) was considered as an alternative to describe telephony sessions (or multimedia) but due to lack of consensus at IETF the idea was abandoned. Also, as Christian Huitema, one of the head engineers of Bellcore, now Telcordia, describes: ‘One advantage of a layered specification (such as using SDP in MGCP) is that it provides a clean partition between call signaling (as in MGCP) and media signaling (as in SDP).’
In its first release MGCP is composed of eight commands exchanged between the media gateway controller or call agent and the media gateway or simply gateway with the following features:
Notification Request |
From call agent to gateway |
Notification |
From gateway to call agent |
Create Connection |
From call agent to gateway |
Modify Connection |
From call agent to gateway |
Delete Connection |
From call agent to gateway |
Audit Endpoint |
From call agent to gateway |
Audit Connection |
From call agent to gateway |
Restart In Progress |
From gateway to call agent |
Readers may find all the details concerning MGCP in the draft (see above) and on the archive of the following mailing lists: sgcp@bellcore.com and megaco@baynetworks.com.
MGCP commands
Notification Request
This command requests the media gateway to watch for specific telephony events. These could be telephony signals, such as off-hook, on-hook, fax tones, modem tones, wink, flash hook, continue tone and detection, DTMF and pulse digits. One of the nice features of this command is the association of actions with each of the events. Using this facility, the communication and processing of information between the two entities can be optimized. For example, when the call agent requests the media gateway to watch for digits, it can request the media gateway to buffer the digits. By using this functionality the en bloc sending can be achieved easily.
One feature that is missing in this command is the ability for a media gateway controller to give other backup media gateway controllers’ addresses. Should this functionality be included, MGCP could provide a built-in network reliability, just as H.323 version 2 does.
Notification Command
This command enables the media gateway to send back events that were requested by the media gateway controller. The media gateway can send one or several events in a notification command if it is asked to do so by the media gateway. Since the gateway is not supposed to have any ‘intelligence’, it sends the events in the order it detects them. It is up to the call agent to put events in the right order.
The collected information is sent by the media gateway to the call agent using the Notify command in the ObservedEvents field. From a protocol engineering point of view it would have been much more effective to use RTP (with compressed RTP headers) to send these events since RTP is designed to carry such information. Future releases of MGCP may adopt the use of RTP to send these messages back to the call agent.
Create Connection
This command is sent by the call agent to the media gateway to create a connection between two endpoints. In addition to the necessary parameters that enable a media gateway to create a connection, the LocalConnectionOptions parameter provides features for quality of service (echo cancellation, silence suppression), security, and network-related QOS fields (bandwidth, type of service, use of RSVP).
By sending a Notification Request command the call agent has the ability to request the gateway to execute simultaneous actions. In order to achieve this feature the call agent can use RequestedEvents, RequestIdentifier, DigitMap, SignalRequests, QuarantineHandling and DetectEvents parameters. The following example is given in MGCP:
-
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 RequestedEvent parameters for the off-hook event, and the SignalRequest parameter for the ringing signal.
This feature dramatically reduces the number of round trips necessary to establish a connection between two endpoints and improves the scalability of the call agent.
Modify Connection
This command enables a call agent to modify a connection that has already been set up by the gateway. The simultaneous feature mentioned below can also be used with the Modify Connection command. Modify connection can affect the following parameters of a connection: activation, deactivation, change codec, packetization period, etc.
Delete Connection
This command enables the call agent to terminate a call for a given connection. It should be noted that if there is more than one gateway involved, the call agent will send the Delete Connection command to each of the media gateways.
A nice functionality provided by MGCP (note that this is also provided by H.323) is that the media gateway, upon termination of a connection, has to send the call agent the following information:
-
number of packets (RTP) sent
-
number of octets (number of payloads) sent
-
number of packets (RTP) received
-
number of octets received
-
number of packets lost
-
interarrival jitter
-
average transmission delay.
These parameters are fully described in RFC 1889.
MGCP allows also a media gateway to clear a connection on its own, such as when there is loss of a connection. In this context the media gateway issues a Delete Connection command to the call agent and sends all the parameters concerning call statistics back to the call agent as if it were a normal Delete Connection situation.
It is also possible for a call agent to delete multiple connections at the same time, using advanced hierchical naming structures and/or a wildcarding option (the wild card character is *). This command does not return any individual statistics or call parameters, making it unsuited for multiparty or conference calls. We believe that in the near future the media gateway will be required to send back this information.
Audit Endpoint
In order to check whether an endpoint is up and running the call agent can use this command. This feature is inherited from the switch environment.
Audit Connection
This command enables the call agent to retrieve all the parameters attached to a connection.
Restart in Progress
This command allows a gateway to make a call agent aware of an endpoint or a group of endpoints that have problems. The command allows three options: graceful (no connection lost), forced (connection(s) lost) and restart (the media gateway will restart soon). Further to these messages the call agent can decide if it wants to test these endpoints/connections before trying to make another call.
Fig. 3.3 shows MGCP protocol and architecture in use.
Figure 3.3. MGCP protocol and architecture in use