Subscribe to bloggeek feed bloggeek
The leading authority on WebRTC
Updated: 2 hours 24 min ago

What will Happen when iOS Webviews Adopt WebRTC?

Thu, 05/12/2016 - 12:00

The real benefits of Apple and WebRTC has been left out of the conversations.

Can you help Apple find WebRTC?

There’s been too much chatter recently about Apple adding WebRTC. I am definitely in the opinion of Fippo here:

Things are going wild on the twitter #webrtc tag. Not a day without someone writing about Apple and WebRTC. Usually with little actual information.

I am not one to say I have inside information – I don’t. I don’t even know personally any Apple employee.

What I can say for sure, is that the real discussion on why Apple is important in the ecosystem of WebRTC has been ignored – as does the only place that is important.

Apple can add WebRTC in 3 places:

  1. Safari on Mac OS X
  2. Safari on iOS
  3. Webview on iOS

Just as a point of reference, when Google adopted WebRTC, it added it to Chrome on the desktop, then to Chrome on Android and somewhat later to Android webview. Not surprisingly, the priorities were decided based on the complexity and risk of the tasks (from the “easiest” to the most complex).

WebRTC in Mac OS X Safari

Safari on Mac OS X is nice, but at this point it won’t matter much. For the most part, Chrome is the leading browser these days – surpassing even IE; and from asking around, it seems that Mac users are used to switching from Safari to Chrome when needed – it isn’t unheard of.

Adding support for WebRTC to Safari on Mac OS X is nice, but for the most part, it won’t change things in any meaningful way.

WebRTC in iOS Safari

Safari on iOS is interesting. For iOS, there’s only a single alternative today, and that’s to port WebRTC on your own and integrate it into your app.

While this works well for most use cases, there are a few edge cases where this isn’t desirable.

Here are 4 such areas:

#1 – Porn

I had an interesting discussion two years ago with a porn vendor who wanted to start exploring WebRTC as a long term solution and a migration path from Flash.

Their main concern was that porn viewers were migrating from the desktop to their smartphones. I guess it has something to do with phone use in restrooms.

Surprisingly (or not), the main reason for him to want WebRTC was iOS. Applications on iOS require to be puritan apps to a large degree. If an app’s content doesn’t abide to the app store submission rules (and porn doesn’t), then the app won’t get approved. This becomes a kind of a headache if what you do is serve porn.

There are two ways to “fix” that today, both run in the browser (Safari on iOS that is):

  1. Use HLS to stream the video, but the latency wasn’t good for this vendor. He needed low latency. In his words, “the viewer needs to be able to interact with the performer and tell her what to do”. Apparently, waiting 20 or 30 seconds until the performer responds to the viewer’s whims isn’t fast enough
  2. Capture JPEG images and send them over HTML as if they are video. It means 3 frames per second or something just as stupid, but it seems porn viewers are happy with it. At least to some extent

Having WebRTC in Safari for iOS means no need to go through the approval process of Apple’s App Store, something impossible for such companies.

As you might have guessed, I learned a lot in the meeting with that company.

#2 – Click to dial

There are times when WebRTC is used for customers and potential customers to reach out to the vendor. They happen to search the internet, bump into your travel agency, and want to make a call to book a flight. Or they might have bumped into an issue with the toaster they purchased and want to ask for assistance. Whatever the case is, that person has no inclination to install an app on his phone just to make that one time interaction.

WebRTC on Safari’s iOS means that this is possible now to achieve for iOS users – and not only the Android ones.

#3 – Guest Access

In many cases, there’s a UC (Unified Communication) system already in use. While its focus is in employees communicating with each other, these systems also allow for guest access. Think of joining one of them GoToMeeting or WebEx sessions. First thing you do in them is install a client to be able to do them – or fumble around with a phone number and a PIN code. Both ugly practices.

WebRTC enables to leave that behind by sending the guest a URL in his email – not a URL with instructions in it, or an installation link – but a URL to the actual session. Along the way, you can also make that URL unique per participant if you wish. This is already available today – unless you use an iOS device.

#4 – Gaming (the gambling kind)

Apple takes 30% of all purchases made through apps. 30%

Gambling and booking usually work on profit margins that are usually lower than 10%.

That being the case, how, if at all, can they make money out of gamblers using apps without letting them pay through the app? The whole idea of gambling is the reduction of friction.

Now, getting gamblers to open a URL and play from there, with whatever interactivity they wish to add through the use of WebRTC – that’s a useful capability.

WebRTC in iOS Webview

This is where things get really interesting.

As stated earlier, most consumption on mobile today is done via apps. For WebRTC, most of these apps are developed as native apps. This happens for a couple of reasons:

  1. Force of habit. That’s just life as we know it today
  2. Native tends to work slightly better than HTML5 apps
  3. WebRTC dictates porting it and wrapping it as an SDK on iOS today

While native is great, HTML5 is even better. It offers cross platform development capabilities across desktop, browser and mobile – and in them, across ALL operating systems. WebRTC isn’t there yet because Apple isn’t there yet.

Add to that the new technique behind PWA (Progressive Web Applications), and you may well find HTML5 enticing for your service. To support such a thing, WebRTC on iOS isn’t enough, but it is still needed. What got this piece of technology into my radar was this write up by Henrik Joreteg – Why I switched to Android after 7 years of iOS. It goes into detail on the user experience of PWAs.

Even if you decide to stick to native development, having WebRTC implemented, optimized and fine tuned by Google and Apple for their respective mobile operating systems and then just slapping a Webview in place to use them in your app is a worthwhile investment.

Will Apple add WebRTC to its products? Probably yes

Do we know when will it happen? No

Should we prepare for it? Maybe. You tell me


The post What will Happen when iOS Webviews Adopt WebRTC? appeared first on

VP8 vs VP9 – Is this about Quality or Bitrate?

Mon, 05/09/2016 - 12:00


VP8 and VP9 are video codecs developed and pushed by Google. Up until recently, we had only VP8 in Chrome’s WebRTC implementation and now, we have both VP8 and VP9. This lead me to several interesting conversations with customers around if and when to adopt VP9 – or should they use H.264 instead (but that’s a story for another post).

This whole VP8 vs VP9 topic is usually misunderstood, so let me try to put some order in things.

First things first:

  1. VP8 is currently the default video codec in WebRTC. Without checking, it is probably safe to say that 90% or more of all WebRTC video sessions use VP8
  2. VP9 is officially and publicly available from Chrome 49 or so (give or take a version). But it isn’t the default codec in WebRTC. Yet
  3. VP8 is on par with H.264
  4. VP9 is better than VP8 when it comes to resultant quality of the compressed video
  5. VP8 takes up less resources (=CPU) to compress video

With that in mind, the following can be deduced:

You can use the migration to VP9 for one of two things (or both):

  1. Improve the quality of your video experience
  2. Reduce the bitrate required

Let’s check these two alternatives then.

1. Improve the quality of your video experience

If you are happy with the amount of bandwidth required by your service, then you can use the same amount of bandwidth but now that you are using VP9 and not VP8 – the quality of the video will be better.

When is this useful?

  • When the bandwidth available to your users is limited. Think 500 kbps or less – cellular and congested networks comes to mind here
  • When you plan on supporting higher resolutions/better cameras etc.
2. Reduce the bitrate required

The other option is to switch to VP9 and strive to stay with the same quality you had with VP8. Since VP9 is more efficient, it will be able to maintain the same quality using less bitrate.

When is this useful?

  • When you want to go “down market” to areas where bandwidth is limited. Think a developed countries service going to developing countries
  • When you want to serve enterprises, who need to conduct multiple parallel video conferences from the same facility (bandwidth towards the internet becomes rather scarce in such a use case)
How is bitrate/quality handled in WebRTC by default?

There is some thing that is often missed. I used to know it about a decade ago and then forgot until recently, when I did the comparison between VP8 and VP9 in WebRTC on the network.

The standard practice in enterprise video conferencing is to never use more than you need. If you are trying to send a VGA resolution video, any reputable video conferencing system will not take more than 1 Mbps of bitrate – and I am being rather generous. The reason for that stems from the target market and timing.

Enterprise video conferencing has been with us for around two decades. When it started, a 1 mbps connection was but a dream for most. Companies who purchased video conferencing equipment needed (as they do today) to support multiple video conferencing sessions happening in parallel between their facilities AND maintain reasonable internet connection service for everyone in the office at the same time. It was common practice to reduce the internet connection for everyone in the company every quarter at the quarterly analyst call for example – to make sure bandwidth is properly allocated for that one video call.

Even today, most enterprise video conferencing services with legacy in their veins will limit the bitrate that WebRTC takes up in the browser – just because.

WebRTC was developed with internet thinking. And there, you take what you are given. This is why WebRTC deals less with maximum bandwidth and more with available bandwidth. You’ll see it using VP8 with Chrome – it will take up 1.77 Mbps (!) when the camera source is VGA.

This difference means that without any interference on your part, WebRTC will lean towards improving the quality of your video experience when you switch to VP9.

One thing to note here – this all changes with backend media processing, where more often than not, you’ll be more sensitive to bandwidth and might work towards limiting its amount on a per session basis anyway.

All Magic Comes with a Price

We haven’t even discussed SVC here and it all looks like pure magic. You switch from VP8 and VP9 and life is beautiful.

