addTrack's streams parameter is unused.

[jan-ivar]

We must either specify how this parameter is to be used, or remove it.

[jan-ivar]

This applies to addTransceiver as well btw. It would be nice if the overall intent of this parameter was described. Also:

Is the parameter optional?
Should the API fail if a passed-in track is not in all or any of the passed-in streams?

I think the answers are yes and no respectively, because users can do this:

var track = stream.getTracks()[0];
pc.addTrack(track, stream);
stream.removeTrack(track);

or even this:

var transceiver = pc.addTransceiver ("video", { streams: [stream] });
transceiver.sender.replaceTrack(track).catch(e => console.error(e));

where replaceTrack is defined to explicitly ignore stream associations.

So I think I'm good, but this could be a lot clearer.

[jan-ivar]

Is the parameter optional?

Sorry, this was resolved in #288 (it is), but the remaining question stands (validation), and I hope we agree that processing models should explain to implementers exactly what to do with input parameters.

[alvestrand]

Copying over comment from #426: The expected result is that there are MSIDs for those streams listed in the SDP. This will probably take a JSEP reference (not sure where).

[adam-be]

I agree with @jan-ivar that this processing model needs to be detailed out.

The addTrack() steps don't say much about how the track should be used either. Just that it's set on the sender object. This section needs some work. We should be able to define some steps that can be shared between addTrack() and addTransceiver().

[adam-be]

Proposed fix: PR #702