Monthly Archives: September 2012

    Archive: September, 2012

Hardware Trumps Software Each and EVERY Time

In the end of the day, every software success relies on hardware modifications.

I am a bit fed up with people telling me that software codecs are just good enough – they consume the same battery life (they don’t), they provide the same quality (they don’t), they can run on small devices (they can’t). You can spam to your heart’s content in the comments below, but please – read this one through before you do.

The model of running our code faster than ever with each hardware iteration is breaking. We have 2 or even 3 GHz machines, but this has been true for several years. To stay ahead of the curve, we’ve moved into packing more computational units (cores) into our chipsets (this was the Intel way of life) or we went to accelerating specific tasks with dedicated hardware (the ARM/MIPS way of life in embedded devices).

Every time a software technology becomes mainstream, it gets accelerated by way of hardware. Here are a few examples from recent years.


Virtualization is a great concept: you take the hardware and virtualize it – running the software on top of it wherever you want – instead of running a single software instance on a single physical hardware you can now run multiple software instances on a single piece of hardware – sharing the capacity it has.

Guess what – this whole virtualization thing requires hardware that explicitly supports it to be of any real use without huge penalties on performance and capabilities. This is why Intel and other chipset vendors have invested in virtualization in their chipsets. While there are still debates as to the advantages of hardware assisted virtualization, you can be rest assured that this trend will only increase.

3D rendering

Guess what? That realistic video game you are playing? Or the nice transitions your iPhone does for the user interface? They get accelerated on a GPU.

The iPhone and most other smartphones today use PowerVR GPU which makes its appearance as part of their system-on-chip. The code that runs the visualization stuff simply offloads all the heavy lifting to the GPU – can’t do it on the host chip with software if you want responsiveness from your phone or a full day of battery life.

Video compression

We’ve been doing video compression in hardware for ages – the reason is simple – there was no other way.

And then Intel with its Moore’s Law decided to catch up with our needs. But then our needs increased: we decided we want more resolution and frame rate for our videos, and we want to compress them better with modern standards.

So yes. You can use an Intel chip and run video compression on it. But even Intel understands the futility of it, so their latest chipsets does hardware based encoding of video. If you own an Android or an iPhone – your camera recordings and YouTube playback are done with hardware acceleration as well.


When it comes to security, hardware can cause problems and solve them.

Troy Hunt did an interesting test where he tried to generate hash values using a GPU. Here’s the result:

You see, using hashcat to leverage the power of the GPU in the 7970 you can generate up to 4.7393 billion hashes per second. That’s right, billion as in b for “bloody fast”.

Let’s see you do that without a GPU acceleration – a CPU won’t get to billion hashes per second – that’s for sure.

On the other end of it, when you want to encrypt bulk data – either for storage or network – you will shift to hardware to do it efficiently. As Adrian Kingsley-Hughes notes in his own suggests:

This drive features AES 256-bit hardware encryption to allow you to encrypt and protect your sensitive data while at the same time getting the performance, reliability and power benefits of a solid state drive.

In other words – if heavy lifting is done by hardware, then there are no penalties on the software you still need to run on the same hardware.


The most fascinating example of all is probably that of taking Java and accelerating it – running pieces of it on the GPU itself.

Hardware acceleration is going to grow. It has come to a point where there are thoughts of accelerating higher level programming languages such as Java, which only goes to show that as much as Moore’s law is concerned, our needs are insatiable even further.

So you see, even if you do think you are running pure software for your super uber algorithm – it is most likely accelerated somewhere to make it feasible for the use cases you need.

In other words – hardware trumps software each and EVERY time.

  • September 27, 2012

3 Takeaways From Martin Geddes on WebRTC

Martin Geddes is one of the most important thinkers of our times when it comes to telecommunications. And now he has voices his opinions about WebRTC.

Martin Geddes has a great newsletter – if you are in the telecoms industry, make sure you subscribe to it. In his latest installment, he decided to look at WebRTC. His thoughts about WebRTC reflect my own, only in a better form – he puts ideas to words a lot better than I can.

