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