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

The Day Adobe Adds WebRTC is the Day we Kill Flash

Thu, 08/06/2015 - 12:00

Adobe Migrating to WebRTC?

The company behind the abomination called Flash? Adobe.

The logic then, is that when Adobe moves to WebRTC, there’s no reason anymore to try and run real time communications related use cases with Flash. Correct?

Well… it is already happening.

Guillaume Privat, Director and General Manager of the Adobe Connect business unit, spilled the beans: Adobe Connect “plans to be ready to support HTML5″ “when WebRTC matures”.

AT&T. Cisco. Microsoft. Comcast. Facebook. And now Adobe. An interesting 2015.

Some thoughts about this partial announcement by Adobe (read it all – it is short and rather interesting):

  • Why did Adobe go with WebRTC?
    • The promise of HTML5 content working across desktops and mobile devices
    • Portability – cross platform development and deployment
    • The same thing I always say – if you plan on developing any communication service these days, WebRTC needs to be your first choice and the question should by why you haven’t picked it
  • Their future plans are broad, and rather simplistic – use HTML5/WebRTC wherever to bring feature compatibility to what Adobe Connect is capable of today
  • Somehow, Adobe places WebRTC as an immature technology. While I see this type of thinking in many places, I believe it is short sighted at best. Those who deem it immature probably aren’t wielding it correctly
  • Worse – maturity in WebRTC means “once HTML5 can support large scale collaboration across browsers”
    • Will Microsoft Edge imminent support of it enough?
    • Will Adobe wait until benevolent Apple introduces WebRTC in Safari?
    • Will Adobe be adamant that WebRTC must run on the older Internet Explorer browsers before it is mature enough for Adobe?
    • Or is there some other arbitrary rule at play? Maybe the development time inside Adobe Connect’s team?
  • The context of the announcement is odd
    • It resides on a blog that talks about use cases deployed by Adobe Connect and features introduced
    • This announcement is neither
    • It says “we know there’s WebRTC and we plan on using it. One day. When we think it is time. Maybe. If we get there. And browsers support it”
    • Not sure how should I respond to it. Should I use Adobe Connect now that I know they plan on using WebRTC in some far flung future? Should I sit and wait until they do? Should I rejoice? Should I be worried about my existing Adobe Connect integration?

At least we have another incumbent openly validate WebRTC as a technology. I wonder when the rest of the ostriches burying their head in the sand out there will also come to their senses.

Adobe is abandoning Flash. Shouldn’t you be doing the same?

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

The post The Day Adobe Adds WebRTC is the Day we Kill Flash appeared first on

Should WebRTC Data Channels be Explicitly Approved by the User?

Mon, 08/03/2015 - 10:00

I don’t think so.

There have been at of chatter lately about the NY Times and local IP address use. A rather old Mozilla bug got some attention due to it, with some interesting comments:

Daniel Roesler #106:

I’ve said this before and I’ll say it again. Data channels should require user consent just the same as video and audio (getUserMedia). I haven’t yet heard a good reason on why a silent P2P data channel connection is required.

Eric Rescorla #116:

We are considering adding an extension to restrict the use of WebRTC but are still studying what would be most effective.

Zack Weinberg (:zwol) #117:

I would like to second this observation. I have not attempted to dig into the details of the spec, but it *sounds* like the entire problem goes away if creating any sort of channel requires explicit user authorization.

The rants go on.

What they all share in common? Leak of IP addresses is wrong and shouldn’t be done. Not without a user’s consent.

I’d like to break the problem into two parts here:

  1. IP leakage
  2. Consent
IP leakage

The issue of leaking a local IP address is disconcerting to some. While I understand the issue for VPN configurations, I find it a useless debate for the rest of us.

My own local IP address at the moment is Feel free to store this information for future dealings with me. Now that you know it – have you gained anything? Probably not.

Oh, and if you have a mobile phone, you probably installed a bunch of apps. These apps are just as complex as any web page – it connects to third parties, it most likely uses an ad network, etc. How hard is it to get the local IP address inside an app and send it to someone else? Do you need special permissions to it? Do users actually approve it in any way? Do you think the NY Times app uses this for anything? How about Candy Crush? Or Angry Birds?

Local IPs are compromised already. Everywhere. They are easy to guess. They are easy to obtain in apps. Why is the web so different? And what huge secret do they store?


When someone wants access to my camera, microphone or screen – I understand the need for consent. I welcome it.

But when it comes to the data channel I am not so sure. There are differences here. My thinking about it runs in multiple paths.

1. Content

Microphone, Camera and Screen actually give new data to Java Script code to work with. The Data Channel is a transport and not the data itself.

The browser doesn’t ask permission to download 50+ resources from a web page when we only asked for the web page. It doesn’t ask for permission when 40+ of these resources are located at other domains than the one that we asked for. It doesn’t ask for permission when a web page wants to open a WebSocket either. It doesn’t ask for permission when a web page tries to generate other bidirectional methods to connect to our browser – SSE or XHR – it just runs it along.

As we are trying to protect content, permission on the data channel level seems unnecessary.

If we want to protect local IP address exposure, we should find other means of doing that – or accept that in many use cases, they aren’t worth the protection.

2. User experience

For a video call, a request to allow access is fine – there’s a human involved. But for a programmatic interface that’s a bit of an overkill. With many WebRTC data channel use cases targeting CDN augmentation or replacement, would users be willing to take the additional approval step? Would content providers be willing to take the risk of losing customers?

Let’s assume GIS and mapping on the internet adopts the WebRTC data channel – similar to what PeerMesh are doing. Would you be happy with the need to allow each and every web page that has a Google Map on it to have access to the data channel?

Would you want your games to ask you to allow connecting to others when switching to multiplayer?

Do you want Akamai (a CDN) powered websites to ask you to allow them to work to speed up page loads?

This doesn’t work.

Stop thinking about the data channel as a trojan horse – it is just another hammer in our toolbox.

3. Web trends

In many ways, we are at a phase where we are trying to decentralize the web – enabling browsers to reach each other and to dis-intermediate the servers from the communications. FireChat is doing it for awhile now, but they are far from being alone in it.

This kind of decentralization cannot work properly without letting browsers chat sideways instead of via web servers. While we may want in the future to make such connections as low level TCP and other network building blocks, this isn’t the case today.

We need to find other solutions than placing a permission request on every data channel we try opening.

Why is it important?

We need to be able to distinguish between FUD and reality.

Data channels by themselves aren’t a threat. They may change the way browsers operate on the network level, which may expose vulnerabilites, but the solution shouldn’t be disabling data channels or putting manual roadblocks to them on the browser – it should be in better architecting the solution around them.

As WebRTC grows and matures, these issues will be polished out. For now, I still believe WebRTC is the most secure VoIP technology out there to build your services. Trust, on the other hand, will always depend on the web service’s developers.

The post Should WebRTC Data Channels be Explicitly Approved by the User? appeared first on

WebRTC Monitoring: Do you Monitor your Servers or Your Service?

Thu, 07/30/2015 - 12:00