Well… like all magic, VP9 also comes with a price. For start, VP9 isn’t as stable as VP8 is yet. And while this is definitely about to improve in the coming months, you should also consider the following challenges:

  • If you thought VP8 is a resource hog, then expect VP9 to be a lot more voracious with its CPU requirements
  • It isn’t yet available in hardware coding, so this is going to be challenging (VP8 usually isn’t either, but we’re coping with it)
  • Mobile won’t be so welcoming to VP9 now I assume, but I might be mistaken
  • Microsoft Edge won’t support it any time soon (assuming you care about this Edge case)

This is a price I am willing to pay at times – it all depends on the use case in question.


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



The post VP8 vs VP9 – Is this about Quality or Bitrate? appeared first on

What if WebRTC SDP Munging was Prohibited?

Thu, 05/05/2016 - 12:00

How will we be able to live in a world without… SDP?

The one thing I love best about the WebRTC Standards website is that it looks at a place I neglect most of the time – the IETF and W3C. While I had my share of dealings with standardizaton organizations when I was young and pretty, it isn’t something I like doing much these days.

Last month, it seems a decision was made/in the process of being made – to prohibit SDP munging. As these things go, if this happens at all it will take VERY long to happen. That said, such a change will have huge impact on a lot of services that make use of this practice.

What’s WebRTC SDP munging?

SDP munging is a process of a WebRTC application taking its future in its own hands and deciding to change the SDP. With WebRTC, once the application sets the user media and connects it with a peer connection (=setting up to start a session), it receives the SDP blob that needs to be sent to the other participant in the session. This blob holds all of its capabilities and intents for the session.

If you want to learn more about the contents of the SDP, then this article on webrtcHacks will get you started.

Here’s a quick flow of what happens:

Where SDP munging takes place in WebRTC

Now that the application holds the SDP blob, the question that must be asked is what can the application should/can do with this SDP blob?

  1. The application should pass it to the other participant. Probably by placing it in an HTTP request or a Websocket message
  2. The application can change it (=mung it) before well… setting and sending it

The problem is in that second part.

What’s the problem with WebRTC SDP munging?

SDP embodies everything that is wrong about SIP. Or at least some of what’s wrong about SIP

There are several aspects to it:

  1. Being a textual kind of a protocol that is open as hell, it is open to interpretation of humans, making it hard to use. Interoperability is a headache with it, and now we’re leaving it at the hands of web developers. It becomes doubly hard, as there are extensions to SDP – some standardized, some in process and some just proprietary ones. And you need to sift between them all to decide what to do on the SDP level
  2. When you modify the SDP, it is assumed that the browser needs to interpret your modifications. Since it already created an SDP, it had its own understanding of what you want, but now he needs to interpret it yet again but instead of doing that through an API, it needs to do it via an ugly text blob. And browsers are created by humans, so they might not interpret it the same way you did when you munged it – or different browsers might interpret it differently
  3. New browser versions might not be able to interpret what you munged simply because that isn’t part of their main focus. The smaller you are, the more susceptible you will be to practicing SDP munging – what you do there might not be as popular as you though (or not defined as popular by browser vendors) – and it will break in some future version
  4. SDP isn’t that fun to modify with JavaScript. So it frustrates developers which ends up leading to more bugs and inconsistencies
What happens if and when it gets prohibited?

When SDP munging gets banned, existing applications that rely on it will break.

They might break completely, but mostly, they’ll break in ways that are less predictable – codecs won’t be configured in the exact way the developer intended, bitrates won’t be controlled properly, etc.

The whole idea behind SDP munging is to get more control over what the browser decides to do by default, so disabling it means losing that control you had.

When is this change expected?

Not soon, if at all.

That said, I wouldn’t recommend ignoring it.

What I’ve understood is that there’s little chatter about this on the standards mailing lists, so this just might die out.

The reason I think it is important is because at the end of the day, munging the SDP leaves you prone to whims of browser vendors as well as leaves you open to this future option of banning SDP munging.

What should you do about it?

First of all – don’t worry. This one will take time. That said, better plan ahead of time and not be surprised in the future. Here’s what I’d do:

  1. Refrain from practicing SDP munging as much as possible
  2. Since we’re already starting to see some of the ORTC APIs tricking into WebRTC, you should make an active investment now and in the near future to use these APIs whenever you feel the urge to make changes in the SDP (that’s assuming what you need is supported in the API level and not only via the SDP)
  3. If you aren’t sure, then check the code you have to see if you are practicing SDP munging, and if you are, make some kind of a plan on how to wean yourself from it


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

The post What if WebRTC SDP Munging was Prohibited? appeared first on

The WebRTC Slack-Rush

Mon, 05/02/2016 - 12:00

If the only thing you have is IP calling, then why are you investing in a Slack integration this late in the game?

Looking for gold in Slack by adding WebRTC calls to it?

Slack is a rising star. It has a small and growing set of users, some of which are happy to pay for the service. When it works, it is great. When it doesn’t, well… it then just feels like any other UC or enterprise communication service. I find myself using Slack more and more. Not necessarily because I need to, but rather because I am drawn to it by the teams I collaborate with. I like the experience.

In the last few months it seems that everyone is rushing to Slack, trying to build their own WebRTC integration with it. The latest casualty? LyteSpark.

Browsing Slack’s App Directory, I found the following WebRTC based services under the Communications category:

  • Google Hangouts
  • Skype
  • GoToMeeting free
  • Room
  • UberConference
  • Limnu
  • Blue Jeans
  • Screenleap
  • Yodel
  • Quickchat

There are others, not in the marketplace, and probably a few others in other categories or ones that I just missed.

The problem with many of them is that Slack is actively adding VoIP now – using WebRTC of course.

As I always stated, WebRTC downgrades real time communications from a service to a feature. And now, Slack is adding this feature themselves.

The problem now becomes that these WebRTC services are competing with the built-in feature of Slack – something that will be infinitely easier and simpler to use – especially on mobile, where it is just there. What would be the incentive then to use a Hangouts bot when I can just start the same functionality from Slack without any integration? This is doubly so for free accounts, which are limited to 10 integrations.

The only WebRTC services that can make sense in such a case, are those that have some distinct added value that isn’t available (or easily available through roadmap of Slack). It boils down to two capabilities:

  1. Seamless integration with PSTN calling. This is what OttSpott does. I think this is defensible simply because I don’t see Slack going after that market. They will be more inclined to focus on IP based solutions. Just a gut feeling – nothing more
  2. Solving a higher level problem than pure voice or video calling. Maybe a widget integration with the customer’s website for click-to-call capabilities, though it can be some other capabilities that focus on a smaller niche or vertical

This Slack-rush of WebRTC services seems a bit unchecked. Basking under the light of WebRTC doesn’t work anymore, so time to move to some other hype-rich territory, and what better place than Slack? Problem is, without a real business problem to solve (conducting a video call over the web isn’t a business problem), Slack won’t be the solution.


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

The post The WebRTC Slack-Rush appeared first on

WebRTC and Server GPUs? A whitepaper

Fri, 04/29/2016 - 13:00

GPUs is most probably where we’re headed.

A couple of months ago, I was approached by SURF. An Israeli vendor specializing in server media processing. As many of its peers, SURF has been migrating from hardware based DSP systems to software systems in their architecture. As they’ve entered the WebRTC space, they wanted to have a whitepaper on the topic, and I accepted the challenge.

The end result? WebRTC Server Side Media Processing: Simplified

Download the whitepaper

Two things that I wanted to share here:

#1 – WebRTC Server Side Media Processing is real

What made writing this whitepaper so interesting for me was the fact that there really is a transition happening – not to using WebRTC – that already happened as far as I can tell. It is something different. A transition from simple WebRTC services that require a bit of signaling to services that process the media in the backend. This processing can be anything from recording to gatewaying, streaming, interoperating or modifying media in transit. And it seems like many commercial use cases that start simple end up requiring some kind of server side media processing.

In the span of the last two months, I’ve seen quite a few services that ended up building some WebRTC server side media processing for their use case. Maybe it is just related to the research I did around this are for the whitepaper, but I think it is more than that.

#2 – The Future Lies in GPUs

As I was working on the whitepaper, this one got published by Jeff Atwood – it is about AI winning a game of Go. Or more accurately, how GPUs are a part of it:

GPUs are still doubling in performance every few years

The whole piece is really interesting and a great read. It also fits well with my own understanding and knowledge of video compression (=not that much).

Two decades ago, video compression was a game of ASIC – the ugliest piece of technology possible. Hard to design and develop. You wanted to implement a new video codec? Great. Carve a few years for the task and a couple of millions to get there. They are hard to design and hard to program for.

Later it was all DSP. Still hard and ugly, but somewhat cheaper and with some flexibility as to what can get done with them. DSPs is what powers most of our phones when it comes to recording and playing back videos. It works pretty well and made it seem as if the device in our pocket is really powerful – until you try using its CPU like a real PC.

GPUs were always there, but mostly for gaming. They do well with polygons and things related to 2D and 3G graphics, but were never really utilized for video compression. Or at least that’s what I thought. I heard of CUDA in passing. Heard it was hard to program for. That was something like 5 years ago I believe.

Then I read about GPUs being used to break hashes, which was an indication of their use elsewhere. The Jeff Atwood piece indicated that there are other workloads that can benefit from GPUs. Especially ones that can be parallelized, and to some extent, video compression is such a task. It is also where SURF is focusing with its own server media processing, which places them in the future of that field.

