NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 18-Oct-99
Tom Taylor <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Vern Paxson <email@example.com>
Transport Area Advisor:
Scott Bradner <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe megaco first_name last_name
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.
* 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
Submit architecture and requirements document to IESG
Updated draft of protocol between MC and MG
Initial draft of MG and MC MIBs
Initial draft of Application Programming Interface (API) for the protocol between the MC and the MG
Submit protocol(s) between MC and MG to IESG for publication as RFCs
Submit RFC MIBs for MC and MG to IESG for publication as RFCs
Submit API for the protocol to the IESG for publication as an RFC
Close Working Group
No Request For Comments
MEGACO WG Wednesday, November 10, 1999 Washington D.C.
Chair: Tom Taylor <firstname.lastname@example.org>
Reported by Matt Holdrege <email@example.com>
164 people signed the blue sheet.
1. Agenda Bashing
The proposed agenda for this session was accepted. See slides in file Megaco1.ppt.
2. Review of Red Bank Results
Brian Rosen <brosen@ENG.FORE.COM> led us through the Red Bank meeting results. (See Brian's note to the list entitled "Changes made in Red Bank", sent 25 Oct'99 at 12:12pm Eastern time.)
Changes covered the areas of
- Signals and Events
o open issues remain despite much discussion
Other changes include an issue regarding SDP. One must be able to parse received SDP s, t, o lines. But you don't need to send them.
The ATM and SCTP transports are still being worked and will be added at a later date.
3. Intellectual Property
Tom Taylor made the following announcement with respect to intellectual property claims:
(a) We will follow normal IETF policy, to the effect that where equally satisfactory alternatives exist, we will choose the unencumbered one.
(b) In the case of the Scoggins/Brown proposal for an ATM package, the claim is embodied in a package description. Megaco packages can be registered by anyone according to the procedures described in our draft). That doesn't mean that anyone is forced to implement them outside of a normal commercial agreement.
Tom also requested authors to declare any knowledge they might have of IPR embedded in the content of the V12 draft of the base protocol and all annexes. No one made any declaration.
4. Process and Relations With The ITU-T
Concern was expressed about ITU process. Scott Bradner related that there was an IESG and ITU meeting on the Sunday preceding the IETF meeting where they straightened out the understandings about the process. At that meeting, he indicated that we might issue Megaco as a Proposed Standard RFC in advance of decision as H.248, in order to provide a cleaner handoff. We have since taken the decision that we will follow this procedure, with WG Last Call targeted for early December.
5. Review of Requirements
Tom Taylor presented the results of a review of the requirements document against what we had accomplished in the actual protocol (see file Megaco1.ppt). He noted that a large number of deliverables depend upon completion of the appropriate package definitions.
Inward loopback is a requirement that is not satisfied by the current protocol. Christian noted that it was a requirement for MGCP and that MEGACO should have it as well.
The section on resources associated with a call ID should be edited better.
We have a requirement that the MG provide statistics at fixed time or count intervals. We could define a package to handle this.
Tom indicated that we had not met the requirement for an MG to release all resources under control of an MGC for the purposes of failover. It is believed that we actually satisfy the spirit of the requirement.
There is a requirement for throttling of bursts of event reports at the MG. We have partial compliance. It was suggested that this is related to overall congestion management and future improvements should be handled in the next revision.
Tom had noted an open issue on MG discovery of MGC capabilities. An MGC can return profiles to an MG so we satisfy the requirement.
Ability to specify commands and parameters as ignorable. This topic will be covered in more detail at a later date.
MG control over incoming message rate. The transport layer can satisfy this requirement.
Application-level segmentation. It seems that we satisfy the main requirement.
Replay attacks. These are covered by IPsec AH.
Resistance to denial over service. AH covers this, but we should state it better in our document.
VC identifier plus AAL2 slot, and wildcarded variant of these. This is referred to the design team.
Concept of containers of terminations. This is referred to the design team.
Efficient disconnections of all VCC's on a given physical port. This will be taken to the list.
How are ATM and RTP bearer characteristics specified? Issue noted for further discussion.
Is the MG expected to match wildcarded terminationIDs where property values are specified? For ADD only or for all commands? For further discussion.
The requirements document will be modified to reflect the outcome of the review, to the extent that rephrasing of requirements seems to be required. The requirements document will be issued for last call shortly. Tom will issue an I-D annotating the requirements to indicate how we have satisfied them (or not, as the case may be).
6. Packages Work Program
Zacharias Bilalis <Zacharias.Bilalis@icn.siemens.de>,
Mike Kallas <firstname.lastname@example.org>
The basic principles worked out for package definition in Red Bank were reviewed. The following packages are in the H.248 white document:
- Tone generation/detection - defines generic mechanism to generate/detect tones.
- DTMF generation/detection
- Call progress tones generation/detection
- Analog line supervision
- Basic continuity test
- Networks - properties of network terminations, independent of network types
Other basic packages are still being drafted:
- Fax/modem detection package.
- Dynamic tone definition - playback tones
- Signal processing network equipment package - extends DS0 package
- Key - key systems
- Label key
- Function key
- Soft key
- Text conversation
- Text Telephony
- Robbed bit signalling
Matt Holdrege stated that there is no need for a NAS package. The few points that were made about what should be in a NAS package were established. But these were determined to be general case items that should be in some sort of root or basic package and there is no need for a specific NAS package. Someone said that there will be a NAS package anyway.
Concern was expressed about who publishes packages. If the IETF and ITU are publishing a package for the same solution, they should be the same. Otherwise, each organization can publish their own packages. This topic will be discussed further off-line.
6. Fax/Modem package
Glenn Parsons <email@example.com>
Glen described ITU-T Study Group 8 FAX standards timelines and proposed annexes to H.248 for FAX. The design goal is to define all FAX and modem events, define switching interaction call flows (voice to FAX, voice to modem, FAX to voice to FAX, etc.) See slides in file MegacoFAX.ppt.
A design team was formed under the leadership of Glenn, Roy Spitzer <firstname.lastname@example.org>, and James Rafferty <email@example.com>, to develop these packages. About ten people expressed interest in participating. The team was asked to coordinate with Gunnar Hellstrom <firstname.lastname@example.org> to ensure that these packages would operate in harmony with packages for text conversation.
Second session Friday, November 12, 1999
See file Megaco2.ppt for the agenda.
Matt Holdrege <email@example.com>
Matt described the current draft as very preliminary and that a more complete draft would be issued before the end of the year. It was mentioned that we need a coordinating document which describes how to manage all the MIB's on an MG cohesively. We discussed how and where to produce such a document. The consensus seems to be that the MEGACO WG could start on such a document, but it should work closely with the OPS area where they have the network management techniques.
2. Specification of transport:
Each stream has its own star. Do we permit multiple media transport types on the same termination? There were no objections. The implication is that a termination name doesn't necessarily reveal anything about what transport it supports.
We discussed the fact that the network package may be redundant. This will be taken to the list.
3. How to audit ephemeral terminations at MG startup.
Have the Audit command specify properties? Or use a termination naming pattern? As noted above, that will not necessarily work. We need the solution to the problem of learning names of provisioned terminationID's in any event. MGC's must have terminationID's provisioned anyway, in order to route to them, but may not know which MG they are on. A proposal to specify the naming pattern for terminations on the MG as a string property of ROOT was considered worth taking to the list.
The volume of audit responses was a major concern. A proposal for syntax to request and receive aggregated (set union of) capabilities for a group of terminations was considered worth following up on the list.
4. Signals & Events & Digitmap package
Brian Rosen <firstname.lastname@example.org>
Proposals coming out of Thursday evening's informal discussion of events were discussed. One of these proposals was to eliminate event buffering except for the operation of digit maps, and to have the latter then perform any buffering needed. Michael Thomas [email@example.com] pointed out that the intent of quarantine buffers in MGCP was to capture ALL events, not just those enabled in the current event descriptor, and hold those events between the time a Notify is sent to the MGC and the time it sends an update to the reporting termination. This view differs from that understood by the protocol design team, and needs to be considered in further work on events. It was also proposed that digit maps should be defined in packages rather than as part of the basic protocol. This drew unfavourable comment, on the ground that it amounted to a structural change to the protocol as currently defined and put an excessive amount of behaviour into a package.
It was suggested that queuing of signals should be optional since there will be a large class of MG's that does not need it. This is already the case in the current (v12) H.248 document, since support of signalList is optional.
Chip Sharp <firstname.lastname@example.org>
Chip Sharp [email@example.com] noted that an annex providing the option of Megaco/H.248 transport over SIGTRAN SCTP was in preparation, for determination at the February SG 16 meeting (and decision presumably in the fall). The ITU-T is able to add annexes without reissuing the whole protocol document.
6. Open issues
Tom Taylor presented a long list of minor issues for discussion
- Root package: need for definition noted.
- Can the command set be extended? Can the set of descriptors be extended?
- Time stamps: local or UTC? Confirmed that they should be UTC.
- Deleting AAL2 bearers not possible? Resolution being worked.
- Wildcards in SDP allowed? To the list.
- Whitespace in SDP allowed? No.
- Extend SDP with ATM parameters? Some said we should be aligned with Annex C and we should do this in the MEGACO WG rather than MMUSIC. Others said we shouldn't try to be aligned with ITU annexes. Others said that we could do all this in a package. Tom Taylor will sort out with Brian Rosen and Joerg Ott (Chair of MMUSIC).
- Synchronization of streams? Discuss on list.
- What to do with duplicate transaction when having sent a TransactionPending? Editor to clarify.
- Interpretation of optional commands? Errors should not stop processing of the transaction.
- Scope of names. Can a property in a package have the same name as a Megaco command? Resolved that we would NOT have reserved words within the protocol.
Matt Holdrege emphasized that we need to make some compromises soon to get the document finished. The alternative is further deployment of non-standard schemes such as IPDC, MGCP and DSS1 over IP.
7. Going Forward
The plan for going forward was discussed. Some said we should re-charter to study applications. Some questions were raised about the cooperation with the ITU. It was proposed that a hibernation period between version 1 and 2 would be good to find out what the real issues are. An interoperability test was proposed.
We have decided to produce a proposed standard for the IETF. If the ITU meeting adopts changes, we may recycle the proposed standard. How we would go about deprecating features during the draft standard phase was discussed but not clearly resolved. It was mentioned that the ITU has the flexibility to fix or remove features, just as the IETF does.
Media Gateway Control Agenda
Fax and Modem call setup with Megaco/H.248