[webrtc-pc] Should stopping the bundle-owning transceiver kill datachannels? (#2562)

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

== Should stopping the bundle-owning transceiver kill datachannels? ==
While implementing transceiver.stop, I found the following test:
```
  promise_test(async t => {
    const pc1 = new RTCPeerConnection({bundlePolicy: "max-bundle"});
    const pc2 = new RTCPeerConnection();
    t.add_cleanup(() => pc1.close());
    t.add_cleanup(() => pc2.close());
    const stream = await getNoiseStream({audio: true, video: true});
    t.add_cleanup(() => stopTracks(stream));
    const audio = stream.getAudioTracks()[0];
    const video = stream.getVideoTracks()[0];
    pc1.addTrack(audio, stream);
    pc1.addTrack(video, stream);
    const [dc1, dc2] = await createDataChannelPair(t, options, pc1, pc2);

    pc2.getTransceivers()[0].stop();
    const dc1Closed = new Promise(r => dc1.onclose = r);
    await exchangeOfferAnswer(pc1, pc2);
    await dc1Closed;
  }, `Stopping the bundle-tag when there is a ${mode} in the bundle ` +
     `should kill the DataChannel`);
```
Clearly the test-writer expected that when one stops a transceiver, the transport should close, and therefore the DC should close.

1) Is this written in the spec?
2) Is it the right thing to do?

The alternate reading is that the offer/answer with the stopped transceiver should move the transport data to another media section, and let that be the bundle leader. I don't know if we do that either.

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


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

Received on Tuesday, 11 August 2020 13:23:55 UTC