Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here

Sunday, November 17, 2013

Updated WebRTC forecasts + new analysis of browser vs. non-browser uptake

I saw someone on Twitter post the other day that we are currently at "Peak Telco Conference". Last week & next week have an extraordinary number of clashing events, around the world. One interesting thing I'm noticing is how many seem to be adding in a session or couple of presenters on WebRTC, which is fast becoming the "topic du jour" across telecoms overall.

Unfortunately, these clashes mean I won't be with my familiar crew at the WebRTC Conference in Santa Clara, for their 3rd event, although I'll be watching the Twitter feed with avid interest! Instead I am at the ITU World & TADS Summit conferences in Bangkok in Thailand. 

I'm doing a workshop at ITU on Future of Voice (notably WebRTC & Hypervoice) along with regular conspirator Martin Geddes, as well as moderating what should be a lively panel on Telcos vs. OTT, in front of an audience of telecoms ministers & regulators. Friend Andy Abramson is on the panel, and is threatening to be even more disruptive then me.

At TADS, I'm doing a session on WebRTC (unsurprisingly), and then joining a panel of luminaries (including Martin again) about the Future of Voice.

So, in order to keep afloat in the inevitable media storm about WebRTC and telecoms over the next week, I thought I'd put out a quantitative blog post, updating some headline numbers and drilling down on how the WebRTC marketplace may evolve over the next few years. The figures come from the most recent update of my WebRTC research - subscribers got their 30 pages of new analysis about a month ago. (I know that quite a lot of people use my already in their presentations & press releases - feel free to ping me if you need updates).

  • Overall device support for WebRTC at end-2016 now predicted at 4.2bn, up from 3.9bn in previous forecasts
  • Addition of new category of devices (beyond PCs, smartphones & tablets) to account for embedded-WebRTC products such as TV dongles, in-vehicle systems, M2M etc
  • Active individual user-base of 1.6bn people, with around an average of 2 devices each, using WebRTC by end-2016. This equates to roughly 50% of the expected Internet user base at that time.
  • Over 3bn devices will support the use of WebRTC outside the browser by end-2016. This is a critical understanding, as it fundamentally alters the way the technology will be perceived.
  • WebRTC is already live in a variety of commercial use-cases, ranging from contact centres to online interviews.
  • Sudden adoption of WebRTC by a major OTT player such as Twitter, LinkedIn or Facebook could lead to a rapid (almost overnight) acceleration of adoption beyond the forecasts. Thus far, we haven't seen this happen, but it could be a major catalyst, especially in conjunction with non-browser mobile WebRTC (see below). A "background" use of realtime data-streaming (eg for CDNs) could do the same, especially if hooked into one or more of the major browsers without user intervention.

Various new services are employing WebRTC "in spirit" even if the technology is not 100% identical to the (proposed) standards. This doesn't matter in many ways - innovations like Amazon Mayday (customer support) or Google Helpouts (expert interview platform), point to the underlying democratisation of voice and video outside the traditional "phone call" model. In many ways the strict technology enablers are irrelevant except academically - the bottom line is more forms of communication, developed more easily and cheaply by web, corporate, mobile & telco app developers.

Perhaps the most important output of the new analysis is this: overall from late-2015 onwards, the number of non-browser WebRTC-supporting devices will grow above 50% of the total across all device categories (ie including PCs). The majority will have both access mechanisms. For smartphones, browsers will not be the main way that users discover and use WebRTC.

It is important to explain what "non-browser WebRTC" consists of, as it is only really starting to be discussed now. There is growing evidence that WebRTC is moving (on mobile) from browser towards app implementations, either though:

  •  “Hardcore” development by specialists, directly using the RTCWeb and so-called "RAI2.0" stack of protocols and codecs which underpin WebRTC, built directly into apps. The forecasts include use of the media engine & firewall traversal & encryption components, even where there the “official” WebRTC Javascript APIs aren’t used. An early example is Vonage's mobile app, which incorporates a lot of WebRTC's underlying nuts & bolts.
  • Use of 3rd-party client APIs and SDKs, which give a more rounded and accessible set of capabilities to developers than “raw” WebRTC JS APIs, especially when applied to standalone apps. Examples here include Tokbox, Crocodile, Twilio, Tropo and many others. There may well be extra server-side APIs used for various functions as well. 
  • As yet, we haven’t seen WebRTC APIs appear directly in device OS’s, although there are rumours that Android may soon start to support them, while Firefox OS is clearly on a similar trajectory. Disruptive Analysis expects this model of WebRTC to become a reality over the next 1-2 years - and we may even see Apple joining in at some point. (Sidenote: Facetime appears to use a lot of the same underlying technologies as WebRTC)
  • Devices such as Google Chromecast do not have screens, and therefore do not have normal browsers. They may still enable some form of WebRTC capability (even if just data-streaming) however. 
