Media Gateway to Media Controller Protocols

Aug 1, 2003

␡

⎙ Print

Page 1 of 4 Next >

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 

IP Telephony

Learn More Buy

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.931¹, 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.² 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).

Figure 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.

Figure 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.

Page 1 of 4 Next >

🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Privacy Notice

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
Such marketing is consistent with applicable law and Pearson's legal obligations.
Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

As required by law.
With the consent of the individual (or their parent, if the individual is a minor)
In response to a subpoena, court order or legal process, to the extent permitted or required by law
To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
To investigate or address actual or suspected fraud or other illegal activities
To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020

Email Address