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

Stop Whining about WebRTC Security Threats

Thu, 03/03/2016 - 12:00

It is a waste of time.

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

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

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

A few things about that one:

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

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

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

The things Nissan got wrong here includes:

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

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

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

The bane of security is developers and processes.

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

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

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

Here’s why:

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

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

What more do you want?

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

The post Stop Whining about WebRTC Security Threats appeared first on

Does Google’s Support of RCS Changes Anything for WebRTC?

Mon, 02/29/2016 - 12:00


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

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

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

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

There are two ways to view these questions:

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

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

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

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

How is that different than WebRTC?

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

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

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

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

Will Google stop supporting WebRTC?

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

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

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

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

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

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

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

Join me in London for WebRTC Global Summit

Sun, 02/28/2016 - 14:00

Why don’y we meet in London on April?

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

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

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

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

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

When? 11-12 April

Where? Cavendish Conference Centre, London, UK

Free registration here

I will speak about two topics during the event:

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

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


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

SoftBank’s Adoption of WebRTC Should be a Wake Up Call to Video Conferencing Vendors

Thu, 02/25/2016 - 12:00

Wake up and smell the ashes?

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

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

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

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

Microsoft Skype? Cisco Telepresence? Or Spark? Polycom?

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

It is not only verticals

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

But video conferencing?

And without even a vendor?


Unheard of!

But SoftBank is now doing it.

Why is it important?

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

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

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



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

The Biggest Risk of Building a Business over Messaging Platforms

Tue, 02/23/2016 - 12:00

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

Building house of cards on top of Facebook?

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

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

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

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

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

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

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

  • Websites
  • Mobile Apps
  • Messaging

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

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

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

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

My suggestion?

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


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

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

Different Requirements of Scaling real time video

Mon, 02/22/2016 - 12:00

There’s scaling and then there’s scaling.

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

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

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

#1 – Streams per machine

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

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

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

What is this one good for?

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

But that’s not our only vector of scale.

#2 – Streams per session

How many streams can we “bundle” per session?

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

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

There are, in general, two critical challenges here:

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

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

#3 – Failure diffusion

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

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

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

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

Which leads us to the question –

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

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

When Talking About Scaling…

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


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


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

The Future of WebRTC Live Broadcast

Thu, 02/18/2016 - 12:00

It is in the viewer side.

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

WebRTC Live Broadcast Today

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

How you live broadcast using WebRTC today

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

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

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

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

WebRTC Live Broadcast Tomorrow

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

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

How WebRTC live broadcast will look like tomorrow

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

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

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

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

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

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

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

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

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

Is it worth it?

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

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


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

The post The Future of WebRTC Live Broadcast appeared first on

Are WhatsApp and Messenger competitors or partners in Facebook?

Tue, 02/16/2016 - 12:00

Two messaging services. Focused on consumers. Doing practically the same thing. Do they compete or cooperate under Facebook’s roof?

Messenger and WhatsApp are the biggest messaging platforms toady. Messenger announced 800M monthly active users recently, while WhatsApp celebrated hitting the 1 billion mark. As they both strive to continue with this rapid growth, I have to question – are they joining forces or competing fiercely between themselves.

The reason I raise it stems with how they implemented web support and VoIP:

  • Messenger unbundled from Facebook, opening its own independent site, which acts as a full messenger client. If you want to make calls, you use WebRTC for that
  • WhatsApp created a web frontend tethered to the phone app. It cannot work without the phone nearby. And when it comes to VoIP, it might be using the same codecs as WebRTC, but not the vinyl implementation

They are taking different architectural approaches. But they end up implementing the same feature set.

WhatsApp in 2015

Here’s what WhatsApp did or was rumored to be working in the last year:

Messenger in 2015

Here’s what Messenger did in the last year:


Not much of a difference…

