A media server in a WebRTC infrastructure plays a critical role in scaling a WebRTC call beyond 4 participants. Whenever you join a call that has 8-10 participants or more, know that a media server is doing the hard work behind the scene to provide you with a smooth audio/video experience. If you have a need for building a WebRTC infrastructure and you need to select a WebRTC media server for your use case, then this post is going to help you with enough information to take an informed decision.
Why and When a WebRTC Media Server is required?
A WebRTC Media Server is a critical piece of software that helps a WebRTC application distribute audio/video streams to all the participants of an audio/video meeting. Without them, creating a large audio/video call beyond 4 users would be a highly difficult task due to the nature of WebRTC calls. WebRTC calls are designed for real-time use cases (<1 second of delay between the sender and receiver of an audio/video stream). In this case, a user sending his/ her audio/video streams has to send the streams to all the participants who are joining the conference for viewing it in real-time, so that a real conversation can happen. Imagine a call with 10 people, where everybody is sending his / her audio/video stream to rest 9 people(other than himself/herself) so that they can view it in real time. Let’s do some maths to find out some interesting details.
When a user joins an audio-video call that is running on WebRTC, he/she can share either audio/video/screen or all of them together.
If joined only with audio: ~40Kbps of upload bandwidth is consumed
if joined with only video: ~ 500Kbps of upload bandwidth is consumed
if joined with only screen share: ~ 800 Kbps of upload bandwidth is consumed
if all 3 are shared together : ~1340Kbps or 1.3Mbps of upload bandwidth is consumed
If there are 10 people in the meeting, then 1.3 * 9 = 11.7 Mbps of upload bandwidth will be consumed every second! Remember that you need to send your audio/video/screen-share or all of them together to everybody else except yourself. Anybody who doesn’t have a consistent 11.7Mbps bandwidth, can’t join this meeting!
This also brings another challenge for the device being used by the user to join the conference. The CPU of the device has to work very hard to compress and encode the audio/video/screen share video streams to send over the network as data packets. If the CPU has to spend 5% of its capacity to compress and encode the users audio/video/screen-share streams to send it to another user who has joined the meeting, then it has to spend 9 * 5 = 45% of its efforts to compress, encode, and send the user’s audio/video/screen-share streams to rest 9 participants.
Is the CPU not wasting its efforts by trying to do the exact same thing 9 times in this case?
Can we not compress, encode, and send just the user’s audio/video/screen-share streams
once to the cloud and the cloud does some magic to replicate the audio/video/screen-share streams of that user and send it to everybody else present in the same meeting room!
Yes we possibly can do this magic and the name of this magic is Media Server!
Different kinds of WebRTC Media Servers, MCU vs. SFU
Primarily there are 2 kinds of Media servers. One is a SFU and another is a MCU.
According to the last example, now we know that we need a media server that can replicate and distribute the streams of a user to as many people as needed without wasting the user’s network and CPU capacity. Let’s take this example forward.
There is a situation, where the meeting needs to support various UI layouts with a good amount of configuration options regarding who can view and listen to whom! It turns out that this is going to be a virtual event with various UI layouts like Stage, backstage, front-row seats, etc. Here the job of the media server is to replicate and distribute the streams to everybody else except the user himself/herself. Therefore in this case of a 10-user virtual event, every user will be sending only his / her streams to the media server once and receiving the streams from everybody else as individual streams. This way, the event organizer can create multiple UI layouts for viewing by different users according to the place they currently are in, i.e. the backstage/ stage / front row. In this situation, the SFU is helping us by sending all the streams as individual audio/video streams without forcing the way they should be displayed to an individual user. In an SFU, though the user sends only his/her audio/video/screen-share streams it receives from everybody else as individual streams which consumes download bandwidth based on the number of participants. the more the number of participants, the more the download bandwidth is consumed!
Now let’s take a different situation of a team meeting of 10 users of an organization who don’t need much dynamism in the UI but are happy with the usual Grid layout of videos. In this situation, we can merge the audio and video streams of all other participants except himself/herself in the server and create one audio/video stream which can then be sent to all other participants. Here, all the users will send their own audio/video stream and receive all others’ combined audio/video stream(Only one stream!) in a fixed layout as created by the server. The UI will just show one video which was sent by the server as the combined video element. Here MCU is helping us do our job neatly. In this situation, the download bandwidth consumption will be consistent irrespective of the number of users joining the meeting as every user will receive only one audio/video stream from the server. The 2 major downside of this approach is the number of servers needed to create a combined video of all users would be much higher than just replicating and sending the approach of an SFU and rigid UI layout which is already decided by the server without the UI having any control over it.
Two of the largest global video conferencing services use one of the approaches described above.
Gmeet : SFU
MS Teams: MCU
SFUs are slowly gaining more popularity due to the amount of flexibility they provide in creating UI layouts which is highly important for an engaging user experience and takes much lesser servers to cater to a large number of users as compared to an MCU. We are going to discuss the most popular SFUs available out there today and how to choose one for your next WebRTC Media Server requirement.
How to Choose a WebRTC Media Server for your next requirement?
In this section, we are going to discuss the top open-source media servers currently available out there and how they perform against each other. Here, I am going to discuss those media servers which use WebRTC/ openRTC as their core implementation. I won’t be covering the media servers built on PION, the go implementation of WebRTC as that needs a different post.
We would be discussing some of the key things about the below media servers.
Jitsi Video Bridge(JVB), Jitsi (SFU)
Kurento (SFU + MCU)
Janus (SFU)
Medooze (SFU + MCU)
Mediasoup(SFU)
We would primarily be discussing the performance of each media server along with its suitability for building a WebRTC infrastructure.
Jitsi Video Bridge(JVB), Jitsi
Jitsi is a very popular open-source video conferencing solution available out there today. It is so popular because it provides a complete package for building a video conferencing solution including a web & mobile UI, the media server component which is JVB along with some required add-ons like recording and horizontal scalability out of the box. It has very good documentation as well which makes it easy to configure it on a cloud like AWS.
Kurento
Kurento used to be the de facto standard for building WebRTC apps for the promises it made to the WebRTC developers with its versatility(SFU + MCU) and OpenCV integration for real-time video processing way back in 2014. But after the acquisition of Kurento and its team by Twillio in 2017, the development has stopped and now it’s in maintenance mode. One can understand that it is not so great now from the fact that the current team which is maintaining Kurento has a freemium offering named OpenVidu which uses mediasoup as its core media server!
Janus
Janus is one of the most performant SFUs available out there with very good documentation. It has a very good architecture where the Janus core does the job of routing and allows various modules to do various jobs including recording, bridging to SIP/PSTN, etc. It is being updated regularly by its backer to keep it up-to-date with the latest WebRTC changes. This can be a choice for building a large-scale Enterprise RTC application which needs a good amount of time and resource investment for building the solution. The reason is that it has its own way of architecting the application and can’t be integrated as a module into a large application like mediasoup.
Medooze
Medooze is more known for its MCU capabilities than SFU capabilities though its SFU is also a capable one. Though it is a performant media server, it lacks in the documentation side which is key for open source adoption. It was acquired by Cosmo Software in 2020 after which Cosmo Software has been acquired by Dolby. This can be your choice if you are a pro in WebRTC and know most of the stuff by yourself. From Github commits it seems that it is still in active development but it still needs good effort in the documentation side.
Mediasoup
Mediasoup is a highly performant SFU media server available today with detailed documentation and it is backed by a team of dedicated authors with a vibrant open source community and backers. the best part is that it can be integrated into a large Nodejs / Rust application as a module to let it do its job as part of a large application. It has a super low-level API structure which enables developers to use whatever/however they need to use it inside their application. Though it needs a good amount of understanding to build a production-ready application that is beyond the demo provided by the original authors, it is not that difficult to work with it if one is passionate and dedicated to learning the details.
Below is a set of exhaustive performance benchmarking tests done by Cosmo Software people back in 2020 at the height of COVID when WebRTC usage was going beyond the roof to keep the world running remotely. Below are the important points from the test report that are needed to be considered. The whole test report can be found at the bottom of this post for people interested to know more.
Testing a WebRTC application needs to be done with virtual users which actually are cloud VMs joining a meeting room as a test user performing a certain task/tasks. In this case, the test users aka cloud VMs joined using the below-mentioned configuration. In this case, all the above servers were hosted as a single instance server using a VM as described below.
The next is load parameters which were used to test each of these media servers. The numbers are not the same for all these media servers as the peak load (after which a media server fails!) capacity is not the same for every one of these. Here these peak load numbers of each media server have been derived after a good amount of DRY runs.
The test result of the load test.
Page loaded: true if the page can load on the client side which is running on a cloud VM.
Sender video check: true if the video of the sender is displayed and is not a still or blank image.
All video check: true if all the videos received by the six clients from the SFU passed the video check which means every virtual client video can viewed by all other virtual clients.
There are other important aspects of these media servers like RTT(Round Trip Time), Bitrates and overall video quality.
The RTT is an important parameter which tells that how fast a a media stream data aka RTP packet is delivered over the real time network conditions. The lower the RTT the better it is.
The Bitrate is directly responsible for video quality. It simply means how many media stream data packets are being transmitted in real time. the higher the bitrate the better is the image quality but the higher the load on the network to transmit and on the client side CPU to decode. Therefore, it is always a balancing act tp trying to send as many data packets aka the bitrate as possible without congesting the network or overburdening the CPU. Here a good media server can play a good role with techniques like Simulcast / SVC to perosnalise the bitrate for each individual receiver based on their network and CPU capacity.
As it tells, this is the video quality being transmitted by the media server in various load patterns. The higher the quality the better it is.
I hope I was able to provide a brief description of each media server with a enough data points so that you can make a good decision in choosing the media server for your next video project. Feel free to drop me an email at sp@centedge.io if you need any help with your selection process or with video infrastructure development process. We have a ready to use cloud video infrastructure built with mediasoup media server which can take care of your scalable video infra needs and let you focus on your application and business logic. You can have an instant video call/ scheduled video call with me using this link for discussing anything related to WebRTC/media servers/ video conferencing/live streaming etc.
PS: Here is the link to the full test report if anybody is interested in reading the whole of it which has a detailed description of this load test along with many interesting findings.
In today’s fast-paced world, effective communication is the lifeblood of any successful enterprise. As businesses continue to expand globally, the demand for a reliable, scalable, and secure communication system becomes paramount. This is where CWLB, our cutting-edge Media Stack steps in as the ultimate solution for enterprise usage. In this article, we will explore the myriad benefits of our Media Stack and how, as a dedicated solution provider, we can help enterprises build an Enterprise-grade communication system to meet their specific needs.
1. Unmatched Performance and Scalability:
Our Media Stack boasts exceptional performance, enabling real-time audio and video streaming without latency issues. With built-in load balancing and clustering capabilities, it can effortlessly scale to accommodate growing enterprise requirements, ensuring seamless communication across geographically dispersed teams.
2. Reliable and Secure Communication:
Security is of utmost importance for enterprises, especially when handling sensitive data. Our Media Stack is equipped with state-of-the-art encryption protocols, securing all communication channels and safeguarding against potential threats, ensuring confidential information remains private and protected.
3. Customization to Suit Enterprise Needs:
One of the key strengths of our Media Stack lies in its versatility. As a solution provider, we understand that each enterprise has unique requirements. With our expertise, we can tailor the Media Stack to meet specific needs, integrating it seamlessly with existing infrastructure and applications.
4. Seamless Integration with Communication Tools:
Our Media Stack is designed to effortlessly integrate with a wide array of communication tools, including Voice over Internet Protocol (VoIP), WebRTC, instant messaging, and more. This compatibility ensures that enterprises can leverage their existing tools while enjoying enhanced communication capabilities.
5. Enhanced Collaboration and Productivity:
Effective communication fosters collaboration, thereby boosting overall productivity. Our Media Stack facilitates crystal-clear audio and high-definition video conferencing, breaking down communication barriers and allowing teams to collaborate seamlessly.
6. Real-time Analytics and Monitoring:
Monitoring communication performance is crucial for enterprises to make informed decisions. Our Media Stack provides real-time analytics, enabling businesses to assess call quality, user engagement, and system health, ensuring optimal performance at all times.
7. Reduced Costs and Enhanced ROI:
By choosing our Media Stack, enterprises can benefit from cost savings due to its efficient resource utilization and scalability. Moreover, the enhanced communication system increases efficiency, delivering a higher return on investment (ROI).
8. Reliable Support and Maintenance:
As a solution provider, we take pride in our unwavering commitment to customer satisfaction. Our team of experts is always available to provide reliable support and timely maintenance, ensuring that our Media Stack operates at peak performance throughout its lifecycle.
9. Future-proof Solution:
With technology evolving rapidly, it is essential for enterprises to invest in future-proof solutions. Our Media Stack is built on cutting-edge technology, ensuring it remains relevant and adaptable to emerging trends and industry changes.
10. Seizing the Opportunity:
By partnering with us, enterprises can harness the power of our Media Stack to build a robust, secure, and scalable communication system. Our expert team will work closely with clients to design, implement, and maintain the ideal solution, tailored to their specific needs.
11. Enterprise Mediasoup:
As Mediasoup is a highly popular open-source Media server with an active community around it, we built CWLB on top of it which makes CWLB solid as a rock and future-proof. CWLB as a Media Stack converts open-source mediasoup to Enterprise Mediasoup to provide unmatched performance with scalability, reliability, and security.
In conclusion, our Media Stack CWLB is the ultimate choice for enterprises seeking to elevate their communication system to new heights. With unmatched performance, security, scalability, and customization options, it empowers businesses to communicate seamlessly and collaborate effectively. As a solution provider, we are committed to helping enterprises harness this power to build an Enterprise-grade communication system that drives success and growth. By embracing CWLB, our Media Stack, businesses can forge ahead confidently into the future of communication technology.
Feel free to meet one of us for an instant meeting or a scheduled meeting using Meetnow. We are reachable at hello@centedge.io and we would be delighted to hear from you.
In an era defined by rapid technological advancement and shifting business landscapes, video communication has emerged as a pivotal tool for modern enterprises. Platforms like Twilio, Zoom, Google Meet, and Jitsi have revolutionized the way businesses operate, enabling seamless collaboration and communication regardless of physical distance. The COVID-19 pandemic underscored the critical importance of these tools, as companies around the world were forced to quickly adapt to remote work environments.
During the height of the pandemic, these video communication platforms played a crucial role in maintaining business continuity. Zoom, for instance, saw a massive surge in users as companies turned to its platform for virtual meetings, webinars, and conferences. Similarly, Twilio’s cloud communication solutions enabled businesses to quickly implement and scale their communication strategies, ensuring that employees remained connected and productive. Google Meet and Jitsi provided secure and reliable video conferencing capabilities, allowing teams to collaborate effectively in a virtual setting. These platforms not only kept businesses running but also paved the way for a new era of remote work and digital collaboration.
The current Video communication providers can be categorized into 2 broad categories. One category has those who provide ready-to-use video meeting solutions like Gmeet & Zoom, and another category has those who provide all the tools and technologies like Twilio & Jitsi for building custom video meeting solutions. The second category who provide tools to build video solutions can further be categorized into 2 sub categories. One subcategory is Jitsi which provides ready to use self-hosted video meeting solutions including the frontend, backend, media server, horizontal scaling, etc and the other subcategory is the CPAAS/ Video SDK providers like Twilio which provides a scalable backend service along with frontend APIs to build video applications.
All the above-mentioned categories and subcategories have their strengths and weaknesses for a specific business use case. But in general, a requirement can be divided into the abovementioned categories / sub-categories. Accordingly, an option can be chosen from all the available options in that category/sub-category. To keep this post clear and crisp, we are going to discuss more on the second subcategory of the second category, i.e. Twilio as a Video SDK provider and the impact of its EOL (End Of Life) on its existing customers as well as the sub-category/category as a whole.
Twilio Video Discontinuation & Changing Landscapes
The recent announcement by Twilio regarding the discontinuation of its Twilio Video service marks a significant shift in the landscape of video communication platforms. This decision comes amidst a rapidly evolving market, with new players entering the field and existing ones constantly innovating to meet the growing demands of users. While this change may initially cause concern for businesses relying on Twilio Video, it also presents an opportunity to reassess and adapt to the evolving needs of modern communication.
As businesses navigate this transition, it’s important to recognize that the discontinuation of Twilio Video does not signify the end of innovative video communication solutions. Instead, it signals a dynamic market where companies must remain agile and open to exploring new technologies. This shift also underscores the importance of choosing a video communication platform that aligns with the long-term goals and requirements of the organization. By carefully evaluating the available options and selecting a platform that offers both stability and scalability, businesses can continue to leverage the power of video communication to drive growth and success in an ever-changing landscape.
Possible reasons that could have led to Twilio Video Sunset
People who understand how Video technologies work and how complex it is to build a stable enterprise-ready video application, can’t ignore the importance of correct decisions early on related to the core components of the video application. If one goes wrong here at the early stages, there is a good chance of negative impacts in the later stages related to stability, scaling, future feature enhancements, etc. I assume something like this, i.e. some incorrect decisions in the early stages of the Twilio video, would have happened with them as well. I wish to share a short story from my own experience before moving on.
We who followed WebRTC from its early days i.e. from 2012-13 time, can’t forget the promise made by an open-source WebRTC media server named Kurento to the developer community at that time. It was the leading media server at those times with a promise of media forwarding(SFU), merging(MCU), and real-time post processing(with OpenCV) all combined into one package. It was theoretically the perfect media server that could change the world of media scaling and real-time processing forever. I had used Kurento for some of my personal/commercial projects in 2014-15 and I was also super excited about its prospects and possibilities. It was developed by some students and professors at a Spanish University and this open-source package was maintained by them as well along with other contributors.
But in the year 2016-17, after using this media server for 1 -2 years in some commercial projects, I realized that it is hard to manage and scale this media server. It is resource-guzzling as well as slow and less capable of handling concurrent meeting rooms
in larger numbers. It had some core features like ICERestarts were missing as well which are a necessity if wish to deal with bad networks. Therefore, a realization came to us in the year 2019 that we need to move our commercial project to a better media server if we wish to scale it to larger numbers.
The interesting part here is that Twilio bought Kurento for its promises in the year 2017 and built Twilio video on top of it. They bought it for $ 40 million (I read it somewhere back in 2017!) and spent a good amount of money afterward to make it Twilio Video. I think they realized something similar in 2023 which we realized in 2019 and thought of moving on.
I am not sure if this was the primary reason or not as I can only assume what could have happened. But I think the decision to buy Kurento 2017 and deciding to build a Twilio video on top of it may have some role to play in the decision to Twilio video Sunset.
Key learning from this incident
Anybody planning to build a video application should take a learning from it. The key learning is to avoid doing the fundamentally wrong things early on which may have catastrophic impacts later. Therefore it is critical to have good video application professionals (like us!) on your side who have sufficient experience with your kind of use cases early on, to make the right decisions that is beneficial for you and your application both in the shortest as well as in the longest term.
The Beginning of Search for a Twilio Video Alternative
In the realm of real-time communication, Twilio Video has established itself as a go-to solution for many businesses. However, as it is sun-setting its service for some reasons, we need to consider various factors when exploring alternatives. The importance of reliability, scalability, security, and ease of integration cannot be overstated in this context.
Reliability is paramount in any communication system. Look for alternatives with a proven track record of uptime and minimal disruptions. The best way to check reliability is by building a POC to check the performance of the provider with some edge cases like how the audio/video connection performs when the network degrades OR does the video freezes for a user when switching between 5g / Wifi. These scenarios tell about the depth of the provider concerning building video applications.
Scalability is not a deal breaker if your use case doesn’t require 1000s of users in 1 room or 1000s of rooms concurrently running with 10s / 100s of users in each room. But if you have a use case that needs either 1000s of users in 1 room or 1000s of concurrent rooms, then do check the scalability aspects well. A good practice is to as for load test reports which was done by the provider. The best option is to run the load tests yourselves with a POC application to check the scalability for yourself.
Security is non-negotiable, especially when dealing with sensitive information. Look for alternatives that offer end-to-end encryption and comply with relevant regulations like GDPR and HIPAA. Are they providing E2E encryption in case it is a need for your application Or can they store the recordings in an encrypted format in case of a need? These are some of the questions that need to be asked to the provider before deciding on the security aspects of it.
Ease of integration is another important aspect that can make or break your video application. If it takes too many API calls to achieve a small thing or there are important APIs that are not available for your use case then it is not worth considering the solution even if it offers the above 3.
Based on the above parameters, we can consider 2 types of solutions that can become a Twilio video alternative. One is an open-source media server-based solution and another is a proprietary solution provided by a commercial vendor. In this post, we are going to explore both alternatives in a detailed manner.
Open Source Twilio Video Alternatives:
Open-source video communication solutions are software platforms that enable users to communicate through video conferencing, messaging, and collaboration tools. Unlike proprietary solutions, open-source solutions provide the underlying code for free, allowing users to modify, customize, and distribute the software according to their needs. This openness fosters innovation, as developers worldwide can contribute to improving the software, leading to rapid advancements and feature enhancements.
One of the key benefits of open-source video communication solutions is their flexibility and scalability. Organizations can tailor the software to meet their specific requirements, integrating it into their existing infrastructure seamlessly. Additionally, open-source solutions are often more cost-effective than proprietary alternatives, as they eliminate licensing fees and allow users to leverage a global community of developers for support and development.
In recent years, open-source video communication solutions have gained popularity due to their reliability, security, and privacy features. These solutions prioritize user data protection, offering end-to-end encryption and other security measures to safeguard sensitive information. As businesses and individuals increasingly rely on video communication for work, education, and social interactions, open-source solutions provide a reliable and accessible platform for connecting people around the world.
Primarily open source solutions can be divided into 2 categories. One is a ready solution with both frontend(UI) and backend ready to be deployed on the server and used. The downside of this is that the front end (UI) may not be suitable for your use case. A great example in this category is Jitsi. Jitsi is a ready to be used open source video conferencing solution with a pre-built UI with a scalable backend. The only issue is that we can use the default UI as an IFrame inside our solution but can’t modify it easily according to our use case. Also, it may not be a great Twilio video alternative as Twilio video is used to provide the APIs to build a custom video solution according to our exact needs.
Therefore let’s explore the second alternative,i.e. a media server-based solution that provides a set of APIs to build custom video conferencing/ Interactive live streaming solutions like Twilio video currently provides. Though there are a good number of open-source Twilio alternatives, we are going to mention the top 2 alternatives that can be worthy of replacing Twilio video APIs. One great example is the mediasoup-demo project which can be considered as a real Twilio video alternative. It has all the ingredients for building a production-grade video conferencing/ Interactive live streaming system. The only downside of this project is that it is a raw tech that has been built to demonstrate the capabilities of the mediasoup media server. Hence it lacks the polish of a production-grade video application. This can be considered as a great base/starting point on top of which a production-grade video conferencing / Interactive live streaming application can be built. Please note that the APIs provided by the mediasoup-demo project are not the same as Twilio and they need a separate integration effort than the existing Twilio implementation. Another very good project is liveKit, built using PION, the Go lang version of WebRTC. If you have a Go lang backend, then this project can be worth the consideration.
Open source Twilio Video Alternatives, Pros and Cons
Customization: Developers can tailor the solution to meet specific enterprise needs, ensuring flexibility and scalability.
Community Support: Access to a large community of developers can provide assistance, bug fixes, and ongoing updates.
Security: Regular updates and scrutiny by the community can enhance security, ensuring vulnerabilities are quickly identified and patched.
Interoperability: WebRTC’s standardization enables interoperability with various platforms and devices, ensuring seamless communication.
Cons:
Complexity: Integrating and managing an open-source WebRTC project can be complex, requiring specialized knowledge and resources.
Maintenance: While community support can be beneficial, it also requires active management to ensure compatibility and security updates are implemented.
Scalability: While WebRTC itself is scalable, managing the infrastructure to support enterprise-grade usage can be challenging without dedicated resources.
Quality Control: Open source projects may lack the same level of rigorous testing and quality control as commercial solutions, potentially leading to reliability issues.
Legal Considerations: Open source licenses may have implications for proprietary use, requiring careful consideration of licensing terms and compliance.
Open Source Considerations, Building from Scratch vs. Using a Vendor
Building from Scratch:
Building from scratch can be considered an option if you have
At least 3-5 Highly Skilled people in the core Audio/Video technologies like WebRTC, SIP, FFMPEG, GStreamer, WebSockets
Peripheral skill sets like JavaScript, HTML, Android, iOS, etc. for building Web and mobile clients
If you have at least 12 months and enough financial resources to maintain a team of 8-10 available. It may go to 18-24 months if your requirement is too complex and it needs a very specialized approach.
You will get the benefits of the above-mentioned pros but also you need to deal with the above-mentioned cons on your own.
Using a Vendor:
Using a vendor is beneficial as well as recommended if
You don’t have a team with the above-mentioned skill sets who can understand and modify an open-source package according to your use case.
You don’t have at least 8 – 12 months available for implementing your use case using an open-source package.
You would get the pros of open source as mentioned above without having to deal with many of the cons as mentioned above. The vendor would provide you with much-needed support, scalability, and quality control capabilities.
The financial resources needed would be similar to building it from scratch with the difference that you would get the results faster with better predictability and control of the outcome.
Commercial Twilio Video Alternative:
Nothing much needs to be written about commercial alternatives for the Twilio video. As the header suggests, this category has commercial vendors who provide audio/video SDK software similar to Twilio. The SDKs may not be the exactly same but they do the job effectively i.e. providing audio/ video capabilities in your application without you having to go through the pain of building the audio/video SDK for yourself.
These are some of the providers of audio/Video SDKs that offer similar audio/video capabilities as Twilio.
There are many others as well who provide video/audio SDKs. Please google and you will find others.
Pros
Faster time to market: If you are not sure about the prospect of the product or service and you wish to test your product or service really quick
No need to maintain a team of audio/video experts
Easy to start with a lesser amount of cost when utilization is low
Cons
Cost becomes prohibitive as usage grows with time
Complex to forecast monthly costs with pay-per-minute/user billing techniques
Chance of getting stuck with a vendor with a huge switch cost,( Vendor lock-in)
Lesser control over the actual media streams of your users
The fear of if Twilio can decide to shut down the video service, then your current vendor may also decide to shut it down next year!
Sometimes your video SDK provider may not be flexible enough to customize according to your requirements.
The simple formula to choose between using a commercial vendor vs not using a commercial vendor is below.
If the audio/video capabilities are mission-critical to your business for some reason and are deeply coupled to the core workflows of your business, then it’s best not to choose a commercial vendor. In this case, it is better to look for alternatives that would provide you with better control over the entire stack of your audio/video capability requirement.
If you wish to know more about a possible Twilio video alternative that can be tailored to your specific use case, please feel free to drop an email at hello@centedge.io to kickstart a conversation with us. If you wish to schedule a discussion with one of our principal engineers to discuss your use case in detail, feel free to use the Meetnow button available at the top of this page to schedule it.
WebRTC has become a cornerstone for real-time communication in web applications, enabling seamless audio, video, and data streaming directly in the browser. However, when it comes to IoT and embedded devices, leveraging WebRTC in a browser may not be the most efficient option. This is where compiling LibWebRTC natively for ARM devices comes into play. By doing so, developers can create highly optimized applications that significantly reduce CPU usage, resulting in lower power consumption and improved performance—key factors for IoT and embedded systems.
When you compile LibWebRTC for ARM, especially in the context of IoT and embedded devices, you unlock the potential to run real-time communication applications natively on ARM processors. This approach offers several advantages over using WebRTC within a browser, such as reduced latency, better resource management, and enhanced performance. The result is a more stable and reliable communication experience, which is crucial for applications in resource-constrained environments like smart homes, industrial IoT, and other embedded systems.
WebRTC for Embedded: Steps to Compile LibWebRTC for ARM
Compiling LibWebRTC for ARM, particularly for IoT and embedded devices, requires a few detailed steps. The following guide will help you through the process:
1. Set Up the Build Environment
Start by preparing an Ubuntu environment, either directly on an ARM device or on an x86 machine if you plan to cross-compile for ARM. Ensure that all necessary dependencies, such as Python, Git, and the build-essential package, are installed.
Fetch the LibWebRTC source code using the following commands:
fetch --nohooks webrtc
cd src
gclient sync
3. Explore Available GN Build Options
Before generating the GN build files, it’s beneficial to review all available build options. This step ensures that you configure your build optimally for your IoT or embedded ARM device.
gn args out/Default --list
This command lists all configurable GN build options, allowing you to tailor the build process to your specific needs.
4. Set Up GN Configuration
Generate GN build files tailored to the target architecture, either ARM32 or ARM64.
For ARM32:
gn gen out/arm32 --args='target_os="linux" target_cpu="arm" is_debug=false is_clang=true use_custom_libcxx=false'
For ARM64:
gn gen out/arm64 --args='target_os="linux" target_cpu="arm64" is_debug=false is_clang=true use_custom_libcxx=false'
Selecting the correct target_cpu (either arm for ARM32 or arm64 for ARM64) is crucial for optimizing the build for your IoT or embedded device.
5. Compile the Code
Once the GN configuration is set, you can proceed to compile the code using Ninja.
For ARM32:
ninja -C out/arm32
For ARM64:
ninja -C out/arm64
The compilation process may take some time, depending on your system’s hardware capabilities.
6. Deploy and Test
After successfully compiling LibWebRTC for ARM, deploy the binaries to your target IoT or embedded device. Comprehensive testing is essential to ensure that all functionalities are working correctly and that the performance benefits specific to your device are realized.
Note:
While compiling for ARM devices, one should use this option is_clang=truewhich is required to compile the neon flags available in the ARM architecture for video rendering acceleration. The default GCC in the Ubuntu-based Linux systems is not capable of compiling these flags and complains about neon flags. Therefore, it is advisable to use the clang already provided by the LibWebRTC to compile it rather than using the system’s default C++ compiler which is GCC.
Summary
Compiling LibWebRTC for ARM devices, particularly in the context of IoT and embedded systems, offers significant advantages over using browser-based WebRTC. Native compilation allows you to fine-tune applications to run efficiently on ARM processors, resulting in lower CPU usage, reduced power consumption, and enhanced performance. This is especially important for IoT and embedded devices where resources are limited, and efficiency is paramount.
For businesses operating in the IoT and embedded systems domain, optimizing WebRTC for ARM devices by compiling LibWebRTC natively opens up a world of possibilities. It enables the delivery of high-quality video calls, low-latency data streaming, and efficient resource usage—all critical factors for success in this field. Whether you’re developing applications for remote healthcare, smart home devices, or industrial automation, the ability to provide reliable, real-time communication on low-powered ARM CPUs is a game-changer that can drive innovation and efficiency in your solutions.
We recently built a C++ video application for ARM devices (both 32-bit and 64-bit) to work with our existing cloud video infrastructure. From our recent experience, we can say that it’s not an easy task and needs significant effort to compile & build a native C++ video application. If you also have an IOT / Embedded video conferencing/streaming use case and don’t know where to start, do shout at hello@centedge.io. You also can schedule a video call with us to discuss your use case using our Meetnow page.
In today’s digital-first world, enterprises are increasingly looking to enhance their workflows with real-time video communication capabilities. Whether it’s for a cloud contact center, customer engagement, or internal collaboration, WebRTC (Web Real-Time Communication) has emerged as the backbone for building custom video calling, conferencing, and live streaming applications. However, building a production-ready, enterprise-grade custom real-Time audio/video solution using WebRTC is no small feat. It requires careful planning, technical expertise, and a clear understanding of business needs.
Here are the top five points enterprises should consider before embarking on the journey of building and integrating a custom WebRTC application:
1. Define Business Use Cases and User Experience Requirements
Before diving into development, it’s crucial to outline the specific business use cases and the user experience (UX) goals. Are you building a customer-facing video support solution, an internal collaboration tool, or a live streaming platform for events? Each use case has distinct requirements for latency, resolution, and feature sets such as screen sharing, recording, or chat integration. Additionally, consider:
Target audience and their technical proficiency.
Device compatibility (web, mobile, and native applications).
Regulatory requirements, such as HIPAA for healthcare or GDPR for customer data privacy.
A well-defined scope not only ensures a smoother development process but also aligns the solution with your business goals.
2. Ensure Scalability and Reliability
For enterprise-grade applications, scalability and reliability are non-negotiable. Video calls with hundreds of participants or live streams with thousands of viewers demand robust infrastructure. When planning your architecture:
Opt for distributed servers and load balancers to handle peak traffic.
Implement mechanisms to recover from failures, such as session restoration.
Ensure low-latency media streaming for real-time interaction if it is a critical requirement for your application with techniques like media server cascading.
WebRTC itself doesn’t offer a signaling protocol—you’ll need to design or integrate one to manage session initiation, participant connection, and message exchange. Using standards like WebSocket or MQTT can provide the required reliability for signaling.
3. Optimize for Network Conditions and Bandwidth Management
Unstable network conditions can severely degrade the user experience in a real-time application. Enterprises should prioritize:
Adaptive bitrate streaming to dynamically adjust video quality based on network bandwidth.
Packet loss recovery techniques such as forward error correction (FEC).
Configuring TURN (Traversal Using Relays around NAT) and STUN (Session Traversal Utilities for NAT) servers to ensure seamless peer-to-peer connections, even behind firewalls.
Testing the application across various network scenarios, including low bandwidth and high latency, is essential to delivering a consistent experience.
4. Incorporate Advanced Security Features
Security is a critical concern for enterprises, especially in industries like healthcare, finance, and government. WebRTC encrypts media streams by default using DTLS-SRTP, but additional measures should be considered:
Implementing end-to-end encryption for sensitive communications.
Using secure signaling channels (e.g., HTTPS and WSS).
Regular security audits and compliance with standards such as ISO 27001.
Additionally, access control mechanisms, like token-based authentication, can prevent unauthorized use and ensure that only authenticated users can access the system.
5. Plan for Long-Term Maintenance and Updates
Building a custom WebRTC solution is not a one-time investment. As technologies and user needs evolve, so must your application. Enterprises should:
Set up continuous monitoring and analytics to track performance and usage.
Regularly update the application to address security vulnerabilities and incorporate new WebRTC standards.
Invest in skilled developers who understand the nuances of WebRTC and its ecosystem.
Moreover, ensure your solution can integrate with other enterprise systems, such as CRM, ERP, or cloud contact center platforms, to provide a seamless workflow.
Alternatives to Building a Enterprise-Grade Custom Real-Time Audio/Video Solutions
While building a custom WebRTC application offers complete control and customization, it can be resource-intensive and time-consuming. For enterprises that want to fast-track implementation or lack in-house expertise, leveraging commercially available programmable video SDK solutions is a viable alternative. Vendors like Samvyo.com provide enterprise-grade APIs and SDKs that enable businesses to integrate video conferencing, live streaming, and real-time communication into their workflows without starting from scratch.
These solutions come pre-built with essential features like:
Scalable infrastructure to handle high traffic.
Pre-configured security and compliance mechanisms.
Advanced analytics and monitoring tools.
Using a programmable video SDK not only reduces development time but also ensures a production-ready, reliable solution that can be tailored to your specific business needs. By partnering with trusted providers, enterprises can focus on delivering value to their users rather than managing the complexities of WebRTC development.
Final Thoughts
Enterprises looking to integrate real-time video communication into their workflows have a strategic decision to make: build a custom solution or leverage a programmable video SDK. While custom development offers unparalleled flexibility, it demands significant investment in time, resources, and expertise. On the other hand, commercially available SDKs from providers like Samvyo.com offer a faster and more cost-effective path to integration, enabling enterprises to stay agile in a competitive market.
Ultimately, the choice depends on your organization’s priorities, resources, and long-term vision. Whether you opt for a custom-built WebRTC application or a ready-to-use SDK, the key is to align the solution with your business objectives and deliver a seamless, secure, and scalable user experience.
If you are an Enterprise looking for professional help for your planning process before venturing out to building Enterprise-Grade Custom Real-Time Audio/Video solutions for integrating to some of your critical business workflows, feel free to drop us an email athello@centedge.io for a free 30mins strategic discussion session for diving deep into your requirement to provide you with the correct ingredients required to realize your requirement without time and cost overruns. You can reach out to us using this link as well.
As urbanization drives the construction of high-rise buildings, elevators have become an essential component of modern infrastructure. With millions relying on these systems daily, ensuring passenger safety has never been more critical. This white paper explores the evolution of safety elevators, current market dynamics, and how WebRTC technology can redefine safety standards by enabling real-time two-way video communication.
A Brief History of Safety Elevators
The invention of the safety elevator revolutionized urban architecture, enabling skyscrapers and high-rise buildings. Elisha Otis introduced the first safety elevator in 1852, a system that incorporated a fail-safe brake mechanism to prevent the elevator from plummeting in case of rope failure. Since then, elevators have become indispensable, evolving from simple manual controls to advanced automated systems equipped with state-of-the-art safety features.
The Growing Importance of Safety Elevators
With the rapid urbanization of cities worldwide, safety elevators have seen exponential growth. According to market reports, the global elevator market is expected to reach $135 billion by 2030, driven by increased high-rise construction and stricter safety regulations. As cities grow vertically, ensuring the safety of elevator passengers during emergencies has become a paramount concern for manufacturers and regulators alike.
Rethinking Elevator Safety: The Role of Two-Way Video Calling Systems
While traditional safety systems like alarms and emergency stop buttons have been effective, they often fall short in addressing real-time emergencies, such as medical crises or mechanical failures. Two-way video calling systems offer a transformative solution, enabling real-time communication between passengers and emergency response teams. This technology can bridge critical gaps in emergency response, providing instant visual and auditory information that aids faster and more effective rescue planning.
Current Emergency Response Technologies in Elevators
Most modern elevators are equipped with:
Emergency intercoms for audio communication.
Alarm buttons to alert building security.
Automatic emergency braking systems for mechanical safety.
However, these legacy systems often lack the real-time visual context required for effective decision-making during complex emergencies.
WebRTC: Enhancing Safety with Real-Time Video Communication
WebRTC (Web Real-Time Communication) introduces a paradigm shift by enabling high-quality, low-latency video and audio communication directly between elevator occupants and rescue teams. Its benefits include:
Improved situational awareness through live video feeds.
Faster response times as rescue teams receive real-time updates.
Enhanced passenger confidence during emergencies.
Unlike traditional systems, WebRTC-based solutions operate efficiently without relying on centralized servers, ensuring robust performance even in challenging network conditions.
Challenges in Hardware Integration
Integrating a WebRTC-based video calling system into elevator hardware poses unique challenges:
Limited CPU Power: Elevator control units typically run minimalistic Linux-based operating systems with low processing capabilities.
Absence of Browsers: Many systems lack browser environments necessary for running WebRTC applications.
Hardware Constraints: Limited support for video and audio processing, leading to potential performance bottlenecks.
Building a Native WebRTC Solution for hardware integrations
To overcome these challenges, Videoedge developed a highly optimized solution:
Native libWebRTC Build: Custom-compiled WebRTC libraries for target hardware.
C++ Application: Designed to leverage RTC peer connection objects for establishing calls.
Media Capture: Implemented browser-equivalent getUserMedia functionalities for camera and microphone access.
Rendering Layer: Utilized GStreamer and libgtk for efficient video/audio rendering.
Hardware Acceleration: Exploited available GPU resources to offload processing tasks, minimizing CPU load.
Multithreading: Distributed tasks across multiple threads to avoid bottlenecks and ensure smooth video and audio streams.
Beyond Elevators: Broader Industrial Applications
The same WebRTC-based capabilities can revolutionize workflows in:
Industry 4.0: Real-time video monitoring of manufacturing processes.
Advanced Automotive Use Cases: Video telematics for driver assistance and remote diagnostics.
Other Industrial Scenarios: Enhanced safety and communication in mines, oil rigs, and remote construction sites.
Case Study: Revolutionizing Emergency Response for a Global Elevator Manufacturer
Centedge recently partnered with one of the world’s largest elevator manufacturers to design a cutting-edge emergency response system. By adhering to the principles outlined above, we successfully delivered a WebRTC-based two-way video calling system that:
Operates seamlessly on low-powered hardware, a dual-core 900Mhz NXP IMX6 processor: This processor is responsible for the entire operation of the Elevator unit including its core Linux-based OS and the entire application layer built on top of the OS layer for smooth elevator operation. The mandate provided to us was to keep the CPU usage < 70% while running a crystal clear audio/video call along with all other elevator processes running. We were able to achieve the mandate while keeping the CPU usage at 62% while running a 2-way WebRTC-powered video call along with all other elevator processes.
Provides crystal-clear video and audio streams for real-time communication: The goal was to achieve the best possible audio/ video quality while trying to keep the CPU utilization below 70%. With a lot of experimentation, we found, that 320X240 at 10fps is the sweet spot that provides a clear 2-way audio/video while keeping the overall CPU utilization at 62%.
Meets rigorous safety and compliance standards: Rigorous testing was done on the actual production hardware under various scenarios to find out issues and fix them proactively.
This solution significantly reduced response times and enhanced the overall safety of elevator passengers.
Elevator Safety with WebRTC: Conclusion
As the demands for safety and real-time communication continue to grow, Centedge’s unique and custom WebRTC-based solutions are setting new standards for emergency response systems. Whether it’s elevators, industrial workflows, or advanced automotive applications, our technology is designed to adapt and excel in diverse environments. If your organization is looking to enhance safety and operational efficiency, let Centedge tailor a solution that meets your unique requirements.
If you are an Enterprise looking to build Enterprise-Grade Custom Real-Time Audio/Video solutions with hardware integrations for integrating into some of your critical business workflows, here is a link to the list of services we provide for Embedded/IOT integration use cases for WebRTC. Feel free to drop us an email athello@centedge.io for a free 30mins strategic discussion session, if you feel a discussion with us would be an important starting point. This session would be exclusively for diving deep into your requirements to provide you with the correct ingredients required to realize your requirements without time and cost overruns. You can reach out to us using this link as well.
Feel free to take a look at the Videoedge Video API/SDK to speed up your development process without having to build the entire application from scratch. With Videoedge SDK, you get the entire backend ready to be deployed into multiple geographies across the world within a week’s time.
References:
Here is a blog we wrote some time ago on how to compile and build the native Libwebrtc for a target CPU type of ARM, responsible for enabling 2-way video calling natively on a hardware device without a dependency on browsers.
