In WebRTC group calling, media server scaling is one of the biggest challenges. There are multiple scaling architectures that are used, and most likely, you will be aiming at a routing alternative, where media servers are used to route media streams around between the various participants of a session.

As your service grows, you will need to deal with scale:

• Due to an increase in the number of users in a single session
• Because there’s a need to cater for a lot more sessions concurrently
• Simply due to the need to support users in different geographical locations

In all these instances, you will have to deal with the following challenge: How do you decide on which server to allocate a new user? There are various allocation schemes to choose from for WebRTC group calling. Each with its own advantages and challenges. Below, I’ll highlight a few such schemes to help you with implementing the WebRTC allocation scheme that is most suitable for your application.

Single data center allocation techniques

First things first. Media servers in WebRTC don’t scale well. For most use cases, a single server will be able to support 200-500 users. When more than these numbers are supported, it will usually be due to the fact that it sends lower bitrates by design, supports only voice or built to handle only one way live streaming scenarios.

This can be viewed as a bad thing, but in some ways, it isn’t all bad – with cloud architectures, it is preferable to keep the blast radius of failures smaller, so that an erroneous machine ends up affecting less users and sessions. WebRTC media servers force developers to handle scaling earlier in their development.

Our first order of the day is usually going to be deciding how to deal with more than a single media server in the same data center location. We are likely to load-balance these media servers through our signaling server policy, effectively associating a media server to a user or a media stream when the user joins a session. Here are a few alternatives to making this decision.

Server packing

This one is rather straightforward. We fill out a media server to capacity before moving on to fill out the next one.

Advantages:

• Easy to implement
• Simple to maintain

Challenges:

• Increase blast radius by design
• Makes little use of other server resources that are idle

Least used

In this technique, we look for the media server that has the most free capacity on it and place the new user or session on it.

Advantages:

• Automatically balances resources across servers

Challenges:

• Requires the allocation policy to know all sever’s capacities at all times

Round robin

Our “don’t think too much” approach. Allocate the next user or session to a server and move on to the next one in the list of servers for the next allocation.

Advantages:

• Easy to implement

Challenges:

• Feels arbitrary 🙂

Random

Then there’s the approach of picking up a server by random. It sounds reckless, but in many cases, it can be just as useful as least used or round robin.

Advantages:

• Easy to implement

Challenges:

• Feels really arbitrary 😀

Region selection techniques

The second part is determining which region to send a session or a user in a session to.

If you plan on designing your service around a single media server handling the whole session, then the challenge is going to be where to open a brand new session (adding more users takes place on that same server anyway). Today, many services are moving away from the single server approach to a more distributed architecture.

Lets see what our options are here in general.

First in room

The first user in a session decides in which region and data center it gets created. If there are more than a single media server in that data center, then we go with our single data center allocation techniques to determine which one to use.

This is the most straightforward and naive approach, making it almost the default solution many start with.

Advantages:

• Easy to implement

Challenges:

• Group sizes are limited by a single machine size and scale
• If the first user to join is located from all the rest of the users, then the media quality will be degraded for all the rest of the participants
• It makes deciding capacities and availability of resources on servers more challenging due to the need to reserve capacity for potential additional users

👉 Note that everything has a solution. The solutions though makes this harder to implement and may degrade the user experience in the edge cases it deals with.

Application specific

You can pick the first that joins the room to make the decision of geolocation or you can use other means to do that. Here, the intent is to use something you know in your application in advance to make the decision.

For example, if this is a course lesson with the teacher joining from India and all the students are joining from the UK, it might be beneficial to connect everyone to a media server in the UK or vice versa – depending on where you want to put the focus.

A similar approach is to have the session determine the location by the host (similar to first in room) or be the configuration of the host – at account creation or at session creation.

Advantages:

• Usually easy to implement

Challenges:

• Group sizes are limited by a single machine size and scale
• It makes deciding capacities and availability of resources on servers more challenging due to the need to reserve capacity for potential additional users
• Not exactly a challenge, but mostly an observation – to some applications, the user base is such that creating such optimizations makes little sense. An example can be a country-specific service

Cascading

Cascading is also viewed as distributed/mesh media servers architecture – pick the name you want for it.

With cascading, we let media servers communicate with each other to cater for a single session together. This approach is how modern services scale or increase media quality – in many ways, many of the other schemes here are “baked” into this one. Here are a few techniques that are applicable here:

• Always connect a new user to the closest media server available. If this media server isn’t already part of the session, it will be added to the session by meshing it with the other media servers that cater for this session
• When capacity in a media server is depleted, add a new user to a session by scaling it horizontally in the same data center with one of the techniques described in single data server allocation at the beginning of this article
• In truly large scale sessions (think 10,000 users or more), you may want to entertain the option of creating a hierarchy of media servers where some don’t even interact with end users but rather serve as relay of media between media servers

Advantages:

• Can achieve the highest media quality per individual user

Challenges:

• Hard to implement
• Usually requires more server resources

Sender decides

This one surprised me the first time I saw it. In this approach, we “disconnect” all incoming traffic from outgoing and treat each of them separately as if it were an independent live stream.

What does that mean? When a user joins, he will always connect to the media server closest to them in order to send their media. For the incoming media from other users, he will subscribe to their streams directly on the media servers of those users.

Advantages:

• Rather simple to implement

Challenges:

• Doesn’t use good inter-data center links between the servers
• Doesn’t “feel” right. Something about the fact that not a single media server knows the state of the user’s device bothers me in how you’d optimize things like bandwidth estimation in this architecture

A word about allocation metrics

One thing I ignored in all this is how do you know when a server is “full”. This decision can be done in multiple ways, and I’ve seen different vendors take different approaches here. There are two competing aspects here to deal with:

1. Utilization – we want our servers to be utilized to their fullest. Resources we pay for and not use are wasted resources
2. Fragmentation – if we cram more users on servers, we may have a problem when a new user joins a session but has no room on the media server hosting that session. So at times, we’d like to keep some slack for such users. The only question is how much slack

Here are a few examples, so you can make an informed decision on your end:

• Number of sessions. Limit the number of sessions on a server, no matter the number of users each session has. Good for services with rather small and predictable session sizes. Makes it easier to handle resource allocations in cases of server fragmentation
• Number of users. Limit the number of users a single server can handle
• CPU. Put a CPU threshold. Once that threshold is breached, mark the media server as full. You can use two thresholds here – one for not allowing new sessions on the server and one for not allowing any more users on the server
• Network. Put a network threshold, in a similar way to what we did above for CPU

Sometimes, we will use multiple metrics to make our allocation decision.

Final words

Scaling group calls isn’t simple once you dive into the details. There are quite a few WebRTC allocation schemes that you can use to decide where to place new users joining group sessions. There are various techniques to implement allocation of users in group calling, each with its own advantages and challenges.

Pick your poison 🧪

👉 One last word – this article was written based on a new lesson that was just added to the Advanced WebRTC Architecture course. If you are looking for the best WebRTC training, then check out my WebRTC Courses.

The post Different WebRTC server allocation schemes for scaling group calling appeared first on BlogGeek.me.

Around 6 years ago I launched the first WebRTC course here. Since then, that grew into its own separate website and multiple courses and bundles.

Next month, another round of office hours is about to begin. In each such round, there are live sessions where I teach something about WebRTC and then open the floor for general questions. That’s on top of all the recorded lessons, the chat widget and slack channel that are available.

In this round (starting February 6), I am experimenting with something new. This time, I will be adding home assignments…

The dynamics of office hours

The office hours are 10-12 lessons that take place on a weekly cadence at two separate time zones, to fit everyone.

In each I pick and choose a topic that is commonly discussed and try to untangle it from a slightly different angle than what you’ll be finding in the course itself. I then let people ask questions.

The office hours are semi-private. Usually with 2-6 participants each time. This gives the ability to really ask the questions you care about and need to deal with in your own WebRTC application.

Why home assignments?

As part of my new role as the Chief Product Officer at Spearline, I asked to enroll in a course – CPO Bootcamp (the best one if you’re in Israel). It is grueling as hell but more importantly – highly useful and actionable.

One of the components in that bootcamp is home assignment. They are given every week, then they get checked and feedback is given. They make me think about the things I am doing at Spearline and how to improve and finetune our roadmap and strategy. I even share them with my own team – being able to delegate is great, but it is more about the shared brainpower.

As with anything else, when I see something that is so good, I try to figure out if and where I can make use of that idea.

Which brings me to the WebRTC courses home assignments.

Home assignments = implementation AND feedback

For me, home assignments fit the best as part of the office hours.

Here’s what we’re going to do:

• You come to the office hours
• I share a topic related to WebRTC. In this round, the focus will be on requirements and architecture and design – and the planning of it all
• Then, I will present the home assignment for the given round
• You will have time until the following office hour to write down the assignment and submit it – in Google Docs or a Microsoft Word file
• Once submitted, I’ll be reviewing and writing my feedback

