[webrtc-pc] What happens when an answerer stops a transceiver that others are "bundled" on?

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

== What happens when an answerer stops a transceiver that others are "bundled" on? ==
The BUNDLE spec says:

> When an answerer wants to reject a bundled "m=" section in an answer, it MUST first check the following criterium:
> 
> -In the corresponding offer, an offerer BUNDLE address:port (previously selected [Section 8.3.1] or newly suggested [Section 8.5.1]) has been assigned to the "m=" section by the offerer.
> 
> If the criterium above is fulfilled the answerer can not reject the "m=" section in the answer (unless the answerer rejects each bundled "m=" section within the BUNDLE group).  The answerer can either reject the whole offer, reject each bundled "m=" section within the BUNDLE group, or keep the "m=" section within the BUNDLE group in the answer and later create an offer where the "m=" section is disabled within the BUNDLE group [Section 8.5.4].

Or, in [this PR](https://github.com/cdh4u/draft-sdp-bundle/pull/59/files) which changes the terminology:

> When an answerer wants to reject a bundled "m=" section in an answer, it MUST first check the following criterium:
> 
> - In the corresponding offer, the "m=" section is the offerer tagged "m=" section.
> 
> If the criterium above is fulfilled the answerer can not reject the "m=" section in the answer. The answerer can either reject the whole offer, reject each bundled "m=" section within the BUNDLE group, or keep the "m=" section within the BUNDLE group in the answer and later create an offer where the "m=" section is disabled within the BUNDLE group.

Either way, the point is the same. If you have an established bundle group, "a=BUNDLE audio video", the answerer can't reject the "audio" section without rejecting "video" as well.

So: how should this play with `RTCRtpTransceiver.stop`? Should stopping the audio transceiver automatically cause the video transceiver to be stopped as well? Or should the answerer keep the audio m= section (as "inactive", maybe?), then stop it in a subsequent offer triggered by `onnegotiationneeded`?

And does this require JSEP changes?

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

Received on Friday, 27 April 2018 18:56:49 UTC