RE: [Megaco] Draft IETF 51 Megaco Minutes

["Madhu Babu Brahmanapally" <[e-mail]>]

HI Tom,
Of the different Internet-drafts listed, which are the working group
documents??? You have added list of questions below (like the strategy for
attention ..age, priority,etc) are there any answers for those?

Regards
Madhubabu Brahmanapally

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of
Tom-PT Taylor
Sent: Wednesday, August 08, 2001 7:16 AM
To: 'megaco'
Subject: [Megaco] Draft IETF 51 Megaco Minutes


Corrections and additions welcomed ...

The Megaco WG met on Monday afternoon, 6 Aug. 2001.  Tom Taylor
<[e-mail]> chaired.  About 95 people were present.

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

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
     ftp://standard.pictel.com/avc-site/0105_Por/PL-015_H248_imp_guide.zip
  -- 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
     ftp://standard.pictel.com/avc-site/0105_Por/AnnexM4H248.zip
  -- H.248 Supplement: H.248 Packages Guide Release 1

ftp://standard.pictel.com/avc-site/0105_Por/H248_supp2_Packages_guide.zip

Work in hand:
  -- H.248 Annex M.1: Advanced Audio Server packages
     ftp://standard.pictel.com/avc-site/0103_Lau/TD-51.zip (soon to be
revised)
  -- H.248v2 (see below)
     ftp://standard.pictel.com/avc-site/0105_Por/h248v2draft.zip
  -- MCU decomposition (still in discussion stage)
     ftp://standard.pictel.com/avc-site/0105_Por/MCU_Decomposition.zip
  -- aggregate bearer load control (early discussion stage)

Ideas picked up into H.248v2:
  -- auditing single properties, events, signals and statistics (Document
AVD-2068)
     ftp://standard.pictel.com/avc-site/0103_Lau/AVD-2068.zip
  -- indicating that capabilities have changed in the Media Gateway
(Document APC-1911)
     ftp://standard.pictel.com/avc-site/till_0012/0008_Por/APC-1911.zip
  -- playing a signal on the Root Termination (Document APC-2002)
     ftp://standard.pictel.com/avc-site/till_0012/0011_Gen/APC-2002.zip
  -- 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 <[e-mail]> 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 <[e-mail]>
(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
<[e-mail]> 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.  [Brian Rosen
confirmed that this was the Megaco equivalent of BLES (Basic Loop Emulation
Signalling)]

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
	Name Pattern Package for Megaco
      November 2000
draft-bouwen-megaco-isdn-data-00.txt
	Extensions to Megaco to support Data in an ISDN D-channel
      November 2000
draft-bothwell-megaco-mftonepkgs-00.txt
	MF Tone Generation and Detection Packages
      December 2000
draft-manyfolks-megaco-caspackage-00.txt
	Megaco/H.248 Basic CAS Packages
      January 2001
draft-ietf-megaco-h248f-01.txt
	H.248 Annex F (Fax, Text Conversation, and Call discrimination))
      January 2001
draft-doyle-megaco-tonesmib-00.txt
	Tones MIB for Megaco/H.248
      February 2001
draft-rosen-megaco-atm-package-00.txt
	Megaco ATM Package
      February 2001
draft-bouwen-megaco-isdn-pack-01.txt
	ISDN Package for Megaco
      February 2001
draft-bouwen-megaco-isdn-bcp-01.txt
	Best Current Practice for Megaco-Sigtran Interaction in ISDN
Acces...
      February 2001
draft-taylor-megaco-enhalpkgs-00.txt
	Megaco/H.248 Enhanced Analog Line Packages
      April 2001
draft-ietf-megaco-mib-02.txt
	MEGACO MIB
      May 2001
draft-ietf-megaco-r2package-02.txt
	Megaco/H.248 R2 Package
      June 2001
draft-madhubabu-megaco-qospackage-00.txt
	Megaco/H.248 QoS Packages
	July 2001
draft-madhu-megaco-callflows-00.txt
	Megaco/H.248 Call flow examples
      July 2001
draft-cutler-megaco-mgc-cookie-02.txt
	MGC Cookie Package for Megaco/H248
      July 2001
draft-boyle-megaco-alerting-02.txt
	Enhanced Alerting Packages for Megaco/H.248
      July 2001
      (H.248 Annex M.3 withdrawn in its favour)
draft-boyle-megaco-tonepkgs-05.txt
	Supplemental Tones Packages for Megaco/H.248
      July 2001
	(Completed list Last Call, bounced by IESG)
draft-ietf-megaco-naspkg-03.txt
	Megaco/H.248 NAS Package
      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 <[e-mail]> 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.

[Didn't get the name] 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.  [Sorry, I missed
the first one.]  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 <[e-mail]> 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 <[e-mail]> 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 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.

Tom Taylor
[e-mail]
Ph. [phone] (ESN 396 1490)


_______________________________________________
Megaco mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/megaco