2.6.7 Media Gateway Control (megaco)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00


Tom Taylor <taylor@nortelnetworks.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:megaco@standards.nortelnetworks.com
To Subscribe: listserv@standards.nortelnetworks.com
In Body: subscribe megaco first_name last_name
Archive: http://standards.nortelnetworks.com/archives/megaco.html

Description of Working Group:

The working group will develop an informational RFC detailing the architecture and requirements for controlling Media Gateways from external control elements such as a Media Gateway Controller. A media gateway is a network element that provides conversion between the information carried on telephone circuits and data packets carried over the Internet or over other IP networks. This work will be done in consultation with other IETF working groups looking at similar issues.

The working group will also ensure that good information conduits exist with groups in other standards groups with expertise in the relevant PSTN technology. Other IETF working groups include PINT, IPTEL and SIGTRAN. In addition the working group will ensure that reasonable liaisons exist with similar activities in other standards bodies such as the ITU-T and ETSI.

This working group will also define standards track protocol(s) for controlling media gateways from external control elements such as a media gateway controller.

Examples of media gateways are:

* Trunking gateways that interface between the telephone network and a Voice over IP network. Such gateways typically manage a large number of digital virtual circuits. * Access gateways that provide traditional analog or Primary Rate (PRI) line interfaces to a Voice over IP network. * Network Access Servers that can attach a "modem" to a telephone circuit and provide data access to the Internet.

This working group assumes a separation of call control so the call control "intelligence" is outside the media gateways and handled by a media gateway controller. This group will NOT work on media gateway controller to media gateway controller protocols, nor on media gateway to media gateway protocols.

The working group will ensure that the security issues relating to the use of the standards track protocol in hostile environments are fully understood and that the protocol will will include security mechanisms to protect against attacks on the protocol and to ensure confidentiality where needed.

Planned output:

* Architecture & Requirements informational RFC

* Standards Track RFC for the protocol between a media gateway controller and a media gateway.

* Standards Track RFC for the MG and MC MIBs

* Informational RFC for application programming interface for the MC to MG protocol

Goals and Milestones:



Submit Initial draft of architecture and requirements document



Initial draft of protocol between MC and MG



Updated draft of protocol between MC and MG



Initial draft of MG and MC MIBs



Submit architecture and requirements document to IESG



Submit protocol(s) between MC and MG to IESG for publication as RFCs



Submit protocol to ITU-T SG 16 for decision as Recommendation H.248

Mar 00


Submit RFC MIBs for MC and MG to IESG for publication as RFCs

Apr 00


Close Working Group


Request For Comments:







Media Gateway Control Protocol Architecture and Requirements

Current Meeting Report

Reported by Tom Taylor.

The Media Gateway Control Working Group (Megaco) met on Thursday afternoon, Aug. 3, beginning at 3:30, with Tom Taylor as Chair. About 120 people attended. The meeting did not fill its entire two hour slot.

1. Agenda

The proposed and actual agenda was as follows:

1) Agenda bashing 5 min
2) Status report -- work in progress 15 min
3) Status report -- interop 5 min Brian Rosen
4) ISDN 10 min Bart van Doorselaer
5) CAS package issues 10 min Michael Brown
6) Auditing of ephemerals 10 min
7) SDPng requirements 5 min
8) IETF/ITU operating agreement 15 min

2. Status Report

The Chair presented a report on the status of work on Megaco/H.248, organized under the headings of "Base Protocol Status", ITU-T Work In Hand", "TIPHON Work In Hand", and "IETF Megaco Work In Hand".

2.1 Base Protocol Status

Draft-ietf-megaco-protocol-08.txt and -megaco-errata-03.txt were approved as Standards Track RFCs in May. As of the meeting date, they were at top of RFC Editor's queue, and should therefore be assigned RFC numbers shortly.

The ITU-T formally decided H.248 in June.

IETF Last Call on draft-ietf-megaco-merged-01.txt is complete. It was expected to be approved by the IESG as a standards-track RFC in the week following IETF 48. Since it is simply the merged content of the other two RFCs, it will obsolete them when it is published.

Two errors have been identified so far:

The list has also brought up a large number of points of clarification.

There was a discussion on how we would document these points. It was agreed (subject to ratification by the list) that we would rely on ITU-T documentation as presented in the H.248 Implementor's Guide. Specifically, we would publish the draft Implementor's Guide as an I-D. When Study Group 16 approves the document, we will publish a short RFC pointing to it. The ITU-T makes Implementor's Guides publicly available on the web at no cost.

The Chair noted that list discussion included some proposals for changes to the protocol. Since Megaco/H.248 has now been fully approved, no changes are possible to this version of the protocol.

2.2 ITU-T Work In Hand