Overall, these trends have much more impact on the WebRTC market than the wrangling over codecs, or even the offer-answer/SDP debate. What is happening is that there is now sufficient critical mass of effective, open-source or commercial enablers, that WebRTC or WebRTC-like development is taking on a life of its own. If the official, browser-based standard still faces a lot of arguments..... well, the dirty secret is that it doesn't matter, unless you're someone form whom native apps vs. web is a religious argument you feel evangelical about.

If you would like to get access to the new forecasts, and indeed the original Disruptive Analysis WebRTC report, details about purchase are available on this page. (Note: my travel schedule may mean it takes slightly longer to get content out to customers).

I'll also be at the December WebRTC event in Paris, so I hope to catch up with everyone there.

Monday, November 11, 2013

Mobile data traffic - some quick thoughts on Ericsson's latest update

Ericsson has just published the November edition of its Mobility Report.

I'm just going through a couple of stand-out items, especially about mobile data traffic. There's some good stuff about subscription growth, "app coverage" and small cells, but that's for another post.

Ericsson reckons that global mobile data traffic grew 10% quarterly between Q2 and Q3 2013, and 80% from Q3'12 to  Q3'13. The chart seems to suggest the beginnings of an S-curve tail-off in growth - the previous June report suggested 19% growth quarterly Q4'12-Q1'13, and the chart suggests c15% for Q1-Q2. The February report cited 28% quarterly growth for Q3-Q4'12. That said, the growth rates are quite "lumpy", although the last quarter showed the slowest growth in 2 years by a considerable margin.

Quarterly Mobile data traffic growth from previous Ericsson Mobility reports
Q4'11-Q1'12 = 19%
Q1'12-Q2'12 = 14%
Q2'12-Q3'12 = c20% (read from chart)
Q3'12-Q4'12 = 28%
Q4'12-Q1'13 = 19%
Q1'13-Q2'13 = c15% (read from chart)
Q2'13-Q3'13 = 10%

Overall, the global forecast is for a CAGR of 45% mobile data traffic growth between 2013 and 2019, with much greater traffic growth from smartphones, and comparative stagnation of mobile PC dongles, MiFis and the like. That's a slightly more realistic forecast than others have predicted, but I still think it's a too top-heavy, given the S-curve effect (ie quarterly growth has fallen from 28% to 10% in less than a year).

This forecast compares with Ericsson's earlier 50% CAGR for 2012-2018 - but in the June report, it said it expected 2012-13 growth to "continue doubling", which when calculated through implied the remaining 2013-2018 period to have CAGR of only 41%. It's possible that the shift to LTE (which often comes with bigger data buckets in plans) might drive a "double-S", but there's limited evidence of that so far.

My main problem with the analysis, is that the chart on page 11 suggests that smartphone mobile data subscriptions will triple between 2013 and 2019, and that average usage will simultaneously grow about 3.5x. I think that is unsupportable, as the next 3 billion smartphone users will be late adopters, often in low-ARPU markets with parsimonious data plans (or more likely, sporadic prepay top-ups). It suggests that smartphone user #5 billion, coming online in 2018, will instantly be using gigabytes per month from Day 1, unless user #1 billion is using about 20GB/month by then to skew the averages. In almost all maturing sectors, the laggards & late-adopters tends to be low, casual users. This suggests that Ericsson's forecasts are over-cooking things substantially.

Ericsson puts 2013 mobile data traffic as 35% video, and is predicting that to go to 50% in 2019. But interestingly, Cisco VNI had video at 50% in 2012 and forecast 66% by 2017. To my mind, that's partly because "video" is a useless concept bundling in hundreds of arbitrary and different elements - streaming, downloads, uploads, 2-way communications and so on, not to mention mashups (is Vine a video application, or social? How about sharing videos on Facebook?)

