News from Industry

Who do you go to with your WebRTC needs?

That moment you realized you selected the wrong vendor

There are now over 20 vendors out there offering WebRTC APIs in the cloud.

20.

How the hell do you decide which one to pick for your service?

This question was rather “simple” to answer, but it is getting harder.

Two months ago, Facebook decided to shutdown Parse. This is something that should not be taken lightly.

In 2013, Facebook acquired Parse. Parse was a MBaaS(mobile backend as a service platform). If you want to build a mobile app, you’ll be needing some backend in high probability – a place to store account information, maybe sync data between users, etc. MBaaS does exactly that, and in this domain, Parse was one of the bigger platforms. They had around 60,000 applications on their platform at the time of acquisition – not something to take lightly.

Facebook didn’t acquire Parse for its great technology but rather for its developer ecosystem – for its popularity. In the two years since, Facebook invested more in the platform – just so it can close it.

In the context of communication API platforms with WebRTC capabilities, what we’ve seen so far are two kinds of acquisitions:

 

1. Acquiring a technology – Snapchat acquiring AddLive, Requestec getting acquired by Blackboard are such examples. So is Crocodile RCS acqisition by Acision and then Acision wrapped into Xuar
2. Acquiring a developer ecosystem – TokBox’s acquisition by Telefonica and the recent Cisco acquisition of Tropo

Will Cisco decide in a year or two to shutter down Tropo if it doesn’t bring the traction it wants or if it serves its purpose of getting enterprises to adopt Cisco Spark?

Would Telefonica stop investing in TokBox? Highly unlikely after 3 years, but who knows? I wouldn’t have bet on Facebook shedding Parse.

The thing about Parse is that Facebook didn’t even spun it off again – or sold it. It just closed the service. More akin to how Snapchat treated its own acquisition of AddLive.

Kin Lane explains nicely the false expectations people had from Facebook and Parse:

There is no basis for believing a platform or API will ALWAYS be there, no matter what you are promised. Companies go out of business, get acquired, and in this fast paced tech climate, companies are always looking to deliver the latest product, and features. Everything in the space points to disruption, change, and evolution, where the hell did we get the idea these services shouldn’t go away?

What can we deduce?

1. Platforms with large ecosystems aren’t impervious to being taken off market. TokBox may get shuttered. Twilio might get acquired
2. In the build vs buy decision of WebRTC, using a platform doesn’t mean write once and forget. You may need to update your code, switch vendors, etc. – be ready for it

–

As I start working on another update for my Choosing a WebRTC API Platform report, I will take the time to research the reasons for vendors selecting the less popular API platforms – what makes them take that plunge. If you are such a vendor – contact me.

Until this new update gets released (April-May timeframe), there’s a $700 USD discount on the report (which includes a 1-year update period).

The post Developer Ecosystem Acquisitions Makes Build vs Buy Decisions Harder appeared first on BlogGeek.me.

This week we had some fun new updates to mod_avmd and began the process of moving libvpx into tree. This is a big change and should be carefully noted. There were too many issues associated with maintaining and updating it so the developers decided to instead link to a static version in tree.

Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! And, head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-8852 [mod_avmd] Now we use predefined table length instead of hardcoded computation in stop condition of for loop
• FS-8854 [mod_avmd] Now all members of buffer are initialized in INIT_CIRC_BUFFER macro
• FS-8867 [mod_vpx][core] Build using in tree libvpx, vpx no longer optional and does not use system libvpx due to issues with having to update it, frequently conflicting with system libraries, now we link to the static in tree version instead. Also, mod_vpx is now a core module instead of a loadable module, so mod_vpx.so will no longer be built
• FS-8876 [core] Add CPU affinity to each Video thread in a round robin fashion.
• FS-8878 [mod_amr] Make AMR NB transcode in octet-align mode (when compiled with HAVE_AMR)

The following bugs were squashed:

• FS-8856 [mod_callcenter] Updating a member fails because the agent_dispatch_thread removed the member just before it tried to update it.
• FS-8842 [verto] Fixed an issue where calls created using the originate command lose audio when left on hold for 45 seconds
• FS-8877 [verto] Fixed an issue caused by Chrome Canary removing some audio mandatory constraints that break Verto
• FS-8862 [core] Auto adjust on passthru
• FS-8871 [configuration] Fixed encoding “&” and “<” symbols in vanilla configuration
• FS-8879 [mod_sofia] Fixed SIP UPDATE and attended transfer for ipv6
• FS-8864 [core][mod_av] Improve video file playback

