Categories
Uncategorized

Video Conferencing System Architecture: P2P vs MCU vs SFU ?

Even though WebRTC is a protocol developed to do one job, to establish low-ping high-security multimedia connections, one of its best features is flexibility. Even if you are up for a pretty articulated task of creating a video conferencing app, the options are open.

You can go full p2p, deploy a media server backend (there is quite a variety of those), or combine these approaches to your liking. You can pick desired features and find a handful of ways to implement them. Finally, you can freely choose between a solid backend or a scalable media server grid created by one of the many patterns. 

With all of these freedoms at your disposal, picking the best option might – and will – be tricky. Let us clear the fight P2P vs MCU vs SFU a bit for you.

What is P2P?

Let’s imagine it’s Christmas. Or any other mass gift giving opportunity of your choice. You’ve got quite a bunch of friends scattered across town, but everyone is too busy to throw a gift exchange party. So, you and your besties agree everyone will get their presents once they drop by each other.

When you want to exchange something with your peers, no matter whether it’s a Christmas gift or a live video feed, the obvious way is definitely peer to peer. Each of your friends comes to knock on your door and get their box, and then you visit everyone in return. Plain and simple.

For a WebRTC chat, that means all call parties are directly connected to each other, with the host only serving as a meeting point (or an address book, in our Christmas example).

This pattern works great, while:

  • your group is rather small
  • everyone is physically able to reach each other

Every gift from our example requires some time and effort to be dealt with: at least, you have to drive to a location (or to wait for someone to come to you), open the door, give the box and say merry Christmas.

  • If there are 4 members in a group, each of you needs time to handle 6 gifts – 3 to give, 3 to take.
  • When there are 5 of you, 8 gifts per person are to be taken care of.
  • Once your group increases to 6 members, your  Christmas to-do list now features 10 gifts.

At one point, there will be too many balls in the air: the amount of incoming and outgoing gifts will be too massive to handle comfortably.

Same for video calls: every single P2P stream should be encoded and sent or decoded and displayed in real time  – each operation requiring a fraction of your system’s performance, network bandwidth, and battery capacity. This fraction might be quite sensible for higher-quality video: if a 2-on-2 or even a 5-on-5 conference will work decently on any relatively up-to-date device, 10-on-10 peer to peer FullHD  call would eat up give or take 50 Mbps in bandwidth and put quite of a load even on a mid-to-high tier CPU.

p2p architecture
Peer-to-peer architecture 

Now regarding the physical ability to reach. Imagine one of your friends has recently moved to an upscale gated community. They are free to drive in and out – so, they’ll get to your front door for their presents, but your chances to reach their home for your gift are scarce.

WebRTC-wise, we are talking about corporate networks with NATs and\or VPNs. You can reach most hosts from inside the network, while being as good as unreachable from outside. In any case, your peers might be unable to see you, or vice versa, or both.

And finally – if all of you decide to pile up the gifts for a fancy Instagram photo, everyone will have to create both the box heap and the picture themselves: the presents are at the recipients’ homes.

WebRTC: peer-to-peer means no server side recording (or any other once-per-call features). At all.

Peer-to-Peer applications examples

Google Meet and secure mobile video calling apps without any server-side features like video recording.

That’s where media servers come to save the day.

WebRTC media servers: MCU and SFU

Back to the imaginary Christmas. Your bunch of friends is huge, so you figure out you’ll spend the whole holiday season waiting for someone or driving somewhere. To save your time, you pay your local coffee shop to serve as a gift distribution node. 

From now on, everyone in your group needs to reach a single location to leave or get gifts – the coffee shop.

That’s how the WebRTC media servers work. They accept calling parties’ multimedia streams and deliver them to everyone in a conference room. 

A while ago, WebRTC media servers used to come in two flavors: SFU (selective forwarding unit) and MCU (Multipoint conferencing \\ Multipoint control unit). As of today, most commercial and open-source solutions offer both SFU and MCU features, so both terms now describe features and usage patterns instead of product types.

What are those?

SFU / Selective Forwarding Unit

