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
Chair(s):
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:
Done |
|
Submit Initial draft of architecture and requirements document |
Done |
|
Initial draft of protocol between MC and MG |
Done |
|
Updated draft of protocol between MC and MG |
Done |
|
Initial draft of MG and MC MIBs |
Done |
|
Submit architecture and requirements document to IESG |
Done |
|
Submit protocol(s) between MC and MG to IESG for publication as RFCs |
Done |
|
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 |
Internet-Drafts:
· Megaco IP Phone Media Gateway Application Profile
· MEGACO Packages Not Included In MEGACO/H.248 White Draft
· Fax, Modem, Text Telephone Determination using Megacoo/H.248
· Megaco Protocol (With erratta folded in)
· H.248 Annex G (Pre-Decision White Document)
· H.248 Annex H (Pre-Decision White Document)
· H.248 Annex I (Pre-Decision White Document)
· H.248 Annex J (Pre-Decision White Document)
Request For Comments:
RFC |
Status |
Title |
RFC2805 |
Media Gateway Control Protocol Architecture and Requirements | |
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:
- conflict between the TDM Circuit package and Annex C
- token "EB" used for both EmbedToken and EventBufferToken.
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.
Packages:
Annex F: facsimile, text conversation, call discrimination
- comments (Mule/Parsons, 7/25-26/00)
Annex G: display, key, keypad, label key, function key, indicator, soft key, ancillary input
- one error noted (Blatherwick, 7/31/00)
Annex J: dynamic tone generation
Annex K: generic announcement
- a meeting participant noted a comment which the Chair had overlooked.
New transports:
Annex H: SCTP
- correction noted (Xie, 7/13/00)
Annex I: ATM
- I-D abstract typo noted (Xie, 7/11/00)
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)
SG 11 BICC
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
http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg6/DTS06017/
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)
- main remaining charter item
- awaiting inputs from Brown et al
- awaiting ideas out of interop event.
A new draft of this document was promised within the next month.
draft-ietf-megaco-naspkg-00.txt (Standards Track)
- expert resource located, more complete draft in next month.
draft-ietf-megaco-ipphone-02.txt (Informational)
- recycled document to be submitted for WG Last Call in the next month.
draft-ietf-megaco-r2package-01.txt
- WG Last Call issued, issues raised re CAS in general and this document in
particular
- proposed to constitute CAS design team to settle.
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:
draft-bouwen-megaco-isdn-00.txt
- alternatives for ISDN signalling transport; ISDN D-channel data
The Chair was corrected on this -- a more recent draft is available (see below).
draft-brown-supplpkgs-00.txt
- more call progress tones (two packages)
- analog line enhanced alerting package
- trunk signalling packages (robbed bit, MF)
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-hss-megaco-r1package-00.txt
- R1 signalling (international counterpart to MF)
draft-sharp-megaco-t1rbsapp-00.txt (expired)
- applicability statement for robbed bit signalling
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:
- whether auditCapability of ROOT returns packages which apply to individual terminations rather than the MG as a unit
- whether there are constraints on the combinations of packages supported on a given (ephemeral) termination
- naming patterns associated with specific types of ephemerals
- (implicit) whether naming pattern is a meaningful concept with binary encoding
Potential solutions:
- favourable definition of auditCapability of ROOT
- naming pattern property
- transport-specific ROOT packages, including naming patterns.
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
http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/
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:
- Ability to indicate when a given parameter is required and when it can safely be ignored if not supported or understood.
- Ability to indicate whether a given proposal applies to send direction, receive direction, or both.
- Ability to provide multiple formats and indicate whether the intent is "support all" or "choose one".
- Ability to group: equivalent of multipart/related and multipart/alternative.
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:
- we work with them as equal partners in developing any new versions of the base protocol;
- WG Last Call resolution precedes ITU-T determination;
- once any new version has been determined, it is frozen except for bug fixes and clarifications;
- IETF Last Call and IESG approval occur in the interval between determination and decision;
- in principle, the document approved by the IESG is the same as the document decided by the ITU-T (i.e. we do not have to keep a separate errata document as we did this time around). The ITU-T naturally retains the right to make last-minute modifications based on members' comments or newly-found errors.
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:
- they will coordinate work on packages with us to minimize duplication of effort;
- we will be given a chance to review packages that they are working on when we have relevant expertise, and our comments will be taken into account;
- our respective processes will be coordinated to allow for that review.
Discussion:
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.