The assignments relate and are focused on your WebRTC application. Not to something unrelated. Their purpose is to make you think, revisit and evaluate the things you’ve done and decided.

They are also building upon one another, each touching a different aspect of the design and architecture.

In a way, this is a unique opportunity to get another pair of eyes (mine) looking at your set of requirements, architecture and decisions and offering a different viewpoint.

Getting the most of the WebRTC courses

If you are planning to learn WebRTC, then now is the best time possible.

Those who have enrolled to the course in the last 12 months or have renewed their course subscription can join the office hours and take part in the home assignments.

Office hours will start  February 6.

If you haven’t enrolled yet, then you should 😉More information on how to enroll can be found on the WebRTC courses site.

The post WebRTC course home assignments are here appeared first on BlogGeek.me.

This article has been written along with Philipp Hancke. We cooperate on many things – WebRTC courses (new one coming up soon) and WebRTC Insights to name a few.

—

WebRTC is free. Every modern browser incorporates WebRTC today. And the base code that runs in these browsers is open sourced and under a permissive BSD license. In some ways, free and open source were mixed in a slightly toxic combination. One in which developers assume that everything WebRTC should be free.

The end result? The sorry state in which we find ourselves today, 11 years after the announcement of WebRTC. What we’re going to do in this article, is detail the state of the WebRTC open source ecosystem, and why we feel a change is necessary to ensure the healthy growth of WebRTC for years to come.

Your open source Cliffs Notes

We’ll start with the most important thing you need to know:

Open Source != Free

Let’s take a quick step back before we dive into it though.

What’s open source exactly?

An open source project is a piece of source code that is publicly available for anyone under one of the many open source licenses out there. Someone, or a group of people from the same company or from disparate places, have “banded together” and created a piece of software that does something. They put the code of that software out in the open and slap a license on top of it. That ends up being an open source project.

Open source isn’t free. There’s a legal binding associated with using open source, but it isn’t what we’re interested in here. It is the fact that if you use open source, it doesn’t mean that you pay nothing to no one. It just means that you get *something* with no strings attached.

Why would anyone end up doing this for free? Well… that brings us to business models.

Open source business models

There are different types of open source licenses. Each with its own set of rules, and some more permissive than others, making them business-friendly. Sometimes the license type itself is used as a business model, simply by offering a dual license mode where a non-permissive open source license is available freely and a commercial one is available in parallel.

In other cases, the business model of the open source project revolves around offering support, maintenance and customization of that project. You get the code for free, but if you want help with it – you can pay!

Sometimes, the business model is around additional components (this is where you will see things like community edition and enterprise edition popping up as options in the project’s website). Things such as scripts for scaling the system, monitoring modules or other pieces of operational and functional components are protected as commercial products. The open source part brings companies to use it and raise popularity and awareness to the project, while the commercial one is the reason for doing it all. How the developers behind the project bring food to the table and become rich.

In recent years, you see business models revolving around managed services. The database is open source and free, but if you let us host it for you and pay for it, we’ll take care of all your maintenance and scaling headaches.

And some believe it is really and truly free. Troy Hunt wrote about it recently (it is a really good post – go read it):

“… there is a suggestion that those of us who create software and services must somehow be in it for the money”

To that I say – yes!

At the end of the day, delving into open source is all about the money.

Why?

• If you do this to create a popular project, then your aim is almost always to figure out how to monetize it. Directly (see above examples) or indirectly, by increasing your chances of getting hired for higher paying jobs or into more interesting projects
• Sometimes, you do this because you care deeply about a topic. But the end result is similar. You either have the time to deal with it because you make money elsewhere and this is a hobby – or because the company hiring you is HAPPY that you are doing it (which means you are doing it to some extent for the intrinsic value it gives you at that company)
• You might be doing it to hone your skills. But then again, the reason for all this is to become a better programmer and… get hired

The moment the open source project you are developing is meaningful to two more people, or even a single company, there are monetary benefits to be gleaned. We’d venture that if you aren’t making anything from these benefits (even minor ones), then the open source project has no real future. It gets to a point where it should either grow up or wither and die.

A few more words about open source projects

Just a few things before we start our journey to the WebRTC open source realm:

• Most open source projects are just an API abstracting out a certain activity or capability that you need for your own application development. In the case of WebRTC, we will be focusing on such abstractions that implement specific network entities – more on that later
• When using open source, you usually have a bit more control over your application. That’s because you can modify the source code of the open source components you use as opposed to asking from a vendor to do that when you use a precompiled library
• Many open source projects will have poor documentation. That will be doubly true when they are lacking a solid business model – hobbyists developers are more into writing code than they are explaining how to use that code
• Documentation is an important aspect for commercial use of open source projects. So are its ability to provide a clear API facade and code samples to make it easy to start using

The WebRTC open source landscape

A common mistake by “noobs” is that WebRTC is a solution that requires no coding. Since browsers already implement it, there’s nothing left to do. This can’t be farther away from the truth.

WebRTC as a protocol requires a set of moving parts, clients and servers; that together enable the rich set of communication solutions we’re seeing out there.

The diagram above, taken from the Advanced WebRTC Architecture course, shows the various components necessary in a typical WebRTC application:

• Clients, web-based or otherwise
  • The web browser ones are the ones you get for “free” as part of the browser
  • Anything else you need to figure on your own
• Application server, which we’re not going to touch in this article. The reason being that this is a generic component needed in any type of application and isn’t specific to WebRTC
• Signaling server, taking care of setting up and negotiating the WebRTC sessions themselves
• STUN/TURN server, which deals with NAT traversal. Needed in almost every deployment
• Media server, for media processing heavy lifting. Be it group calling, recording, video rendering, etc – a media server is more than likely to make that happen

For each and every component here, you can find one or more open source projects that you can use to implement it. Some are better than others. Many are long forgotten and decaying. A few are pure gold.

Lets dive into each of these components to see what’s available and at what state we find the open source community for them.

WebRTC open source client libraries

First and foremost, we have the WebRTC open source client libraries. These are implementations of the WebRTC protocol from a user/device/client perspective. Consider these your low level API for WebRTC.

There used to be only a single one – libwebrtc – but with time, more were introduced and took their place in the ecosystem. Which is why we will start with libwebrtc:

libwebrtc

THE main open source project of WebRTC is libwebrtc.

Why?

1. It is the first one to be introduced
2. Chrome uses it for its WebRTC implementation
3. The same goes for Safari, Edge and Firefox – each with a varying degree of integration and use
4. Many of the native mobile apps use libwebrtc internally

Practically speaking – libwebrtc is everywhere WebRTC is.

Here are a few things you need to know about this library:

• libwebrtc is maintained and controlled solely by Google. Every change needs to be signed off by a Googler.
• It gets integrated into Chromium and Chrome, which means it reaches billions of devices
• That means that Google is quite protective about it. Getting a contribution into libwebrtc is no easy feat
• While there are others who contribute, external contributions to libwebrtc are rare and far between
• Remember also that the team at Google doing this isn’t philanthropic. It does that for Google’s own needs, which mostly means Google Meet these days. This means that use cases, scenarios, APIs and code flows that are used by Google Meet are likely to be more secure, stable and far more optimized than anything else in libwebrtc’s codebase
• Did we mention the whole build system of libwebrtc is geared towards compiling it into Chromium as opposed to other projects (like the one you’re building)? See Philipp’s Fosdem talk from 2021.
• Or that some of its interfaces (like device acquisition) are less tested simply because Chrome overrides them, so Google’s focus is on the Chrome interfaces and not the ones implemented in libwebrtc?

Looking at the contributions over time Google is doing more than 90% of the work:

The amount of changes has been decreasing year-over-year after peaking in early 2016. During the pandemic we even reached a low point with less than 200 commits per month on average. Even with these reduced numbers libwebrtc is the largest and most frequently updated project in the open source WebRTC ecosystem.

The number of external contributions is fairly low, below 10%. This doesn’t bode well for the future of libwebrtc as the industry’s standard library of WebRTC. It would be better if Google opened up a bit more for contributions that improve WebRTC or those that make it easier to use by others.

This leads us to the business model aspect of libwebrtc 👇

💰 Money time

What if one decides to use libwebrtc and integrate it directly in his own application?

• There’s no option for paid support
• No real alternative to pay for custom development
• Maintaining your own fork and keeping it in sync with the upstream one is a lot of effort

That said, for the most part, and in most situations, libwebrtc is the best alternative – that’s because it follows the exact implementations you will be bumping into in web browsers. It will always be the most up to date one available.

A side note – libwebrtc is implemented in C++. Why is this relevant? Pion 👇

Pion

Pion is a Go implementation of the WebRTC APIs. Sean DuBois is the heart and sole behind the Pion project and his enthusiasm about it is infectious.

Putting on Tsahi’s cynic hat, Pion’s success can be attributed a lot to it being written in Go. And that’s simply because many developers would rather use Go (modern, new, hip) and not touch C++.