What SFU is?

SFU sends separate video streams of everyone to everyone.

The bartender at the coffee shop keeps track of all the gifts arriving at the place, and calls their recipients if there’s something new waiting for them. Once you receive such a call, you drop by the shop, have a ‘chino, get your box and head back home.

The bad news is: the bartender gives you calls about one gift at a time. So, if there are three new presents, you’ll have to hit the road three times in a row. If there are twenty… you probably got the point. Alternatively, you can visit the place at a certain periodicity, checking for new arrivals yourself.

Also, as your gift marathon flourishes, coffee quality degrades: the more people join in, the more time and effort the bartender dedicates to distributing gifts instead of caffeine. Remember: one gift – one call from the shop.

Media Server working as a Selective Forwarding Unit allows call participants to send their video streams once only – to the server itself. The backend will clone this stream and deliver it to every party involved in a call.

With SFU, every client consumes almost two times less bandwidth, CPU capacity, and battery power than it would in a peer-to-peer call:

  • for a 4-user call: 1 outgoing stream, 3 incoming (instead of 3 in, 3 out for p2p)
  • for a 5-user call: 1 outgoing stream, 4 incoming (would be 4 and 4 in p2p)
  • for a 10-user call: 1 out, 9 in (9 in, 9 out – p2p)
sfu architecture
SFU architecture

The drawback kicks in with users per call ratio approaching 20. “Selective” in SFU stands for the fact that this unit doesn’t forward media in bulk – it delivers media on a per-request basis. And, since WebRTC is always a p2p protocol, even if there is a server involved, every concurrent stream is a separate connection. So, for a 10-user video meetup a server has to maintain 10 ingest (“video receiving”) and 90 outgoing connections, each requiring computing power, bandwidth and, ultimately, money. But…

SFU Scalability

Once the coffee shop owner grows angry with the gift exchange intensity, you can take the next step, and pay some more shops in the neighborhood to join in. 

Depending on a particular shop’s load, some of the gift givers or receivers can be routed to another, less crowded one. The grid might grow almost infinitely, since every shop can either forward a package to their addressee, or to an alternative pick up location.

Forwarding rules are perfectly flexible. Like, Johnson’s coffee keeps gifts for your friends with first names starting A – F, and Smartducks is dedicated to parcels for downtown residents, while Randy’s Cappuccino will forward your merry Christmas to anyone who sent their own first gift since last Thursday.

One stream – one connection approach provided by SFU pattern has a feature to beat almost all of its cons. The feature is scalability software development.

Just like you forward a user’s stream to another participant, you can forward it to another server. With this in mind, the back end WebRTC architecture can be adjusted to grow and shrink depending on the number of users, conferences and traffic intensity.

E.g., if too many clients request a particular stream from one host, you can spawn a new one, clone the stream there and distribute it from a new unoccupied location.

Or, in case if you expect rush entrance on a massive conference (e.g., some 20-30 streaming users, and hundreds of view-only subscribers), you can assign two separate media server groups, one to handle incoming streams and the other to deliver it to subscribers. In this case, any load spikes on the viewing side will have zero effect on video ingest, and vice versa.

SFU applications examples

Skype and almost every other mobile messenger with a video conference and video call recording capabilities employs SFU pattern on the backend.

Receiving other users’ video as separate streams provides capabilities for adaptive UX, allows per-stream quality adjustment and improves overall call stability in a volatile environment of a cellular network.

MCU / Multipoint Conferencing Unit

What MCU is?

MCU unites all streams into 1 and sends just 1 stream to each participant.

Giving gifts is making friends, right? Now almost everyone in town is your buddy and participates in this gift exchange. The coffee shop hosting the exchange comes up with a great idea: why don’t we put all the presents for a particular person in a huge crate with their name on it. Moreover, some holiday magic is now involved: once there are new gifts for anyone, they appear in their respective boxes on their own.

Still, making Christmas magic seems to be harder work than making coffee: they might even need to hire more people to cast spells on the gift crates. And even with extra wizards on duty, there is zero chance you can rearrange the crates’ content order for your significant other to see your gift first – everyone gets the same pattern.

