Re: [webrtc-pc] Firing the right events in "rollback": Which description to use? (#2332)

@jan-ivar Please take a look at this comment and let me know if I've discovered a bug or if I am confused again.

> I think this is the right logic. This description value is never set. It's used in the remainder of the algorithm solely to undo events fired and tracks moved based on remote descriptions.

We're on the same page here that this is the intent.

However, if you look at the steps, it modifies stuff like the [[Receptive]] slot and transports too. Which I suppose is only appropriate, e.g. early media use case. Mids also get assigned, but those are immutable between offer and answer, so that is not a concern, whichever SDP we get would be useful. But anything that could change between offer and answer could potentially get reverted to the "have-local/remote-offer" state rather than the previous stable state?

The [[Receptive]] one could be a big concern, if that value is wrong we could be in a state where a track that should unmute doesn't or a track that shouldn't unmute does based on packets on the wire.

SLD(offer) might have created bundle transports, which at SRD(answer) disappears.
In a follow up O/A that gets rolled back, setting _description_ to [[CurrentLocalDescription]] might cause transports to change not to the transports as they were at "stable" (e.g. SRD(answer)), but the transports as they were at "have-local-offer" (e.g. SRD(offer)).

The direction might be different... e.g. in stable we could be receiving and an offer to stop receiving (mute the track) comes in, then we roll that back: which direction do we use to make sure ontrack/onmute behaves correctly?

> The most utilitarian way to undo these SRD actions (offer or answer, doesn't matter), is to re-apply the previous remote description if there is one [...]

Why the previous _remote description_? Why not the previous _description that got us to stable_, i.e. the current description that is of type "answer"?

Examples where I think the current logic bites us:

pc1.SLD(offer) with bundling; multiple transports are offered.
pc1.SRD(answer), only one transport remains because bundling was accepted.
In a follow-up O/A exchange, reverting to [[CurrentLocalDescription]] due to rolling back a local offer will resurrect the transports, even though in stable they had already been discarded.

This may get fixed if we explicitly revert transports ([slide](https://docs.google.com/presentation/d/1QEdMf6Ixg1NNvHoZUvO29njrSKn9pdF1WqcrFWI4uX8/edit#slide=id.g6b7f95ec98_0_6)), but it would seem strange to temporarily resurrect them only to override them.

pc1.SRD(offer) with direction 'sendrecv'.
pc1.SLD(answer) making currentDirection 'inactive'.
In a follow-up O/A exchange, reverting to [[CurrentRemoteDescription]] due to rolling back an incoming remote offer, will fire ontrack, even though in stable state the transceiver was inactive.

-- 
GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2332#issuecomment-558287011 using your GitHub account

Received on Monday, 25 November 2019 18:42:49 UTC