2.8.7 Media Gateway Control (megaco)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-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

Mar 00

  

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

Apr 00

  

Close Working Group

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

The Megaco WG met on Monday afternoon, 6 Aug. 2001. Tom Taylor (taylor@nortelnetworks.com) chaired. About 95 people were present.

1. Agenda Bashing
==============

Proposed Agenda (Posted to list 30 July 2001)

1. Agenda bashing (2 minutes)

2.Megaco Status (15 minutes)
a. IETF activity
b. SG 16 activity
Includes discussion of Packages Guide supplement
c. SG 11 activity
d. Other

3. Initial work items under re-charter (30 minutes)
See list of current drafts at the end of this note.
Discussion can include further work items which should be undertaken.
Should get some idea of priorities and schedule out of this discussion.

4. Megaco and MPLS (5 minutes)

5. Scripting involving multiple endpoints (10 minutes)
(has relevance to IN)

6. Profiles (5 minutes)

7. MG and MGC state machines for control associations (10 minutes)

8. H.248v2 discussion (30 minutes)

Spare (20+ minutes)

The Chair proposed and the meeting agreed that the published agenda be accepted, with the change that H.248v2 discussions be moved up to follow the discussion of WG work items going forward.

2. Review Of Status
================

Tom Taylor presented a review of Megaco/H.248 status in the IETF, in Study Group 16, and elsewhere. His charts are reproduced here:

(Begin charts)

Megaco IETF Status
------------------

Re-charter: will happen. Emphasis on MIB, packages, joint work with SG 16 on H.248v2.

Drafts in progress: 18 drafts, as per list below. There has been limited movement in progressing them: do we need performance standards for management?

List activity: mostly devoted to main protocol. Continuing accretion of Implementor's Guide items. Use of ServiceChange a frequently recurring topic.

MIB: draft-ietf-megaco-mib-0x.txt recycled to provide a coherent view. Some issues have been raised since it was published. Matt Holdrege's long list of open items at IETF 49 is only partly answered. The Chair noted that the editor, Michael Brown, is no longer with Nortel and may be unable to continue the work. Volunteers to help can contact the Chair.

CAS: draft-manyfolks-megaco-caspackage-00.txt was put together by a design team in January. We were waiting for draft-ietf-megaco-r2package-02.txt before moving forward, with the intent of making sure they were well integrated. Discussion is in progress between the R2 authors and the CAS team on how the packages fit together.

draft-boyle-megaco-tonepkgs-05.txt: contains a number of packages that started life in an I-D but got taken into Q.1950 (BICC vertical interface). It also contains a few new packages. It passed Last Call and was submitted it to the IESG. The IESG rejected it because they were concerned about the confusion that might be caused by publishing a document which mixed ITU material with purely IETF material. Chair's proposal: break into two documents, with one making clear its propagation of portions of Q.1950. [In subsequent discussion Scott Bradner clarified that the problem wasn't simply the mixing of sources, but also the fact that the document took some of the material from Q.1950 Annex A and not all of it.]

ATM: the SDP for ATM has become an RFC. Brian Rosen contributed draft-rosen-megaco-atm-package-00.txt.

draft-boyle-megaco-alerting-02.txt: is the result of a compromise to meet European requirements. This compromise averted collision between material submitted to SG 16 and material submitted to IETF. The proposed H.248 Annex M.3 was withdrawn in favour of IETF work.

NAS: draft-ietf-megaco-naspkg-03.txt was recently recycled after receiving WG Last Call comments last November. draft-taylor-mmusic-sdp-tdm-00.txt was submitted to MMUSIC to provide missing bearer capabilities. This draft also has potential use in SIP control of TDM circuits. We need to register several new MIME media subtypes to complete the work.

Study Group 16 Status
---------------------

Recently approved:
-- June 2001 version of H.248 Implementor's Guide

-- H.248 Annex L: Error Codes and ServiceChange Reasons
ftp://standard.pictel.com/avc-site/0105_Por/H248_Annex_L_consent.zip
-- H.248 Annex M.2: Media Gateway Resource Congestion Handling Package
ftp://standard.pictel.com/avc-site/0105_Por/H248_annexM2_Load_Control.zip
-- Annex M.4 - Interworking between H.324C and H.323

-- H.248 Supplement: H.248 Packages Guide Release 1

