W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2020

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

From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
Date: Mon, 21 Sep 2020 08:32:55 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-705398567-1600677174-sysbot+gh@w3.org>
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
Received on Monday, 21 September 2020 08:32:57 UTC

This archive was generated by hypermail 2.4.0 : Monday, 21 September 2020 08:32:58 UTC