Large conferences translates to media server, network, sometimes interop, and eventually session control requirements.

Ideally, media servers with excellent IP connections, distributed around the world, and behind GeoDNS.

It also often means some interop capabilities (signaling and/or media interworking), since many large conference use cases include some users on traditional video (SIP or H.323), Lync/Skype For Business and/or PSTN.

Finally, session control becomes important if we get into enterprise and service provider conferencing markets.

Those reqs - especially media intensive ones - are interesting in that they are mostly not Twilio's core competency. Do they build it? Partner for it? Do they care enough about those use cases?

The answers to those questions are very interesting given Twilio's tremendous developer ecosystem.

Some Ns are larger than others. :-) At Talky, we can scale up to 15-25 participants using the excellent Jitsi Videobridge as a selective forwarding unit, and the results are similar at Jitsi Meet. Even at that relatively small scale, your browser might melt down depending on your hardware. Beyond ~25 we'll need to look at something more like a broadcast scenario a la Hangouts on Air (e.g., do you really need 25+ people actively participating and sending video at the same time?). As gz5 notes, that might imply a need for session control and moderation queues and such, or a larger group of passive audience members with the ability to temporarily grant send privileges to select users as needed. Those are all fun problems to solve. :-)

Hey, my coworkers and I built https://OpenTokRTC.com to test OpenTok (also a webrtc API) video streams. We've tested it with 15 people a year ago and it worked great. I would imagine that they have improved even more at this point in terms of scalability and quality. You can also test the android/ios companion apps, they all interoperate pretty nicely. As an added bonus, they also support real time video recording and playback, which is really nice.

Twilio's step into video streaming more interesting than video itself though, because now you can have the ability to call into a webrtc video conference, which can be pretty cool.

Here at Sococo (I work there) we support 20+ clients per meeting. Audio, video, doc sharing, rich presence info, always-on but no bandwidth burden when you're not meeting. Free to try!

We use it ourselves for our Agile process, doing ad-hoc meetings all day in various bullpens; Scrum each morning with 20+ participants; all-hands meetings once a week with a shared presentation. And all day I can see who is meeting with whom in my group. Its really pretty performant.

Connections are P2P for small meetings (<=4) but switches in an MCU automatically when more people 'enter the room'. Still, if you're on the same subnet (in the same building) with some of the participants it keeps those connections P2P based on ping time.

We're distributed across 5 states and 3 countries. Everybody has an equal footing in the meetings since we're all on-line. Even people in the same office (we have several small offices) attend using Sococo - I can see other attendees in the background of some people's videos :)

Thought I'd mention jitsi (https://jitsi.org) since it seems to aim to do what you are wanting. I am not sure how many connections it practically supports currently though.

Jitsi, licode, janus ... there are a whole list of them, open-source. Unfortunately they conflate the MCU feature with the SDP exchange feature. Which may or may not suit your application. For instance if you want to connect clients in anything but an everyone-in-the-room-hears-everyone-else model, they don't support anything else.

Bingo. You hit the nail on the head. To efficiently do large conferences, you need to both multiplex audio and video at the media server layer and have a concept of active speakers.

You can write your app to use one of those MCUs for large conference, and accomplish the audio/video multiplexing via those MCUs. But only in a logical full-mesh configuration. So for instance 100 people listening to 6 panel members but not one another - not easy. Not unless the clients cooperate and carefully trim the streams for audience peers (fail to subscribe to them), just leaving the panel streams. It becomes complicated very fast.

Jitsi Videobridge has both of those.

Jitsi only does the audio portion. There's no support for layouts/video mixing.

"Jitsi Videobridge does not mix the video channels into a composite video stream, but only relays the received video channels to all call participants."

Joe, this is actually not true. At least not for Jitsi where we have things like last N and possibilities to have 1:m or n:m sessions ...

There's also absolutely no usage of SDP Offer/Answer in Jitsi Videobridge

I think you've hit the nail on the head, here. WebRTC is really great for a handful of people. Implementation using some third party was never the difficult part, but scale was and is still a total nightmare.

I'd love to see WebRTC done by a service provider in a highly scalable way, so I can stop relying on RTMP (and typically embedding a flash player to support it) to deliver live streaming audio/video on a large scale.

As someone who has only leveraged WebRTC through third party providers (e.g., OpenTOK, etc.), I have no idea the complexity of what I'm asking for. Perhaps it's boil the ocean difficult, but it sure would be nice to have!

Yeah, I don't think that it is boil the ocean difficult but there is definitely some complexity there. I have been working on a scala WebRTC server, but I am not sure if it would really work at a large scale

Here was my basic approach:

An end user creates a PeerConnection with a Publisher node and starts sending a MediaStream using a string identifier.

Then another user can create a PeerConnection with a Subscriber node using the same identifier.

The Subscriber node then makes a request to the Publisher to make another PeerConnection to a Registry that exists on the same node as the Subscriber.

The replicated MediaStream can then be attached to the Subscriber.

Since the replicated MediaStream is in a Registry, any additional subscribers can attach the MediaStream on the same node as well.

The code is a huge mess but it is here (The scala server is in the media directory): https://github.com/jgrowl/livehq

There is a vagrant file that brings up the whole system at the root of the project (using docker). I have not tested it recently on anything other than ubuntu.

I've been working on exactly this. It's not horribly difficult if you've got experience building media servers, but it is tedious, because WebRTC has so many more moving parts than eg, RTMP, and the tooling is not very mature yet. Not to mention WebRTC itself is still a bit in flux (eg, ORTC).

Unfortunately, until IE and Safari support WebRTC, then RTMP is really still the best way to do low-latency streaming and video chat in the browser. Additionally, most RTMP server software will scale out to hundreds of clients out of the box.

Yep, absolutely right. Although I appreciate Twilio's approach all of this was easy before and the libraries exist in many variations... If you're doing WebRTC though Twilio's TURN service is very cheap and worth looking at

Blue Jeans solves this at scale, with higher quality than WebRTC alone, while also supporting video conferencing equipment joining the same meetings.

Transcoding is tough with unique views per client, but audio processing is tougher. :)

Interesting, is the 15 person cap a new thing? I remember it was still 10 at some point.

I think it is 10 for ad-hoc Hangouts, but you can raise it to 15 if you attach the meeting to a calendar invite.

Awesome!