Martin covers a lot of ground about WebRTC. My 3 main take aways?

No Signaling

In Martin’s own words:

There is no ‘WebNet’ for voice or video. WebRTC is the minimal set of functions necessary to enable adoption of voice and video, and learning of its new affordances.

No signaling means that WebRTC can be used for almost any type of a scenario you can think of, without complicating things due to signaling standards – just use whatever works for you – standardized or otherwise.

Martin attributes that to the experimental spirit of the internet – a connection I haven’t made but I really like.

My enemy’s enemy

OTT players are the real losers from WebRTC. As Martin phrases it:

If Skype and Viber are telephony’s real-time communications competition, WebRTC is your enemy’s enemy – since it lessens the need for these rival voice services. It should thus be considered a friend.

I have recently written about it on Vision Mobile, with the exact same opinion: WebRTC is an opportunity for telcos and a headache for OTT players.

The long road ahead

Martin sees WebRTC is a nice beginning, but something that is still immature – especially on the specification side:

The list of possible issues and incidents around inbound call notifications, feature interaction and privacy problems is long enough to ensure this is a technology for experimental use, not core production business services.

On this I disagree.

WebRTC may be immature and in experimental stages, but it will take little time until we start seeing it in real services – services people will be paying to use, and then it will just replace the OTT ecosystem and flip its market. The road ahead is long, but it isn’t a matter of more specification and plugging holes in the WebRTC standard – it is the issue of developing services and then improving them over time.

A year from now? Real services using WebRTC, and a lot of apps on mobile that will use it as a pure media engine.

2 to 3 years from now? Services running on both PC and mobile platforms seamlessly – with or without the assistance of the operating system vendors. It might not be the best quality possible, but it certainly will be the best overall solution out there.

  • September 26, 2012

WebRTC’s Hardware Challenge

Having WebRTC VP8 on hardware is going to take time. Here’s why.

If I had to select an Achilles heel for WebRTC it would definitely be hardware support. There are those that will say I am making a fuss of a non-existent problem, but working for over a decade in the video conferencing market, I can tell you that hardware support simplifies things and improves the end result.

WebRTC decided to take the path of patent free (or more accurately royalty free) codecs. This reflects on the selection of codecs: Opus for voice and a clear preference of Google for VP8 over H.264. If Google has its way and VP8 will be selected as the mandatory codec, then we are headed into a world of hardware headache.

H.264 is the dominant video codec on the market today. I don’t think there’s a single multimedia chip that supports video codecs without supporting H.264 – it is simply unheard of. Chip manufacturers have taken H.264 to the extreme – the fact that you can encode and decode video in 1080p resolutions (=high definition) on a smartphone without taking too much toll on the running applications can be attributed to this.

Today, if you are into any serious video compression, then you do it with hardware – software just doesn’t cut it. A quad-code Intel CPU can probably run high definition video compression, but it won’t be able to do much else in parallel. If video communication is what we are looking for, then the ecosystem to support it must include hardware.

Google understands that – it is why it is offering the intellectual property of a hardware encoder and decoder for VP8 practically for free. But even having that as a head start still means a year or two of development – it requires adding it to the chipset roadmap, doing the design, development, testing and then manufacturing of such chipsets.

It will take time for VP8 to become commonplace in chipsets, while at the same time, H.264 is widely available.

I wonder how the fight over the video codec will end for WebRTC, and will we have licensing headaches or hardware headaches once a decision is made.

  • September 24, 2012

WebRTC@frisB: An Interview With Terry Shats

frisB is an interesting startup that uses WebRTC to generate missed calls from the web to your phone.

I hope this is the first of many such interviews. I have decided to go and hunt for WebRTC companies – those startup disruptors entering the telecom industry using WebRTC and an innovative idea.

The first one in this series is going to be frisB, where Terry Shatenstein, a Co-founder at frisB, was kind enough to answer a few questions for me.


What is frisB all about?

