[MMUSIC] minutes from IETF 77 posted
Jean-Francois Mule <jf.mule@cablelabs.com> Thu, 15 April 2010 20:49 UTC
Return-Path: <jf.mule@cablelabs.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14703A6A91 for <mmusic@core3.amsl.com>; Thu, 15 Apr 2010 13:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.137
X-Spam-Level: **
X-Spam-Status: No, score=2.137 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muqVYrixUtGM for <mmusic@core3.amsl.com>; Thu, 15 Apr 2010 13:49:43 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id B11593A694A for <mmusic@ietf.org>; Thu, 15 Apr 2010 13:49:42 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o3FKnYl6025126; Thu, 15 Apr 2010 14:49:34 -0600
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 15 Apr 2010 14:49:34 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 15 Apr 2010 14:49:34 -0600
From: Jean-Francois Mule <jf.mule@cablelabs.com>
To: "mmusic (E-mail)" <mmusic@ietf.org>
Date: Thu, 15 Apr 2010 14:49:24 -0600
Thread-Topic: minutes from IETF 77 posted
Thread-Index: Acrc3SHAfBQQZn9YTr2ZM5Al/GGVDA==
Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4EDC2B2@srvxchg>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Approved: ondar
Cc: "tom111.taylor@bell.net" <tom111.taylor@bell.net>
Subject: [MMUSIC] minutes from IETF 77 posted
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2010 20:49:44 -0000
The minutes from the MMUSIC WG meeting at IETF 77 are posted at http://www.ietf.org/proceedings/10mar/minutes/mmusic.html The text version is below - let Tom and I know if we missed anything or misstated any discussion. Thank you, Tom & Jean-Francois. --- ============================================================ --- Multiparty Multimedia Session Control (MMUSIC) Working Group --- Minutes of IETF#77 MMUSIC WG Meeting --- Tuesday, March 23, 2010 - 15:20-17:20 --- ============================================================ Thank you Cullen for being the RAI AD for MMUSIC. Thank you Joerg for chairing MMUSIC for 13 years! CHAIRS: Jean-Francois Mule <jf.mule@cablelabs.com> Tom Taylor <tom111.taylor@bell.net> The MMUSIC WG met on March 23 at IETF#77. The session was attended over 50 participants. The meeting was chaired by Tom Taylor and Jean-Francois Mule. The minutes are reported by the chairs. 0. Introduction and WG progress report The IPR notice and Note Well text were presented. There was no comment on the agenda. The chairs thanked Joerg Ott for his many years of service and all WG participants gave him a round of applause. The WG progress report since IETF#76 was presented: See the new Document Tracker http://datatracker.ietf.org/wg/mmusic/ - No RFC Published since Hiroshima - In the RFC Editor queue draft-ietf-mmusic-ice-19 now in AUTH48 draft-ietf-mmusic-rfc3388bis-04 - IESG Evaluation::AD Follow-up draft-ietf-mmusic-connectivity-precon-07 draft-ietf-mmusic-sdp-capability-negotiation-12 - Publication Requested:: Waiting for AD Go-ahead draft-ietf-mmusic-rfc4756bis-06 - Ready for WGLC draft-ietf-mmusic-sdp-media-capabilities-09 (to be issued by April 19 as a new draft expected) draft-ietf-mmusic-media-loopback-12 (to be issued by April 26 as a new draft expected) draft-ietf-mmusic-image-attributes-04 (to be issued by May 10) - the following documents completed WGLC. Updates are needed: draft-ietf-mmusic-media-path-middleboxes-02 (no updates since 3/2009) - Other Drafts from the WG draft-ietf-mmusic-sdp-cs-03 draft-ietf-mmusic-rfc4566bis-02 draft-ietf-mmusic-rtsp-nat-08 draft-ietf-mmusic-ice-tcp Roni Even noted a typo in the slides presented at the meeting since the current version of sdp-media-capabilities at IETF 77 is draft-09. To conclude the WG chair report, Jean-Francois clarified the status of draft-ietf-mmusic-sdp-misc-cap-00 (see the chair's slides #9). This Internet-Draft was mistakenly accepted as a WG document without confirmation on the list. After a brief recap of the I-D history and scope, several comments were made in support of continuing the work as part of a WG item as long as the scope does not overlap with ICE for IPv4-IPv6 connection address negotiations: - Roni Even indicated support for the work and noted that the b parameter was part of the original SDP capability negotiation framework. - John Elwell, Gonzalo Camarillo, Jonathan Lennox and Cullen Jennings are in favor of the work item as long as its scope is clarified to not overlap with ICE for IPv4-IPv6 address negotiation. - Ingemar Johansson also expressed support for it There was strong support for continuing to define a capability parameter for b, i and some concerns with the ccap parameter. More discussions occurred at the end of the meeting when the document was presented, see notes below. Jean-Francois proposed the next steps: - the WG chairs will confirm the interest for a WG item to define additional SDP cap neg parameters (b and i lines) - Pending AD approval, the WG item will be chartered - Simo V. will re-submit an updated Internet-Draft as an individual submission - then the chairs will ask the list if the Working Group supports making Simo's individual submission as the WG draft. Robert Sparks speaking as the RAI AD indicated he supported this plan of action. 1. Primary SDP Capability Negotiation Drafts 1.1 SDP Capability Negotiation Draft http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-12 Flemming Andreasen presented the updates in draft-12 based on the IESG reviews. All IESG comments have been addressed, see slides 7&8 for the key changes. No questions or comments were expressed during the meeting on these changes. Flemming discussed the comments raised by Bob Gilman on the list regarding the use of acap for session level attributes (slide 9). Based on additional comments from Jonathan Lennox, there was consensus to: - not add a new attribute like scap - keep using acap - add clarifications in the I-D as part of the processing of SDP cap neg on the answering side to say that a session-level attribute not understood by the receiver should/must be ignored. There was agreement to accept the text changes on transport capabilities (see slide 10 and mailing): clarify text as suggested ("transport protocol" versus "transport protocol capability"). Additional notes re: TIAS based on a comment from Roni Even: see mailing list based on discussions held on 3/26 at IETF, it is recommended to remove the paragraph re: TIAS in SDP cap neg. Next steps: - Cullen Jennings said he was reassured that the Working Group was comfortable with the post-WGLC changes that had been made to the document. He cleared the last discuss during IETF#77. - Flemming will incorporate the changes as part of the next updates. 1.2 SDP Media Capability Negotiation Draft http://tools.ietf.org/html/draft-ietf-mmusic-sdp-media-capabilities-09 Roni Even covered the recent updates in draft-09 and mentioned the good review comments from Kevin Fleming. There were some comments to move the bcap parameter back into SDP media capability negotiations. Roni argued against: keeping bcap in a separate document allows for finer granularity in the choice of what to implement (or it would cause some additional work on option tags). The next steps for this I-D are: - an update is expected to address Kevin's comments - a WGLC will be started by April 19 if the update is posted by then, or shortly after. 2. RTSP 2.0 http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-23 Martin Stiemerling presented the ID updates for RTSP 2.0. All tickets against RTSP are closed. There were no comments on the set of changes presented (see slides for details). The issue related to the handling of media line groupings and dependencies in RFC 5583 must be taken to the list - see slide 7. It is the intent of the WG chairs to push for this document's completion before the next IETF. There was a call for several volunteers to review RTSP sections. Tom Taylor and Wolfgang Beck volunteered. The next step is to issue a 4-week WGLC (done on 3/26, WGLC ends on 4/23). 3. Secondary SDP capability drafts 3.1 draft-garcia-mmusic-sdp-misc-cap http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-03 Simo Veikkolainen presented the minor changes. There were no comments. This draft will go through WGLC once we complete the other higher priority calls. 3.1 http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-01 See minutes from the WG chair report above in this document for a status clarification on the Internet-Draft. Simo Veikkolainen presented the draft changes. Jean-Francois Mule expressed a preference for having the port number as a distinct capability parameter. Based on comments from Hadriel Kaplan and Jonathan Lennox, there was a consensus to keep the port in the ccap parameter as currently proposed unless there is a good use case for port only. As noted earlier in these notes, there were some comments about the potential use of ccap instead of ICE for IPv4-IPv6. ccap addresses a requirement to be able to negotiate alternative nettype address. This discussion point should continue on the list to seek a resolution. For example, one option might be that the updated draft calls out this particular applicability of ccap and point to ICE. 3.2 http://tools.ietf.org/html/draft-boucadair-mmusic-altc-00 http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-01 These two drafts were presented one after the other before we opened the discussion since they address the same use cases but with different methods. Mohamed Boucadair presented an alternative connectivity attribute proposed termed ALTC. This draft is an update from what was proposed in IETF#75 as draft-boucadair-mmusic-ccap. Andy Hutton presented a proposal for ICE microlite (ICE lite without connectivity checks). There were several comments made by Cullen Jennings, Jonathan Lennox, Hadriel Kaplan, and Mohamed Boucadair. - Cullen warned about the cases where IP connectivity cannot be taken for granted, in particular in IPv6 deployments. Hence the applicability of this mechanism would be mostly for walled-garden environment. ICE was designed so that UAs know that there is connectivity for the media path. - Hadriel Kaplan commented that these solutions are meant for use within a SIP Service Provider's network where there is awareness of connectivity - Jonathan Lennox asked what is the impediment to having an ICE lite implementation (just have to respond to connectivity checks?). If both sides do ICE lite, then you revert to this microlite solution. - Andy Hutton confirmed that indeed, the proposed solution were made to avoid having to respond to STUN connectivity checks - Hadriel Kaplan added that there is indeed an impact to responding to connectivity checks. - Cullen: This only works if you are in a walled garden environment. But if it is meant to change the impact on DSP resources, in fact you get no significant drop in the number of relevant audio streams. - Gonzalo Camarillo reminded the group that a decision was made to go with ICE and that these proposals keep re-hashing arguments over and over again without bringing anything new. - Hadriel Kaplan responded that the decision for ICE lite to mandate responding to connectivity checks dates back from IETF 68 and that some folks still do not want to implement a responder to connectivity checks - Jonathan Lennox commented that ccap is also part of this discussion. Perhaps adding a nettype into ICE instead of ccap would be a possibility to address the delta between ICE and ccap. There must be more justification for why responding to STUN connectivity checks is expensive. Based on the discussions, the chairs concluded that the main motivation for these two drafts is to simplify ICE lite to remove the response to connectivity checks. As was pointed out, a number of scenarios in IPv4 and/or IPv6 deployments drove the ICE design and solutions developed for walled-garden approaches may not lead to the expected results. Based on the current proposal and without further new and substantive justification, there does not appear to be any path forward for either altc or ICE microlite. The meeting was adjourned. >end.
- [MMUSIC] minutes from IETF 77 posted Jean-Francois Mule