Re: [rtcweb] No Plan - but what's the proposal
Emil Ivov <emcho@jitsi.org> Fri, 31 May 2013 18:27 UTC
Return-Path: <emil@sip-communicator.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EED721F9050 for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 11:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.294
X-Spam-Level:
X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_20=-0.74, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrS+-6KNtC+4 for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 11:27:18 -0700 (PDT)
Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A9E3421F8FCB for <rtcweb@ietf.org>; Fri, 31 May 2013 11:27:17 -0700 (PDT)
Received: by mail-bk0-f43.google.com with SMTP id jm2so917482bkc.2 for <rtcweb@ietf.org>; Fri, 31 May 2013 11:27:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=QVCeerntQ/RfFrsKOA6qSbPP16zsKzFIuHNnlPgfvuM=; b=HNgzAzYrlpEJHIzdlsJCgPx7vGWnHP54H2Rc0U1m99qsGnFwQ7IkyZarHQ2r7S0K09 rBppAxqrOrJycrTfwUzCMhBzif38MP0Y0KdD4hVFZe8TbIKKyGVH+WA0ncpmkJISlxPI BOlu8yg7gnkzZq/lPzYgSGT8YY2Zj0PieMmvF0lFfsDd4EJ5qHNwUyRFKPNoOEtaJT6b lYp8BE2ntvHREN8UZpf909mJUedszkLUYC/0m4gJUfdROdNXpcQ5PiX9JMS109ov0JS4 yLAthRPkPgIC3bIWfaq8AiF0eF2sFWDrprtr/CdOhXG9fWcjavmf3ZguwBm5b6wQEInf hS+Q==
X-Received: by 10.204.172.136 with SMTP id l8mr3656285bkz.49.1370024836605; Fri, 31 May 2013 11:27:16 -0700 (PDT)
Received: from camionet.local ([83.228.77.158]) by mx.google.com with ESMTPSA id da16sm15604733bkb.2.2013.05.31.11.27.14 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 11:27:15 -0700 (PDT)
Message-ID: <51A8EB7F.6000506@jitsi.org>
Date: Fri, 31 May 2013 21:27:11 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Cullen Jennings <fluffy@iii.ca>
References: <51A65017.4090502@jitsi.org> <C3639EB3-0F44-4893-88DA-BB9F9C96A116@iii.ca>
In-Reply-To: <C3639EB3-0F44-4893-88DA-BB9F9C96A116@iii.ca>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkpInODCrxDH2v6VdNSkk5nBGXqYKBQ0wN5MS6tCuNlbK+estQK47WJ2USHz+I/iR+KT3dh
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No Plan - but what's the proposal
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 May 2013 18:27:19 -0000
Hey Cullen, On 30.05.13, 20:07, Cullen Jennings wrote: > Interesting draft but it seemed to have more questions about how > things would wok than answers. Let me try and ask you some specifics > to help flesh out what this plan is and offer a few comments. > > Of the actual recommendations in the draft that relate to the problem > I would summarize that draft as > > 1) demux RTP based on PT but let the application know the SSRC in > case it wants to do something more > > 2) the way the applications interacts with the browser for set up of > the media stack is via SDP > > 3) Other session control not related to the media stack is left up to > the application to do how it wants > > 4) Things like conference control and clue control and call control > should be handled by the application > > 5) you have a few avenues we might pursue for making FEC, RTC, etc > work > > 6) you have some API requirements Yes, the above seem like an accurate summary. > which, with the exception of 4 > about exposing the max number of incoming streams that can be > decoded, I think are pretty much agreed to be put put in W3C API > already. > On the topic of #4, it's a big unclear what is really needed > and ongoing discussion is happening around how do indicate what can > be received but thats a webrtc issue Then I suppose this is a good time for us to agree here on what we need the API to expose so that the underlying protocols would work. > This is very close to Plan A. I'd say it's actually closer to Plan B but Plan-A-style signalling should certainly be possible to implement by the app or a signalling gateway. > So I read the whole draft and asked > myself how is this different than plan A. What parts of this draft > would not be abel to do if we did Plan A. The part where one doesn't have to redo (and propagate) an Offer/Answer exchange every time a source is added or removed. > The only real topic I could > come up with was the port music here is PT only instead of PT + SSRC. > I'l start a separate thread on that. This is another difference indeed. > But lets ask what the proposal is for the question Plan A and Plan B > are trying to resolve. > > Let's say browse A wants to say it can send two streams of video and > here are the parameters for the video codecs for each to the streams. > What does the SDP that createOffer generates look like? There's an example in the draft. I assume the "parameters" you mention are not in there, so could you please be more specific? > I see the > draft says "strongly advises against the use of multiple m= lines for > a single media type. " but I don't really know what you mean by that. It means a browser should generate and offer that looks like this: m=audio m=video rather than an offer that looks like this m=audio m=video m=video m=video Also if one bundle is not enough to fit all payload types in the two media lines, then we split them in two. > Can you explain what you are actually proposing we do do instead of > just saying what not to do ? We create an offer that would describe the media types and the bundle. We use that offer to also describe capabilities in terms of maximum resolutions, supported header extensions, potentially max-ssrc-s, etc. It is up to the application how to handle the rest. If it needs to transmit additional signalling: let it. If it wants to encode that in SDP, great. If it wants to attach it in JSON next to the browser generated SDP, that also works. > The above paragraph is the most important part of my email. Please, > what is the proposal for what the SDP in the offer looks like. You started another thread for this, so I'll respond there. > The idea of exposing a low level API to the media stack and having > the all proposing to do FEC, RTX, SDP processing ect has been > discussed many times across the various working groups. It' jokingly > refereed to as comment 22 at this point. I appreciate you are trying to turn this into a joke (which I think is a pity provide your chairing role in this working group), but abandoning SDP really isn't what this is about. You might have noticed text about this as early as the abstract: This document does not question the use of SDP and the Offer/Answer model or the value they have in terms of interoperability with legacy or other non-WebRTC devices. Emil > It's not that it does not > have merits, but many people myself included see it as a much longer > road to get done, a lot more work, and no clear gain. One of the > other issues is we are trying to make this so you don't have to be a > telephone expert to use it and that lots of developers can use it. > I'm not going to try and summarize the low level API augments here > but if you want to discus it webrtc is the right WG. > > I'll note there are many points in the draft that I disagree > with but > I'd rather try and sort through what the actually proposal is here > before addressing any of them. > > There is one point I would like to make that is the confusion > introduced by "legacy endpoint". When I talk about legacy endpoints, > I am talking about endpoints that use SIP or Jingle and both past > ones and future endpoints. SIP will continue to evolve and I expect > WebRTC to continue being able to negotiate new features. For example, > if a SIP phone added VP9 and a browser supported VP9, I would expect > to be able to use it. The legacy refers to an older protocol, SIP, > and not to the age of the endpoint. We do know that things can't work > with all deployed endpoints and long ago we made the decision to give > up on endpoints that don't do ICE. But we do try and have a > reasonable experience with old and future endpoints. > > > On May 29, 2013, at 12:59 PM, Emil Ivov <emcho@jitsi.org> wrote: > >> Hey all, >> >> Based on many of the discussions that we've had here, as well as >> many others that we've had offlist, it seemed like a good idea to >> investigate a negotiation alternative that relies on SDP and >> Offer/Answer just a little bit less. >> >> The following "no plan" draft attempts to present one such >> approach: >> >> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan >> >> The draft relies on conventional use of SDP O/A but leaves the >> intricacies of multi-source scenarios to application-specific >> signalling, with potentially a little help from RTP. >> >> Hopefully, proponents of Plans A and B would find that the >> interoperability requirements that concerned them can still be met >> with "no plan". Of course they would have to be addressed by >> application-specific signalling and/or signalling gateways. >> >> Comments are welcome! >> >> Cheers, Emil >> >> -- https://jitsi.org >> _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > -- https://jitsi.org
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Richard Barnes
- Re: [rtcweb] No Plan Cullen Jennings
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Martin Thomson
- [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Mary Barnes
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan - PT based MUX Cullen Jennings
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- Re: [rtcweb] No Plan Mark Rejhon
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- [rtcweb] RTT (was Re: No Plan) Matthew Kaufman
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Matthew Kaufman
- Re: [rtcweb] RTT (was Re: No Plan) Paul Kyzivat
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was Re: No Plan) Gunnar Hellstrom
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Barry Dingle
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- [rtcweb] Translating Plan A into No Plan (Was: No… Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Eric Rescorla
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] Translating Plan A into No Plan (Was… Martin Thomson
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] RTT (was :No Plan ) Paul Kyzivat
- Re: [rtcweb] No Plan - but what's the proposal Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Jonathan Lennox
- Re: [rtcweb] No Plan Jim Barnett
- Re: [rtcweb] Translating Plan A into No Plan (Was… Roni Even
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- [rtcweb] Repair Flows and No Plan (Was: No Plan) Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was :No Plan ) BeckW
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] Repair Flows and No Plan (Was: No Pl… Sergio Garcia Murillo
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Silvia Pfeiffer
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- [rtcweb] Plan xyz discussions; MMUSIC <> RTCweb R… Flemming Andreasen
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Peter Thatcher