Whatever the reason is, Pion has grown quite nicely since its inception and is now quite a popular WebRTC open source project. It is used in embedded devices, cloud based video rendering and recently even SFU and other media server implementations.

💰 Money time

What if one decides to use Pion and integrate it directly in his own application?

• There’s no option for paid support
• No official alternative to pay for custom development
• There are a handful of contributors to Pion who are doing contracting work

Python, Rust, et al

There are other implementations of WebRTC in other languages.

The most notable ones:

• aiortc – a Python implementation of WebRTC
• WebRTC.rs – a Rust implementation of WebRTC, created as a rewrite of Pion

There are probably others, less known.

We won’t be doing any 💰 Money time section here. These projects are still too small. We haven’t seen too many services using them in production and at scale.

GStreamer

GStreamer is an open source media framework that is older than WebRTC. It is used in many applications and services that use WebRTC, even without using its WebRTC capabilities (mainly since these were added later to GStreamer).

We see GStreamer used by vendors when they need to transform video content in real-time. Things like:

• Taking machine rendering (3D, screen casting or other) and passing them to a browser via WebRTC
• Mixing inputs combining them into a single recording or a single livestream
• Collecting media input on embedded platforms and preparing it for a WebRTC session

Since WebRTC was added as another output type in GStreamer, developers can use it directly as a broadcasting entity – one that doesn’t consume data but rather generates it.

GStreamer is a community effort and written in C. While it is used in many applications (commercial and otherwise), it lacks a robust commercial model. What does that mean?

💰 Money time

What if one decides to use GStreamer and integrate it directly in his own application?

• There’s official option for paid support (by Centricular)
• You can pay Centricular for custom development as well
• The ecosystem is large enough to allow finding people with GStreamer knowledge

Open source TURN server(s)

Next we have open source TURN servers. And here, life is “simple”. We’re mostly talking about coturn. There are a few other alternatives, but coturn is by far the most popular TURN server today (open source or otherwise).

In many ways, we don’t need more than that, because TURN is simple and a commodity when it comes to the code implementation itself (up to a point, as Cloudflare is or was❓ trying to change that with their managed service).

But, and there’s always a but in these things, coturn needs to get updated and improved as well. Here’s a recent discussion posted as an issue on coturn’s github repo:

Is the project dead?

Read the whole thread there. It is interesting.

The maintainers of coturn are burned out, or just don’t have time for it (=they have a day job). For such a popular project, the end result was a volunteer or two from the industry picking up the torch and doing this in parallel to their own day job.

Which leads us to:

💰 Money time

What if one decides to use coturn and integrate it directly in his own application?

• There’s no official option for paid support
• No official alternative to pay for custom development
• The ecosystem is large enough to allow finding people with coturn knowledge

Open source signaling servers for WebRTC

Signaling servers are a different beast. WebRTC doesn’t define them exactly, but they are needed to pass the SDP messages and other signals between participants. There are several alternatives here when it comes to open source signaling solutions for WebRTC.

It should be noted that many of the signaling server alternatives in WebRTC offer purely peer communication capabilities, without the ability to interact with media servers. Some signaling servers will also process audio and video streams. How much they focus on the media side versus the signaling side will decide if we will be treating them here as signaling servers or media servers – it all boils down to their own focus and to the functions they end up offering.

Signaling requires two components – a signaling server and a client side library (usually lightweight, but not always).

We will start with the standardized ones – SIP & XMPP.

SIP and XMPP

SIP and XMPP preceded WebRTC by a decade or so. They have their own ecosystem of open source projects, vendors and developers. They act as mature and scalable signaling servers, sometimes with extensions to support WebRTC-specific use-cases like creating authentication tokens for TURN servers.

We will not spend time explaining the alternatives here because of this.

👉 Here, it is worthwhile mentioning MQTT as well. Facebook is known to be using it (at least in the past – not sure about today) in their Facebook Messenger for signaling

PeerJS

PeerJS has been around for almost as long as WebRTC itself. For an extended period of that time, the codebase has not been maintained or updated to fit what browsers supported. Today, it seems to be kept.

The project seems to focus on a monolithic single server deployment, without any thought about horizontal scaling. For most, this should be enough.

Throughout the years, PeerJS has changed hands and maintainers, including earlier this year:

Without much ado, lets move to the beef of it:

💰 Money time

What if one decides to use PeerJS and integrate it directly in his own application?

• There’s no official option for paid support
• No official alternative to pay for custom development
• The codebase is small, so if you know WebRTC, these challenges shouldn’t pose any real issue

simple-peer

Simple-Peer has been driven by Feross and his name in the early days. It is another one of those “pure WebRTC” libraries that focuses solely on peer-to-peer. If that fits your use-case, great, it is mature and “done”. Most of the time your use-case will evolve over time though.

It has received only a few maintenance commits in 2022 and not many more in 2021. The same considerations as for PeerJS apply for simple-peer. If you need to pick between the two… go for simple-peer, the code is a bit more idiomatic Javascript.

💰 Money time

Just go read PeerJS – same rules apply here as well.

Matrix

Matrix is “an open network for secure, decentralized communication”. There’s also an open standard to it as well as a commercial vendor behind it (Element).

Matrix is trying to fix SIP and XMPP by being newer and more modern. But the main benefit of Matrix is that it comes as client and server along with implementations that are close to what Slack does – network and UI included. It is also built with scale in mind, with a decentralized architecture and implementation.

Here we’re a bit unaligned… Tsahi thinks Matrix is a good alternative and choice while Philipp is… less thrilled. Their WebRTC story is a bit convoluted for some, meandering from full mesh to Jitsi to a “native SFU” only recently.

So… Matrix has a company behind it. But they have their own focus (messaging service competing with Slack with privacy in mind).

💰 Money time

What if one decides to use Matrix and integrate it directly in his own application?

• There’s no official option for paid support
• No official alternative to pay for custom development
• That said, Matrix does have a jobs room on Matrix where you can search for paid help

Everything else in the github jungle

At the time of writing, there are 26,121 repositories on github mentioning WebRTC. By the time you’ll be reading it, that number will grow some.

Not many are sticking out too much, and in that jumble, it is hard to figure out which projects are right for you. Especially if what you need needs to last. And doubly so if you’re looking for something that has decent enough support and a thriving community around it.

Open source SFUs and media servers in WebRTC

Another set of important open source WebRTC components are media servers and SFUs.

While signaling servers deal with peer communication of setting up the actual sessions, media servers are focused on the channels – the actual data that we want to be sending – audio and video streams, offering realtime video streaming and processing 👉 Whenever you’ll be needing group sessions, broadcasts or recordings (and you will, assuming you’d like video calls or video conferences incorporated in your application), you will end up with media servers.

Here’s where are are marketwise 👇

Janus, Jitsi, mediasoup & Pion

I’ve written about these projects at length in my 2022 WebRTC trends article. Here’s a visual refresher of the relevant part of it:

Janus, Jitsi, mediasoup and Pion are all useful and popular in commercial solutions. Let’s try to analyze them with the same prism we did for the other WebRTC open source projects here.

Janus

• There’s official paid support available from meetecho
• You can pay meetecho for consulting and paid development. From experience, they are mostly busy which means they are picky with who they end up working with
• The Janus ecosystem is large enough and there are others who offer development services for it as well

Jitsi

Jitsi can be considered a platform of its own:

• At the heart of Jitsi is the Jitsi Videobridge, with additional components around it, composing together the Jitsi Meet video chat app
• There’s also a managed CPaaS service offering as part of it – 8×8 JaaS

💰 Money time

• Jitsi was acquired a few years ago by 8×8. Which means that there’s no official option for paid support
• Similarly, custom development isn’t available
• The Jitsi ecosystem is large enough and there are others who offer development services for it as well
• Oh, and like Matrix (where Element offers paid hosting), 8×8 JaaS offers paid hosting for Jitsi (=CPaaS). There’s also Jitsi Meet which is essentially a free managed service built on top of Jitsi itself

Mediasoup

• mediasoup is maintained by 2 developers who have a day job at Around. Which means that there’s no official option for paid support
• Similarly, custom development isn’t available
• The ecosystem around mediasoup means you can get developers for it as well

Pion

• We’ve already discussed Pion when we looked at WebRTC clients
• Assume the same is true for media servers
• Only you have the headache of choosing which media server written on top of Pion to use

–

To be clear – in all cases above, getting vendors to help you out who aren’t maintaining the specific media server codebase means results are going to be variable when it comes to the quality of the implementation. In other words, it is hard to figure out who to work with.

The demise of Kurento

The Kurento Media Server is dead. So much so that even the guys behind it went to build OpenVidu (below) and then made OpenVidu work on top of mediasoup.

Don’t touch it with a long stick.

It has been dead for years and from time to time people still try using it. Go figure.

Higher layers of abstraction

