Home > Articles > Networking

Media Gateway to Media Controller Protocols

  • Print
  • + Share This
Get a brief history of IP telephony and then move into a definition of the media gateway controller protocol (MGCP) to help you understand the usage of protocols.
This chapter is from the book

This chapter is from the book

Introduction

It is interesting to note that once the technical credibility of carrying real-time data such as voice over IP was acknowledged by the carriers and service providers, the involvement of well known telecommunications equipment manufacturers in the definition of IP telephony protocols changed dramatically.

In the early days of IP telephony, 1995–1997, the VoIP market was created by the pioneers using the drivers of cheap, long-distance and international communications and the excitement of new technology. This trend was supported by endpoint-oriented – mostly PC vendors such as Intel and Microsoft. It is not surprising that the first incompatibility issues between IP telephony clients have been addressed by the ITU-T recommendation H.323 based on ISDN video-conferencing protocols, ITU-T recommendation H.320.

We have seen that the core of the signaling protocol uses a slightly modified version of digital subscriber signaling number 1 (DSS1) protocol, also known as ITU-T recommendation Q.9311, a user to network interface (UNI) protocol. This protocol assumes that the endpoint has the capability of generating the rich set of signaling messages. The terminal must have the intelligence to assemble and disassemble ASN.1 PER structures and interpret the information and also maintain the state of the call. Those aware of the ISDN philosophy and protocols would immediately recognize the pattern that distributes the call-control functions between local exchanges (class 5 switches) and intelligent ISDN terminals.

The same basic assumption was used in drafting the H.323 recommendation: personal computers running the VoIP client software have all the intelligence and processing power necessary to use H.225 and H.245 for signaling and RTP for transferring real-time traffic. Using powerful PC endpoints was fully in line with the assumption that the market will be developed by corporate users eager to use video conferencing on their existing IP or IPX network.

But the market interest for real-time communications over IP came from another direction: new and incumbent carriers space.2 Although the business model of various roles in carrier space may differ, they share at least one common denominator: they will make their revenue on services and the basic voice service is the necessary condition to be in this market. The early adopters of this market realized that their customers demand more and more bandwidth to carry their data traffic needs and IP is the right protocol for carrying both voice and data.

Now we can come back to the protocols. In mid-1998, when the important request for information (RFI) and request for proposals (RFP) for building large VoIP networks were sent to the vendors, those who did not have any product or any product plan based on H.323 were caught by surprise. They could not let such opportunities escape them knowing that time to market is the killer weapon in the high-tech market. On the other hand, some R&D departments realized that H.323v1 was not satisfactory in fulfilling some important requirements from carriers.

Lack of mature products, lack of some features in H.323v1, lack of marketing efforts in favor of H.323v2 and time to market issues (trying to stall the market until they were ready) pushed the incumbent vendors to react against H.323 and propose alternative protocols to address the needs of large-scale phone-to-phone deployments.

Which protocol?

The first proposal came from Bellcore (now Telcordia) and Cisco to address the needs of cable operators that want to become Competitive Local Exchange Carriers (CLEC) using IP on top of their HFC infrastructure. The simple gateway control protocol (SGCP) was introduced in early May 1998 by Cisco during a PacketCable™ meeting (later in other standards bodies, IETF, ITU-T SG 16 and ETSI TIPHON) as a cost-effective alternative and better suited protocol to implement and deploy than current H.323 implementations in the context of the cable operators’ market.

The second proposal, the Internet protocol device control (IPDC) set of protocols, was presented to ITU-T SG 16, ETSI TIPHON and IETF a month later. IPDC addresses more or less the same requirements as SGCP but with a different transport approach. While SGCP depends solely on UDP, some reliability features and the application layer to fulfill transport requirements, IPDC proposes the use of Diameter (an extension and replacement for Radius) to carry PDUs between respective entities.

It was not long before the forces behind these two protocols realized that by unifying their efforts they could get bigger consensus and foster the adoption of their position.

Bellcore and Level3 played a key role in merging these two proposals into one: media gateway control protocol (MGCP). MGCP has been proposed to various standards groups, IETF (media gateway controller (MEGACO) working group), ETSI TIPHON and ITU-T SG 16. In addition, companies supporting this protocol created an industry forum, the multiservice switching forum (www.msforum.org), to develop complementary protocols and services necessary for providing different types of services on ATM (and, of course, IP) based networks.

