Device Control Protocol
Alternatives For Media Servers
As the newest component of next generation voice
architectures, media servers have been receiving a lot of attention
recently. While there is strong consensus about what a media server is and
how it fits into packet voice networks, there is some debate about how to
best control the features, or ï¿½service building blocks,ï¿½ offered by
media servers. The goal of this article is to examine, in detail, the
various options currently available for media server control. The main
control protocols contrasted are MGCP/Megaco and SIP. In addition, we will
look at the differences in tightly coupled and loosely coupled interactions
between a media server and its control agent.
CONTROL INTERFACE OVERVIEW
The media server control interface can be viewed as allowing a
softswitch or application server, called a control agent, to perform two
main functions, namely bearer control and media control.
Bearer control enables the establishment of media streams between the
media server and far-end devices such as media gateways and packet-attached
terminals (e.g., SIP or H.323 terminals). Session Description Protocol (SDP)
is used to describe these media streams. SDP descriptions are exchanged
between far-end devices and the media server, through the control agent, and
are used to negotiate the characteristics of media streams. Once these
characteristics are negotiated, the media server and far-end device set up
the agreed-on media streams.
In contrast, media control allows the control agent to tell the media
server exactly how to process media streams.
Protocols such as MGCP, Megaco, and SIP fundamentally provide bearer
control, but can also provide media control, when augmented with additional
mechanisms such as signals and events (tightly coupled interactions) or
scripts (loosely coupled interactions). Both signals/events and scripts can
be used with MGCP/Megaco or SIP, although, as will be described below, MGCP/Megaco
is commonly associated with tightly coupled media control and SIP is
commonly associated with loosely coupled media control.
Tightly Coupled Media Control
In tightly coupled interaction, detailed, real-time, asynchronous
messages are sent back and forth between the control agent and the media
server. To use the MGCP/Megaco terms, messages downward (from the control
agent to the media server are signals,) and message upward (in the reverse
direction are events).
Each signal message provides specific instructions to the media server on
actions to perform on media and/or what events to look for. Each event
message provides complete information on an event condition that the media
server has detected.
A good example of tightly coupled operation is a multi-level IVR prompt
menu, where the control agent and media server exchange signals before (what
announcements to play and digits to detect) and events after (what digits
were detected) each menu level.
Loosely Coupled Media Control
In loosely coupled operation, messages are still exchanged between
control agent and media server. There are fewer such messages, however,
because the control agent sends the media server a script with a potentially
complex set of instructions. Only after the script has completed executing
will the media server return results to the control agent. The control agent
then processes the results and can, if necessary, send the media server a
new script to be executed. In the example above with a multi-level IVR
prompt system, the entire menu tree would be described completely in the
script passed to the media server.
SPECIFIC PROTOCOL ALTERNATIVES
Until now the discussion around the media server control interface has
been theoretical: Bearer control versus media control, and tight coupling
versus loose coupling. We will now examine specific protocols that carry out
these operations in todayï¿½s media servers.
MGCP and Megaco (H.248)
MGCP and Megaco are the most common media server control protocols,
and they provide essentially similar and interchangeable functionality. They
began as media gateway control protocols and have been evolved to also
support control of media servers and simple terminals. As a bearer control
protocol, MGCP/Megaco by itself allows the setup and tear down of single
(e.g., IVR) or multiple (e.g., conferencing) stream sessions. For media
control, more than 50 event packages have been defined for MGCP/Megaco. The
majority of these have been defined in the IETF/ITU for Megaco and not for
media servers, although two that are especially relevant to media servers
have been defined for MGCP in the PacketCable project of CableLabs.
These latter two are called Basic Audio Server (BAU) and Advanced Audio
Server (AAU) and are described in the PacketCable Audio Server Specification
(PASS). BAU and AAU provide rich and mature functionality for announcements,
IVR, and play and record. Additional event packages are currently being
defined for ASR and TTS.
MGCP and Megaco are usually associated with tightly -coupled media
control but an event package has been defined to describe how they invoke
scripts such as VoiceXML. Thus MGCP and Megaco can also support loosely
With rich and mature standards and support of key bodies such as the
Softswitch Consortium, CableLabs PacketCable, and IPCableCom, MGCP has
become the most widely adopted control interface for media servers. Megaco,
although not currently deployed widely for media servers, is endorsed by the
Internet Engineering Task Force (IETF), the International Telecommunications
Union (ITU), the Multiservices Switching Forum (MSF), and the Third
Generation Partnership Project (3GPP).
SIP is a newcomer to the world of media server control protocols and while
not as mature, offers some powerful capabilities. Although SIP is a
peer-to-peer protocol designed, and used, for end-to-end signaling, it can
easily be used in a client-server or master-slave manner, when coupled with
third-party call control by the control agent. Control SIP is not a new
protocol variant, however, just a way of using SIP, essentially a profile of
There are only two differences in this profile:
- The media server waits passively for service requests (SIP INVITE
messages) and never sends service requests to the control agent.
- There is a special syntax defined for the service request (for the
Request-URI) to specify what task the media server is to perform.
As a bearer control protocol, SIP by itself, just like MGCP/Megaco,
allows the setup and tear down of single or multiple stream sessions. SIP
service requests to the media server can also, however, play announcements
and invoke scripts.
In contrast with MGCP/Megaco, SIP is usually thought of today in
association with loose coupling and scripted operation, typically VoiceXML
(in combinations with HTTP). The Speech Application Language Tags (SALT)
scripting language has been proposed by Microsoft, Cisco, and others as an
alternative to VoiceXML and may be a strong contender once it is fully
defined by mid-year. In addition the industry is now starting to look at how
to support tight coupling in SIP. SIP already has in place an events
mechanism (also called SUBSCRIBE/NOTIFY) that provides a framework for event
packages. It is likely that this mechanism will be used for tight coupling
Tight versus Loose Coupling
Because both MGCP/Megaco and SIP have very similar bearer control
capabilities, a key decision factor in media server control protocols is the
type of media control, tight coupling versus loose coupling.
The basic conclusions that can be drawn are:
- Plain SIP can support both simple conferencing and announcements.
- Plain MGCP/Megaco is used, and is always combined with event packages
even in the simplest implementations.)
- Scripting allows all tasks except business conferencing and fax to be
supported, for both bearer control protocols.
- Event packages allow all tasks to be supported, for both bearer
Thus loose coupling alone does have limitations compared to tightly
coupled media control, for example it cannot provide the complex interaction
required by business conferencing or facsimile.
SIP versus MGCP/Megaco
As indicated above, both MGCP/Megaco and SIP provide very similar
bearer control capabilities. Where they differ, though, mainly because of
their unique histories, is in their degree of maturity and the degree of
maturity of their event packages.
The following are some key factors that favor SIP:
- The SIP protocol is better specified than MGCP. Work on the MGCP
protocol was distracted by the introduction of Megaco, and the MGCP
specification is consequently not as solid as it might be. But although
Megaco itself is better specified than MGCP, its media server events
packages lag MGCPï¿½s.
- As a result of SIPï¿½s popularity as an end-to-end signaling protocol,
there are more powerful development tools available for SIP. This
results in shorter development times and less expensive development.
- Application servers already have need to support SIP for signaling and
HTTP for Web interfaces, and so donï¿½t need to add additional protocols
in order to support SIP media servers.
- Some applications need only basic media processing such as simple
announcements and simple conferencing, and for them, plain SIP is a good
- Some applications do additionally need IVR but want to, and are able
to, entirely delegate the IVR handling to the media server through the
use of scripts. For this, plain SIP augmented with scripting is a good
MGCP/Megaco, however, still have some strong advantages today:
- There are carrier class MGCP/Megaco media servers available today and
deployed in the field. SIP lags MGCP/Megaco in this respect.
- MGCP/Megaco is the only alternative possible today for tasks requiring
signals and events, such as business conferencing or facsimile or more
complex features. MGCP/Megacoï¿½s event packages are mature, tested, and
deployed, whereas SIPï¿½s event packages have not yet been defined.
- Softswitches already use MGCP/Megaco and event packages for media
gateway control, and can reuse much of this functionality for media
Our analysis has shown that overall there is no clear winner today between
MGCP/Megaco and SIP. In the absence of a simple answer, the prospective user
of media servers must carefully consider their own technical and timing
requirements in order to select the protocol that best meets their needs.
Finally, a related factor to consider is multi-protocol support. Media
servers are infrastructure components that will likely be communicating with
multiple application servers and softswitches, and there is therefore a
strong case for requiring media servers to concurrently support multiple
device control protocols and coupling types, i.e., both MGCP/Megaco and SIP
as well as loose and tight coupling. Only when such capabilities are
available will service providers be able to fully realize the operational
and capital savings afforded by a multi-service, shared resource such as a
media server. c
Garland Sharratt is chief architect and vice president of business
development at Convedia, a leading supplier of carrier class,
next-generation media servers. For more information, please visit the
companyï¿½s Web site at www.convedia.com.
To The March 2002 Table Of Contents ]