Running such a thing at scale of 100’s of millions of people is painfully hard. Doing that twice under the same roof is even harder:

  • It seems like they develop everything twice or separate infrastructure and architecture.
  • There’s no federation between the two – you can’t send a message from a Messenger user to a WhatsApp user – even though both belong to the same company

Where would each of these services go next for growth?

The above slide from eMarketer shows how in some countries, the main competitor of WhatsApp is Facebook Messenger – and vice versa. I think each of them tries independently to raise his users base – with no real regard of the other’s footprint at any given location.

This one from Activate goes to show how growth for both these platforms come from the same areas – and where they overlap or compete on the same set of users.

Something doesn’t work out here for me, though it is hard to lay a finger on it.

WhatsApp is probably still a strange bird in Facebook, far from the rest of the company and its DNA. Getting it in line with Facebook will take considerably more time.


The post Are WhatsApp and Messenger competitors or partners in Facebook? appeared first on

Would WebRTC be as Big a Thing if it Didn’t Run in a Web Browser?

Mon, 02/15/2016 - 12:00

Probably not.

I wrote about Peer-to-Peer and WebRTC recently, and got this interesting question due to it from Fabian Bernhard on LinkedIn:

Without arguing about the quality of a specific Open Source media stack, would you say that WebRTC was as big a thing if it didn’t run in a web browser?

I guess the answer is no it wouldn’t be that big a thing.

Here’s where I am getting at it. There are two popular slides I usually use:

The one above explains that WebRTC sits at an intersection – it appeals both to VoIP people as well as to Web people.

The second slide above is about what makes WebRTC so transformative – it is about the fact that it is Free, but also because it is available for Web people.

Without the web browser part, we would have been left with only Free.

We’ve had open source media engines before. GStreamer is a popular one. Codecs were a bit harder to come by – especially those that don’t require patent payments (royalty free). It wasn’t the best thing out there, but it worked – people still use it today.

WebRTC made the open source version of a media engine as good as a commercial one – it came out of an acquisition of a commercial media engine vendor after all.

But that’s where it stops – it wouldn’t have made such a transformation in the market – it would be more of the same with a small evolutionary step. Nothing to write home about.

The browser bit, though… that made VoIP available and open to everyone with some HTML and JS experience – a lot larger pool of talent – and one dabbling a lot in experimentation. This is what got us so many use cases.

Mobile might be different

For mobile only use cases, WebRTC would have made all the difference – same as it does today. The idea behind it in mobile isn’t that it offers a browser experience or that it is available in the browser (it isn’t on iOS). The idea is that it would have been the cheapest route to a product than anything else out there. And with the trend of communications moving in-app, that would still make the impact it does there relevant.

Which brings us full circle.

Let’s assume mobile is eating up the world. Let’s assume it is only a matter of time until content creation and not only content consumption moves from the PC to mobile. Once that happens – who cares about what happens in the browser?

It will all be in-app anyway.

And there – WebRTC is making a difference.


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

The post Would WebRTC be as Big a Thing if it Didn’t Run in a Web Browser? appeared first on

WebRTC Use Cases

Thu, 02/11/2016 - 12:00

WebRTC use cases? An endless list of opportunities.

Here are a few, off the top of my head, of use case I’ve came across in the past year or so, where WebRTC was used or seriously planned to be used.

  • Simple video chat
  • Web conferencing
  • International voice calling
  • Receiving a call in the browser
  • Hospital clowns
  • Performing digital art on stage
  • Visiting a museum at night
  • Praying
  • Porn
  • Adult gaming
  • Gaming
  • Doctor visitation
  • Group therapy
  • Jail visits
  • Banking
  • Retail
  • Drug prescription
  • Document signing
  • Live broadcasting
  • Radio stations
  • Music jams
  • Karaoke
  • Gym classes
  • Dance classes
  • Teaching and learning online
  • Expert consulting
  • Contact centers
  • CRM integration
  • Job interviews
  • Virtual classes
  • One on one tutoring
  • Web meetings
  • Webinars
  • Dating
  • Video streaming
  • P2P CDN
  • Private messaging
  • File sharing and sending
  • Assisting hard of hearing people
  • Assisting the blind
  • Assisting people who need live translation
  • Language learning from a tutor
  • Practicing language with native speakers
  • Security cameras
  • Collecting sensor data