The Chair listed the following SG 16 Annexes scheduled for November decision. WG Last Call has been issued on them. One general comment was received: make the I-D titles more descriptive.

Annex F: facsimile, text conversation, call discrimination

Annex G: display, key, keypad, label key, function key, indicator, soft key, ancillary input

Annex J: dynamic tone generation
Annex K: generic announcement

New transports:
Annex H: SCTP

Annex I: ATM

It was agreed that we would consolidate these annexes into two documents (packages, transport alternatives) for IETF Last Call and publication as Standards Track RFCs. The errors noted in WG Last Call will be reported to the SG 16 Rapporteur's meeting being held in Portland, OR, the week of Aug. 21-25.

The Chair listed the following further ITU-T work items:

In Study Group 16, for November determination, Feb'01 decision:

Annex L: Error Codes
Annex M: Advanced Audio Server packages.

On this latter, the Chair noted a potential Nortel Networks IPR claim on the original submission to the IETF (draft-cromwell-...), but could not say whether this survived in the current Study Group 16 document. He agreed to follow IETF rules on disclosure if and when Annex M comes back to the IETF.

As noted already, Study Group 16 will also maintain an H.248v1 "Implementor's Guide" (i.e. bugs and clarifications) as a living document. The first draft of this document should appear out of the Portland Rapporteur's meeting, and the first approved version out of the November Study Group meeting.

Study Group 16 has applied Annex G packages in H.323 Annex L "Stimulus Signalling", where H.248 content is embedded within messages passed between the Gatekeeper and the H.323 stimulus set. (For November decision.)

In ITU-T Study Group 11, two different pieces of work are in progress:

Question 9, for December determination:
New Recommendation Q.5x, package(s) for H.248
control of signal processing network equipment.
Contact: Larry Forni (larry.forni@errols.com)

Work on Bearer-Independent Call Control (BICC) related packages.
Contact: Christian Groves (christian.groves@ericsson.com)

2.3 TIPHON Work In Hand

ETSI TIPHON Working Group 6 is working on a protocol conformance statement (PICS) for a very limited subset of the protocol -- just enough for a basic call through a trunking gateway. For the latest draft document, see


Contact: Klaus Sambor(Klaus.Sambor@TELEKOM.AT)

2.4 Megaco Work In Hand

The Chair listed the following drafts reflecting work items of the group.

draft-ietf-megaco-mib-00.txt (Standards Track)

A new draft of this document was promised within the next month.

draft-ietf-megaco-naspkg-00.txt (Standards Track)

draft-ietf-megaco-ipphone-02.txt (Informational)



It was at about this point that Scott Bradner intervened to point out that Megaco was attempting to move beyond its charter. The Working Group cannot take on new work items unless they fall within that charter. Once the charter has been completed, what happens to the Working Group is a matter for discussion between the WG Chair, our Area Director, the IESG at large, and the IAB. The Megaco E-mail list should continue regardless of the fate of the Working Group itself, and IETF procedure allows the submission of non-WG-initiated drafts for advancement to RFC status.

Subject to that reminder, the Chair noted the following individual submissions to Megaco:


The Chair was corrected on this -- a more recent draft is available (see below).


A comment was raised on this draft, to the effect that the proposed tone identifiers needed clearer documentation so that parties outside of North America could judge their applicability. Michael Brown (michael.brown@nortelnetworks.com) indicated that the document was to be reissued and that it would be split into three parts. (See further discussion of channel-associated signalling below.)


draft-sharp-megaco-t1rbsapp-00.txt (expired)

Also note draft-rajeshkumar-mmusic-sdp-atm-02.txt (SDP for ATM connections). The intent is to complete work on this document within the next month or two. Comments should be made now. Brian Rosen (brosen@marconi.com) committed to follow up and close the loop with a Megaco package for ATM.

3. Interop Event Status Report

Brian Rosen presented one chart giving all the essential details regarding the Megaco/H.248 interoperability event to be held this month. Between ten and twenty implementations are expected, representing both MGs and MGCs.

4. ISDN (draft-bouwen-megaco-isdn-01.txt)

Bart Van Doorselaar (bart.van_doorselaer@alcatel.be) noted that the draft had been recycled to take out the discussion of signalling transport in Megaco. Nevertheless, the issues of signalling channel management and D-channel data remained open. Brian Rosen encouraged Bart and his co-authors to submit detailed package proposals. Scott Bradner asked whether the ITU-T might have related work in hand. Christian Groves suggested that the group in Study Group 11 dealing with ISDN might be the right place to do the work.

5. Channel-Associated Signalling

