- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Jul 2020 15:02:58 +0000
- To: public-webrtc-logs@w3.org
> changing bundlePolicy is not possible ... @henbos Great! Thanks for catching that. But another case transports are stopped are shown in the crbug I link to: use `"max-compat"` when both end-points support bundle (which is common). The fiddle in the crbug has a pilot error, so here's a [working fiddle](https://jsfiddle.net/jib1/1en2jd4z/) that I think does the right thing in Chrome (all extra transports on offer get closed on processing the answer). > Not sure but I think this refers to if you do an ICE restart then you shouldn't create a new transport object. As I recall, the "terminalness" of connection states only applies until ICE restart happens. So technically it is not terminal... That makes sense, as there's a [similar](https://w3c.github.io/webrtc-pc/#rtcicetransport) (but not identical, difference highlighted) note for iceTranport: _"**An ICE restart for an existing RTCRtpTransceiver** will be represented by an existing RTCIceTransport object, whose state will be updated accordingly, as opposed to being represented by a new object."_ If ICE restart is what both notes refer to, I propose a PR to change the former note to match the latter. Except... > However stopping a transceiver may or may not stop the transport When we solved _"the BUNDLE problem"_ in https://github.com/w3c/webrtc-pc/pull/2220 we said it only existed on the answerer side, not in SLD on the offerer side where JSEP can easily reshuffle the _"offerer tagged"_ m-line. But `stop()` will still [stop sending and receiving](https://w3c.github.io/webrtc-pc/#dfn-stop-sending-and-receiving) immediately ON BOTH SIDES, which should fire the appropriate events on the local transport objects I claim. The only issue wrt to these notes I think is whether we ressurect the same transport object on SLD(offer) or create a new one. Since `transceiver.stop()` is terminal for the _transceiver_ being stopped, I see no benefit (only pain) in keeping events firing on that stopped `transceiver.(sender|receiver).transport`. For other transceivers affected indirectly through BUNDLE, I think I prefer changing their `transceiver.(sender|receiver).transport` to a new object, because that's consistent with what happens with `"max-compat"` and the fiddle. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2486#issuecomment-655575378 using your GitHub account
Received on Wednesday, 8 July 2020 15:03:00 UTC