GPUs are no longer used only for gaming or in our PCs and laptops – they are also being deployed in the cloud. They assist companies running Audocad in the cloud (heard such a story in the recent WebRTC Global Summit event), so why not use them for video compression when possible?

If you are interested in WebRTC and how media processing is finding its way to the server, and how that fits in with words like cloud and GPU, then take a look at this new whitepaper. I hope you’ll enjoy reading it as much as I’ve enjoyed writing it.

Download and read this new WebRTC whitepaper.

The post WebRTC and Server GPUs? A whitepaper appeared first on

Where are we with WebRTC?

Thu, 04/28/2016 - 12:00

Progressing nicely – of course.

Checking the pulse of WebRTC

It’s been 5 years since WebRTC came to our lives. Different people count it from different times. I heard in the last month or two the years 2009, 2010 and 2011 stated as the year of birth of WebRTC. While no one should really care, for me, WebRTC started with Google’s announcement of WebRTC in May 2011. It was the first time Google publicly stated its plans for its GIPS acquisition, and it came out as an open source package that was planned to get integrated into browsers and be called WebRTC. I was a CTO at a business unit licensing VoIP products to developers. The moment I saw it, I knew everything was going to change. It was one of the main reasons I left that job, and got to where I am today, so it certainly changed everything for me.

As we head towards Mat of 2016, it is time to look a bit at the 5 years that passed – or more accurately the 5th year of WebRTC.

One one hand, it seems that nothing changed. A year ago, Chrome and Firefox supported WebRTC. That’s on Windows, Mac OS X, Linux and Android. Today, we’re pretty much in the same position.

On the other hand, adoption of WebRTC is huge and its impact on markets is profound; oh – and both Microsoft and Apple seem to be warming up to the idea of WebRTC – each in his own way.

If you are interested in a good visual, then my WebRTC infographic from December 2015 is what you’re looking for. If it is numbers and trends today, then read on.

951 Vendors and Project – and growing

I’ve been tracking the vendors and projects of WebRTC since 2013, actively looking for them and handpicking relevant projects that are more than 10 lines of code and any vendor I saw. It turned into one of the services I have on offer – access to this actively growing (and changing) dataset of WebRTC vendors.

Earlier this month, the WebRTC dataset had the following interesting numbers:

  • 951 vendors and projects that I track
    • There are a few that shutdown throughout the years, but not many
    • There are a few that I know of and don’t make it into the list, because they want to remain private at this point
    • There are data points I’ve stored and haven’t processed yet – many of them additional vendors (got around 80 in my backlog at the moment)
  • 2015’s average was 26 vendors added every month
  • 2016 shows a slight increase to that average. 3-4 months aren’t enough to make this definitve yet
  • For now, there are 41 acquisitions related to WebRTC in one way or another
    • Some of them are less relevant, such as Mitel acquiring Polycom
    • Others are all about WebRTC, such as Talko’s acquisition by Microsoft

What is interesting is that these vendors and projects are always evolving. They aren’t only limited to startups or large enterprises. They aren’t specific to a certain vertical. They cut through whole industries. Just this week a new use cases popped – movers who can give a price quote without being on site. Will it fly? Who knows.

We’ve been witnessing a surge in communication services. We are not limited today by concepts of Telephony or Unified Communications. These became use cases within a larger market.

What is different now is that the new projects and vendors don’t come with VoIP pedigree. They are no longer VoIP people who decided to do something with WebRTC. Most of them are experts in communications – not digital communications, but communications within their own market niche. Check out the interview from last week with Lori Van Deloo of BancSpace – she knows her way in banking.

API Platforms are Maturing

Communication API platforms using WebRTC are maturing. Many of them have the basics covered and are moving further – either vertically or horizontally. Vertically by deepening their support of a specific capability or horizontally by adding more communication means. You can read my WebRTC API report on it. I am in the process of updaing it.

What is interesting is how this space is being threatened from two different domains:

  1. Unified Communication platforms turned Enterprise Messaging turned developer ecosystems. Cisco Spark and Unify’s Circuit are such examples. They are an enterprise UC solution that can be used (and is actively being marketed as) a long tail development platform for general communication needs
  2. Specialized component vendors who are offering widgetized approach of their service, enabling its integration elsewhere. Gruveo, and Veeting do it a lot; Drum ShareAnywhere and a lot of others are also examples of it

This is affecting the decision making process of those who need to roll out their own services, making the technology more accessible, but at the same time more complex and confusing when the time comes to pick a vendor to lean on.

Verticals are Fragmenting Further

What does a communication solution in healthcare looks like?

If you ask a Unified Communications vendor, it will be able having a room system everywhere and enabling doctors/nurses/patients communicate.

I had conversations with these types of health related vendors:

  • Contact centers for doctor visitations of a healthcare insurer
  • IOT measurement device a user takes home, connects to the phone and from there to a doctor
  • Online group treatment
  • Serving rural areas from an established hospital in developing countries
  • Assisting/learning/teaching/participating in remote surgery
  • Medical tourism
  • Counseling for enterprise employees
  • Care for seniors
  • Secure messaging for doctors
  • Medical clowns
  • Fitness related

Each of these is a world unto its own, and to think we’ve looked at them all through the prism of Unified Communications or even the “healthcare vertical”.

WebRTC brought with it the ability to hone in on specific market needs.

WebRTC is already ubiquitous. As with any technology, its has its rough edges and challenges.

I’ve dealt with developing VoIP products for the better part of the last two decades – I can tell you hands down that never before did we have the alternatives to do what we can today. If you have VoIP on your mind, then WebRTC should be the first thing to try out as a component in your solution.

The post Where are we with WebRTC? appeared first on

Skype will go the Hangouts Route with WebRTC (or vice versa?)

Mon, 04/25/2016 - 12:00

Well… Almost.

For those who haven’t been following the path Skype is taking, here’s a quick recap of the last year or so:

  • Lync got “merged” with Skype, rebranding it as Skype for Business – so now all of Microsoft’s voice and video calling services are Skype
  • Skype for Web was announced at about the same time
  • A Skype SDK was launched
  • And now, Skype for Web is running on Microsoft Edge without any plugin installation
  • Oh, and they announced bots too
Skype on Edge sans plugins was to be expected

That last bit near the end? Of Skype not needing plugins when executed on Edge? That was rather expected.

Microsoft is hard at work on adding RTC to Edge – be it ORTC or WebRTC – or both.

The main UC and consumer messaging service of Microsoft are based on Skype, so it is only reasonable to assume that Skype would be utilizing Edge capabilities in this are AND that Edge would be accommodating for Skype’s needs.

This accommodation comes by way of the first video codec that Edge supports – H.264UC – Skype’s own proprietary video codec. Edge doesn’t interoperate with any other browser when it comes to video calling due to this decision. In a way, The Edge team sacrificed interoperability for Skype support.

Browser vendors tend to care for themselves first. And then for the rest of the industry:

Google Hangouts route to plugin-less world

Hangouts today is in the same predicament as Skype in a lot of ways.

  1. Its support for the browser of the mothership is native (Chrome-Hangouts; Microsoft-Skype)
  2. Both require plugins on browsers other than their own – and will stay that way for the forseable future
  3. Both are no consumer/enterprise services, trying to cater both
  4. Both aren’t as big or as active as their newer competitors (Facebook, WhatsApp and WeChat to be specific)

Where do they diverge?

No Plugin+SDK=Interesting

Skype has added the SDK bit before Hangouts.

Skype now offers its large user base and infrastructure to 3rd party developers to build their own services. The documentation is quite extensive (too much to go through to get things done if you ask me – especially compared to the WebRTC API platforms) and the intent is clear.

Skype doesn’t have a glorious record with developers. Maybe this time around it will be different.

And it added bots.

They did that ahead of the rumored bot support by Google.

Where’s Hangouts?

Meanwhile, Hangouts is just the same as it were two or three years ago.

The backend probably changed. It now sometimes do P2P calling. And it has a new UI. And the old one. And you can never know which one will pop up for you. Or where to write (or read) that text message.

Something needs to change and improve with Hangouts.

Skype seems to be moving forward at a nice pace. Cisco Spark has its own forward motion.

But Hangouts has stalled – especially considering we’re talking about Google – a company that can move at breakneck speeds when needed.

I wonder what’s ahead of us from both these services.

The post Skype will go the Hangouts Route with WebRTC (or vice versa?) appeared first on

BancSpace and WebRTC: An Interview With Lori Van Deloo

Thu, 04/21/2016 - 12:00
isVisible=false; function show_hide_searchbox(w){ if(isVisible){ document.getElementById('filterBoxSelection').style.display = 'none'; w.innerText='Filter ▼'; }else{ document.getElementById('filterBoxSelection').style.display = 'block'; w.innerText='Filter ▲'; } isVisible=!isVisible; } function checkIfSelected(chk){ if(chk.checked==1) chk.parentNode.className = "selected"; else chk.parentNode.className = "notselected"; getSelectedValues(); } function getSelectedValues(){ var a=document.getElementsByClassName('selected'); var vtVal=[] , ctVal=[] , ftVal=[]; var ct=0,vt=0,ft=0; for (x = 0; x < a.length; ++x) { try{ if(a[x].getElementsByTagName('input')[0].className=='companyType'){ ctVal[ct]= a[x].getElementsByTagName('input')[0].value; ct++; } if(a[x].getElementsByTagName('input')[0].className=='vendorType'){ vtVal[vt]= a[x].getElementsByTagName('input')[0].value; vt++; } if(a[x].getElementsByTagName('input')[0].className=='focusType'){ ftVal[ft]= a[x].getElementsByTagName('input')[0].value; ft++; } }catch(err){ } } search_VType(vtVal); search_CType(ctVal); search_FType(ftVal); } function search_VType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null){ a[x].style.display='block'; } } if(val.length==0){ a[x].style.display='block'; } } } function search_CType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null && a[x].style.display=='block'){ break; } if(i==val.length-1){ a[x].style.display='none'; } } } } function search_FType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null && a[x].style.display=='block'){ break; } if(i==val.length-1){ a[x].style.display='none'; } } } }Check out all webRTC interviews >>

