- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 22 Jul 2019 23:31:17 +0000
- To: public-webrtc-logs@w3.org
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:
== Rollback of pranswer is hard and unnecessary ==
Rolling back back from `"have-remote-pranswer"`/`"have-local-pranswer"` can be as hard as rolling back from `"stable"`.
When an answer or pranswer comes in, stuff is set in motion in the transport & media stacks. To roll that back would require we:
1. Undo "start transmitting RTP media" and/or "stop transmitting all RTP media" in [JSEP](https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.11).
2. Undo "prepare to initiate a SCTP association" and the [creation](http://w3c.github.io/webrtc-pc/#dfn-create-an-rtcsctptransport) of the `RTCSctpTransport`.
3. Undo "discard any ICE components for the m= sections that will be bundled ... and begin muxing"
4. Roll back any ICE restart, which [JSEP](https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.10) finalized in pranswer. There's no way to rescind new `candidate` events that may have fired and been sent over the signaling channel to replace the current candidates.
It also hardly seems necessary. With [perfect negotiation](https://blog.mozilla.org/webrtc/perfect-negotiation-in-webrtc/) where both sides are browsers with state machines, glare is detected in earlier states.
Should one end up in this state, an [easier way out](https://jsfiddle.net/jib1/7ejav9y3/) seems to be:
```js
await pc.setLocalDescription({type: "answer", pc.localDescription.sdp});
```
```js
await pc.setRemoteDescription({type: "answer", pc.remoteDescription.sdp});
```
I propose we drop rollback of pranswer and throw `InvalidStateError` instead.
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2235 using your GitHub account
Received on Monday, 22 July 2019 23:31:18 UTC