Comparison Between MGCP and H.248

Copyright 2000 / All rights reserved. Reprinted from CompactPCI Systems / September-October 2000

In this article Vikas describes the distributed architecturefor media gateway implementation that has been endorsed byall of the relevant telecom and datacom standards organiza-tions. He then recounts the long and torturous process bywhich these organizations have attempted to standardizecommunication protocols for use between the components ofthis distributed architecture. Vikas then compares the featuresof the two leading protocols in use today (MEGACO andMGCP), discusses their current market acceptance, andpredicts future trends in the usage of these two protocols.

Figure 1 shows a distributed architecture for media gatewayimplementation that is based on three components:

a Media Gateway (which we will call a gateway) that mon-itors and controls media endpoints, media resources andmedia connections

a Media Gateway Controller (which we will call a gatewaycontroller), that interfaces to the Media Gateway to controlthe Media Gateways resources, and interfaces with theSignaling Gateway to obtain call processing information

a Signaling Gateway, which signals call termination, anddelivers signaling information to the Media GatewayController

All of the relevant telecom and datacom standards organiza-tions have now endorsed this architecture.

Because these three entities are separate network components,there is a need for standardized protocols that allow communi-cation between them. Both ITU-T (a telecom standards orga-nization) and IETF (a datacom standardization organization)have been working to define such protocols.

Protocols for use between the gateway controllerand the gatewayOf particular interest here is the protocol that allows the gate-way controller to establish connections with the requiredmedia properties for each specific call, based on call controlinformation that it receives from the Signaling Gateway. Thereare currently two competing protocols that have been proposedto allow this:

the Media Gateway Controller Protocol (MGCP) the MEGACO protocol

To provide a basis for comparing these two competing proto-cols, we will first list the functional requirements of a gatewaycontrol protocol.

Resource control requirementsThe protocol should:

permit the gateway controller to allocate and de-allocateterminations and media resources for each call.

allow the gateway controller to tell the gateway whichresources to allocate to a call, or the gateway to select the re-quired resources, and then inform the gateway controller thatthose resources have been allocated from the resource pool.

permit the gateway controller to find out the current statusof all of the resources managed by the gateway.

Connection managementThe protocol should:

permit the gateway controller to create connectionsbetween packet and circuit terminations in any combina-tion. These terminations might be TDM, analog, Ethernet,ATM, or Frame Relay.

support the establishment of unidirectional, symmetric bi-directional, asymmetric bi-directional, point-to-point, andpoint-to-multipoint flows of various media types,including audio, text, and video.

permit the gateway controller to add mediastreams to (or subtract media streams from) anexisting connection during the call.

Media processing controlThe protocol should:

permit the gateway controller to specify the mediatransformation parameters for each media streamthat is part of a call. This includes adaptation offlows between different types of transport, and medi-ation of flows between different stream contents.

By Vikas Bajaj

Media gateway controller

Signalinggateway

SIGTRANMGCPMEGACOH.248

Mediagateway

Gateway reference architecture

PacketInterface

SCN InterfaceFigure 1

Reprinted from CompactPCI Systems / September-October 2000 Copyright 2000 / All rights reserved.

permit the gateway controller to specify specialized mediaprocessing to be done on media streams, such as echo can-cellation, tone detection, silence suppression, and u-law/A-law companding.

permit the gateway controller to specify any media inser-tion operations (such as playing announcements) or mediaextraction operations (such as DTMF detection and extrac-tion, modem termination, or fax termination) to be executedon a media stream.

Signal and event processingThe protocol should:

permit the gateway controller to specify the events thatthe gateway is to monitor in a particular media stream of acall.

permit the gateway controller to specify the signals that thegateway is to apply to a particular media stream of a call.

permit the gateway to report events to the gateway con-troller.

permit the gateway controller to specify the actions that thegateway is to take when an event occurs, such as reportingevents to the gateway controller, applying another signal, oraccumulating events until requested.

permit the gateway controller to specify when the gatewayshould remove a signal from a stream, such as after a time-out, on occurrence of an event, or on request to applyanother signal.

permit the gateway controller to specify the collection ofdialed digits as a per-a-dial plan.

