As for implementation, I've already created the dashboard and studio panel components for this in January. So it only requires connection to the SFU, websockets and some polishing /testing. So we could have this up and running in a week or two (potentially with the C2 phone carrier release).

We can use connect.studiio.* to host the captive portal for the widget (and use a websocket for realtime room status), invitations will live on the captive portal too and work the same way (just with name pre-population).

As for pricing, we are investing in the infrastructure up-front under our existing AWS SP so costs are very low. This will very much likely be included for free in all Studiio plans (no per-min pricing, caps or excess usage).

Jason Jordan I know you've created your own version of this yourself recently, but let me know if you're still interested in testing our implementation! :-)

Dev update:

I began testing 4 types of architecture for this feature a few months ago, we've tested:

Twilio and Cloudflare were options for us to try for quick setup. Twilio was pretty expensive, Cloudflare was cheaper. Both 3rd party platforms carry tech debt risk and depreciation with no clear pathway to switch providers/protocols easily if either services went down or were depreciated (we don't want a repeat of our C1 carrier issues with this! ergh).

Custom WebRTC/P2P was okay, but limitations on how many streams/participants (<5) is a big factor (vs other services who offer 10+). I feel like if we went down this route, it would not be production stable and we would be looking at an upgrade to support more streams/participants.

Custom WebRTC with a custom SFU (built in AWS on Kubernetes and using our Redis cache) was great, stable streams (up to 5000/128kbps) through a tX.medium server with Redis, P2P fallback with TURN. Very stable audio connection with SFU routing, quality up to 256kbps (cap at 128kbps as we're dealing with voice anyway). I think this is the winner for us for features, capacity and cost.

With an SFU layer, we can also implement IP rate limiting and other security related controls, session stickiness (good for when calls drop temporarily) and it remains separate from talkback-rest which is an added layer of redundancy.

As for recording calls, we can re-use our recording engine from phone calls to capture 320kbps audio. Added benefit is the recording for all participants will be 320kbps (local) which is a huge improvement over PSTN recordings.

Longevity isn't an issue as we're hosting our own stack (no 3rd party platforms to rely on or pay), and reliability seems an acceptable risk with multiple fallbacks (SFU place, P2P, WS). We have multiple avenues for audio to route if one fails.