BancSpace: Lori Van Deloo

April 2016


Banking and WebRTC done right.

[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.]

I had my fair share of demos where a banking or a contact center application felt boring and Spartan. Too many times, the focus is on how to get video to show and when that happens – the developers are so happy they forget about the bigger picture – the service.

When I met Lori Van Deloo, Founder & CEO of BancSpace, I thought I was in for the same kind of an experience. But boy, was I wrong. She started off in the best way possible. She just explained that she worked for many years at VISA and then decided to found BancSpace. This is always a good sign – a founder who comes from the vertical he or she wants to serve instead of a VoIP engineer who decides to fix and disrupt industries.

The rest of the demo was an eye opener on how things could be done in a way that looks so simple but is devilishly complex. I of course wanted an interview, and Lori was kind enough to oblige.


What is BancSpace all about?

BancSpace is a WebRTC digital banking communications and collaboration platform that facilitates live access and engagement with qualified specialists, anytime, anywhere.

Prior to founding BancSpace, I spent a number of years working in software, including mobile and most recently, payments.  These and other technologies have become increasingly important in the delivery of financial services for both consumers and businesses.  However, when it comes to critical decisions or complex tasks, many prefer to consult with an expert to get financial advice or to get assistance such as when opening an account or applying for a loan.  The idea behind BancSpace is to allow Financial Services providers to deliver innovative customer experiences that combine both – the best of digital technology and live service expertise.

BancSpace provides a full suite of real-time capabilities to enable advisors/specialists to connect and collaborate with their customers just as if they were meeting face-to-face.  It’s basically video banking + deep, two-way collaboration.  Since the service is cloud-based, both advisors and customers can access the platform from any device (and thanks to WebRTC, no downloads or plugins on either side!)

Having spent more than a decade working closely with large Financial Institutions, we also knew that any service we developed must address industry needs for greater management and controls.  As such, multiple layers of authentication, security and permissions have been built into the BancSpace service platform.  These additional features help support compliance with industry standards to confirm a customer’s identity and help protect the access to and exchange of information during a BancSpace session.


Why WebRTC, and why in banking?

Unlike other communications technologies, WebRTC was purpose-built from inception to specifically address security considerations through the framework of the WebRTC technology architecture.  For example, encryption is a mandatory feature of all data and media streams sent over WebRTC.  Features like this are especially important when you are working in highly sensitive, highly regulated environments such as banking and other financial services.

We also chose WebRTC for its ability to deliver on the important benefits of quality and convenience.  The real-time nature results in a high quality voice-video-data exchange, and the convenience of no downloads / no plugins makes for a superior customer experience.


Backend. What technologies and architecture are you using there?

We have developed an intricate service platform that integrates a number of different technologies and a proprietary advisor-customer interaction model.  Our developers are strong advocates for node.js.  It is great for use with WebRTC, as well as more broadly to support our full suite of real-time collaboration capabilities.  The underlying service architecture also includes support for managing the controls and permissions that govern the access and use of the service.


In your service, you have an interesting co-browsing and collaboration mechanism. Can you elaborate a bit about it?

Yes.  Our two-way collaboration workspace is a core aspect of the BancSpace service.  The workspace allows advisors or specialists to engage and assist their customers to immediately complete important tasks or transactions, all in a secure 1:1 session.

A number of services provide one-way screen sharing tools or applications, but as we looked at the requirements for our customers’ use cases, we needed a solution that went well beyond that.  It called for something that enabled a more intimate, two-way interaction because our goal was to replicate the same high quality, engaging experience that typically has been associated with in-person or in-branch service and then extend it to every customer interaction, on any device.

We also needed something that was more secure in terms of managing session content.  The basic “open desktop” format offered by other services just doesn’t work for many Financial Services transactions.  Think about how many times someone running an online meeting inadvertently shared the wrong file?  Or had a personal email or IM pop up in the middle of a meeting?  BancSpace’s approach allows providers to completely prevent these issues and only allow approved content to be shared in a given session.


Where do you see WebRTC going in 2-5 years?

For WebRTC-based vertical applications it is still early days.  Especially for those in highly regulated industries, WebRTC needs to be viewed within the broader technology adoption landscape – many Financial Services providers are still getting comfortable with cloud and SaaS.  Focused pilots and test programs will be important for applications in Financial Services to ensure bank-grade quality before expanding to full, generally available (GA) services.  A real opportunity to accelerate efforts here is for leading Financial Services providers to partner with Fintech-focused start-ups developing WebRTC-based applications and establish a beachhead for the industry.

Getting to an agreed standard with ubiquitous access for all end-customers is also critically important for driving enterprise adoption.  Financial Institutions, and really any large enterprise, need to be able to provide solutions that serve their broader customer base (not just the majority), and do so in a way that maintains a consistent experience for customers across any channel.  It’s also more efficient from a back-office operational perspective.


If you had one piece of advice for those thinking of adopting WebRTC, what would it be?

If you are thinking about creating a mobile/web application or service that includes WebRTC, it’s important to understand the problems that your clients are trying to solve.  WebRTC is an enabling technology and we believe a foundational one, but consideration should be given for how to best incorporate it into the design of your service to ensure it delivers the desired functionality and provides a great experience.  Once this is determined, then there is much to be leveraged from the vast resources, libraries and community supporting WebRTC globally.

For BancSpace, we are 100% focused on the end customer experience (CX).  Any WebRTC functionality we include must address a specific need and support the scenarios for which our clients are looking to employ our service. We then spend time on the UX design so that using our service (and WebRTC) is an effortless experience for both advisors and customers.


Given the opportunity, what would you change in WebRTC?

Our experience with WebRTC has been very positive thus far, especially when you compare to the early days of video banking.  For years the industry has been experimenting with various instantiations of video banking applications.  WebRTC unlocks the potential to truly bring together technology + live expertise and provide a modern, cost-effective option for Financial Institutions to expand their footprint without the legacy CAPEX and OPEX of a fixed, physical branch network.

So what would I change?  Well, I guess continuing to drive toward a foundational set of standards so that WebRTC can become a ubiquitous enabling technology.


What’s next for BancSpace?

Driving the next wave of Digital Banking!  The ability to combine communications and collaboration technologies with live expertise is allowing us to re-imagine the delivery of Financial Services in ways that can have immediate impact on growth.

We are actively engaged with Financial Institutions and other Financial Services providers, and believe there is a real opportunity to reinvent the advisor-customer experience.  WebRTC is central to this proposition and we expect it will play an increasingly important role in the BancSpace technology strategy as we expand our use of it and create new capabilities to support a growing client base.

The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.

The post BancSpace and WebRTC: An Interview With Lori Van Deloo appeared first on

How Video Conferencing Vendors Adapt to WebRTC?

Mon, 04/18/2016 - 12:00

We can do better.

In 2012, when I started this blog, I had only 3 WebRTC related posts in mind. One of them was about the room system of the future. While this has never materialized in the 4 years since, things have definitely changed in the video conferencing space.

Let’s see what video conferencing vendors have done about WebRTC so far (vendors are listed in alphabetical order).


Avaya’s assets in video conferencing comes from its acquisition of RADVISION.

A quick glance at the current website specs for its video conferencing line of products (mainly SCOPIA) shows a rather sad story. SCOPIA offers the best money can get, assuming we were 4 years after 2012 and WebRTC didn’t exist.

As the website states, you can “Experience crisp, smooth video quality with resolutions up to 1080p/60fps, stellar bandwidth efficiency, and error resiliency with H.265 High Efficiency Video Coding (HEVC) and Scalable Video Coding (SVC).”

Bolded tech words are my own.

Some things to note:

  • 1080p is great, and the “de facto” thing these days – if you have the juice and the bandwidth for it. 60fps is more than 30fps, but I wonder if it is worth the additional effort to get there
  • H.265 is betting the farm on the wrong codec
  • SVC is where we’re headed. Getting one out of 3 main bullet points correct is a good start

Cynicism aside, I have it from good sources that Avaya is working on adding WebRTC support to its gear. Where exactly does it fit in its bigger picture, and why so late is a different story altogether.

What bugs me the most here is that in the last 4 years, any advancement in the SCOPIA video conferencing product line was reliant solely on hardware capabilities. You can’t leapfrog in this way over competitors – especially when something like WebRTC comes into the scene.

It is sad, especially since Avaya does work and promote WebRTC in contact centers already. At least on the press release level.


Cisco is a large and confusing company. If you look at its telepresence products, they resemble the ones coming from Avaya. Same highlights about speeds and feeds.

On the other hand, Cisco has thrown its weight behind a new product/service called Cisco Spark.

Cisco Spark is a Slack lookalike with a focus on voice and video communications by connecting to the massive line of products Cisco has in this domain. Cisco Spark uses WebRTC to drive its calling capabilities in browsers. What Spark enables is connectivity from web browsers using WebRTC to Cisco video conferencing products.