Statistical reportingThe protocol should:

permit the gateway to report statistics collected during acall, such as the volume of content carried, the quality ofservice statistics, and the duration for which the mediastream was active.

permit the gateway controller to request thesestatistics at any time during the call.

Association managementThe protocol should:

support a control relationship between the gatewaycontroller and gateway.

permit a single gateway controller to control mul-tiple gateways.

permit multiple gateway controllers to control ter-minations on a single shared gateway.

TransportThe protocol should:

provide a reliable transport mechanism for the exchange ofmessages between the gateway and the gateway controller.This transport mechanism should permit detection of trans-port failure and should support a large number of controlassociations.

provide a mechanism for the gateway controller to associ-ate commands sent to and responses received from the gate-way, and vice versa.

provide a mechanism for the gateway controller to detectand reject duplicate commands and responses from thegateway, and vice versa.

SecurityThe protocol should:

allow secure communication between the gateway and thegateway controller. In doing so, it should allow for mutualauthentication between the gateway and the gateway con-troller, ensure confidentiality of control messages exchangedbetween the two, and mitigate denial-of-service attacks.

Note: Denial-of-service attacks occur when an attacker floodsan Internet node (such as a WWW server) with harmless IPpackets. Due to the excessive traffic generated by the attacker,that node is unable to service valid service requests originatingfrom service seekers, such as people accessing a popular website. This is termed denial of service. A gateway control pro-tocol should include defensive mechanisms to protect against(mitigate) such attacks.

Application supportThe protocol should permit the gateway controller to use thesignal processing resources available in the gateway to providespecialized services, such as:

real-time fax services conferencing services network access server services, which provide connectivity

services to dial-up Internet users. (The dial-up user mightbe connecting to any Internet public domain server or a pri-vate domain server.)

interactive voice response services, which prompt the userfor various inputs using playback of a recorded voice andcollect the inputs in the form of digits. (One example ofsuch a service is the prepaid calling card service.)

Evolution of gateway control protocolsThe earliest competing candidates for the gateway controlprotocol described above were:

the IP Device Control Protocol (IPDC) the Simple Gateway Control Protocol (SGCP)

The successors to these protocols are:

MGCP MEGACO H.248, the early version of which was called H.GCP


All three of these latter protocols define the interface betweenthe gateway and the gateway controller. (See Figure 1)

The evolution of gateway control protocolsCommunication technology has been evolving at a very rapidpace so fast that it has been difficult for standards organiza-tions to keep up. A good illustration of this is the evolution ofgateway control protocols, which is illustrated in Figure 2, andis summarized below:

The SGCP and IPDC protocols were first used to producethe GCP protocol, which was actually derived from the ver-sion 1.1 of the SGCP protocol document.

The IETF (a datacom standardization organization) estab-lished the MEGACO working group in January of 1999,and gave this group responsibility for the standardization ofthe control interface between gateways and the gatewaycontrollers. The working group then developed MGCP ver-sion 0.1 as their first solution.

The MEGACO group continued to evolve the MGCP pro-tocol, eventually releasing revision 3 on February 1, 1999.

The MEGACO group continued to evolve the MGCP pro-tocol, eventually producing version 4. However, at this pointit was abandoned due to some shortcomings of the protocoland industry acceptance of another competing protocol(MDCP) which was being developed by another group the IETF, ITU-T (a telecom standards organization). TheMGCP protocol was then converted into InformationalRFC 2705 in October 99. (RFC stands for Request ForComments. An RFC is an IETF standards document. IETFdrafts become RFCs after the approval ballot.)

The MEGACO working group then started work-ing on a compromise protocol between MGCP andMDCP, which was later named the MEGACO pro-tocol. The first draft of the MEGACO protocolappeared in March of 1999.

In April 1999 ITU-T SG16 group adoptedMEGACO version 0.1 as the starting specificationfor their ITU-T protocol, which they calledH.GCP. (This name was later changed to H.248.)

The ITU-T SG16 group then added multimedia context intotheir H.GCP protocol in May/June 1999, and the IETFMEGACO working group started debating about whetheror not to accept this addition.

