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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 04 June 2013 17:39 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 23D3E21F960D for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 10:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.056
X-Spam-Level:
X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1]
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 PiEYPinlizbD for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 10:39:00 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2CC21F96A9 for <mmusic@ietf.org>; Tue, 4 Jun 2013 09:16:10 -0700 (PDT)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta12.westchester.pa.mail.comcast.net with comcast id kBPB1l0030cZkys5CGG9nr; Tue, 04 Jun 2013 16:16:09 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id kGG91l00g3ZTu2S3WGG9De; Tue, 04 Jun 2013 16:16:09 +0000
Message-ID: <51AE12C8.3090501@alum.mit.edu>
Date: Tue, 04 Jun 2013 12:16:08 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: mmusic@ietf.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> <CABcZeBP1RSZC4cAtUEDFEkkE0bugW9EMgtWaQehX61qaL=2i3A@mail.gmail.com>
In-Reply-To: <CABcZeBP1RSZC4cAtUEDFEkkE0bugW9EMgtWaQehX61qaL=2i3A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370362569; bh=v2XssIOod/dahDl4HwJ/MyzwtA9oI9uBW60nFSVnZAM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bBRuf5XaRxUJCG1A3P+JgESfuY3xyna4Yg0czZsXhBksrG+1bu0cBiNcVyaqYjhL/ MXeBpIcAD7ECXfEW36Zt7WptSXJEL2lTf2Bz09DBHaXrCv9xTFsyI6+ex9Ue97nCrn 0rTD2ztT5ukumSFF6bdbJiqe2STOYC6owmqzP1qrttdtr4aT+evSp5FcakEr1l7cYt gZYC6h48ui0WYWv8Zplu8dN4fdtekOA8E098HE0mmo7/DIvq6BFzXQ/2x0CorQeODQ TewoWtjufVtueKKQUqsk7tU37cznKMEAgAI4Dn+wTwYYIpj/lniAJ2IjYLkWL7PPhi nDyOwnxi1J9ww==
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 17:39:05 -0000

On 6/4/13 9:13 AM, Eric Rescorla wrote:

>     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.

If we fold in *Colin's* comments, then demuxing by SSRC is separate from 
determining if/how/where to render that stream.

Is there a need for an API to associate multiple SSRCs with a single 
mediaStreamTrack? Or should it be up to the app to accept multiple 
mediaStreamTracks to render them to the same place?

	Thanks,
	Paul

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