Home > Articles > Networking

This chapter is from the book

This chapter is from the book

What is MGCP?

The media gateway controller protocol (MGCP) is specified in draft-huitema-MGCP-v0r1-00.txt and was released in November 1998 just prior to the IETF meeting in Orlando where it was debated in the MEGACO working group.

MGCP is designed to interface a media gateway controller and media gateway. The protocol is text based3 and supports a centralized call model. The media gateway controller is called call agent in MGCP terminology and the media gateways can be either different types of VoIP gateways (residential, trunking, corporate, etc.), network access servers or even voice over ATM gateways. The protocol is being built to serve gateways from 1 (a multimedia terminal adapter to connect an analogue phone to IP) to 100 000+ ports (class 4 or 5 switches). In the MGCP connection model the ‘atoms’ are endpoints (just like in H.323 and SIP) and connections (this is not the case in H.323 and SIP) that are ‘virtually’ connected (just like within a switch).

Only signaling and media planes are covered by the current MGCP draft. Both management and services planes have not been specified yet.

The protocol is based on SGCP version 1.1 (sgcp.bellcore.com) with CableLabs extensions and IPDC version 1.0. From the last protocol MGCP imports mainly the notion of event packages, a few new operations and some name changes. The end of the MGCP document describes in detail the changes made from SGCP v.1.1 and IPDC and incorporated in MGCP.

MGCP is a master/slave protocol. It uses other protocols to fulfill its requirements, such as the session description protocol which is used to describe the media aspects of the phone call. In its principle, MGCP is very close to the proprietary protocols of switch manufacturers that convey information back and forth between call control points (this terminology is not a ‘standard’ one used in intelligent network documents. IN does not define a standard interface between CCF and SSF) and service switching points.

This principle (in the context of MGCP) clearly places the intelligence on a physically separate element – the media gateway controller and not on the hardware endpoint, the media converter. But unlike the switch architecture as specified in IN documents where the call control remains close to the actual hardware endpoints, in the MGCP architecture the call control functionality is no longer attached to the media part.

Initially the protocol was designed to support only constant capabilities (for example, same codecs). But market needs and an ever-increasing number of requirements pushed the authors to consider adding dynamic capabilities, such as codec negotiation, a feature built in H.323. H.323 endpoints can negotiate their capabilities through H.245 messages and can even change one or more of their capabilities while the conversation is taking place. The origins of MGCP, known and published as SGCP, tried to avoid such dynamic features in order to keep SGCP as ‘simple’ as possible and be a competitive alternative to H.323. The addition of such functionalities and the expected addition of multimedia features will undoubtedly increase the complexity of MGCP.

In MGCP the session description protocol (see Chapter 2) is used to describe formally various parameters to enable establishment of connections between endpoints. MGCP does not use the multimedia features of SDP, such as the description of multiparty multimedia conferences. MGCP is not designed to support multimedia calls like H.323 or SIP does. It is nevertheless expected that this functionality will be added very soon (see requirements section). One of the other nice features of SDP is its flexibility and extensibility. New information elements can be added easily and registered to IANA. For a while, the use of Extensible Markup Language (XML) was considered as an alternative to describe telephony sessions (or multimedia) but due to lack of consensus at IETF the idea was abandoned. Also, as Christian Huitema, one of the head engineers of Bellcore, now Telcordia, describes: ‘One advantage of a layered specification (such as using SDP in MGCP) is that it provides a clean partition between call signaling (as in MGCP) and media signaling (as in SDP).’

In its first release MGCP is composed of eight commands exchanged between the media gateway controller or call agent and the media gateway or simply gateway with the following features:

Notification Request

From call agent to gateway

Notification

From gateway to call agent

Create Connection

From call agent to gateway

Modify Connection

From call agent to gateway

Delete Connection

From call agent to gateway

Audit Endpoint

From call agent to gateway

Audit Connection

From call agent to gateway

Restart In Progress

From gateway to call agent

Readers may find all the details concerning MGCP in the draft (see above) and on the archive of the following mailing lists: sgcp@bellcore.com and megaco@baynetworks.com.

MGCP commands

Notification Request

