This does use a real WebRTC stack (specifically libdatachannel - https://libdatachannel.org https://libdatachannel.org). Under the hood this is making real WebR

This does use a real WebRTC stack (specifically libdatachannel - https://libdatachannel.org https://libdatachannel.org). Under the hood this is making real WebRTC connections. But I guess you mean why it doesn't mock using real peers in the browser where the tests are happening, using the browser's existing stack there? There's a few reasons I've avoided that: * Primarily: I want to do things that the browser APIs won't let you do. E.g. sending invalid data, or intentionally causing various types of errors. The browser APIs are designed to stop you doing the wrong thing, by keeping the raw data at arm's length. Very sensible for normal WebRTC usage, but bad for testing edge cases and breaking things. * Similarly I want access to the raw RTP data, to derive metrics, track metadata, and generally fiddle around with it. AFAIK browsers only let you access processed video, not the raw packets. * I want to use this to build a WebRTC proxy, and then independently launch one or more browsers and redirect their traffic through it, which means the proxy has to live independently from the browsers (and I don't want to launch a whole separate headless browser instance just to 'host' that proxy). * I want the option to intercept WebRTC connections from non-browser clients too. Most of that isn't strictly required for the basics, but it's all nice to have, and if you do everything inside the same browser with the standard APIs then it's all completely off the table. If you use a lower-level library, you get a lot more control, and all these become possible.