MEGACO Vs. MGCP

• Resource Control
• Media Processing Control
• Evolution of Gateway Control
• What Protocols MEGACO derives form MGCP
• MEGACO version 0.5 vs MGCP version 1.0
• Conclusion : Why MEGACO
• Acknowledgement
• References

ESTI (TIPHON) has proposed a distributed architecture for the Gateway implementation that is based on three components - Media Gateway, Media Gateway Controller and the Signalling Gateway. All standardization bodies have accepted this architecture and both ITU-T and IETF have been working on the interface definition between the three Gateway components. 

ITU-T SG16 and IETF WG MEGACO have been looking at the interface between the Media Gateway (MG) and the Media Gateway Controller (MGC) to support the MG-MGC communication. IETF initially defined the interface in the MGCP specification and then proposed a new interface definition in the MEGACO specification. ITU-T has in parallel published its own specification as H.248 protocol (also referred as H/GCP).

This paper first delves on the need and evolution of Gateway Control Protocols and then captures the differences in MEGACO version 0.5 and MGCP protocol version 1.0 (RFC 2705). Further, it discusses the status of each of these protocols and their acceptance in the market today. Note that the differences with ITU-T SG16 are not presented, as MEGACO and H.248 are the same.

Need for a Gateway Control Protocol

The decomposed Gateway architecture depicted above distributes the Call control functionality and the Media processing functionality over different network elements viz. the Media Gateway Controller and the Media Gateway respectively. Consequently, there arises the need of a control protocol between these entities that permits the Call Control to set up media connections and media properties based on the call requirements. To form a suitable basis for the comparison of the MGCP and MEGACO protocols in later sections, this section summarizes the functional requirements of the Gateway Control protocol.

The Gateway Control Protocol permits the MGC to allocate and deallocate bearer terminations and media resources for use by a particular call.

• The protocol provides the flexibility that allows the resources required for a call to be specified by the MGC or selected and informed to the MGC by the MG from a resource pool. 
• The control protocol permits the MGC to get the status of resources in the MG.
• Connection Management
• The Gateway Control protocol permits the MGC to create connections involving packet and circuit bearer terminations in any combinations. The bearer terminations may be TDM, analogue, Ethernet, ATM or Frame Relay.
• The protocol supports establishment of unidirectional, symmetric bi-directional, asymmetric bi-directional, pt-to-pt as well as pt-to-multipoint flows of different media types such as audio, text, video etc.
• The protocol permits the MGC addition of subtraction of one or more media streams to a connection as required during a call.

The Gateway Control protocol permits the MGC to specify the media transformation parameters for each media stream that is part of a call. This includes transformation such as adaptation of flows between different types of transport, mediation of flows between different stream contents etc.

• The protocol permits the MGC to specify specialized media processing such as echo cancellation, tone detection, silence suppression, u-law/A-law companding etc to be done on media streams.
• The protocol permits the MGC to specify any media insertion such as playing announcements etc or media extraction operations such as DTMF detection and extraction, modem termination, fax termination etc to be executed on a media stream.

• The Gateway Control protocol permits the MGC to specify the events to be monitored or the signals to be applied by the Media Gateway on a particular media stream of a call.
• The protocol provides a mechanism by which the events detected by the Media Gateway are reported to the MGC.
• The protocol permits the MGC to specify the actions (e.g. report event to MGC, apply another signal, accumulate event till requested etc) to be taken by the MG when an event occurs. Similarly, it permits the MGC to specify when a signal applied to a stream needs to be removed (e.g. after timeout, on occurrence of an event, on request to apply another signal etc). 
• The protocol permits the MGC to specify the collection of dialed digits as a per a dial plan.

• The Gateway Control protocol provides a mechanism by which the Media Gateway can report statistics such as volume of content carried, QOS statistics, duration for which the media stream was active etc collected during a call.
• The protocol supports a mechanism by which the MGC can request these statistics anytime during the call.
  

• The Gateway Control protocol supports the establishment of a control relationship between the MGC and MG.
• It permits a single MGC to have associations to multiple MGs and vice versa i.e. it is possible for multiple MGCs to control terminations on a single MG.
• These terms encapsulate design, planning, installation, provisioning, maintenance, performance, security, accounting and customer query and control of telecom management