MCU architecture

Well, some of the MCU-related features do really ask for puns over an acronym shared with Marvel Cinematic Universe. Something marvelous is definitely involved. Media server in an MCU role has to keep only 20 connections for a 10 user conference, instead of 100 links of an SFU – one ingest, one output per user. How come? It merges all the videos and audios a user needs to receive into a single stream, and delivers it to a particular client. That’s how Zoom’s conferences are made: with MCU, even a lower-tier computer is capable of handling a 100-user live call.

Magic obviously comes at a price, though. Compositing multiple video and audio streams in real time is *much* more of a performance guzzler than any forwarding pattern. Even more, if you have to somehow exclude one’s own voice and picture from the merged grid they receive – for each of the users. 

Another drawback, though mitigable, is that a composited grid is the same for everyone who receives the video – no matter what is their screen resolution, or aspect ratio, or whatever. If there is a need to have different layouts for mobile and desktop devices – you’ll have to composite the video twice.

MCU scalability

In WebRTC video call, compared to SFU, MCU pattern has considerably less scaling potential: video compositing with sub-second delays does not allow on-the-fly load redistribution for a particular conference. Still, one can autospawn additional server instances for new calls in a virtualized environment, or, for even better efficiency, assign an additional SFU unit to redistribute composited video.

MCU applications examples

Zoom and a majority of its alternatives for massive video conferencing run off MCU-like backends. Otherwise, WebRTC video calls for 25+ participants would only be available for high-end devices.

TL;DR: what and when do I use?

Quick comparison: P2P, SFU, MCU or MCU + SFU

~1-4 users per call – P2P

Pros:

  • lowest idling costs
  • easiest scaling
  • shortest TTM (time to market)
  • potentially the most secure

Cons:

  • for 5+ user calls – quality might deteriorate on weaker devices
  • highest bandwidth usage (may be critical for mobile users)
  • no server side recording, video analytics or other advanced features

Applications:

  • private \ group calls
  • video assistance and sales

5-20 users per call – SFU

Pros:

  • easily scalable with simultaneous call number growth
  • retains UX flexibility while providing server side features
  • can have node redundancy by design: thus, most rush-proof

Cons:

  • pretty traffic- and performance intensive on the client side
  • might still require a compositing MCU-like service to record calls 

Use cases:

  • E-learning: workshops and virtual classrooms
  • Corporate communications: meeting and pressrooms

20+ users per call – MCU \ MCU + SFU

Pros:

  • least load on client side devices
  • capable of serving the biggest audiences
  • easily recordable (server side / client side)

Cons:

  • biggest idling and running costs
  • one call capacity is limited to performance of a particular server
  • least customizable layout

Use cases:

  • Large event streaming
  • Social networking
  • Online media 

Conclusion

P2P, MCU, and SFU are parts of WebRTC. You can read more about WebRTC on our blog:

How to minimize latency to less than 1 sec for mass streams?
WebRTC in Android.
WebRTC security in plain language for business people.

Got another question not covered here? Feel free to contact us using this form, and our professionals will be happy to help you with everything.

Categories
Uncategorized

How to Protect Your Online Business from Internet Shutdown? [2021]

internet-shut-down-2021

On October 4th the internet went down. Facebook, Instagram, and WhatsApp were unresponsive for several hours. It, in turn, caused abnormalities with other services. People called it Monday Blackout.

Building on ready-made PaaS (Platform-as-a-Service, third-party tools, and platforms you can combine into your own product) is awesome. It may reduce your time-to-market by half and is probably saving quite a buck while you rush to a quick release. But sometimes it hurts – just like it did on Monday when half the web went out. 

Let’s find out what’s happened, and throw in a couple of battle-proven tips on how to evade downtime even when things come at you that hard. 

What has happened?

In short, the DNS service (partially) failed. For a metaphor, let’s imagine half of all the world’s streets went missing from all the maps and nav apps. At the very moment when you’re out on a leave. On your way to the airport. Running out of time. In a country where nobody speaks your language. Ouch.