A higher layer abstraction open source project strives to become a platform of sorts. Their main focus in the WebRTC ecosystem is to offer a layer of tooling on top of open source media servers. The two most notable ones are probably OpenVidu and LiveKit.video conferencing 

OpenVidu

OpenVidu is a kind of an abstraction layer to implement a room service, UI included.

It originates from the team left behind from the Kurento acquisition. With time, they even adopted mediasoup as the media server they are using, putting Kurento aside for the most part.

💰 Money time

Unlike many of the open source solutions we’ve seen so far, OpenVidu actually seem like they have a business model:

• There’s an official commercial support available
• There are hosted commercial plans available as well as consulting and development work

LiveKit

LiveKit offers an “open source WebRTC infrastructure” – the management layer above Pion SFU.

For the life of me though, I don’t understand what the business model is for LiveKit. They are a company – not just an open source project, and as such, they need to have revenue to survive.

Most probably they get some support and development money from enterprises adopting LiveKit, but that isn’t easily apparent from their website.

Other, less popular open source alternatives for WebRTC

There are other companies who offer commercial solutions that are proprietary in nature. Some do it as on premise alternatives, where they provide the software and the support, while you need to deploy and maintain.

These can either be suitable solutions or disasters waiting to happen. Especially when such a vendor decides to pivot or leave the market.

Tread carefully here.

Is it time for WebRTC open source to grow up?

This has been a long overview, but I think we can all agree.

The current state of WebRTC open source is abysmal:

• We are more than 10 years in
• There are thriving open source projects for WebRTC out there
• These projects are used by many – hobbyists and professionals alike
• They are found inside commercial applications serving millions of users
• But they offer little in the way of support or paid help
• Somehow, the market hasn’t grown commercially

If it were up to us, and it isn’t, we’d like to see a more sophisticated market out there. One that gives more and better commercial solutions for enterprises and entrepreneurs alike. 

The post The state of WebRTC open source projects appeared first on BlogGeek.me.

In the past couple of months we’ve seen two new entrants to the managed WebRTC TURN business. After stagnation for many years, this small market niche is becoming interesting. REALLY interesting.

TURN and the WebRTC developer ecosystem

TURN servers are used in WebRTC in order to get your sessions connected if there’s no direct route available. I am not going to go into the technical part of it, but I’d say that without TURN servers, not all of your WebRTC sessions will get connected. You don’t need it for all sessions, but for some, you won’t be able to work without it. They are an essential component that has its own category in my WebRTC Developer Tools Landscape.

At the end of the day, TURN servers act as intermediaries by relaying the media between two points.

Roughly speaking, you have 3 alternatives in how you can get these set up:

1. Self host. You can install and host your own TURN servers and manage them on your own. In most cases, this will be by using the open source coturn server
2. Managed. You can use a third party that runs its own TURN servers, giving you access to their servers, paying for the service. Don’t search for free TURN servers – if they exist, then they aren’t worth the money you aren’t paying for them
3. Everything and the kitchen sink. You could just go with a WebRTC CPaaS vendor. These will give you everything you need, including TURN servers and service. An all in one deal

In this article, I will be ignoring the “everything and the kitchen sink” approach. Not because it is bad, but because if you’re just interested in a managed WebRTC TURN, then you probably want to control a bit more of your destination (more on that later).

Challenges of using open source coturn in production

Let’s start with the self hosting approach. The leading choice today is to take coturn, a popular open source TURN server, and deploy it on your own. There are one or two other alternatives, but this is by far the most common one.

The challenge though stems from the fact that for TURN the majority of the issues aren’t around integration or development but rather in configuration and maintenance. As such, it falls into the laps of ops, but requires knowledge and understanding of WebRTC.

The main culprit? The fact that you don’t need TURN for each and every session – and that there are 3 different TURN transport protocols, offering a progressive fallback mechanism.

What does that mean?

You install and configure your TURN server. But how do you test that all went well? Just conducting a WebRTC session will not tell you that. If the session succeeded, is it because it didn’t need TURN or because it used your TURN server properly? And if it did use it properly, was that on all 3 different transport protocols?

Configuring TURN is a headache:

• Testing TURN configuration it isn’t straightforward
• Scaling TURN horizontally may seem simple, but it has its own set of challenges
• Geolocating TURN servers properly is tough and tricky when you’re small
• Securing your TURN servers from abuse isn’t hard, but another necessary task. So is monitoring it
• And then there’s the hacking angle to it, as Slack found out in 2018

Managed WebRTC TURN – the early days

In the early days of WebRTC, developers had two main alternatives:

1. DIY – building everything on their own, including the installation and configuration of their TURN servers
2. CPaaS – “outsourcing” all of the WebRTC infrastructure components including their TURN servers to a third party vendor who specializes in it

You either knew what you were doing or didn’t want to know what you were doing.

The initial indication for managed WebRTC TURN service came from two vendors. It started with Xirsys and continued with Twilio.

Xirsys

Xirsys was the first vendor to offer a managed WebRTC TURN service commercially. It was limited to a data center or two when they started, but grew over time.

Today, the Xirsys Cloud service spans 7 regional data centers.

Twilio

Twilio is the most widely known CPaaS vendor out there. It is playing the best of suite game, with its large and growing portfolio of services. One of these products is their Twilio Global Network Traversal Service, a half-hidden product that enables you to leverage their TURN servers for your application without using their other CPaaS and WebRTC products.

At the time of writing, Twilio runs its media over 9 different regions, all on AWS.

Why use a managed WebRTC TURN service?

I guess it is a matter of experience and expertise. Do you really want to deal with questions such as how do you decide which TURN server to connect a user to? How to deal with WebRTC TURN geolocation?

A managed WebRTC TURN service eventually targets the exact pain points and challenges that setting up your own TURN servers pose:

• Someone else takes care of properly configuring the TURN servers (assuming they know what they are doing)
• They take care of scaling this for you, so you don’t need to deal with increases in traffic, at least not on the TURN servers
• You get someone else to decide on geolocation (and do it better than you can for the most part)
• Inherently, managed WebRTC TURN services secure their service from abuse, so that’s also a given – oh – and they’ll provide you with a nice usage dashboard as well

The best thing about managed WebRTC TURN services?

There’s no vendor lock-in.

Switching from one managed WebRTC TURN service to another or to your own self installed servers is a breeze – just change the iceServers configuration on your peer connections in WebRTC and you’re done. Theoretically, that’s a single line of code change.

It is also why I suggest anyone who is building their own WebRTC application to start by using a managed WebRTC TURN service – they can always switch to their own, and the cost of switching next year will be the same as just building it today. And as the lazy person that I am, I will always postpone to tomorrow something that I don’t have to do today.

Managed WebRTC TURN – the post-pandemic version

Then came the pandemic, with its lockdowns, quarantine and the rise in use of WebRTC and any other remote communications technology.

The market stayed roughly the same for managed WebRTC TURN servers, or at least it did until 2021. What happened is that we now have 2 more vendors in this domain: Subspace and Cloudflare. And they are different: they are bigger in the physical footprint they have and they make use of Anycast – an IP addressing and routing scheme used to connect a large set of globally spread servers via a single IP address. This type of a solution also makes things a lot simpler to whitelist when needed.

Subspace GlobalTURN

Subspace offers better connectivity than the open internet. They do that by optimizing the routes your packets go through. What you do is send your packets through their network, which will then figure out the best route.

In 2021, they decided to expand what they are doing to WebRTC as well, offering their GlobalTURN service. With around 100 cities and an Anycast addressing scheme, they offer a global footprint.

For Subspace, this isn’t the first VoIP related product they offer, but it is the first WebRTC related one. Would they move towards hosting media servers as well? I think it is an unlikely path for them.

Cloudflare WebRTC Components

Cloudflare announced their own deployment of a managed WebRTC TURN service called WebRTC Components. Besides it being a TURN service, there’s not much to go by yet.

What we do know is that it relies on Cloudflare’s anycast network spanning 250+ cities.

For Cloudflare, this is the first WebRTC related offering, which was announced alongside a slew of other capabilities, targeted at cloud vendors (their R2 storage which directly competes with AWS S3 for example). There’s a good overview of the disruption path Cloudflare is taking. The WebRTC addition to it is an interesting choice.

Interestingly, I debated the potential of using Cloudflare’s Workers as a TURN service enabler when it was announced. Seems like they decided to build it on their own 😎

Which managed WebRTC TURN service to use?

That should be the question you should ask yourself.

It isn’t about whether you should use a managed WebRTC TURN service or deploy your own – it should be which managed WebRTC TURN service to select. Why? Because this is super simple to adopt and replace with zero vendor lock-in.

Pricing is important, but also global footprint, latency and quality. Then there are things like actually doing its job – the percentage of successful connections you get with it.

It will be interesting to see if and how Xirsys and Twilio address the threat from the newcomers to this market niche. For Xirsys this should be more worrying than it is for Twilio, as that’s one of their core products, whereas for Twilio it is a small part of what they offer to their customers.