• The Gateway Control protocol provides a reliable transport mechanism for exchange of messages between the MG and the MGC. The transport mechanism permits detection of transport failure and supports a large number of control associations.
• The Transport mechanism provides a mechanism for one entity to correlate commands and responses from the other entity as well as to detect and reject duplicate commands and responses.

The Gateway Control protocol allows secure communication between the MG and the MGC. It allows for mutual authentication between the MG and the MGC, confidentiality protection of control messages exchanged between the two entities and mitigates denial of service attacks. 

The Gateway Control protocol permits the MGC to provide specialized services such as NAS services, Real-time fax services, conferencing services and IVR services by using the signal processing resources available at the MG.

The IPDC (IP Device Control Protocol) and the SGCP (Simple Gateway Control Protocol) protocol specifications were the first competing candidates for the Gateway Control Protocol described in the section above. MGCP, MEGACO and H.248 (earlier referred as H.GCP) are successors to these protocols. All define the interface between the Media Gateway (MG) and the Media Gateway Controller (MGC) identified in the distributed Gateway Architecture proposed by ETSI-TIPHON. The evolution of these competing standards captures the trend in the industry today.

• The MGCP protocol came into existence as a consequence of the fusion of SGCP and IPDC protocols and was derived out of the version 1.1 of the SGCP protocol document.
• The IETF MEGACO Working Group (approved by IESG in January '99), responsible for the standardization of the control interface between the Media Gateway and Media Gateway Controller adopted MGCP version 0.1 as the first solution. 
• The MEGACO group worked on the evolution of the MGCP protocol till the revision 3 of this protocol, which was released on 1st Feb 1999, but abandoned the effort due to some shortcomings of the protocol and more acceptance of another competing protocol (MDCP) by ITU-T.
• Meanwhile, MGCP evolution continued and it was finally converted into Informational RFC 2705 in October '99 after the fifth revision of its draft.
• IETF MEGACO WG then started working on a compromise protocol between MGCP and MDCP, which was later named as MEGACO protocol. The first draft of MEGACO appeared in March '99Parallel to MEGACO and MGCP efforts by IETF, ITU-T was evaluating multiple options and in April 1999 ITU-T SG16 adopted MEGACO version 0.1 as the starting specification for ITU-T protocol, and named it initially as H.GCP and later as H.248 (H-series Gateway Control Protocol). 
• ITU-T SG16 introduced multimedia context into the protocol in May/June and IETF MEGACO WG started the debate to accept it or not.
• MEGACO WG finally decided to enhance the protocol for support of Multimedia. An agreement was reached in June 99 between IETF MEGACO and ITU-T to come out with a single protocol document. As a consequence all subsequent revisions of the protocol document were the same for IETF MEGACO and ITU-T.
• The IETF meetings in Oslo and Washington, the ITU-T meeting in Berlin and hectic activity on the MEGACO mailing list resolved many issues pertaining to the protocol. It is now in good shape and the current version v11 (which is the same as Internet Draft version 05) is being presented at the ITU-T Red Bank meeting for (October 18 - October 22) final ratification. The output of the Red Bank meeting will be the "white document" for H.248, which will be, circulated to all ITU-T member countries for final approval. The results of the balloting will go to the ITU-T meeting in February '2000 for freezing as a standard. The IETF will simultaneously release a RFC.

Since MGCP has been the immediate predecessor of MEGACO, many concepts proposed in MGCP have found there way into the MEGACO specification. This section tries to list down the concepts found in both MEGACO and MGCP.

• Although the modeling of the Media Gateway differs in MEGACO when compared to MGCP, there is a similarity between the semantics of the commands in the two specifications. There is almost a one to one mapping between the commands of MEGACO and MGCP. For example the Create connection command in MGCP has an equivalent ADD termination command in MEGACO, the Modify connection command in MGCP equates to the MODIFY termination command of MEGACO and the Delete connection command equates to the SUBTRACT termination command of MEGACO.
• The concept of underspecified, unspecified and fully specified termination ids is derived from MGCP where the same concept is used to permit the flexibility of either the MG or MGC choosing resources for a call.
• The use of ABNF grammar for syntax specification and the Session Description Protocol (SDP) to specify media stream properties is the same as in MGCP.
• The Audit commands (Audit Value and Audit Capabilities) and Notify command in MEGACO are derived from similar commands in MGCP.
• The Service Change command in MEGACO has its genesis in the RestartInProgress command specified in MGCP.
• The processing of signals and events in media streams is the same in MEGACO as in MGCP. The use of the event descriptor, the signal descriptor and the embedded (signal or event) descriptor is the same as in MGCP. 
• The concept of digit map download to indicate to the MG the dial plan while collecting digits is a scheme that has been adopted from MGCP.
• The concept of packages containing event and signal definitions that permits easy extension to the protocol is borrowed from MGCP. 
• The MEGACO specification for transport of messages over UDP is the same as specified in MGCP. The three-way-handshake, computation of retransmission timers and mechanism to fight the restart avalanche described in MGCP find their way into the ALF definition specified in Annex E of MEGACO.
• The concept of a provisional response to a command that is likely to take a long time to execute was carried over from MGCP to MEGACO. 

This section attempts to capture the differences between the latest versions of the MGCP and MEGACO based on some key attributes such as the basic protocol model, protocol definition, performance, extensibility and application support. 

Both the protocols assume some connection model within the Media Gateway and provide interface functions for the control of connections within the Media Gateway. The protocol models are vastly different and an automatic migration path from MGCP to MEGACO is not possible.

1. The MEGACO protocol has been defined keeping in view a Media Gateway connection model that has the following two entities:

• Terminations - These source or sink one or more media streams. Terminations may be physical or ephemeral depending on whether they have permanent (e.g. DS0s) or temporary (i.e. only for the duration of a call) existence.
• Contexts - These are star connections created by associating multiple terminations. A NULL context contains all non-associated terminations.
  

A typical two-party call in MEGACO contains two terminations, one physical termination represented by a PSTN trunk (DS0 termination) and the other an ephemeral termination represented by a RTP Stream Termination connected together in a single context identified by a context id. Both terminations are explicitly added to the context by use of MEGACO commands. Thus, a Context is essentially a grouping of terminations connected for a call. All accounting and resource usage logging is done for a context.

MGCP has been defined keeping in view a Media Gateway connection model that has the following two entities:

• Endpoints - Endpoints are sources or sinks of data and could be physical or virtual. A Media Gateway is assumed to be a collection of endpoints of various types such as DS0s, Analog line, Announcement server access point etc.
• Connections - A connection is an association between two endpoints, which may reside in the same or different Media Gateways, with the purpose of transmitting data between these endpoints. Connections may be either point-to-point or point-to-multipoint.

Thus, a two-party call in MGCP is established by creating a connection to a DS0 endpoint lying within the Media Gateway using the Create Connection command. A call-id assigned by the MGC is associated to connections for accounting and logging purposes.

The MEGACO model considerably simplifies connection setup within the MG and to entities outside the MG. It simplifies the mechanism by which the MGC can specify associated media streams as well as specify the direction of media flow. MEGACO is therefore able to provide greater application level support than MGCP. For example, setting up a multi-party conference using MEGACO merely involves adding several terminations to a context. In case of MGCP however, the MGC needs to establish several connections to a special type of endpoint called the conference bridge.

2. The MEGACO model introduces the concept of an Ephemeral termination to accommodate RTP streams whereas in case of the MGCP model the RTP stream is implicit in the connection and gets automatically created. 

The concept of Ephemeral terminations brings about uniformity in representation in the sense that the RTP stream can be operated upon in a manner similar to any other termination in the MG. Thus, adding a Packet Data Network (PDN) subscriber in a conference is not different than adding a Switched Circuit Network (SCN) subscriber to a conference. The MEGACO model also has the advantage that internal connections (within the MG) are no different than external connections (to another Media Gateway or Terminal). In MGCP, external connections are really half connections running from an endpoint out towards a network. Thus two connections will need to be established for a full-duplex communication. Internal connections may be half-duplex or full duplex. 

3. The MEGACO model introduces the concept of a Multiplex Termination and Streams within a termination where a single termination may have multiple media streams that may be transmitted or received on different bearer channels. This enables the support of H.320 multimedia terminals.

The protocol definition for MEGACO and MGCP is driven by the differences in the protocol models. Some of the key differences are summarized below.

1. MEGACO supports an augmented command set with new commands such as Audit Capabilities that permits the MGC to Audit the capabilities of a Media Gateway thereby increasing the flexibility of the protocol.
   
   
2. In MGCP most of the commands after the connection establishment apply to endpoints directly without referring to connection id, whereas in MEGACO most of the commands applies to terminations within contexts. 
   - Mode in MGCP applies to connection, whereas Mode in MEGACO applies to terminations
   - There are many more other finer differences, which are not listed here like the MGCP audit command applies to endpoint, connections whereas MEGCOP audit command applies to terminations only.
   
   
3. Delete connection in MGCP deletes the media stream automatically. MEGACO uses Subtract that deletes a termination only, and the last subtract deletes context.
   MGCP returns statistics with the delete connection command, whereas MEGACO returns statistics with subtract termination command.
   
   
4. The Audit Capabilities command permits the MGC to audit the capabilities of the Media Gateway. For example, by the use of the Audit Capabilities command the MGC can determine the packages supported by a particular MG. The availability of this command introduces a flexibility that permits design of Media Gateways with varying complexity. MGCs can interoperate with all types of Media Gateways by first determining their capabilities and then interfacing accordingly. This command is not supported in MGCP. 
   
   
5. Parameters are syntactically different in the two protocols. MEGACO has many more parameter descriptors compared to MGCP that permit wider application support.
   
   
6. MEGACO introduces the concept of transactions using which multiple commands and their responses can be clubbed together. Transactions enforce execution sequence. Multiple transactions can go in a single MEGACO message.
   
   MGCP does not allow commands to be clubbed together into a single transaction and supports only one command to be communicated in a single message. Each command contains header, parameters and session descriptor.
   
   Bundling of commands into transactions in a single command is an important feature that is likely to reduce the load of MG-MGC communication as well as reduce call setup times.
   
   Media Stream properties 
   
   
7. All the modifications to the media stream properties are specified as part of connection parameters in MGCP, whereas MEGCO uses termination descriptor to specify the properties.
   
   
8. MEGACO specifies that the media processing attributes of terminations be restored to their default values when a termination goes back to NULL context in MEGACO. As per MGCP specification, deleting all connections to an endpoint restores media processing attributes to their default values.
   
   Signals, Events and Digit Maps
   
   
9.  MEGACO activates event notifications and signals by passing the Event Descriptor, Signals Descriptor and Digit Map Descriptor in an Add, Modify or Subtract command. MGCP activates event notifications and signals by means of an explicit Notification Request or a Notification Request embedded in a Create Connection, Modify Connection or Delete Connection.
   
   MGCP explains handling of Quarantine events while MEGACO does not treat Quarantine events.
   
   
10. MEGACO permits referencing of preloaded digit maps in the Event descriptor. Also, a digit map has a scope that defines the termination or set of terminations to which the Digit map applies. Such a feature does not exist in MGCP. This feature reduces the size of messages that need to be exchanged between the MG and the MGC as the complete digit map need not be downloaded every time a call with a new dial plan needs to be terminated.
    
    Packages and Termination Types 
    
    
11. MEGACO provides a simpler set of endpoint types and supports termination properties and packages to support a wider set.
    
    MGCP defines each endpoint type as a separate entity, with additional types such as Announcement server endpoint, IVR access endpoint, Conference bridge endpoint, Packet relay endpoint, and Wiretap endpoint.
    
    
12. Packages supported by MGC are bundled into the main protocol document whereas in MEGACO they will be defined in separate RFCs and/or Annexes. The concept of packages is the key to the extensibility of both MEGACO and MGCP. The separation of packages from the main MEGACO protocol document permits easy extension of the protocol. New versions of the protocol are not required for every new package that is added which is what will need to be done for MGCP. 
    
    MG-MGC Control Association
    
    
13. MG-MGC control association is established using the Service Change message in MEGACO. In MGCP this is established through the "security" layer and hence results in a security association.
    
    
14. In MEGACO, when MGC fails, handover is initiated by the MGC issuing a Service Change command to the MG indicating the new MGC Id to communicate with. In case of MGCP, association between MGC & MG is defined at Security level. Any MGC can take over if it has the proper security credentials. 
    
    MG reboot in MEGACO is communicated by means of Service Change command while MGCP uses Restart In Progress for that purpose. 
    
    Security 
    
    
15. Both MEGACO and MGCP address security. However, MGCP only talks of IPSEC as the underlying security mechanism. MEGACO on the other hand provides an additional option of including an authentication header that provides security when IPSEC is not available.

• The concept of contexts is a powerful tool to represent conferences. As context definition is not dependent on the order in which terminations are added or subtracted, the context provides a framework where no special operations are required when a participant in a conference drops out. The terminations can be subtracted without affecting the connectivity of the terminations remaining in the conference. 
• Conferences using MGCP are achieved by terminating several connections on a conference endpoint.
• MEGACO is multimedia ready. It has defined way to set mixing parameters for audio, video. This is achieved by the support of multiple media streams per termination and the ability to synchronize streams by setting context properties.
• MGCP does not have the capability to set mixing parameters. Hence, it is does not provide any explicit support for multimedia.
• MEGACO supports the MOVE command that allows the MGC to move terminations from one context to another using one command. This eases implementation of supplementary services like Call Waiting, call hold etc in which the media stream from the same subscriber needs to be connected to media streams in two different contexts alternately.
• MEGACO supports a Mux Termination construct that facilitates interworking with H.320 multimedia terminals. MGCP does not provide this construct.
• MEGACO provides a high degree of control on the media streams contained in a context. It allows transmit and receive of each termination to be individually controlled as well as the connections between individual streams can be controlled. This permits easy implementation of new services such as muting of one of the participants, wire tapping, speech to text conversion etc.
• Adding new packages to MEGACO protocol is easy because package definitions are not part of the main protocol text. Adding new packages is an independent procedure that merely requires registration of the new package with IANA. Building new applications by introducing new packages is therefore easier than for MGCP that requires a new protocol revision to introduce a new package.
• MEGACO has a more general call model than MGCP. Thus it is more efficient for TDM to TDM calls, TDM to ATM calls as well as for TDM to IP calls.

*Expected to be accepted as an RFC.

**Since mid-June 1999, MEGACO WG and ITU-T SG16 have agreed to publish a single document.

It is evident from the above comparison that MEGACO covers a broader set of requirements, is easily extensible, provides greater application level support and can provide a better performance in comparison to MGCP. MEGACO includes almost all the good features of MGCP (e.g. Transport, Packages, events, signals etc) and adds new features that permit fabrication of Gateways with more capabilities. It is therefore emerging as the final solution for the MG-MGC interface. 

• MEGACO introduces several new concepts (such as contexts, ephemeral terminations, transactions etc.) that provide a powerful mechanism for supplementary services (like call waiting), multi-party conferencing and multimedia support. 
  Conclusion: MEGACO is feature-rich and provides a better option to manufacturers to build value-added products with differentiated features.
• IETF (MEGACO WG) and ITU-T (SG16) have joined hands and agreed to publish a combined document now onwards. This is a significant development and should lead to the definition of a common protocol for the convergent networks that is acceptable to both the telecom standardisation bodies (ITU-T and ETSI) and datacom standardization organizations (IETF). 
• MEGACO (which will evolve into H.248) has a higher chance of being accepted in the market.
  Conclusion: The effort is being driven by major datacom and telecom vendors and it is in the interest of both parties to ensure interoperability in the converged networks. This will help to overcome the vastly dissimilar backgrounds of the standardisation bodies. 
• MGCP is only an informational RFC. Hence, there will not be any further support from IETF for MGCP.
  Conclusion: The evolution of MGCP has virtually stopped and any enhancements of services carried by vendors are likely to be proprietary in nature. 
• CableLabs has also adopted and modified MGCP protocol for telephony support on cable systems, they are going to support the protocol for their implementation or definition.
• Most of these MGCP vendors have committed to moving to MEGACO in future.
  Conclusion: Even though MEGACO is still evolving there are no commercial implementations and vendors today have joined to form industry forums (SoftSwitch) and support initial implementations based on MGCP, most of the large vendors are fully supporting MEGACO and have roadmaps to deliver MEGACO in the year 2000.
• MEGACO is powerful and lends itself to meeting all the requirements of existing telecom applications while creating new opportunities for futuristic multi-media based services.

The authors wish to acknowledge the contribution of Nancy Greene of Nortel Networks in the making of this white paper. Nancy's mail in the MEGACO mailing list, citing differences between the MGCP and MEGACO protocols, provided significant inputs for this paper.

[1] M. Arango, A.Dugan, I. Elliot, C.Huitema, S.Pickett, "Media Gateway Control Protocol (MGCP)", RFC 2705
[2] B. Hill, N.Greene, C.Huitema, A.Rayhan, B.Rosen, J.Segers, "draft-ietf-megaco-protocol-05.txt", "Work-in-progress"
[3] N.Greene, M.A.Ramalho, B.Rosen, "draft-ietf-megaco-reqs-08.txt"

Last updated : February 2, 2004