[webrtc-pc] Unassociated, stopped transceivers after createOffer: Present or absent? (#2576)

alvestrand has just created a new issue for https://github.com/w3c/webrtc-pc:

== Unassociated, stopped transceivers after createOffer: Present or absent? ==
Consider this code snippet:
```
const pc = new RTCPeerConnection();
const transceiver = pc.addTrack('audio');
pc.addTrack(video);
transceiver.stop();
await pc.setLocalDescription(await pc.createOffer()); // Offer is video only
// MYSTERY PLACE
await pc.setRemoteDescription(remoteAnswer); // Answer is also video only. Creating answer left out for compactness.
assert_equals(pc.getTransceivers().length, 1);    // Only video remains
assert_equals(transceiver.currentDirection, null);  // The stopped one has never been used.
```
Now: In the MYSTERY PLACE, what length shoiuld pc.getTransceivers() return?

According to the spec-as-written, it should return 2 - the stopped one and the video one - because stopped transceivers are ONLY removed from the set of transceivers when applying answers. Not when creating offers.

This means that pc.getTransceivers() will contain an element that is irrelevant to the current offer/answer exchange.
Is that a correct reading of the spec?
Is that a reasonable behavior?

Two possibilities (if correct):
- It is correct and reasonable. No change needed.
- It is correct, but not reasonable. Modify pc.setLocalDescription to discard stopped transceivers that have never been associated with a media section.

Discuss.


Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2576 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config