Bug 244002

There are 2 possible approaches: a. Somehow move the transport GStreamer elements to the network process, using the newly gstwebrtc ICE split that will ship in GStreamer 1.22. That will require GStreamer initialization in the network process + a custom pipeline there, unless I misunderstood the intent. This approach is still not clear to me. b. Abstract sockets handling in libnice, perhaps using a factory pattern. That would allow the Agent to request sockets creations from the WebProcess, we could then build a socket wrapper similar to the existing infrastructure in-place already for the libwebrtc backend. This is lower-level, but imho nicer...

Another option, which looks "nicer", would consist of using librice (https://github.com/ystreet/librice) which would eventually be supported by GstWebRTC. Then we could make a WebKit-specific network backend for librice.

For now I'm submitting a libnice backend. Later with librice we can have another backend...

Pull request: https://github.com/WebKit/WebKit/pull/48903

(In reply to Philippe Normand from comment #3) > For now I'm submitting a libnice backend. Later with librice we can have > another backend... The libnice approach doesn't work out, it's prone to deadlocks, sync IPC calls and some internal MediaStream code (related with tracks observation stopping and closing down the PeerConnection) compete to run on the main thread... This was a nice experiment but I'm afraid not the way forward. We've learned some new things though that hopefully will apply to the librice backend yet to be written.

I have a working librice-based backend in https://github.com/philn/WebKit/tree/wip/webrtc-rice Likely some leaks to fix and iterate a bit, but it's looking like the way forward :)

Pull request: https://github.com/WebKit/WebKit/pull/50740

Committed 303623@main (53277244d7bb): <https://commits.webkit.org/303623@main> Reviewed commits have been landed. Closing PR #50740 and removing active labels.

<rdar://problem/165516876>