W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2019

[webrtc-pc] Rollback of pranswer is hard and unnecessary (#2235)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Mon, 22 Jul 2019 23:31:17 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-471395568-1563838275-sysbot+gh@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:
await pc.setLocalDescription({type: "answer", pc.localDescription.sdp});
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:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:48 UTC