Who would have thought that in 2021 we will see competition and innovation coming to the managed WebRTC TURN service?

The post Managed WebRTC TURN: The need for speed appeared first on BlogGeek.me.

The State of online WebRTC resources

Where should you start with WebRTC? There’s not enough information about it and at the same time too much information about it. Most of it is old and outdated. Needle in a haystack.

Sift through discuss-webrtc, stackoverflow and the W3C WebRTC mailing list? All great. But there’s no explanation besides pieces of code. It lacks context.

Read the spec and work your way from there? If you don’t fall asleep, you might just find that browsers aren’t exactly spec compliant yet anyways.

Books? None from 2020. None from 2019. Less than 10 in total. A handful.

How about online courses? There are a few on udemy and pluralsight, but they are also old and broken by now.

My own Advanced WebRTC Architecture course? While great, I purposefully haven’t gone through the APIs of WebRTC, understanding they change so frequently.

A codelab then? Sure. find one that works and explains signaling properly.

The way I see it, there are 3 types of WebRTC codelabs today:

1. The outdated ones
2. The broken ones
3. The ones that sell you a managed streaming service

Enter Philipp Hancke

I’ve been working with Philipp here and there in the last couple of years. He is fun to work with and knows everything there is to know about WebRTC and the intricacies of its APIs along with the status of browsers.

Here’s a bit about him:

I don’t quite recall how, but we got to the point a couple of months back that it would make sense to create a solid WebRTC codelab that covers the signaling aspects of WebRTC. Simply because there is nothing out there that does the trick properly.

The missing WebRTC codelab

Fast forward to today, we have a codelab course for you:

The codelab has 4 parts to it:

1. Github repo and course introduction module, both publicly available
2. Codelab walkthrough. Over 2 hours of recorded lessons covering the source code and explaining all you need to know to grok it
3. Exercises. We’ve started creating useful exercises on the codelab. These include the challenge, the solution and the explanation. Along with the additional code for the solution and best practices
4. Resources library. If you are new to WebRTC, this will come handy in closing some gaps for you. They are lessons from my other courses that fit nicely here

We’ve made sure the lessons aren’t boring by making them interactive. I’ll be there with Philipp, taking the part of the student asking questions. The intent is to try and get into his head, understand his thought processes. What do you gain out of it? You will understand why things are implemented that way and not only how.

WebRTC Codelab FAQ

The post WebRTC codelab: New training appeared first on BlogGeek.me.

When I wrote that WebRTC is ready over 6 months ago it pissed a few people off.

Here’s the thing – WebRTC is ready simply because the industry deems it ready and companies are deploying products that rely on WebRTC to work for them.

Are there challenges along the way? Sure.

Do things break? Sure.

But if you are thinking of whether you should start using WebRTC and build an application on top of it or wait for the next fad to come by for your video calling service, then don’t. Use WebRTC as nothing else will do today.

WebRTC 1.0 – the specification

In 2015 I remember someone telling me that WebRTC 1.0 will be closed and published by year end.

I heard the same in 2016. And later in 2017.

In 2018 I ignored such promises.

2019? There is a small chance that things will be ready. Why? Because the spec is almost completed. That almost is the sticking point.

But then again, who cares?

Everyone is already using WebRTC as if it is a done deal. Because it is.

We’ve agreed on the technology (WebRTC). We’ve agreed on the larger picture and the ways things are going to look like (peer connection and how browsers implement it today). We’re left with the nitty gritty details of how to make the experience easier and uniform across browsers for developers. We will get there, but just remember – users expect it to work, and it does.

Chrome and WebRTC

Consider Chrome to be the de facto specification for WebRTC. It isn’t WebRTC 1.0 compliant. Yet. According to Statista, 69% of the desktop internet is driven by Chrome. On this website? 74% of the viewers use Chrome.

The thing about Chrome is that it is slowly getting the missing WebRTC 1.0 support, and by moving there it is breaking things up with each release. Usually because the way it works today isn’t exactly spec compliant, so things have to break – or just because the additions are delicate and the work done breaks behavior that developers relied on in the past. At times, it is because Google has no qualms when it comes to technical debt and code rewrites and when it sees a need to optimize something it usually does that (we’re now in the 3rd generation of echo canceller in WebRTC, each one was a complete rewrite of the previous one).

If you are developing anything that needs to run in the browser and use WebRTC, then Chrome is the first thing you should be developing for.

Firefox and WebRTC

Firefox is close to be spec compliant when it comes to WebRTC.

They had it easy with the recent decision to adopt Unified Plan instead of Plan B in the WebRTC specification. Where Google had to shift from Plan B to Unified Plan, Firefox had only slight modifications to make.

The problem is that Firefox is a distant second to Chrome in market share. At times, developers actively decide not to support Firefox just because they consider it a waste of time. This is doubly true for those who use Chrome for guest access and as a stepping stone to getting their users to download their Electron app instead.

Safari and WebRTC

Safari now supports WebRTC. That includes things like simulcast and both VP8 and H.264. Which is to say that most WebRTC features already work in Safari, but not all of them.

You wouldn’t find VP9 which isn’t mandatory or popular yet, but something that is more than desirable. And then some of the more complicated scenarios such as multiparty sessions have more pending open issues of both functionality and interoperability than Chrome or Firefox have.

The challenge is that Safari is important to developers. Both because it is the only way to get on iOS devices and because it is the default browser for Mac, a desktop/laptop that for some reason is becoming a fad with developers (go figure).

Edge and WebRTC

Edge was once its own browser with its own technology stack, but is now becoming just another flavor of Chrome. Microsoft announced that Edge will be using Chromium as its browser engine. This has gotten Edge to work on Mac already with rumors of a possible Linux release.

Edge runs on Chromium.

Chrome runs on Chromium.

Chrome isn’t WebRTC spec compliant because Chromium isn’t WebRTC spec compliant.

So Edge isn’t spec compliant either. But it is well… the same as Chrome.

This all relates to the upcoming official release of Edge.

Microsoft IE and WebRTC

Still dream about Internet Explorer at night?

Stop it.

IE won’t be supporting WebRTC. Not now and not ever.

Use a plugin or just use Electron. Or better yet – update to a more modern browser.

Opera/Brave/whoever and WebRTC

Most of the other browsers out there, be it Opera, Brave or anything else is just a fork of Chromium or a skin on top of Chromium.

For all intent and purpose, they are Chrome, offering the same spec compliance to WebRTC as Chrome does. At least if they haven’t gone and intentionally made changes to it (like disabling it in the name of privacy).

Android and WebRTC

Android has support of WebRTC.

Chrome browser that ships with Android has WebRTC support.

Other browsers shipping on Android have WebRTC support (such as Firefox).

Sometimes, a device manufacturer ends up shipping his own browser (Samsung for example). Then WebRTC compliance and availability is somewhat questionable.

The good thing is that the Webview in Android also supports WebRTC. So built-in application browsers such as the one used by Facebook or Slack also end up supporting WebRTC experiences.

And if you write your own app, you can use the Webview, a precompiled version of WebRTC for Android or compile it on your own.

iOS and WebRTC

On iOS things are slightly trickier.

Safari supports WebRTC on iOS and there are companies making commercial use of it already.

Other browsers don’t and can’t support WebRTC on iOS. That’s because the supplied iOS Webview still doesn’t support WebRTC (or disables it on purpose).

If you write your own app, you can use a precompiled version of WebRTC for iOS or compile it on your own. No Webview for you yet.

Your Next Steps?

Haven’t started with WebRTC yet? Now’s the time. I can help.

Also, go ahead and learn more about WebRTC browser support.

The post What’s the status of WebRTC in 2019? appeared first on BlogGeek.me.

Here’s a comment left on one of my recent articles:

WebRTC is… still just a little confusing…Tsahi, i’m reading the book recommended by Loreto & Romano but the examples are outdated. With regards to the SDP signal – if peer A is on a webRTC application, but peer B is surfing youtube – How does peer B get notified of an offer? It would have to go to peer B’s email address right? — because there is no way of knowing peer B’s IP address. Please help.

A few quick things before I dig deeper into this WebRTC connectivity thing:

• Yap. WebRTC is a little confusing. Maybe even a lot. It doesn’t behave like any other browser technology we have
• The sad thing about books about WebRTC is that they didn’t age all too well. WebRTC still changes too fast
• There’s some confusion here in wording – peers, offer, etc.

Connecting, Signaling and WebRTC

I’ll try to use a kind of a bad comparison here to try to explain this.

