[MMUSIC] IETF 75 MMUSIC meeting notes posted
"Jean-Francois Mule" <jf.mule@cablelabs.com> Wed, 16 September 2009 03:12 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 B5FE23A67F8 for <mmusic@core3.amsl.com>; Tue, 15 Sep 2009 20:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.18
X-Spam-Level:
X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001]
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 P7Im5bm8TmJ1 for <mmusic@core3.amsl.com>; Tue, 15 Sep 2009 20:12:08 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 48E3C3A681C for <mmusic@ietf.org>; Tue, 15 Sep 2009 20:12:08 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id n8G3CtrF010759 for <mmusic@ietf.org>; Tue, 15 Sep 2009 21:12:55 -0600
Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 15 Sep 2009 21:12:55 -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
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA367B.95BFD7F3"
Date: Tue, 15 Sep 2009 21:12:55 -0600
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601ABA112@srvxchg3.cablelabs.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IETF 75 MMUSIC meeting notes posted
Thread-Index: Aco2e5WqFJnVGG4VREuPnSKrN9+rIw==
From: Jean-Francois Mule <jf.mule@cablelabs.com>
To: mmusic@ietf.org
X-Approved: ondar
Subject: [MMUSIC] IETF 75 MMUSIC meeting notes 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: Wed, 16 Sep 2009 03:12:10 -0000
See http://www.ietf.org/proceedings/75/minutes/mmusic.html and below: Send any comments or corrections to the list. Regards, Joerg and Jean-Francois. --- --- ============================================================ --- Multiparty Multimedia Session Control (MMUSIC) Working Group --- DRAFT Minutes for IETF#75 MMUSIC WG Meeting --- Thursday, July 30, 2009 - 9:00 to 11:30am --- ============================================================ CHAIRS: Joerg Ott <jo@acm.org> Jean-Francois Mule <jf.mule@cablelabs.com> The MMUSIC WG met on July 30 at IETF#73. The session was attended by 57 participants. The meeting was chaired by Joerg Ott and Jean-Francois Mule and the minutes are reported by Jean-Francois. 1/ Introduction and progress report Joerg and Jean-Francois presented the progress since the last meeting. - 3 RFCs were published since March 2009: RFC 5547, RFC 5576 and RFC5583 - ICE is still in the RFC Editor queue and publication has been requested for connectivity preconditions and RFC 3388bis. - The capability negotiation draft received comments from IESG and needs revision. - The media path guidelines for middleboxes WGLC is complete and the ID needs an update - 3 I-Ds are in the queue for WGLC request (RFC4756bis, sdp media cap and image attributes after an udpate) - ICE TCP has not been updated and Simon Perreault who is the new editor plans to issue a revision after IETF. - Hadriel Kaplan volunteered to work with the authors of the media loopback ID to complete it and go to publication request by October 2009. See slides for more details. There were no comments or questions from the Working Group on the progress report. 1) RTSP-related Drafts 1.1. RTSP 2.0 http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22 Magnus Westerlund presented an update on the latest RTSP draft. See slides for details on the changes. Two versions of the Internet-Draft were posted between IETF 74 and IETF 75. The one open issue is to update the "changes since RFC 2326" section. The authors believe the document is in good shape for working group last call. There were no comments on the plan to launch WGLC in September for 4 weeks. The following people volunteered to be reviewers during WGLC: Ingemar Johansson, Jeff Goldberg, and Ye-Kui Wang (thank you). 1.2 RTSP NAT http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-08 Magnus Westerlund presented the draft updates on RTSP NAT. The document received feedback from implementers. There was consensus to go to WGLC after RTSP/2.0. 1.3 Fast Content Switching with RTSP 2.0 http://tools.ietf.org/html/draft-einarsson-mmusic-rtsp-macuri-02 http://tools.ietf.org/html/draft-lohmar-mmusic-rtsp-fcs-00 Thorsten Lohmar presented RTSP extensions to support Fast Content Switching. There are existing extensions defined in 3GPP for RTSP 1.0 and the goal of this work would be to define extensions in IETF for RTSP 2.0. Joerg Ott asked how RTSP session parameters could be reused across streams in the context of multicast. Thorsten answered that the scope of the current ID is unicast and with unicast, channel change is faster if you use these RTSP extensions. On slide 7, Joerg commented that the proposed solution presented in the examples looks "unhealthy" because various feature parameters including SDP are put into one header line (it seems like the DESCRIBE message is encapsulated in PLAY). Thorsten indicated that this point was discussed in the past and given the number of SDP descriptions for video services like YouTube, the current direction is to not do DESCRIBEs to reduce the number of transactions. Jean-Francois noted that the examples show the 3gpp tags and their particular syntax. It would be benefitial to discuss the parameters required for fast channel switching first, then figure out how to convey them in the protocol. In the jabber room, Martin Stiemerling asked if the proposal is aligned with the RTSP/2.0 state machine where you can use PLAY on new URIs without SETUP first. Based on questions from Wolgang Beck (via jabber), there was a discussion on whether this work is required given the client has to wait for an I-frame for the new content channel. Brian Rosen responded that there is work in AVT in reducing the delay related to the I-frame and there is enough experience in 3GPP that this mechanism actually helps. Ye-Kui Wang indicated the issues related to the I-frame may be different than what is being addressed in AVT since the action is done by the server (the server may know where the I-frame is before starting channel change). Joerg pointed out that there is an assumption in the mechanism that the new SDP offer is going to be compatible (no DESCRIBE fetching). It implies that the client makes some assumptions. Thorsten agreed this is an open issue, even though the server could know what the client can support. Joerg added that if the server has multiple codec options, a SETUP might help for the client to choose from. Jeff Goldberg asked how this mechanism works with the RTSP NAT draft given the exchanges. We need to consider how the two mechanisms could work together. Thorsten indicated that there should be little impact but further analysis is indeed required. In summary, based on the discussions at this IETF#75 meeting, there is WG interest in progressing this work on the mailing list and see the Internet-Draft updated to address the feedback. 1.4 SIP-SDP Overlap with RTSP http://tools.ietf.org/html/draft-lindquist-mmusic-sip-rtsp-00 Jan Lindquist presented a draft on how the session related information could flow between SIP and RTSP session controllers. Jan indicated that ETSI TISPAN, 3GPP and the Open IPTV Forum are working on this topic. Hadriel Kaplan asked what "session management protocol" refered to in the slides and whether it could be somethink like SIP without media description. Hadriel asked whether this work proposal should potentially go to DISPATCH given it goes beyond MMUSIC. Hadriel expressed support for this work. Tom Hiller expressed some concerns about the claim that OMA is working on this topic. Tom said that this was discussed in OMA and rejected. Tom indicated that RTSP should be left intact given the client implementations. Joerg suggested that Tom puts an email to the mmusic list to explain what OMA did to solve the requirements. Xavier Marjou expressed support for this work. There are people that use both SIP and RTSP and there is no work in IETF to make the 2 protocols work together. It would be good to take on this work. The chairs polled the room for interest in this work (13 peple interested, 5 opposed to do work on this). Dave Oran added 3 options that could get support in MMUSIC: a) stop RTSP 2.0 and step back to redefine it to meet the goals defined here b) designing new media control protocol inside a SIP session (put the PLAY controls in SIP) c) create an MRCP sub-set All of these would allow to use SIP to do media streaming server operations. Jan indicated this is good input. Gonzalo Camarillo agrees with Hadriel that this might be best discussed in the DISPATCH working group. The chairs concluded that more discussion is needed on this topic. 2) SDP Attributes 2.1 SDP Connectivity Capability (CCAP) http://tools.ietf.org/html/draft-boucadair-mmusic-ccap-00 Hadriel presented an Internet-Draft to solve some IPv4-IPv6 interworking issues. There were questions and comments about the characterization of the problem (slide 2). Cullen Jennings and Francois Audet commented that there is an implication that there are a lot of things broken, and the problem statement is exagerated. Cullen Jennings, it was pointed out that the WG decision to fix IPv4-IPv6 connectivity declarations in SDP was the ICE protocol. Xavier Marjou would like to do IPv6 in the very short-term with this draft, and perhaps this is an informational or experimental document, not standard-track. There were several questions and comments on the subsequent slides: - the c line in O/A does not need to have the same address family (Roni Even) - you have to do a re-INVITE since the answer should have the same c line (Dan Wing) - Capabiliy negotiation is "messy" and having two mechanisms would be even worse - the garcia draft to negotiate c lines is a potential solution (Christer Holmber). The garcia draft has been proposed as a WG item based on IETF#74 (Roni). - This is a special case of capability negotiation (Roni Even) but capneg is too complicated (Hadriel Kaplan) - This problem could be addressed based upon the garcia draft (Simo) - We always start out simple and it gets complex. We will need to implement all of this in the end process: we did discuss and agreed on a solution (Francois Audet) - The motivation is to do a "super-ice-lite mechanisms" - ICE-like negotiation without the connectivity checks. - This is a strategic direction we make for the wg (Gonzalo) - We should spend energy on solving generic SDP capability negotiation (Ingemar) There were additional comments from Roni, Jonathan Lennox, Derek, John Elwell and Christer Holmberg. In summary, the discussions asked: - how difficult would the solution be if it were to rely or build on capneg and draft-garcia? - how different is it from a solution re-using ICE? There was no consensus on this draft but many questions and comments recommending to re-use the tools that are available in MMUSIC including SDP Cap Neg and its extensions like the garcia draft for the c= line, ICE and new semantics to make this work. 2.2 SDP Attribute for Maximum Media Sources http://tools.ietf.org/html/draft-lennox-mmusic-sdp-max-sources-00 Jonathan Lennox presented a new draft on max media source count. Based on a comment from Dave Oran, the upper bound limit for maxbound should be 2^32-1 (unlimited). Christer asked how does the user know whether the media comes from different or a single source. Jonathan clarified that the use only cares whether media comes from a different SSRC: there are different buffers for playing media so the question is whether the endpoint supports more than one simulatenously. It has nothing to do with forking. Gunnar Hellstrom sees good use of this mechanisms; he submitted a draft on text conferencing indicating that it can use multiple SSRCs. Hadriel added a few comments on SSRCs and their handling by SBCs. The take-away from the WG discussions is that the ID should progress and it should integrate more information about SSRC handling. 2.3 Media Source Selection in SDP http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-selection-00 Jonathan Lennox introduced his draft allowing media source selection in SDP. There is potential IPR on this draft, check the IPR disclosure. Based on a discussion with Jonathan, Alan Johnston, and Roni Even, there was consensus that this work should continue in MMUSIC and also be presented and discussed in XCON given the related SIP/XCON conference package. There was a question about how to associate a media stream with a certain SIP dialog when forking for example. Jonathan answered that RFC 5576 should be sufficient on its own for that. The chairs asked how many people are interested in this work by a show of hands: 7 people. 2.4 SDP Extensions for audio over PSTN CS bearers http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-01 Simo Veikkolainen presented an update on the above ID to integrate comments from John Elwell. The chairs asked for reviewers to send comments to the list. Cullen Jennings commented that this revision looks good. Given the meeting time constraints, Peter Fassberg had a few comments that should be discussed after the meeting and sent to the list as needed. 2.5 Misc Capability Negotiation in SDP (Simo Veikkolainen, 10) http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-01 Simo Veikkolainen indicated there were no technical changes in this revision. Hadriel Kaplan asked about the motivations of bundling the bundle i= and b= parameters. This should be clarified on the mailing list. Simo indicated that the goal was to be exhaustive on other SDP attributes. Hadriel Kaplan and Mohamed Boucadair raised questions about why comments expressed on the ccap draft presented earlier in the session do not apply to this draft. Jean-Francois clarified the motivations for this draft (ability to have capability negotiation for the c line), and that this has been discussed on the list and in previous meetings. More discussion should continue on the list re: ccap and how the requirements or solution relate to this Internet-Draft. The meeting concluded.
- [MMUSIC] IETF 75 MMUSIC meeting notes posted Jean-Francois Mule