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

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
>