Not a cookbook, but should be useful to plan yor multipoint service offering.

[If you are new around here, then you should know I've been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]

WebRTC is usually coined as a peer-to-peer solution – something that allows browsers to skip the server altogether. There’s nothing new in that approach, and I am not talking about Skype, but rather about pure VoIP as we know it.

The “peer-to-peerness” of WebRTC is compared to that of that of a browser, where all communication flows through a server. With VoIP, from the very beginning, there was the option of sending media directly between the endpoints.

This is also why there’s nothing new in how you deal with multipoint video calling with WebRTC than the ways this was done with other VoIP solutions in the past – there’s just the need to understand it by those who are now venturing into the realm of multipoint with little knowledge of video conferencing.

I am starting a short post series to deal exactly with this. There will be little reference to WebRTC per-se on the subject and more about video flows. I leave it to you to do the relevant modifications in actual implementations.

What am I going to talk about?

1. How to broadcast video streams?
2. How to implement small group video conferences?
3. How to implement large scale video conferences?

In each, I will try to provide the main reasoning behind the suggested architecture, its advantages and disadvantages.

The analysis is going to revolve around these aspects:

Client side bandwidth

How much bandwidth are we going to need on the client side? This is going to be split between incoming and outgoing bandwidth, as most networks today are not symmetric in nature.

You can add to that data cap when mobile devices are of interest.

Server side bandwidth

How much bandwidth are we going to need on the server side? This is going to affect network needs, scaling capabilities and also the cost of bandwidth we will need to pay for our data center.

Client side processing

Besides bandwidth, there’s a need to understand the amount of work we expect the web browser to deal with, if and how it is affected from specific WebRTC implementations and the type of user experience we can strive to get with it.

Server side processing

On the server, there’s work to be done besides passing data sent from the clients in the session in some of these use cases. If that happens, there’s a need to understand the cost associated with it.

-

See you all next week, when we cover the broadcasting use case.

Tags: analysis, architecture, bandwidth, broadcast, browser, conference, device, media, mobile, multipoint, network, resources, video conferencing, VoIP, WebRTC