There is little mention in the report of the increasing use of (non-operator) WiFi on smartphones, which is up to 80% of total device use in some countries, even excluding WiFi-only tablets. There are a couple of mentions of "WiFi offload" being excluded, but as offload is probably (at most) 20% of total smartphone WiFi compared to private incremental non-offloaded use, that suggests that the numbers have very significant downside sensitivity, as free amenity WiFi proliferates around the world. Even in developing markets, it is common to have free WiFi in various public locations such as cafes, and savvy price-conscious users can be expected to exploit this, rather than paying for dataplans or prepay data credit where possible. In some countries, WiFi use is also increased by the risk of smartphone theft if the devices are used openly in the street - instead, people use their phones mostly indoors, in more secure (and WiFi-rich) environments.

Taken together, I'd say that Ericsson's numbers are starting to fall into the realm of sanity (unlike the continued breathless "exponential" hyperbole I heat in many presentations), but the forecasts are still too optimistic, given what we're seeing with both typical data allowances, and WiFi use. I haven't done a full analysis, but I suspect that a global mobile data traffic CAGR in the range 35-40% for 2013-2019 would be much more realistic, translating to perhaps 30-35% in developed markets and 40-50% in developing.

Tuesday, November 05, 2013

VP8 acceleration hits the mobile phone in time for IETF88

Following on from Cisco's open-sourcing pitch for promoting H.264 in the big WebRTC codec debate, it's now Google's turn to turn up the dial on VP8. [My take on Cisco's move is here]

One of the biggest stumbling-blocks cited for VP8 so far has been the lack of any mobile optimisations - specifically hardware acceleration in smartphones or tablets, necessary to avoid battery-sapping processing for VP8 video done in software.

But with what surely cannot be coincidental timing, Google has announced that its new LG-made Nexus 5 phone comes with - drum roll - hardware encoding/decoding for VP8.

According to this chart, it's a native feature of the chipset in the Nexus 5, which is based around a spanking-new 2.3GHz Qualcomm Snapdragon 800 as a CPU, and Adreno 330 GPU. This marks the first time that Qualcomm has appeared as clear enabler of WebRTC & VP8, as far as I'm aware.

The chart also points out that as well as the Snapdragon 800, there are also VP8-supporting chips that do encoding & decoding from nVidia, ST-Ericsson and Rockchip. But given its share of high-end phone chips, I've long believed that Qualcomm is something of a potential "kingmaker" when it comes to codecs and, ultimately, the ways in which WebRTC will manifest on mobile. If this is what it seems, then it is highly significant.

Other phones/tablets announced with the 800 include:
- Samsung W2014 dual-screen flip phone
- Samsung Note 12.2 tablet
- Samsung Galaxy S4 LTE+
- Sony Experia Z1S
- Asus Padfone Infinity

Overall, it looks like the usual mantra of "phones only support H.264" is now obsolete - especially as Apple is pretty stingy with providing access to its video acceleration APIs anyway.

Monday, November 04, 2013

WebRTC codecs & Cisco open-sourcing H.264

It's gearing up to be a busy week in WebRTC-land. In particular there's the 88th IETF meeting in Vancouver, and up for discussion and hopefully finalisation is the thorny issue of WebRTC mandatory video codec(s), with the main candidates being H.264 and VP8 this time around, but with H.265 and VP9 hoving into view in the near future as well.

Quite a lot has already been written on this topic, including by me in the October 2013 report update which has recently gone out to subscription clients, plus numerous other blogs and pundits, such as the guys at WebRTChacks who came out with a great post listing the various options last week.

But then a few days ago, Cisco Systems set the cat among the pigeons with its announcement it was open-sourcing its H.264 codec and paying the MPEG-LA royalties for anyone else who wants to use it, as long as it uses it in the form of Cisco's binary distribution. For those that want to use the Cisco source code to build their own binary however, there will remain a royalty liability. 

There's a ton of great analytical blog posts around already on Cisco's move, including by Tsahi, Chris KoehnkeDave Michels, WebRTCHacks and assorted great comments from Lawrence Byrd. 

I'm hoping to make some different points, especially about mobile WebRTC and non-browser implementations.

In my view WebRTC is inevitably going to divide along an important dimension:

  • Use-cases that need interoperability with “other stuff” (eg existing videoconferencing, enterprise UC systems, telco SS7/IMS etc)
  • Use-cases that are perfectly fine as standalone islands (eg a karaoke app, business walkie-talkie apps, or a customised video-chat service). Some of these will be P2P, but many will be server-based as well.

At present, it is hard to determine whether the future balance of importance & value is 20/80, 50/50 or 80/20 around interoperability vs standalone use-cases for WebRTC. It could go either way, and will be influenced partly by the way the industry and standards are set up in the near future. My view is that standalone uses will generally be more innovative (as is already being see with datachannel uses for WebRTC), but interoperable ones probably have easier near-term revenue pathways.