Cisco took the approach of using H.264, making it work only on Firefox and in future Chrome versions (unless you run the new Chrome 50 from command line with the necessary parameter to enable H.264).

Cisco has also been heavily investing in acquiring and nurturing its WebRTC chops:

  • Tropo acquisition, to get an API and a developer ecosystem for Spark
  • Acano acquisition, which fits perfectly well in offering native browser access to its existing infrastructure
  • Spark fund, with $150M to entice developers to use its APIs

Cisco has a huge ship to steer away from hardware and it is pouring the money necessary to take it there.

Google Hangouts

WebRTC. Chrome. Hangouts. Google. All connected.

Google invested in WebRTC partly for its Hangouts service.

Today, Hangouts is using WebRTC natively in Chrome and uses a plugin elsewhere – until the specific support it needs is available on other browsers.

Google also introduced its Chromebox, its take on the room system. I am not sure how successful Chromebox is, but is refreshing to see it with all the high end systems out there that don’t know a word in WebRTC. It would have been nicer still if it could use any WebRTC service and not be tied to Hangouts.

The problem with Hangouts is its identity. Is it a consumer product or an enterprise product? This is hurting Hangouts adoption.


Lifesize was a Logitech division. It was focused on selling hardware room systems.

In 2014, Lifesize launched its own cloud service, starting to break from the traditional path of only selling on premise equipment and actually offering a video conferencing service.

In 2015, it introduced its WebRTC support, by enabling browsers to join its service via WebRTC – and connect to any room system while doing so.

2016 started with Lifesize leaving from the Logitech mothership and becoming an independent company.

Microsoft Skype

Skype has done nothing interesting until 2015. At least not when it comes to WebRTC. And then things changed.

Skype for Business, Skype for Web and the Skype SDK were all introduced recently.

Skype for Web started off as a plugin, which now runs natively on Microsoft Edge – the same initial steps Google took with Hangouts.

My own take here:

  • Skype is investing in switching its backend and modernize it to fit something like WebRTC
  • This process is taking too long, and probably isn’t coordinated properly
  • It is coming, and it will give Skype a lot of flexibility in where to go and what to do next

Or should I say Mitel?

Polycom added WebRTC support in its launch of RealPresence Web Suite. In traditional enterprise video conferencing fashion, it seems like a gateway that connects the browser to its existing set of products and tools.

At almost the same time, Polycom shed its Israel office, responsible for its MCU. This is telling as to how transformative is WebRTC in this market.


Vidyo had a love-hate relationship with WebRTC throughout the years but has done a lot of work in this space:

2016? Two things already happened this year with WebRTC:

  1. VP9 is now in Chrome and Firefox for WebRTC, with plans of adding SVC to it. This is something that Google and Vidyo are working on together
  2. Vidyo launched their VCaaS and PaaS cloud offerings

In a way, Vidyo is well positioned with its SVC partnership with Google to offer the best quality service the moment Chrome supports VP9/SVC. They also seem to be the only video conferencing vendor actively working on and with VP9 as well as supporting both VP8 and H.264. Others seem to be happy with H.264/VP8 or running after H.265 at the moment.

The New Entrants

There are also some new entrants into this field. Ones that started at the time WebRTC came to being or later. The ones I am interested in here are those that connect to enterprise video conferencing systems.

These include Unify, Pexip, Videxio and many others.

What defines them is their reliance on the cloud, and in many cases the use of WebRTC.

They also don’t “do” room systems. They are connecting to existing ones from other vendors, focusing on building the backend – and yes – offering software connectivity through browsers, plugins and applications.

My room system dreams

I’ll have to wait for my WebRTC room system for a few more years.

Until then, it is good to see progress.

The post How Video Conferencing Vendors Adapt to WebRTC? appeared first on

Scalability, VP9, and what it means for WebRTC

Thu, 04/14/2016 - 12:00

Why and where do we use SVC exactly?

[When Alex Eleftheriadis, Ph.D., the Chief Scientist & Co-founder of Vidyo, approached me about writing a piece about SVC and WebRTC – how could I refuse? Someone had to give the explanation, and what better person than Alex to do that?]

Just when the infamous WebRTC video codec debate appears to have been settled, with both H.264 and VP8 being set as mandatory-to-implement by browsers, VP9 has started making inroads into the WebRTC software stack and into browsers themselves. Indeed, Chrome 48 includes, for the first time, VP9 support for WebRTC. Firefox also includes support for it in WebRTC in the Developer Version of Firefox 46.

Why is this relevant for the WebRTC community – users and developers? First off, VP9 offers significantly better compression efficiency compared with H.264, and even more so compared with VP8. This translates to better quality for the same bit rate, or a lower bit rate for the same quality (as low as 50%). This by itself is a big plus, but it does not tell even half of the story.

The Need for Scalability

When using WebRTC beyond two-way, peer-to-peer calls, or in networks with significant quality problems, system architects are encountering the same design issues that the videoconferencing industry has been dealing with for a long time now. It is not accidental then that WebRTC solutions designed for multi-point video gravitate towards those offered in videoconferencing, or that videoconferencing companies are adapting their systems to become WebRTC solutions. For the latter, this typically entails aligning with transport-level, security, and NAT traversal specifications, and of course providing a JavaScript library that enables WebRTC-enabled browsers to use their system’s facilities.

If we look at today’s architectural landscape for high-quality multi-point video, there are two main designs. One is based on transmission of a single stream of scalable coded video. Scalable means that the same bitstream contains subsets, called layers, that allow you to reconstruct the original at different resolutions. If you get the lowest, or base, layer you can decode the video at a certain resolution, whereas if you also get a higher, or enhancement layer, you can decode the video at a higher resolution. This is great for robustness and adaptability, because you do not need to process the video at all to get at the different resolutions.

The second design is based on simulcast transmission of two separate streams that encode the same video at different resolutions. Contrary to the scalable design, here we have two encoding passes rather than one, with the associated streams requiring a higher bitrate compared with scalable coding. It is also less error resilient. On the plus side, however, simulcast allows the use of older, non-scalable decoders. This has been an important consideration for systems that interface with legacy devices (not relevant for WebRTC).

Single Layer, Scalable, and Simulast Coding of Video. In scalable coding the various layers (“a” and “A”) are multiplexed in a single stream. In simulcast two or more independently encoded streams are produced and are transmitted separately.

Both of these designs utilize a special type of server for which I have coined the term “Selective Forwarding Unit” (SFU). This type of server was not known when the original RTP Topologies RFC was published in 2008 (RFC 5117), but it is now included in its 2015 update, RFC 7667.

The operation of the SFU, using the VidyoRouter as an example. In the diagram the SFU receives three scalable streams, and it selects to forward the full resolution for the blue participant (base and enhancement layers), but only the base layer for the green and yellow participants.

The SFU works in the following way: it receives scalable or simulcast video, and it decides which layer or which stream to forward to a receiving participant. There is no signal processing involved, and the operation incurs very little delay (less than 10 ms is typical). If we contrast this with the traditional architectures that are still being used and involve transcoding of multiple videos, the advantages are obvious – both in terms of processing complexity but also in terms of delay (150 ms delays would be typical for the traditional architectures). Minimizing delay is hugely important for perfecting the end-user experience.

What is interesting is also how the receiving endpoint operates. Contrary to legacy videoconferencing systems, it receives multiple streams that it has to individually decode, compose, and display on the screen. This multi-stream architecture perfectly matches WebRTC’s design.

The multi-stream architecture of an SFU endpoint – the endpoint receives multiple video streams that it has to individually decode, and composite on the user’s screen.

To appreciate the significance of these architectures it suffices to point out that both Skype for Business and Google+ Hangouts use simulcasting (of H.264 and VP8, respectively). So does the open source VideoBridge by Jitsi. Vidyo, which first introduced the concept in its VidyoRouter product in 2008, is using scalability (with H.264 SVC). Simulcast support is now in the scope of the WebRTC 1.0 specification and it is being actively worked upon. Scalable coding is already supported by the ORTC specification, and will be addressed in WebRTC-NV (post 1.0).

Scalability, SVC and VP9

Now we can turn back to our original question regarding scalability and VP9. If you want to be able to use an SFU architecture with scalable coding, the codec itself must support scalability. That’s why back in 2013 Vidyo announced that it would be collaborating with Google to develop a scalable extension for the VP9 codec. This effort is now bearing fruits.

One may ask, “why care about VP9, I will just use whatever stock codec my browser has and be done with it.” The answer is that you do want to care, when quality matters. Depending on the codec used, and the type of multi-point server architecture deployed, the end user will get a vastly different quality of experience.

We can think of the WebRTC endpoint as a kitchen that has a bunch of ingredients. If your expectations are low, you can go for the raw vegetables and have a meal in no time. If you want a fine meal, you will want both the right ingredients as well as the right recipe. The standardization process will ensure that the WebRTC kitchen has all the right ingredients. The recipe and, in fact, the cook, are all part of whoever is offering the service. By taking into account all the realities of imperfect network transmission, heterogeneous clients, mobility, etc., they make sure that the users enjoy a great experience. If you go with a proprietary solution, you can then add plenty of secret sauce.

Endpoint Quality Scale: One ordering of relative quality of different codec and endpoint engine combinations.