Did I miss any WebRTC use cases? Definitely.

What will you do with WebRTC today?

And if you built anything – might as well publicize it on the WebRTC Index.

The post WebRTC Use Cases appeared first on

What’s the Size of Your Messaging app?

Tue, 02/09/2016 - 12:00

Not too big, but not small either.

Here’s a shocker – Facebook Messenger has been updated 19 times on Android in 2016. WhatsApp has had 25 releases in the same time span. And we’re not even in the middle of February.

We are talking about the two messaging applications with the largest number of monthly active users, with WhatsApp surpassing the one billion milestone. gulp.

Should we place messaging apps under weight watchers?

To deliver an app that weighs 26 MB to a billion people (I am thinking WhatsApp here), you end up sending over 23 petabytes of data (translation: a shitload of bits). Doing that 25 times since January 1st…

I took a stab at looking into the consumer messaging apps (some of the enterprise ones are larger, though less frequently updated). Here’s what I found:

#1 – They are all fattening up

The scatter graph above is a bit scattered, but it is easy to see that most apps are increasing in size over time. Since September 2014 until January 2016. They all migrated from the 10-20 MB sizes into the 20-40 MB sizes. That’s a doubling in their weight in less than two years.

We don’t think about it much, but we’re in a serious need of a diet here:

  1. This loads our networks. Not as much as video traffic, but still significant
    • Most users have more than one such app on their phone
    • These apps update frequently
    • It adds up
  2. With WhatsApp reaching the one billion mark, where will it be headed next?
    • To maintain its growth it needs to search for additional users
    • These need to come from developing countries
    • And there, bandwidth and data is scarce
    • The smaller the app, the easier it is on users to handle
  3. Most of the messaging apps don’t seem to care about how fat they are
#2 – Size doesn’t equate feature richness

The bar chart above shows how big the latest version of each of these messaging apps is.

Te results are rater surprising:

  • Skype is the bloated of them all at this point in time, but I don’t remember anything new or interesting that Skype on Mobile introduced in the last two years. And yet – it managed to double its size
  • Those in the vicinity of one billion users/downloads are trying to stay on the skinny size – Facebook Messenger, WhatsApp and Hangouts are all rather small compared to the rest of the pack – and somehow, Facebook Messenger is even smaller than WhatsApp (I’d expect it to be the opposite)
  • WeChat and LINE, which can be seen as e-commerce platforms are larger than most, but somehow Skype and Viber manged to be even bigger

I wonder when a diet will be called for. And maybe it already is.


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

The post What’s the Size of Your Messaging app? appeared first on

Are You Using AppRTC as Your WebRTC Baseline Reference?

Mon, 02/08/2016 - 12:00

If you aren’t using AppRTC yet then you should start.

I had a few customers last month who had quality issues with their service. They were trying to understand the root cause of these issues, and at times, the question raised was “is WebRTC up for the task?”

  • Does the poor audio quality we experience in our service derive from the codec, the browser’s implementation or something in our own backend?
  • Are the video stutters stem from heavy packet loss and that’s just life – or are we adding some of our own issues into the mix?
  • The average bitrate we reach in a call. Is it because the browser is limiting us? Is it because the connection is bad? Is it…

The list goes on.

The fact that now you get a fully implemented media engine in the browser for free is great. The problem is, it gives you (or your developers) the opportunity to blame the browser: It isn’t us. Google’s engineers did such a crap job with X that we just can’t fix it.

More often than not – this won’t be the problem.

When in doubt – check AppRTC

Google launched AppRTC quite some time ago.

