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

Peter Thatcher <pthatcher@google.com> Mon, 17 June 2013 12:59 UTC

Return-Path: <pthatcher@google.com>
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 D5F8C21F9BA6 for <rtcweb@ietfa.amsl.com>; Mon, 17 Jun 2013 05:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 i8HVEkgfLxrh for <rtcweb@ietfa.amsl.com>; Mon, 17 Jun 2013 05:59:27 -0700 (PDT)
Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB9921F9B8D for <rtcweb@ietf.org>; Mon, 17 Jun 2013 05:59:27 -0700 (PDT)
Received: by mail-pb0-f45.google.com with SMTP id mc8so2756290pbc.18 for <rtcweb@ietf.org>; Mon, 17 Jun 2013 05:59:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CTJuMzFO8nA13bphYdGX6GQQTEn07PpXiXoS08YzvC0=; b=LOnLFamllZF58Slh3Ye7pMMbp18fMwD4MkZ3kDmM3b5FSTvpKCJYj+wDi8H+0QrgMi +nnYF1yTjiqebc/ScXqzoZwUncVN8hy6UvBMNbnA8P0Ve8B3BpwjLW7RbJgNlKD6QsfO JjwPUHjTKSfOUmvdwdfvrNv/OqbUQtsgm5266xX68vHOqSGZY35WnHF3KIQ28+7Xf+Cr 2miWVUty/MyEuCx1JvYHh6TWIrMuwZRp3p+j/XZO8i6IU0Uy1WAZMaAtRbBtKpF2hybS znc6HRnEaAMPlL25FtcH3hs4/qW/aIf/Q9BIDDTqwP3k0rI2AgekJJALlzyYaaWGKLyg RQgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=CTJuMzFO8nA13bphYdGX6GQQTEn07PpXiXoS08YzvC0=; b=Lia93vbjb3tQ+1k7hrNOlxV0SqyKb8gmanNBN3rZpv95fncb3jh3clLxXi+6790jH2 nkrW2BdhOqhqKjEybGNK8K3Maa7wKnCLhMxSBX3CwW31MkbhoQU+VLB9HLGDiH7YJANt fN8iWVbGIqacrdF3GGkLXYFc2A1RjZ1jZoexkOegF9YnJyvYG5WQkiLTaUfQVhDCg8VP YEfsrwSeFMCFp1FpxNlooAXJrqldU7o+atbDt8gAtdtCegPgXP8QxwAn/HU6DCIPDnCq oQC2gchQeyFGfEca31gV0tRxW75O2wTvXoYcWVZKg3J1rZ9lqAmuI/Kn69Vg171YBZ7J lNLw==
X-Received: by 10.66.83.7 with SMTP id m7mr13061415pay.150.1371473966688; Mon, 17 Jun 2013 05:59:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.88.8 with HTTP; Mon, 17 Jun 2013 05:58:46 -0700 (PDT)
In-Reply-To: <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> <6AC8E7C0-F199-4090-94D6-FFF2DF1559F0@iii.ca>
From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 17 Jun 2013 05:58:46 -0700
Message-ID: <CAJrXDUERZAhUFNJEjX3Oixs2WZus=_C5TS=ur7vuq0cZ0YEEKQ@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: multipart/alternative; boundary="f46d042ef48d9a83dc04df592ad6"
X-Gm-Message-State: ALoCoQmtZggczStzmFdd+F7bSPspfRL0/TiiIAF4zZ21v5X7EqDqG7ZcBC0P0xWUGxzL5u1MslCbodTG8yE+xGilIa9tX/LPPnKcGcRFZVJw70SNG465MtvY2AQmajr4lWm4dfJeGsj83ddSUmDqJH9bQuMfdQHC/HSE2YXzg18u0TrF7NZ+DNRKYDU/BUkoBtbJ/yYZGxb7
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: Mon, 17 Jun 2013 12:59:27 -0000

>From Cullen: "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"


I think this hits the nail on the head.  Generally, we need to decide what
the JS API is to allow the JS app to control what is sent and received.
 Specifically for NoPlan, we need a JS API that does not rely on encoding
multiple sources in SDP and doesn't require extra SDP exchanges to
add/remove sources.

I'm glad you asked for such an API, because I was interested in working on
one.  So, I just sent an email with a proposed JS API, and Emil will be
updating the draft RFC to incorporate it.

To be clear, Google is in full support of Plan B, and wants to see the Plan
A vs. Plan B decision resolved.  But if Plan A vs. Plan B cannot be
decided, then we support NoPlan with this JS API as a backup plan, since
Plan B could be implemented on top of NoPlan within JS (and so could Plan
A).


On Fri, Jun 7, 2013 at 10:43 PM, Cullen Jennings <fluffy@iii.ca> wrote:

>
> 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.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>