1728367 - RTCPeerConnection-setDescription-transceiver.html expects a stopped transceiver to have currentDirection == "inactive"

Status: NEW

(Core :: WebRTC: Signaling, defect, P3)

Description

[Byron Campen [:bwc]]

The spec says that when a transceiver is stopped, the currentDirection should be set to null:

https://w3c.github.io/webrtc-pc/#dfn-stop-the-rtcrtptransceiver

This test case causes the transceiver in question to be stopped by rejecting it with negotiation:

https://searchfox.org/mozilla-central/rev/ad2ffab089e4e0c0fe99a1a046ab2b1c45546bdb/testing/web-platform/tests/webrtc/RTCPeerConnection-setDescription-transceiver.html#252-257

The spec says that this is one of the cases where the "stop the RTCRtpTransceiver" is run:

https://w3c.github.io/webrtc-pc/#ref-for-dfn-stop-the-rtcrtptransceiver-1

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Byron Campen [:bwc] from comment #0)

The spec says that when a transceiver is stopped, the currentDirection should be set to null:

Firstly, currentDirection would be "stopped" instead of null.

But RTCPeerConnection-setDescription-transceiver.html is misleading and is testing something else: it is testing that stop() "Irreversibly marks the transceiver as stopping" — not stopped. See bug 1568296.

So the test is still correct, but is not testing the "stopped" case. It is testing pc2 (not pc1) calling stop() in "have-remote-offer".

The spec says that this is one of the cases where the "stop the RTCRtpTransceiver" is run:

https://w3c.github.io/webrtc-pc/#ref-for-dfn-stop-the-rtcrtptransceiver-1

This is different, and applies when an m-line is rejected in the offer (by pc1.stop()). E.g. https://jsfiddle.net/jib1/76c1hogy/