Blake Priddy joins the ClueCon Weekly team to talk experiences deploying FreeSWITCH in rural public schools and some of the technical and political challenges he faced.

The scripts for integrating FreeSWITCH with Sevana AQuA software are now available at github: https://github.com/voxserv/fsqa

More details on what they are doing are available in this older post: https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/

Filed under: Networking Tagged: freeswitch, monitoring, pbx, sip, testing, voip

Digital Voice Teleconferencing overt the ARPAnet 1978

This week we had the addition of CPU affinity to each video thread in a round robin fashion and a logo image and parameters were added to mod_local_stream.

Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! And, head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-8876 [core] Add CPU affinity to each video thread in a round robin fashion.
• FS-8903 [mod_local_stream] Add a logo image and some parameters to control its behavior

The following bugs were squashed:

• FS-8884 [build] Add –disable-libyuv and –disable-libvpx configure arguments to disable building these libraries on FreeBSD and smartos
• FS-8891 [RTP] Fix for T38 fax failing between 2 freeswitch boxes with high cpu usage
• FS-8354 [mod_conference] Fix for G722 audio issues
• FS-8811 [core] Fixed an intermittent crash
• FS-8851 [core] Fix for codec for recording negotiated before call answered
• FS-8904 [core] Fix memory leak in img_write_text
• FS-8905 [core] Fixed for a heap buffer overflow detected by ASAN in the img patch/img overlay and it may show up as a rare segfault when using video with banners
• FS-8864 [core] Set video ready on first push to avoid catch 22 on some video files

It’s the money stupid.

We all love to hate the model of an MCU (besides those who sell MCUs that is).

There are in general 3 main models of deploying a multiparty video conference:

1. Mesh – where each participant sends his media to all other participants
2. MCU – where a participant is “speaking” to a central entity who mixes all inputs and sends out a single stream towards each participant
3. SFU – where a participant sends his media to a central entity, who routes all incoming media as he sees fit to participants – each one of them receiving usually more than a single stream

I’ve taken the time to use testRTC to show the differences on the network between the 3 multiparty video alternatives on the network.

To sum things up:

• Mesh fails miserably relatively fast. Anything beyond 3 isn’t usable anywhre in a commercial product if you ask me
• MCU seems the best approach when it comes to load on the network
• SFU is asymmetric in nature – similar to how ADSL is (though this can be reduced, just not in Jitsi in the specific scenario I tried)

This being the case, how can I even say that SFU is the winning model for WebRTC?

It all comes down to the cost of operating the service.

Here’s what an MCU does in front of each participant:

How media gets processed by an MFU

Here’s what an SFU does in front of each participant:

How media gets processed by an SFU

To make things easy for you, I’ve marked with colors varying from green to red the amount of effort it puts on a CPU to deal with it.

The most taxing activity in an MCU is the encoding and decoding of the video. With the current and upcoming changes in video and displays, this isn’t going to lessen any time soon:

• Google just switched to VP9, which takes up more CPU
• 4K displays and cameras are becoming a reality. 8K is being discussed already. This means 4 times the resolutions of full HD

If anything – things are going to get worse here before they get any better.

It is no surprise then that MCUs scale on single machines in the 10’s of ports or low 100’s at best; while SFUs scale on single machines in the 1,000’s of ports or low 10,000’s.

Which brings us to two very important aspects of this:

1. Price per port, where an SFU will ALWAYS be lower than MCU – by several factors
2. Deployment complexity

The first reason is usually answered by people that if you want quality – you need to pay for it. Which is always true. Until you start reminding yourself that video calling today is priced at zero for the most part.

The second reason isn’t as easy to ignore. If you aim for cloud based services needing to serve multiple customers, your aim is to go to 10,000 or more parallel sessions. Sometimes millions or more. Here would be a good time to remind you that WhatsApp crossed the billion monthly active users and most messaging services become interesting when they cross 100 million monthly active users.

With such numbers, placing 100 times more machines to support an MCU architecture instead of an SFU one is… prohibitive. There are more costs that needs to be factored in, such as power consumption, rack space and higher administration costs.

