Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun)

[Emil Ivov <[e-mail]>]

Hey Harald,

On 12.05.13, 22:55, Harald Alvestrand wrote:
> On 05/12/2013 06:03 PM, Emil Ivov wrote:
>>
>>> Or you could signal none of them and depend on the fallback case in
>>> draft-ietf-mmusic-msid to handle them in a consistent manner, and
>>> use other methods to figure out how to handle them...
>>
>> If you are referring to section 4.1 that you also pasted earlier in 
>> this thread, it only talks about one track, per stream, per m= line. 
>> This doesn't cover the conferencing case I described in my previous 
>> mail (quoted above).
>>
> Changing subject as I'm replying to a subtopic, and because I was 
> misunderstanding what Emil was arguing in favour of.....
> 
> when I wrote that text, I didn't intend it to cover only one SSRC per 
> stream.
> What I intended to say was that when, in an RTP session, a browser gets 
> several SSRCs that were not mentioned in signalling, it will send 
> several onaddstream signals to the application, each indicating a new 
> stream being added, which has exactly one track.

Aha! OK, I understand and it sounds better now that I do.

That's only half of it though. We would also need ways in the API to
control these streams if we weren't using SDP O/A.

Incidentally, when people have tried this with Chrome it didn't work as
described above and the unannounced SSRCs were handled in unpredictable
ways. I suppose this is just a matter of time and that the
implementation would eventually get there?

> If the language doesn't 
> say that, I need to change it.

Well obviously I hadn't understood but that might be just me.

Incidentally, we might want to replace Pre-WebRTC with Non-WebRTC or
something similar. Applications that don't aggressively rely on SDP O/A
for stream control are not necessarily a thing of the past.

Emil

-- 
https://jitsi.org