Re: [rtcweb] Interaction between MediaStream API and signaling

[Stefan Hakansson LK <[e-mail]>]

On 04/14/2012 04:22 AM, Randell Jesup wrote:
> A reply I hadn't sent...
>
> On 4/2/2012 9:55 AM, Stefan Hakansson LK wrote:
>> On 04/02/2012 05:16 AM, Justin Uberti wrote:
>>>>> Yes. Just like in SIP. And so when you send an OFFER (or
>>> modified
>>> re-OFFER), you must be ready to receive data per that offer
>>> even if no
>>> ANSWER has been received - just like in SIP. And if its a
>>> re-offer, you
>>> need to accept the old, and accept the new (though you could
>>> probably
>>> use reception of obviously new-OFFER media to turn off
>>> decoding/rendering old-OFFER in preparation for the ANSWER).
>>>
>>> The flip side of this is the responder has to infer when the
>>> sender
>>> switches over to the result of the ANSWER from the media.
>>> For example:
>>>
>>> A B
>>> <--- H.261 --->
>>> re-OFFER(VP8) --->
>>> <-- ANSWER(VP8) (delayed in reception)
>>> <-----------VP8 (A should infer that B ANSWERed
>>> and accepted VP8)
>>> ---------->  H.261
>>> <-- ANSWER(VP8) (received)
>>> <--------VP8---------->  (B should infer by reception of
>>> VP8 that ANSWER
>>> was received)
>>>
>>> (Personally, I hate inferences, but without a 3 (or 4) way
>>> handshake,
>>> you have to). If you switches of codecs are staged, then
>>> this isn't
>>> (much) of a problem. Either leave old codec on the list, or
>>> leave it on
>>> the list until accept, and then re-OFFER to remove the
>>> un-used codec.
>>>
>
> [ Stefan responded: ]
>
>>> I think I understand what you mean, and this would work fine as
>>> long as
>>> you just switch codecs that are used in already set-up MediaStreams.
>
> Ah, but how do you know which stream the packets are for:
> in bundle, the packets are designated by SSRC, but without the ANSWER
> you can't figure it out, and on ANSWER the SSRCs could change.

If I read the spec right, the ANSWER can't change the SSRCs for streams 
going offerer -> answerer (but I agree to the first point you are making).



> Or if
> you change from non-bundle to bundle (admittedly, it's unclear when one
> would do so, but we're discussing a protocol, and that's not disallowed
> I assume).

Right.

>
> We have to consider, since we're designing a protocol, not only the
> preferred and likely negotiations, but all possible negotiations.
> Painful, but true.

Agree. IMO, there is a lot that is unclear, and need to be speced out. 
JSEP basically allows you to modify anything at any time, and to be able 
to build interoperable implementations we need to define what should happen.

>
>>> This may have been a very bad example. Probably you can tell them
>>> apart on the SSRC. But even so, the A browser won't know what the
>>> VP8 stream (if it has an unknown SSRC) represents without receiving
>>> the ANSWER.
>>>
>>>
>>> I think this is only an issue if you decide to add streams in the
>>> ANSWER. But even so, eventually the ANSWER arrives and you can start
>>> demuxing/decoding appropriately.
>>
>> Yes, I agree to that it is only an issue if you add streams in the
>> answer. Perhaps it is a model we should move away from - but that is the
>> model used in the basic examples of the JSEP draft.
>
> Even if you don't add streams you could change the Bundle; or the SSRC's
> could change messing up demux until ANSWER, etc.
>
>> I think there is a risk of clipping if you start sending immediately,
>> but can only start demuxing/decoding once an answer is received.
>
> I would agree.
>
>
>