The end result?

An SFU model is by far the most popular deployment today for WebRTC services.

Does it fit all use cases? No

Will it fit your use case? Maybe

Do customers care? No

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post WebRTC Multiparty Video Alternatives, and Why SFU is the Winning Model appeared first on BlogGeek.me.

  Dear Slack, There has been quite some buzz this week about you and WebRTC. WebRTC… kind of. Because actually you only do stuff in Chrome and your native apps: I’ve been there. Launching stuff only for Chrome. That was is late 2012. In 2016, you need to have a very good excuse to launch something […]

The post Dear Slack: why is your WebRTC so weak? appeared first on webrtcHacks.

Kamailio SIP Server v4.3.5 stable is out – a minor release including fixes in code and documentation since v4.3.4. The configuration file and database schema compatibility is preserved.Kamailio (former OpenSER) v4.3.5 is based on the latest version of GIT branch 4.3, therefore those running previous 4.3.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.3.x.Resources for Kamailio version 4.3.5Source tarballs are available at:

• http://www.kamailio.org/pub/kamailio/4.3.5/src/

Detailed changelog:

• http://www.kamailio.org/pub/kamailio/4.3.5/ChangeLog

Download via GIT: # git clone git://git.kamailio.org/kamailio kamailio
# cd kamailio
# git checkout -b 4.3 origin/4.3Binaries and packages will be uploaded at:

• http://www.kamailio.org/pub/kamailio/4.3.5/

Modules’ documentation:

• http://www.kamailio.org/docs/modules/4.3.x/

What is new in 4.3.x release series is summarized in the announcement of v4.3.0:

• http://www.kamailio.org/w/kamailio-v4-3-0-release-notes/

Thanks for flying Kamailio and looking forward to meeting many of you at Kamailio World Conference 2016!

It is a waste of time.

I’ve heard it more than one.  Security threats in WebRTC make it a bad alternative. You have MITM (man in the middle) attacks on it. It leaks IP addresses. You can screen share without the user’s knowledge. The list goes on.

It isn’t the first time I write about WebRTC security and it still pisses me off when I see such answers on Quora:

The WebRTC plugin (which means Web Real-Time Communication) allows to conduct audio and video teleconferencing just in a browser without any additional software installed. However, it reveals the true IP address. How to disable WebRTC in various browsers.

A few things about that one:

1. WebRTC isn’t a plugin…
2. Why would you want to disable it?

If you trust Skype or any other VoIP or messaging app more, then you are in for a big surprise.

I read the above Quora answer on the same day I read Troy Hunt’s piece on controlling a Nissan remotely – one that… well… isn’t YOUR Nissan.

The things Nissan got wrong here includes:

• Having cars get sequential serial numbers, so they are easy to guess
• Having an undocumented backend API that controls cars remotely – with no authentication on it

I don’t want to go into additional measures they could have added such as geolocation for the origination of the command or throttling to bar hackers from going berserk on their car fleet.

What would a leaked IP address on a WebRTC session in a browser do exactly compared to such stupidity?

The bane of security is developers and processes.

IOT (Internet of Things) is going to bring us many more such stories. That’s because it is based on developers and they make mistakes. Increase that a thousand fold, put it in a heating market where features and gadgets take center role, pushing back privacy and security – and you get hackable cars.

Telephony and video conferencing systems or old are devices sitting in networks. They need to “interoperate”. They have IT people who like controlling how things get deployed and updated. Are you sure these have been configured to work encrypted (I am sure most deployments aren’t). Are you sure the IT person really upgraded to the latest version that patches a bunch of security flaws?

And while we are talking about communications. The router you have at home that gives you WiFi on one end and connects you to the internet via ADSL or whatever on the other end – when did you last upgrade its firmware? Did you ever updated its password from the default? Is your service provider taking care of these things for you by any chance?

Here’s why:

• It is encrypted. By default. And there’s no way to remove that encryption from occurring (people complain about that one as well – go figure)
• It gets updated every 6-8 weeks with your browser. That update includes security patches when they are found
• It now forces (at least on Chrome) the sites using it to run over HTTPS instead of HTTP (did we say encryption?)
• It has permission mechanisms around camera and microphone access
• It has stricter permission mechanisms around screen sharing (white listing and extensions)
• Whenever someone peeps about security – it gets discussed and potentially updated in the implementation. Which gets to your browser in… 6-8 weeks
• Being a part of Chrome and other browsers means security gets front row and is prioritized properly