frisB is a highly magnetic voice channel that permits any internet user to freely ring and invite any telephone user in the world to talk. It’s a digital fusion between flying discs and telecoms 🙂

Internet users spin virtual discs to phones around the world inviting them to talk. Discs present as “missed calls” listing the local frisB dialback number. When the phone returns the call the web catches and connects free. Effectively a net user can instantly and freely reverse connect to any phone on the planet and critically without any payment whatsoever. We are the only service delivering free global telecoms on this convergence model. It has never been done before.


Why generate missed calls in the first place?

Trying to convert free net users to paying is almost impossible. It’s the proverbial billing brick wall. We wanted to change the landscape and the thinking … to converge rather than convert the free masses to paying: Consumer VoIP is a fiercely competitive business as free becomes cheap and cheap becomes cheaper in what is a classic industry caught in a penny gap. On the internet requesting any payment no matter how small inhibits mass adoption.

Look at search, can you imagine how big Google would be if you had to pay?

We saw the opportunity to light up the cloud and industry with seamless origination rather than termination which means the user on the web receives an incoming free connection rather than incurring an outgoing paying one.

This subtle yet profound connection reversal changes almost nothing yet changes almost everything:

The mass free can now pull in their mobile social and paying contacts up into the cloud since we can virtualize VoIP by presenting it at the highest telephony interface abstraction: the missed call manager.

Missed calls can present a gateway callback number that hooks any phone into the cloud and keeps everything in the telephony domain. Missed calls also permits us to fly in under the billing radar and then back over the billing brick wall … stimulating increased call origination on the carriers network.


How did you come up with the idea?

We are a “virtual telco” with global aspirations and built the service so we could talk freely over the Atlantic Ocean between the USA and South Africa. We found that day/night time zones often had “one at PC and the other mobile and off the 3G grid” and were frustrated with exorbitant international direct calling rates and the constant “harassing to add Skype credit to call phones.” We wanted to make global phone calls without paying and without prescribing the environment and time zones.

We love playing “frisbee” and found it to embody the perfect callback analog (“throw it out there and catch the return”). So we modeled a phone service on the game, “simple enough for a child of 5”.

And then fell in love with it.

We now play “intercontinental frisB” daily. It has become an essential service to us and we are passionate about sharing it with others, one by one, by word of mouth.


What part did WebRTC take in it?

The native voice drivers are key to WebRTC as is the fact that users do not require plugins. Native gives highest quality lowest latency.  We started out with Java, however Java is on a “descending vector” and has many challenges including reliable microphone access and end user acceptance. Flash was never a contender for us because poor audio quality compromises the conversation.


How did you find the integration with it? What worked, what didn’t?

Embracing WebRTC so early on in its dev cycle has proven to be remarkably stable with exceptional audio quality. You know this when conversations begin to shift from “discussing the quality of the connection to holding real conversations” … when the technology disappears into the background.

This is in part due to native access to device drivers and given that we leverage the “best of both worlds … packet switched on IP and circuit switched on telephones”

On the integration you really have to ask our lead engineer Ashley Brener as he did the integration, and our PSTN interworking specialist Klaus-Peter Junghanns who developed an ultra lightweight gateway.

“WebRTC API changes have been a significant challenge because during the WebRTC development cycle the product is not necessarily backward compatible from version to version and frisB needed to support all previous and current versions while also playing on the Chrome Canary channel which is the latest rendition. This makes having a past, present and future view of the WebRTC universe quite challenging as is the fact that Chrome Broswers mostly update in the background without any (developer) notice. However this is what living on the edge is all about … building and launching the rocket ship at the same time.”


What would you change in WebRTC if you were given that choice?

The one fundamental change we would make and would still like to see given the standards process is still a work in progress is support for plain legacy RTP/STUN under application control rather than mandating (secure) SRTP/ICE as the only supported media transport.

RTP would permit seamless meshing between browser and legacy PSTN gateways without requiring a media plane interworking server that has to translate between plain RTP and secure RTP. This is a very expensive interworking component because it requires the provider to carry the media whereas supporting a common protocol permits peer to peer traffic.


