Mobile Video-Conferencing Using Jitsi

Jitsi is a collection of free and open-source multiplatform voice, video conferencing and instant messaging applications for the web platform, Windows, Linux, macOS, iOS and Android. It is one of the most popular open source real-time media servers out there.

When used on mobile devices, Jitsi can be used both from a mobile app or in a web browser. Which is the more popular approach? Interestingly, there’s no single answer here. And at the end of the day, it may well depend on the use case you are providing to your users.

Developers looking to host their own virtual meeting service or embed video calling in their application can make use of Jitsi. How does Jitsi get this done? By using a technology called WebRTC. More on that later, for now let’s start from the Jitsi ecosystem.

Jitsi architecture and ecosystem

Jitsi has been around for as long as WebRTC, with Jitsi Videobridge first introduced in 2013. Through the years, it has grown in size and features. The diagram below illustrates the technical architecture of a typical Jitsi deployment:

The main Jitsi components are:

• Jitsi Videobridge (JVB), the heart of the Jitsi service, is modeled as an SFU which acts as an intelligent routing server capable of hosting group video calls at scale.
• Prosody, the signaling server used by Jitsi, which uses XMPP as its signaling protocol. This is used as an intermediary enabling users to join rooms and communicate with each other in Jitsi.
• Jitsi Meet, the frontend web interface implementation. This is rather unique to Jitsi, as it offers a fully functional, ready to deploy meeting experience. It is built using React and React Native.
• Jitsi Conference Focus (jicofo), a load-balancer that manages and handles horizontal scaling for Jitsi.
• Jitsi Broadcasting Interface (jibri), a recording/streaming service for JVB. In essence, this is built around headless Chrome and ffmpeg to offer a single video stream out of an ongoing Jitsi video meeting.
• Jitsi Gateway to SIP (jigasi), the gateway Jitsi offers for those who need to connect telephony services into Jitsi meetings.

A typical deployment will have JVB, Prosody, Jitsi Meet and jicofo, and optionally include jibri and jigasi.

Interestingly, this component-based approach used by Jitsi differs from other open source media servers, which focus on offering a media server component only, with references or samples on how to handle the rest of the necessary pieces – Janus and mediasoup come to mind here. This gives Jitsi an advantage for those looking for quick solutions for general purpose video meetings, whereas the alternatives are better at giving more flexibility in the specific implementation and optimizations to employ by their communications architecture.

Jitsi’s open source and commercial offering

While Jitsi started as a pure open source project, this has changed throughout the years. Jitsi was developed and maintained by BlueJimp with the premise of providing support and customization services. Once BlueJimp got acquired (first by Atlassian and later by 8x8), that has changed. The support and customization services were scrapped, which meant those who needed support services had to rely on third-party vendors, who are not necessarily maintaining the main Jitsi source code branch directly.

Instead, 8x8 introduced a SaaS model called JaaS – Jitsi as a Service. With it, companies can skin the Jitsi experience with their own branding or embed it into their own business workflow without needing to host it on their own – that is taken care of by the Jitsi team. JaaS is akin to other CPaaS (Communication Platform as a Service) solutions such as Twilio Programmable Video and Vonage Video API, where developers can build their own solutions on top of a third-party managed infrastructure.

Throughout most of its existence, Jitsi also offered a demo service, Meet Jitsi, as a kind of a showcase of Jitsi. With time, it became its own free, standalone meeting service. Think of it as the freemium component in the Jitsi ecosystem to get developers and users alike hooked with the Jitsi technology stack.

To summarize, the Jitsi ecosystem has three main variants:

1. Jitsi, the open source project
   1. The target "customer" here is developers who want to build and maintain their technology stack
   2. You install and configure the servers on your own
   3. You take care of maintaining them, patching and upgrading them over time
   4. You deal with scaling and monitoring the system yourself.
2. Meet Jitsi, the managed video calling service (also available as part of the 8x8 unified communications offering itself)
   1. The target "customer" here are the end users. People who wish to communicate with one another using an existing tool
   2. You use it as an end user
   3. You send meeting links to people and think of it as a free/open alternative to zoom, for example.
3. JaaS, the video APIs/CPaaS solution
   1. The target "customer" here are businesses and developers who wish to whitelabel, brand, and embed an existing video meeting solution within their own application or business process
   2. Embed it in your own application
   3. Whitelabel the hosted service
   4. Don’t care or worry about the ongoing maintenance and scale of your video infrastructure.

Different vendors and developers take different approaches to what they end up using in the Jitsi ecosystem. What interests me here is to try and understand how end-user behavior manifests itself on mobile devices for those video calling services. Why is that important? Because of the underlying technology - WebRTC.

WebRTC, browsers and mobile devices

Lets look at WebRTC for a bit – the underlying communication technology used by Jitsi.

In a nutshell, WebRTC is an open standard that defines a real-time media engine API that can be used to implement communication applications, such as voice and video calling. WebRTC is available in all modern browsers so that web developers can develop such applications on their own. For that, backend infrastructure that deals with real-time data is needed.

The question remains what to do with mobile devices. WebRTC is available for mobile devices as well via mobile browsers, but a lot of the media traffic on mobile devices comes from native applications that users install. This is why a lot of the communication applications for mobile devices take an open source implementation of WebRTC (the one developed and maintained by Google) and use it inside their mobile applications. It takes a bit more care and attention to use and deploy, but if you need a mobile application this is something you will need to do (or buy from someone else).

For a long time, many assumed that the correct way of using WebRTC in mobile devices was via native applications. Others, who viewed WebRTC as a browser technology, envisioned a world where the browser ruled mobile activities. Neither is correct. The truth, as always, is somewhere in the middle.