Clearly, Cisco would like to tip the balance of WebRTC towards the interop-rich use-cases, especially given its large installed base of H.264 (and also SIP) end-points. Cisco's open-sourcing move improves the ease of creating interoperability-based use cases, for example corporate videoconferencing systems extending out to browsers as additional end-points. It should be noted, however, that interoperability needs more than just codec similarity - a ton of other signalling and security issues will likely mean that gateways and SBCs are still essential, even if the theoretical transcoding burden is reduced.

However, interop is not the sole motivation, important though it is - and neither, really, is the financial benefit of H.264 royalties for the patent holders. What is also important to them is restricting the growth of new, competitive greenfield services and apps, which work best as low-cost islands - based around open-source software and (ideally) completely unencumbered codecs. Because H.264 works best with the current status-quo endpoints, it also favours current status-quo vendors and business models. It also helps to lock in H.265 as the future codec of choice, rather than VP9 or Mozilla's Dalla.

This is one reason why, in Disruptive Analysis' view, IETF should not go with H.264-only as the MTI codec, but should also add VP8. Just as there are two audio codecs (G.711 and Opus), there should also be two video options, to enable a level playing field between old and new participants. And to assure a "fair fight" between VP9 and H.265 - something which again, may skew the world between open/unencumbered and royalty-bearing. 

This is especially true as the MPEG-LA licencing regime is aimed very much at the traditional media industry in terms of streamed video, rather than application developers using new forms of communication. The 100k user threshold at which H.264 royalties become payable typically means a quite successful content or web company - but 100k users for a free mobile app is almost trivial - and almost certainly not profitable. The current licencing regime is heavily stacked against the small developer, and free/freemium models.

Consequently, next-generation developers will need an unencumbered video codec of one form or another - both for the desktop web, and for mobile apps.

Indeed, all the discussion about Cisco's H.264 move assumes that WebRTC remains a single, web-based standard. But the other, little-discussed dimension here is whether WebRTC use-cases will be primarily based in the browser or not. My view is that on the desktop, WebRTC will indeed be predominantly browser-based, although we'll also see it appear in some standalone applications.

But on smartphones, tablets and other devices, WebRTC will primarily be embedded into native apps, or the underlying device OS, and not necessarily the browser. That is *especially* true on iOS, unless Apple suddenly changes its mind on WebRTC support in mobile Safari.

Let me reiterate that: on mobile devices, the bulk of WebRTC will NOT appear in-browser, but instead it will be in-app, with either the developer directly integrating the various WebRTC code modules (such as codecs, DTLS, SRTP etc) into an app, or being provided with a 3rd-party API and code libraries by cloud-comms player like TokBox or Tropo.

In my newest forecasts, from the middle of 2015, there will be MORE non-browser mobile implementations of WebRTC than mobile browser devices. There will be 2.3bn mobile devices with non-browser support of WebRTC by end-2016.

That means that WebRTC on mobile (especially iOS) probably cannot easily exploit Cisco’s H.264 offer. There needs to be a way for either standalone app developers to get access to iOS’ existing H264 (and iPhone hardware acceleration is not currently allowed under present APIs) or else there needs to be “BYOcodec” with the app. In other words, either a separate (and potentially royalty-bearing) implementation of H.264, or else VP8. My expectation is that future mobile chipsets will likely support hardware acceleration of both H.264/5 and VP8/9 - although whether the OEMs like Apple provide API access is another matter.

In other words, Cisco's kind offer will be irrelevant for most mobile implementations of WebRTC. That doesn't mean Cisco is being duplicitous here - just that it cannot, by itself, influence those forms of distribution and use of H.264, especially on iOS.
For this reason, Disruptive Analysis believes that in order of preference, the IETF should choose as MTI video codec:

1) [Best] H.264 + VP8, with a clear statement of intent on H.265 + VP9 for the future
2) An old, out-of-patent codec so that there's a minimum fallback option, but each app chooses its preferred codec as it needs to
3) No mandatory video codecs at all. Fallback is voice-only, unless an app specifically negotiates video.
4) [worst] Either VP8-only or H.264-only.

[Also - I've seen a couple of mentions on Twitter about  the idea of a mandatory codec selection API, rather than a codec itself. Also sounds like a good idea, but not exactly sure how it would work in practice. I'll keep an eye out]