WebRTC monitoring the right way.

When we started out developing testRTC, what we had in mind is a service that helps QA people test their service prior to heading to production. We’ve built a sleek webapp that enables us to simulate virtually any type of a WebRTC use case. Testers can then just specify or record their script and from there run it and scale it in their tests using testRTC. What we quickly found out was that some were looking for a solution that helps them monitor their service as opposed to manually (or even automatically and continuously) testing their latest build.

The request we got was something like this: “can you make this test we just defined run periodically? Every few minutes maybe? Oh – and if something goes awfully wrong – can you send me an alert about it?”

What some realized before we did was that the tests they were defining can easily be used to monitor their production service. There reasoning behind this request is that there’s no easy way to run an end-to-end monitor on a WebRTC service.

The alternatives we’ve seen out there?

  • Pray that it works, and wait for a user to complain
  • Using Pingdom to check that the domain is up and running and that the server is alive
  • Using New Relic or its poor man’s alternative – Nagios – to handle application monitoring. It boils down to testing that the servers are up and running, CPU and memory load look reasonable and maybe a bit of your server’s metrics

But does that mean the service is up and running, or just that the machines and maybe even processes are there? In many cases, what IT people are really looking to monitor is the service itself – they want to make sure that if a call is made via WebRTC – it actually gets through – and media is sent and received – with a certain expected quality. And that’s where most monitoring tools break down and fail to deliver.

This is why a few weeks ago, we’ve decided to add WebRTC monitoring capabilities to testRTC. As a user, you can set it up by defining a test case, indicate from where in the world you want it to run, define the intervals to run it along with thresholds on quality. And that’s it.

What you’ll get is a continuously running test that will know when to alert you on issues AND collect all of the reports. For all calls. The bad ones and the good ones. So you can drill down in post mortem to see what went wrong and why.

If you need something like this, contact us on testRTC – the team would love to show you around our tool and set you up with a WebRTC monitor of your own.


Test and Monitor your WebRTC Service like a pro - check out how testRTC can improve your service' stability and performance.

The post WebRTC Monitoring: Do you Monitor your Servers or Your Service? appeared first on

Who Needs WebSockets in an HTTP/2 World?

Tue, 07/28/2015 - 12:00

I don’t know the answer to this one…

I attended an interesting meetup last month. Sergei Koren, Product Architect at LivePerson explained about HTTP/2 and what it means for those deploying services. The video is available online:

One thing that really interest me is how these various transports are going to be used. We essentially now have both HTTP/2 and WebSocket capable of pretty much the same things:

HTTP/2 WebSocket Headers Binary + compression Binary, lightweight Content Mostly text + compression Binary or text Multiplexed sessions Supported Supported Direction Client to server & server push Bidirectional

What HTTP/2 lacks in binary content, it provides in compression.

Assuming you needed to send messages back and forth between your server and its browser clients, you’ve probably been considering using HTTP based technologies – XHR, SSE, etc. A recent addition was WebSocket. While the other alternatives are mostly hacks and workarounds on top of HTTP, a WebSocket essentially hijacks an HTTP connection transforming it into a WebSocket – something defined specifically for the task of sending messages back and forth. It made WebSocket optimized for the task and a lot more scalable than other alternatives.

With HTTP/2, most of the restrictions that existed in HTTP that required these hacks will be gone. This opens up the opportunity for some to skip WebSockets and stay on board with HTTP based signaling.

Last year I wrote about the need for WebSockets for realtime and WebRTC use cases. I am now wondering if that is still true with HTTP/2.

Why is it important?
  • BOSH, Comet, XHR, SSE – these hacks can now be considered legacy. When you try to build a new service, you should think hard before adopting them
  • WebSocket is what people use today. HTTP/2 is an interesting alternative
  • When architecting a solution or picking a vendor, my suggestion would be to understand what transports they use today and what’s in their short-term and mid-term roadmap. These will end up affecting the performance of your service


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

The post Who Needs WebSockets in an HTTP/2 World? appeared first on

WebRTC Basics: How (and Why) WebRTC Uses your Browser’s IP Address

Mon, 07/27/2015 - 12:00

To reach out to you.

I’ve been asked recently to write a few more on the topic of WebRTC basics – explaining how it works. This is one of these posts.

There’s been a recent frenzy around with the NY Times use of WebRTC. The fraud detection mechanism for the ads there used WebRTC to find local addresses and to determine if the user is real or a bot. Being a cat and mouse game over ad money means this will continue with every piece of arsenal both sides have at their disposal, and WebRTC plays an interesting role in it. The question was raised though – why does WebRTC needs the browser’s IP address to begin with? What does it use it for?

To answer, this question, we need to define first how the web normally operates (that is before WebRTC came to be).

The illustration above explains it all. There’s a web server somewhere in the cloud. You reach it by knowing its IP address, but more often than not you reach it by knowing its domain name and obtaining its IP address from that domain name. The browser then goes on to send its requests to the server and all is good in the world.

Now, assume this is a social network of sorts, and one user wants to interact with another. The one and only way to achieve that with browsers is by having the web server proxy all of these messages – whatever is being sent from A to B is routed through the web server. This is true even if the web server has no real wish to store the messages or even know about them.

WebRTC allows working differently. It uses peer-to-peer technology, also known as P2P.

The illustration above is not new to VoIP developers, but it has a very important difference than how the web worked until the introduction of WebRTC. That line running directly between the two web browsers? That’s the first time that a web browser using HTML could communicate with another web browser directly without needing to go through a web server.

This is what makes all the difference in the need for IP addresses.

When you communicate with a web server, you browser is the one initiating the communication. It sends a request to the server, when will then respond through that same connection your browser creates. So there’s no real need for your browser to announce its IP address in any way. But when one browser needs to send messages to another – how can it do that without an IP address?

So IP addresses need to be exchanged between browsers. The web server in the illustration does pass messages between browsers. These messages contain SDP, which among other things contains IP addresses to use for the exchange of data directly between the browsers in the future.

Why do we need P2P? Can’t we just go through a server?

Sure we can go through a server. In fact, a lot of use cases will end up using a server for various needs – things like recording the session, multiparty or connecting to other networks necessitates the use of a server.

But in many cases you may want to skip that server part:

  • Voice and video means lots of bandwidth. Placing the burden on the server means the service will end up costing more
  • Voice and video means lost of CPU power. Placing the burden on the server means the service will end up costing more
  • Routing voice and video through the server means latency and more chance of packet losses, which will degrade the media quality
  • Privacy concerns, as when we send media through a server, it is privy to the information or at the very least to the fact that communication took place

So there are times when we want the media or our messages to go peer-to-peer and not through a server. And for that we can use WebRTC, but we need to exchange IP addresses across browsers to make it happen.

Now, this exchange may not always translate into two web browsers communicating directly – we may still end up relaying messages and media. If you want to learn more about it, then check out the introduction to NATs and Firewalls on webrtcHacks.


Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post WebRTC Basics: How (and Why) WebRTC Uses your Browser’s IP Address appeared first on