To understand how the story of WebRTC and Jitsi has played out for mobile platforms, let's start by understanding user behavior and preferences when it comes to virtual meetings. And what better place to start than my own preferences?

Desktop or mobile?

I conduct over 90% of my meetings on my desktop. I hate participating in video meetings on my smartphone, although I do that from time to time when I am on the go and my laptop or desktop are out of reach. That isn’t the case for others though.

Different people have different preferences. It depends on their inclination as well as the scenario. As a developer of a communication application, should you invest your time and focus on a mobile experience or a desktop one?

Furthermore, on mobile devices, should you go for a mobile web solution or take the time to build and deploy a native mobile application? Let’s focus here on the mobile case and see if we can reach an understanding.

Mobile web or mobile native?

The mobile experience is ruled by native applications. People just don’t open their web browsers on mobile. They spend their  time on smartphones inside apps. eMarketer estimated that in the US, around 90% of the time spent in smartphones is spent in applications:

With such estimations, you may ask why would anyone invest in a mobile web-based experience? The answer to this is "it depends".

It depends who your target audience is and what your use case is about. You can see this really well by reviewing the usage patterns of the Jitsi ecosystem.

Meet Jitsi vs. JaaS

As mentioned, Jitsi is an open source media framework that makes use of WebRTC. Many enterprises and developers have adopted it and deployed their own instances. That said, If you are looking for a hosted managed solution, then 8x8, the maintainer of Jitsi has you covered:

1. Jitsi Meet, a free group video calling service, which showcases what is readily available with Jitsi. It acts as a great demo as well as a testbed for the Jitsi team of new features and optimizations to the framework
2. JaaS (Jitsi as a Service). A programmable managed Jitsi Meet service offering. One that developers can use as a whitelabeled solution for their own communication needs

Looking at a month-worth of data kindly provided by Jitsi for the redaction of this article shows some interesting usage patterns and behaviors for both Jitsi Meet and JaaS in May-June 2022. Let's dive into the numbers.

Meet Jitsi

As a quick reminder, Meet Jitsi is the free online group video calling service of Jitsi. People use it as they see fit without the need to authenticate themselves with the service. It is a kind of an alternative to conducting your meetings with zoom.

We will start by taking a look at the Jitsi Meet’s use on mobile devices. Users can either install the native mobile app, or use the web browser on their device.

Sessions taking place in mobile devices for Jitsi Meet

The diagram above shows that for Jitsi Meet, users are leaning towards the use of native mobile applications. They end up installing these native applications and communicating through them. In the cases of both iOS and Android there are more than x3 times the number of sessions taking place over the Jitsi Meet native application than directly in web browsers.

Does this stem from the fact that frequent users would rather install an application on their device than open a web browser?

Can it mean that Jitsi Meet users are "repeat customers", installing the mobile app because they use it frequently enough?

JaaS

While both Meet Jitsi and JaaS share and use the same backend infrastructure, their users differ greatly. Remember: while Meet Jitsi is all about end users, JaaS is about developers hosting their own white labeled web applications that happen to have video meetings as a feature in them for their own end users.

How does JaaS behave on mobile? Here is what the numbers say:

Sessions taking place in mobile devices for JaaS

In this diagram we see the exact opposite than what happens with Jitsi Meet. This time we have a x5 to x10 difference between web and native, but in the opposite direction. With JaaS, there’s a clear preference towards using mobile web than towards using native mobile applications.

One wonders if that is because JaaS customers simply don’t develop and launch native mobile apps or because their service lends itself better towards web use.

There are a few reasons why this might be the case:

1. Developers using JaaS support use cases where mobile use is ad-hoc and one time in its nature. This may include uses such as patients on a telehealth service, joining for a single consultation call with a doctor.
2. Vendors using JaaS are looking to reduce their development efforts. Building native mobile applications is time and resource consuming, so they prefer to forgo this and rely on the available mobile web solution instead.

Whatever the answer is, it is interesting to see the stark difference in usage behavior on mobile between Jitsi Meet and JaaS.

Does your Jitsi deployment need a mobile app?

Developing a native mobile application is both time consuming and expensive compared to the creation of a web application. This is why this route isn’t a simple or clear cut decision.

Here are some quick tips to guide you with your own decision here:

Here are a few examples:

Lets say your service is providing remote care for patients. Most will come to the doctor’s clinic, but from time to time, they’d prefer to join virtually. The doctor will be using his laptop or desktop device, so a web browser is what he will be using. Your patients join from mobile devices and get an SMS and a calendar invite with the link to the visit. They also aren’t frequent users of this service - the majority will use it once a year or less. For them, the mobile web is the perfect solution.

If you are offering a language learning service for people on the go, then your users will be accessing live tutoring from the device. Assuming you want them to be able to schedule a quick training session ad-hoc when they have some time available, then your route should definitely be a mobile native application.

The service you offer enables field service employees to get immediate access to experts sitting in the back office when they need further assistance. They have an app installed that provides everything they need to do their job. Embedding video calling into that native application is the path forward for you.

Your dating service is adding that virtual meeting feature to get couples to meet virtually for the first time online. Should you add video calling as a native application or as a web experience? This one is up to you: how you’ve conducted and handled the service so far on mobile (either as a native app or mobile web) is probably how you should continue once adding video meetings to it.

What’s your mobile preference with Jitsi?

In this article, we have looked at alternatives for providing video meetings on mobile devices. We took Jitsi as a popular open source option, and saw that, based on both Jitsi Meet (their ad-hoc video meetings service) and JaaS (their as a service platform for developers) user engagement, there’s no "one size fits all" solution.

Some application types lend themselves better to be used as mobile web experiences while others can benefit from a native mobile application.

If you plan on offering video meetings on mobile devices, you should figure out your users usage patterns and decide from there what type of experience you want to invest in, web-based or native mobile.