The IP telephony industry, although very young, already has a legacy in the H.323-based VoIP products and solutions. Since the inception of H.323 there has been a lot of effort invested in the creation and improvement of the recommendation, in its marketing, its implementation and in interoperability testing. None of the companies behind these products is ready to throw away these efforts and lose the potential sales opportunities. The H.323 contenders are well aware of the limitations of the protocols composing this recommendation and they have chosen to adopt a different approach to address the new needs (see the require-ments section) and any H.323 flaws – they will contribute to the improvement of H.323 rather than propose an alternative.

The first set of improvements came with release 2 of the recommendation (see the chapter on H.323) and at the time of writing this book more improvements were being made in release 3 of H.323 (see the chapter on H.323) to match the growing interest and the new requirements of service providers and corporate users and, of course, to fix some more bugs.

The third proposal comes from the H.323 supporters. It is based on the same set of requirements as MGCP (see the requirements section) and uses an object-oriented protocol to carry the information flow between the media gateway and media gateway controllers. As expected, this protocol fits in better with the H.323 architecture.

It is important to note that all the media gateway to media gateway controller protocols emphasize the interworking of network elements introduced in these new proposals with H.323 network elements. However, we would like to draw readers’ attention to the fact that such considerations are over simplified – as we will see later, when considered together, MGCP and H.323 architecture present redundant network elements, especially the gatekeeper, the heart of an H.323-based network. It is obvious that the authors of these protocols had to comply with one of the unwritten rules governing technical wars: political correctness.

Having set the background we propose to review the general requirements being addressed with these device protocols, how they fit in a global voice over IP network architecture, what impact they have on the existing network models, and finally call flows for basic services.

All these questions are debated heavily in various standards bodies and industry consortiums, and none of the protocols is expected to be adopted as proposed by their authors. The selection process in standards groups follows more or less the natural selection process – it can only be hoped that the best technical solution among the various proposals will be adopted to serve the business needs of the IP telephony industry.

What about the requirements?

In 1998 there were a lot of contributions in standards groups concerning the requirements for IP telephony, focusing either on architecture issues and/or protocols questions. It is interesting to note that the number of contributions concerning requirements is much higher than it was in the early days of IP telephony standardization in ITU-T and ETSI. This is a good sign.

We are not going to focus on generic requirements for IP telephony or realtime data transport over IP networks but on those relating to architecture and protocol issues that were discussed on the different mailing lists related to IP telephony, especially the TIPHON and MEGACO standard groups.

The following documents specify most of the requirements expressed in various standards bodies with regard to media gateway to media gateway controller protocol. As IETF provides an easy access to its document through its web server, www.ietf.org, we have chosen to reference these documents through the IETF. These documents can also be found in TIPHON and ITU servers, with different names and format:

  • draft-taylor-ipdc-reqts-00.txt: Requirements for A Telephony Gateway Device Control Protocol

  • draft-taylor-megaco-reqs-00.txt:

  • draft-sijben-megaco-mdcp-00.txt:

The chairman of the MEGACO working group of IETF provided a list of requirements divided into nine categories: accounting, applications, architecture, design efficiency, flexibility, scalability, performance, reliability and security. Obviously the list is not exhaustive and we expect some of these categories to be removed, or others added, as the standardization work proceeds.

Table 3.1 is based on the compilation of requirements provided on the MEGACO mailing list as the first summary. The term ‘device control protocol’ represents the media gateway controller to media gateway protocol.

A new architecture for IP telephony?

The requirements listed in Table 3.1 lead us to propose a reference network architecture that will support the services to be provided by all the functional elements we will need to identify. Unfortunately, at the time of writing, there was no agreed reference architecture in standards bodies. We believe that it will be difficult to reach a global consensus on the physical plane but there is a good chance of achieving a stable and lasting functional architecture for these requirements.

Whenever a network architecture is designed there are always some basic assumptions made. We will try to clarify the inevitable hidden words and suggest possible functional architectures that are likely to shape tomorrow’s networks.

The first assumption is that these architectures and protocols are being designed to ease the interworking between an IP network carrying real-time data and a PSTN network. The corollary of this is that one day – hopefully within 5–10 years for incumbents and today for newcomers – the IP network will carry all types of data over high-speed backbone and access networks.

It is also assumed that in the carrier environment the direct routed call model of H.323 does not fit very well with the existing habits of service providers which are used to having the means to control the call from its beginning to its end.

Table 3.1. Requirements compiled by MEGACO for MG to MGC protocol

Requirements

Category

Globally unique session ID

Accounting

Need to allow connections to modems (network access server function) This feature is very interesting: it allows an Internet access server to offer voice capabilities, especially if this feature can be offered through a single port (universal port)

