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

[Harald Alvestrand <[e-mail]>]

Apologies for being late in the response....

On 05/15/2013 06:06 PM, Emil Ivov wrote:
> On 15.05.13, 09:24, Harald Alvestrand wrote:

<snip>
>>
>> Exactly - IF the party sending the SSRC is able to see when the
>> offer/answer completes.
>> The offerer is the only party that can actually know if the offer/answer
>> exchange is complete.
> OK, got it.
>
> Then, going back to your second bullet, we could apply the same
> buffering as the one you currently describe there. Only this time, once
> we are done with the offer/answer things could go either way: we could
> end up either signalling a new track or determining that packets
> actually belong to some specific stream.
Hm. Declaring a moratorium on "onaddstream" events while a negotiation 
is in progress actually solves the problem - I think!

In the case where signalling takes a while to complete (response got 
lost, signalling relay server is overloaded, or something else weird 
happens) we do have a problem with buffering - we have to be able to 
throw away some data at some point, or we require infinite buffers. But 
throwing away RTP data is something we have to deal with anyway - 
recovery should not be much worse than after a temporary transmission 
glitch.

>
> If this makes sense, I'd be happy to propose text if it helps.
>
>> So the ambiguity only applies if the answerer is able to announce new
>> SSRCs in an answer.
>> Is it reasonable to remove this functionality (and thereby mandating
>> Plan B's double offer/answer) in order to achieve this functionality?
>>
>>> 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.
>> As long as you don't need any information not carried in the RTP packet
>> in order to announce the stream correctly, this would work.
> I suppose we'll get there eventually. RTCP is one option here but what I
> am personally hoping is that we'll agree that the APIs can also start
> providing that information so that web apps can exchange it any way they
> wish. Before, with, or after the SDP O/A has taken place.

If we're depending on RTCP, we have to wait until the first RTCP packet 
arrives, of course.

>
> Cheers,
> Emil
>
>