This command requests the media gateway to watch for specific telephony events. These could be telephony signals, such as off-hook, on-hook, fax tones, modem tones, wink, flash hook, continue tone and detection, DTMF and pulse digits. One of the nice features of this command is the association of actions with each of the events. Using this facility, the communication and processing of information between the two entities can be optimized. For example, when the call agent requests the media gateway to watch for digits, it can request the media gateway to buffer the digits. By using this functionality the en bloc sending can be achieved easily.

One feature that is missing in this command is the ability for a media gateway controller to give other backup media gateway controllers’ addresses. Should this functionality be included, MGCP could provide a built-in network reliability, just as H.323 version 2 does.

Notification Command

This command enables the media gateway to send back events that were requested by the media gateway controller. The media gateway can send one or several events in a notification command if it is asked to do so by the media gateway. Since the gateway is not supposed to have any ‘intelligence’, it sends the events in the order it detects them. It is up to the call agent to put events in the right order.

The collected information is sent by the media gateway to the call agent using the Notify command in the ObservedEvents field. From a protocol engineering point of view it would have been much more effective to use RTP (with compressed RTP headers) to send these events since RTP is designed to carry such information. Future releases of MGCP may adopt the use of RTP to send these messages back to the call agent.

Create Connection

This command is sent by the call agent to the media gateway to create a connection between two endpoints. In addition to the necessary parameters that enable a media gateway to create a connection, the LocalConnectionOptions parameter provides features for quality of service (echo cancellation, silence suppression), security, and network-related QOS fields (bandwidth, type of service, use of RSVP).

By sending a Notification Request command the call agent has the ability to request the gateway to execute simultaneous actions. In order to achieve this feature the call agent can use RequestedEvents, RequestIdentifier, DigitMap, SignalRequests, QuarantineHandling and DetectEvents parameters. The following example is given in MGCP:

  • ask the residential gateway to prepare a connection, in order to be sure that the user can start speaking as soon as the phone goes off-hook

  • ask the residential gateway to start ringing

  • ask the residential gateway to notify the call agent when the phone goes off-hook.

This can be accomplished in a single CreateConnection command, by also transmitting the RequestedEvent parameters for the off-hook event, and the SignalRequest parameter for the ringing signal.

This feature dramatically reduces the number of round trips necessary to establish a connection between two endpoints and improves the scalability of the call agent.

Modify Connection

This command enables a call agent to modify a connection that has already been set up by the gateway. The simultaneous feature mentioned below can also be used with the Modify Connection command. Modify connection can affect the following parameters of a connection: activation, deactivation, change codec, packetization period, etc.

Delete Connection

This command enables the call agent to terminate a call for a given connection. It should be noted that if there is more than one gateway involved, the call agent will send the Delete Connection command to each of the media gateways.

A nice functionality provided by MGCP (note that this is also provided by H.323) is that the media gateway, upon termination of a connection, has to send the call agent the following information:

  • number of packets (RTP) sent

  • number of octets (number of payloads) sent

  • number of packets (RTP) received

  • number of octets received

  • number of packets lost

  • interarrival jitter

  • average transmission delay.

These parameters are fully described in RFC 1889.

MGCP allows also a media gateway to clear a connection on its own, such as when there is loss of a connection. In this context the media gateway issues a Delete Connection command to the call agent and sends all the parameters concerning call statistics back to the call agent as if it were a normal Delete Connection situation.

It is also possible for a call agent to delete multiple connections at the same time, using advanced hierchical naming structures and/or a wildcarding option (the wild card character is *). This command does not return any individual statistics or call parameters, making it unsuited for multiparty or conference calls. We believe that in the near future the media gateway will be required to send back this information.

Audit Endpoint

In order to check whether an endpoint is up and running the call agent can use this command. This feature is inherited from the switch environment.

Audit Connection

This command enables the call agent to retrieve all the parameters attached to a connection.

Restart in Progress

This command allows a gateway to make a call agent aware of an endpoint or a group of endpoints that have problems. The command allows three options: graceful (no connection lost), forced (connection(s) lost) and restart (the media gateway will restart soon). Further to these messages the call agent can decide if it wants to test these endpoints/connections before trying to make another call.

Fig. 3.3 shows MGCP protocol and architecture in use.

03fig03.gifFigure 3.3. MGCP protocol and architecture in use


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.

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