Michael Brown gave a brief presentation of the the issues associated with channel-associated signalling (CAS) packages. He and others felt that the approach presented in the R1 and R2 package documents was overly repetitious, and that it should be possible to define reusable events and signals common to multiple signalling systems. The authors of those documents had responded on the list to say that they had not seen enough commonality to be worthwhile isolating. In any event, it appears desirable to make CAS package definition a matter of focussed discussion amongst interested parties. The action is upon the Chair to invite these parties to submit their names and then work together to come up with a common view.

6. Auditing Of Ephemerals

In the original draft agenda, this portion of the meeting was to be devoted to issues raised on the list. The Chair observed that list discussion did not lend itself to easy summarization, because there were a lot of small issues rather than a few large ones. He had identified one recent issue which could be followed up: the question of how the MGC could find out what kinds of ephemerals the MG supported in advance of instantiation. His summary of list discussion was as follows:

Issue: how to tell what kind of ephemerals the MG supports, in advance of instantiation.

Subsidiary issues:

Potential solutions:

It was noted in subsequent discussion that the original proposal for a naming pattern property had been turned down at the ITU-T not because binary naming patterns are implausible, but because the ASN.1 expression of naming patterns had not been formulated and it was considered too risky to attempt the task at the last minute. Now that the pressure is off, the job can be done. Brian Rosen expressed an interest in submitting a proposal.

On the general issue, Brian suggested that the Chair had presented a good summary, but that resolution would have to be done on the list.

7. SDPng

The Chair noted that MMUSIC is beginning to study requirements for a protocol to support session negotiation as opposed to simple session description. They have dubbed this work "SDPng".

A first cut at requirements has been presented in draft-kutscher-mmusic-sdpng-req-00.txt. Related material has been assembled at


Megaco is a potential customer (in Megaco/H.248v2), recalling that we had to add a fair amount to SDP to achieve what we needed.

Discussion in a small group following the MMUSIC meeting had brought about general agreement that there was a fairly fine balance between meeting the real requirements and creating something overly complex. The Chair presented a summary of those requirements which originated with Mark Handley (mjh@aciri.org), a participant in that discussion:

Note that others would consider this list a good start but not quite complete.

Flemming Andreasen (fga@cisco.com) and Michael Brown both expressed their concern over what introduction of a new protocol would do to existing SDP implementations.

8. Cooperation With Other Standards Bodies

In May the Chair had presented to the list a draft agreement for continued cooperation with Study Group 16 and other Study Groups. In reprise of this topic, he proposed to leave aside the legalese and have the meeting consider just the principles of any agreement. He presented four charts enumerating these proposed principles.

8.1 Considerations

The first chart presented the considerations which should be behind any agreement.

1) IETF members have a continuing interest in free access to H.248 documentation as H.248 evolves. Almost certainly they wish to participate as equal partners in that evolution.

2) There is a small probability that ITU-T reorganization this fall may place the Question dealing with H.248 (currently Q. 14/16) under new senior management. Thus any agreement for cooperation with this Question should be finalized only after the WTSA finishes its work.

3) The IESG may choose to reorganize/disband Megaco. Hence as much as possible, any agreement should be drafted to be independent of Megaco's existence.

4) Other groups doing H.248 related work may not want to cooperate as closely with Megaco as SG 16.

There was no discussion of these points.

8.2 Keeping Each Other Informed

The minimum requirement for any agreement is that the signatories agree to keep each other informed about any Megaco/H.248-related work they plan to undertake.

Corollary: the IETF must provide a designated point of contact for notifications.

Discussion: Scott Bradner noted that the minimum aim of any agreements between the IETF and other bodies should also include the encouragement of cross-publication of the resulting work. This could be by means of Informational rather than Standards Track RFCs.

8.3 Base Protocol Evolution

Chart contents:

We want agreement with Q. 14/16 and its successor that:

Discussion: Scott Bradner and Greg Ratta indicated that discussion of this chart was moot. Any continuing agreement with the ITU-T should have broader scope than that of a particular Working Group and a particular Question. Moreover, ITU-T procedures may change significantly in the wake of the meeting of the governing body next month.

8.4 Packages

Chart contents:

We want agreement with other standards groups that:


Michael Kallas noted that the strong relationship between many packages points to a need for continuing coordination. Christian Groves in response recalled that the Megaco E-mail list will continue. As for the matter of consultation, package work actually involves two issues: style, and content. The originator of a package should control the content. An expert adviser could rule on style. Further discussion reiterated the importance of maintaining Megaco as a continuing list. Scott Bradner summed up by recalling that IANA registration rules could include review by a designated expert. This procedure is recommended when some degree of control over the registered material is desired. The alternative is to base registration on publicly-reviewed specifications.

9. Adjournment

The Chair adjourned the meeting with a word of thanks to all who had faithfully supported the work of Megaco. He noted that it might be the last time we met.


None received.