What are your plans ahead for frisB?

While frisB is still in its infancy as an MVP (minimal viable product) and minimalist features it has a passionate and small community that has already clocked over 1000+hrs (60,000 minutes) of talk time. A key metric that has emerged from our small user base is that since calls are rendezvoused they last longer. The average off net VoIP calls is mere minutes whereas frisB calls average 20 minutes or more.

Our vision is simple and singular … to evolve our service into the next long distance carrier.


WebRTC offers also video. Why only voice?

Being ultra-minimalists we have very little interest in video calling. Face time consumes far too much bandwidth. Video is at best a visual distraction and you cannot beat pure voice for real world connections. There is a reason the global trillion dollar telephony industry is predicated on voice. If it were video it would best be a “poorly dubbed movie” 🙂

Make sure to check out the frisB service!

  • September 20, 2012

H.264 vs VP8: Which is the Better Codec for WebRTC?

We’re in a codecs war, and the main event is going to be between H.264 and VP8. Who will win?

A few disclaimers before we begin:

  • I know video coding theory quite shallowly – at least compared to those developing codecs
  • I am more familiar with H.264 than VP8
  • I don’t know which of these codecs will win

But – at the end of the day, this isn’t going to matter.

If people tell you the selection of a video codec when it comes to H.264 or VP8 is done on a technical level, then they are lying. For the same amount of bitrate, the difference between the two codecs isn’t big enough to give any of them a real advantage – one that would make you select the one and not the other.

Now that we’ve got that one out of our system, it is time to see what the differences between the two are:

“Legacy” systems

As much as Google would love to tell us, VP8 is not that widespread – especially not if you look into video calling solutions.

The world of enterprise video conferencing revolves around H.264 these days, with a roadmap looking into H.265.

If connectivity to existing video systems is of any importance, then the ability to interact with them directly without the need for transcoding (translating between H.264 and VP8) should be taken into consideration. Transcoding is a taxing task – it requires a lot of CPU, adds latency and can reduce video quality in the process as well. It means that the video stream needs to go through an intermediary media device in all scenarios.

When it comes to legacy systems, H.264 wins big time.

Existence of an ecosystem

When Google announced WebM (=VP8 for this purpose) they also announced a slew of companies endorsing it. The reason for that is that any codec requires an ecosystem of companies – especially the video codec ones. Codecs don’t live in closed systems – they require multiple companies to develop and work with, and that means having everyone on the same page – the same codec spec.

The H.264 ecosystem is larger than that of VP8 and is already in place for a lot of years now.

Need the best example?

That’s 75 times more links for a search of a codec implementation. Not the most accurate one, but it goes to show the power of an ecosystem.

When it comes to the ecosystem, H.264 wins.

Patent related issues

The reason for this post started from patent related issues and openness:

It is hard to stress the importance of this point. I’ve worked at a video company. Whenever the issue of patents and codecs came up, the delicate legal dance was played out: what are the costs, who pays, how it works.

H.264 is rigged with patents. Most of them are owned by a group called MPEG-LA. In the laundered language of their website:

Our goal is to provide a service that brings all parties together so that technical innovations can be made widely available at a reasonable price. Utilizing our collaborative approach, we help make markets for intellectual property that maximize profits for intellectual property owners and make utilization of intellectual property affordable for manufacturers, consumers and other users.

A simple translation would be that they simply take money from whoever wants to use H.264 because it is patented by a large number of companies – these include the likes of Apple, Microsoft, Ericsson, Samsung, Sony and others.

VP8? It has a free patent license from Google. That said, MPEG-LA stated in the past that it might hold patents over VP8 and it wishes to for a patent pool for it as well.

It is yet to be seen if VP8 will remain patent free or not, but for now, it is the cheaper alternative.

Availability of hardware support

This is the real crutch of VP8: hardware support.