The MEGACO working group finally decided to enhancetheir own protocol to support multimedia, and an agreementwas reached in June 99 between IETF MEGACO and ITU-Tto come out with a single protocol document. As a conse-quence all subsequent revisions of the protocol documentwere the same for IETF MEGACO and ITU-T.

IETF meetings in Oslo and Washington, and an ITU-Tmeeting in Berlin (plus hectic activity on the MEGACOmailing list) have resolved many of the remaining issuespertaining to the protocol, and it is now in good shape. Thecurrent version (v11, which is the same as Internet Draftversion 04) was presented at the October 1999 ITU-T RedBank meeting. The resulting white document for H.248was then circulated to all ITU-T member countries for final

approval. The results of the balloting went to the ITU-Tmeeting in February of 2000, but revision to the standardcontinued. Therefore, this ratified version has not yetbecome a standard.

What does MEGACO derive from MGCP?Since MGCP was the predecessor of MEGACO, many con-cepts proposed in MGCP found their way into the MEGACOspecification. This section lists the concepts found in bothMEGACO and MGCP.

The semantics of the commandsAlthough the MEGACO model of the gateway differs from theMGCP model, there is a similarity between the semantics ofthe commands in the two specifications. In fact, there is almosta one-to-one mapping between the commands of MEGACOand MGCP. For example:

the Create Connection command in MGCP has an equiva-lent ADD Termination command in MEGACO

the Modify Connection command in MGCP equates to theMODIFY Termination command of MEGACO

the Delete Connection command in MGCP equates to theSUBTRACT Termination command of MEGACO

Termination IDsThe concept of underspecified, unspecified and fully specifiedtermination IDs is derived from MGCP, where the same con-cept permits either the gateway or the gateway controller tochoose resources for a call.

SGCPVer. 1.0

IPDC

Abandoned

IETF MEGACO working group

MGCPVer. 0.1

MGCPVer. 3

MGCPVer. 5

Feb 1999 Oct 1999

MDCP

MGCPRFC

Mar 1999

April 1999

IETF ITU-T

Oct 1999

Finalizedstandard

Feb 2000

GCPMEGACO

Ver 0.1/H.GCPH.248

whitedocument

IETF ITU-T

MEGACOVer 0.2

MEGACOVer 0.3

MEGACOVer 0.4

Figure 2


Use syntax specificationThe use of Augmented Backus-Naur Form (ABNF) for syntaxspecification and the Session Description Protocol (SDP) tospecify media stream properties is the same as in MGCP.(ABNF is a standard notation for specifying grammar, and isused to parse text.)

The audit commandsThe audit commands (Audit Value and Audit Capabilities) andthe Notify command in MEGACO are derived from similarcommands in MGCP.

The Service Change commandThe Service Change command in MEGACO has its genesis inthe Restart In Progress command specified in MGCP.

The processing of signals and eventsThe processing of signals and events in media streams is thesame in MEGACO as in MGCP. The use of the event descrip-tor, the signal descriptor, and the embedded (signal or event)descriptor is the same as in MGCP.

Digit map downloadingThe concept of digit map downloading to indicate to the gate-way the dial plan while collecting digits is a scheme that hasbeen adopted from MGCP.

Packages for events and signalsThe concept of packages containing event and signal defini-tions (which permits easy extension to the protocol) is bor-rowed from MGCP.

The transport of messagesThe MEGACO specification for transport of messages overUDP is the same as the MGCP specification. The three-way-handshake, computation of retransmission timers, and themechanism to fight the restart avalanche described in MGCPhave found their way into the Application Layer Framing(ALF) definition, which is specified in Annex E of MEGACO.(The ALF defines framing and procedures that ensure reliabledelivery of messages in the absence of an underlying reliabletransport protocol.)

Provisional responses to a commandsThe concept of a provisional response to a command that islikely to take a long time to execute was carried over fromMGCP to MEGACO.

MEGACO version 0.5 vs. MGCP version 1.0This section attempts to capture the differences between the

latest versions of the MGCP and MEGACO, based on somekey attributes such as:

