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

[Harald Alvestrand <[e-mail]>]

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. If the language doesn't 
say that, I need to change it.

(One reason why I changed this from the version with just a single 
stream with one track per unknown SSRC was that there's no way to know 
the desired synchronization properties of the stream before one sees the 
CNAME of the stream - which may be at an arbitrary time after the first 
packet.)