![]() |
Though IP telephony may well be the springboard for the kinds of new, enhanced voice and data services that carriers crave, deployment has been slowed by lack of (or too many!) Voice over IP (VoIP) standards. The latest call control protocol, Megaco (an evolution of Media Gateway Control), adds to the problem while seeking to reduce the number of protocols in use.
Megaco addresses the relationship between the Media Gateway (MG), which converts circuit-switched voice to packet-based traffic, and the Media Gateway Controller (MGC), sometimes called a call agent or softswitch, which dictates the service logic of that traffic (see Figure 1). Put another way, Megaco is designed for intradomain remote control of connection-aware or session-aware devices, such as VoIP gateways, remote access servers, Digital Subscriber Line Access Multiplexers (DSLAMs), Multiprotocol Label Switching (MPLS) routers, optical cross-connects, PPP session aggregation boxes, and so on.
For carriers and vendors , the decision to implement Megaco means answering the question "How much signalingthe protocols that make connections between endpoints (such as telephones, PBX uplinks, and videoconference stations )should be in the gateway?" From time to time, this debate has swung from "Endpoints are where the action is; they should be smart," to "Interaction is king; best to centralize."
For those who believe that end devices should be intelligent , signaling terminates in the MG itself. An example is a Session Initiation Protocol (SIP) phone, as the call control signaling runs directly on the end device. For those who believe there is merit in leaving the signaling on a general-purpose computer, leaving adaptation of media on and off the network to a specialized device, there is need for a protocol between the media handling part (the MG) and the signaling part (the MGC).
That's where MGCP and the newest kid on the block, Megaco, (also known by _its ITU designation, H.248) come in. These are relatively low-level device-control protocols that instruct an MG to connect streams coming from outside a packet or cell data network onto a packet or cell stream such as the Real-Time Transport Protocol (RTP). Megaco is essentially quite similar to MGCP from an architectural standpoint and the controller-to-gateway relationship, but Megaco supports a broader range of networks, such as ATM.
For example, MGCP typically conditions the endpoint to look for an off-hook indication (when a person lifts the receiver to make a call). When the MG detects the off hook, it tells the MGC, which might respond with a command to instruct the MG to put dial tone on the line and listen for DTMF tones indicating the dialed number. After detecting the number, the MGC determines how to route the call and, using an inter-MGC signaling protocol such as H.323, SIP, or Q.BICC, contacts the terminating MGC. The terminating MGC might instruct the appropriate gateway to ring the dialed line. When the MG detects the dialed line is off hook, both MGs might be instructed by their respective MGCs to establish two-way voice across the data network. Thus, these protocols have ways to detect conditions on endpoints and notify the MGC of their occurrence; place signals (such as dial tone) on the line; and create media streams between endpoints on the MG and the data network, such as RTP streams.
Right now, many vendors consider it more practical to build large gateways that separate the signaling from the media-handling because of the density of the interconnections (which may have OC-3 or even OC-12 connections). Removing the signaling to a fast server is more practical than trying to integrate it into the MG. Also, by removing the signaling from a residential gateway, network operators retain a higher degree of control, which many believe will result in more reliable networks vital if VoIP systems support lifeline/emergency services.
There are two basic constructs in Megaco: terminations and contexts (see Figure 2, page 38). Terminations represent streams entering or leaving the MG (for example, analog telephone lines, RTP streams, or MP3 streams). Terminations have properties, such as the maximum size of a jitter buffer, which can be inspected and modified by the MGC. A termination is given a name , or TerminationID, by the MG. Some terminations, which typically represent ports on the gateway, such as analog loops or DS0s, are instantiated by the MG when it boots and remain active all the time. Other terminations are created when they are needed, get used, and then are released. Such terminations are called "ephemerals" and are used to represent flows on the packet network, such as an RTP stream.
Terminations may be placed into contexts, which are defined as when two or more termination streams are mixed and connected together. The normal, "active" context might have a physical termination (say, one DS0 in a DS3) and one ephemeral one (the RTP stream connecting the gateway to the network). Contexts are created and released by the MG under command of the MGC. Once created, a context is given a name (ContextID), and can have terminations added and removed from it. A context is created by adding the first termination, and it is released by removing (subtracting) the last termination.
While a simple call may have two terminations per context (the termination representing the end device, such as the telephone, and the termination representing the RTP connection to the network), a conference call might have dozens, each one representing one leg of the conference. It's also possible to have a context with only one termination (say, in a three-way call). At any one time, two of the terminations are in one context (and are therefore connected together), while the third termination is in a context all by itself. When the user indicates that he or she wants to switch from the active to the standby caller (by using "flash," for instance), one of the terminations is moved to the other context.
A termination may have more than one stream, and therefore a context may be a multistream context. Audio, video, and data (for example, T-120 shared whiteboard) streams may exist in a context among several terminations.
Besides making basic connections by placing terminations in contexts, MGs may also be able to generate tones, announcements, ringing, and other signals that the user can hear. Megaco includes facilities to apply signals to terminations and control them. This enables gateways that have Interactive Voice Response (IVR) functionality to be controlled with Megaco, and also provides normal call-progress indications .
Asynchronous events, such as the hookswitch on a phone or a DTMF keypress , can be detected on the MG and reported to the MGC. By using a shorthand notation called a "digitmap," MGs may be programmed to look for an entire phone number or feature invocation and send the "dial string" to the MGC as one event. Statistics may be kept by the MG, and reported to the MGC, for such quantities as bytes sent or received, packets lost, and so on.
Megaco uses a series of commands to manipulate terminations, contexts, events, and signals. The Add command adds a termination to a context and may be used to create a new context at the same time. The Subtract command removes a termination from a context and may result in the context being released if no terminations remain. The Move command moves a termination from one context to another. Modify changes the state of the termination. The commands AuditValue and AuditCapabilities return information about the terminations, contexts, and general MG state and capabilities. ServiceChange creates a control association between an MG and an MGC and also deals with some failover situations. All of these commands are sent from the MGC to the MG, although ServiceChange can also be sent by the MG. The Notify command, with which the MG informs the MGC that one of the events the MGC was interested in has occurred, is sent by the MG to the MGC.
Commands are grouped into transactions, which are a series of commands that are executed in order, acting as the unit of transfer from the MG to the MGC and back again. Transactions are sent by a variety of transports between MGs and MGCs, including UDP and TCP (other transport options are coming). The MGC then sends an acknowledgement , along with replies for each command, back to the MG.
A package is a set of properties, events, signals, and statistics that are defined in a document and realized on a set of terminations in a gateway. Megaco defines a base set of packages for very common capabilities, such as analog and digital loops, DTMF detection and generation, and RTP. Both the IETF and ITU are working on additional package definitions. By defining a package, all the specific characteristics of a termination that realizes how that package is defined, and all gateways that implement that package can be controlled by an MGC that understands the package. The analog loop package has events for hookstate, signals for ring, and statistics for bytes sent and received, for example. A termination can have more than one package implemented on it. Packages can also be defined by any organization; a vendor could even define its own package.
With approximately a dozen independently developed implementations expected at a late-August 2000 interoperability-testing event at the University of New Hampshire's Interoperability Laboratory (see www.tsemantics.com/megaco-interop), Megaco is off the starting block. Several carriers have begun asking their vendors for Megaco support. There are, of course, a number of MGs already on the market. These devices use older, de facto protocols, most notably IPDC and MGCP. Of concern to many is whether Megaco will supplant MGCP, or whether the on-the-ground reality of MGCP will stymie acceptance of Megaco as the international standard for media applications.
"I can't predict if Megaco will take root, at the expense of MGCP or IPDC, or [if] the reverse will happen," says Ike Elliott, vice president of softswitch services at Level 3 Communications. "In truth, the protocols bear a strong resemblance to one another, and for many applications, it won't matter much which protocol is used. However, I can say that Megaco is more closely coupled with media applications than MGCP because the base protocol includes semantics for conferencing. Because of that, MGCP may be a better base for non-media-centric applications, such as MPLS-based session control.
This article was largely taken from notes by Brian Rosen, the chief technology officer at Marconi (www.marconi.com), who put together the lion's share of this article's material.
Learn more about Megaco at the IETF's home page (www.ietf.org/html. charters /megaco-charter.html). The current draft is available at ftp://standards.nortelnetworks.om/megaco/docs/latest/megah248_protocol.pdf/.
This tutorial, number 147, by Doug Allen, was originally published in the October 2000 issue of Network Magazine.
![]() |