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

Cullen Jennings <fluffy@iii.ca> Sat, 08 June 2013 05:43 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 B6BB021F998A for <rtcweb@ietfa.amsl.com>; Fri, 7 Jun 2013 22:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level:
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 fHpF7ph-FPdA for <rtcweb@ietfa.amsl.com>; Fri, 7 Jun 2013 22:43:29 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 18C0A21F86AE for <rtcweb@ietf.org>; Fri, 7 Jun 2013 22:43:29 -0700 (PDT)
Received: from [10.70.232.148] (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 304A522E1FA; Sat, 8 Jun 2013 01:43:25 -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: <CAHp8n2ngefdpyNMLw+5Mb0Lkk4pWFC5Yc_+xt+StDYD_6HgZrg@mail.gmail.com>
Date: Sat, 8 Jun 2013 12:43:26 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AC8E7C0-F199-4090-94D6-FFF2DF1559F0@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> <13444A29-86C6-4D69-964D-AE9A5BA7BB4A@iii.ca> <CAHp8n2ngefdpyNMLw+5Mb0Lkk4pWFC5Yc_+xt+StDYD_6HgZrg@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
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: Sat, 08 Jun 2013 05:43:43 -0000

On Jun 6, 2013, at 2:14 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

> On Thu, Jun 6, 2013 at 3:41 PM, Cullen Jennings <fluffy@iii.ca> wrote:
>> 
>> 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.
> 
> 
> Wouldn't that simply be multiplexed over one PeerConnection in the
> browser using addStream()?

Yes, that makes sense. I was assuming all the streams would be on the same PeerConnection

> I have an application like that working. I
> can dig out the SDP packets that the browser sends in this case, if
> you are interested.

Uh, not sure that would help much. The issues is that current standards don't say what the browsers should do and we have two proposal on how the browsers could implement this. One proposal from Mozilla and one proposal from Google. I don't think either browser implements exactly the corresponding proposal yet but they are trying to figure out what to do. We need to agree on roughly what is passed across the JS API such that the browser know how to set up the media stack to send and receive the appropriate RTP that is desired by the JS application. 


> 
> Regards,
> Silvia.