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

[Emil Ivov <[e-mail]>]

On 14.05.13, 09:16, Emil Ivov wrote:
> 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.

Oh, just thought of something else while reading Stefan's mail: is it
really necessary that this should only happen in case no SSRCs have been
defined? Why not apply that to any unknown SSRC regardless of whether or
not others exist in SDP?

The second bullet there talks about a possible race condition but I am
not sure I see how this could occur with valid use of O/A.

Emil

-- 
https://jitsi.org