Video and Slides
Outline
How to architect your WebRTC application
Alberto González, CTO WebRTC.Ventures, & Arin Sime, CEO/Founder at WebRTC.ventures and AgilityFeat.
- There is no “one size fits all” application architecture for live video applications using WebRTC.
- The options vary widely based on your use case and choices between commercial and open-source options for back end services.
- In this presentation, we will discuss typical use cases and architectural considerations based on our experiences working with a wide range of clients.
Review
Alberto and Arin have worked on WebRTC for as long as I’ve known them. Whenever they take part in TADHack, I know we’re going to see some world-class hacks with real-world potential. The no BS approach of WebRTC.ventures / AgilityFeat is one of the reasons behind the implementation success of WebRTC.
In this presentation they cover:
- Why it’s not easy to build with WebRTC
- Open Source vs CPaaS
- SFUs and MCUs
- A standard 1-1 app
- Group Chat
- Live Interactive Broadcasting
- Contact Centers
Last year at TADSummit Asia I gave a presentation entitled, The Status of WebRTC across Asia, where a provided broad guidance on the options for building with WebRTC:
- Develop your own WebRTC-like system;
- Build on your own using open source pieces and developing your own orchestration and management;
- System integrators using open source and proprietary extensions and management platforms;
- CPaaS with no professional services;
- CPaaS partner;
- Use one of the few vertically integrated specialized solutions fitting your use case.
I lack the deep real-world experience of Alberto and Arin, so this provides the meat on the bones of what I provided last year.
I really like their slide 10 which summarizes the 3 main approaches. Everybody has a different situation, there is no one right answer.
The insights on scaling WebRTC are excellent, I agree strongly on the benefits of using both MCU (Multipoint Control Unit) that handles mixing of video/audio streams in a central server so each participant only has one stream to deal with. And SFU (Selective Forwarding Unit) where each participant only connects to the SFU, but receives unique streams for each participant.
This supports many capabilities such as interconnect to the PSTN for voice, yet many people still use voice for conferencing. Support for streaming of the conference, as well as connection to mobile devices.
The use cases are great, especially the ‘things to consider sections’ that can only come from years of experience. Thank Alberto and Arin for sharing your knowledge in such a clear, no BS way 😉
Thank you for a great presentation. I have some questions:
1) If you choose a CPaaS option, does that limit your MCU/SFU options?
2) Do you know of many projects where they “build your own stack”?
3) Given the complexity of WebRTC and the need to deeply understand existing and planned parts of the standard, as well as Google’s foibles, is this a niche of programmable communications service providers?
4) Across enterprise projects (not the RTC uber geeks) is open source media servers or CPaaS the dominant option?
5) Should a company be proficient in open source to be effective in using “Open source media servers” for their WebRTC application?
6) Of the 3 approaches your identity which do you think will become the dominant approach?
Hi Alan,
Those are really good questions! Answering to some of your questions below:
1) If you choose a CPaaS option, does that limit your MCU/SFU options?
Definitely, CPaaS are built with a specific architecture and while some can be more flexible than others (supporting SFU/MCU/Mesh architectures) there will always be limitations. It is very important to evaluate and find the right CPaaS for your use case.
2) Do you know of many projects where they “build your own stack”?
Projects won’t usually start taking this approach so in general is less popular. However, most of the WebRTC based applications that are build by large enough engineering teams or that his revenue is based on their video/audio advanced features will build their own stack.
3) Given the complexity of WebRTC and the need to deeply understand existing and planned parts of the standard, as well as Google’s foibles, is this a niche of programmable communications service providers?
I think so. This technology was underestimated. Now priority is being given to this and people is getting more familiar.
4) Across enterprise projects (not the RTC uber geeks) is open source media servers or CPaaS the dominant option?
I would say that for non-tech enterprises there is no doubt that CPaaS is the dominant. For tech enterprises, you might see as many projects using CPaaS as open source media servers. There are also cases that combine both.
5) Should a company be proficient in open source to be effective in using “Open source media servers” for their WebRTC application?
It is not necessary but think a company should understand the risks of open source and believe in it to build on top of open source media servers.
6) Of the 3 approaches your identity which do you think will become the dominant approach?
I think those 3 approaches will always be there. But the dominant one will depend on the type of project and industry. I think for traditional non-tech enterprises CPaaS will always be the best approach (even when we need to interact in the metaverse). For enterprises that are more tech oriented or where the full control of their WebRTC architecture is important, I think that open source media servers or WebRTC frameworks will become the dominant approach.