It used to be the wild west but FCC is tightening up (maybe even going too far, we'll see). STIR/SHAKEN and KYC (know your customer) rules are making it more expensive for providers to allow any traffic over their networks. Shady providers would look the other way at spammers pumping traffic (providers getting paid); shady providers mix legitimate traffic in so upstream carriers can't just block them, etc.
Now, there's more regulatory teeth to go after the shady providers allowing this traffic.
I know FreeSWITCH and Kamailio both have WebRTC connections available, so if you use a SIP client in the browser over WebRTC to the server, you can plug into telephony networks on the server side.
We use Kamailio's WebRTC implementation heavily in Kazoo along with our libwebphone client. The transport is abstracted so Kazoo deals with the device and its configs; the Kamailio instance the browser connects to does the TLS termination for WebRTC. FreeSWITCH has the smarts for the SDP DTLS bits. And it all just works real nice together.
Curious how the Erlang->C++ progress is going? I asked a bit over a year about it (which I think prompted the pre-emptive note :) ); obviously not owed an explanation but perhaps you can get a quick update on whether the migrations are more painful than expected, or the scope of changes in-/decreased, etc?
Oh hi! It's going on - and indeed, your question prompted the note.
As one might expect, the original scope was ... insufficient. The exchange team have taken over the responsibility for new customer-facing stream API. The current one is starting to bump into a number of edges that were not obvious two years back.
I can however happily say that the first major migration is complete: the team moved settlements from the old Erlang-based system to C++. (The final remnants of the old component were removed from our tree less than a month ago.) This doesn't necessarily sound like much, but it required a lot of walltime due to multi-month shadow deployment. Since the last time we visited the topic, they have also migrated the market state updates from their old "teed off" feed to a dedicated subsystem with higher throughput and better reliability - though not without hitches.
A kafka client library bug caused them (and our customers) quite a lot of grief. The postmortem for that was rather uninteresting, even if the visible impact was bad enough. When the solution to a problem is "downgrade client library, wait until upstream fixes are in place, avoid local delta", the technical aspect scores quite high on boring.
Another component, a customer-facing "recent orders cache" subsystem written in C++ now augments its Erlang predecessor. A service designed to run in a K8S cluster from inception is obviously an easier deployment and maintenance target.
The two really big ones left are the actual exchange core ("matching engine") and market maker trading API. Both under active development. It'll probably be some months still before the new trading API can take over. And it will be a long road to validation, but the matching engine has also recently graduated to an early shadow mode, feeding off of the the order flow spigot.
We've used RabbitMQ since 2010 in KAZOO. I would argue, save one or two instances in the intervening 10 years, that RabbitMQ is the most stable piece of the infrastructure. I think it might be the only open-source project we build on that we haven't committed upstream to because we haven't encountered any issues in our usage.
The Regrarians [0] is another avenue to explore - I find Darren a bit more grounded in science than your average "permie" and appreciate the work he's doing, integrating holistic systems design (see Savory Institute), permaculture, and Yeoman's keyline design work. It seems more of a toolbox approach vs what can feel like "doctrine" at times from permaculture. Perhaps more suitable to larger farming operations than backyard gardens but still worth reading, I think.
Kazoo [0] offers this as a config option on devices (which can represent SIP desk phones, soft phones, WebRTC endpoints, or call-forwarded cell phones): call_forward.require_keypress [1] There's a lot of re-inventing of telecom wheels required (if even possible) with TwiML (and clones).
Now, there's more regulatory teeth to go after the shady providers allowing this traffic.