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

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.)

Received on Wednesday, 13 May 2015 18:20:51 UTC