Work in hand:
-- H.248 Annex M.1: Advanced Audio Server packages

-- H.248v2 (see below)

-- MCU decomposition (still in discussion stage)

-- aggregate bearer load control (early discussion stage)

Ideas picked up into H.248v2:
-- auditing single properties, events, signals and statistics (Document AVD-2068)

-- indicating that capabilities have changed in the Media Gateway (Document APC-1911)

-- playing a signal on the Root Termination (Document APC-2002)

-- preventing infinite retransmissions of TransactionPending
-- New ContextAttributeDescriptor to hold context properties, which can be defined in packages
ftp://standard.pictel.com/avc-site/0105_Por/DC-xxx_Context_Property_v2.zip

Next meetings:
-- Rapporteur's meeting, Santa Barbara CA, 24-28 September
-- anyone can attend (theoretically needs Rapporteur's invitation)
-- objective is to move documents along in preparation for Feb 2002 approval
-- full SG 16 meeting Feb 2002, restricted to ITU-T members

(End charts (for the moment))

At this point Brian Rosen (Brian.Rosen@marconi.com) noted the need for better information flow between Study Group 16 and Megaco. Study Group 16 has given final approval to a number of items which should have been reviewed by the Megaco WG first. Glen Freundlich (ggf@avaya.com) (Rapporteur Question 3 in Study Group 16, which deals with H.248) noted that other groups besides Study Group 16 are creating Megaco packages. The IETF doesn't have to bless every package. Brian expressed the view that the Study Group 16 work is different because it is covered by specific agreement between the ITU-T and the IETF. Tom Taylor noted at this point that the Study Group 16 documentation is open to Megaco with one specific exception: the Delayed Contributions into formal Study Group 16 meetings. It would be good to have some arrangement whereby these could also be made available to IETF members. Glen Freundlich suggested that the workaround was for the authors to supply informal copies which could be made available to Megaco members.

Brian returned to his point that Megaco needs to process and review all the Study Group 16 work. We need to settle whether we publish all the Annexes as RFCs. Do we make them all Standards Track? What do we do if we have disagreements? Tom stated his concern that we might have to publish all the Annexes to maintain a precedent set up by the initial agreement with Study Group 16 granting us free access to them. Flemming Andreasen (fandreas@cisco.com) expressed strong disagreement with the thought that they should all be Standards Track: we should apply our judgement to decide in each case.

Tom pointed out that the reason for publishing Annexes as RFCs was to make them available to non-ITU members. He asked how many people had difficulty getting access to ITU documentation. One person raised his hand (but there are undoubtedly others).

Glen Freundlich noted that three of the four most recent Annexes to H.248 have actually been discussed in Megaco. He accepted part of the responsibility for keeping Megaco in the loop.

(Resume charts)

SG 9 (on behalf of cable industry):
-- earlier approved NCS (variant of MGCP) as line control standard
-- will allow H.248 as well as TGCP (another MGCP variant) for trunk control

SG 11:
-- was due to complete approval of BICC Call Bearer Control (CBC) protocol (Q.1950) in July
-- Still working on package for remote control of Signal Processing Network Equipment (SPNE)
-- proposes joint study of end-to-end QOS signalling (recall note to list)

ATMF:
-- Source of the I-D draft-taylor-megaco-enhalpkgs-00.txt. [Martin Taylor subsequently pointed out that the work began in the ATMF, but is now a draft more broadly inclusive of features needed for control of analogue lines. See his note to the Megaco list, topic "Draft IETF 51 Megaco Minutes", sent Wednesday 8/15/2001 4:38 PM EDT. See also Brian Rosen's note in the same thread, sent Friday 8/17/2001 2:19 PM EDT.]

3GPP:
-- Has registered a bunch of packages with IANA

(End status charts)

3. Working Group Priorities
========================

Tom Taylor presented a series of charts listing current Megaco drafts along with their latest publication dates)

(Begin charts)

draft-rosen-megaco-namepatterns-00.txt

November 2000

draft-bouwen-megaco-isdn-data-00.txt

November 2000

draft-bothwell-megaco-mftonepkgs-00.txt

December 2000

draft-manyfolks-megaco-caspackage-00.txt

January 2001

draft-ietf-megaco-h248f-01.txt

January 2001

draft-doyle-megaco-tonesmib-00.txt

February 2001

draft-rosen-megaco-atm-package-00.txt

February 2001

draft-bouwen-megaco-isdn-pack-01.txt

February 2001

draft-bouwen-megaco-isdn-bcp-01.txt

February 2001

draft-taylor-megaco-enhalpkgs-00.txt

April 2001

draft-ietf-megaco-mib-02.txt

May 2001

draft-ietf-megaco-r2package-02.txt

June 2001

draft-madhubabu-megaco-qospackage-00.txt

draft-madhu-megaco-callflows-00.txt

July 2001

draft-cutler-megaco-mgc-cookie-02.txt

July 2001

draft-boyle-megaco-alerting-02.txt

July 2001
(H.248 Annex M.3 withdrawn in its favour)

draft-boyle-megaco-tonepkgs-05.txt

July 2001

draft-ietf-megaco-naspkg-03.txt

July 2001
(Partly through WG Last Call)

Some Questions

Are there drafts in this list which are NOT suitable Working Group work items?
-- are there principles we can use to decide?

What's missing? Should some other drafts be started and added to the WG work load?

How do we decide which items get earliest attention?
-- by age? by degree of activity?
-- whatever rule we use should allow the odd justifiable exception

What is the longest a Working Group work item should sit without visible activity before:
-- it is prepared for Last Call, or
-- it is dropped from the charter?

(End charts)

Peter Blatherwick (Peter_Blatherwick@Mitel.COM) began discussion by suggesting that Megaco provide an organized view of outstanding drafts, including milestone dates, in the same way SIP does now. Scott Bradner commented that official Working Group work items should be listed separately from individual submissions.

Another person commented that priority should be given to core rather than peripheral issues. Peter Blatherwick agreed, with the name pattern draft as an example of a core item. He would also like to see more progress on the line-related packages. Scott Bradner pointed out that the charter will say what we should be working on. There may be a mismatch in scope between existing drafts and the related work items, implying that the drafts have to be revectored.

4. H.248v2
=======

Tom Taylor presented one chart to initiate this discussion

(Begin chart)

H.248v2 will create a document which:
-- merges the Implementor's Guide into the main standard
-- incorporates new features into the main protocol while preserving
backward compatibility

Questions to be answered:

+ What is the document approval process?

+ When is the content freeze date for new features?

+ What limitations will be applied to the scope of new features?

+ How do we ensure a steady flow of communications between SG 16 and Megaco?

(End chart)

Glen Freundlich began the discussion by making two points. The first is that Study Group 16 is driven by the contributions of its members. The second point was that the target approval date of February 2002 is a proposal, not so far opposed in Study Group 16. It would be set back if resistance to the current date became apparent. As to process, the ideal would be that the input to the ITU-T decision process had already been approved by the IETF. We need to focus on the communications between the two groups to approach this ideal. Measures like having a single editor might help.

Brian Rosen remarked that Megaco/H.248 does not yet have deployment experience. It is better to clean up the protocol and add the needed packages in the nearer term. February 2003 would be a more appropriate date for H.248v2. The currently proposed features (see relevant status chart above) are optimizations. Ian Rytina (ian.rytina@ERICSSON.COM.AU) said that it is entirely appropriate to advance H.248 in Study Group 16, and that February 2002 is a resonable date for version 2.

Brian Rosen expressed a desire to take Megaco to Draft Standard status. The question to consider in moving forward is whether we are stabilizing or diverging (like SIP). He also noted the potential loss of features under the interoperability rules if we went to draft. Minimizing this loss is one incentive to delay going to a second version. Tom Taylor noted that the new features accepted in Study Group 16 would force a recycle to Proposed Standard. Scott Bradner clarified: advancement to Draft requires no non-compatible changes.

Roni Even (roni.even@POLYCOM.CO.IL) noted that he had introduced proposals for decomposing multimedia MCUs, originally based on termination packages. The experts at SG 16 had rejected his approach in favour of new context properties. He now had a dependency on H.248v2 to complete the work.

Scott Bradner pointed out that the WG had no basis on which to make a decision about moving forward with H.248v2 until they had a draft to look at. There is an ACTION on the Chair to provide such a draft.

5. MPLS Transport
==============

Tom Taylor presented an initial chart:

(Begin chart)

For the MPLS-knowledgable to answer: will there ever be a situation where the MG has to explicitly select an MPLS path?

If the answer is YES, then:
-- we have to add MPLS-awareness into SDP just as we had to add ATM- and TDM-awareness
-- we have to update Annex C in step.

Proposal for SDP (Christian Groves):
-- define a single new attribute: pkgitem
-- define syntax: "a=pkgitem:" DQUOTE (pkgname)"/"(pkgpar)"="(value) DQUOTE
-- define new Local and Remote properties in packages.

Saves having to go to mmusic for our transport-related extensions.

(End chart)

Brian Rosen said he liked the thought of having the MG allocate MPLS paths directly, but had been advised that this was a "layer violation". He drew Scott Bradner into the discussion. Scott said that in his view there was no layer violation. Parenthetically, MPLS pollutes everything it touches. He suggested that it might be premature to embark on such an activity because MPLS is a bit fluid.

6. Scripting Involving Multiple Endpoints
======================================

Again Tom Taylor presented a preliminary chart:

(Begin chart)

Background:
MGCP connection model automatically allows event on one termination to trigger action on another (from Megaco point of view). We lost that when our connection model decoupled the sides of a connection. Result is that round-trip to MGC is required to propagate (e.g.) fact of on-hook while operation is in progress on other termination.

Question: do we care?

If we care:
-- what are the requirements for reflex actions across a context?
-- impact of multiple streams
-- impact of topology

(End chart)

Tom noted that this topic had been suggested for discussion on the basis that support of the IN might require it. Brian Rosen responded that he has dealt with this question in a few discussions, but as yet no one had identified a situation where multi-termination scripting was necessary. Peter Blatherwick remarked that it is incredibly complex to define scripting. We should not do it if we don't have to. No one in the meeting could think of a specific IN requirement.

7. Profiles
========

The Chair asked Peter Blatherwick to introduce the issue. Peter pointed out that profiles had been taken off the table for v1. There are two outstanding work items: providing a full description of their use, and possibly adding protocol.

Brian Rosen affirmed that this is the right time to tackle the topic. There is experience -- the MSF has defined some profiles. The only protocol issue is whether more than one profile can be offered in a ServiceChange. He suggested we take the matter to the list, giving it a high priority. Peter added that he saw an Informational RFC on profile use as an official WG work item. Scott Bradner suggested that a one-paragraph description of the work be drafted for possible insertion into the charter. ACTION: Brian and Peter volunteered to draft the paragraph.

8. Use Of ServiceChange
====================

The Chair noted that issues around the use of ServiceChange and ServiceChange properties had arisen repeatedly on the list. Brian Rosen agreed that at a minimum we need more text to clarify this usage. He was not sure whether protocol work was also needed, but if so, it was a v2 work item. He noted that we had always intended to work on more robust failover in v2.

The Chair advised the meeting that a draft on ServiceChange usage had been written by people from Hughes and would be submitted shortly.

9. Miscellaneous Discussion
========================

Having reached the end of its agenda, the meeting returned to some of the previous topics.

a. H.248v2 Reprise
---------------

The question was asked: what is driving v2 work at this point? The Chair pointed out one motivation: integration of the Implementor's Guide corrections into the main document. Beyond that a review of the additions so far accepted by SG 16 did not in itself reveal clear deficiencies in the protocol, except possibly in connection with MCU control. Roni Even suggested we had a case of philosophical differences, with two possible solutions to the problem. One of these solutions might be accommodated within the existing protocol.

b. Work Program
------------

Peter Blatherwick suggested that we review the outstanding drafts to decide which should be advanced. As a first item, was there an objection to moving the name pattern draft forward? When the Chair put the question to the meeting, no objection was raised. Brian Rosen informed the meeting that he had one or two small changes to make and would recycle the draft. We will hold list Last Call when the new version is available.

Regarding the tones draft which was rejected by the IESG: a new draft should include all of Q.1950 or none of it.

Peter Blatherwick expressed a wish to see most of the Annexes turned into Standards Track RFCs. Scott Bradner suggested that one-page drafts referring back to the ITU-T standards might be all that is needed. He reported that the ITU-T has a new policy, whereby up to three documents per year may be sent to any one E-mail address at no charge. Thus availability of the ITU-T material to IETF memebers is less of an issue than it used to be.

Slides

None received.