Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan)

Eric Rescorla <ekr@rtfm.com> Tue, 04 June 2013 01:30 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EA021F9983 for <mmusic@ietfa.amsl.com>; Mon, 3 Jun 2013 18:30:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.811
X-Spam-Level:
X-Spam-Status: No, score=-100.811 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
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 BoTSD8P3OdyG for <mmusic@ietfa.amsl.com>; Mon, 3 Jun 2013 18:30:22 -0700 (PDT)
Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id EC0A421E80C7 for <mmusic@ietf.org>; Mon, 3 Jun 2013 17:48:05 -0700 (PDT)
Received: by mail-qe0-f45.google.com with SMTP id q19so2841904qeb.32 for <mmusic@ietf.org>; Mon, 03 Jun 2013 17:48:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=dR5E2Gv1La/VzayboyisiPvJsbriW0PABFBoJDjQLHw=; b=j2eL1eAmm3sgsFlo3p/VbB9IUajUOmK7xMBgouvCcuJGlmFDmwtU6nm+wpsRudN5to W0JRUCmq2waVG2gKxGlZBC3LLh3jDJwskz/LIxg7ssWDHP2h2+FvattJfvAiL4wPYnfi rWrKu6Mk/Tht0JqRp89KvVnob4mGlOCACsKGwouo6cBMPDXEXcGiuTZhBpvN2zwdlJeU c6iBSxdlRh+gZEONagL10x79M1EvpDdjI8sUo2tyT9QqbMzx96Z9C2XyYHeNRJMts/D0 L4qmcFWoCoJ071dvw9+pjBv8egMAnLJz/AUT7LNHHexQC5EhFMtLGOAReFiJrSNAaIBp 1cew==
X-Received: by 10.224.71.145 with SMTP id h17mr21614122qaj.31.1370306885406; Mon, 03 Jun 2013 17:48:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.0.163 with HTTP; Mon, 3 Jun 2013 17:47:25 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <51AD0AC2.2080001@jitsi.org>
References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB113528171@xmb-aln-x02.cisco.com> <51A8EAB7.8080206@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB11352940B@xmb-aln-x02.cisco.com> <51ACD224.8080100@jitsi.org> <CABcZeBNp72QirKG1WPaX0HFjCFC+WRJ4Zh-H9L8zaVmmb4Yuog@mail.gmail.com> <51AD042E.2090302@jitsi.org> <CABcZeBPgs17NqjnVC06APSzUebWZpKtqisRJy8Op+Zp=Kn7jaw@mail.gmail.com> <51AD0AC2.2080001@jitsi.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 03 Jun 2013 17:47:25 -0700
Message-ID: <CABcZeBNOyPpcsxFqtagcNvTEFaMBGdfDZuSJx7dJJnzXwTW7Ww@mail.gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: multipart/alternative; boundary="047d7bea317423624f04de496fd4"
X-Gm-Message-State: ALoCoQnF1giMlXo9wbD4LO+PcbKwUt3o/Xvd2p4B8J1NJzIE9POhcwQegY36WFKGYnQHdtMTlPgq
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2013 01:30:37 -0000

On Mon, Jun 3, 2013 at 2:29 PM, Emil Ivov <emcho@jitsi.org> wrote:

> Hey Eric,
>
>
> On 04.06.13, 00:07, Eric Rescorla wrote:
>
>>
>> On Mon, Jun 3, 2013 at 2:01 PM, Emil Ivov <emcho@jitsi.org
>> <mailto:emcho@jitsi.org>> wrote:
>>
>>     (moving from rtcweb)
>>
>>     Hey Eric,
>>
>>
>>     On 03.06.13, 21:33, Eric Rescorla wrote:
>>
>>
>>         On Mon, Jun 3, 2013 at 10:28 AM, Emil Ivov <emcho@jitsi.org
>>         <mailto:emcho@jitsi.org>
>>         <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
>>         [...]
>>
>>              III. Talking to other WebRTC applications
>>
>>              This is the fun case and the one we should be most
>>         concerned with.
>>              Let's imagine that the answerer needs to add a fourth video
>>         stream.
>>              To make this work endpoints would need to do the following:
>>
>>              a) with Plan A and draft-roach-rtcweb-glareless-_**___add:
>>
>>
>>                  - send application specific signalling to the offerer
>>                  - have a new O/A exchange
>>
>>              b) with Plan A:
>>                  - have a new O/A exchange
>>                  - potentially risk glare with some impact on user
>>         experience
>>
>>              c) with No Plan:
>>                  ... nothing
>>
>>
>>         I'm really not following how this works in "No Plan". Ignoring
>>         Plan A
>>         and Plan B, can you just
>>         walk through a complete example of what happens in your plan?
>>         I.e., how
>>         does browser
>>         B learn learn that Browser A wants to send 3 streams instead of
>> one?
>>
>>
>>     It just gets three streams instead of one. It sees three new SSRCs
>>     and it generates three new MediaStreams.
>>
>>
>> So, just for clarity: you mean that A advertises one m-lin, B accepts,
>> and then A sends some arbitrary number of media flows,
>>
>
> Yes.
>
>  identified
>> by SSRC?
>>
>
> What does "identified" mean?


I mean demultiplexed by SSRC.



 If so, I've got some questions:
>>
>> - If B can only display one video stream, how does it say so?
>>
>
> This is something that one app needs to tell another app. They can do so
> however they wish. As far as browsers are concerned: the transmitter just
> sends whatever the application instructs. The receiver just handles
> whatever it can.


But there needs to be a complete set of API surfaces that allow
both sides to do the right thing.




 - How does B tell A not to send various streams?
>>
>
> What does "various" streams mean? If what you have in mind is: How does B
> tell A: "don't send me SSRCs 1, 2, 3 and 5" but keep 4 going, then B would
> send the list of SSRCs in app-specific signalling and A would stop sending
> them.


Uh, how does that work? Is there some API that I'm unaware of that
allows JS to get the SSRCs? And another one that allows the JS
to say "don't send SSRC A"?

It would be really helpful if you could provide a complete example of
exactly what each side does. I'm find if you just invent some
application-specific
signaling for this purpose, but what I'd like to see is exactly what API
calls each side makes.

-Ekr