Closed Bug 1769802 Opened 5 months ago Closed 2 months ago

setRemoteDescription and setLocalDescription identity validation failures leave JSEP in new state

Categories

(Core :: WebRTC: Signaling, defect, P2)

defect

Tracking

()

RESOLVED FIXED
105 Branch
Tracking Status
firefox105 --- fixed

People

(Reporter: bwc, Assigned: bwc)

References

Details

Crash Data

Attachments

(9 files)

If identity validation fails, we should not be leaving JSEP in a state where the description was successfully set.

We cannot really rely on the JSEP engine's rollback here, since that only works for offers. We need a more aggressive rollback here. This is at least partially related to bug 1423365, which we may want to revive.

Ultimately, we may need to allow JsepSessionImpl to be deep-copied, so PeerConnectionImpl can copy it, run the operation on the copy, and if that operation (and all other related operations, which may be in PeerConnection.jsm) succeeds, overwrite mJsepSession with the new copy, and update pointers to JsepTransceivers everywhere it makes sense. Otherwise, we discard the new JSEP session, leaving the original totally unchanged.

Depends on: 1626414

If we're going to clone the JSEP engine, first we need to be able to clone SDP

Depends on D150167

The integer index we're replacing here is based on the order in which
transceivers were added. If we clone the JSEP engine for an sRD that happens to
result in the creation of a transceiver, and at the same time JS calls
addTransceiver, we have a situation where the sRD transceiver is added first
to the cloned JSEP engine, but the addTransceiver transceiver is added first
to the old JSEP engine, resulting in them having the same index. So, let's just
use a proper key for this stuff.

Depends on D150168

We could go to the trouble of teaching the JSEP engine to succeed/fail
atomically, but even if we did, we still need to be able to undo a successfully
executed sRD or sLD when identity-related stuff (in JS) fails. The simplest way
to get undo functionality is to clone the JSEP engine, and perform the
operation on one of the copies.

Depends on D150169

This will make it easier to replace the JsepTransceiver a given
RTCRtpTransceiver is using, which is necessary if we're going to be
deep-copying and replacing the JSEP engine.

Depends on D150170

The previous changeset was causing nullptr crashes because RTCRtpTransceiver
was performing an unlink before PeerConnectionImpl got a chance to close. It is
likely that there were already ways to trigger this bug.

Depends on D150171

This fixes a class of bugs where modifications to the RTCRtpTransceivers were
applied before sRD/sLD were completely done (while all of the JSEP and transport
stuff was finished, JS could still be working on identity-related stuff).

Depends on D150172

This fixes the class of bugs where identity-related failures could leave the
JSEP engine in a different state than the JS-observable state, and also the
class of bugs where a failure in the JSEP engine could leave the JSEP engine in
a weird halfway state.

Depends on D150173

Attachment #9282658 - Attachment description: WIP: Bug 1769802: Test-cases for bug. → Bug 1769802: Test-cases for bug. r?jib
Attachment #9282659 - Attachment description: WIP: Bug 1769802: Deep clone stuff for SDP. → Bug 1769802: Deep clone stuff for SDP. r?ng
Attachment #9282660 - Attachment description: WIP: Bug 1769802: Key JsepTransceiver by UUID instead of a simple integer index. → Bug 1769802: Key JsepTransceiver by UUID instead of a simple integer index. r?mjf
Attachment #9282661 - Attachment description: WIP: Bug 1769802: Make the JSEP engine cloneable. → Bug 1769802: Make the JSEP engine cloneable. r?mjf
Attachment #9282662 - Attachment description: WIP: Bug 1769802: Stop holding a reference to the JsepTransceiver in RTCRtpSender/Receiver. → Bug 1769802: Stop holding a reference to the JsepTransceiver in RTCRtpSender/Receiver. r?mjf
Attachment #9282663 - Attachment description: WIP: Bug 1769802: Ensure that PeerConnectionImpl is in charge of unlinking (except when it shouldn't be, ugh). → Bug 1769802: Ensure that PeerConnectionImpl is in charge of unlinking (except when it shouldn't be, ugh). r?mjf
Attachment #9282664 - Attachment description: WIP: Bug 1769802: Call the success callback for sRD/sLD after the JS work is done. → Bug 1769802: Call the success callback for sRD/sLD after the JS work is done. r?jib
Attachment #9282665 - Attachment description: WIP: Bug 1769802: Ensure that sRD/sLD fail atomically. → Bug 1769802: Ensure that sRD/sLD fail atomically. r?jib
Pushed by bcampen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7db66c7d7f46
Test-cases for bug. r=jib
https://hg.mozilla.org/integration/autoland/rev/58439a6601ff
Deep clone stuff for SDP. r=ng
https://hg.mozilla.org/integration/autoland/rev/87692ef0b35d
Key JsepTransceiver by UUID instead of a simple integer index. r=mjf
https://hg.mozilla.org/integration/autoland/rev/732e02234941
Make the JSEP engine cloneable. r=mjf
https://hg.mozilla.org/integration/autoland/rev/fb9d2e7e5fae
Stop holding a reference to the JsepTransceiver in RTCRtpSender/Receiver. r=mjf
https://hg.mozilla.org/integration/autoland/rev/b046b56d111f
Ensure that PeerConnectionImpl is in charge of unlinking (except when it shouldn't be, ugh). r=mjf
https://hg.mozilla.org/integration/autoland/rev/9c544f877fa4
Call the success callback for sRD/sLD after the JS work is done. r=jib,webidl,smaug
https://hg.mozilla.org/integration/autoland/rev/d25d7e866391
Ensure that sRD/sLD fail atomically. r=jib
https://hg.mozilla.org/integration/autoland/rev/52f3bf105790
Make sure we apply addTrack magic when redoing sRD. r=jib
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/35355 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
Duplicate of this bug: 1766668

Copying crash signatures from duplicate bugs.

Crash Signature: [@ mozilla::JsepSessionImpl::CheckNegotiationNeeded]
Regressions: 1783765
Regressions: 1783781
You need to log in before you can comment on or make changes to this bug.