the protocol model the protocol definition performance extensibility application support

The protocol modelBoth the protocols are based on a connection model within thegateway, and both define services for the control of connec-tions within the gateway. However, the protocol models arevastly different, and an automatic migration path from MGCPto MEGACO is not possible.

The MEGACO protocolThe MEGACO protocol is based on a gateway connectionmodel that has the following two entities:

Terminations, which source or sink media streams. Theseterminations may be physical or ephemeral, depending onwhether they are have permanent connections (for example,DS0s) or temporary connections (that is, only for the dura-tion of a call).

Contexts, which are star connections created by associat-ing multiple terminations. A NULL context contains allterminations that are not currently associated with anyother context.

A typical two-party call in MEGACO has two terminations: a physical termination, represented by a PSTN trunk (DS0

termination) an ephemeral termination, represented by an RTP stream

termination (RTP stands for Real-time Protocol. It is theprotocol described in RFC 1889 that standardizes themethod of transport of Real-time traffic over packet net-works.)

These two terminations are connected together (in a singlecontext) and identified by a context ID.

The two terminations are explicitly added to the context byuse of MEGACO commands. Thus, a context is essentiallya grouping of terminations that are connected for a call.All accounting and resource usage logging is done basedon contexts.

The MGCP protocolThe MGCP protocol is based on a gateway connec-tion model that has the following two entities:

Endpoints, which are sources or sinks of data, andmight be either physical or virtual. A gateway isassumed to be a collection of endpoints, whichmight be of different types, such as DS0s, analoglines, or announcement server access points.

Connections, which are associations between twoendpoints that might (or might) not reside in the


same gateway, with the purpose of transmitting databetween these endpoints. These connections might beeither point-to-point or point-to-multipoint.

Thus, MGCP establishes a two-party call by creating a con-nection to a DS0 endpoint lying within the gateway, using theCreate Connection command. A call-ID (assigned by the gate-way controller) is associated with each connection foraccounting and logging purposes.

MEGACO versus MGCPThe MEGACO model simplifies connection setup, both withinthe gateway and to entities outside the gateway. It simplifiesthe mechanism by which the gateway controller can specifyassociated media streams, as well as specify the direction ofmedia flow.

Because of this MEGACO can provide better support at theapplication level than MGCP. For example, setting up a multi-party conference using MEGACO merely involves adding sev-eral terminations to a context. However, in the case of MGCPthe gateway controller must establish several connections to aspecial type of endpoint, called a conference bridge.

Ephemeral terminationsThe MEGACO model introduces the concept of an ephemeraltermination to accommodate RTP streams. (An RTP stream isa logical stream of audio/video frames that are contained inReal Time Protocol packets.) In contrast, in the MGCP modelthe RTP stream is implicit in the connection, and gets createdautomatically.

The concept of ephemeral terminations brings about a unifor-mity in representation in the sense that the RTP stream can betreated like any other termination in the gateway. Thus, addinga packet data network subscriber to a conference is no differ-ent from adding a switched circuit network subscriber to a con-ference.

The MEGACO model also has the advantage that internal con-nections (within the gateway) are no different from externalconnections (to another gateway or terminal). In MGCP, exter-nal connections are really half connections, running from anendpoint out towards a network. Thus, two connections mustbe established for full-duplex communication. (Internal con-nections might be half-duplex or full duplex.)

Multiplex termination and streamsThe MEGACO model includes a concept of a Multiplex ter-mination and streams within a termination, where a single ter-mination might have multiple media streams that might betransmitted or received on different channels. This enables thesupport of H.320 multimedia terminals.

Differences in protocol definitionsThe differences between the protocol definitions forMEGACO and MGCP stem from the differences in their pro-tocol models. Some of the key differences are summarizedbelow.

CommandsMEGACO supports an augmented command set (see Table 1)with commands such as Audit Capabilities that permit thegateway controller to determine the capabilities of a gateway,thereby increasing the flexibility of the protocol.

Endpoints versus TerminationsIn MGCP most of the commands (after the connection estab-lishment) apply to endpoints directly, without referring toconnection ID, whereas in MEGACO most of the commandsapply to terminations within contexts. For example, Mode inMGCP applies to connection, whereas Mode in MEGACO

