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

Eric Rescorla <ekr@rtfm.com> Tue, 04 June 2013 15:02 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 DF4C821F9C59 for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 08:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.593
X-Spam-Level:
X-Spam-Status: No, score=-101.593 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, 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 liG61SgC75Z9 for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 08:02:38 -0700 (PDT)
Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 711C321F9C2D for <mmusic@ietf.org>; Tue, 4 Jun 2013 06:14:15 -0700 (PDT)
Received: by mail-qe0-f54.google.com with SMTP id ne12so129751qeb.13 for <mmusic@ietf.org>; Tue, 04 Jun 2013 06:14:14 -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=WgjsZFauJqBl9elP8ipyOSp2lWMBFdAuXHNEsRkd0oE=; b=dlLUzj+Ho7gbVytuTrArnUGZlYtW/s9voDpmFGjfH6ffzWNJPXpo8NFlBbpudLYjKV IMrBMGLIOsYolF7cQVCet8W3w5nub9OSCRSnim35gD1Fi4wsA7J4jY36p4NQxGSqApC8 UOkQvvcfGr8KRsj3uBpMkiEdUWfhI4j3Tg/n3jheNWcwrT0GfMidKtBJf9wCcc1b7Ul9 F92tD/sdS0xkwiU0MM3Cmlw6TfUXH7NptfLuy13o8/CnQy2LffnVTkq5MIaIsSfzTuOn ANtoIk7tKvw/6DM1K8th6P43uJXTHYETKgmyJPgHutre2O62eDf/VHJHxrFN7hrp0VZo FDcw==
X-Received: by 10.224.68.10 with SMTP id t10mr23057590qai.24.1370351654739; Tue, 04 Jun 2013 06:14:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.0.163 with HTTP; Tue, 4 Jun 2013 06:13:34 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <51ADA539.1020505@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> <CABcZeBNOyPpcsxFqtagcNvTEFaMBGdfDZuSJx7dJJnzXwTW7Ww@mail.gmail.com> <51ADA539.1020505@jitsi.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 4 Jun 2013 06:13:34 -0700
Message-ID: <CABcZeBP1RSZC4cAtUEDFEkkE0bugW9EMgtWaQehX61qaL=2i3A@mail.gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: multipart/alternative; boundary=001a11c2e2dc994de004de53db2b
X-Gm-Message-State: ALoCoQkOBX312sAsF+zhXQhCKbu3hwfsHOn1vu8R1sO8o2a1znXTFA1LHrvHu2LxkM4u/oESL2Gj
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 15:02:59 -0000

On Tue, Jun 4, 2013 at 1:28 AM, Emil Ivov <emcho@jitsi.org> wrote:

> Hey Eric,
>
>
> On 04.06.13, 03:47, Eric Rescorla wrote:
>
>> On Mon, Jun 3, 2013 at 2:29 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>
> <snip>
>
>          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.
>>
>
> Demuxing by SSRC, as in being able to distinguish one RTP stream from
> another is totally OK and there's no issue with this in No Plan


Well, maybe. So, your claim is that multiple SSRCs on the same m-line are
to be rendered
separately? I note that that's *not* the view Cullen has  expressed.



> er one that allows the JS
>> to say "don't send SSRC A"?
>>
>
> As long as the JS knows the SSRC of a specific track it can just disable
> that specific track. There's no need to tell the browser "don't send SSRC
> A".


Well, given that the only mechanism you provide for addressing tracks
is SSRC, it'a hardly an advantage to not have a "don't send SSRC A"
API point, since that just means you need to go grovelling through the
MSTs for their SSRC values.


>  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.
>>
>
> Does the above answer your question, or would you like me to come up with
> an example of how these new APIs could look?
>

I would like to see a *complete* example with all the data flowing back and
forth
and the API calls (even if they are mocked up) that you think the sides will
make.

-Ekr