Application

Neutrality of device control protocol with respect to signaling protocols used. The referred signaling protocol is the telephony signaling protocol. This can be SS7, TUP or any other protocol.

Application

An efficient way to set up and parameterize RTP associations, regardless of the way they are set up between MGCs, or between an MGC and an autonomous station

Application

Need to listen for tone signaling even on endpoints controlled by other types of signaling (e.g. Q.931), with consequent co-ordination issues

Application

Need for IVR-controlling extensions to scripting Application Need for support of detection and reporting of long tone (especially #) duration

Application

This is useful for calling card features. Need to consider how MGC and IVR interact in both directions

Application

MG able to provide event notification

Application

Need to support connections to complex network resources such as IVRs, wiretaps

Application

Need to support multimedia. This is definitely a new and important feature. The addition of this requirement clearly makes the MGCP-like protocols an alternative to H.323 or SIP

Application

Need to support use of network resources located in the MG or elsewhere

Application

Protocol should be able to refer to network resources such as announcements in the same way regardless of their physical location

Application

High-level protocol structure should be independent of bearer type. Here we can have, for example, an ATM layer instead of the IP layer

Application

Must provide for situation where requested connection or modified connection cannot be supported

Application

Specialized requirements for IVR application

Application

Permit synchronization of tone signaling and other media content at downstream points in the media path

Application

Requirement for reliable transport of event notifications to the MGC

Application

Requirement for ordered delivery of messages relating to a given session at the final point of consumption

Application

Potential need for pre-emption of outstanding requests

Application

Need to support provision of tones (particularly ringback) and announcements from different points in the call path

Application

Reliable detection of all valid supervision events (such as on/off hook transitions)

Application

Need to support different flavors and both ends of continuity tests

Application

Ability to request continuity test and report (transponder end)

Application

Ability to run continuity test over packet bearer connection

Application

Wireless IP support

Application

Potential need to leave DTMF in wave form for PSTN interaction

Application

Need to support DTMF as RTP payload type, as notifications to MGC, or both at once. This particular point was missing in original SGCP, IPDC and MGCP documents. Surprisingly, the protocol to carry real-time information, RTP, was not taken into account in these documents. A complete new protocol was used instead to carry DTMF tones

Application

Architectural requirement that integrated gateways have no need to implement MEGACO protocol. This leaves the option of having H.323 or SIP-based gateways and gatekeepers since if MGCP is not used the gateways will have to handle all the lower layer signaling issues anyhow

Architecture

The specification of the media gateway should be the minimum required to design the protocol, and beyond that should not constrain implementations

Architecture

Need for a clean syntactical separation between content which is of strictly local interest and content which the MGC must share with other network entities

Design efficiency

Reuse existing protocols where possible. It seems obvious that this decision was difficult to reach because it is sometimes easier to design a protocol from scratch. The use of RTP was long debated for DTMF signals

Design efficiency

Limit protocol scope to promote reusability

Design efficiency

Protocol syntax for requesting and receiving notification of signaling events should be independent of the application and the specific signaling system in use

Design efficiency

Need to distinguish static endpoint configuration from other functions and use appropriate protocol for purpose

Design efficiency

Need to specify structure of protocol formally at an early date

Design efficiency

Need to pass easily through firewalls

Design efficiency

Can upgrade different network entities independently

Flexibility

MG should be able to indicate a temporary resource unavailability

Flexibility

Need means for MGC to determine which optional capabilities a given MG supports

Flexibility

Need to allow for signaled flow characteristics on circuit as well as on packet bearer connections

Flexibility

Need to allow internal connections between any combination of bearer types

Flexibility

Potential need to specify which of multiple incoming streams on a bearer connection is to be monitored for tone signals

Flexibility

Should allow for possibility that protocol PDUs exceed UDP MTU size

Flexibility

Flexibility in distribution of call-processing control

Flexibility

Cannot assume proximity of MGC to MG

Flexibility

Need to allow multiple MGCs to have active access to the same MG

Flexibility

Need to consider various domain models for MGC-MGC, MG-MGC and MG-MG operation. But it is outside the scope of the MEGACO working group to specify protocols between these entities

Flexibility

Need for extensibility

Flexibility

Need to support distributed MGs

Flexibility

Ability for MGC to receive all notifications of DTMF detection on a single port, accompanied by associated call context information

Flexibility

Control of QOS for signaling path. There was a clear lack of QOS signaling in the early versions of SGCP

Performance

Take note of current PSTN performance standards when setting design performance targets

Performance

Need to consider critical resource consumption in design of protocol

Performance

Need to consider protocol PDU sizes vs transport MTU sizes in designing protocol

Performance

Need to support peak calling rates in order of 150 calls/s at MGC

Performance

Need to consider cost of encryption when designing wireline protocol

Performance

Reduce the number of unnecessary iterations between MGC and MG

Performance

Need to respect time constraints on processing of individual control messages

Performance

Allow for default/provisioned settings so that commands need only contain non-default parameters

Performance

Endpoint programmability

Performance

Need to minimize messaging required to perform continuity tests

Performance

Maximum 200 ms cross-MGC initial address message (SS7 message) propagation delay

Performance

Maximum 200 ms from end of dialing to IAM (initial address messsage) emission

Performance

Ability for MGC to delegate filtering to MG

Performance

MGC able to invoke scripts on MG

Performance, scalability

Avoid messaging avalanches on startup

Performance, startup

Need to minimize messaging required upon boot/reboot

Performance, startup

Need audits to return actual states in MG rather than requested states

Reliability

Should be possible to detect mismatches of perceived resource state between MG and MGC

Reliability

MGC and MG provide each other with booting and reboot indications

Reliability

MGC and MG able to detect loss of connectivity

Reliability

MG must offer its configuration to the MGC upon startup or association recovery

Reliability

Use names rather than physical addresses to locate network entities

Reliability

Allow for different control relationship profiles, then define a very few covering majority of industry needs

Reliability

Reporting of unexpected endpoint state (e.g. persistent off-hook after reboot)

Reliability

Explicit activation of endpoint programs by MGC on boot/reboot

Reliability

Appropriate handling of endpoint program activity status on failover

Reliability

MG detection and quarantine of endpoints generating ‘showers’ of supervision events

Reliability

Need to specify MG behavior for interactions between maintenance commands and resource (e.g. endpoint) states

Reliability

Need to correlate commands and responses

Reliability

Need to detect duplicate transmissions

Reliability

MGC able to activate/deactivate specific endpoint programs at any time

Reliability, application

Assure reliability, availability, security of services being provided

Reliability, security

Appropriate handling of endpoint supervision transients following boot/reboot

Reliability, startup

Need to inform MGCs on a per-endpoint basis that boot/reboot has occurred, if control associations are between MGCs and endpoints rather than between MGCs and MGs

Reliability, startup

Need to allow MGC control over order of reactivation of endpoints following boot/reboot

Reliability, startup

Large potential fanout from MGC to associated SGs and MGs

Scalability

MG/MGC can authenticate source of messages received

Security

Privacy of control messages maintained

Security

Protocol must operate across untrusted domains in secure fashion

Security

Need to ensure that commands come from sources authorized to use the resources affected

Security

Need for authentication and authorization of commands

Security

Non-repudiation in context of customer-located MG talking to operator MGC

Security

Minimize system cost by avoiding duplication of effort (DTMF detection) Requirements Category

System

Because SS7 is so essential for service providers as a network to network signaling protocol, the proposed architecture has to interface seamlessly with the existing SS7 network. This will allow carriers to control from either network circuit switched connections and supplementary services as specified in the intelligent network framework. This integration implies that the IP network with these network elements will be seen by the PSTN network as just another switch.

The original idea of interfacing PSTN and IP networks came in mid-1998 from carriers in the US facing congestion problems in their egress switch that terminates Internet telephony service numbers. The incredible success of the Internet and the price pattern of local calls in the US triggered a high usage by end users. Unfortunately, none of the incumbent network was designed and built to face such a call pattern. To overcome these problems most of the US carriers requested a solution from network access servers’ vendors (see Fig. 3.1).

03fig01.gifFigure 3.1. SS7 dialup access architecture

Another important point to mention is the actual physical separation of the SS7 signaling gateway from the call agent and the media gateway. One of the driving factors of such separation is the scarce number of SS7 point codes; other drivers are the need to improve the scalability and reliability, and allowing a pair of SS7 signaling gateways to be connected to a pair of signal transfer points.

From this architecture to an architecture integrating VoIP was just a small step, as shown in Fig. 3.2, and these views can be found in draft-greene-ss7-arch-frame-00.txt.

03fig02.gifFigure 3.2. The media gateway to media gateway controller architecture with SS7 connectivity

It is important to note that SG and SA/MC can be combined, as well as all three boxes, of course. But the architecture is being designed to identify open interfaces and specify the protocols between these interfaces.

  • + Share This
  • 🔖 Save To Your Account