As the main author of Janus, I didn't appreciate at all them proactively suggesting Calls as a replacement for existing deployments based on Janus and mediasoup. I'd understand them aggressively marketing against other RTC cloud providers like Agora, Twilio, and others: trying to "steal" users from open source projects (who share everything and so often live on consulting) really feels like a d*ck move, instead, and basically stealing candy from kids.
Then I think what you can use are the Lua or Duktape plugins, which were indeed written to allow people to write their own logic without having to worry about C or forks: even if the C code of the plugins is updated, your code is in a script that is loaded dynamically and is external to them.
If you forget about the videoroom.lua code and do something from scratch, you're free to handle the logic however you want: handling media is as simple as saying "send incoming media from A to B and C", and media-wise that's all you need to do in the script itself to have the C portion do the heavy lifting for you. You still need to take care of SDP and signalling, but you can do that on your own terms. I still have a plan to implement yet another plugin that delegates the logic to a remote node using something RPC-based, but unfortunately I didn't have time for that yet.
Janus only supports WebRTC, and WebRTC doesn't support MPEG out of the box (to be more precise, it's not in the codecs list any endpoint supports). Besides, streaming happens over WebRTC, not WebSockets: we only use WS as one of the alternative "transport" protocols for the Janus API, so just signalling.
Why's that? We wrote it to be functionally identical to the Lua plugin (the code base is the same), so engine and language apart they should behave pretty much the same way. Is there any known issue or limitation you're aware of?
Not sure what you were expecting: at the very foundation of WebRTC is SDP, which implies negotiation, and with endpoints supporting potentially different codecs, negotiation is very much important whether you like it or not. That's why the VideoRoom plugin does need to take that into account. I won't get into the discussion of how complex a fork is to maintain: I always hope people contribute back what they add (assuming it's generic enough to fit the project and not customer-specific), rather than keeping it to themselves.
That said, the vast majority of people don't really need to write their own plugin, or even customizing existing ones. What we foster a lot is leveraging existing plugins as much as possible, maybe combining them at an application level, and not reinvent the wheel, and it seems to work for most (it certainly does for us, for our own applications).
On the Lua demo, it is indeed a bit more limited than the C counterpart (we clearly didn't invest as much time on it), but I'd disagree on the "incomplete" part. All the relevant parts are there, and most importantly, it's supposed to be much easier to extend and modify than the C version. There's at least one big company we're aware of that's using it in production and is very happy with it.
It's not like Rust or Golang will magically save you either. I've been programming for a long time, C is my main language, so that's what I started using at the time and what I'm using still today. We worked a lot on performance and stability, so hopefully it won't suck nevertheless ;-)
I didn't know anyone else apart from me and and my tutor had read my Ph.D Thesis... :-) Glad you found it informative! Janus was indeed born during my research efforts there.