Yes. Developers can still do stupid things on top of WebRTC and botch it all, but that’s true about that snazzy new car you just bought or the smart TV that looks at you and hears what you say.

What more do you want?

If I wanted to hack you, WebRTC would be the last place I’d start.

The post Stop Whining about WebRTC Security Threats appeared first on BlogGeek.me.

No.

Now that we got that one out of the way, lets see why the recent announcement from Google and the GSMA isn’t relevant to WebRTC.

On February 22, the GSMA issued a press release titled Global Operators, Google and the GSMA Align Behind Adoption of Rich Communications Services. The subheading sums up the message:

Operators align on universal RCS profile; Google to provide RCS messaging client in Android

I was asked if this kills WebRTC – and the efforts of companies invested in WebRTC already.

There are two ways to view these questions:

1. People don’t understand what WebRTC (or RCS) is
2. People are just afraid of Google deciding on a whim to close WebRTC as just another experiment (think Google Reader, Wave, Buzz and a lot of other technologies and services in the Google graveyard)

Nothing really changed

I’ve written about the Google’s acquisition of Jibe. Nothing changed since then. I then assumed that Telcos will accept this and adopt it.

The recent press release shows that that has happened – at least by the GSMA. Time will tell which of the carriers will join this initiative.

I am not sure it will save RCS, but as I still believe it is the only alternative that brings RCS any future.

How is that different than WebRTC?

When I think about RCS, I think signaling, messaging and federation. It is about serving all people with a mobile device.

When I think about WebRTC, I think about media processing, business enablement. business processes and customizaton.

RCS isn’t about to win back the world in storm. It won’t beat WhatsApp or Facebook Messenger or WeChat or any of these other players any time soon. And if it does, it won’t be useful for most use cases I’ve seen with WebRTC anyway.

While both RCS and WebRTC can now be said to be promoted by Google, they aren’t serving the same needs in Google.

Will Google stop supporting WebRTC?

I don’t think that’s a possibility in the foreseeable future. How much investment will it put on WebRTC is another topic.

WebRTC is now part of HTML5. It is implemented by Google, Mozilla and Microsoft (don’t start with me on ORTC here please). Rumors abound about Apple, but I don’t really care at this point.

Google dropping WebRTC means back to plugin realm for things like Google Hangouts. And for things like RCS.

When you want to implement an RCS client on a browser, and initiative a voice call through it. From inside the browser. What are you going to use for it? Flash?

Google needs to continue its investment in WebRTC as long as it feels it needs Hangouts as part of its strategy. Messaging is  important to Google – check out their investments and acquisitions around messaging vendors. To that end, it can’t just drop WebRTC.

If, on the other hand, WebRTC gets to a point where it is good enough for Google, its investment in it may change. Until all browsers support WebRTC reasonably – there’s no threat of this happening.

The post Does Google’s Support of RCS Changes Anything for WebRTC? appeared first on BlogGeek.me.

Why don’y we meet in London on April?

It is that time of year. Informa is doing their annual WebRTC Global Summit in London on April.

This year, there are three tracks going on: Telecom, Developer and Enterprise

As with last year, if you arrive early (=for the weekend), you can also attend the TADHack event that is taking place.

I am chairing the developer day along with Chris Khoencke, we. We’ve worked hard to bring you some interesting topics and fresh new content.

While the developer day is free to attend, the rest of the conference is something I am waiting for as well.

When? 11-12 April

Where? Cavendish Conference Centre, London, UK

Free registration here

–

I will speak about two topics during the event:

1. Video codecs and WebRTC
2. Testing challenges with WebRTC

If you plan on attending or are just in town, then make sure to contact me in advance or just come say hi when you see me at the conference.

 

The post Join me in London for WebRTC Global Summit appeared first on BlogGeek.me.

Wake up and smell the ashes?

This week, as part of the slew of announcements of MWC, there was this one – SoftBank Deploys Large-Scale WebRTC-Based Conferencing Application Enabled by Dialogic. From the press release:

