[Megaco] Draft IETF 51 Megaco Minutes
"Tom-PT Taylor" <taylor@nortelnetworks.com> Wed, 08 August 2001 11:49 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10515 for <megaco-archive@odin.ietf.org>; Wed, 8 Aug 2001 07:49:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10766; Wed, 8 Aug 2001 07:16:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10735 for <megaco@ns.ietf.org>; Wed, 8 Aug 2001 07:16:40 -0400 (EDT)
Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10190 for <megaco@ietf.org>; Wed, 8 Aug 2001 07:15:31 -0400 (EDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f78BFR904963 for <megaco@ietf.org>; Wed, 8 Aug 2001 07:15:33 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 8 Aug 2001 07:15:43 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <PMVSH3VX>; Wed, 8 Aug 2001 07:15:46 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110514F9C2@zcard00g.ca.nortel.com>
From: Tom-PT Taylor <taylor@nortelnetworks.com>
To: 'megaco' <megaco@ietf.org>
Date: Wed, 08 Aug 2001 07:15:44 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Orig: <taylor@americasm01.nt.com>
Subject: [Megaco] Draft IETF 51 Megaco Minutes
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Media Gateway Control <megaco.ietf.org>
X-BeenThere: megaco@ietf.org
Corrections and additions welcomed ... The Megaco WG met on Monday afternoon, 6 Aug. 2001. Tom Taylor <taylor@nortelnetworks.com> 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 <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. [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 <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. [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 <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 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 taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco@ietf.org http://www1.ietf.org/mailman/listinfo/megaco
- [Megaco] Draft IETF 51 Megaco Minutes Tom-PT Taylor
- RE: [Megaco] Draft IETF 51 Megaco Minutes Martin Taylor
- RE: [Megaco] Draft IETF 51 Megaco Minutes Rosen, Brian
- RE: [Megaco] Draft IETF 51 Megaco Minutes Madhu Babu Brahmanapally
- RE: [Megaco] Draft IETF 51 Megaco Minutes Tom-PT Taylor