Will Patents Kill H.265 or Will H.265’s Patents Kill WebRTC?

Thu, 07/23/2015 - 12:00

To H.265 (=HEVC) or not to H.265? That is the question. And the answer will be determined by the browser vendors.

I gave a keynote at a UC event here in Israel last week. I really enjoyed it. One of the other speakers, made it a point to state that their new top of the line telepresence system now supports… H.265. And 4K. I was under impressed.

H.265 is the latest and greatest in video compression. Unless you count VP9. I’ve written about these codecs before.

If you think about WebRTC in 2016 or even 2017, you need to think beyond the current video codecs – H.264 and VP8. This is important, because you need to decide how much to invest in the media side of your service, and what implications these new codecs will bring to your architecture and development efforts.

I think H.265 is going to have a hard time in the market, and not just because VP9 is already out there, streamed over YouTube to most Chrome and Firefox browsers. It will be the case due to patents.

In March this year, MPEG-LA, the good folks counting money from H.264 patents, have announced a new patent pool for HEVC (=H.265). Two interesting posts to read about this are Jan Ozer‘s and Faultline‘s. Some things to note:

  • There currently are 27 patent holders
  • Over 500 essential patents are in the pool
  • Not everyone with patents around H.265 have joined the pool, so licensing H.265 may end up being a nightmare
  • Missing are Google and Microsoft from the patent pool
  • Missing are also video conferencing vendors: Polycom, Avaya and Cisco
  • Unit cost for encoder or decoder is $0.20/unit
  • There’s an annual cap of $25M

What does that mean to WebRTC?

  • Internet users are estimated above 3 billion people and Firefox has an estimated market share of around 12%. With over 300 million Firefox users, that places Mozilla way above the cap. Can Mozilla pay $25M a year to get H.265? Probably not
  • It also means every successful browser vendor will need to shell these $25M a year to MPEG-LA. I can’t see this happening any time soon
  • Google has their own VP9, probably with a slew of relevant patents associated with it. These will be used in the upcoming battle with H.265 and the MPEG-LA I assume
  • Microsoft not joining… not sure what that means, but it can’t be good. Microsoft might just end up adopting VP9 and going with Google here, something that might actually look reasonable
  • Apple being Apple, if they decide to support WebRTC (and that’s still a big if in 2015 and 2016), they won’t go with the VPx side of the house. They will go with H.265 – they are part of that patent pool
  • Cisco isn’t part of this pool. I don’t see them shelling $25M a year on top of the estimated $6M they are already “contributing” for OpenH264 towards MPEG-LA

This is good news for Google and VP9, which is the competing video technology.

When we get to the WebRTC wars around H.265 and VP9, there will be more companies on the VP9 camp. The patents and hassles around H.265 will not make things easy:

  • If WebRTC votes for VP9, it doesn’t bode well for H.265
    • WebRTC is the largest deployment of video technology already
    • Deciding to ignore it as a video codec isn’t a good thing to do
  • If WebRTC votes for H.265, unlikely as it may seem, may well kill standards based high quality video support across browsers in WebRTC
    • Most browsers will probably prefer ignoring it and go with VP9
    • Handsets might go with H.265 due to a political push by 3GPP (a large portion of the patent owners in H.265 are telecom operators and their vendors)
    • This disparity between browsers and handsets won’t be good for the market or for WebRTC

The codec wars are not behind us. Interesting times ahead. Better be prepared.


Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post Will Patents Kill H.265 or Will H.265’s Patents Kill WebRTC? appeared first on

Is Microsoft Edge Going to be the Best Browser Around?

Tue, 07/21/2015 - 12:00

The newest game in town.

Apple’s Safari. Haven’t used it so can’t say anything. Just that most people I know are really comfortable using Chrome on Macs.

Chrome? Word’s around that it is bloated and kills your CPU. I know. On a machine with 4Gb of memory, you need to switch and use Firefox instead. Otherwise, the machine won’t survive the default tabs I have open.

Firefox? Hmm. Some would say that their Hello service is bloatware. I don’t really have an opinion. I am fine with using Firefox, but I prefer Chrome. No specific reason.

From a recent blog post from Microsoft, it seems like Microsoft Edge is faster than Chrome:

In this build, Microsoft Edge is even better and is beating Chrome and Safari on their own JavaScript benchmarks:

  • On WebKit Sunspider, Edge is 112% faster than Chrome
  • On Google Octane, Edge is 11% faster than Chrome
  • On Apple JetStream, Edge is 37% faster than Chrome

Coming from Microsoft’s dev team, I wouldn’t believe it. Not immediately. Others have slightly different results:

Here’s the rundown (click on an individual test to see the nitty-gritty details):

Some already want to switch from Chrome to Edge.

Edge is even showing signs of WebRTC support, so by year end, who knows? I might be using it regularly as well.

Edge is the new shiny browser.

Firefox is old news. Search Google for Firefox redesign. They had a major one on a yearly basis. Next in line is their UI framework for extensions as far as I can tell.

Safari is based on WebKit. WebKit was ditched by Google so Chrome can be developed faster. As such, Chrome is built on the ashes of WebKit.

Internet Explorer anyone?

Edge started from a clean slate. A design from 2014, where developers thought of how to build a browser, as opposed to teams doing that before smartphones, responsive design or life without Flash.

Can Edge be the best next thing? A real threat to Chrome on Windows devices? Yes.

Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post Is Microsoft Edge Going to be the Best Browser Around? appeared first on

Now That Flash and Plugins are out the Door, What’s Holding you from Adopting WebRTC?

Mon, 07/20/2015 - 12:00

All routes are leading towards WebRTC.

Somehow, people are still complaining about adoption of WebRTC in browsers instead of checking their alternatives.

Before WebRTC came to our lives, we had pretty much 3 ways of getting voice and video calling into our machines:

  1. Build an application and have users install it on their PCs
  2. Use Flash to have it all inside the browser
  3. Develop a plugin for the service and have users install it on their browsers

We’re now in 2015, and 3 (again that number) distinct things have changed:

  1. On our PCs we are less tolerant to installing “stuff”
    • As more and more services migrate towards the cloud, so are our habits of using browsers as our window to the world instead of installed software
    • Chromebooks are becoming popular in some areas, so installing software is close to impossible in them
  2. Plugins are dying. Microsoft is banning plugins in Edge, joining Google’s Chrome announcement on the same topic
  3. Flash is being thrown out the window, which is what I want to focus about here

There have been a lot of recent publicity around a new round of zero day exploits and vulnerabilities in Flash. It started with a group called The Hacking Team being hacked, and their techniques exposed. They used a few Flash vulnerabilities among other mechanisms. While Adobe is actively fixing these issues, some decided to vocalize their discontent with Flash:

Facebook’s Chief Security Officer wants Adobe to declare an end-of-life date for Flash.

It is time for Adobe to announce the end-of-life date for Flash and to ask the browsers to set killbits on the same day.

— Alex Stamos (@alexstamos) July 12, 2015