Video codecs are voracious CPU consumers: the more you give them the better.

  • To make set-top-boxes work, the manufacturers put specialized chipsets in them that decode the video on hardware, making sure the cost of the set-top box remains low.
  • The 1080p video recording on the latest smartphones? It doesn’t come from the quad core ARM CPUs – it comes from hardware acceleration that is designed and built for this purpose – and it does that with H.264.
  • Thinking of a new Intel PC? The latest Ivy Bridge series has H.264 encoding and decoding done with hardware acceleration and not using the CPU.

Encoding and decoding video today is a task left for specialized hardware accelerators. You can do it with software, but then you will need to reduce the resolution, frame rate or other tasks running at the same time – not the best of experiences. It will also eat more of your battery.

For VP8 to get the same hardware acceleration as H.264 will take time – a year or two to get there – assuming chipset vendors see this as important enough.

My view? It is going to be a hard decision to make. While openness is important, there’s the ecosystem and availability of hardware to take into consideration. I wouldn’t want to be the one making this decision.

  • September 18, 2012

The Next Evolution of Mobile Apps: Cross Platform

The iPhone 5 is out. So are the Kindle Fire HD and the Lumia. How are you going to develop for them all?

Fanboys love bashing Android and one of their main points is fragmentation: how bad the integration between software and hardware is on an Android device and how developers are having a hard time focusing there on phones. It gets worse.

The best source of how bad (and good) things are on Android can probably be found on OpenSignalMaps blog.

These guys have logged information from over half a million phones over a period of 6 months and visualized it all. That was a few months ago, but things haven’t changed a lot in terms of the variability.

Go to the link above to get the visualization – I’ve decided to show off here only the phone models map – 3997 of them…

Add to that the variance in API levels of Android, screen resolutions and screen rations and you’ve got enough of a headache. But then there’s the iPhones and iPads (old and new).

Microsoft or RIM may join the game in 2013, making things a bit more complex for developers.

And there’s Mozilla’s Boot to Gecko – a project of making a Firefox OS for mobile, backed by the telcos – simply because it takes control from app stores and brings it back to them.

If you are planning on writing an app, there’s a lot of headache involved:

  • Which operating system to target?
  • Which versions of the operating systems to support?
  • Which phone brands and models to focus on?
  • What language to use?

The first 3 are an issue for marketing to deal with. The end result will be a long list of devices – marketing will want the largest footprint, and developers will need to find ways to comply.

There are essentially three approaches out there for mobile development:

  1. Develop natively on each platform
  2. Develop using HTML5 and wrap it up as an app (or leave it on the web)
  3. Hybrid

Native development will get the best results: it is what the operating system vendor is using and focuses on. HTML5 can be seen as the lowest common denominator – all modern web browsers support it, so if the app doesn’t need any special attention, then this is probably the way to go. The hybrid model means using both native and HTML5 code within the application – HTML5 to get at least some code to work across operating systems and native code to get the quirks of each operating system nailed down.

This have brought with it a slew of cross platform tools that you can use to develop and deploy applications on multiple mobile platforms. A year ago, Jonas Lind analyzed the market of these tools on Vision Mobile. In his summary, he made the following statement:

Web apps and HTML5 should make the largest dent in the market power of traditional platforms. But the final nail in the coffin will come when C++ cross-platform engines can offer almost the same performance and functionality as coding directly on the target platform.

It seems like there’s another option these days, which is to focus on Java – at least if you want your apps to run on both Android and iOS. Simon Judge just reported on a new tool from Google that converts Java to Objective-C (=Android to iOS):

the gains will not just be in the initial translation/port but more importantly in subsequent maintenance where it will be much easier to keep the iOS and Android apps in sync.

Provided in source code with a rather permissive Apache license leads me to believe that this will find its way to some of the cross platform tools out there. It has a compelling value proposition: instead of writing the code in a scripting language of an arbitrary tool, or using HTML5 with Java Script (with all of its disadvantages), you can write the business logic of your application once in stable Java code – and use it anywhere you want.

