Re: Question: how should addTrack work in relation to createOffer et. al.?

On 05/13/2015 08:20 PM, Martin Thomson wrote:
> On 13 May 2015 at 07:29, Harald Alvestrand <harald@alvestrand.no> wrote:
>>   pc.addTrack(X);
>>   pc.createOffer().then(offer)
>>   pc.addTrack(Y);
>>
>> always give the same number of tracks represented in the offer. And I do
>> mean *ALWAYS*.
>>
>> My aesthetic preference is that X be included and Y not be included,
> I agree with this.
>
> I think that we can do that if we are willing to break backward
> compatibility in some of the more perverse corner cases.
>
> Think about the following:
>
> pc.setRemoteDescription(offer)
> pc.addTrack(X);
> pc.createAnswer().then(answer => { ... });
> pc.addTrack(Y);
>
> If code like this exists, then I think we need to have it fail
> (because the state of the PC at the time that createAnswer is called
> is not correct).  Then we get the sort of cleanliness that you are
> looking for.
>
> (We only get in this sticky situation because we carry state between
> operations implicitly.)

I'm not sure what you're saying here - to me it seems that
createAnswer() is clearly called between pc.addtrack(X) and
pc.addTrack(Y), but we don't have a description of when the .then task
of createAnswer() (and thus the ... part) is called.

Care to clarify?

(One thread suggested that .then is a microtask, which means that it's
definitely called after pc.addTrack(Y), but apparently this isn't an
universally held position.)



-- 
Surveillance is pervasive. Go Dark.

Received on Wednesday, 13 May 2015 18:39:05 UTC