Mozilla decided to ban Flash from its browser until the recent known vulnerabilities are patched.

Don’t get me wrong here. Flash will continue being with us for a long time. Browsers will block Flash and then re-enable it, dealing with continuing waves of vulnerabilities that will be found. But the question then becomes – why should you be using it any longer?

  • You can acquire camera and microphone using WebRTC today, so no need for Flash
  • You can show videos using HTML5 and MPEG-DASH, so no need for Flash
  • You can use WebGL and a slew of other web technologies to build interactivity into sites, so no need for Flash
  • You can run voice and video calls at a higher quality than what Flash ever could with WebRTC
  • And you can do all of the above within environments that are superior to Flash in both their architecture, quality and security

Without Flash and Plugin support in your future, why would you NOT use WebRTC for your next service?


Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post Now That Flash and Plugins are out the Door, What’s Holding you from Adopting WebRTC? appeared first on

What I Learned About the WebRTC Market from a Webinar on WebRTC Testing

Thu, 07/16/2015 - 12:00

We’re a lot more than I had known.

One of my recent “projects” is co-founding a startup called testRTC which offers testing and monitoring services for WebRTC based services. The “real” public announcement made about this service was here in these last couple of days and through a webinar we did along with SmartBear on the impact of WebRTC on testing.

I actively monitor and maintain a dataset of WebRTC vendors. I use it to understand the WebRTC ecosystem better. I make it a point to know as many vendors as possible  through various means. I thought I had this space pretty much covered.

What surprised me was the barrage of requests for information and demos by vendors with real services out there that came into our testRTC contact page that I just wasn’t aware of. About 50% of the requests from vendors came from someone I didn’t know existed.

My current dataset size is now reaching 700 vendors and projects. There might be twice that much out there.

Why is this important?
  • A lot of the vendors out there are rather silent about what they are doing. This isn’t about the technology – it is about solving a problem for a specific customer
  • There are enough vendors today to require a solid, dedicated testing tool focused on WebRTC. I am more confident about this decision we made with testRTC
  • If you are building something, be sure to let me know about it or to add it to the WebRTC Index

Oh – and if you want to see a demo of testRTC in action, we will be introducing it and demoing it at the upcoming VUC meeting tomorrow.


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.

The post What I Learned About the WebRTC Market from a Webinar on WebRTC Testing appeared first on

Is the Web Finally Growing up and Going Binary?

Tue, 07/14/2015 - 12:00


I remember the good old days. I was hired to work on this signaling protocol called H.323. It used an interesting notation called ASN.1 with a binary encoding, capable of using a bit of data for a boolean of information. Life was good.

Then came SIP. With its “simple” text notation, it conquered the market. Everyone could just use and debug it by looking at the network. It made things so much easier for developers. So they told me. What they forgot to tell us then was how hard it is to parse text properly – especially for mere machines.

Anyway, it is now 2015. We live in a textual internet world. We use HTTP to describe our web pages. CSS to express its design and we code using JavaScript and JSON. All of these protocols are textual in nature. Our expectation is that this text that humans write (and read to debug), will be read and processed by machines.

This verbosity of text that we use over the internet is slowing us down twice:

  1. Text takes more space than binary information, so we end up sending more data over the network
  2. Computers need to work harder to parse text than they do binary

So we’ve struggled through the years to fix these issues. We minify the text, rendering it unreadable to humans. We use compression on the network, rendering it unreadable to humans over the network. We cache data. We use JIT (Just In Time) compilation on JavaScript to speed it up. We essentially lost most of the benefits of text along the way, but remained with the performance issues still.

This last year, several initiatives have been put in place that are about to change all that. To move us from a textual web into a binary one. Users won’t feel the difference. Most web developers most feel it either. But things are about to change for the better.

Here are the two initiatives that are making all the difference here.


HTTP/2 is the latest and greatest in internet transport protocols. It is an official standard (RFC 7540) for almost 2 full months now.

Its main objective is to speed up the web and to remove a lot of the hacks we had to use to build web pages and run interactive websites (BOSH, Comet and CSS sprites come to mind here).

Oh – and it is binary. From the RFC:

Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing.

While the content of our web pages will remain textual and verbose (HTML), the transport protocol used to send them, with its multitude of headers, is becoming binary.

To make things “worse”, HTTP/2 is about to encrypt everything by default, simply because the browsers who implemented it so far (Chrome and Firefox) decided not to support non-encrypted connections with HTTP/2. So the verbosity and the ability to watch messages on the network and debug things has gone down the drain.


I’ve recently covered WebAssembly, comparing the decisions around it to those of WebRTC.

WebAssembly is a binary format meant to replace the use of JavaScript in the browser.

Developers will write their frontend code in JavaScript or whatever other language they fancy, and will have to compile it to WebAssembly. The browser will then execute WebAssembly without the need to parse too much text as it needs to do today. The end result? A faster web, with more languages available to developers.

This is going to take a few years to materialize and many more years to become dominant and maybe replace JavaScript, but it is the intent here that matters.

Why is it important?

We need to wean ourselves from textual protocols and shift to binary ones.

Yes. Machines are becoming faster. Processing power more available. Bandwidth abundant. And we still have clogged networks and overloaded CPUs.

The Internet of Things won’t make things any easier on us – we need smaller devices to start and communicate. We need low power with great performance. We cannot afford to ruin it all by architectures and designs based on text protocols.

The binary web is coming. Better be prepared for it.

The post Is the Web Finally Growing up and Going Binary? appeared first on

WebRTC on the New York Times – Not as an Article or a Video Chat Feature

Mon, 07/13/2015 - 12:00

WebRTC has been mentioned with regards to the New York Times. It isn’t about an article covering it – or a new video chat service they now offer.

I was greeted this weekend by this interesting tweet:

WebRTC being used now by embedded 3rd party on to report visitors' local IP addresses.

— Mike O'Neill (@incloud) July 10, 2015

I haven’t been able to confirm it – didn’t find the culprit code piece in the several minutes I searched for it, but it may well be genuine.

The New York Times may well be using WebRTC to (gasp) find your private IP address.

In the WebRTC Forum on Facebook, a short exchange took place between Cullen Jennings (Cisco) and Michael Jerris (FreeSWITCH):

Cullen: I’ve been watching this for months now – Google adds served on slash dot for example and many other sites do this. I don’t think it is to exactly get the local ip. I agree they get that but I think there is more interesting things gathered as straight up fingerprinting.

Michael: local ip doesn’t seem that useful for marketers except as a user fingerprinting tool. They already have your public ip, this helps them differentiate between people behind nat. it’s a bit icky but not such a big deal. This issue blows up again when someone starts using it maliciously, which I’m sure will happen soon enough. I don’t get why exactly we don’t just prompt for this the same way we do camera and mic, it wouldn’t be a huge deal to work that into the spec. That being said, I don’t think it’s actually as big of a deal as it has been made either