Cross platform tools have just become much more interesting.

  • September 17, 2012

Skype vs. Facebook: Which Gains More From WebRTC?

The fight is on: OTT VoIP against the social networks. Who stands to gain and who to lose from WebRTC?

This was a very exciting week for me: I published my first guest post on Venture Beat. This one was about how WebRTC affects Skype and Facebook, and the imminent faceoff between these two web giants.

Assuming both adopt WebRTC wholeheartedly tomorrow and start providing voice and video calling features from within the browser – without any app or download attached to it, what cards do each of them has to play?


Skype is now a Microsoft tool. With their blessing and assistance they can grow considerably.

First things first: Skype call button from the web can now work without an extension or a download – it can just BE there and use WebRTC.

Let’s talk devices. Skype gets integrated into all of their devices and operating systems: From Windows 8 on tablets, phones and laptops to Xbox game center and even the Microsoft Media room. This can be done with or without WebRTC. I prefer with – it gives them more flexibility and reach.

Bing – Microsoft’s search engine which just got integrated into the Kindle Fire HD can fit well here as well: integrate Skype call buttons (with the help of WebRTC of course) into everything and anything that allows it – especially the ads section.


Facebook has its share of trouble. Any growth it can show, new interaction and additional revenue stream will be welcomed.

Facebook can adopt WebRTC and provide a calling experience that surpasses most VoIP players. It already provides presence and chat, so what’s the trouble of adding voice and video calling integrated into their website with WebRTC? Integrate it into their Facebook app on mobile devices and it gets used more than Skype for VoIP calling.

Once done, they can monetize it by offering Facebook Out – similar to Skype Out.

Some other ideas?

  • Allow for voice and video postings that use WebRTC APIs directly from the activity feed itself
  • Integrate Facebook calling in the ads they show
  • Enable companies on their Facebook pages to add call buttons
  • Allow integrating a Facebook call button similar to their Like and Subscribe ones out of their own website

If you ask me, my bet on this one goes to Facebook. As I’ve stated in the Venture Beat post – the main attraction of OTT VoIP players such as Skype lies in holding my buddy list and enabling presence and calls to these people. The fact that I am interacting with them more time already and with a larger group of them on Facebook gives Facebook the edge.

Social is where we are headed, and it is where real time interactions are. It is time to fold the good old calling services into them.

  • September 13, 2012

4 Awesome Reading Sources for Your Kindle

Kindle is a great device, but it isn’t complete without some ways to discover things to read.

Now that Amazon’s event is behind us, the only thing left to say is that I probably won’t get an Amazon phone from any of you. Get me a Kindle Fire HD instead. For those who might be pursuing the Kindle road instead of an iOS one, there’s something to know, and that’s where to find great reading material – you definitely didn’t buy the tablet for the new movie deals Amazon got with EPIX. Or did you?

Call me a Findle – a Kindle fan. I truly love the concept and the device. I curse Amazon on a daily basis for spending so much time reading and ending up with a larger reading list than I started the day with.

When I received my first Kindle it was bare for a couple of weeks. It had a book or two at a time – nothing more. I used it the same way I used Amazon physical books before it, which didn’t translate well for the digital experience it can offer.

With time, I found more resources I can use to find good content to read, mainly at a lower price point than the mainstream stuff you can find.

Here are 4 awesome reading sources that I use:

100 Top Books

Amazon has a top list for everything. For the Kindle specifically there’s the top 100 Kindle books list, which is actually a lot more than a single list: it is a list per category, where in each there are two lists: top 100 paid and top 100 free.

I am a sucker for the science fiction top 100 list.

Start your way by selecting 2-3 books of your preferred categories on the free list and also on the paid one. I usually check out these lists when I am out of reading material or just want something fresh.

The Daily Deal

Amazon has its Kindle Daily Deal. If you are into exploring new grounds and book categories that you don’t usually read, then this is the best way to do that.