SoftBank Corp. has selected Dialogic® PowerMedia™ XMS software media server as a core network element of their new multimedia web conferencing solution, supporting SoftBank’s enterprise collaboration needs for video conferencing and chat room capabilities. The WebRTC-based web conferencing application will replace aging legacy video equipment and services for employees across their various divisions and brands.

The emphasis is mine, so lets unravel it a bit.

• Dialogic PowerMedia XMS is a media server for developers
• Video conferencing in enterprises was something you purchase not something you develop
• But something is changing
• Fidelity in the US acquired Vidtel a few years ago to get in-house the ability to build their own video conferencing capabilities
• SoftBank is doing the same now by licensing PowerMedia XMS and probably some other tools from other vendors
• To top it off, it is transitioning from “legacy video equipment” (=video conferencing vendors) to an in-house solution

Microsoft Skype? Cisco Telepresence? Or Spark? Polycom?

No. Just WebRTC. With their own logic and implementation.

It is not only verticals

If you asked me in 2015, I’d have said that video conferencing has its place, but it is now limited to the enterprise. Finance, Retail, Contact centers, healthcare, education – all these now have their own specialized vendors offering WebRTC solutions that are a lot more focused on the business of the vertical than a generic video conferencing vendor can ever be. It was easy to see why these verticals are heading away from video conferencing towards WebRTC vendors.

But video conferencing?

And without even a vendor?

DIY?

Unheard of!

But SoftBank is now doing it.

Why is it important?

The value of video conferencing in its generic unified communications form is diluting.

It is no wonder that Polycom closed its office in Israel and many of the other players of this market are struggling to grow. The future ahead of a legacy video conferencing vendor is murky. If I were working in that market – I’d be worried. Very worried.

SoftBank is just another instance of the tectonic shift taking place – the change in guard in communications that is happening all around us.

 

 

The post SoftBank’s Adoption of WebRTC Should be a Wake Up Call to Video Conferencing Vendors appeared first on BlogGeek.me.

Dear FreeSWITCHers,

We would like to share this open letter with you to say thank-you for your support. You really came through and helped keep our developers fueled and functioning during our annual summit. With your donations we were able to provide lunches and dinners for our team while they worked hard to keep FreeSWITCH moving forward.

This meeting allowed us to coordinate some awesome plans for ClueCon 2016 and formulate exciting additions for the code base! Meetings like these are extremely beneficial to the team and allow in depth discussions to help work through some of the more difficult problems.  We also have some exciting news for our community coming down the pipeline! So, once again, thank-you so much for your support!

Dear FreeSWITCHers,

We would like to share this open letter with you to say thank-you for your support. You really came through and helped keep our developers fueled and functioning during our annual summit. With your donations we were able to provide lunches and dinners for our team while they worked hard to keep FreeSWITCH moving forward.

This meeting allowed us to coordinate some awesome plans for ClueCon 2016 and formulate exciting additions for the code base! Meetings like these are extremely beneficial to the team and allow in depth discussions to help work through some of the more difficult problems.  We also have some exciting news for our community coming down the pipeline! So, once again, thank-you so much for your support!

Do you really want to trust a messaging platform to be there tomorrow as well?

Building house of cards on top of Facebook?

Facebook just killed Parse. A successful mobile BaaS platform they acquired in 2013. There’s a nice round up of feedback about it on Business Insider.

Inside the span of the same year, Facebook also announced the ability for businesses to integrate with its messaging platforms (both Messenger and WhatsApp).

It is funny somehow. The Business Insider article indicates Orbitz being one of Parse’ customers. I wonder how willing they will be to use another Facebook API to drive their messaging in front of their own users.

Here’s the thing. Messaging platforms are about messaging platforms. Most of them, don’t really care about the ecosystem of developers being built around them.

Twitter is famous for closing doors on developers. In 2012, it changed its rules around APIs, limiting access in a way that virtually killed any possibility to develop alternative Twitter clients.

What are we left with? The simple fact that relying on a single messaging platform and its API access for your service and business model is risky at best. Probably suicidal.

There’s a shift happening in the world. It started somewhere in the dot com bubble, morphing every couple of years:

• Websites
• Mobile Apps
• Messaging