Cullen: It’s not exactly clear to me exactly how one uses this maliciously. I can tell you most peoples IP address right now and knowing that a large percentage of the world has that local IP does directly help you hack much. To me the key things is browsers need to not allow network connections to random stuff inside the firewall that is not prepared to talk to a browser. I think the browser vendors are very aware of this and doing the righ thting.

My local IP address is which is also quite popular.

In recent months, we’ve seen a lot of FUD going on about WebRTC and the fact that it leaks local IP addresses. I’ve been struggling myself in trying to understand what the fuss is. It does seem bad, a web page knowing too much about me. But how is that hurting me in any way? I am not a security expert, so I can’t really say, but I do believe the noise levels around this topic are higher than they should be.

When coming to analyze this, there are a couple of things to remember:

  • As Cullen Jennings points out, for the most part, the local IP address is mostly known. At least for the consumers at home
  • We are already sharing so much about ourselves out of our own volition, then I don’t see how this is such an important piece of information we are giving away now
  • The alternative isn’t any good either: I currently have installed on my relatively new laptop at least 4 different communication apps that have “forced” themselves on my browser. They know my local IP address and probably a lot more than that. No one seems to care about it. I can install them easily on most/all enterprise machines as well
  • Browser fingerprinting isn’t new. It is the process of finding out who you are and singling you out when you surf across the web through multiple websites. Does it need WebRTC? Probably not. Go on and check if your browser have a unique fingerprint – all of the 4 browsers I checked (on 3 devices, including my smartphone’s) turned out rather unique – without the use of WebRTC
  • The imminent death of plugins and the commonality of browsers on popular smartphones means that browser fingerprints may become less unique, reducing their usefulness. WebRTC “fixes” that by adding the coupling of the additional local and public IP address information. Is that a good thing? A bad thing?

One thing is clear. WebRTC has a lot more uses than its original intended capability of simply connecting a call.

The post WebRTC on the New York Times – Not as an Article or a Video Chat Feature appeared first on

3CX and WebRTC: An Interview With Nick Galea

Thu, 07/09/2015 - 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 >>

3CX: Nick Galea

July 2015

Enterprise web meetings

WebRTC video conferencing for the enterprise.

[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 have been following 3CX for several years. They were one of the first in the enterprise communication solution vendors that offered WebRTC. Recently, they introduced a new standalone service called 3CX WebMeeting. It has all the expected features of an enterprise multiparty video calling service. And it uses WebRTC.

I had a chat with Nick Galea, CEO of 3CX. I wanted to know what are they doing with WebRTC and what are his impressions of it.

Here are his answers.


What is 3CX all about?

3CX provides a straightforward and easy to use & manage communication solution that doesn’t lack in functionality or features and is still highly affordable. We recognised that there was a need for a Windows-based software PBX and so this is where 3CX began.

Given the fact that the majority of businesses already use Windows, 3CX provides a solution that is easy to configure and manage for IT Admins. There’s no need for any additional training that can be time-consuming and costly. We also help businesses to save money on phone bills with the use of SIP trunking and free interoffice calls and travel costs can be reduced by making use of video conferencing with 3CX WebMeeting. As a UC solutions provider, we focus on cost savings, management, productivity and mobility, and we help our customers to achieve improvements in all four aspects.

Our focus is on innovation and thus, our development team works nonstop to bring our customers and partners the very best. We are always looking out for the latest great technologies and how we can use them to make 3CX Phone System even better and so of course, WebRTC was a technology that we just had to implement.


You decided to plunge into the waters and use WebRTC. Why is that?

To us, unified communications is not only about bringing all methods of communication into one user-friendly interface, but about making those methods of communication as seamless, enjoyable and productive for all involved, whether that be for the organisation that invested in the system, or a partner or client that simply has a computer and internet connection to work with.

Running a business is not an easy feat, and the whole purpose of solutions such as 3CX Phone System and 3CX WebMeeting is to make everyday business processes easier. So, for us, WebRTC was a no-brainer. We believe in plugin-free unified communications and with such technology available for us to leverage, the days of inconvenient downloads and time-consuming preparation in order to successfully (or in some cases, unsuccessfully) hold a meeting are over.

What signaling have you decided to integrate on top of WebRTC?

Signalling is performed through websocket for maximum compatibility. Messages and commands are enveloped in JSON objects. ICE candidates are generated by our server library while SDP are parsed and translated by MCU. This allows full control over SDP features like FEC and RTX in order to achieve best video performance.


Backend. What technologies and architecture are you using there?

The platform is based on a web application written on PHP. We developed a custom MCU service (actually it’s a Selective Forward Unit aka SFU). This service allows us to handle a very large number of media streams in real time. Performance is optimized to reduce latency to a minimum. Raw media streams can be saved to disk, then our Converter Service automatically produces a standard video file with meeting recording.

A key component of web application is the MCU Cluster Manager, which is able to handle several MCUs scattered in different areas, distribute load and manage user location preference.


Since you cater the enterprise, can you tell me a bit about your experience with Internet Explorer, WebRTC and customers?

So far most people are using Chrome without any complaints so it doesn’t concern me that WebRTC is not supported by Internet Explorer. We haven’t come across any issues with customers as they are aware that this is a limitation of the technology and not the software and actually our stats show that 95% of people connect or reconnect with Chrome after receiving the warning message, so for most users Chrome is not a problem.


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

I think that WebRTC will become the de facto communications standard for video conferencing, and maybe even for calls. WebRTC is a part of how technology is evolving and we may even see some surprising uses for it outside the realms of what we’re imagining right now. It’s incredibly easy to use and no other technology is able to compete. It’s what the developers are able to do with it that is really going to make the difference and I believe there is still so much more to come in terms of how WebRTC can be utilised.


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

That they should have adopted it earlier :).


Given the opportunity, what would you change in WebRTC?

Nothing really but the technology is still growing so I’m looking forward to see what’s in store for WebRTC and how it’s going to improve.


What’s next for 3CX?

We’re working on tighter integration between 3CX WebMeeting and 3CX Phone System and integrating our platform more closely with other vendors of third-party apps such as CRM systems and so on.

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

The post 3CX and WebRTC: An Interview With Nick Galea appeared first on

How do You Test Your WebRTC Service?

Mon, 07/06/2015 - 12:00

Join the webinar on WebRTC and its Impact on Testing to get a clear answer.

I’ve been working recently with some friends on solving an issue for WebRTC that seems to be ignored by most – testing WebRTC services.

We had a concept in mind, and decided to follow through and develop a service for it, naming it testRTC. Since we started, we’ve enhanced the service greatly to include monitoring and analytic due to customers request.

What I noticed in our calls with customers is that there are 3 different paradigms used for testing WebRTC-based services:

  1. Not testing at all, assuming things will work out just fine or that customers complaining will just get us to fix bugs
    • I thought only startups with a demo or a proof of concept will be in this category, but was surprised to see large vendors in this category as well
    • Some assume that if they test their product in other ways (SIP/VoIP aspects of it for example), then this would be enough
    • Others assume that things will just work because Google is testing WebRTC in Chrome
  2. Testing manually, where you have QA teams (more likely the developer himself) go through the motions of testing the service
    • Which begs the question of how exactly can this scale or work with the continuous deployment nature of WebRTC, where browsers release new versions every 6-8 weeks
  3. Framework DIY, where an automation framework is put in place to test WebRTC
    • This usually amounts for a one-time investment that is then never improved upon
    • These frameworks will usually lack functionality, as other priorities related to feature requests and functionality trickle in