MEGACO Supports MGCP Supports

ADD termination (Equivalent to Create Connection) Create ConnectionSubtract termination (Equivalent to Delete Connection) Delete ConnectionModify termination (Equivalent to Modify, Notification Request & Modify ConnectionEndpoint Configuration) Notification RequestEndpoint Configuration

Service change (Equivalent to Restart In Progress but includes other functions as well) Restart In ProgressNotify Notify

AuditValue (Equivalent to AuditEndpoint and AuditConnection) AuditEndpointAuditConnection

Move Move

Audit Capabilities (New Command) Not supportedTable 1


applies to terminations. There are many other finer differ-ences that are not listed here, such as the fact that the MGCPaudit command applies to endpoint and connections, whereasMEGACO audit command applies to terminations only.

Deletion of media streamsThe Delete Connection command in MGCP deletes the mediastream automatically. MEGACO uses the Subtract Term-ination command, which deletes a termination only the lastsubtract command also deletes the context.

MGCP returns statistics with the Delete Connection com-mand, whereas MEGACO returns statistics with SubtractTermination command.

The Audit Capabilities commandMEGACOs Audit Capabilities command (which is not sup-ported in MGCP) permits the gateway controller to audit thecapabilities of the gateway. For example, the gateway con-troller can use the Audit Capabilities command to determinewhat packages are supported by a particular gateway. Thiscommand permits the design of gateways of varying complex-ity. Gateway controllers can interoperate with all of these typesof gateways by first determining their capabilities, and theninteracting with them accordingly.

Parameter syntaxParameters are syntactically different in the two protocols.MEGACO uses many more parameters than MGCP, andthese additional parameters permit better application soft-ware support.

TransactionsMEGACO introduces the concept of transactions, whichallow multiple commands to be bundled together into a singleMEGACO message. This bundling of commands reduces theload of gateway-to-gateway-controller communication, andalso reduces call setup times. However, MGCP does not allowcommands to be grouped into a single transaction it supportsonly one command per message.

Media stream propertiesAll of the modifications to the media stream properties arespecified as part of the connection parameters in MGCP,whereas MEGACO uses a termination descriptor to specifythese properties.

MEGACO specifies that the media processing attributes of atermination be restored to their default values whenever thattermination is assigned to the NULL context. MGCP specifiesthat the media processing attributes are restored to their defaultvalues only when all connections to an endpoint are deleted.

Signals and event handlingMEGACO activates event notifications and signals by passingthe Event Descriptor, Signals Descriptor and Digit MapDescriptor in an Add, Modify, or Subtract command.

MGCP activates event notifications and signals by means ofan explicit Notification Request, or a Notification Request

embedded in a Create Connection, Modify Connection, orDelete Connection.

MGCP explains the handling of Quarantine events, whileMEGACO does not discuss Quarantine events. Quarantineevents are events that occur at an endpoint while that endpointis still waiting for acknowledgement of its previous event noti-fication. Quarantine handling is needed because MGCP doesnot permit endpoints to report new events until they receiveacknowledgement of the previous event notification. Since thisrestriction is not imposed by MEGACO, quarantine handlingis not needed in MEGACO.

Preloading of digit mapsMEGACO permits an Event descriptor to reference a pre-loaded digit map. Each digit map has a scope that defines thetermination (or set of terminations) to which that digit mapapplies. Such a feature does not exist in MGCP.

Preloaded digit maps reduce the size of messages that need tobe exchanged between the gateway and the gateway controller,as the complete digit map need not be downloaded every timea call with a new dial plan is made.

PackagesThe concept of packages is the key to the extensibility of bothMEGACO and MGCP. The MGCP protocol specificationdefines all of the package types supported by MGCP, whereasin the MEGACO definition, the package types are defined inseparate RFCs and/or Annexes. This separation of packagetype definitions from the main MEGACO protocol specifica-tion permits easy extension of the MEGACO protocol. UnlikeMGCP, new versions of the MEGACO protocol specificationwill not be needed each time a new package that is defined.