Each day, Amazon selects two books – one for adults and one for kids – and reduces their price to 2 dollars or less. For a single day. The books there don’t related to your reading habits – it is just a single book, promoted globally and reduced to a price you just can’t resist. And to make it even more tempting, they have an email subscription to it.

This daily deal thing cost me a lot until now, but it also exposed me to a large number of books that I wouldn’t have tried and enjoyed without it.

This is curated content from Dave Pell. He just decided to look at news articles in US newspapers, and share a few of them at a time – for Kindle reading people. You can subscribe to the service on

Only problem is, there was nothing new from him for most of 2012 which is sad – the articles he selected were always interesting, eye opening, and out of my usual reading list.

I do hope he will continue with it – subscribe to it just in case.

Send to Kindle

If you own a Kindle, then you also have a email address. You can send stuff to it – long emails, documents, and web pages. I use it a lot to read things on “paper” instead than reading on a PC screen.

For best results, use Amazon’s own Chrome extension: Amazon Send to Kindle

Works like a charm.


There are more ways to dins great things to read on a Kindle – be sure to share them with me in the comments.

And if you are still not convinced about the Kindle, then here’s why it is way better than the iPad:

[slideshare id=13766997&doc=201207-bloggeek-kindle-vs-ipad-120726123443-phpapp02]
  • September 11, 2012

WebRTC Book: An Interview With Alan Johnston

It was only a matter of time until someone published a WebRTC Book. Here’s an interview with the author.

I even thought of doing it myself – publish a book about WebRTC. Not a “real” book – an eBook. Or a presentation. Maybe I’ll stick to posts.  Alan B. Johnston and Daniel C. Burnett decided to publish a book and did just that. It is probably the first book about WebRTC.

WebRTC Book

The book is aptly titled “WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web” and is available on Amazon.

If there’s anything missing today it is developers with enough experience with WebRTC. There aren’t a lot of them, and as far as I know, those that know something about WebRTC are already employed. This means that companies need to settle for either web developers or VoIP developers – and pray that they catch up on the technology. While there are good resources out there, you need to find them.
No more. The WebRTC Book is for developers – it covers the basics of VoIP, WebRTC and how to use it to develop… anything.

Alan Johnston, one of the authors of the book, was kind enough to answer a few questions for me now that the book is published:


Why a book about WebRTC?

WebRTC is an exciting technology that seems likely to be very disruptive to a number of industries.  Having voice, video, and data communication capabilities built into every browser, and available for any web developer with just a few lines of JavaScript will change the web and the way we use it.  There’s lot of interest in WebRTC, but also lots of confusion about what it is, how it works, and how developers can use it. Dan Burnett and I have been involved in the standardization of WebRTC from the beginning, in both the IETF and W3C. With the pieces starting to come together, we thought now was a good time to write a book about it.


Who is the target audience? Is this for web developers, who want to understand VoIP and WebRTC – or for VoIP developers, looking for understanding of WebRTC?

The nature of WebRTC is that it is about the collision of the web world and the telephony world.  Web developers can use WebRTC to add cool new communication features to their sites and apps, while VoIP and telephony developers can use it as a new way to expand their reach.

We tried to write the book for both of these groups.  In the book, we introduce the APIs used by JavaScript web developers, and the protocols used by VoIP and telephone developers.

And don’t forget game developers, or those wanting accessibility in their apps and sites, who will also find WebRTC incredibly useful.


WebRTC is a work in progress. As such, how did you cope with writing a book for developers about it?

It is challenging to write about a fast moving topic, but technology book publishing has always been this way.  We had to wait until a majority of the details were fairly solid, but things will continue to develop and evolve.

Fortunately, we can take advantage of electronic publishing and print-on-demand technology to keep the book up-to-date.  In the past, I have typically done new editions of my technical books every 3-4 years or so. For this WebRTC book, we plan to do this much more frequently, perhaps with multiple editions per year.  And as more details are finalized, the book will grow and lengthen.

We also will post updates and changes in the standards and APIs to our book website


You focus a lot in the book about connectivity to SIP and PSTN. Why is that?

