[MMUSIC] wg meeting minutes from IETF 71
"Jean-Francois Mule" <jf.mule@cablelabs.com> Mon, 14 April 2008 10:01 UTC
Return-Path: <mmusic-bounces@ietf.org>
X-Original-To: mmusic-archive@megatron.ietf.org
Delivered-To: ietfarch-mmusic-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E8A3A6A3D; Mon, 14 Apr 2008 03:01:41 -0700 (PDT)
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 A13EA28C1E9 for <mmusic@core3.amsl.com>; Mon, 14 Apr 2008 03:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.026
X-Spam-Level: *
X-Spam-Status: No, score=1.026 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 JOJJjZ+acafF for <mmusic@core3.amsl.com>; Mon, 14 Apr 2008 03:01:37 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 9F5363A67B3 for <mmusic@ietf.org>; Mon, 14 Apr 2008 03:01:37 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m3EA277p002486; Mon, 14 Apr 2008 04:02:07 -0600
Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 14 Apr 2008 04:02:07 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com)
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 14 Apr 2008 04:01:54 -0600
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6010F1F76@srvxchg3.cablelabs.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MMUSIC] wg meeting minutes from IETF 71
Thread-Index: Aca59ATN8FFtZkcZQ3aEhkmofINcLU1CkzAAG8LHtgAQAy0P8A==
From: Jean-Francois Mule <jf.mule@cablelabs.com>
To: mmusic@ietf.org
X-Approved: ondar
Cc: Joerg Ott <jo@netlab.tkk.fi>
Subject: [MMUSIC] wg meeting minutes from IETF 71
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-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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org
The minutes from the MMUSIC WG meeting at IETF#71 are below. They are also posted at: http://www.ietf.org/proceedings/08mar/minutes/mmusic.html Your comments are welcome by April 21. Joerg and Jean-Francois. --- --- Multiparty Multimedia Session Control (MMUSIC) Working Group --- IETF#71 Meeting Minutes --- Monday, March 10 2008 from 9:00-11:30 --- ============================================================ The MMUSIC WG met once at IETF#71. The meeting was chaired by Joerg Ott and Jean-Francois Mule. The session was attended by about 140 participants. Minutes reported by Jean-Francois Mule based on notes from Christian Schmidt and Jean-Francois Mule 1/ Introduction and progress report After the note well reminder on Intellectual Property, the chairs presented the agenda and a brief working group. - RFCs Published: none since Vancouver - RFC Editor Queue: draft-ietf-mmusic-ice-19 (dependencies on other drafts) - Close to Publication: draft-levin-mmusic-xml-media-control-13 - Awaiting Write-up and/or Publication Request: draft-ietf-mmusic-sdp-capability-negotiation-08 draft-ietf-mmusic-qos-identification-01 draft-ietf-mmusic-sdp-source-attributes-01 (Jonathan Lennox noted the slides omitted draft-ietf-mmusic-sdp-source-attributes-01 which had just completed WGLC) - Ready for WGLC: draft-ietf-mmusic-connectivity-precon-04.txt draft-ietf-mmusic-decoding-dependency-01.txt - Needs Update draft-ietf-mmusic-file-transfer-mech-06.txt draft-ietf-mmusic-media-loopback-07.txt (it was noted that the media loopback draft has still not been updated based on the feedback received in IETF#70, see details in the minutes). - Other Drafts draft-ietf-mmusic-rfc4566bis-00.txt (IPv6 fix in ABNF) draft-ietf-sip-dtls-srtp-framework-00.txt (noted for the SDP attributes now defined in this draft) The chairs noted the liaison statements sent by the MMUSIC working group on RTSP 2.0, see slides for details. Finally, the idea of conducting some ICE interoperability testing at SIPit22 was proposed. The objectives are to do ICE/STUN/TURN and potentially SIP outboud testing to collect feedback from the implementers. 2/ ICE TCP draft-ietf-mmusic-ice-tcp-06.txt Jonathan Rosenberg presented the main changes and open issues on ICE TCP. See draft and slides for the main changes since draft-05. The "big problems" with the current draft were then discussed. The main issue is that the recommended mechanisms in ICE-TCP work for about 45% of the cases for double NAT scenarios. This is based on the use of simultaneous opens and on the findings recorded in a paper from SaiKat (http://saikat.guha.cc/pub/imc05-tcpnat.pdf) The other problem is that the mechanism may have issues with Windows XP (some have concerns that SO support does work in XP). Different approaches for improvement were then discussed: a) Port prediction: The idea would be to add some text in the document to take into account the fact that, if you open one connection and then a second one, you normally get port+1. Comments at the mike from Magnus Westerlund and Francois Audet, and additional points made by Jonathan, the consensus was to not add port prediction as part of the ICE-TCP solution but create an informative document separate from ICE-tcp and potentially release the document with ICE-TCP. Later on in the meeting, Cullen Jennings brought up the scenario of running AJAX applications while initiating ICE and based on his testing, he was not sure port prediction would even work due to the many TCP connections. b) Support for TCP Simultaneous Open in Operating Systems Jonathan called for volunteers to run some tests on OSes to check S-O support and verify draft mechanisms. c) TCP over UDP: Jonathan proposed to use a radical approach in ICE-TCP: run ICE-TCP over UDP. The success rate for a UDP connection is good with ICE. With TCP over UDP, you get the best of both worlds, e.g. congestion control. Discussions followed with comments at the mike from several folks (Remi D-C, Philip Matthews, Dave Oran, Cullen Jennings, Adam Roach, Ekr, Rohan and others): - some raised questions and doubts about what this proposal was (is it TCP over IP over UDP, or TCP over UDP - Dave Oran) - Philip Matthews indicated that behave-tcp does recommend how to fix this in NATs and wondered if the solution was in fact dependent on how NAT vendors do comply with those guidelines. Cullen indicated that the problem is the deployment of current NATs. Jonathan stated this was a multi-year problem. - this solution would likely be used for p2pSIP and 3GPP - real data on how this works on NATs would be great - Adam Roach warned about trends and not describing things that work today but won't work anymore when the document goes RFC. - how would implementers do this (Ekr)? - there are mechanisms for UDP encapsulation of other protocols [e.g. IPsec] and there might be interest in TSVG to define a more generic solution (Magnus W) - this idea could be part of the solution, this is what the HIP wg and some drafts in p2psip have been looking at. More data is required and there was no consensus. Cullen Jennings <AD hat on> concluded that MMUSIC is not the right working group; the transport area and TSVWG is where discussions should happen. The rest of the comments were centered around what to do with the document based on the "big" problems. Based on comments, folks expressed interest in 3 options: - Continue with S-O as currently defined. The solution works (pending confirmations on the S-O use on certain OSes), and requires TURN relay for roughly 50% of the use cases. P2PSIP may be a customer for this solution. - Remove S-O from the solution: this makes it easier to implement and will result in more relay use. - Select a radical approach like the one proposed in this meeting. There was consensus to continue working on this draft but no consensus on what the best approach is based on the 3 above options. 3/ NICE draft-rosenberg-mmusic-ice-nonsip-00.txt Jonathan Rosenberg presented a new draft, Non-SIP usage of ICE. A few comments were received about additional motivations for NICE (RTSP, Jabber/jingle). The chairs asked where this work should be done, is MMUSIC the right place? Cullen Jennings mentioned that the IESG has had discussions related to the rechartering of MMUSIC: ICE is tied to SDP so MMUSIC is the right home but the transport of ICE in more protocols is subject to discussions. AD discussions take place between Magnus and Cullen. Bruce Lowekamp indicated he has implemented ICE for P2PSIP. He wondered how many people who need something like NICE don't already have an implementation. Therefore, simplifications for NICE might make it harder to implement than staying close to the original ICE. Bruce raised another comment: it is hard to predict what new protocols will need from the ICE spec and his preference is to not do a sub-set of ICE. This was also the opinion of Ekr, Philip Matthews, Remi D-C, and Magnus. Some protocols may use subsets but these may not be aligned and the NICE spec may not be the right place to make this choice for other protocols. In summary, the group discussed several questions related to NICE: - is it worth having a generic ICE as NICE intends to spec out - if yes, should it be all of ICE or a subset? - who are the customers of NICE and where should this work be done. There was no consensus on whether this work is really needed and comments were between: a) no need for this work, do ICE and b) do this work on NICE but no subset. 4/ SDP media capabilities Negotiation draft-ietf-mmusic-sdp-media-capabilities-03.txt Roni Even covered the last changes and open issues in draft-03 of SDP media capability negotiation. Roni acknowledged the work done by Bob Gilman in particular (Bob did not attending the meeting). Note that about 5 to 7 people had read the new revision of the draft. Christer Holmberg asked if the draft needs to support the grouping of media lines/media attributes. This is an open question: do we need to address regular grouping in this draft? More reviewers and feedback are requested. Philip Matthews indicated that a group of folks in Avaya is interested in this work. Henry Sinnreich wondered if this draft limits the adoption of new codecs due to its complexity and the coupling of codec & SDP descriptions. Joerg and Magnus addressed the comment: signaling the codec parameters do not prohibit codec creativity and you still need an RTP profile definition. Miguel Garcia found a nice applicability of this draft so this I-D is solving some problems and he would like to see this I-D progress. Ingemar Johannson commented that he would like to see more rules for constructing capability attributes in SDP (Roni's last bullet on slide 6). The chairs called for additional reviewers to send comments to the list. 5/ RTSP 2.0 draft-ietf-mmusic-rfc2326bis-17.txt draft-ietf-mmusic-rtsp-nat-06.txt draft-ietf-mmusic-rtsp-nat-evaluation-00.txt 5.1./ draft-ietf-mmusic-rtsp-nat-06 Magnus Westerlund presented the recent changes in the RTSP 2.0 NAT draft (draft-ietf-mmusic-rtsp-nat-06.txt). A NAT traversal solution is needed for RTSP with use cases of clients and/or servers being behind NATs. Jonathan Rosenberg noted that the D-ICE solution proposed in the draft is some kind of ICE-lite with trigger checks (see draft and slides). There were some discussions around RTSP re-setup and ICE restarts. Jonathan noted that ICE restart provides continuity and wondered about the need to create a new ICE exchange. It could affect client behavior. More discussions are needed on the list. Remi asked about the use cases for re-setup: roaming? There is a potential use case if the client moves from one interface to another. Magnus asked if this approach was a good one to use. Now is the time to send feedback. Jonathan asked why regular nomination should be used in a core re-setup to provide continuity? He does not see what benefits this is bringing because you would not be able to re-use the ICE stack. Remi asked what would the use case could be for not using RTCP mux? Given that the other end implements ICE, why not implement RTCP mux? This would have fewer problems. Magnu answered that there are a few cases, for example, the delivery of media behind a NAT and there are different RTP and RTCP streams. Jonathan Rosenberg added another case if for layered codecs across ports but current ones like SVC do not work that way. Philip Matthews commented that this is an example for ICE usage for a certain protocol. There is a need to come up with a more general solution. Bill commented that we need to support components. May be FEC is a candidate for other types of components? 5.2/ RTSP 2.0, draft-ietf-mmusic-rfc2326bis-17.txt Martin Stiemerling presented a brief status report on the changes in draft-17 of RTSP 2.0. There is a proposal to add semantics for an END_of_STREAM indication. Martin and Magnus are the two principal contributors and the working group does not seem to review or comment. More interested folks are needed to move this work item forward. 6/ RTSP and SIP draft-whitehead-mmusic-sip-for-streaming-media-03.txt The draft on Media Playback Control Protocol Requirements was presented next by Sam Ganesam/Xavier Marjou. Magnus indicated that there is already work done in TISPAN and may be other standards organizations on this. Magnus believes it would be better to do a solution in IETF as a complement to regular RTSP. Jonathan Rosenberg commented that he is still unconvinced and more work is required on the use cases (use case #3 seems like an RTSP extension, the first 2 use cases are where RTSP does not work). He asked if there were use cases compelling enough to motivate the work and wondered if the first case really requires streaming control. There are relations to SIP. It would be the right approach to identify, how SIP and RTSP can work together. There was a discussion on whether the individual SIP TOTE draft was a potential solution. Jonathan clarified that the ID does not intend to do that. Martin S. commented that we should investigate how SIP and RTSP can work together. Dave Oran proposed to characterize the problem of overlap in in-session control protocols better. The presentation concluded with no consensus to work on this and participants requested more list discussions on the "real-world" "concrete" use cases and related requirements. 7/ SDP DSCP Attribute draft-polk-mmusic-dscp-attribute-02.txt James Polk presented an update of the DSCP attributes in SDP. Dave Oran raised the issue of where the decisions should be made for the DSCP code points, is it layer 3 and IP or layer 7? The issue raised by Dave is putting bits at layer 3 in layer 7. Additional comments were made by Henry Sinnreich, Cullen Jennings, Magnus W and Brian Rosen. Brian summarized the comments by indicating that the problem should be explored before finding out the solution. We might need to look back at what needs to be communicated by whom. 8/ Signaling media decoding dependency in SDP draft-ietf-mmusic-decoding-dependency-01.txt Remi D-C made a minor comment on the values used for payload types (may be a bit big numbers for payload types). If extensibility is needed, an extension mechanism should be defined. Magnus added that the ABNF needs some work to add extensibility and a few cleanups. Stefan Wenger indicated that new text should be inserted to specify what is required to add an extension. There was wg consensus to go to WGLC with the upcoming revised ID. 9/ SDP Grouping Issues draft-begen-mmusic-fec-grouping-issues-00.txt Ali Begen covered a few SDP grouping issues based on the FEC work. RFC3388 contains a restriction related to the rule for grouping: an "m" line identified by its 'mid' attribute MUST NOT appear in more than one "a=group" line using the same semantics. It was introduced, because, there was no use case known at the time and to keep the solution simple. There was no objection to remove the restriction in RFC3388 and update the RFC. As part of the discussion, the following comments are noted: - Jonathan Lennox indicated that the source attribute defines grouping to the source level so we might want to look if this problem applies to the source-specific SDP draft too. - Joerg clarified the needs to keep implementers who have done RFC 3388 happy. Dave Oran indicated that there is some implementations of RFC 3388 but there does not seem to have any dependence on the restrictions in the RFC 3388. - Gonzalo Camarillo confirmed that as he recalls, the limitation was due to a scope limitation more than anything else. There was WG consensus to revise RFC 3388 to remove this restriction. The chairs will post a note on the list though. We ran out of time. The chairs asked if folks were willing to stay. The last two presentations were done with only about 50% of the working group participants in the room. 10/ SDP ptime attributes draft-garcia-mmusic-multiple-ptimes-problem-02.txt There were questions raised on whether MMUSIC is the right place for this draft. Based on comments from Christer Holmberg and Joerg, it is recommended that this draft be discussed in AVT, at a minimum to ask for input and opinions. It was commented that the draft has developed in the right direction in giving guidance to implementers. More list traffic is required on this draft. 11/ SDP for circuit-switched media draft-garcia-mmusic-sdp-cs-00.txt Miguel Garcia-Martin presented the motivations for defining new SDP attributes for circuit-switched media. Christer Holmberg commented that there could be use cases for these. Christer brought up an issue which is not specific to this draft but to the capneg draft. The offer/answer changes the c line between the offer/answer and this could cause some problems. Joerg commented this is not related to this draft, same issue with IPv4 and IPv6. There was support stated in favor of the draft and what the authors are trying to achieve. Further list discussions is required on this draft to progress it. 12/ SDP for Collaboration Applications draft-garcia-mmusic-sdp-collaboration-00.txt This draft was not covered due to time limits. The meeting concluded. > end. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] wg meeting minutes from IETF 71 Jean-Francois Mule