AppRTC is Google’s way of showcasing WebRTC in their simplest version of the “Hello World” program. This being WebRTC, there are many moving parts, but to some extent, AppRTC is rather baseline – especially in its dealings with media.

This makes AppRTC a great baseline reference when you have issues with the media paths of your own service or just want something to compare it with.

Got an issue? Test what happens when you run AppRTC and compare it with your own service. If you see that your service isn’t performing in the same manner, chances are the problem is on your end – and now you can start diverting focus and resources towards searching the problem instead of blaming the browser.

Where to look for the problems?

  • Your NAT traversal servers, if they are being used
  • Are you doing any backend processing for the media? Map your pipeline there. Check each step of that pipeline to see if it is to blame
  • Transcoding never fails to fail you – check there if you use it
  • Jitter buffers are notoriously… jittery. Make sure the implementation fits your use case
  • Network routes and handling dynamic bitrates and packet losses might be handled nicely by the browser, but is your backend up for the task as well?
Don’t forget either

Google has another great analysis tool –

You open the settings, insert your own STUN and TURN server configuration – and start the test.

It will then check the system and network connections to give you a nice view of what the browser is experiencing – something you can later use to understand the environment you operate in.

Why is this important?

With WebRTC, it is easy for developers to blame the browser. This isn’t productive.

Your first task should be to create a baseline reference you can trust. One that enables isolating the issues you are experiencing systematically.

AppRTC is a good place to start.

The post Are You Using AppRTC as Your WebRTC Baseline Reference? appeared first on

Join us for Kranky Geek India: March 19

Sat, 02/06/2016 - 08:00

Our next Kranky Geek event is taking place in India.

Kranky Geek events? We did them twice. Both times in San Francisco. Both were very successful events. In both we didn’t know if these are one time gigs or something we want to continue doing.

Then we sat down to plan 2016, and came up with three planned events. The first one is taking place in Bangalore, India.

As with any Kranky Geek, this one is about developers of real time communications.

Like previous Kranky Geek events, it is free to attend. Sponsors take the burden of enabling us to plan this event and then pay for everything around it.

Google has been taking the lead here and helping us a lot in getting these events off the ground – in a way taking the leap of faith in our ability to manage these events.


Google asked us to do an event in India, so we happily obliged. For me, it would be the first time in India, making the excitement on my end even higher.

India makes sense in a lot of ways. Many of the vendors I end up looking are vendors that are local to India. Others are vendors with large development teams in India who end up doing a lot of the WebRTC development. Kranky Geek India gives me personally a great opportunity to meet many of these people in person.

To make things short:

Where? Bangalore, India

Exact location: MLR Convention Center

Date and time: March 19, 11:00 until we finish

How do I register? here


Our sponsors this time are Google, TokBox and IBM. Expect a large cadre of interesting speakers and topics – some local and some international in nature.

I’d love to see you with us at the event!

The post Join us for Kranky Geek India: March 19 appeared first on

Subscribe to the New testRTC Blog

Thu, 02/04/2016 - 12:00

Just making sure you’re not missing out…

If you don’t know, in the last year I’ve been part of a great team of partners. We are building together a WebRTC monitoring and testing service called testRTC. The service is up and running for some time now with an increasing number of customers.

The most crappy part of our service was our website (not the one customers are using, but rather the one potential customers look at). So we updated it recently.

One of the main additions to that website is the new blog there. I’ve got an editorial calendar for it running until March with weekly content that I want to share with you, but felt that isn’t the best of places for it – it was too focused on testing or too related to testRTC.

What will you find in our testRTC blog?
  • Announcements about our service and the versions we are rolling out
  • Useful tips for testers, like the one we published yesterday about .y4m files and Chrome
  • Things we think you should take care of in your testing practices
  • Insights into our design decisions for our internal architecture
  • Test script samples of how testRTC can be used to handle certain WebRTC testing issues