Taking into account the different combinations of video codecs and endpoint engines, I put together an “Endpoint Quality Scale” diagram, shown above. You can think of it as the skeleton of the multi-point video kitchen menu. Vidyo is vigorously trying to be the three Michelin star restaurant; its proprietary engine uses a lot of secret sauce in addition to the standard ingredients. But together with the industry as a whole we want to make sure that the menu, especially when it comes to WebRTC, offers something for all tastes and price ranges.

Bottom line, when people select platform providers for their WebRTC-based solutions they need to be aware of these differences and, especially when quality matters, make an educated and well-informed choice. Bon appetit.

The post Scalability, VP9, and what it means for WebRTC appeared first on

You Won’t Find Guesstimates in My WebRTC PaaS Report

Mon, 04/11/2016 - 12:00

Forecasts are overrated.

I’ve been asked time and again things related to the market sizing of WebRTC, and I’ve tried to shy away from it all the time. The Dilbert strip above explains why…

This whole notion of estimating the size of a market that is, to be frank, hard to define, without solid numbers, too new – all lead to the question: why bother?

What are you looking for? The market size of WebRTC contact centers? Is that only for the WebRTC piece of it? Greenfield ones? With or without call widgets in tiny WordPress sites? How do you place the monetary value on it? Is it the WebRTC part or the whole contact center you’re interested in? Do you want the number to amount to a billion $ and go backwards from there so it fits your desired strategy?

All useless.

2 billion users. X% CAGR. 15% YoY growth.


Any day.

With something like WebRTC, such things are close to impossible as far as I can say, and probably not really worth it. Need to throw a number in the air? Generate it randomly.  It’s good enough for the TSA then why not for you?

Which leads me to something you won’t find in my WebRTC PaaS report – the one dealing with the WebRTC API market and assists developers in understanding if they should use a vendor and help picking up the right vendor (if that’s the course selected). These estimates don’t help in such a case. They are worse than useless.

Need estimates? Find some other report online. They will happily share their guesstimates in press releases out there (seen a few lately) so you can decide if it is worth paying for to get that “validation” you need for your management.

Need to make real decisions on how and what to implement? That probably won’t be in these reports.

The post You Won’t Find Guesstimates in My WebRTC PaaS Report appeared first on

Microsoft, Apple and WebRTC in 2016

Thu, 04/07/2016 - 12:00

There’s progress, but the real action will be in 2017.

There has been a lot of chatter lately around Apple’s snail-like progress in supporting WebRTC and Microsoft’s announcements at their BUILD conference. I am still left under-impressed but positive and confident. Here’s why.

Apple and WebRTC

Let’s start with Apple. The only official statement we will get from Apple will be “we have WebRTC”. Question is when, for what and if at all.

We have indications of progress in Apple, and Alex is keeping us updated on the goings with Apple and WebRTC.

I think Itay Rosenfeld  is making a good case why Apple needs WebRTC more than WebRTC needs Apple.

So we know WebRTC is of interest to Apple and we know it is being added to Safari.

We know one more thing. Apple is actually trying to refresh and update its Safari browser. Dare I say “modernize” it. They even recently started a Technology Preview for Safari, joining the rest of the gang of browser vendors to showcase their upcoming plans and intentions. That doesn’t include WebRTC, but WebKit indicates WebRTC as “in development” – and WebKit is the rendering engine used by Safari.

Will Safari include WebRTC? Yes.

When? My guess is end of 2016.

What will it include? WebRTC. H.264. No VPx “nonsense”.

Where? On Mac OS X, but not on iOS. That one will come in 2017.

Microsoft’s Romance with xRTC

Microsoft added ORTC to Edge. I shared my view about Edge already. To sum it up – great browser. No adoption.

To date, there has been little adoption of Edge/ORTC by vendors. If my memory serves me right, adopters include Twilio, &yet and Frozen Mountain. That’s less them impressive. And Microsoft knows that.

The problem here isn’t ORTC. It is Edge. And Microsoft seems to miss that minor detail.

At the recent Microsoft BUILD conference, a few announcement were made (thanks @hcornflower for the tip):

"We now have more than 150 million monthly active devices using Microsoft Edge" — @morris_charles #EdgeWebSummit

— Kenneth Auchenberg (@auchenberg) April 4, 2016

So. “150 million” monthly active devices. But no monthly minutes as in their last disclosure. I wonder what monthly active means and how many of them open it up just to get to IE when Chrome doesn’t work. I know that’s how I use it to get to a Silverlight site that my kid wants to use.

I guess this number was high and positive that the managers at Microsoft decided to focus on it instead of the more important number of average use time per user. This led them to this decision:

MS announces new WebRTC goodies coming to Edge:
H.264/AVC, VP8, MediaRecorder, DTLS 1.2, ECDSA certs

— Justin Uberti (@juberti) April 4, 2016

  1. Adding WebRTC and not ignoring it with an implementation of only ORTC. At long last, they got sense and decided to make it easier for developers to support Edge instead of having developers look at the abysmal market share of Edge. The challenge they face is that people who switch to Windows 10 opt for Chrome over Edge more often than not, and in the enterprise die hards stick with IE. Until this trend changes, there’s a real issue here
  2. Supporting H.264, and not only their interanl H.264UC proprietary codec. This makes sense, as Chrome is adding H.264 and Firefox is already supporting it
  3. VP8 is “under consideration”, so we will have it after H.264. Probably somewhere into 2017. Too late
  4. No VP9. With current development speeds, I can see VP9 getting adopted en mass in many use cases and Microsoft Edge staying behind, with no Edge

It would have been better to just add WebRTC to IE11 in parallel than to entice users to switch altogether to Chrome.

When will vendors need to revisit Edge when it comes to WebRTC? Not before Q4 2016.

Microsoft Skype

Skype is interesting. Late to the market. 300 million active users. A lot, but unimpressive if you compare to the leading consumer communication services that are out there.

Skype for Web is what Google Hangouts did the first two or three years of WebRTC’s existence – took components of the WebRTC implementations, modified it to fit their needs and made a plugin for Hangouts out of it. Until they just made it “native” to the browser when they could.

As written in a recent comment I’ve read – they should have done this 5 years ago, but better late than never.

The more interesting part here is the newly minted Skype SDK. I think this is Skype’s third attempt at an SDK – there may have been more. Previous ones were failures. Not because of lack of adoption, but rather because the way developers were treated. This doesn’t bode well for this round. Especially not if you couple it with the current numbers and the size of Skype.

That said, I can easily see Lync/Skype for Business enterprises adopting the SDK to deal with customer support related requirements, taking a bit of the market from WebRTC PaaS vendors. To go beyond this use case, it will take more effort from Microsoft.

The Microsoft Skype for Web and SDK initiatives need to be viewed in the light of other players as well.

Cisco Spark

Cisco Spark (along with their Telepresence and UC offering) goes head to head against Lync/Skype for Business.

Cisco made several interesting moves lately:

  • Acquired Tropo, to beef its Communication APIs and integrate them with Spark
  • Acquired Acano, which fits nicely into high-end paying customers who use WebRTC
  • Acquired Synata, to offer better search capabilities to Spark, to better compete with Slack
  • Created the Cisco Spark Innovation Fund, and placed $150 million to developers building use cases on top of Spark

That’s a lot of milage to go against Skype for Web and the Skype SDK.

You can easily say that when it comes to publicizing and marketing their investment in communication services and enables, Cisco is ahead of Microsoft.

Google Hangouts

Google Hangouts is a shadow of what it can be when it comes to usage.

As a platform, it has it all. Everything you need to communicate, at a fraction of the cost of other solutions or for free. We use it daily at testRTC – both internally and to host meetings with customers and potential customers. We have no incentive to switch to anything else.

Hangouts adopted WebRTC from the beginning. First by embedding the WebRTC stack into the Hangouts plugin, using the components of WebRTC that it could, until it was able to just use WebRTC natively in Chrome. It still runs as a plugin on other browsers, but I assume that will change when WebRTC will be supported with all of the nuances of Hangouts.

What Hangouts is lacking is the traffic and the APIs to go along with its service. I am assuming Google are aware of it.

Apple FaceTime

Apple has FaceTime. Its proprietary service that should have been standardized at some point.

I’ll be surprised if Apple did anything interesting or serious when it comes to connecting FaceTime to WebRTC or adding an SDK to it. Or god forbid, let the poor people of the world who use Android – or a 5 year old Windows PC, connect to FaceTime.


Slack just added voice support with WebRTC and intends to add video. I’ve written about Slack a few times before, and how WebRTC is a logical investment for them. If they add integration points in their API that can access their real time communication capabilities it might become a very interesting player in the SDK/API space.

The real question in this case: Will a vendor using Slack continue using Skype in the long run?

Facebook and WhatsApp

Facebook Messenger uses WebRTC. WhatsApp somewhat uses it.

Skype has 300 million monthly active users. That’s way smaller than WhatsApp’s billion and Messenger’s 800 million. I am assuming there’s more voice and video calling happening on Skype on average per user than on either Messenger or WhatsApp, but the trend is probably towards Facebook and not Microsoft here.

The reason Facebook is so strong here is their new initiatives towards enabling businesses connect with their user base – the Facebook user base directly, which is the largest social network at the moment. If they want, they can throw in voice or video interactions with an SDK on top of it.

WeChat, LINE, ooVoo and Viber

All have integration points. All heading in multiple directions for monetization. Be it businesses connecting to their user base, market places, digital currency or bots.

