[webrtc-pc] Local versus remote rollback, and clarifying implicit SRD-rollbacks (#2294)

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

== Local versus remote rollback, and clarifying implicit SRD-rollbacks ==
Confusion ensued in https://crbug.com/980875 when discussing implementing the implicit rollback in Chrome. Mainly,
1. Should we roll back only local offers, only remote offers, or either type of offer when setRemoteDescription is called with a description and we implicitly roll back due to the signalingState not being stable?
2. Is there a difference between SLD(rollback) and SRD(rollback)?

We treat SLD-rollbacks and SRD-rollbacks differently it seems: in SLD-rollbacks we null the [[PendingLocalDescription]] and in SRD-rollbacks we null the [[PendingRemoteDescription]]. However, other wording says to update the states according to the description that is being rolled back, which would work regardless of the description being rolled back was local or remote. See [](https://w3c.github.io/webrtc-pc/#set-the-rtcsessiondescription).

If we look JSEP, section 4.1.9. says "[...] rollback, which results in a revert to the current local description" in the description of the function. However, if we look at the actual algorithm steps, both SLD and SRD says to process rollbacks according to [section 5.7](https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.7), which explicitly says that "The effect of rollback MUST be the same regardless of whether setLocalDescription or setRemoteDescription is called."

This would have me believe that the answer to 2) should be No, and that we should null both pending descriptions when rollback happens. This would imply that the answer to 1) is that both types of offers are rollbed back, unless we explicitly add clauses that examines the signalingState and only applies the rollback if it is the type of rollback that we are interested in.

@jan-ivar @aboba 

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

Received on Monday, 9 September 2019 09:16:43 UTC