So some of the content will be relevant to everyone while other parts of it for those using testRTC.

Subscribe now and follow us

If this sounds interesting, I suggest you subscribe to our blog or social media link(s):


The post Subscribe to the New testRTC Blog appeared first on

Google Fi, Internet of Things and the Bleak Realities of Telecom Services

Tue, 02/02/2016 - 12:00

Dumb pipe or not, data services thrive mainly out of the telecom world these days.

Can Telecom Services survive the Internet?

Telecom Services are an interesting notion. For over a hundred years we’ve been taught that Telecom Services=Phone calls. Then messaging was added to it in the form of SMS on mobile. Telecom services themselves assume that their role in life is to sell us our communication services.

This is no longer true.

I remember working on 3G-324M. A circuit switched video protocol, now dead to the world at large. In many of my discussions, people complained about their inability to add services on top of what a carrier provided – there were too many layers of debilitating bureaucracies.

Today? Everything operates over an IP network. Most of us don’t even care if it is cellular, landline, wireless, or whatever – as long as we get our bits on the line – we’re happy.

While we are all happy using VoIP services and discussing how disruptive it is to carriers, we haven’t seen nothing yet.

The wheel has turned. In the past, advantage lay in owning the network and offering managed services on top of the network. Today, and moving forward, advantage lay with those who can operate their service across networks.

This means that carriers are left with their own network, and a DNA of working inside their own managed network – something that makes it harder for them to operate in this new reality.

Here are two areas that drive the message home:

#1 – Google Fi

Google Fi is how mobile phones should operate. It is Google being an MVNO and offering mobile plans to its customers. Instead of buying a plan (and maybe a subsidized handset) from a carrier, you can just purchase a plan from Google – and use a Nexus smartphone.

What makes Google Fi so different is that it operates on 3 different networks:

  1. Sprint
  2. T-Mobile
  3. Any Wi-Fi it can get connected to

Read the FAQ for this one – it is quite telling.

Here’s one piece of it:

What happens if I start a call over Wi-Fi and then lose my Wi-Fi connection?
On your Project Fi device, if you start a call over Wi-Fi and then your connection weakens or drops (such as when you leave your home or office), Project Fi seamlessly transitions your call to a cellular network (if one is available) so you can keep talking.

Calling is no longer tied to a cellular network. Fi has 2 cellular network and whatever Wi-Fi you happen to be on. And it decides what to use based on past experience of Google – and is able to change that dynamically mid-call.

Fi is not your typical MVNO. Or your typical VoIP provider. Or your typical carrier.

It is just how things should be.

#2 – Internet of Things

The Internet of Things to me is everything but a carrier. The hint to that is in that first word – Internet. You don’t really need a carrier for that – just an IP connection. Any IP connection.

While there are use cases that will necessitate a carrier (or just his SIM cards?), most of them don’t have a carrier as a prerequisite for their existence.

I like this slide of Octoblu – an IOT platform that was acquired by Citrix:

It shows the various players in the IOT space:

  • IOT frameworks
  • Smartphones (control points of us humans)
  • Embedded devices and sensors
  • Messaging, aggregation and rules engine for all the data flowing around
  • Storage and analytics
  • Applications and integration

Nothing about the underlying network. No one really cares what that ends up being. Which makes sense. For this to work, you need an ubiquitous network. Not necessarily one with high bandwidth or no packet loss – but one that you can assume exist. Which is what we have in most of the modern world now.

Final Thoughts

No. This isn’t the end of carriers.

Yes. They will still make boatloads of money.

Much like electricity is a utility, access to the Internet is a utility.

The services on top of it though? They don’t necessarily belong to the carriers.

The post Google Fi, Internet of Things and the Bleak Realities of Telecom Services appeared first on

First Plugins, then Flash and now Java – WebRTC is now the only alternative

Mon, 02/01/2016 - 12:00

All roads lead to WebRTC.

Java in the browser no longer an option