Leveraging Skype as an SDK means you want their reach and users base. But all of these messaging plaforms have their user bases in the hundreds of millions of active users as well. They essentially compete over similar mind share and budgets of enterprises.

What’s in store for us in 2016?

More chatter and talks about Apple and Microsoft, but little in the way of progress by developers making use of Edge or Safari WebRTC capabilities. That will wait for 2017.

For Skype, there’s a challenge here, but also an opportunity. They can leverage WebRTC, focus on developers and come with use cases and success stories that will be hard to compete against. Microsoft is doing a lot already in this space, but there’s a lot more they need to be doing when you look at the competition they have.


Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.

Get your Choosing a WebRTC Platform report at a $700 discount. Valid until the beginning of May.

The post Microsoft, Apple and WebRTC in 2016 appeared first on

Messaging is Migrating from the Browser to the Desktop

Tue, 04/05/2016 - 12:00

Messaging is used too much to stay only in the browser.

There seems to be a few conflicting trends going on at the moment:

  • Most people on mobile consume their services through apps they install on the device
  • People don’t install apps on their desktops and laptops anymore. They expect everything (most things?) to be available in the browser
  • A new approach of Progressive Web Applications is on the rise, while at the same time, frameworks like React are becoming trendy
  • Chrome dropping support for their app launcher due to limited use by users – at least from their own experience – people prefer launching their services from inside the browser than let it live on their desktop
  • Mobile (and to some extent web) based messaging is leaving the browsers in favor of apps on desktops and laptops

This last trend is what I want to focus here. When all of the apps we use are now browser web apps on the PC, there are generally two types of apps I still install on my laptop:

  1. Microsoft Office
    • I use Google apps whenever I can, but official documents to most of my customers still necessitate a Word file
    • Oh, and Powerpoint is a lot faster for me to create presentations with than the Google alternative
  2. Developer tools
    • There’s something about development that still doesn’t fit in the browser
    • Oftentimes, I just need things locally or more responsiveness. Can’t explain why. Maybe I am just old fashioned

When it comes to communications, though, I prefer pinning tabs to the browser for the most common tasks I have – or just leave it to my phone. WhatsApp, Slack, Gmail – all get a pinned tab on Chrome for me. Whenever I need to use messaging in other domains (Facebook, LinkedIn, Meetup, Upwork, etc) – I just open a new tab in Chrome “on demand” and then close it once done.

I assume others install apps locally on Windows for things they want to use frequently. Which brings me to two interesting developments from the last year or so:


So we are now taking HTML5 web apps, wrapping them as Windows apps and install them locally.

It probably makes sense for a lot of the enterprise messaging apps – instead of just living inside the browser, be part of the installed set of apps on the desktop. Purists of WebRTC will complain that this is not how its done. Detractors of WebRTC will say it isn’t WebRTC at all. I’ll say it is just another way of using the technology.

If you want to take your own communication web apps and make a desktop application out of them, then the most popular approach these days that I know of is CEF – Chromium Embedded Framework. It takes your web app, and packages it with Chromium so that they both get downloaded and installed together.

I assume that this is what Slack used. I am not sure about the Facebook Messenger one though – the addition of Windows tiles is a complication, but probably solvable.

In a way, web and HTML5 have already took over our desktop. Even in apps what you get is HTML5 these days.

I wonder if and when will this trend hit mobile, and if so, will it be achieved via the new Progressive Web Apps approach.

The post Messaging is Migrating from the Browser to the Desktop appeared first on

Which WebRTC PaaS Vendor is Investing in His Platform?

Mon, 04/04/2016 - 12:00

Not all of them.

Who is investing in its platform?

Twilio. Added a slew of services in 2015.

TokBox. Got a new Spotlight live broadcast service. But not only.

VoxImplant. Added HD to its audio conferencing.

The rest? Not really sure?

Most of the time, when people talk to me about their use case, and the need to pick a specific platform, it boils down to a shopping list of features. They want everything. Usually more than any single vendor can offer. When prodded further, they reduce the need to a small set of requirements. But then again, they do see in their future these added set of features.

In many cases, selecting a vendor means understanding which of them might have what you need in the future down the road in their roadmap – not necessarily in their service today, but they will get there by the time you will.

Guess what – this is another factor that needs to included to the list of requirements you need to look at when selecting a vendor to work with.

This is why in the latest release of my “WebRTC PaaS report”, I am adding a new section, which will give a quick indication to which vendors made changes to their platform (and if these changes were serious or not). The information there will date back two years, giving some perspective.

If you are thinking of stating to use one of the WebRTC API platforms out there and not sure which one to use, then this report may come in handy. Until this next updated release, I’ve taken the price down considerably – if you purchase now you pay $1250 instead of $1950 and you get a year of updates (so that the updated version will be yours next month the moment it gets published).

Check the WebRTC PaaS report page to decide if you need.

The post Which WebRTC PaaS Vendor is Investing in His Platform? appeared first on

DIY or SaaS for Your In-App Messaging?

Tue, 03/29/2016 - 12:00

No easy answer.

What route should your messaging implementation take?

If there’s something I like is to write code. I haven’t done so in years, but it still is my passion. A year or two ago, I’ve done a small coding project for something I needed. After a whole day of coding it dawned on me that I haven’t checked my email, social networks or notifications the whole time – and didn’t even miss it. The only thing these days that can focus me on a single task at a time is programming.

When I did develop, and manage developers, there was always that tension of NIH in the air – the Not Invented Here syndrome that we developers are so good at. We want to develop stuff on our own and not “outsource” it to others. Hell – if I wrote a piece of code a year ago it was crap the next year and had to be rewritten.

I had the chance to listen in to Apigee’s recent webcast on Build vs Buy API Management. See it here:

This webcast goes over a lot of reasoning I see going on in any development project when the decision needs to be building build and buy.

The funny thing is that I don’t hear this kind of a discussion enough when it comes to messaging. Somehow, people think it is trivial.

I took a few of the concepts in this webcast, and “translated” them into the realm of build vs but for messaging.

Limited view of the scope

When a project starts, it seems that adding messaging isn’t that hard. You have a bunch of people. Maybe some presence indication. Run around a few Websocket messages for the text involved in the conversation and you’re done.

But is it really true, or is there more to messaging? It is far from trivial. Even simple things like delivering messages while disconnected or handling push notifications are notoriously hard to get right – even for those who should be the experts in it.

When you define what it is you need to build for your messaging, most often than not, you’ll be doing it with the following “mistakes”:

  • You will have a narrow scope of what is really needed
  • You will focus on the functional part of messaging, but probably a lot less of the other requirements (such as a good backend to understand what your system is doing and how people end up using it)

With limited scope comes the challenge of not comparing the right things when deciding between build or buy.


Every development project is risky. Purchasing an off the shelf solution usually mitigates the risk by having it done by someone else where the payment and deliverables are known in advance.

Developers tend to ignore risk – especially if the project is interesting enough to build. And yes. A distributed, low latency, high efficiency, large scale messaging backend written in Lua or Go is highly interesting.

You are not WhatsApp. Or Netflix

Building your own messaging system is hard. It takes a lot of effort. WhatsApp seems so easy, but getting there is hard.

This shift towards in-app messaging that is occurring means that in most cases, messaging is becoming part of an IT project and not exactly an R&D project. As a company, this means the focus is elsewhere and that messaging is considered a commodity or a non-core technology.

In such cases, there is no real funding for ongoing development, support and maintenance of an in-house DIY messaging framework.

Can open source help?

Sure, but is it at the right level of maturity?

There are a few dozen open source messaging frameworks out there. They probably do the work, but barely.

And the main challenge is that messaging is rapidly changing, which means that whatever is out there today is probably somewhat obsoleted or out of sync with what you need anyway – and getting it to where you need it means more investment on your end. Probably.

To top it all, with most of these open source initiatives, what you’ll find out that they have one main contributor behind them. That contributor is most probably a vendor who is offering support and proprietary modules to take care of commercializing the open source offering. Things like reporting, scaling, maintenance, etc. – all these will fall in the domain of proprietary and payment.

So if the idea from the start was to use open source to refrain from having to negotiate and work with a vendor, where does that lead you down the road? Isn’t it better to acknowledge the fact from the onset and find a suitable solution out of a larger set of available vendors?

Time To Market

I know. I know.

If you write your own messaging system, it will take you the better part of a weekend. Adding a bit of code and stability around it clocks it at a month. Nothing can beat that.

But what is it you are comparing here? Are you concerned about your prototype implementation or is that like production grade we’re talking about?

Getting something to production requires a lot more time.

Why are you even going DIY?

Is it because it will be cheaper?

Because you’ll have more control over your future and destiny?

DIY is going to cost you in time and effort which you don’t necessarily have.

If and when this project of yours going to succeed, you’ll find out that with it more requirements and maintenance work is necessary. But what you’ll also find out is that the budget might not be there for you to handle that extra load in development. You promised the organization a working messaging system, and now that it is working – why are you asking for more funding exactly?



Easy? Hard? Core? Commodity?

I guess in most cases, deciding to develop your own messaging system requires a very good reason.

At testRTC we had that same need, though slightly different. We needed a way to communicate with the browser machines we’re running. It was all fine and well when the number of machines was rather small and their locations were simple. It became a real headache when we grew bigger and when customers started connecting machines in locations with flaky internet connections. We ended up using integrating one of the realtime messaging players for that purpose – and haven’t looked back at it since.