To give this ouch a more techy scent, let’s drop in some detail. The root cause of the whole thing was that a considerable part of domain names failed to resolve. This means, the internet backbone gave zero response when your browser asked, how to reach, say, Facebook. And all the third-fourth-twentieth-level subdomains used for third-party apps, all the authentication services, all the ad trackers, and zillions more services of various application scope.

How to minimize the risks of going down for your online project?

1. Don’t use third-party solutions to provide critical features

Monday Blackout is the reason to never use third-party solutions to provide critical features and to be so skeptical about using them as a single source of any feature. Using one global authentication provider like Google IS convenient, but any downtime on their side would totally ruin the user experience for your customers. And even if it is up and running – there is always a chance politics kick in: cases, when Middle Eastern or Asian governments sanction global tech corporations, are, unfortunately, not unheard of.

2. Have native iOS and Android apps for a reliable experience

We suggest building native mobile apps for both platforms, instead of relying solely on web apps. While web applications are naturally dependent on the DNS (you have to type in the URL to get where you want to), mobile software is already on your customer’s phone. It implies that all the fallback features can be at their disposal: e.g., in case of a DNS failure, it can store a number of backup domain names or even straight away IP addresses to reach out for, retaining a service level even when the others fail.

3. Use peer-to-peer (p2p) communication

The more the merrier, right? DNS failure was the root cause of the internet shutting down, but the effect was much more vast. When some of the social networks went unreachable, users rushed to their competitors — who, in turn, were not all ready to deal with that spike.

That’s why we’re so much into WebRTC’s p2p capabilities. With live multimedia being pretty traffic and resource-intensive, peer-to-peer communication is a budget saver at all times, and a business saver in cases like that. Even if a secondary service running somewhere in the cloud becomes unreachable for a while, the key feature will be available, as the spike load will be redistributed between the devices that are directly involved in a particular call.

4. Set up auto-scaling to handle spike load

Another critical thing is scalability. Design your platforms to scale up and down – by different strategies. Either automatically or manually, make your high-load solutions to be architectured to respond to traffic spikes without service degradation. For example, we architect, develop and test them to match the target criteria and even outdo them considerably. 

5. Keep your code portable

And now – back to the PaaS, as it was what made the Monday blackout a blackout. When the users rushed to competing social networks, they sure reached for different domains. But under the hood, many of those were attached to the same cloud computing platforms, known for their quality and massive resource pool. And those platforms started to crack under load, making the internet go down.

That is why we recommend delivering software in code – it’s not only ownership rights. With code at your disposal, you are independent of some premade set up in a cloud. If your cloud provider goes down, what you do is simply deploy the whole thing on a different availability zone, or a competing provider, or even on-premise — whichever serves you better. 

So, here’s the summary of why the internet went down.

What’s happened? A chain reaction. 

  • DNS failure made a number of massively used resources unreachable
  • Their audience rushed to alternative destinations
  • Many of those destinations run off the same cloud platforms the traffic snowballed to
  • Many side services also failed, as they used third-party solutions provided by big tech companies affected by the DNS failure

How we mitigate these risks:

  • Third-party independent critical features
  • Mobile apps and PWAs for less DNS dependency
  • P2p to avoid bottlenecks
  • Auto-scaling to handle spike load
  • Code availability for quick redeployment

Blackouts like this one are, definitely, a rare occurrence. But when they arrive, you are either struggling to minimize your losses, or welcoming the discontent customers of your less reliable competitors. Need a team capable of keeping your business ready for a chance like that? Request a quote.  

Categories
Uncategorized

Why cut features and launch the product early or what is MVP?

Many of our customers come up to us asking if we could make an MVP for them. Yep. Even big corporate clients want what used to be a startup fad — and what is now an industry standard.

But what is an MVP? The abbreviation, standing for Minimal Viable Product, is used to imply you hit the market before you’re done with all the features. Why is it that popular then? Is it a fancy way of saying “whatever works is fine”, a bargain solution for low-budget projects… or a misused football term after all?