This started happening in 2015, and is growing as a trend. Half a year ago we witnessed browsers killing off plugins and Flash with a slew of new security issues getting shunned by browsers for a few days.

This left developers with 4 available alternatives for VoIP in a browser:

  1. Flash, with the assumption it is being declining in popularity and support
  2. Plugin, which is getting harder and harder to build and maintain in a way that browsers will support it at all
  3. Java, the promising technology from a decade or two ago that got outdated for frontend browsers, but still available
  4. WebRTC

Oh and there’s this Java Web Start thing, but seriously – you planning on enticing your customers to INSTALL something on his desktop in 2016?

With Flash and Plugin options becoming deprecated as we move further, it seems that Java will be taking the deprecation plunge as well. Oracle just announced they won’t be supporting their Java plugin moving forward.

You are yet again left with WebRTC.

The real implications aren’t for those using WebRTC, but rather those who are trying to support browsers without WebRTC:

  • Up until today, they were two ways of supporting non-WebRTC browsers: Flash or a plugin (Java or other)
  • Flash was always a challenge due to the mismatch in media codecs between Flash and WebRTC, along with crappy echo cancellation
  • Plugins meant you could support WebRTC by wrapping it as a plugin, but this is becoming harder to do with each passing day
  • Java seemed like a good enough alternative:
    • Many organizations had to enable Java in browsers because their internal systems worked with Java applets and programs
    • With Java you could implement WebRTC on the network on your own – there was an implementation or two of this nature
  • The problem is that Java will stop supporting plugins, so if you relied on Java to get WebRTC for you – that route is closing as well

The future of communications is in WebRTC.


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

The post First Plugins, then Flash and now Java – WebRTC is now the only alternative appeared first on

Get Over it: WebRTC isn’t Peer-to-Peer

Thu, 01/28/2016 - 12:00

It is. But it really isn’t.


Still thinking WebRTC = P2P?

There’s so much misunderstanding about WebRTC that it is funny at times. People throw into a conversation sentences like “WebRTC is just peer-to-peer – it can’t do a large conference service like you can with [PLACE-YOUR-COMPANY-NAME-HERE]”.

As with anything else in life, such comparisons are plain wrong. As I always say: WebRTC is just a technology. It is up to you to develop your service on top of it. If that service happens to be a large conferencing service, then why not?

WebRTC being P2P is just as P2P as SIP is. Or H.323. The only difference is that you get to choose your own signaling and your own client. For the first time in history, you get to choose how the topology of your solution will look like from a media and signaling perspective while using a standard specification – and not be bogged down by how people decided to define SIP. Or XMPP. Or whatever.

I had a call with a customer recently. A question that was asked during that call is do I see anyone using WebRTC in mobile just because of cost inefficiencies – not because there’s a browser requirement hiding somewhere in there. The immediate answer I gave was “definitely”. Followed with a few examples to show the point.

WebRTC is P2P? WebRTC is for browsers only? WebRTC only works in Chrome and Firefox?

There are two ways to think of WebRTC:

  1. A standard specification with a default implementation in browsers
  2. An open source media engine

If you miss that second option of open source media engine then you are missing out on a lot of the use cases out there that are based on WebRTC.

The same applies for server implementations.

There are 3 main components to a WebRTC deployment on the server side:

  1. Signalling – how do you get the WebRTC clients connected in the first place?
  2. NAT traversal – STUN and TURN needs to be mediated
  3. Media processing

The first two are mandatory. You’ll have them in all production services with WebRTC no matter what. The media processing one is a bit less obvious, but it is necessary in many use cases. I’ve touched this briefly recently on a post on Dialogic’s blog – oftentimes, you’ll need a server. Be it for recording, multiparty or something else. When that time comes – it isn’t that WebRTC doesn’t cut it for the job because it is P2P – it is that you’ll need to search beyond Google for a solution.

