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

[Emil Ivov <[e-mail]>]

(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 <[e-mail]
> <mailto:[e-mail]>> 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.

If these streams are supposed to reach the application and be rendered 
as separate tracks then this is all that needs to happen. They may need 
to be rendered in a specific order from left to right. But this only 
concerns the application.

There are of course cases where the browser does actually need to know 
about a relation between these three streams. This would be the case for 
various kinds of repair flows and layering.

Exactly how the browser would learn about these relations would depend 
on the specific mechanism and there are various options. They may be 
some that are handled entirely by the codec, or they could use something 
like the RTP header extension from the draft, or something like Magnus's 
SRCNAME.

They could even be specified in the SDP, but in that case they would be 
there only because the specific mechanism required it, not because 
RTCWEB did.

Does this make things clearer?

Cheers,
Emil


-- 
https://jitsi.org