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

[Harald Alvestrand <[e-mail]>]

On 05/14/2013 10:59 AM, Emil Ivov wrote:
>
> 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.

The worrying case is:

A sends offer
B sends answer (either with or without MSID)
B starts sending data on some SSRCs
A receives the data, but has not yet seen the answer

The two cases are:

- B sends with MSID. In this case, he expects those specific IDs to be 
signalled in onaddstream.
- B sends without MSID. In this case, he expects that A will announce a 
locally generated ID in onaddstream.

A can't know the difference between those two before he sees the answer 
from B.
In this spec, I've "solved" it by saying that we don't signal 
onaddstream before we see the answer.

After the first answer has been seen, either party knows that new SSRCs 
always will be signalled, so any data on an unknown SSRC can be held 
until the negotiation announcing it is complete - or discarded as "bad 
data" if signalling doesn't happen in a reasonable time.

If we were to permit unknown SSRCs when there are some MSIDs, the 
decision to announce as "Unsignalled MediaStream" or wait for the 
offer/answer announcing the MSID it should be announced with has to 
depend on some other resolution mechanism. I don't like timers, and 
haven't found a better way to do it.

Note: If we follow "plan B"'s idea of having B send an offer with its 
own streams immedately after sending the answer to A, and only announce 
its streams in the counter-offer, not in the answer, and not sending 
data until it gets the answer, this problem goes away; there cannot be a 
case where A gets an SSRC that was intended to be signalled before he 
gets the signalling message that announces it.

I'm sure there's a cost to this solution (the extra half RTT is one 
obvious cost. Are there others?)



>
> Emil
>