What is an MVP?

Speaking of minimal viable products, let’s get started with setting on the viability criteria. For a software piece, viability definition may lie within the range of “not crashing on launch” to “being able to compete against the leaders”. 

Within the Lean Production Methodology, where the MVP concept originated, V stands for “bringing value to the user”. That’s why they often read MVP as Minimal Valuable Product.

The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction, and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers

Frank Robinson, the author of the term

So, MVP is basically a killer feature, and the simplest buttons and handles one might need to make use of it. You cut all the bells and whistles off your concept, strip it of all the fancy design extras, and anything that is not crucial – as simple as that.

Why would you go for an MVP?

Here’s an example. Imagine you’re a fan of a particular sport — let’s say, boxing. And you want to become the new Muhammad Ali. So, you start training with all the passion and dedication and whatever else you may find in movies about Rocky Balboa. The question is: when will you take on your first fight?

Option one. You train for ages until you feel like you are two hundred percent fit and ready.

Option two. You get some pretty basic training and jump into the ring as soon the coach is sure you’ll make it to the last round without kicking the bucket. As soon as you are viable for the ring. 

Option one is tempting: if things go well, you’ll plow through the underdogs and face the big guys without losing your breath. Option two appears hurtful: if things go well, you will win. But should you win or should you lose, you won’t leave without a bruise.

However, there is a but. “If things go well” is the critical part in both scenarios. Once you enter the ring, reality comes at you fast. What if you figure out you missed something in your training? What if those in the ring are still trained better? What if the blows you receive hurt too much (shocker!)? Or – why not – what if what you deemed boxing and your passion was actually wrestling, so all your great punching skills are totally inapplicable? You’d better know that in three months than in ten years after you put your gloves on for the first time.

So, MVP is a reality check done the quickest and the cheapest way. It’s not actually cutting functions, but ensuring they are needed before you spend time and money on those.

Reality check and real checks

The MVP-centric approach grows popular as marketing skills become commonplace for entrepreneurs, no matter which is their sphere. TTM is the reason for that. TTM, or Time-to-market, is one of the key metrics for a new product. Time is always money, but when the market launch countdown is ticking, every minute costs you cash in many ways.

  • You want to pay for what others will pay for.

With all the research and insight behind it, the great idea your new product is based on is still a hypothesis until proven. It’s not like you already know the market craves your product, but you assume it is. There are no other means to make this hypothesis a fact but to check it on real customers. The earlier you hit the market, the quicker the feedback is on what would make your product more desirable.

  • Your product might be lucrative, but before it is in the market, it earns nothing.

With all the variety of monetization models available today, your product may be able to generate revenue long before it’s done and ready. Think of World of Tanks, the videogame that earned billions while being still in beta, or of all the mobile apps that are paying back the investments made. Ad-supported or subscription-based, bought in a one-time purchase or enhanced via microtransactions, your product might add some green lines to your bank account report as soon as it can deliver any value to your clients.

And yes, while the scope is small yet, you are safer in your experimenting with monetization models per se. No matter what, your missed revenue numbers will be the least frustrating.

Think of almost every successful software product. Yes, even the hardcore enterprise one would work. They never start as a one-size-fits-all solution, but as a demanded yet simple tool designed to perform a specific task.

  • Take a turn before you’ll have to brake for that 

Developing a complicated product before learning you have to adjust it to the market is not only about losing money on features discovered to be undemanded. The more had been done before a pivot, the more has to be done to perform one. You only have to remove seats and add panels to make a cargo van from a microbus, but should you try turning a Corvette into one, you’ll end up building it from scratch.

OK, are there any real-life MVP cases?

Telegram grew popular before it got the channels, stickers, secure calls, and bots. In the beginning, all it had was a boringly simple messenger with awesome encryption. It could do less than competitors, but it could keep your communication secure. MVP? Betcha.