You might think that using a solid VoIP testing product would suffice for WebRTC, but the reality is starkly different. While WebRTC is VoIP, it bears little resemblance to it when it comes to testing.

If you wish to learn more, check out what we are doing at testRTC. Or better yet – join SmartBear and testRTC for a free webinar:

WebRTC and Its Impact on Testing – July 8, 2015, 2:00 p.m. EDT

Nikhil Kaul and I will be discussing the challenges WebRTC posts to testing and suggest best practices to meet these challenges. See you there!

The post How do You Test Your WebRTC Service? appeared first on

I Need Your Help: Who is Missing from my WebRTC PaaS Report?

Thu, 07/02/2015 - 08:30

Time for another update.

Only 4 months have passed since I released my last update to the Choosing a WebRTC API Platform report and things have already changed enough to merit another update.

Some of the things we’ve seen?

The report, as it is, currently covers 19 vendors: AddLive (Snapchat), APIdaze, Apizee, CafeX, Forge (Acision/Comverse), Kandy, OnSIP, ooVoo, OpenClove, Plivo, Requestec (Blackboard), Respoke, SightCall, Sinch, Temasys, TokBox, Tropo (Cisco), Twilio and VoxImplant.

AddLive and Requestec are now out of the game. Others may evaporate by year end. There are other players who are in this market and I am setting my sights on adding.

Which vendors do you think are missing in this report? What topics should I cover beyond those in the current table of contents?

I’d love to get your feedback.

The next update of this report will occur during September timeframe.

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.

The post I Need Your Help: Who is Missing from my WebRTC PaaS Report? appeared first on

I an now Officially a 100% WebRTC… Hermit

Wed, 07/01/2015 - 12:00

It took some time, but it finally happened.

Today is the first day in my adult life that I wake up in the morning needing to plan ahead for myself and myself only.

I started this journey three and a half years ago. It started small. With a post: Starting anew.

Two things happened at that time:

  1. I left my first full time job – working at RADVISION for 13 years. I did that for another full time job at Amdocs
  2. I decided to open my own professional blog (this one), with no clear idea what to do with it

The blog grew nicely and formed into a WebRTC focused site. So much so that I reduced my work at Amdocs to part time and started offering consulting around WebRTC. Today I am completing that step. I have left Amdocs, an employer that was good to me in every way, in order to carve up my own path in the world.

For now, it will mostly be WebRTC. But not only.

It will be consulting. But also entrepreneurship. There is already an established startup I founded with some friends, and another one in the works.

Most of all, it will be exciting. And fun.

If you want to have a chat or get my assistance – I’ll be happy to be of help.

The post I an now Officially a 100% WebRTC… Hermit appeared first on

Why an SDK is Critical to your API Offering

Tue, 06/30/2015 - 12:00

While you need to give direct access to your APIs, an SDK is a critical piece of your offering.

There was an article on the ProgrammableWeb on NOT offering an SDK for their service. I think in most cases, this approach is wrong. decided to offer only an API layer for its customers. You can access their REST APIs, but how you do it is your problem – even when what they give is designed and built for mobile devices.


I’ll start with a quick explanation of the two – at least in the scope of this post. There will be those who will definitely object my definitions here, but the idea is just to make the distinction I need here – and not to pontificate the meaning of the two.

  • API – an API is a set of operations you can use to access a backend service of sorts. Assumption is this is a server-side API, where we have a service on some remote server (probably on AWS or whatever other cloud), and that service offers access to it via APIs. You invoke the API by making a remote call from your machine or device to the cloud running the service. Usually these APIs will be REST based, though not always
  • SDK – an SDK is a piece of code that gets embedded into the customer’s service. The customer is a developer who decided to use your API, so he downloads your SDK and puts it in his own code. The SDK itself calls the API when necessary to get things done. The result – the customer calls the SDK locally, the SDK calls the API remotely and your service gets used
Why not an SDK?

Back to and their reasons – from this article:

  • SDKs introduce performance issues
  • Reduces control of the customer using it
  • Crashing SDKs
  • Privacy issues

While this may work in the gaming industry, I think it is not workable in many other industries. Here are my thoughts on this one:

It all boils down to your execution

There are two ways to treat an SDK – as part of your offering or as an afterthought.

If you treat it as an afterthought, then performance issues, crashes and privacy issues will crop more frequently than not.

With most SDKs today built as frontends to a backend REST API, it makes perfect sense that some of them just aren’t written well: Backend developers are good at scaling a service to run in the cloud. For them, considerations of memory and performance of the single session in the same way that a native Android developer thinks about is foreign.

If you really want to offer an SDK, have a pro build it for you.

The customer’s control

Assuming what you have on offer is a closed binary SDK that the customer ends up using, then control may be an issue.

It doesn’t have to be this way.

There are 3 options you can take here, each with its own control points for customers:

  1. Offer your SDK as a closed binary, but also give access to the backend API
    • Those who wish to use the SDK to shorten their time to market can do that
    • Those that wish to have more control can use the API directly
  2. Offer your SDK in source code format
    • This gives more control to your customer, who can now debug the code
    • The customer may modify the code, and in such cases, you should make it clear your support will be of the backend API only
  3. Offer a sample SDK client only
    • Provide a reference written in the native language of choice
    • Don’t offer support for it, but write it in a way that makes it easy to understand and modify
Why an SDK is needed?

There are several reasons that make an SDK so powerful:

  1. While REST APIs are simple enough, connecting to them can be quite a hassle
    • Which native library should be used? Have the APIs been tested with these libraries? Having this one decided, implemented and tested makes life easier for customers
    • What authentication mechanism is provided? How do you implement it on your own in the native language? This can eat up many hours, so having that done for customers reduces the friction and the chance of your customer moving to a competitor
    • There’s a flow issue – you need to call API A then API B then check something locally before running API C. Developers never read documentation. Give them a sample to work from in the SDK, and half your problems are solved
  2. It might not be REST…
    • There’s a shift towards WebSocket communications in some places. Documenting the spec and having customers follow it isn’t easy
    • Give an SDK instead, and the actual protocol you use for the WebSocket becomes irrelevant to the customer – AND allow you to easily update it in the future
  3. You might want to run things in the client side
    • WebRTC, for example, runs on the client side
    • You can’t really offer a backend API and just forget about the client side – there’s a lot of code that ends up there
    • That code has value – especially on mobile

Plan on offering a backend API for your customers?

You shouldn’t just ignore an SDK – especially not if you plan on having developers integrate with your APIs inside mobile apps.


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

The post Why an SDK is Critical to your API Offering appeared first on

Why I Hate Video Conferencing Plugins and LOVE WebRTC Services

