setRemoteDescription and setLocalDescription identity validation failures leave JSEP in new state
Categories
(Core :: WebRTC: Signaling, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox105 | --- | fixed |
People
(Reporter: bwc, Assigned: bwc)
References
(Regressed 1 open bug)
Details
Crash Data
Attachments
(9 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
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.
Assignee | ||
Comment 1•2 years ago
|
||
Assignee | ||
Comment 2•2 years ago
|
||
If we're going to clone the JSEP engine, first we need to be able to clone SDP
Depends on D150167
Assignee | ||
Comment 3•2 years ago
|
||
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
Assignee | ||
Comment 4•2 years ago
|
||
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
Assignee | ||
Comment 5•2 years ago
|
||
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
Assignee | ||
Comment 6•2 years ago
|
||
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
Assignee | ||
Comment 7•2 years ago
|
||
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
Assignee | ||
Comment 8•2 years ago
|
||
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
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 9•2 years ago
|
||
Assignee | ||
Comment 10•2 years ago
|
||
Depends on D150174
Assignee | ||
Comment 11•2 years ago
|
||
Try looks good so far:
https://treeherder.mozilla.org/jobs?repo=try&revision=0c8408990985d91831677b4ea0891142c1d48a99
https://treeherder.mozilla.org/jobs?repo=try&revision=eded99b3f2f0be56f8d1cb9ec9ff77e8f90399eb
I think I'll re-run the gtest suite, just in case.
Comment 12•2 years ago
|
||
Comment 14•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7db66c7d7f46
https://hg.mozilla.org/mozilla-central/rev/58439a6601ff
https://hg.mozilla.org/mozilla-central/rev/87692ef0b35d
https://hg.mozilla.org/mozilla-central/rev/732e02234941
https://hg.mozilla.org/mozilla-central/rev/fb9d2e7e5fae
https://hg.mozilla.org/mozilla-central/rev/b046b56d111f
https://hg.mozilla.org/mozilla-central/rev/9c544f877fa4
https://hg.mozilla.org/mozilla-central/rev/d25d7e866391
https://hg.mozilla.org/mozilla-central/rev/52f3bf105790
Comment 17•2 years ago
|
||
Copying crash signatures from duplicate bugs.
Description
•