Messaging might seem easy, but it is pretty hard once you get to the details.

So why not outsource it and be done with it?

The post DIY or SaaS for Your In-App Messaging? appeared first on

Everyone and His Dog is Fixing WebRTC

Mon, 03/28/2016 - 12:00

Enhanced. Fixing. Solving. Enterprise grade. Improving. Completing.

I’ve been seeing this too much lately.

Companies decide to market their product as a way to “fix” WebRTC. The gall.

I understand where this comes from. Marketing is a lot about FUD. How to put fear in your potential customer until the only thing left for him to do is buy.

If you look closely, though, none of them really “fixes” WebRTC. The only thing they are doing is using WebRTC in a way that may fit you as a customer.

An example?

Companies who “fix” WebRTC by adding signalling to it. Or adding authorization. Or having it connect to PSTN.

This isn’t about “fixing”. This is about supporting a specific scenario or feature in a product – not even related to WebRTC itself.

Others “fix” WebRTC by having it work on IE (forcing a plugin on the user or using Flash). Again, less about WebRTC, and more about the use case.

And you know what? WebRTC doesn’t offer notifications either – I am sure you can go ahead and “fix” WebRTC by adding push notifications to your app on top of WebRTC!

WebRTC is a very powerful building block, but that’s about all it is – a building block. You’ll need to add additional building blocks to create a solution with it, so no – you aren’t fixing it – you are just implementing your use case with it.


Stop fixing WebRTC. It isn’t broken.

Just focus on solving a real world problem for a real customer and be done with it.

The post Everyone and His Dog is Fixing WebRTC appeared first on

Standards are for Losers

Mon, 03/21/2016 - 12:00

They really truly are.

Whenever someone whines to me that WebRTC isn’t a standard yet so it isn’t ready it makes me laugh. Who the hell cares about such a thing anymore?

The standard is whoever’s got the clout and strength in the market. Ask any marketer – would they want to be able to interact with the carrier’s standardized, federated (and almost non-existent) RCS client to send a message – or would they rather be able to interact with WhatsApp users. The answer, for countries where WhatsApp is popular will be WhatsApp. Marketers don’t care about the standard. The users don’t care about the standard. And most developers don’t care either – as long as the interface is adequately documented.

Enter WebRTC.

No. The IETF hasn’t gone through the motions and finalized the spec yet.

Yes. It might change.

No. I couldn’t care less.

You see, there are already billions of users available to me via WebRTC. There’s source code I can take, compile and run anywhere I want. There’s a vibrant ecosystem of developers and vendors ready to assist. There’s a large and growing number of companies and use cases that make use of WebRTC.

Who am I to say that WebRTC doesn’t exist because someone didn’t put their “standard” stamp on it?

For the last 3 years I’ve been using WebRTC almost daily to communicate with others using various services. I didn’t think for once that this isn’t working because there’s no standard.

Whenever companies band together to create a standard, I begin to question their motive. These days, it usually comes from a point of weakness – a place where there is one (or more) vendors who are strong in a domain and the only way the smaller kids can have a go at it is by specifying a standard to rally all small players to fight the dominant force.

Whenever you see a standard being announced – ask who isn’t there – that’s the one with the power.

In the case of codecs, the MPEG-LA asserts its power and dominance over H.264 and H.265/HEVC for video codecs. Which is why the aomedia was created and announced – to find an alternative codec and win the market back.

The examples are countless.

In the domain of real time communications, everyone were using H.323 or SIP. Then Skype came out, ignoring standards altogether. The industry tried its best to explain that Skype isn’t federated. There’s no standard there. To no avail. So companies (the same ones) tried connecting to Skype, to offer that as part of their service.

The same is happening today with WhatsApp and other social networks. They are so big, that they are the standard.

WebRTC is making the same distinction. It is taking away the hegemony on VoIP from VoIP vendors and putting the weight of this industry on the browser vendors. And now, these vendors are complaining that WebRTC isn’t interoperable. Doesn’t fit their needs. They don’t understand that they are neither in control here nor influencers. They lost control over that part of technology.

This isn’t to say that WebRTC won’t stabilize or get standardized – it is just that it doesn’t matter when it comes to adoption.

Standards? They are for the losers to run after to make sure they get to play the game. The winners don’t really need them.

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

The post Standards are for Losers appeared first on

WebRTC is a Distraction

Mon, 03/14/2016 - 12:00

Had to take this one out of my system.

Just in time for Enterprise Connect, Dave Michels decided to write a post to attract readers. The title? WebRTC is a distraction. It is hard to pin point what’s wrong with the arguments in this one, but most of them are just lacking in knowledge or understanding of this market and how it operates, which is sad – especially coming from Dave who I value very much.

The 4 main reasons why it is a distraction for Dave?

  1. Limited support
  2. Mobile is what really matters
  3. Why bother?
  4. WebRTC is dangerous

Let’s try to dismantle each of these so called arguments one by one. Shall we?

#1 – Limited Support

WebRTC today runs on Chrome and Firefox. Microsoft went for ORTC (=WebRTC) and is now “considering” WebRTC as well.

Apple isn’t there, but frankly – I almost never hear complains about Safari not having WebRTC. For some reason, Mac uses have been trained to use Chrome when needed. Furthermore, there’s work been done at Apple about WebRTC, if you care about rumors.

Add to that the fact that no other solution runs on a browser. No other. None. Zilch. They are all getting thrown out from browsers who are stopping support for plugins, Java and probably Flash in the future. And what else have this amount of support anyway?

Now, you can use WebRTC as a desktop app, using a plugin, through Java – or in whatever other manner people use their comms today – so that limited support is wider than any other alternative to date.

#Doesn’t work for you? Don’t use it. But don’t complain that others are using it and are happy about it.

#2 – Mobile is what really matters

To whom?

And while at it, using WebRTC inside an app makes a lot of sense. You shouldn’t care about the technology – just your customers. If they want apps, give them apps. Wrap WebRTC and be done with it.

There’s no other serious media engine for mobile that can be considered – the price point for it will be too prohibitive as well as the investment made.

Mobile is what really matters, which is why Facebook Messenger uses WebRTC. In both mobile and desktop. And is probably larger in deployment, users, minutes, seconds and engagement than anything else the unified communications market has to show for its huge success in its 10+ years of existence.

You know what? I am tired of waiting for unified communications to happen. It is time we take matters into our own hands (with WebRTC) instead of waiting for these large stale companies to move at a reasonable pace and come up with a workable solution.

#3 – Why bother?

Dave says Google no longer cares or invests in WebRTC. I’d say this can’t be further away from the truth.

Google are heavily invested in WebRTC today, based on the number of new features and changes they bring with every new version of Chrome (which happens every 6-8 weeks as opposed to 12-18 months of the slow vendors Dave asks us to put our trust in).

The pace of change for WebRTC is staggering. Nothing comes close to it.

In the span of a year, we’ve seen the echo canceler getting replaced in WebRTC, VP9 introduced, H.264 is underway, ORTC related APIs getting added and that’s just what I can remember off the top of my head (and really took place in the last couple of months only).

Will Google continue at these breakneck speed? Who knows? For now, I’ll take what I am given – especially for free.

#4 – WebRTC is dangerous

Not sure where to start here.

With Unified Communications and its current cadre of vendors, the issues raised by Dave (things you don’t understand and control coupled with hard to patch and upgrade) are a lot more dangerous.

Do you know when your PBX was upgraded last for that critical security issue it had? Do you even know if it was upgraded at all? What about the router you have at home? This FUD about security in WebRTC wreaks of misundersanding of the technology.

We are living in a world where we move everything to the cloud and our mobile devices. In such a world, security needs to be taken seriously. Not by introducing stupid proprietary solutions that are hard to manage or maintain, but rather by introducing cloud based solutions that can upgrade and update automatically. Ones where security is taken into account from the ground up and not as a bolt on feature to show the buyer.

WebRTC has all that and more, so if you think WebRTC is dangerous – sure it is. To anyone who is trying to compete against the companies using it. In the long run, resistance is futile.

The truth of it

Google doesn’t care about the unified communication market when it comes to WebRTC.

They just couldn’t care less if this does headaches to Cisco or Polycom or anyone else in this market. The way vendors are bitching about WebRTC shows how they view VoIP and UC as their own, as if they are entitled to what goes on there and as if someone needs to think about their business models and legacy deployments so they don’t get hurt.

Get over it.

WebRTC is a huge distraction to those who aren’t built to embrace it. They are going to fade away. Just a matter of time. And Dave – you won’t need to wait much longer for it to happen.


[show promotion title=”strategy-session”]

The post WebRTC is a Distraction appeared first on

Developer Ecosystem Acquisitions Makes Build vs Buy Decisions Harder

Thu, 03/10/2016 - 12:00

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.


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 technologySnapchat 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 ecosystemTokBox’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

WebRTC Multiparty Video Alternatives, and Why SFU is the Winning Model

Mon, 03/07/2016 - 12:00

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


Using the greatness of Parallax

Phosfluorescently utilize future-proof scenarios whereas timely leadership skills. Seamlessly administrate maintainable quality vectors whereas proactive mindshare.

Dramatically plagiarize visionary internal or "organic" sources via process-centric. Compellingly exploit worldwide communities for high standards in growth strategies.

Get free trial

Wow, this most certainly is a great a theme.

John Smith
Company name

Startup Growth Lite is a free theme, contributed to the Drupal Community by More than Themes.