Mon, 06/29/2015 - 12:00


A true story…

I had a meeting the other day. It was with a company that has been offering WebRTC video chat as part of its own services to their own customers for some time now, but internally, they used some other vendor for their own business meetings. My invitation was on that other vendor’s platform.

At the time of the meeting, I opened the calendar invitation, searching for the link to press.

Found it. Clicked it.

Got using my Chrome browser on my home desktop Ubuntu machine to the web page.

Clicked to join the meeting using my browser.

Was greeted with a message telling me Chrome isn’t supported due to a Chrome bug (with a link to a page detailing the issue on Chrome’s bug tracker) AND suggesting me to use Firefox.


Opened up Firefox, pasted the link to it.

Clicked to join the meeting using my browser.

Was greeted with a message telling me that only Windows and Mac are supported.


Opened my laptop to join. It runs Windows 8, so no issues there (I hoped).

Clicked the link on the email there, just to get Chrome opened there.

Somehow, the system knew this time that I should be able to use Chrome, so it happily instructed me to wait to download and then run the executable they were sending me.


It took a minute or two to get that executable to run and start installing *something*.

But it got lost in all my windows. A bit of searching and I found the pesky window telling me to open the link yet again.

So I did.

It then went into this seemingly endless loop of trying to open up a meeting, failing and reopening.

This is when I noticed that the window being opened was an Internet Explorer one.

I cut the loop short and opened the link to the meeting on Internet Explorer.

It worked.

10 minutes later, frustrated, with another crappy installation of a client lurking around my Windows machine, I got to talk to the people who invited me.

Two were there with video – me one of them – we actually installed and executed that “plugin”.

Others joined by phone.

I am a technical person.

I worked in the video conferencing industry.

Why the hell should we use such broken tools and technologies in 2015?

I couldn’t care less if the video conferencing equipment that have been purchased ions ago don’t support VP8 or require conversion of SRTP to RTP or require translation from REST/WebSocket to H.323 signaling. I really don’t.

The only thing I want is to open a browser to a specific URL and have that URL just work.

On Ubuntu please.

The service in question?

Wasn’t a new one. They’ve been around for a decade or so.

They started with the desktop, so why can’t they get that experience to work well?

Yes. Internet Explorer and Safari are missing. I know. But I couldn’t care less.

If you want to provide a broken plugin experience for IE and Safari, then please do. But wherever possible make it easier for me to use.

It really isn’t hard. I attend a lot of video calls these days. The crushing majority of them are through WebRTC based services. Most of the services I used weren’t built by billion dollar companies.

Get your act together.

Start using WebRTC for your own business meetings.

The post Why I Hate Video Conferencing Plugins and LOVE WebRTC Services appeared first on

How the Politics of Standardization Plays in WebRTC, WebAssembly and Web Browsers

Thu, 06/25/2015 - 12:00

Companies care little about standards. Unless it serves their selfish objectives.

The main complaint around WebRTC? When is Apple/Microsoft going to support it.

How can that be when WebRTC is being defined by the IETF and W3C? When it is part of HTML5?


We learned last week on a brand new initiative: WebAssembly. The concept? Have a binary format to replace JavaScript, act as a kind of byte-code. The result?

  1. Execute code on web pages faster
  2. Enable more languages to “run” on web pages, by compiling them to this new byte-code format

If the publication on TheNextWeb is accurate, then this WebAssembly thing is endorsed by all the relevant browser vendors (that’s Google, Apple, Microsoft & Mozilla).

WebAssembly is still just a thought. Nothing substantiate as WebRTC is. And yet…

WebAssembly yes and WebRTC no. Why is that?

Why is that?

Decisions happen to be subjective and selfish. It isn’t about what’s good for the web and end users. Or rather, it is, as long as it fits our objects and doesn’t give competitors an advantage or removes an advantage we have.

WebAssembly benefits almost everyone:

  • It makes pages smaller (binary code is smaller than text in general)
  • It makes interactive web pages run faster, allowing more sophisticated use cases to be supported
  • It works better on mobile than simple text

Google has no issue with this – they thrive on things running in browsers

Microsoft are switching towards the cloud, and are in a losing game with their dated IE – they switched to Microsoft Edge and are showing some real internet in modernizing the experience of their browser. So this fits them

Mozilla are trying to lead the pack, being the underdog. They will be all for such an initiative, especially when WebAssembly  takes their efforts in asm.js and build assets from there. It validates their credibility and their innovation

Apple. TechCrunch failed to mention Apple in their article of WebAssembly. A mistake? On purpose? I am not sure. They seem to have the most to lose: Better web means less reliance on native apps, where they rule with current iOS first focus of most developers

All in all, browser vendors have little to lose from WebAssembly while users theoretically have a lot to gain from it.


With WebRTC this is different. What WebRTC has to offer for the most part:

  • Access to the camera and microphone within a web browser
  • Ability to conduct real time voice and video sessions in web pages
  • Ability to send arbitrary data directly between browsers

The problem stems from the voice and video capability.

Google have Hangouts, but make money from people accessing web pages. Having ALL voice and video interactions happen in the web is an advantage to Google. No wonder they are so heavily invested in WebRTC

Mozilla has/had nothing to lose. They had no voice or video assets to speak of. At the time, most of their revenue also came from Google. Money explains a lot of decisions…

Microsoft has Skype and Lync. They sell Lync to enterprises and paid 8.5 billions for Skype. Why would they open up the door to competitors so fast? They are now headed there, making sure Skype supports it as well

Apple. They have FaceTime. They care about the Apple ecosystem. Having access to it from Android for anything that isn’t a Move to iOS app won’t make sense to them. Apple will wait for the last moment to support it, making sure everyone who wishes to develop anything remotely related to FaceTime (which was supposed to be standardized and open) have a hard time doing that

All in all, WebRTC doesn’t benefit all browser vendors the same way, so it hasn’t been adopted in the same zealousness that WebAssembly seems to attract.

Why is it important?

Back to where I started: Companies care little about standards. Unless it serves their selfish objectives.

This is why getting WebRTC to all browser vendors will take time.

This is why federating VoIP/WebRTC isn’t on the table at this point in time – the successful vendors who you want to federate with wouldn’t like that to happen.

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


The post How the Politics of Standardization Plays in WebRTC, WebAssembly and Web Browsers appeared first on

Why Did Atlassian Switch Jitsi’s Open Source License from LGPL to Apache?

Tue, 06/23/2015 - 12:00

Jitsi switching to the Apache open source license is what the doctor ordered.

Blue Jimp, and with it Jitsi, was acquired by Atlassian in April this year. I wrote at the time about Jitsi’s open source license:

The problem with getting the Jitsi Videobridge to larger corporations was its open source license

  • Jitsi uses LGPL. A non-permissive license that is somewhat challenging for commercial use. While it is suitable for SaaS, many lawyers prefer not to deal with it
  • This reduces the Jitsi Videobridge’s chance to get adopted by enterprise developers who can pour more resources into it
  • This may limit Jitsi from building the ecosystem Atlassian wants (i.e – outsourcing some of the development effort to an external developers community)
  • Using BSD, MIT or Apache licenses would have been a better alternative. Will Atlassian choose that route? I am not sure
  • Did Atlassian leave the open source offering due to legal issues or real intent in becoming an open source powerhouse?