SAP, the first ERP software coming into one’s mind, started from a pretty simple accounting system, which didn’t sport even 10% of what it has now. The term MVP was not even coined in by that time, but in fact, that was it – a basic solution, offering a new approach on quite a limited scope.

Zappos, the mid-2000 iconic apparel e-store began as a guy buying footwear on your demand from regular stores and sending it by mail. As simple as that. 

Moreover, an MVP may prove an idea before you spend zillions on can even become a business even before you expect them to do it!

Dota and Counter-Strike, as lucrative as they are now, began as community mods for popular games (Warcraft III and Half-Life, respectively). No ginormous teams of developers, designers, and community managers, no weekly content updates or events: they offered the very basic setup needed for a new gameplay pattern. A Minimally Playable Product.

How to scope an MVP?

There is a mnemonic rule designed by Eric Rice, the author of the famous “The Lean Startup”: you take your first idea for an MVP, then cut that in half, and cut it in half again – and there you got what actually is an MVP.

For those hesitant on cutting, here’s another – not that brutal – rule of thumb we nurture here in Fora Soft.
You have to ask yourself three questions.

  • What is your favorite part of your big idea?
  • What do you need to use it?
  • If you had only 30% of your budget, what would you make first?

You may even put your imaginary budget threshold lower than that, until what fits it retains the uniqueness of your product and the very basic usability. Once you understand that you can’t push it down anymore, you got the MVP.

If it is still a complicated task like it may be, as you definitely love your idea, you can start with MVP-izing actual projects. Try to think about what makes Instagram, Google Docs, or your favorite game what they are. Take a shot on imagining they didn’t have all the features they boast now. Where is the border between “I’d go without this feature” and “Oh, it won’t be useless anymore”. More advice on how to define an MVP scope in short time.

Quick. Cheap. Dirty?

Once you develop a vision of your product’s MVP, you start revving your engine. Time is money, so you want your Minimum Viable Precious right away.

Setting your step towards the MVP on your own is where you might run into a dilemma. On one hand, coding or testing in a rush never results in good code. On the other hand, the MVP stage is somewhat forgiving to the code quality — if it works, it works.

It’s up to you to find the balance between those, but the golden rule is: no matter how much duct tape is there under the hood, the user experience for the killer feature should be streamlined and lovely.  Whatever buggy and irrelevant to the key functions should be demolished mercilessly. Whatever is crucial and buggy should be a priority.

And what if they copy it?

Well, everyone remembers the copycat cases – it happened to the MSQRD app, who’d had its minute in the limelight before every competitor got their own masks. Or Snapchat with its fading posts, which turned to be a fading fad (pun intended).  

That’s the concern faced by everyone taking (or sugging taking) the MVP path. If there is a killer feature, isn’t delivering a quick-and-basic product the simplest way to unwantedly hand it to bigger competitors, who’d wrap it up in glossy paper and grab your market in no time?

The short answer is yes. It is. If your killer feature is that great, all the big companies gonna copy it. Or release their own renditions already being in development. But the first one to release is the first one to win the audience — and is able either to retain it, entering the top league (like Zoom or Miro, the COVID-era superstars whose leadership is yet to be shattered). 

And even if the blue chips roll out their own, more refined solutions… Remember what happened to MSQRD? Facebook bought it. For a much bigger sum than they invested in development.

SO, WHY SHOULD I CUT FEATURES AND LAUNCH MY PRODUCT EARLY?

  • To check your idea and be able to refine it before there’s too much money spent;
  • To make the audience like your product before it is even totally complete;
  • To start earning before you’re done spending;
  • To make your product become a synonym to its killer feature. 

Can Fora Soft help you with an MVP?

Most certainly! For example, we started with Vodeo as an MVP. Read what the project owner, Jesse Janson, had to say about it.

On the MVP stage, it’s not just skill but experience that matters. A developer with a massive background in a certain area (media processing, streaming, and low-latency solutions in our case) is a shortcut to an MVP. Our developers, absolute pros cut the time-to-market, as they already know solutions for typical time-guzzling problems. Please, feel free to contact us via the Contact form, and we will get back to you right away!