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

On 5/13/15 3:36 PM, Martin Thomson wrote:
> On 13 May 2015 at 11:38, Harald Alvestrand <harald@alvestrand.no> wrote:
>>> 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?
> This code is currently safe, and I know that people do exactly this.
> But it only works because createAnswer is enqueued behind
> setRemoteDescription: createAnswer doesn't actually get executed until
> setRemoteDescription completes.

Right.

 1. setRemoteDescription is called
 2. Track X is added
 3. createAnswer is chained (not called)
 4. Track Y is added
 5. setRemoteDescription completes
 6. createAnswer is called
 7. createAnswer completes


Which explains why Track Y gets included in this corner-case.

We can:

 1. Outlaw it
 2. Complicate chain (put createAnswer(X and whatelse) on it)
 3. Leave it
 4. Always chain (make non-corner cases take Track Y as well)


Tightening up the processing models of createOffer and createAnswer to 
not race with JS is a separate issue.

.: Jan-Ivar :.