Re: [webrtc-pc] What happens to stopped transports? (#2486)

> 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