Current Meeting Report
Slides
2.7.7 Media Gateway Control (megaco)
NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It
may now be out-of-date. Last Modified:
26-Nov-01
Chair(s):
Tom Taylor <taylor@nortelnetworks.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion:megaco@ietf.org
To Subscribe: megaco-request@ietf.org
In Body: subscribe megaco
Archive: ftp://ftp.ietf.org/ietf-mail-archive/megaco/
Description of Working Group:
Note: There is an additional file storage area at
ftp://standards.nortelnetworks.com/megaco/docs/
There is a Web interface (up to February 2001 only):
http://standards.nortelnetworks.com/archives/megaco.html
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 |
| Apr 00 | | Close Working Group |
| Feb 02 | | Submit Megaco/H.248 version 2 to IESG |
| Feb 02 | | Submit RFC MIBs for MC and MG to IESG for publication as RFCs |
Internet-Drafts:
Request For Comments:
| RFC | Status | Title |
|
| RFC2805 | | Media Gateway Control Protocol Architecture and
Requirements |
| RFC3015 | PS | Megaco Protocol (With erratta folded in) |
| RFC3054 | | Megaco IP Phone Media Gateway Application Profile |
Current Meeting Report
Media Gateway Control (Megaco)
52nd IETF
The Megaco Working Group met on Wednesday afternoon, December 12, from 1400-1500, under the Chairmanship of Tom Taylor <taylor@nortelnetworks.com>.
45 people attended.
Slides presented at the meeting have been placed at
ftp://standards.nortelnetworks.com/megaco/docs/Current/IETF/Megaco-SLC/
1. Agenda
======
The proposed agenda was as follows:
1 min: Agenda Bashing
5 min: draft-tappenden-atm-AAL2-package-00 Chris Tappenden
45 min: H.248v2 new features proposed by SG 16
Remainder: H.248v2 new features proposed by Megaco
The agenda was accepted as proposed. In the event, there was no time for the final item.
2. draft-tappenden-atm-AAL2-package-00
Chris Tappenden <chris.tappenden@alcatel.com>
=============================================
This draft proposes a procedure for setting up an AAL2 connection and a package to support that procedure. Chris asked for an indication of interest in the work. He got two or three responses. Work will continue off-line.
3. H.248 Version 2 New Features
============================
Documentation
-------------
The complete text of draft H.248v2 is provided in draft-ietf-megaco-h248v2-00.txt. It is also available as an MS Word or PDF document with markup at
ftp://standards.nortelnetworks.com/megaco/docs/Current/ITU-SG16/
Note that the markup does not distinguish between version 2 features and unapproved Implementor's Guide items.
Summary:
-------
The Chair opened the discussion with some general remarks on the ITU-T view of protocol evolution and the need to make the transition as painless as possible. He raised the question of what the IETF should do with Megaco/H.248 v1. The final outcome of that discussion is that a new RFC will be requested in February, based on draft-ietf-megaco-3015corr-xx, including all Implementor's Guide corrections approved through that date.
The Chair then went through the new features added to this point in H.248v2.
The intent of the review was not to review the features in detail, but to identify any issues with them and to decide if any should be omitted from H.248v2. During this review, the need to revisit the details of several of the features was noted. The meeting also rejected at this point the proposed text in the table of section 7.2.9 which would provide a union of responses to an ALL wildcard of context audits, without using the W- tag or its binary equivalent. At the end of the meeting a poll was taken: of those
strongly in favour of a given feature, and those strongly opposed. On the basis of these polls, it was concluded that there was a definite preference to omit the context package feature from H.248v2. The remaining features are acceptable. The Chair will seek consensus for this position on the list.
General
-------
This part of the discussion was introduced by the Chair's slide entitled "H.248v2 General Remarks". With regard to Megaco/H.248v1, the Chair suggested that the alternatives were to freeze content as of the issuance of
H.248v2, continue to update version 1 documentation even after that date by back-propagating applicable corrections from the H.248v2 Implementor's Guide, and possibly take version 1 to Draft Standard when deployment experience made this sensible. Immediate discussion brought out the points that:
- talk of a "freeze" was nonsensical, since we are dealing with corrections and clarifications rather than new content
- the real issue is when to issue a consolidated version 1 document for the convenience of the industry, since corrections will continue to accumulate for the indefinite future
- in any event, carriers want Megaco to maintain its identity with H.248.
Peter Blatherwick <Peter_Blatherwick@Mitel.COM> and Brian Rosen <Brian.Rosen@marconi.com> questioned whether new features had to be introduced at this time. Instead, we should follow the Draft Standard process. We should try to negotiate synchronized release of a maintenance update of H.248 with the ITU-T. Without deployment experience, we cannot judge whether the proposed new features are really required.
Regardless of what we do (Brian added), we and the ITU-T must remain in synchronism. It is important to publish the changes which have been introduced by the Implementor's Guide. However, the range of uses for the protocol is shrinking. Given that it was developed so quickly, making additions to it without the benefit of deployment experience is asking for trouble.
Context Properties
------------------
The Chair introduced discussion of this feature by advising the meeting that
his arguments presented at the Dublin meeting had drawn the response that SG
16 was willing to drop the feature from H.248v2 if Megaco so wished. However, the Chair emphasized, this was not a "done deal" and the meeting and list are free to comment on the matter.
The Chair presented charts showing the impact of the feature on the specification. In the text, it affects sections 6.2.3, new 7.1.19, 12, and 12.1.2. It also
affects section 7.2.9, although the new content in this section was covered under "Property-Specific Audits". The syntax effects are additions to productions ContextRequest and ContextAttrAuditRequest for binary, and to productions contextProperty and contextAuditProperties for text. The Chair identified a philosophical issue: that allowing packages for contexts could result in distortion of the protocol.
Brian Rosen elaborated this concern. Packages are eventually realized on terminations. If packages are also defined for contexts, it is possible to arrive at contradictions or ambiguities. He added that package designers would always have to face the decision of whether a given property belonged on a termination or on the context. Peter Blatherwick supported Brian and suggested that the existing arrangement represents a desirable separation of
concerns within the protocol.
The Chair invited Roni Even <roni.even@polycom.co.il> to give his opinion, given Roni's contributions toward application of Megaco/H.248 to MCU decomposition. Roni indicated that context packages were nice to have, but termination based solutions are also possible.
Signal On ROOT
--------------
The Chair indicated that this affects text in section 6.2.5, but has no effect on syntax. Brian Rosen expressed the opinion that this feature did not do a lot of harm, but was objectionable on the general principle that it
was not necessary.
Property-Specific Audits
------------------------
This affects sections 7.1.12, 7.2.5, 7.2.6, and 7.2.9 of the text. It results in an extensive set of additions to the syntax, to the point where this may be an issue in acceptance of the feature.
Brian Rosen pointed to this as a clear example of where the requirement is not yet evident, and where deployment experience would show the real need. Peter Blatherwick stated that the existing audit complexity is already too much for the business sets in which he had an interest, and this just worsens the problem.
Stream-Specific Topology
------------------------
This affects text in section 7.1.18 and adds a term to the TopologyRequest and topologyTriple productions for binary and text respectively. Brian Rosen expressed his continuing dislike of topology as a context property, but given its presence, supported the addition of the optional streamId parameter. He gave the example of a side conversation in a video conference, where the side conference would use audio only.
ServiceChange Announcement Of Property Change
---------------------------------------------
This affects text in section 7.2.8, adds two new reason codes (916 Packages Change and 917 Capability Change), and adds a term to the ServiceChangeParm production. The Chair saw an issue in the lack of text on how the MGC controls the volume of messaging which could be triggered by changes. Brian
Rosen suggested that this was an issue of intelligent implementation (e.g. wildcarding of terminationIds affected). The need for the feature would become more evident with deployment experience, but there does seem to be a requirement for a method to trigger audits.
Implicit Union Of Responses To Audit Of Context Properties With ALL Wildcard
----------------------------------------------------------------------------
This was introduced by text in the table of new section 7.1.19. The Chair pointed out that it is inconsistent with the operation of ALL wildcarding for terminations, and duplicates the operation of W- tagging or its binary equivalent. The meeting agreed that this innovation was unacceptable.
Explicit Limits on Transaction Pending
--------------------------------------
This affects text in section 8.2.3, the version number of the root package in Annex E.2, and introduces new properties in section E.2.1. The Chair pointed out that the changes in section 8.2.3 contain direct references to package content in the body of the specification, an undesirable situation. The meeting agreed that the proposal addresses a real problem, but there may be better ways to solve it. Alternative proposals should be offered on the list.
New Text On Profile Definition
------------------------------
The Chair pointed out that this introduces a new chapter 13 and causes the IANA Considerations chapter to be renumbered to 14. New text on profiles also appears in renumbered section 14.4. The Chair also noted an updated syntax for profile names which may have been the result of an Implementor's Guide item.
Peter Blatherwick indicated that the new text is safe and acceptable as far as it goes. Additional information should eventually be added, but this information deals with more controversial matters. He would be making further proposals on the list. Brian Rosen suggested that the additional work indeed needs to be done, but there is no rush for it.
-----
This terminated the review of specific features. Polling of opinions then took place, with the results as reported above.
Slides
Agenda
H.248 handling of dynamic assignment of AAL2 CIDs