Websites was easy. With access to the internet, everyone could be doing anything. There were no real gatekeepers, besides Google and its search engine – but that’s a rather “soft” sort of a gatekeeper – you could succeed without it (ask Facebook or Twitter).

Then we started the great migration towards mobile and applications. We were left with two gatekeepers – Apple and Google. Apple with its inconsistent and somewhat puritan approval rules, and again Google. Now if you want to reach out to users, you go through these companies, who hold the keys to that kingdom.

Recently, it started changing, with a migration happening towards messaging apps. With billions of users interacting through messaging, these are turning into platforms of interaction – places where businesses, virtual assistants and bots can interact with the users of the platform.

The difference now, is that these messaging platforms have a lot more control over the users who end up using them – and by extension, over the enterprises who integrate with their service.

–

My suggestion?

If you need messaging in your service, build it your own unless “socializing” and communicating directly with specific social networks add some huge benefit to you. The risks are just too great to be worth it.

 

Kranky Geek India takes place in Bangalore on 19 March 2016. Register to join us!

The post The Biggest Risk of Building a Business over Messaging Platforms appeared first on BlogGeek.me.

This week we had a minor improvement to the error response on hang up of a video call. And, for those of you Ubuntu fans out there, we have started a Ubuntu Packages GoFundMe to help get officially supported Ubuntu 14.x and 15.x packages! Please donate to support the cause! The developers work hard to create and maintain these packages and we need support from the community to make that happen.

Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! This week we have Fred Posner from Kamailio! And, head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-8847 [core] When a call ends sometimes the RTP stack complains of a bad poll. This is normal caused by shutting down the rtp on hangup. Add some code to catch the condition that is ok and still print the error otherwise.

The following bugs were squashed:

• FS-8838 [mod_rayo] Improve logging and error handling when executing API on output component. Attempt to make output component stop a little more robust and do a better job of detecting when output component completed because of hangup and preventing operations on output component when call has ended.
• FS-8839 [verto_communicator] Fixed screenshare not displaying in the proper conference when caller is transferred to another conference.
• FS-7132 [mod_verto] Fixed an issue with multiple websockets overwriting the jsock hash entry for a given sessionid causing a disconnection with the verto javascript application.
• FS-8806 [core] Change group_confirm_cancel_timeout to apply only to the legs that answer the call to prevent the remaining legs ringing indefinitely if the answered leg hangs up while executing the group confirm script.
• FS-8821 [core] Fixed switch_core_hash_insert_locked and switch_core_hash_insert_wrlock to make sure they check the status of the operation before returning a switch_status.
• FS-8811 [mod_local_stream] Fixed an intermittent segfault

There’s scaling and then there’s scaling.

The post from last week about the future of WebRTC live broadcast left some interesting impressions. Comments on that post and in Facebook. Red5 even did a follow up post on it.

One thing that was missing from these comments is an understanding of what scale means. Or rather the different types of scaling that are required when it comes to real time video.

Here are a few different aspects of scaling real time video.

#1 – Streams per machine

This is something that was raised on one of the comments on Facebook:

