Re: [rtcweb] No Plan - but what's the proposal

Cullen Jennings <fluffy@iii.ca> Thu, 06 June 2013 05:41 UTC

Return-Path: <fluffy@iii.ca>
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 A87E021F957B for <rtcweb@ietfa.amsl.com>; Wed, 5 Jun 2013 22:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599]
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 wBKC09u9xCMr for <rtcweb@ietfa.amsl.com>; Wed, 5 Jun 2013 22:41:42 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A3B4721F964C for <rtcweb@ietf.org>; Wed, 5 Jun 2013 22:41:28 -0700 (PDT)
Received: from [10.70.233.131] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1B17D22E253; Thu, 6 Jun 2013 01:41:18 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <51AF5784.3060307@jitsi.org>
Date: Thu, 6 Jun 2013 12:41:17 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <13444A29-86C6-4D69-964D-AE9A5BA7BB4A@iii.ca>
References: <51A65017.4090502@jitsi.org> <C3639EB3-0F44-4893-88DA-BB9F9C96A116@iii.ca> <51A8EB7F.6000506@jitsi.org> <72B58042-78E3-4759-B3CD-204B82A38447@iii.ca> <51ACF998.5030202@jitsi.org> <CALiegf=pJtdL2A6V7bprZ_F=V39Fadb+kRw3yfO+6+MFVZ9x2A@mail.gmail.com> <5ED2CC48-1514-4C00-AEE8-A334EB67A6F4@iii.ca> <51AF5784.3060307@jitsi.org>
To: Emil Ivov <emcho@jitsi.org>
X-Mailer: Apple Mail (2.1503)
Cc: "rtcweb@ietf.org" <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: Thu, 06 Jun 2013 05:41:46 -0000

I've trying to help you explain and I keep asking for an example but I don't think we have had a complete example yet. I know you think there is a complete example so let me try and be more specific so perhaps we can get to the bottom of the disconnect. 

Let me try to be specific. 

Say an application running on Alice's browser want to generate an offer that says the browser is ready to send and receive 2 streams of video and 1 stream of audio look like? Imagine that one of the video streams is a document camera running at high res but low frame rate while the other is video of the speaker running at a higher frame rate.  What exactly does the SDP passed from the browser to the JS applications look like.  I agree the applications can do whatever it wants to communicate the relevant data to the far end so I don't care about  the signaling protocol or JSON  that JS app can send across the wire. But next question, can the far end start sending media immediately to the browser? Finally the far end does something that causes the applications to generate an SDP answer from the JS applications to Alice's browser. I want and example of that that looks like in the cases where the far end a) accepted all the video streams and b) rejected some but not all of the video streams. 

If we can get an simple example like this sorted out, then perhaps it will be easy to extrapolate to the ones in the say the use case document and start looking at things like number of round trips and audio clipping. 

Cullen


PS - my apologies but a bunch of the time I have to work on this ends up on planes so there is some time warp sometimes from what data I had to read on the list vs what is on the list by the time my emails arrive. I also tend to try and process email sent to me before dealing with all list email which I tend to deal with in batches. So I'm sending this without having read the all the list traffic. 


On Jun 5, 2013, at 10:21 PM, Emil Ivov <emcho@jitsi.org> wrote:

> 
> 
> On 05.06.13, 02:40, Cullen Jennings wrote:
>> 
>> 
>> On Jun 4, 2013, at 4:07 AM, Iñaki Baz Castillo <ibc@aliax.net>
>> wrote:
>> 
>>> 2013/6/3 Emil Ivov <emcho@jitsi.org>rg>:
>>>>>> 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.
>>>>> 
>>>>> 
>>>>> Great - I have super news for you. The WG agree to do that a
>>>>> year or more ago.
>>>> 
>>>> 
>>>> So I've heard indeed.
>>>> 
>>>> Unfortunately however, it seems that we might have forgotten this
>>>> decision. We are now trying hard to come up with a signalling
>>>> mechanism that will do everything with Offer/Answer.
>>> 
>>> 
>>> I think there is a misunderstanding here. I understand from Emil's
>>> mail that media re-negotation or streams addition after the first
>>> SDP O/A is not carried as a new full SDP O/A. Am I right?
>>> 
>>> 
>> 
>> 
>> I'm just trying to understand what the "No Plan" proposal is. I have
>> not even started to think about what parts of if I like. So far, the
>> more we talk about this, the more confused I get. I think some simple
>> examples that showed what O/A got passed across the API from the JS
>> into the browser for applications with multiple video steams would
>> really help.
> 
> Then, in case you've missed any of these:
> 
> You asked how Plan A endpoints would work with No Plan browsers here:
> 
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07696.html
> 
> The reply, with sample SDP went here:
> 
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07724.html
> 
> You then moved the thread to MMUSIC and asked to see the answer here:
> 
> http://www.ietf.org/mail-archive/web/mmusic/current/msg11347.html
> 
> In the above you also asked how the answerer could refuse one video stream. I replied with the SDP answer and additional sample signalling here:
> 
> http://www.ietf.org/mail-archive/web/mmusic/current/msg11354.html
> 
> I don't think I've seen any additional questions from you since then.You are now saying that the situation is still unclear, so please let me know if I can help in any way. Otherwise we could also switch to whatever problems you have with the approach itself.
> 
> In the mean time, again on MMUSIC, Eric has asked for more detailed examples including sample JS code here:
> 
> http://www.ietf.org/mail-archive/web/mmusic/current/msg11360.html
> 
> Enrico has put up a very helpful and very complete example to this here:
> 
> http://www.ietf.org/mail-archive/web/mmusic/current/msg11382.html
> 
> I added a nit here:
> 
> http://www.ietf.org/mail-archive/web/mmusic/current/msg11386.html
> 
> Cheers,
> Emil
> 
> -- 
> https://jitsi.org
>