The browser-to-browser communication model is fairly simple and straightforward, and we spend most of the book discussing these types of Peer Connections for voice, video, and data channels, and the APIs needed to do this.  However, there is also a lot of interest in having browsers talk to VoIP endpoints, PSTN gateways, and other communication services.  This gets a little more complicated, and we spend some time discussing architectures and protocols needed to do this.


What’s the most complex part in WebRTC?

We are still in the very early days of WebRTC rollout, so my answer to this now is likely to be different in a few months even.  However, right now, it seems that the biggest challenge will be the offer/answer media negotiation between a browser and a VoIP or video endpoint.  There is still quite a lot of discussion in the standards about the right way to do this.  Fortunately, the average web developer doesn’t need to worry about this, but it is probably the most complex part.


What’s next for WebRTC in your view?

Well, we need to finish the standards, in both the W3C and the IETF.

Then we need to get the all the browser vendors to commit to supporting them.  Any fragmentation or proprietary APIs or protocols would be bad for the whole industry.  There are still some major open issues, such as video codec selection that need to be solved, and soon.

If you are a developer who wants to enter the world of WebRTC, or if you are a manager who needs to start developing with WebRTC, I highly recommend this book – it is the best starting point out there.

Get it now on Amazon.

  • September 10, 2012

Apple’s FaceTime is a Total Failure

If you are an Fanapple then stop reading now. Go read some MG Siegler stuff elsewhere. This one is about an Apple failure, so no point in you staying around and flaming the comments.

In June, Apple have boasted a lot of numbers during WWDC. Gleaned out of Alex Wilhelm’s coverage of the event, we had the following numbers.

For the event itself:

  • Apple’s 23rd WWDC
  • Over 1,000 engineers in the event
  • Tickets sold out in 1:43 hours
  • People from over 60 countries attended

For the App Store:

  • 400 million user accounts
  • Over 650,000 apps in the sotre
  • 225,000 apps for the iPad alone
  • Over 30,000,0000,000 downloaded apps
  • Apple paid out over $5,000,000,000 to developers
  • App store is available in 120 countries

For OS X:

  • Around 66,000,000 Mac users
  • 26,000,000 copies of OS X Lion shipped

For iOS:

  • 365,000,000 iOS devices
  • 80% of the users running iOS 5
  • 7,000,000,000 push notifications sent daily

For iMessage:

  • 140,000,000 iMessage users
  • 150,000,000,000 messages sent so far, a billion a day at this point

Some other services:

  • 125,000,000 iCloud users
  • 10,000,000,000 tweets sent through iOS 5
  • 47% of photos shared on Twitter are sent from iOS 5 devices
  • 130,000,000 Game Center users

There are some more numbers and announcements there, and we’ve already got accustomed to being bombarded by Apple with numbers in each WWDC, so this one isn’t any different.

It isn’t any different in one more aspect: there’s no mention about FaceTime’s numbers, and to me, no numbers mean only one thing: the numbers aren’t impressive.

Apple’s FaceTime service hasn’t been adopted as Apple has expected and its numbers are too low to boast at.

How unimpressive is FaceTime?

If you take iMessage in the 9 months of its existence until WWDC, it had an average of 120 messages per user per month.

If you take Skype in September 2011, it had 300,000,000 minutes of video minutes a day. If this same value stayed the same since September, then at the same time of iMessage existence, it would have gathered 81,000,000,000 video minutes. That’s a bit over 50% of the amount of messages over iMessage.

For video calls versus instant messages – this ratio is huge.

FaceTime doesn’t come close. We would have known about it if it did.

There aren’t a lot of areas related to the iPhone where Apple doesn’t publicize usage numbers and FaceTime is one of them. The only reason I see for this secrecy is the lack of success on FaceTime’s part with users.

I was one of those who thought that Apple will move the video calling industry forward. I was wrong.

In the end, Google pulled an Apple instead. It brought WebRTC that will now disrupt the industry.

  • September 6, 2012