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).
![Gateway Reference Architecture](sw3_files/gr_architecture.gif)
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. Resource Control
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.
Media Processing Control
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.
Signal and Event Processing
- 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.
Statistics
Reporting
- 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.
Association Management
- 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
Transport
- 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.
Security
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. Application Support
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. Evolution of Gateway Control
Protocols
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.
What MEGACO Derives from MGCP?
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.
MEGACO version 0.5 vs MGCP version 1.0
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. Protocol Model
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. Protocol Definition
The protocol definition for MEGACO and MGCP is driven by
the differences in the protocol models. Some of the key
differences are summarized below.
MEGACO Supports |
MGCP Supports |
ADD termination
(Equivalent to Create connection) |
Create
connection |
Subtract termination
(Equivalent to delete connection) |
Create
connection |
Modify termination
(Equivalent to Modify, Notification Request &
Endpoint Configuration) |
Modify
connectionNotification RequestEndpoint
Configuration |
Service change
(Equivalent to Restart in progress but includes other
functions as well) |
Restart in
progress |
Notify |
Notify |
AuditValue
(Equivalent to AuditEndpoint and AuditConnection) |
AuditEndpointAuditConnection |
Move |
Move |
Audit Capabilities
(New Command) |
Not
supported |
- 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.
- 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.
- 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.
- 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.
- Parameters are syntactically different in the two
protocols. MEGACO has many more parameter descriptors
compared to MGCP that permit wider application
support.
- 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
- 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.
- 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
- 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.
- 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
- 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.
- 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
- 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.
- 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
- 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.
Protocol Application
Support
- 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.
Standard |
Versions |
Market
Acceptability |
IETF
MGCP |
Current
Version 1.0 RFC 2705 [No updates planned] |
CableLabs Cable Labs has adopted and
modified MGCP version 0.1 for their protocol
specification. Sample Companies - Access
Communications, AT&T Broadband & Internet
Services, Cable One, Cable TV etc. |
Softswitch
ConsortiumSoftswitch has adopted MGCP as their standard,
but they are open to adopt MEGACO or H.248 after the
definition for these standards are frozen.Backers:
Cisco, Enron, HP, Level3, Lucent, Nortel, NorthPoint,
Pulver, Rhythm, Telecordia, Vovida. Note that most of
these companies are members of IETF MEGACO WG as well
and are committed to adopt MEGACO after it becomes
standard |
Other vendors are
building their products based on MGCP till MEGACO is
published as standard |
IETF MEGACO/ITU-T
SG16 H.248 |
Draft 0.5* [H.248
Final Release Planned in Feb 2000 ]** |
No commercial
implementation available but expected only after it is
submitted as RFC. There may be some lab implementations
available |
*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. Conclusion: Why MEGACO?
- 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.
Acknowledgements
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. 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-05.txt", "Work-in-progress" [3]
N.Greene, M.A.Ramalho, B.Rosen,
"draft-ietf-megaco-reqs-08.txt"
Last updated : February 2, 2004
|