Let’s say you are the proud owners of a Pilates studio. You’re the instructor there (#truestory – at least for my wife).

My wife gives Pilates lessons at different hours of the day. These are private lessons so it is rather flexible on both sides. But let me ask you this – how do people know when to come for a lesson?

This being Israel, they usually communicate with my wife via Whatsapp to decide together on the date and time. Usually, people stick to the day of week and time and start communicating only if they can’t make it, want to reschedule or just make sure the lesson is still taking place.

Back to WebRTC.

WebRTC is that Pilates studio. It does one thing – enables live media to flow from one browser to another. Sometimes also non-browsers, but let’s stick to the basics here.

How do the people who need to share or receive that live media connect to each other? That’s not what WebRTC does – it happens somewhere else. And that somewhere is the signaling mechanism that you pick for your own application. I am calling it a mechanism and not a protocol, since it is going to be a tad more confusing in a second.

Or not.

Now let’s go back to WebRTC, signaling and connecting people and look at it from a point of view of different scenarios.

Scheduled Meeting

We’ll start with a scheduled meeting. At any given point in time, I have a few of those coming up. Meetings with clients, partners and potential clients. Here’s one such calendar invitation:

This one happens to take place using Google Meet. Who’s calling who? No one really. I’ll just click that link in the invite when the time comes and magically find myself in the same conference with the other participants.

In most scheduled conferences, you just join a WebRTC link

Where do you get that link to use?

• Inside the calendar invite
• In an email that was sent
• Through an SMS reminder

Some of these services allow inviting people from inside the meeting. That ends up being sent to them via email or an SMS as a link or just dialing their phone (without WebRTC).

Ad-hoc “upgrade” of text chat to video conference

There are ad-hoc calls. These usually start from a chat message.

Often times, I’d rather text chat than do a voice or a video call. It has to do with the speed and asynchronous nature of text. Which means that I’ll be chatting with someone over whatever instant messaging service we select, and at some point, I might want to switch medium – move from text to something a bit more synchronous like video:

Like this example with Philipp – most of our conversations start in Hangouts (that’s where he is most reachable to me) and when needed, we’ll just jump on a call, without planning it first.

Who is calling whom here? Does it matter?

What happens here is that both of us are already “inside” the communications app, so we both have a direct link to the service. Passing that information from one side to the other is a no brainer at this point.

So how will that get signaled? However you see fit. Probably on top of a Websocket or over HTTPS.

I am calling you on the “phone”

What if there’s nothing pre-planned, so it isn’t a scheduled meeting. And we haven’t really been on a text chat to warm things up towards a call. How do you reach me now?

How do you “dial”?

Puneet is one of our support/testing engineers at testRTC. While he will usually text me over slack to start a call, he might just try calling directly from time to time.

What happens then?

I am not in front of my laptop with the Slack app opened. My phone is on standby mode. How does it start ringing on me? What does WebRTC do to get my attention?

Nothing.

The phone starts dialing because it received a mobile push notification. I’ve got the Slack app installed, so it can receive push notifications. Slack invoked a push notification to wake up the app and make it “ring” for me.

The same can be done with web notifications. And there are probably other means to do similar things in IOT devices. The thing is – this is out of scope for WebRTC, but something that is doable with the signaling technologies available to you.

Contact center agent answering calls

When a contact center adopts WebRTC to be able to migrate its agents from using desktop phones or installed softphone towards WebRTC, calls will end up being received in the browser.

This happens by integrating callbars inside CRMs or just by having the CRM implement the contact center part of the equation as well.

What happens then? How do calls get dialed? (the above is a screenshot taken from Talkdesk’s support site)

They go through PSTN towards a PBX. More often than not, that PBX will be based on Asterisk or FreeSWITCH, though other alternatives exist. PBXs usually base themselves around the SIP protocol, which will lead to two alternatives on the signaling protocol that will be used by WebRTC in the browser:

1. SIP over Websocket. Practically the same thing happening in SIP will happen on the browser
2. Some proprietary protocol will be used, translated from SIP

In both cases, the contact center agent is registered in advance. It is also marked as “available” in most contact center software logic – this means that incoming calls waiting in the call center queue can be routed to that agent. So it is sitting and waiting for incoming calls. In some ways, this is similar to the upgrade from text chat scenario.

Connecting? WebRTC?

When it comes to actual users, WebRTC doesn’t get them “connected”. At least not from a signaling point of view.

What WebRTC does is negotiate the paths that the media will use throughout the session. That’s the “offer-answer” (or JSEP) messages that pass between one WebRTC entity to another. And even that isn’t sent by WebRTC itself – WebRTC creates the blob of data it wants to send and lets your application send it in any way you see fit.

The post How does WebRTC connect people? appeared first on BlogGeek.me.

It seems that Jitsi has now switched hands, moving from Atlassian to 8×8.

Three months ago, Atlassian made a bold (desperate?) decision. It put up a white flag, decided to kill Stride, after investing in it huge amounts of money and resources, throw Hipchat along with it, and “sell” them to Slack, who “acquired” them.

The weird thing in this acquisition was that Jitsi was left behind.

Jitsi is an open source media framework. One of the most popular WebRTC frameworks out there. I wrote about that acquisition in 2015. The reason behind it was Atlassian’s need to own the video communications technically that powered Hipchat. And now that Hipchat is gone, what would Atlassian need Jitsi for?

The last 3 years

The last 3 years have been good for Jitsi in Atlassian.

The team of developers it had was big, considering its scope (and open-sourceness). Especially if you factor in the fact that everything that Hipchat (and Stride) needed from Jitsi was implemented directly inside Jitsi. Not on a private branch of the project available only to Atlassian.

Compare it to how Twilio treated Kurento after its acquisition… Atlassian did a great job at keeping Jitsi’s momentum and community. At the very least, it didn’t hurt the project, letting it grow and flourish, paying the salaries of its developers.

The interesting initiative that took place alongside the Jitsi open source project is Jitsi Meet – a free version of a group video calling service. One that wasn’t limited to a small number of participants or lower video resolutions.

Jitsi is in a better place than it were 3 years ago prior to its acquisition.

Leaving Atlassian

Leaving Atlassian was a matter of time.

There was no room in today’s Atlassian for an open source project like Jitsi that brings no added value to its commercial products.

Jitsi didn’t go to Slack as part of the Hipchat/Stride deal. Slack were already using Janus, and moving on to their own homegrown media server – something they shared with us at Kranky Geek 2017 (hint: come and join us this year at Kranky Geek 2018). There was no reason for them to further invest in yet another migration – or they might have wanted to migrate to Jitsi and acquihire the team but it didn’t pan out.

That left Atlassian with one of 3 alternatives:

1. Kill the project and be done with it. Send the developers home or integrate them into some other parts of Atlassian. It would work nicely, but if the asset can be sold, then why not recoup some money?
2. Spin out the project. Let the team go, giving them back ownership of the code, and have them go scrape for a livelihood around Jitsi. Probably by offering a commercial license, support and customization services, etc. – this isn’t that far out as an idea – it is how Janus (another open source media framework) operates today and how Jitsi operated prior to its acquisition by Atlassian
3. Sell it to someone who’s interested in it. This is what it ended up doing. Given the other alternatives in front of them, I tend to agree with Andy’s statement that this is a mercy sale

Joining 8×8

8×8 acquiring Jitsi is an interesting choice.

Here’s where things get interesting:

8×8 already has a WebRTC based web conferencing solution called “8×8 Virtual Office Meetings Online”. Somewhere in 2016, this service got rewritten. At some point between then and now, guest access on Chrome was introduced. From the looks of it, based on WebRTC.

Why would 8×8 need/want Jitsi when it had a solution already?

I can think of three possible reasons for it:

1. Their WebRTC solution isn’t that good, too expensive, and they were looking for a better alternative. Jitsi was a catch in such a case
2. 8×8 is looking to own its video technology and not use third party software, commercial or open source
3. They were using Jitsi for their 8×8 meetings thingy and Atlassian selling that assent was an opportunity for them to control the tech stack without relying on a third party – probably on the cheap

What would 8×8 do with Jitsi?

The obvious thing is to integrate the tech into its meetings service. If it is already there, then use the Jitsi team of developers to tweak and finetune the thing for the 8×8 use case.

If it isn’t there yet, then integrate it and replace its current WebRTC tech in the meetings app. This is a more challenging undertaking, as Jitsi will need to meet the current feature list of what 8×8 already has in that domain, along with integrating to an existing codebase of a service and an application.

Jitsi probably has most of the needed features to make this happen. It wouldn’t have been acquired otherwise.

On a different area, 8×8 has no real open source activity at the moment. Its github account is mostly forked repos. Searching for “8×8 open source” is dominated by the Jitsi acquisition news:

(the rest are comparisons to other vendors, who are leaning more heavily on open source)

If 8×8 is interested in embracing open source, then it just got an interesting opportunity to do just that. While brings me to the last topic –

The future of Jitsi

What will be of Jitsi?

Here we need to look at Jitsi and Jisti Meet separately.

Jitsi

The Jitsi Videobridge, along with its derivatives, add ons, plugins, extensions and client-side SDKs.

That’s the open source part of the project. At Atlassian, there was nothing kept for internal use of Hipchat/Stride. Everything found its way back to the open source project.

Will 8×8 continue in that path?

Their focus in the coming months is going to be the integration of Jitsi into their 8×8 meetings service. They are bound to use the resources of the Jitsi team to do that.

Managers may decide to implement some of the features in the 8×8 meetings service moving forward and not invest in adding it to the Jitsi open source project. Or they might decide to add everything via Jitsi.

8×8 might end up taking the extreme – ditching the Jitsi project as an open source one – embed it into their meetings app and from there on, invest in that privat branch only. I see that as a highly unlikely outcome in the next 2-3 years.

Time will tell which direction is taken.

Jitsi Meet

Jitsi Meet is a different story altogether.

It is a group video meeting service. One which doesn’t limit the users’ bitrate in sessions, doesn’t limit the number of users in a session, offers mobile apps, Slack and calendar integration and scales globally. All for free.

Would 8×8 see it as competition to their own 8×8 meetings app? If it grows in popularity and its maintenance costs increase, how happy would 8×8 be in paying the bills? Would it see Jitsi Meet as a sales tool for its other services? How would it measure the success of this service?

Whatsapp’s founders just left Facebook this year. It was over disputes about data, privacy and such. Most of all, it was probably a dispute around the future of Whatsapp and Facebook’s intent of monetizing the asset. The same (at a much smaller scale) can happen here at some point.

How would 8×8 monetize Jitsi Meet? Should it? If it doesn’t, should it kill it?

I don’t know the answers. I am sure 8×8 doesn’t either. It is just too early to tell.

Last Words

Jitsi is an open source success story in WebRTC. There’s no doubt about it.

It is now entering a new chapter in its life, under 8×8.

I wish the team the best of luck and us as an industry to have the option to use Jitsi for our future projects.

The post 8×8 Acquires Jitsi From Atlassian. Winners and Losers appeared first on BlogGeek.me.

Carriers have a problem

SMS won’t stay here forever. In fact, most of the messaging traffic is happening on social networks now.

Voice is shifting as well. Migrating to these same social networks. With the ability to upgrade these calls to video calls. With stickers. And silly hats, cat lenses and whatnots.

Their circuit switched network technology is decaying, left in its 80’s or probably 50’s. Most of what goes on there is spam or OTP passwords anyways. Nobody cares.

So much so that Google is planning on diverting incoming calls to its assistant (but more about it later).

The solution, in the form of IMS and later RCS (or call it Joyn or whatever other branding it was given throughout the years) are some 20 years in the making. And they don’t seem to be coming any time soon. At least not if left to the arduous processes of carriers and their suppliers.

Google has a problem

A VERY different problem.

Google has no messaging clout.

For consumers?

Apple iMessage wins on iOS. It acts as a Chameleon, catching up your messages and deciding if they should be demoted to SMS or use modern messaging via iMessage instead.

Facebook with Messenger and Whatsapp is ruling supreme in Android, and in many cases on iPhones as well. Where they aren’t as strong, you’ve got a slew of other social players with 100+ million monthly active users. None of them looks like a carrier. And none of them is Google.

Google has Allo, Duo, Chat, Meet, Hangouts, Messages and probably a few more apps that I’ve forgotten to mention. All in different states and capabilities; but none which is dominant compared to its competitors. Actual monthly active users and amount of real messages going between users? Not shared. Probably not stellar.

And Google has RCS..

For businesses?

Apple, Facebook and others are adding APIs. Introducing bot platforms. Building marketplaces. And they are doing it slowly, fearful of becoming the spam cesspit that is the good ol’ carrier communications tech today.

Slack is killing it. And the rest of the cadre of UCaaS and enterprise communications players are trying to move into their space.

Google has Meet and Hangouts Chat. Part of G Suite. Meet gets used. Hangouts Chat I don’t really know. But it seems that most just skip it and move on to Slack or some other tool.

Google also has nothing similar to a business angle to its consumer facing communications applications yet, or at least nothing popular enough.

What’s new in RCS land?

Nothing really.

I’ve written in April about RCS being still dead. For some reason, Google is still hammering away at it. Similar to Google+ if I need something to compare it to.

A press release last month by Samsung and Google brings Samsung to the RCS graveyard. New Samsung devices, and maybe layer older ones will come -gasp- with a Samsung Messages app that will work seamlessly with the Android Messages app using each other’s RCS technology!

This interoperability nightmare of the carriers will continue on, leaving RCS dead.

Adding new carriers or smartphones or chipset makes into the fold won’t help either.

And it isn’t as if Apple is making any noises of being interested in RCS, and why should they be?

That said, there are those who will be adopting RCS.

We are shifting towards an omnichannel world. No single protocol to rule them all. No single vendor to rule them all. You want to send your message as a business to a consumer?

You can use SMS. Or better do it over Messenger or Whatsapp or Apple Business Chat – there’s more context and richness in those, and consumers actually care about these channels. Which brings us to a place where businesses just need to support wherever their customers are with no decent common denominator.

And wouldn’t it be great if we could throw SMS and use RCS instead? At least where we can?

So CPaaS vendors are adding support for RCS and announcing it in their arms race to world domination by collecting as many social messaging icons as they can.

That’s great, but not enough to save RCS.

Can Google change RCS predicament?

Not really.

There are just too many players and this is a domain where Google has been struggling to go it alone as it is.

Here’s what it takes to bring RCS properly to the masses:

Chipset vendors

Chipset vendors are at the bottom of the food chain, but they need to offer their support to make RCS happen.

Unlike other messaging services, RCS is “bolted” on to the identity of the user and his device. The SIM card. The ability to connect the end user, through an application, to the SIM card, and from there to the carrier network is what presumably makes RCS different. But for that to happen, chipset vendors need to pave the way, even if just a little bit.

Handset manufacturers

Handset manufacturers need to make sure that the RCS application is there implemented, supported and pre-installed in the device.

Without being pre-installed, users will need to pick and choose between an RCS app from a handset manufacturer or a carrier (the word bloatware comes to mind) OR pick Whatsapp instead. The choice is a simple one for most.

They need to make the application attractive and sleek. Things they can’t really do. Competing with current successful social messaging apps requires a lot of investment. Nailing the user experience is a lot harder than it looks.

Carriers

Carriers need to actually support RCS. As a service. In their network. And have these things called mobile phones that support RCS. and enough people that have these devices so they can actually talk to each other.

Preferably, all carriers within a country should light on the switch on RCS simultaneously.

How likely is that to happen?

Single, very complex specification

And all of these players need to do so for a very complex IMS/RCS specification.

Testing the combinations of devices and networks is going to be hellish, especially for those who aren’t going to just select the default Google implementation of RCS client/server.

Which is exactly what Samsung decided to do. Have its own service and then interoperate it with Google’s. I can easily see other big players – chipset vendors, handset vendors and carriers who would be either scared shitless of ceding control to Google or not magnanimous enough in letting Google take control over that piece.

This headache also suggests something really important:

If RCS succeeds, it won’t move as fast as any of the other social networks in introducing new features, services and capabilities

There are too many moving parts, controlled by different players, some of which doing the same things.

Network effects

Then there’s the network effects.

When can I use RCS on my phone?

It needs to be installed there. Probably pre-installed.

The people I communicate should have it as well.

Our networks should support it.

Oh – and there’s this minor detail of me actually going into that app to send a message.

How many times this week have you clicked on this icon on your Android phone?

What about these icons?

Enter Artificial Intelligence

I’ve been thinking about it for quite some time.

How can Google become relevant in messaging?

It is unlikely to come from features and capabilities at the core of social messaging. None of its services stick:

• Google+ was “shutdown” publicly this month. Google found a great excuse – a potential security flaw
• Duo was supposed to compete head-on with Apple FaceTime, offering things like faster connections and knock knock feature. But what have we seen from Duo since its launch? And are you using it at all?
• Allo was interesting, but got no adoption. It got halted on April if you believe the news
• Hangouts is being replaced by Meet, at least for the enterprise. Will it be shut down for consumers? Time will tell
• Hangouts Chat is only starting its way, though I haven’t heard anything at all since its public launch
• Meet works just fine. For the enterprise. If you have a Google account
• The Google Messages app is purely for SMS. And it is crappy to say the least. It doesn’t respond as fast or as fluid as other social messaging apps, and frankly, I don’t really care about the technical reasons for it

The one thing Google has going for it is AI. in droves.

Which is probably why Google Duplex is reportedly rolling out next month, helping phone users book tables at restaurants – on their behalf.

It is also why Google is now adding to its Assistant the ability to screen spam calls:

https://www.youtube.com/watch?v=O4jOdVTkqS4

These AI features have a potential to actually succeed. They don’t really relate to RCS or even messaging, but they are about telephony.

Allo was about messaging. As reported on The Verge in the April Allo pause:

As part of that effort, Google says it’s “pausing” work on its most recent entry into the messaging space, Allo. It’s the sort of “pause” that involves transferring almost the entire team off the project and putting all its resources into another app, Android Messages.

Google won’t build the iMessage clone that Android fans have clamored for, but it seems to have cajoled the carriers into doing it for them. In order to have some kind of victory in messaging, Google first had to admit defeat.

That’s the Google RCS effort right there.

If you take the AI related features in Allo, and think of them as getting Google Assistant into Messages, the Google RCS app, then it makes sense in a way. But not enough sense.

The Google Assistant doesn’t feel like a product by now. It is a large set of features and capabilities that can be used to add smarts into phones. It is a window to the phone’s (and Google’s) AI for the consumer.

Limiting it to run for RCS only doesn’t seem like the right thing to do. Would it be enough to save RCS? Would it be enough for Google to gain back users from other messaging apps?

It is too early to say, as none of it as come to fruition in an app customers can use.

Google could have tried to do with Allo the same things it is doing with its Contact Center AI:

Provide the whole AI for communication part as an API, a set of building blocks for others to use and embed. It worked so well for them that it got many in the industry lining up to partner with it in contact centers. Launch partners for the Contact Center AI include Mitel, Genesys, Vonage, Cisco, RingCentral, Five9 and Twilio to name a few.

Would such a thing work with social messaging apps?

Apple wouldn’t touch it with a long stick for its iMessage.

Facebook wouldn’t either. So no Messenger or Whatsapp.

Telegram? I don’t see that happening.

WeChat? Chinese.

Who would they be left with? The smaller players, who might grow, but none seem to be rising above white noise level.

Which gets us back to Google itself. With Messenger/RCS/Chat.

What Google needs to do is find the sticky features that will get users to use its app. Those that can get value out of it even when the other participant isn’t using the same app. Add smarts into SMS itself, while providing a rich experience to the user when interacting with others who have that app.

The real question is why limit this to RCS and carriers? why not just offer it as the out of the box Android experience to everyone? Have it there by default. Let people download and install it on older devices and on iPhones.

Probably because Google still believes it relies on carriers for its Android success. Which is what’s keeping it back in mobile social messaging since Android came to our lives.

The post Can Google RCS Win the Messaging Game Through AI? appeared first on BlogGeek.me.

When looking at messaging in the context of communications and people, we can probably split the story into 3 distinct models:

1. Consumer centric
2. Business centric
3. Businesses to consumers (and vice versa)

I’ll quickly sift through the first two and focus on the third.

Consumer Centric

Consumer centric is easy. That’s where Apple iMessage, WhatsApp, Facebook Messenger, Telegram, WeChat and a bunch of others are competing. The approach there today is to deliver a rich messaging experience that includes text, images, video, voice and video calling, location, groups, … – the list goes on. And on. And on.

They have won the war against SMS. We still have SMS. Some mistakenly call it ubiquitous (on my phone it is used for spam and 2FA messages only). They won the war against RCS that never really started.

To give you a clue – Israel is a WhatsApp country. If you don’t have WhatsApp you don’t exist. It is true from the age of 8. I just purchased the first smartphone for my 8 year old boy. Not so he can play or call with the phone – just so he can send messages to his classmates and stay part of the social fabric of his class. It happened to my daughter when she reached that age. I am now a part of multiple WhatsApp groups: family, close friends, parents of my kids’ classes and after classes, work related, etc.

How easy would it be to move people in Israel from entrenched groups that hold history, images and videos? And to what end? How would RCS be any better in its experience?

Business Centric

Business centric is Slack. It used to be all about calling and the PBX. Slack changed the game. Everyone is talking about “team messaging” today. I used the term enterprise messaging years ago.

What Slack did was find a good balance between functionality and user experience that no other player has been able to copy properly so far, but everyone is after.

• Cisco wrote Spark from scratch, then rebranded it as WebEx Teams
• Then there’s Microsoft Teams, which gobbled up Skype for Business
• And there’s Facebook for Workplace
• Google had Google Talk, and Voice, and then Hangouts, and then Meet, and now Google Hangouts Chat
• Did I miss anyone? Maybe: Twist, Flock, Discord, Mattermost, ChatWork, Ryver, Zoho Cliq, RingCentral Video, Semaphor, Troop Messenger, Redbooth, Flowdock, and the list goes on – each with its own shtick

WhatsApp is unlikely to penetrate businesses in a meaningful way. Facebook built Workplace instead of trying to introduce Facebook or Messenger directly.

Where’s SMS in this orgy of messaging? Meaningful conversations happen in IP messaging services and not over SMS anymore. Some solutions, like VonageFlow offer a seamless experience that encompasses both messaging as we know it today and SMS, though I’d argue that capability is a business to consumer one.

For all intent and purpose, SMS is non-existent when it comes to business centric messaging.

Business to Consumer

Back to RCS. RCS was supposed to be the future of SMS when we all move to IP based packet networks. Guess what? We’re all on IP based packet networks, and RCS isn’t really here yet in any meaningful way.

In the past couple of years, RCS got a new tune by its proponents. The strategy changed from getting consumers back from social networks towards being the one ubiquitous network – the ring to rule them all. Here’s the idea: you get RCS on all smartphones worldwide. Now carriers have the ubiquity they had with SMS. And businesses would pay for such access to customer’s phones.

Not going to happen.

Why? Because Apple and Facebook have other plans for us.

Apple now has Apple Business Chat. It is built into the iPhone, making businesses discoverable and reachable over iMessage from the Safari browser, Spotlight search, Siri assistant and Apple Maps. I’ve written extensively about it when it was introduced on SearchUC: Apple Business Chat looks to polish customer messaging

WhatsApp came out with their own offering called WhatsApp Business API. Similarly to Apple Business Chat, it offers the ability for businesses to communicate with consumers. Apple does that by focusing on contact center vendors while Whatsapp partners with CPaaS vendors. The goal? Get higher exposure and not working directly with longtail developers in the initial release.

What drove me to even start writing this article? This title of a TechCrunch post: Wish, Netflix, Uber and ~100 others testing WhatsApp’s new Business API

Businesses aren’t waiting for RCS. They are trying to figure out how to communicate with their customers via WhatsApp.

They had Line, WeChat, Facebook Messenger. And they’re still aiming for WhatsApp – a messaging service that isn’t even a US-thing.

Which brings me to the main thing – business to consumer is now a social messaging realm. Carriers have lost that domain as well.

1 Billion Defines the Moat

Remember ubiquity? Here’s what it takes to be interesting:

1 Billion Monthly Active Users

Who has that number today?

Facebook (WhatsApp + Messenger), Apple Business Chat and WeChat. WhatsApp being the biggest one are redefining this market. You hear a lot about how customers still phone businesses and chat isn’t catching up with contact centers. That might be true, but only partially.

Today’s chat solutions usually require being on the company’s website. SMS hasn’t proven itself in a large scale for anything other than notifications to customers on orders and transactions. Whatsapp can change that – and to that extent, any of the other 1B+ MAU social messaging apps.

RCS? With what billion users exactly?

With the large social networks, a 100 million monthly active users seem like a rounding error.

Focus is on Customer Care – Not Marketing

Another interesting aspect (and difference) is that social networks are keeping user identity and access close to their chest. While WhatsApp is using phone numbers for identity, piggybacking on carriers in a way, they are not allowing anyone access to a user without the user’s permission. This means:

1. Businesses can’t “spam” users by sending them unsolicited messages just because they know their phone number or user name
2. A user must first approach the business. Inbound use cases are the focus here, which lends itself nicely to support and purchasing activities
3. Outbound marketing campaigns, ads, promotions – these aren’t something that are encouraged at the moment

What these networks are trying to do is to get businesses and consumers off their SMS communications and shift it to their network. To do so, they plan on offering a superior experience. They are doing that not only by adding richness over the limited 160 character experience of SMS, but they are also making sure this will be a useful service to their user base and won’t be considered spammy.

Will there be other avenues opened to businesses on social networks to interact with users through marketing campaigns and outbound messaging? Sure. But it isn’t the first priority. The market needs to be created first.

Where Can We Go Next?

We are headed towards an omnichannel interaction model.

To me that means that a business will meet a customer wherever it is comfortable for the customer in the context of that specific interaction.

A customer may prefer a phone call at one interaction, but a chat over WhatsApp on another.

The challenge here is that different customers may prefer different social networks. Or aren’t even approachable on some of the social networks. This isn’t going to change any time soon either. The number of social networks is still growing, and while we have a few huge players, others are important to specific populations.

Businesses will need to rely on multiple such channels if they want to reach out to a larger target audience of potential customers.

Back to RCS

It is coming. In some carriers. On some devices. In some form.

Is it going to take back ownership of the interactions from social networks? No.

What it can be, is just another channel. Right next to the rest. It will only become important if it can make that 1 billion monthly active users mark.

Oh, and it will need to succumb to the rules of engagement laid out by social networks today, around business-to-user permissions.

The post Social Messaging != Carrier Messaging (the stories of Whatsapp Business API & Apple Business Chat) appeared first on BlogGeek.me.