I think of webrtc-pc and JSEP as two sides of the same coin; I don't know if it makes sense to architect our code around a line that was drawn for bureaucratic reasons.

However, something I'd like to see eventually is a native webrtc API that's more modular, "ORTC-like" and SDP-agnostic. I don't think anyone's using it, but the beginnings were started here: https://cs.chromium.org/chromium/src/third_party/webrtc/api/ortc/

Then, eventually, we could move the implementation of the PeerConnection API from webrtc to Blink. Blink would implement both WebRTC 1.0 and WebRTC 2.0 on top of the same basic abstractions.

This would allow us to have a cleaner native API, with web/standards-related complexities confined to one layer (Blink).

The realignment - "blink objects are implemented in blink, not multiple layers, and one codebase has a clear drawn line about which specs it implements" - sounds appealing, initially, but upon reflection I want to echo deadbeef's concerns.

For me it has to do with usefulness, complexity and maintenance cost.
third_party/webrtc should be useful for building applications on top of.

webrtc-pc surfaces "useful APIs" on top of technical details of lower layer specs.
If we drew a hard line and said third_party/webrtc is only about JSEP and below, would every application building on top of webrtc that isn't Chrome end up implementing their own version of "useful APIs"? Reinventing the wheel = higher development cost and more dependencies = higher maintenance cost, less flexible-to-change interfaces.

As for complexity, as long as blink and webrtc live on different threads we CANNOT arbitrarily chose what we put where without bugs. The layers are not easily kept in-sync, and architecting our code based on a line based on bureaucratic rather than technical/useful reasons could be a mistake.

Something as conceptually simple as [[LastOffer]] / [[LastAnswer]] is an example of the complexity of maintaining and performing multiple states and operations across threads[1]. Me having to redesign setRemoteDescription() callbacks for synchronizing objects and events across layers is another example[2][3] (solving races, flakes, wrong order of events, spec-noncompliance, messy and inflexible code).

Something like ORTC *might* give us more flexibility and velocity without sacrificing usefulness, which is why external developers I've talked to has been excited about it, though I have not yet done my research on ORTC so I shouldn't speak about the pros/cons with confidence.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/966441/14/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp#819
[2] https://docs.google.com/document/d/1-cDDC82mgU5zrHacfFz720p3xwRtuBkOPSRchh07Ho0/edit?usp=sharing
[3] https://docs.google.com/document/d/1A2Qte4gKVLPhb8pDBB7cEUzkN1pVHAXwfGbfJJ698I8/edit?usp=sharing

I would like to see the webrtc signaling thread being the same thread as the main renderer thread, and that any operations described as asynchronous in the spec to be implemented as asynchronous in third_party/webrtc. This would mean that:
- Code is much simplified, no more thread jumps and keeping objects in-sync. Updating states of objects per webrtc-pc spec can be done as written in the spec, without thread jumps before and/or after said updates.
- Increase performance and decrease WebRTC footprint: We don't have to spawn another thread and the resources associated with that, we don't have to do thread jumps with every API.

I don't think the "we should not block the main thread" argument for splitting this up into two threads is valid when:
1. Most operations are blocking, waiting for the signaling thread, so we are not letting the main thread do its thing anyway.
2. If async operations are implemented as async and "do blah in parallel" are performed on the webrtc worker thread then the operations performed on the main thread would not be heavy weight. In fact they would be faster than today.

Is the argument against this that moving things from signaling thread to worker thread would require too much work and refactoring in third_party/webrtc?

Wrt to #4, note also that "main thread" is not really the main thread anymore.
After recent changes, most , if not all aynchronous operations that were on the main thread  are now performed on a per-frame sequenced task runner using a thread pool.

+tommi@ (see #4 and #5) would it be possible to make the webrtc signaling thread be the same as the per-frame sequence task runner?

If we could 1) get rid of this extra thread, and 2) make blink depend on webrtc directly, implementing webrtc-pc should be a breeze.

Concluded that title's idea was a bad one. Closing bug.