Re: Deadline guarantees on addstream event / update set of remote streams

On Thu, Jan 23, 2014 at 9:05 AM, André Susano Pinto <andresp@webrtc.org>wrote:

> I would expect to be able to find a guarantee on the spec that all
> addstream events get queued before the successCallback of a
> setRemoteDescription or some other well defined deadline (e.g. signalling
> state becomes stable). But after reading it I just got more questions:
>

The expectation is that all streams that are defined in the remote
description will be announced via onaddstream callbacks before the success
callback of SRD fires. This is the only way to make sure that you have
gotten all the streams from the remote description.

>
> Question 1:
> """Onnaddstream happens as early as possible after the
> setRemoteDescription.""" - this "as early as possible" sounds vague. Can
> anyone explain me what to derive from this sentence?
>

I'm not exactly sure either, other than the note provided by the following
sentence, "This callback does not wait for a given media stream to be
accepted or rejected via SDP negotiation.". So basically all proposed
streams are announced as a result of setRD, and then you have to call
->stop() on the streams you don't want to reject them.

>
> Question 2:
> Can anyone breakdown these 2 quotes? It is unclear for me on how they
> interact with each other.
> a - """"""This will be fired only as a result of setRemoteDescription ...
> This callback does not wait for a given media stream to be accepted or
> rejected via SDP negotiation."""
> b - """The creation of new incoming MediaStreams may be triggered either
> by SDP negotiation or by the receipt of media on a given flow."""
>

It's possible to have new MediaStreams pop out as a result of media
arriving on an unannounced SSRC, but typically this will only happen when
interacting with non-WebRTC endpoints that do not signal their individual
streams.