Packages and termination typesMEGACO provides a simpler set of endpoint types thanMGCP. It includes termination properties and packages toallow the addition of new endpoint types to this simple set.

MGCP defines each endpoint type as a separate entity, withtypes such as:

announcement server endpoint interactive voice response access endpoint conference bridge endpoint packet relay endpoint wiretap endpoint

Gateway-to-gateway-controller associationThe gateway-to-gateway-controller association isestablished using the Service Change message inMEGACO. In MGCP this association is establishedthrough the security layer, and hence results in asecurity association.

Handling gateway controller failuresIn MEGACO, when a gateway controller fails, handover is initiated by the gateway controller issuing aService Change command to the gateway. This com-


mand indicates the new gateway controller ID to communi-cate with.

In MGCP, the association between the gateway controller andthe gateway is defined at the security level. Any gateway con-troller can take over if it has the proper security credentials.

Gateway rebootsThe fact that a gateway reboot has taken place is communi-cated in MEGACO by means of Service Change command.MGCP uses Restart In Progress for that purpose.

SecurityBoth MEGACO and MGCP address security. MGCP simplyspecifies IPSEC as the underlying security mechanism. (IPSECis the protocol defined for the security of IP networks.)However, MEGACO allows for the inclusion of an authentica-tion header that provides security when IPSEC is not available.

Support for application softwareThe concept of contexts is a powerful tool to represent confer-ences. As context definition is not dependent on the order in

which terminations are added or subtracted, the context pro-vides a framework where no special operations are requiredwhen one participant in a conference drops out. That term-ination can simply be subtracted from the context, withoutaffecting the connectivity of the terminations remaining in theconference. Conferences using MGCP are achieved by termi-nating several connections on a conference endpoint.

MEGACO is multimedia ready. It has a defined way to setmixing parameters for audio, video. This is made possible byits support of multiple media streams per termination, and theability to synchronize streams by setting context properties.MGCP cannot be used to set mixing parameters. Hence, itdoes not provide any explicit support for multimedia.

MEGACO supports the MOVE command that allows thegateway controller to move terminations from one context toanother with a single command. This eases imple-mentation of supplementary services (such as callwaiting and call hold) in which the media stream fromthe same subscriber must be connected to mediastreams in two different contexts, alternately.

MEGACO supports a Mux Termination construct thatfacilitates interworking with H.320 multimedia termi-nals. MGCP does not provide this construct.

MEGACO provides a high degree of control over themedia streams contained in a context. It allows thetransmit and receive of each termination to be con-

Standard Versions Market Acceptability

IETF MGCP Current Version = 1.0RFC 2705[No updates planned]

IETF Draft 0.4 [1] No commercial implementation available but expected MEGACO/ H.248 Final Release Planned only after it is submitted as RFC. There may be some labITU-T SG16 in Feb 2000 [2] implementations available.H.248

[1] There have been many successive revisions to this draft. The latest draft (08) is going through the last call, and is in the process ofbecoming an RFC.

[2] Since mid-June 1999, the MEGACO working group and the ITU-T SG16 group have agreed to publish a single document.

Table 2

CableLabsCable Labs has adopted and modified MGCP version0.1 for their protocol specification. Sample Companies Access Communications, AT&T Broadband & InternetServices, Cable One, Cable TV etc.

Softswitch ConsortiumSoftswitch has adopted MGCP as their standard, but theyare open to adopt MEGACO or H.248 after the definitionfor these standards are frozen. Backers: Cisco, Enron,HP, Level3, Lucent, Nortel, NorthPoint, Pulver, Rhythm,Telecordia, Vovida. Note that most of these companiesare members of IETF MEGACO working group as welland are committed to adopt MEGACO after it becomes a published standard.

Other vendors are building their products based on MGCPuntil MEGACO is published as standard.

Reprinted from CompactPCI Systems / September-October 2000r

trolled independently, and allows the connections betweenindividual streams to be controlled. This permits easy imple-mentation of new services such as muting of one of the partic-ipants, wire tapping, and speech-to-text conversion.