And when you search beyond Google, there are tons of different alternatives:

  • DIY from Google’s WebRTC open source stack (or by other means)
  • Open source frameworks and SDKs, with and without paid support options
  • Commercial products, hardware and software based
  • Commercial SaaS offerings for specific media components
  • Commercial SaaS offerings for the whole shebang
  • You can build/integrate it with your own developers or use outsourced developers or software houses

Next time someone dismisses WebRTC for his project because it is only peer-to-peer – tell them to check his initial hypothesis so he won’t miss out on some of the options he has available to him.


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

The post Get Over it: WebRTC isn’t Peer-to-Peer appeared first on

Facebook and the Future of Messaging

Tue, 01/26/2016 - 12:00

Messaging is a platform.

We’re used to messaging. All of us. SMS has been around for ages. And it feels like iMessage, WhatsApp and Facebook messenger were here in the last few decades as well – they are so ingrained in how so many of us behave that we fail to even acknowledge how new they are.

For those of us who have VoIP in their veins – who learned, worked and breathed VoIP in the beginning of the second millennium, messaging is just an extension of VoIP. A buddy list, with the ability to send a message to a buddy.

Some even believe you can charge for messages (RCS – I am looking at you).

The truth of the matter is, that today, messaging is free. It is an expected “utility”, where money is made elsewhere. Facebook spent countless of billions to own WhatsApp – a messaging service with boatloads of users and little by way of features and bells and whistles. Oh – and in most cases and places, WhatsApp never charge its users for the system, and now, it probably never will.

Facebook released earlier this month their “vision” for Messenger in 2016, and Josh Constine did a nice review of it on TechCrunch.

For me, these are the things that are important from these two posts:

  1. That whole phone number replacement thing
    • Is irrelevant in many cases
    • It might work. It might not
    • But that’s not where the action or money is anyway
    • The future is in messaging services that may acknowledge the phone number but don’t rely on it alone
  2. The business model is in the business
    • Messaging services doesn’t rely on consumers to pay. They rely on having a huge active subscribers base – attracting businesses to pay for the opportunity to interact with the users. Facebook is headed there. WhatsApp announced going there. WeChat is already there
    • This means having an API, a market place/discoverability, good integration points
  3. B2C conversations
    • Should you build a website for your company? A smartphone app?
    • Maybe it needs to be embedded into the messaging services your customers are using instead?
    • And if it is, will it be as brand pages, or just direct messaging to users?
    • For the most part, messaging platforms will end up connecting people not only to other people, but to businesses and maybe even devices (for those of us in love with IOT concepts)
  4. Artificial intelligence and messaging bots
    • Everyone is headed there in the past couple of months for some reason
    • Most don’t know what it means
    • I can’t say I grok it to the level I wish that I did
    • For me, this is about bringing a Siri/Cortana/Google Now like experience into the messaging platform
  5. Delighting users
    • Focusing only on the job-to-be-done of the platform isn’t enough
    • Rationalizing a great UX and putting a polished design isn’t enough
    • Users need to enjoy the service – it is about experiences for them – even in a work environment
    • Here’s how Slack does it – which is a lot more telling than the Facebook examples



Messaging is a lot more than messaging and signaling protocols these days. It is less about the underlying network technology and more about business aspects and usability. It takes away a lot of the power and ego out of the VoIP guys. Just like that, they don’t really know what should be in their core competency. I come from this VoIP background, and I need to struggle with it daily.

What are your messaging plans for 2016?


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

The post Facebook and the Future of Messaging appeared first on

What are the Challenges of DIY your WebRTC SFU?

Mon, 01/25/2016 - 12:00

S doesn’t stand for Simple in SFU.

What are you doing about your WebRTC SFU requirements?

I have noticed recently that more and more companies are attempting the creation of their own SFU. SFU stands for Selective Forwarding Unit, and it is by far the most popular and cost efficient architecture today for multiparty video with WebRTC. With it, all participants send their video to a single entity (usually in multiple resolutions/bitrates), and that single entity decides (selectively) how to route the incoming video to all the participants.

