I suggest to keep addTrack() sync for simplicity.

The problem of which tracks that are included in what offer/answer can be solved by having createO/A() snapshot the list of currently added tracks at the point the method (creatO/A()) is called. According to Justin, that's how it works in Chrome today (but for streams).

The addtrack operation is synchronous, but it causes things to happen that are easier to describe as a queued task (stuff that happens in stable state).

Exemplar case:

createOffer().then(offer =>)
AddTrack(track)

Will the offer include the added track or not?

There should be a test written for this behaviour, so that we know whether the behaviour is consistent or inconsistent between browsers.
It should be defined and deterministic, and the spec should say which is true.

JSFiddle for addStream: http://jsfiddle.net/bvmkdsa4/2/ (needs some tweaking to work in non-webkit browsers)

(In reply to Harald Alvestrand from comment #2)
> The addtrack operation is synchronous, but it causes things to happen that
> are easier to describe as a queued task (stuff that happens in stable state).
> 
> Exemplar case:
> 
> createOffer().then(offer =>)
> AddTrack(track)
> 
> Will the offer include the added track or not?

What do we want the answer to be?

With addTrack() async the answer is *no*. The task that adds the tracks is still on the operations queue when the createOffer task is picked up.

With addTrack(), with a return value, we can decide how we want it to be. If a snapshot of the added tracks is taken when createOffer() is picked up by the JS scheduler and stored for later processing in the queued operation, the answer is *no*. If we don't look at the added tracks until the createOffer task is picked up, then the track will be included and the answer is *yes*.

We need to document this.

this = our decision (not what I wrote)

WebRTC API bugs have been moved to github issues: https://github.com/w3c/webrtc-pc/issues

Please subscribe to the issues you want to keep watching.