Adding new packages to the MEGACO protocol is easybecause package definitions are not part of the main protocoltext. Adding new packages is an independent procedure thatmerely requires registration of the new package with IANA.Building new applications by introducing new packages istherefore easier than for MGCP, which requires a new protocolrevision to introduce a new package.

MEGACO has a more general call model than MGCP. Thus, itis more efficient for TDM-to-TDM calls, TDM-to-ATM calls,and TDM-to-IP calls. Standards status and acceptance. It isevident from the comparison in Table 2 that MEGACO:

covers a broader set of requirements is easily extensible provides greater application level support can provide a better performance

MEGACO includes almost all the good features of MGCP(including Transport, Packages, events, and signals ) and addsnew features that permit fabrication of gateways with morecapabilities. It is therefore emerging as the final solution forthe gateway-to-gateway-controller interface.

Summary: Why MEGACO?MEGACO introduces several new concepts (such as contexts,ephemeral terminations, transactions etc.) that provide a pow-erful mechanism for supplementary services (like call wait-ing), multi-party conferencing, and multimedia support.

Conclusion: MEGACO is feature-rich and provides a betteroption to manufacturers to build value-added products withdifferentiated features.

IETF (MEGACO working group) and ITU-T (SG16) haveagreed to publish a combined document from this time for-ward. This is a significant development and should lead to thedefinition of a common protocol for networks that is accept-able to both the telecom standards organizations (ITU-T andETSI) and datacom standards organizations (IETF).

The IETF MEGACO draft document has been submitted forthe last call, has been accepted as H.248 by ITU-T, and has abetter chance of being accepted in the market.

MGCP Conclusion: This combined effort is being driven bymajor datacom and telecom vendors, and it is in the interest ofboth parties to ensure interoperability in converging networks.

MGCP is only an informational RFC. Hence, it willnot receive any further support from IETF.

The evolution of MGCP has stopped, and anyenhancements of services offered by vendors arelikely to be proprietary in nature.

Note: CableLabs has adopted and already modified the MGCPprotocol for telephony support on cable systems. They plan tosupport the modified protocol for their implementation.

Although MGCP vendors have formed industry forums (suchas SoftSwitch) and continue to support their initial implemen-tations based on MGCP, most have already committed to mov-ing to MEGACO in the future.

MEGACO Conclusion: Even though MEGACO is still evolv-ing and there are no commercial implementations, most of thelarge vendors plan to support MEGACO and have roadmapsto deliver MEGACO in the year 2000. This is becauseMEGACO is powerful and lends itself to meeting all therequirements of existing telecom applications while creatingnew opportunities for futuristic multimedia based services.

AcknowledgementsThe authors wish to acknowledge the contribution of Nancy Greeneof Nortel Networks. Nancys mail sent to the members of theMEGACO mailing list which cited differences between the MGCPand MEGACO protocols provided significant inputs for this article.

References[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-04.txt, Work-in-progress.[3] N. Greene, M. A. Ramalho, B. Rosen, draft-ietf-megaco-reqs-

08.txt.

Vikas Bajaj started his career in soft-ware development in 1991. He has beenworking for the past four years withHughes Software Systems Ltd, which is aleading communications softwareprovider based in India, where he hasbeen involved in architecting H.323,MEGACO and gateway controller based

gateway products. He has experience in implementation ofdatacom and telecom protocols, and has worked on theimplementation of datacom protocols such as TCP/IP, X.25,SDLC, and LLC for satellite networking products. His tele-com experience encompasses CAS signaling protocols (suchas R1-R2) and call-processing software for small switches.For the past two years, Vikas has been working on next gen-eration products, which are based on the latest suite of VoIPprotocols. He has been active in various forums such as theIETF MEGACO working group, which is working on theevolution of the VoIP protocols. Vikas has a Bachelorsdegree in Electronics and Communications Engineering,and a Masters in Computer Science from reputedIndian Universities.

If you have questions about this article, you can contact Vikas at:

Hughes Software SystemsElectronic City, Plot 31 Sector 18Gurgaon 122 015 (India)Tel: +91-124-6346666Web site: www.hssworld.com

Documents

Comparison Between MGCP and H.248