Most of the SFUs out there can actually handle 100’s and even 1000’s of connections (our data is not public but look at JVB:https://jitsi.org/Projects/JitsiVideobridgePerformance) and with most of them it should be possible without much effort to configure multiple SFUs in cascade to scale almost without any limit in my opinion.

That answers the question how many parallel sessions can you conduct on a single machine?

What is this one good for?

When you know how many sessions / streams you plan on having, you can then calculate how many machines you’ll need to run that scenario. From there, it is easier to extrapolate costs.

But that’s not our only vector of scale.

#2 – Streams per session

How many streams can we “bundle” per session?

In the comment above, what was failed to be mentioned was that these tests of 100’s and 100’s of connections were when each session had no more than 33 streams in it. So if what I want is to live broadcast a singer to 1000’s of viewers in real time – this SFU solution won’t be suitable for my need.

It is nice to be able to do multiparty video or to broadcast live with low latency, but always ask yourself – what’s the upper limit here for this single session? How many participants can I cram into that session without making things impossible on my infrastructure?

There are, in general, two critical challenges here:

1. When the number of users per session grows, the amount of communications between peers should be limited. At the extreme, a broadcaster should not be harassed by viewers directly (which is wher e the SFU starts breaking at scale and why I assume Jitsi preferred not to check above 33 participants)
2. When the number of users per session grows beyond a single machine, how does that compute? You’ll need to be able to distribute the session somehow either by cascading or using some other means of architectural magic

It is also worth pointing out that the larger the group, the more fragmentation issues you’ll have across parallel sessions – if the size of a session is dynamic, then on what kind of a machine should you start it? One which is free or one which is already somewhat busy? Can you dynamically route a session to other machines when the need arise? How do you load balance this?

#3 – Failure diffusion

This one is related because the higher the scale and capacity, the more of an issue this will be.

Let’s assume we can get a machine to run 10,000 streams in parallel. I am optimistic today. Let’s also assume that this all happens in a single process running in our machine.

What happens if there’s a bug somewhere (and believe me – there already is), which happen to cause the system to crash? Whenever we hit the bug, 10,000 streams get disconnected.

Now let’s further assume that each session holds 10 streams on average. And the bug was invoked due to one of these streams doing something slightly unorthodox. Now we have one session causing the disconnection of 999 more sessions on that machine.

Which leads us to the question –

Can I run multiple processes on the same machine, each catering a smaller number of sessions? Maybe even only a single session? How does that impact memory and performance? Is it even desirable?

For some, this might be necessary in their architecture – and it is very far from how telecom services are architected…

When Talking About Scaling…

Make sure you refer to the specific aspects you wish to scale.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

 

The post Different Requirements of Scaling real time video appeared first on BlogGeek.me.

It is in the viewer side.

Live broadcast is all the rage when it comes to WebRTC. In 2015 it grew 3-fold. It is a hard nut to crack, but there are solutions out there already – including the new Spotlight service from TokBox.

WebRTC Live Broadcast Today

If you look closely, most of the deployments today for live broadcast using WebRTC look somewhat like the following diagram:

How you live broadcast using WebRTC today

What happens today, is that WebRTC is used for the presenter – the acquisition of the initial video happens using WebRTC – just right to the broadcast server. There, the media gets transcoded and changes format to the dialects used for broadcasting – Flash, HLS and/or MPEG-DASH.

The problem is that these broadcast dialects add latency – check this explanation about HLS to understand.

With our infatuation to real time and the strive of moving any type of workload and use case towards real time, there’s no wonder that the above architecture isn’t good enough. With my discussions, many entrepreneurs would love to see this obstacle removed with live broadcasts having latency of mere seconds (if not less).

The current approaches won’t work, because they rely heavily on the ability to buffer content before playing it, and that buffering adds up to latency.

WebRTC Live Broadcast Tomorrow

This is why a new architecture is needed – one where low latency and real time are imperatives and not an afterthought.

Since standardization and deployment takes time, the best alternative out there today is utilizing WebRTC, which is already available in most browsers.

How WebRTC live broadcast will look like tomorrow

The main difference here? The broadcast server needs to be able to send WebRTC at scale and not only handle it on its ingress.

To do this, we need a totally different server side WebRTC media implementation than the alternatives on the market today (both open source and commercial).

What happens today is that WebRTC implementations on the server are designed to work almost back-to-back – they simulate a full WebRTC client per connection. That’s all nice and well, but it can’t scale to 100’s, 1000’s or millions of connections.

To get there, the sever will first need to split the dependency on the presenter – it will need to be able to process media by itself, but do that in a way that optimizes for large scale sessions.

This, in turn, means rethinking how a WebRTC media stack is architected and built. Someone will need to rebuild WebRTC from the ground up with this single use case in mind.

I am leaving a lot of the details out of this article due to two reasons:

1. While I am certain it can be done, I don’t have the whole picture in my mind at the moment
2. I have a different purpose here, which we are now getting to

A Skillset Issue

To build such a thing, one cannot just say he wants low latency broadcast capabilities. Especially not if he is new to video processing and WebRTC.

The only teams that can get such a thing built are ones who have experience with video streaming, video conferencing and WebRTC – that’s three different domains of expertise. While such people exist, they are scarce.

Is it worth it?

Optimizing down from 20 seconds latency to 2 seconds latency. That’s what we’re talking about.

Is investing in it worth the effort? I don’t have a good answer for this one.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post The Future of WebRTC Live Broadcast appeared first on BlogGeek.me.