You can read my explanation on open source licenses. If you read the comments as well, you’ll see how complex and mired with landmines this domain is.

Last week, an announcement was made in the jitsi-dev mailing list: Jitsi is switching from LGPL to Apache license:

LGPL, our current license allows everyone to integrate and ship our various jars. Once you start making changes and distributing them however, then you you need to make sure these changes are also available under LGPL, AKA the LGPL reciprocity clause.

What I found interesting weer the next two paragraphs:

As the copyright holder, in BlueJimp we have been been exempt from this reciprocity clause. Even though we rarely use it, we had the liberty to modify our code without making our changes public. No one else had this option.

Switching to Apache ends our advantage in this regard, and allows everyone to use, integrate and distribute Jitsi with a lot less limitations.

Some things to notice here:

  • People who made changes to the Jitsi code base had to contribute back the code to Blue Jimp, along with the ability for Jitsi not to act the same – Jitsi maintained a different “license” for itself – this works well when your business model is consulting and customization of the open source project you maintain – not so good for a large enterprise
  • Atlassian took a different approach here by switching to Apache:
    • Atlassian internally has the same decision making processes as other large enterprises. LGPL is harder to adopt than Apache, making a switch to the Apache license for Jitsi a reasonable step to take – preferential treatment for Apache license in Atlassian and elsewhere played a key role here
    • It removed the possible nightmare of maintaining all of the existing CLAs (contributor license agreements) – they might have found them inaccurate, requiring a modification in their terms, needing a reassignment to Atlassian, etc – it was a good time to make the switch to Apache anyway
    • It gives a strong signal to the market, and especially to large enterprises that Jitsi is something they can use – if this turns out well, there will be additional contributors to this software package, as it is a popular one in the WebRTC industry
  • This switch from LGPL to APL (Apache) changes nothing in the ability of Blue Jimp and Atlassian to modify the base code and not contribute it back to the open source package
    • This kind of a thing has happened before during acquisitions of open source project teams
    • It also happens when competition starts using your own open source against you (think Google’s Android)
    • It is unlikely to happen in the short or medium term, based on the signals coming from Atlassian and their current focus
  • This opens up a powerful WebRTC media server (an SFU actually) to a larger number of vendors

All in all, this is a great move to our WebRTC ecosystem. Atlassian is doing the right moves in maintaining the Jitsi community happy and engaged while attracting the larger players in the market. I wouldn’t have done it any other way if I were in their shoes.


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.


The post Why Did Atlassian Switch Jitsi’s Open Source License from LGPL to Apache? appeared first on

How OTTs are Challenging VoLTE’s Prime Asset on Smartphones

Mon, 06/22/2015 - 12:00

While our smartphones aren’t phone anymore, their phone-calling real estate is still a prime asset.

VoLTE stands for Voice over LTE. It has been in the making for quite some time, but haven’t made its grand public appearance yet. While carriers around the globe boast LTE adoption stats, this says NOTHING about the lag of the carrier’s once main service – the humble voice call.

Today, in almost all cases where you open your smartphone greeted with an LTE network, if you make a phone call, it will go over 3G or GSM. Why? Because for voice to traverse LTE it requires VoLTE – or some other workaround means. Once VoLTE makes it into the scene, it will need to replace the voice calls today – and be a part of the smartphone’s dialer.

But there are other means of making calls these days, and I am not talking about Skype buddy lists.

Here is how the different players on the market redefining how we make calls, and trying to win the real-estate of the phone’s dialer by… replacing it.


In some ways, Apple is dependent on carriers selling its smartphones through contract agreements. So it can’t piss off their channel to market too much. But they can are treading on a very fine line here.

It started with FaceTime. Apple’s video chat service. Which then grew to iMessage, and later an introduction of FaceTime Audio.

Apple controls the iPhone’s UI, which means it decides how the dialer looks like and what functions it exposes to the user.

The end result?

  • When you want to send an SMS to someone, Apple will automatically “convert” it to an iMessage if possible
  • When you want to make a call to someone, if he uses an Apple device, you have the option to call him – voice or video – using FaceTime

Google has Hangouts. You get it pre-installed in Android devices. Many never use it, but it is there.

Google tried making Hangouts sticky in the past, so they allowed it to receive and send SMS – similar in some ways to how Apple does iMessage, but different as the experience isn’t as seamless.

On a mobile phone, think of Hangouts as a step in the way. Google’s Project Fi, their new MVNO initiative, probably uses Hangouts internally – it does connect with Hangouts as their website explains:

Connect any device that supports Google Hangouts (Android, iOS, Windows, Mac, or Chromebook) to your number. Then, talk and text with anyone—it doesn’t matter what device they’re using.

Google is bulking up its communication chops nicely these past few years, and Fi is the next step. I am certain that part of the tech and learnings that Google gains from Fi will find its way back to their general Hangouts service.


Facebook had its share of romance with mobile. From rumors of Facebook smartphones, to a failed Facebook Home app.

For Facebook mobile is critical. Many of its customers use it exclusively on mobile. How do you increase your share in a digital life pie if you are Facebook? You try to control the smartphone experience.

Building a smartphone is hard (ask Amazon), so Facebook tried controlling the home screen by developing a Facebook centric Android launcher. This didn’t work, but wasn’t a failure at the scale of a smartphone launch.

Next up, is their relatively new Hello app. It looks rather innocuous – you receive calls through their Hello app to get a “social ID” – Facebook will match the phone number to a person’s Facebook account to show to you on incoming calls.

The end result?

  • Facebook Hello is used as your smartphone’s calling app
  • They didn’t miss the opportunity of adding their own dialer in – which enables you to call via Messenger
Whatsapp (still Facebook)

Whatsapp is a part of Facebook, but it took a very different approach. It simply added voice calling to its app.

If you are interested in understanding the size of Whatsapp, then there’s a good bulleted list on Mobile Industry Review.

Think of this move in the following context:

  • As of April 2015, WhatsApp has more than 800 million active users
  • Average amount of time spent by users on WhatsApp is 195 minutes a week
  • Teenagers use Whatsapp all the time. At least here in Israel. They don’t talk – they text. Faced with the need to escalate a text chat to a voice call – will they switch app and context or just press the phone icon on the Whatsapp page?

What is your dialer now? The traditional phone dialer with its contacts app or Whatsapp?

Why is it important?

Communication is being redefined. Switching from voice and video towards data access and messaging.

This brings with it a bigger change of what is considered prime real estate on one smartphone’s display, and there are non-telco vendors who are positioned nicely to displace the carriers from the dialer as well. Where would that leave the carrier’s efforts with VoLTE?


Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post How OTTs are Challenging VoLTE’s Prime Asset on Smartphones 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.