6 ms·

I was really excited by the title but this seems a bit lacking. I've done a lot of WebRTC work -- we currently use Google Hangouts everywhere at Stack Exchange

by jc4p 12y ago

I was really excited by the title but this seems a bit lacking. I've done a lot of WebRTC work -- we currently use Google Hangouts everywhere at Stack Exchange for internal team communication, but the 15 person cap hurts some bigger all-hands calls or our weekly remote parties. I don't think the hardest part of WebRTC is transcoding or TURN servers (what Twilio seems to be offering), multiplexing is where all the complexity comes from. It's very easy to set up a video chat interface via WebRTC small-scale, and good on Twilio for focusing on making it easier to integrate mobile clients too, but I can't wait until someone (most likely the Talky.io team seeing how their betas are going) makes it a bit easier to have large N connections (right now on Hangouts N is 15, on my own stack N is around 10).

sytse 12y ago
Interesting, is the 15 person cap a new thing? I remember it was still 10 at some point.
- willkelleher 12y ago
  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.
  - sytse 12y ago
    Awesome!
gz5 12y ago
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.
JoeAltmaier 12y ago
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.
- JoeAltmaier 12y ago
  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 :)
jgrowl 12y ago
Thought I'd mention jitsi (https://jitsi.org 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.
- JoeAltmaier 12y ago
  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.
  - kolencherry 12y ago
    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.
    - JoeAltmaier 12y ago
      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.
    - emcho 12y ago
      Jitsi Videobridge has both of those.
      - kolencherry 12y ago
        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."
hootener 12y ago
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!
- jallmann 12y ago
  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.
- jgrowl 12y ago
  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 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.
songzme 12y ago
Hey, my coworkers and I built https://OpenTokRTC.com 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.
- songzme 12y ago
  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.
tommoor 12y ago
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
stpeter 12y ago
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. :-)
mcs 12y ago
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. :)

by jc4p 12y ago

sytse 12y ago

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

willkelleher 12y ago
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.
- sytse 12y ago
  Awesome!

gz5 12y ago

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.

JoeAltmaier 12y ago

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.

JoeAltmaier 12y ago
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 :)

jgrowl 12y ago

Thought I'd mention jitsi (https://jitsi.org 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.

JoeAltmaier 12y ago
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.
- kolencherry 12y ago
  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.
  - JoeAltmaier 12y ago
    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.
  - emcho 12y ago
    Jitsi Videobridge has both of those.
    - kolencherry 12y ago
      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."

hootener 12y ago

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!

jallmann 12y ago
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.
jgrowl 12y ago
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 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.

songzme 12y ago

Hey, my coworkers and I built https://OpenTokRTC.com 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.

songzme 12y ago
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.

tommoor 12y ago

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

stpeter 12y ago

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. :-)

mcs 12y ago

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. :)