One such popular framework is the Jitsi Videobridge.

Up until today, an SFU for WebRTC was rather simplistic. You had VP8 to contend with as a developer but that’s about it. Life was good. You built your service and mostly whined about incompatibility between browsers.

Things have changed.

Here are a few things that you need to take into consideration when you either build your own WebRTC SFU or adopt/acquire one from others:

  • Do you use VP8 or VP9 in your SFU?
    • Google is already adding VP9 to Chrome
    • How long will it take until it catches on for some use cases?
    • VP9 is a better codec, so why not use it?
  • Can it support multiple codecs simultaneously?
    • Before the end of this year, we will have VP8, VP9 and H.264 available to us in browsers
    • Not all browsers will support them all
    • VP8 seems like the lowest common denominator at the moment
    • This may change to H.264 when Microsoft Edge and Chrome support it though
    • An SFU supporting only VP8 will start looking old pretty fast – and won’t work on Edge
    • Staying in H.264/VP8 land will not perform as well as VP9 in terms of perceived quality for the users
    • So it would be beneficial to be able to use whatever is available at the best possible quality
    • Which makes it a lot more complex for an SFU – more decisions to make with more data points to take into consideration
  • Mobile
    • Mobile doesn’t like multiple, simultaneous video decoders
    • Especially not when this is hardware accelerated – not all smartphone hardware can work this way
    • For mobile devices, you just might want to select a single video stream to send it – or combine multiple video streams to a single one (which looks more like an MCU, but who cares?)
  • Broadcast
    • In many new use cases, people want to have multiple participants chatting, but many more passively viewing
    • Can an SFU scale there? And if it can’t, what will you do instead?


Like any other technology, once you get down to it, there’s more to do than the proof of concept. Consider these aspects at the beginning of your project – and not when you need to seriously rethink your architecture.


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

The post What are the Challenges of DIY your WebRTC SFU? appeared first on

Messaging. Federated? Silo? Does it Matter with an API and Bots?

Tue, 01/19/2016 - 12:00

Nobody cares anymore.

Nobody cares if you are a silo or federated as long as you’ve got an API

It used to be important. Interoperability. Federation. Communication across networks, devices and vendors. All useless now.

We’ve got our lowest common denominator: IP, HTTP – the web. We have our point of federation/aggregation – they now call it the home screen of a smartphone.

People got all riled up on my blog last week something about Wire needing to federate – check the comments. My view? Federating wouldn’t move an inch in their user’s base needle.

Today’s openness and messaging is all about being the platform and enabling others to connect to you. How is that achieved? By way of APIs. And by this new stupid word – “Bots” – which most probably stands for automation.

Why is Bots stupid? Because it just means using the API in a certain fashion.

Back to Messaging.


If you have a service. What happens if it is a silo?

You gain users to it. Slowly or faster. Doesn’t matter that much (though it probably does to you).

One day you want to add more utility to the service – some stickiness – making sure people don’t leave. So you add features. But you understand at some point that going it alone won’t move you fast enough, so you open it up to external developers and services.

You publish an open API.


Federation you say? You make your service accessible to other networks by interacting with them using the same protocol?


But what does that give you exactly? Same set of features you have, give or take a feature or two. Same utility. No stickiness. No differentiation. Not enough.

So you again wish to add features, but getting out of the core you’ve federated just places you in the position of proprietary features. And again you’ll one day understand it isn’t enough. Faster “innovation” and growth are required on that front – you can’t cater all of your customers’ needs. So you… open up! Slap an API on top of your service.

No one cares

Two alternatives. Same end result.

Time to move on. Nothing here to see.

Just make sure you have a solid infrastructure – and an API on top of it for others to integrate with.


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

The post Messaging. Federated? Silo? Does it Matter with an API and Bots? 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.