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

[Eric Rescorla <[e-mail]>]

On Tue, Jun 4, 2013 at 1:28 AM, Emil Ivov <[e-mail]> wrote:

> Hey Eric,
>
>
> On 04.06.13, 03:47, Eric Rescorla wrote:
>
>> On Mon, Jun 3, 2013 at 2:29 PM, Emil Ivov <[e-mail]> 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