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

[Emil Ivov <[e-mail]>]

On 14.05.13, 15:08, Harald Alvestrand wrote:
> 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.

I didn't get this part. While I see the race condition that occurs
during offer/answer, I am not sure I understand why a new SSRC received
mid-session by either side is ambiguous. If the application had any
intent to announce it, then presumably it would be on the verge of
initiating a new offer/answer. If that were the case, sending the new
stream/track could have been held off until completion of that
offer/answer.

This way one would be able to only announce SSRCs for things such as FEC
and simulcasting (where available) while simple streams could be
delivered immediately.

Emil


-- 
https://jitsi.org