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 3^rd-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.

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.

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.

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 Koehnke,  Dave 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]

For telcos, IMS integration should only be a small % of WebRTC effort

I've got numerous presentations and conferences coming up over the next couple of months, especially in Europe & SE Asia. Most of these touch on the themes of voice, WebRTC, unified communications and related areas. As a result, I've been giving some thought to my current views on WebRTC and its evolution so far in 2013 and critical angles for development in 2014 - especially where it intersects with the telecom service provider space.

My current thinking is that for many operators, their pace and breadth of innovation around WebRTC is too slow - and often (and ironically) confined to some of the more conservative-minded teams.

I don't want to pre-empt everything in my forthcoming presentations (and the new update for my WebRTC report subscribers) but there is one clear and critical message:

IMS interworking should account for no more than 30% of a telco's overall effort or investment into WebRTC. Further, the IMS/core network group MUST NOT have centralised control over a carrier's overall WebRTC strategy

For those operators that are pursuing IMS, either in fixed or mobile domains, yes it will be important to understand how to leverage WebRTC. It can potentially extend operator-branded VoIP to devices without apps or native support, for example - using a standard browser instead of a softphone or other dedicated client. 

This might be a help for VoLTE, by allowing users to use the same number/identity on (paradoxically) non-LTE devices such as WiFi tablets. It might reduce reliance on the still-clunky SR-VCC standard for switching from VoLTE to 2G/3G circuit telephony at the edge of coverage, if WiFi is available, too. Or allow innovation such as a "second telephony line", or even somehow enable non-telephony voice formats hook into an IMS platform. I'm not convinced this is the best way of doing any of this, and I'm also certain that not every operator will implement IMS anyway, but for those that do, WebRTC offers a way of making a legacy architecture a bit more 21st-century ready.

(WebRTC might also eventually help reduce the difficulty of rolling out RCS to some devices too - although the 17 or 26 other critical problems associated with that standard mean that it still has no chance of success).

But the important factor here is that even looking optimistically at IMS, it will not be the basis for the bulk of new services and revenue streams for operators. It has a role for some SPs in managing a more graceful decline of telephony from its historic peak, by lowing the cost base and maybe adding a couple of extra features. This has been seen with the fixed PSTN moving to NGN/IMS VoIP to replace creaky 30yr-old switches, and will likely be replicated in mobile with VoLTE. (Although here, the industry has been forced into VoIP by LTE not supporting CS voice, even though mobile CS infrastructure is often new and cost-optimised).

Either way, WebRTC-enabling VoLTE or other IMS services will not occur at "web speed". Although we're seeing a ton of gateway solutions emerge from all the big vendors (ALU, Ericsson, Genband, Huawei, Oracle etc), that's only part of the puzzle. There's still a ton of work to do around service creation, testing, regulatory compliance, market research, OSS/BSS integration and all the usual telco paraphernalia which extends launch cycles out to years rather than months. WebRTC might simplify development of device-side clients/apps, but it won't short-circuit the internal legal department's process of signing it off.

But most new services that telcos should be focusing on - whether they relate to content, IPTV, next-gen messaging, home automation, telco-OTT, banking, healthcare, corporate UC, videoconferencing and so on - will almost certainly not be anchored in IMS. They will run on separate platforms, often cloud-based, web-based and/or partner-based.

It is critical that all of the various telco business units and teams that are doing service development have their own views and autonomy when it comes to WebRTC. They should all be experimenting and prototyping using whichever tools and platforms make sense. WebRTC responsibility must be decentralised across a telco's portfolio of efforts. They should use 3rd-party APIs and SDKs, work with Internet companies, use pre-standard tools and platforms, create separate identity spaces and so forth. The same is true for internal processes at the operator - BSS/OSS, HR, field force automation, internal communications/collaboration and so on should all be looking at how WebRTC can enhance their activities.

But these activities should happen independently of whatever is going on in IMS, the Labs & the Core Network. The peripheral innovative business units must "distintermediate" their own core network if necessary - and be must given C-level "air support" when they do it. If they don't, they will lose relevance and opportunity, waiting for the slowly-grinding wheels of IMS/WebRTC integration to catch up. Which they probably won't for some time, if ever.

If and when the telco's IMS/WebRTC platform is equal to other choices in terms of flexibility, performance and planned future evolution speed, it should be considered for migration. But not before - it is not a "special flower" from the perspective of the group thinking about enterprise videoconferencing, or turning next-gen music streaming into karaoke, or considering adding realtime sensor data-collection to home-automation propositions.

The bottom line is that for telcos, WebRTC is a lot more important for IMS, than IMS is important for WebRTC. By all means pursue the extension of VoLTE or whatever - but telco CTOs (and, frankly CEOs and CFOs) must make absolutely certain that the bulk of WebRTC initiatives and investment are made outside of the stifling conservatism of the IMS mindset.

Amazon's Mayday may signal its long-awaited WebRTC strategy

One of the things I've been waiting for is Amazon's foray into the world of WebRTC.

I've been wondering whether it would be simply adding the ability to speak to a customer support rep on the main website, to other users about product reviews - or perhaps the other way, as a competitor to APIs from TokBox & Twilio & Tropo, or as a hosted media/TURN server offer as part of Amazon EC2 or its other cloud services.

We still don't have a full story. But we might have a hint, with the new "Mayday" button on the Kindle Fire HDX (article here) which offers live tech support including one-way voice & video. You can see the Tech guy, but he can't see you. However, the data streams are two-way so the support agent can do diagnostics and so on.

At the moment, it's a little unclear what technology is being used either between the Kindle and the Amazon data centres, or internally within the contact centre facing the agent. It might be WebRTC or a close relative, but nobody's saying one way or the other yet.

However, there are three interesting angles to this:

a) It's a great idea from Amazon which will improve customer convenience, and potentially increase sales (albeit with extra costs of employing agents)
b) It further "democratises" the idea of embedding voice and video capabilities directly into applications and devices, for purposes other than a "phone call". This is a good thing for the WebRTC community, as it opens more eyes to what's possible - and, specifically, that embedded/contextualised comms is going to gradually steal share from "standalone" models of speech or video.
c) Amazon tends to "platformise" its internal technology. It designs and builds its systems in a way that it offer them externally as well, gaining both external revenues and reducing its own unit-costs by spreading them over greater volumes. That's what's driven EC2 and AWS business models, as well as numerous lesser-know platforms that Amazon provides for e-commerce, web-hosting and even physical logistics/warehousing. I remember hearing the CTO give a speech where he talked about building things "inside out".

So... I wonder if Amazon's big WebRTC play *isn't* going to be around technology, such as hosted virtualised gateways on AWS (although that might happen with partners, as it has historically with Flash media servers). Perhaps it isn't going to compete in the contested WebRTC API/SDK space with AddLive & TokBox and the growing range of other cloud players either.

Perhaps it's going to be a more generic "Video customer service & diagnostics"-as-as-service player. (MDaaS or Mayday-as-a-service is probably a snappier name). If this works well on the Kindle, imagine what other devices or applications could benefit from an Amazon-powered Mayday button. Certainly makes a bit of a difference from a generic "call me" button that is a mainstay of WebRTC today.

Just as LiveNinja has used WebRTC to build a generic "consult with an expert" platform, maybe Amazon will be the leader in WebRTC-enabled "interactive tech support". Or, perhaps "almost WebRTC" if they decide they can do better than the official standard for this specific use-case. The nice thing here is that nobody has to be purist about WebRTC, especially for "silo" applications. It's not like something like Mayday needs to interop with legacy SIP services - so its creator is free to use whatever works best, and the user will neither know nor care if it's WebRTC, Flash or magic pixies making it all happen.

Also worth noting that Amazon is doing a lot of stuff around voice recognition and virtual assistance as well, so maybe they'll front-end it with a new flavour of IVR, but with the V standing for video, not voice.

True personalisation for broadband & Internet access: The "Insurance" business model

I drive an unusual car. I live in central London, but unusually have a garage. I've never had a speeding ticket or major accident. I'm male, in my 40s, and work as a telecoms consultant. I drive less than 6000 miles a year. I can be considered an "enthusiast".

All of these are risk factors that insurance companies number-crunch each year, before offering me their annual premium. Some companies decline to offer cover. Some companies specialise in assessing various of the risk factors above, and can price keenly. Some have "live" agents & underwriters involved while others just use an online form and a big computer. They have different tweaks and tunes, such as levels of cover and varying excess (deductible) fees if you claim. If you have an accident/claim-free year, they will probably offer you a discount next year and beyond.

And that's the insurance industry's approach to pricing. It uses something similar for home insurance, health insurance and so on. The details of what and how prices are calculated vary by country, based on culture and law (eg in Europe they're not supposed to discriminate prices based on gender despite women generally being lower risks).

Telecoms, on the other hand, prefers the subscription-based model, with published price plans and perhaps a few add-ons, as well as overage and so-called value added ("out-of-bundle") charges like roaming.

Yet at the moment, much of the telecoms world is:

a) Suffering from a decline of the services which lend themselves best to plans (calls, SMS etc)
b) Trying to work out how to price broadband, given rising usage and declining costs of infrastructure, and a messy relationship between the two.
c) Trying to work out how to balance broadband and Internet access value, perhaps with additional services such as IPTV or new "managed services" completely separate from vanilla, Neutral Internet access (as I wrote about yesterday).

Also, as my colleague & erstwhile debating partner Martin Geddes points out, certain network behaviours (and applications) are worse "citizens" than others, creating problems and congestion. "Greedy" applications can almost be thought of as denial-of-service attacks on other users, consuming excess resource and causing "stationarity" problems. Something similar is true for mobile devices with poor transcievers, or even location - if you live in a basement, you probably consume more of your "fair share" of radio resource than someone on the second floor of a building with big windows. Then there's consideration of signalling (eg on/off applications always ppinging the network) as well as traffic volumes, and so on.

So maybe the telecoms industry should take a leaf out of the insurance companies' book.

Instead of getting a monthly subscription, you get quoted an annual "broadband premium". Watch lots of YouTube over LTE? Access Facebook 74 times a day from your smartphone? Drive a knackered old phone with a lousy radio chip? Download 20MB of emails at 9am in Kings Cross Station? Then sorry, but you're a poor broadband risk, and your premium is going to be really high.

The interesting thing is that if there's enough competition at a retail level (eg with MVNOs or new forms of wholesale), there ceases to be a need for full "transparency" on pricing. Each operator collects its own set of variables, crunches it through its own algorithm, and comes up with a personalised quotation. It also analyses your real usage and "risky online behaviour" to refine its premium next year. Maybe we see the emergence of companies similar to credit-scoring that rank your broadband social/anti-social scores.

Yes, there would need to be a whole range of safeguards put in place. It wouldn't be a direct copy of the insurance business. But it would certainly be a more interesting - and perhaps fairer - way to price broadband and Internet access services. (There would probably need to be assorted regulatory changes too, I know, as well as privacy challenges).

My general view is that business models - and revenues - are driven by the OSS/BSS function in telecoms. Network innovation and network-resident policy functions there to enforce certain things, manage/optimise some others, and monitor and measure statistics - but is not at the core of business model innovation. You only need to look at the years of futile and failed attempts to use DPI and PCRFs to create so-called "application-based" plans. By all means instill more intelligence in the control-layer of the IP core to manage costs and aspects of customer experience - but that's not where the revenue side of profitability will stem from.

And from the OSS/BSS side? You've been talking about "personalisation" for years, and more recently "big data". The problem has been that personalisation hasn't really been personal ("what bolt-ons do you want to buy, based on a central core plan?"). The insurance approach would need very big data to be effective, and would by definition deliver completely personalised prices.

Now yes, I know all this is a bit of a straw-man. It would be hellishly difficult to do, especially with legacy networks and legacy charging/billing systems. But I'm really curious about whether people could actually see it working, if we started from a green-field situation.

Sidenote: this is the type of properly "out of the box" thinking you get if you employ Disruptive Analysis as a consultant or business advisor. You might not agree with all the ideas - but the point is to stimulate *real* business-model and technology innovation, not just a warmed-over iteration of the last century's ideas. Contact information AT disruptive-analysis DOT com. Don't Assume.

EU Net Neutrality Laws: Kroes must ignore ETICS/ETNO proposals for sending-party pays on the Internet

Note: I'm working on a separate full blog post about network quality, purpose, flow-management & the Internet (reflecting my frequent Twitter fights with Martin Geddes). This is a specific set of comments about European Net Neutrality and the upcoming draft law coming from Neelie Kroes at the Commission.

There is something of a battle of words/blog-posts going on between the Commission's spokesman Ryan Heath and a Net Neutrality advocate called Jeremie Zimmerman and his organisation Quadrature du Net. It centres on a leaked draft of the upcoming European telecoms laws which will govern (article 20) network traffic management and related issues. In particular, the debate centres on the concept of a European "specialised service" or "Assured Quality Service" or ASQ, which appears to be some form of prioritised data traffic.

My perception is that Kroes is trying to find a way to allow certain (limited) ways to let telcos offer differentiated broadband services, but without reflecting the idiocy of earlier proposals' like ETNO's attempts to enforce termination-type regimes on the public Internet. I think Kroes (and telecom vendors) are doing a poor job at articulating the idea that such managed services would be for "new broadband use-cases" such as broadband-connected health monitors, environmental/fire sensors, CCTV, corporate homeworking or whatever.

Most discussion seems to centre on the perceived risk of Facebook / Google / Broadcasters etc buying "priority lanes" to the detriment of other web startups. This is a pointless and irrelevant strawman argument.

Personally, I think Hell would freeze over before FB or YouTube or the BBC actually paid for users' traffic or QoS, unless forced. The so-called sending-party pays / 1-800 model for mobile apps or even most fixed-line TV services is an unworkable myth, as I elucidated in last year's report on the topic. It's much more likely that telcos will end up paying Google for premium server access, than vice versa as long as decent Neutral Internet access is provided at the same time, as a pre-requisite.

A lot of this confusion relates to the continued conflation of the terms "broadband" and "Internet" by many in the industry. I wrote about this important semantic difference here.

The intent of any new Net Neutrality legislation must be to ALLOW & encourage the creation of new non-Internet broadband services, but to DISALLOW any attempt to change the current business model of the Internet, which is working fine. In other words, it needs to be framed in a way to help create NEW revenues and opportunities for network operators, without allowing them to restrict or tax the current businesses of Internet-based content and apps players.

My view is that the contended document from the Alcatel-Lucent led project ETICS is a prime example of what must NOT happen. It is written from the same flawed school of Internet Economics as the risible "sustainable Internet" nonsense from ETNO-sponsored consultants ATKearney a couple of years ago. ETICS utterly fails to make a clear distinction between the Internet and any new forms of QoS-managed access. I would hope that the European Commission treats it with the contempt it clearly deserves.

The ETICS model might be a feasible idea for separate non-Internet access based services (although I doubt  the commercial & technical practicality), so I have no problems with it being tested, as long as it is done in a fashion to "quarantine" it away from today's Internet. If it's successful, it will need to win from adjacency on its own two feet, not be superimposed on the existing Internet access/peering business.

My view is that prioritised data / managed services are OK as long as:

1) They are kept completely distinct from Internet access (ie are delivered from servers with a direct connection from the telco's infrastructure or elsewhere, not transiting the public Internet)
2) They are not branded as Internet services, or sold in a bundle with Internet Access. This may mean that they also cannot share the top-level brand with an Internet-based content or application source (ie no "YouTube Premium", but something like "GasCo Energy Meter & Control" or "FireCo Sensor & Alarm Service" would be OK). Possibly, this could be done by disallowing such services to use the Internet DNS, or perhaps prohibit them from running within normal Internet browsers, or on apps delivered from Internet App Stores. They need to be ringfenced from the public Internet as far as possible.
3) There is no or limited implicit negative/deprioritising effect on Internet Access concurrently running on the same access/transport connection, arising from the use of managed services by the same customer or their neighbours
4) There is no attempt to create something that looks like a "termination fee" model for public Internet services. Either the user pays for specific managed services (like IPTV today) or perhaps an upstream content/app provider is allowed to pay (eg an employer paying for home-workers' connection) as long as it is 100% clear that the service is not related to the Internet (see point 2)

As Martin Geddes will no doubt point out, point 3 is mathematically and technically very hard/impossible. That, however, is not the EU's problem - it is vendors' and operators' problem if they want to offer such services. I propose that a very simple legal approach is used - managed services should ONLY be sold by telcos on networks which provide Internet Access with guaranteed minimum speeds & maximum latencies, not those marketed with maximum speeds. As long as the customer is guaranteed a decent minimum level of open, best-efforts Internet (howsoever delivered), then the rest of the broadband service is fine to experiment with.

Yes, within that Internet connection there's the same vagaries from all the various Internet applications fighting for capacity, but that's fine. The technical implementation of this can be left up to the operator - could be a cable MSO using separate dedicated RF frequency bands for Internet vs. non-neutral services; could be using some clever contention/policy-type software & network kit; could be lighting up two fibres or separate wireless connections and so forth. It doesn't matter - the bottom line is that all this happens without the user's Neutral Internet access being notably affected from today's model, except the telco has to provide a guaranteed minimum speed/latency as an SLA (measured appropriately, perhaps with a standard benchmark set of apps determined by the regulator).

It's quite possible that all that is too hard. In which case, the operator concerned (outside Finland at least) always has the option of just not selling Internet access at all.

To reiterate - I'm looking for Kroes and the Commission to articulate a way to allow the creation of new, ringfenced and clearly-labelled managed broadband services. But there needs to be extremely clear safeguards and harsh sanctions to protect the availability, price and usability of today's as-neutral-as-possible public Internet alongside. There needs to be clear blue water - in branding, marketing and technology - for any non-Neutral "specialised services" compared with the Internet. The Commission must ensure that telcos and their vendors avoid both consumer confusion and duplicitous or clumsy ETNO-style attempts to alter current Internet business models.

Quick thoughts on Microsoft + Nokia acquisition

So... I called that one very wrong indeed. I've consistently laughed at the notion that Microsoft would acquire Nokia, as it seemed such a strategically stupid thing for it to do (for Microsoft at least).

I suspect Steve Ballmer thought the same way as me - hence his decision to retire last week. I'm bet that the Board (& presumably Bill Gates) had some "robust" discussion about this.

[Note - technically MS has actually just bought the Devices & Services unit; Nokia remains as an independent company with a 148yr history]

Some quick thoughts (mostly ones that I think other analysts won't cover):

• MS has decided against following Oracle down the trend towards "IT-isation of the network" by leaving NSN out of the deal. Wouldn't surprise me to see IBM or HP step up to the plate, though.
• But on the other hand, it now has a ton of Oracle-powered (ie Java) devices in its portfolio as it's picked up Nokia's featurephone business as well as smartphones
• On the other hand, this reduces any fears that the Windows Phone / Lumia line could suffer mid-term if Nokia's finances had worsened. MS will be able to put its full marketing/distribution muscle to use
• This is mostly irrelevant to anything that Skype is/will be doing, although I'm sure plenty of people will insist that 2+2=5. (Sidenote: Skype is more about extending enterprise comms with Lync, as well as integration with X-Box, Office & Outlook)
• So, the "big guys" for integrated consumer software/device/app ecosystems are now Apple, Google and Microsoft, with Samsung and maybe Sony playing in "everything but an OS". Will be interesting to see if Amazon or Huawei try to crash the party as well (via BlackBerry or HTC perhaps).
• It's entirely unclear if this acquisition helps or hinders Microsoft in the tablet space. WinRT has been pretty pointless so far.
• This isn't especially helpful from the perspective of WebRTC, as it further entrenches the Chrome vs. IE vs. Safari/iOS divide. That said, Nokia has been quite keen in the past as it tends to be fairly web-savvy. Wonder if we'll see Samsung get friendlier with Firefox or maybe acquire Opera?
• Expect a whole new round of IPR lawsuits now that Nokia's patent portfolio has been detached from its devices business. Microsoft has got a licence, but has (wisely?) decided against fully entering that fray as a patent owner.
• The line "will draw upon its overseas cash resources to fund the transaction" suggests that this is partly a tactical move to reduce taxation of repatriated profits
• Qualcomm's role of silicon arms merchant (or indeed ARM merchant) to all the main handset families is underscored here.
• Nokia's huge (and in some places still-loyal) footprint of featurephone users *might* be leveraged to give the flagging PC market a boost, if it can convince them to leapfrog low-end Android tablets and get proper computers instead
• MS has licenced the Nokia brand & will use it to "extend its service offerings to a much wider group"... ie people who don't know/understand/see relevance in the Windows brand, especially non-PC owners.
• The remaining bits of Nokia are actually quite interesting/cool when viewed as a "new company" - a reinvigorated NSN facing the shift to NFV/SDN, the HERE mapping unit and its R&D/patent unit. It's got rid of the stuffy old phone business and can now concentrate on the cloud, where all the action is going to be
• This also means that "New Nokia" has a bunch of new prospective clients, notably Apple (which let's face it, could use some decent maps)
• There will probably be some truly horrible attempts to combine Lumia + Xbox in a couple of years' time
• This will have near-zero effect on Microsoft's enterprise business for the foreseeable future. I can't see corporate users switching en-masse to Windows Phone, especially in the era of BYOD

I'll try add to this as other things come to mind. But overall, this is much more positive for "New Nokia" than it is for Microsoft, in my opinion.

WebRTC & carrier WiFi: a similar story of "desirable fragmentation" for telcos

I cover two main areas of technology at the moment, accounting for about about 80-90% of my work:

•  Personal communications (voice, messaging, video, WebRTC, VoLTE, RCS etc)
•  Wireless networks (LTE, WiFi, policy management, regulation, Net neutrality, EPC, spectrum etc)

In particular, I've recently done a lot of work on WebRTC including various conferences and my research report/updates.  Quite a lot of emphasis goes on the role that WebRTC may have within telecom operators, and the supporting tools such as SIP gateways needed to enable it. I also spend a lot of time thinking and writing about carrier WiFi, and the implausibility of many of the integrated WiFi/cellular models and standards, that many vendors have been pitching.

I've realised an important similarity between WebRTC and WiFi from the viewpoint of telcos:

Operators should pursue multiple strategies, in different parts of the organisation, for exploiting both WebRTC & WiFi - with the "official" 3GPP/GSMA view of the world being only one of those approaches.

So, WebRTC should not just be confined to the domain of telcos' Labs or IMS/core-network groups. It should independently be addressed within the enterprise team, telco-OTT initiatives, product/portfolio management, consumer digital services, IPTV, customer support, developer programme, incubator and other units as well. They should make pragmatic, rapid decisions based on whatever architecture, partner and vendor choices make sense in the near-to-medium term. 

They should not wait for an "official" strategy based around extending an IMS core to WebRTC, as this will likely take upwards of a year to get properly tested and launched, and any further extensions/new services will get mired in the usual telco bureaucracy. By all means, if the core IMS/WebRTC platform works (eventually) then consider porting all the new stuff across to it.

But it is critical for, say, the enterprise UC or conferencing propositions to start jumping onto WebRTC immediately, and not wait. They should look at partnering with existing WebRTC leaders that can offer hosted or white-label services, for example. Consumer-grade bundles should start integrating WebRTC features or applications as soon as they are available. Larger operators might want to follow Telefonica's lead with Tokbox, and acquire specialists that are offering developer platforms for WebRTC.

The key thing is speed - and avoidance of early lock-in to technical architectures like IMS. For some use cases, IMS/WebRTC might be the right approach in the medium term, or maybe longer (for example, when NFV/virtualisation brings down costs). But each application will need to be assessed on a case-by-case basis when it comes to WebRTC - it's far too early for one (as-yet-unproven) approach to be considered a default across the whole telco universe.

But the interesting thing is that this fragmented technical/commercial approach is also true of WiFi in telcos. There is an "official" line (in fact, two or three variants) about using technologies like ANDSF, Hotspot 2.0, IFOM etc, and creating some form of "seamless" integration with the cellular network. But there are also many, many other approaches to WiFi for network operators as well.

By all means, let the networks group within the operator "get on with it", putting WiFi into small-cells, trying to integrate with the EPC and policy infrastructure. But that shouldn't mean that other parts of the telco - enterprise, consumer marketing, M2M, digital services, roaming, government services, a standalone WiFi unit and so on - should be forced into the same technological decisions and timelines. They should make case-by-case decisions about their desired segments - and more importantly, the behaviour and characteristics of the customer base.

For example, while the 3G/4G network group might desire "offload" as the main use-case for WiFi, reducing the need for cell-splitting, backhaul upgrades or even spectrum purchase - the enterprise group or public WiFi group may have other thoughts. They may wish to deploy "carrier neutral" WiFi in a shopping mall or airport or office, where the client (the venue-owner) wants to provide equal services to all visitors and employees, irrespective of their underlying cellular provider. In many such cases, WiFi will be used in non-cellular devices such as PCs and tablets anyway, so having full network integration is pointless.

It may well also be that some teams within operators want to design new products around WiFi that are totally orthogonal to the 3GPP's views on policy-management and "seamless" access. They may be offering advertising services on a log-on splash screen, for example - actually monetising the "seam" rather than pretending it's an impediment. They may be finding value in analytics (eg where someone walked inside a store), ancillary functions like indoor location APIs, or a hundred other models.

Operators may well also want to partner in innovative ways around WiFi that are outside of the standards-based myopia - especially if they are pursuing wholesale or neutral-host models. Or they might just want to tactically resell (or bundle for free) a particular WiFi provider's services, without complex integration or roaming features. 

We may see application-driven WiFi - perhaps an operator's Telco-OTT VoIP service (based on WebRTC, obviously), which uses free non-carrier WiFi wherever possible, or offers easy/discounted payment along the same lines as Skype/Boingo. We may even see carriers partnering with companies like Google, which are developing their own WiFi footprint.

In other words, for both WebRTC and WiFi, carriers should not employ a one-size-fits-all mentality. There are multiple technology approaches, which fit better with specific commercial requirements for different use-cases. 

Operators should avoid the traditional mistake of assuming that the "official" architecture and standards are somehow special or better than more pragmatic alternatives. Those standards have to prove themselves in the market, not just be assumed as being a desirable end-point. They might well turn out to be in the end - but that needs to be earned and not assumed. In the meantime, operators should experiment with everything available - allowing diversity across their different business units.

This goes beyond WebRTC and WiFi as well. The rise in virtualisation, NFV and cloud platforms will further reduce the role of some technology standards in other domains in future. Telcos will reduce their reliance on across-the-board platforms in many cases, building/reselling services based on individual use-cases, rather than constraining them to specific technical architectures. I'll write more about this another time, but in general it maps on to my  view that "ubiquity is dead" in telecoms.
 

WebRTC: we're starting to see the "big guns" emerge into the real world. First up, Zendesk, Vonage & Siemens

While the internal WebRTC world has seen a lot of famous company names attending conferences, participating in standards bodies, issuing press releases, or selling tools, SDKs or enablers to each other, relatively few have actually put out "powered by WebRTC" products into the real world for users.

Obviously, Google and Mozilla have both launched browsers, but that doesn't really count as that's still an "enabler" rather than an end-user product or service. There's also a ton of plucky startups like Bistri, Solaborate, Uberconference, Twelephone and others that have entered niches like conferencing and social networks, but none have yet hit maturity or been seen as major disruptions to the status quo in their sectors.

Buy the Disruptive Analysis WebRTC strategy report & market forecasts - now including the Q2 June 2013 update

To my mind, there are now three "traditional" big players that have walked the walk, and put WebRTC into their mainstream products:

• Zendesk is a major player in SaaS-based customer support, enabling helplines or mail/IM interaction for big web companies and others. It has 30,000 customer companies and has facilitated support for over 200 million "customers' customers". It started to defaulting to WebRTC for voice calls a couple of months ago, on relevant browsers, while others still use Flash or other options. (It's worth noting that other startups such as Zingaya also have WebRTC-based B2C click-to-call buttons deployed for some large companies for support & CRM)
• Vonage created quite a stir at the WebRTC Expo in Atlanta last month. As one of the best-known VoIP players spanning home phonelines to mobile apps, it is the first of the big consumer communications brands to adopt the technology openly. It is also the first massmarket company to commercialise a non-browser, app-integrated variant of WebRTC, optimised for working on mobile devices. (Good interview with the CTO here). It's also pitching to provide white-label/partnered plaftorms for telcos. Outside the main scope of this blog post, but Vonage is apparently using the WebRTC Native Stack - the code mostly intended for browser suppliers - to build WebRTC into a non-browser app instead. It also claims several million users already, on both iOS and Android.
• Siemens Enterprise Communications is the first major enterprise UC player to throw its hat into the WebRTC ring with a (beta, pre-commercial) offering, called Project Ansible . At first sight, Ansible looks remarkably well-thought through, with social integration, fixed and mobile implementations, Hypervoice-type features ("Thought Trails") and, importantly, as much emphasis placed on design (courtesy of specialists frog) as engineering. The website discusses things like "joy of use" and "freemium models" - unusual for business comms tools from major vendors. Siemens has stolen a march on its big UC peers (albeit it with a beta) - despite Cisco being involved in WebRTC since Day 1, and an Avaya employee quite literally "writing the book". As yet, they haven't announced actual WebRTC products, though. Others like Microsoft are pursuing other strategies for now (Skype/Lync integration etc).

So what can we learn from this?

First, the "big guns" are now coming out of hiding (or at least, out of their labs). One is an outlier, two is a coincidence, but three is a trend. I'd expect many of the others in each of these categories' peer groups to start using WebRTC over the next 6-9 months.

Second, there are no telcos in this list. The closest we've seen to market-ready WebRTC offers from SPs are AT&T's API work, and Telefonica's OpenTok and Mantis tools/platforms for developers. However, we haven't yet seen an end-user telco WebRTC proposition, although Telefonica is "eating its own dogfood" with its use of the TokBox-powered Oscar videoconferencing application internally.

Third, a lot of real-world WebRTC use is going to be hidden. There may well be a bunch of companies - banks, healthcare providers and so forth - using WebRTC "under the hood" in their websites, perhaps using call-me buttons, or gateways from Thrupoint or Oracle or Genband or others, without trumpeting it to the wider market.

Fourth, although enterprise deployments are still in the vanguard for WebRTC, the emergence of Vonage's solution raises the possibility that consumer mobile apps will rapidly deliver millions of active users. It's not just Chrome and Firefox browsers that update easily or automatically - most mobile apps do as well. It only takes one major social network to adopt WebRTC - not even for "calling" but maybe something data-related or other video use-cases - and I'm going to be reworking my forecast model again. To my mind, Vonage has been the big light-switch for a lot of people - mobile WebRTC isn't necessarily going to be browser based, but embedded into apps.

Fifth, startups are going to have to either act fast or differentiate solidly. Incumbents in most WebRTC-centric applications aren't going to be taking years to procrastinate and respond to disruptors. This puts a premium on marketing, distribution and sales, especially where newcomers are pitching directly against established players - videoconferencing, I'm looking at you! (I'll reserve judgement on some of the telecom use-cases' ability to accelerate though: let's see what happens).

Overall, it's good to see well-known players like Zendesk, Vonage & Siemens adopting WebRTC. It gives gravitas to the market and gives something for a couple of naysayers to chew on. 

Let's see who's next: my money would be on the other UC vendors looking to spike Siemens' guns with brought-forward announcements, although we could conceivably see a VoIP/IM brand like Viber or Whatsapp surprise us as well.

If you're reading this and want more details about Disruptive Analysis' predictions for WebRTC, you should definitely buy the report - now available including the Q2 June 2013 update.

Broadband, Internet, Voice, Telephony, Messaging etc: Words & semantic matter

I had two conversations about fax machines and security-alarms yesterday.

Very 1980s, you might think. Yet both cropped up in conversations about FTTH, IP networks and the future of communications. My two discussions were with colleagues and peers Benoit Felten and Martin Geddes.

The conversations highlighted the importance of a few words that we use in the telecoms industry without really thinking what they mean properly. "Phone lines", for example, are not just used to make phone calls. Obviously they are used for DSL too (more on broadband below), but also fax machines, alarm systems, point-of-sale terminals, elevator emergency phones and all sorts of other things.

Historically yes, phone calls have been the main use of narrowband phone lines. But as telephony revenues fall ever lower, and we start to look at IP replacements via fibre or perhaps wireless, a bunch of other issues start to become disproportionately important.

"Oh, we can run fax over IP if it's really needed". Yes, true - but what about fire alarms & the elevators? Even if those systems can be reworked over IP, what is the cost of switchover? How much does a "truck roll" for the safety certification guy from Otis cost?

So it's worth being careful about talking about switching off the "phone" network, as it's not just about phones.

Similarly, I've often drawn a distinction between "voice" and "telephony". Apart from a little bit of push-to-talk, and maybe conferencing, telcos only do the latter. They don't have "voice" revenues, they have "telephony" revenues. There's a broad and growing set of voice communications models and applications that are nothing to do with phone calls. However, few executives - or regulators or investors - have quite woken up to this yet. Given the likely downward trajectory of telephone revenues (including mobile calls) over the next few years, this is going to become suddenly important.

The ways we manage, record, bill, present, regulate, intercept non-telephony voice is currently off of most peoples' radar screens. Do we need 911 and lawful-interception for baby monitors, business "hoot'n'holler" intercoms, networked karaoke or in-game chat? Do we count baby gurgles and songs in minutes and report the stats? Will PRISM have to listen to the snores of someone under remote-diagnosis for sleep apnea?

Broadband vs Internet is another critical semantic distinction. Internet access is just a very specific - albeit special - application of broadband access networks. For consumers, broadband today often also has carrier VoIP and IPTV delivered alongside Internet access, and in future we may get various digital lifestyle services, remote metering and so forth delivered, which do not transit the public Internet. This has implications for both how we quantify economic costs and benefits, but also how rules such as Network Neutrality get applied. Sloppy use of the wrong terminology can lead to poor investment and regulatory decisions.

The Internet/Web distinction is well known but also widely overlooked.

"Messaging" is a fairly nebulous concept too, as I've discussed before.

Lastly, we have "mobile" which can refer to mobile networks (3G/4G cellular vs. WiFi), mobile devices (smartphones yes... but are tablets "mobile"?) or mobile users (moving about vs. nomadic vs. stationary). Whenever you see stats claiming "X% of web use / data traffic / Internet users is mobile", you can guarantee that there's no clear definition. Frequently, people will pick whichever definition gives them the largest number to try to make their point stronger. The argument that a WiFi-only tablet that never leaves the sofa - never mind leaving the house - contributes to "mobile web advertising" is somehow "mobile" is ridiculous.

Mobile vs. Wireless is another troublesome one, especially as the telecom industry has historically designed complex and expensive networks specifically to meet the needs of people "moving about", but then happily sold most of their services - and gained most of their revenues - from people who are wirelessly-connected but stationary. That was fine in the past, but is starting to be a questionable assumption as perfectly-good wireless networks start to become available for free as an "amenity" rather than a "service".

We've also got "application" which can means 100 different things depending on who you're speaking to. User vs. subscriber is good one too.

Overall, I think it is incumbent on all of us to become much less sloppy with our telecom semantics. In the past, the world was simpler and we could get away with saying "voice" when we meant "telephony". Lobbyists could conflate Internet and Broadband, twisting words to hide flawed arguments against Neutrality.

But now, the industry is facing laser-like challenges, as well as narrow and well-defined opportunities. Picking the wrong words, making flawed generalisations and comparisons, confusing subsets and supersets - all these will lead to poor decision-making and flawed analysis.

Think twice before you open your mouth....and correct other peoples' sloppiness and push them for definitions of what they mean.

What I'm looking for at this week's WebRTC Conference & Expo in Atlanta

I'm now in Atlanta, catching up from jetlag and preparing for what I expect is going to be a landmark event for WebRTC - probably the year's largest conference and exhibition on the technology, with rumours of 600+ attendees and a sold-out roster of sponsors.

I'm speaking this afternoon at the Business workshop along with organiser Phil Edholm, and fellow analysts Chris Vitek and Brent Kelly. I'm also moderating four panels over the next few days, on topics like SIP/WebRTC coexistence, WebRTC "game-changers" & the impact on telco business models. I'll also be on the wrap-up panel on Thursday, "beyond the call". Add to that being a judge for 50 or so 10-minute demos, numerous client meetings, briefings and dinners, and I think by the end of the week I'll be saturated in the current status of the WebRTC marketplace.

I've got a number of questions to answer, that I'll be looking for input for both directly and indirectly. It's often telling to see what people don't say, who is/isn't present, and meta-themes emerging when comparing multiple presetations or panel responses that gives a real clue.

Some of the topics to watch:

• EDIT (forgot the obvious!) is WebRTC going to be driven more by adding Web-based access to existing types of RTC, or by adding RTC to the Web? eg Web-enabling RTC = browser front end to UC, IMS, contact centre; RTC-enabling Web = click-to-speak on a B2C site, or a million niche things like streaming sensor data, or adding karaoke to a music-download site
• At the moment, I think enterprise use-cases have a narrow real-world lead over both consumer web & telco applications of WebRTC. Will that be sustained?
• How far are we from seeing real, innovative applications of WebRTC actually in the world and being used? I don't mean just using it instead of a SIP softphone or as a cheaper call-centre agent desktop, but something really unexpected or headscratching
• Is the datachannel aspect of WebRTC really the hidden gem?
• How can I categorise and segment the WebRTC Gateway vendor space? Who's real and who's just playing Powerpoint-and-press-release? It's getting really competitive, and I suspect it'll end up as a few big players, plus niche focused specialists, plus a lot of "WebRTC-as-tickbox-feature". And some dead me-toos.
• How can I categorise the API/SDK/cloud bit of WebRTC vendor-land? I've lost count of the number I've encountered here - between 10-15 I think. Is it all about mobile? Is anyone doing anything *real* with WebRTC cloud platforms yet, or will it take developers a few more months to churn out the good stuff?
• Any news on the "missing"? Microsoft, Apple, IBM, Samsung, Amazon - please stand up! Bonus points for anyone doing a WebRTC mashup with face-recognition camera & LinkedIn profiles to spot any stealthy undercover representatives.
• Which telcos are lurking around? Who's willing to actually pipe up  and say something beyond the usual culprits like AT&T & Telefonica/Tokbox?
• Who's here from Asia? All the signs are that WebRTC is under lots of scrutiny in China, Japan, Korea & Singapore. But little news on exactly what's being done....
• Where is Google taking all this? What can be inferred from what's left unsaid?
• Ditto for Cisco, Ericsson, Oracle - do they have big strategic games afoot? Or are they following the NSN & ALU view that WebRTC is just another front-end for IMS/VoLTE/(RCS)
• How much of the WebRTC vendor market will Open Source eat?
• What are the appropriate WebRTC market metrics for me to forecast in the future?
• Are my forecasts for devices support & user base growth too aggressive, or will I need to upgrade them again as I'm actually conservative?
• Will there be any seriously big unexpected announcements?

Plus also a couple of other topics I'm keeping under wraps, either for clients or my own research into WebRTC.

Overall, it's going to be a gruelling week, but by the end of it I expect to have got a much better "world view" of where WebRTC is, and where it's likely to be be by the end of 2013 and beyond. Feel free to come and say hello and/or chat over coffee or beer - and apologies if I'm dashing around like a lunatic for my next session.

On that topic: if you buy a licence for my WebRTC report before July 1st, I'll throw in the Q2 update I published a couple of weeks ago. And if you stump for an enterprise licence or a subscription to the updates (contact me for details), and I'll also add a 1-hour conference call to update on my thoughts from this week's show.

Details / payment here or else contact me via information AT disruptive-analysis DOT com

WiFi - the coming indoor vs. outdoor divide

I've been speaking to assorted vendors recently about their plans for carrier WiFi, linked to the usual rhetoric about Hotspot 2.0, ANDSF, so-called "seamless" authentication and so forth.

I still contend that a lot of this is nonsense - the mobile operators are only one group in an increasingly complex ecosystem of stakeholders interested in WiFi. The end-users, venue-owners, tenants, fixed/cable ISPs, device vendors, OS suppliers, content players, app providers, employers, advertisers and local government all have "skin in the game" with helping users connect to WiFi. Mobile operators are not "special flowers" among that group - and certainly have no likelihood of enforcing their will about when and where users will connect; much less charge them or subject them to onerous policy controls.

But I'm starting to spot a subtle distinction: indoor vs. outdoor use.

In an indoor environment,  users are used to WiFi being provided by their hotel, cafe, airport, home, office or other sponsor. Increasingly it is free, but perhaps with a small "hoop" to jump through such as watching an advert, or asking a barista for a code. Usually, the access point and backhaul are controlled by the venue or tenant, although a 3rd-party like a wireless ISP might be contracted to provide these. There will be an expectation that any person in that venue - irrespective of which cellular operator(s) they might use - will have access to WiFi, especially as many devices like PCs and tablets are WiFi-only anyway.

This is very different from outdoors.

Outdoors, people are properly "mobile", ie moving-about. They get access from only one provider - their cellular operator. Any other stakeholders like MVNO hosts, network-sharing consortia, site owners and so forth are hidden behind the "Operator X" logo displayed on the phone's screen. People accept and except that different operators will have different coverage, and that they do indeed expect "seamless" handoff from cell to cell.

Outdoors, the HetNet vision makes more sense - macrocell, picocell, femtocell - and, yes, maybe WiFi - owned and operated by the telco, may be used to provide decent data connectivity, as well as telephony and SMS.

While a few cities now have outdoor WiFi provided by a local council or company, that remains rare. People don't have expectations about outdoor WiFi behaviour the same way they do inside a building. A smartphone's WiFi essentially becomes a single-stakeholder environment (or two including the user) in the street, or perhaps a few special locations like aircraft.

In summary;

Indoor WiFi = multi-stakeholder, too complex for the 3GPP/WBA/OMA/GSMA model of operator control and network integration. Limited relevance of ANDSF, carrier-driven Hotspot 2.0, SIM authentication. Largely a UX problem.

Outdoor WiFi = fewer stakeholders, more chance for direct integration & seamlessness. Although complexities where the user could access WiFi as well as 3G/4G metrocells & macrocells. Largely a RAN/policy problem.

The other meta-problem comes from how to know when to switch from carrier-WiFi mode to multi-stakeholder WiFi mode as you enter or exit a venue. Linked to all this is a rather thorny issue of pricing and perceived value.

For many years, the mobile industry has assumed that "nomadic" use of its network was a core part of its proposition, as well as when users are "truly mobile". While that might have been the case for telephony - an indoor mobile call is "worth" as much as an outdoor one - that no longer holds true for data. The assumption (increasingly, although varying by country) is that indoor data is free - provided as an amenity, equivalent to air-conditioning or lavatories. Carrier-provided indoor WiFi will be accepted by end-users as long as it is not charged against data plans, or subject too stricter policy controls than "native" WiFi. This is going to be as much a challenge for billing & charging systems as it is for the network.

WebRTC partnerships and ecosystems

One of the things I'm expecting to hear a lot about at the upcoming Atlanta WebRTC conference & expo is partnering and the formation of vendor ecosystems.

Most enterprises and telcos putting together WebRTC solutions – even simple ones such as extensions of VoIP or messaging, or basic customer-service apps – will be reliant on multiple vendors. To this end, we are starting to see the emergence of several “ecosystems” or groups of partnerships. Disruptive Analysis views this as a critical factor for vendor success in the near term.

Some examples include:

·        Oracle/Acme works with Quobis & others

·        Ericsson partners with Mozilla

·        Crocodile is working with Telestax (Mobicents)

Over the next 3-6 months, expect to see many more similar alignments between complementary players, as well as further tactical acquisitions. Specialists such as Zingaya and Thrupoint are likely to carve important roles here, as well as a number of the API providers such as Twilio and AddLive.

I actually wrote the paragraph above in the quarterly WebRTC update I published last week for Disruptive Analysis research report subscribers. Looks like I scored a direct hit - Today I've just seen this announcement and demo from one of the companies mentioned - Zingaya - working with Cisco and another specialist firm, for a clever retail-banking WebRTC demo. See http://www.youtube.com/watch?v=hRbLnj4r71M&feature=youtu.be and more info at http://www.thrupoint.com/2013/06/thrupoint-cisco-syngrafii-light-up-mobile-banking-app/

I think this will be especially important for the growing number of vendors providing WebRTC gateways to telco or enterprise infrastructure. On its own, a gateway is going to be rather useless. It will need to be blended into particular solutions, with specific feature-sets optimised for particular use cases. It will also need to be deployed with the end-user experience in mind, and the realities of mobile apps as well. This will mean design and client-side expertise, as well as testing, security and assorted other realms of software and consulting. 

Few vendors - if any - will be able to do all of this on their own. And as yet, we haven't really seen big system integrators wake up to WebRTC, although surely that is just a matter of time. What will be important in the very short term is the establishment of concrete partnerships and developer ecosystems - I think that will be a key determinant of which vendors emerge as actual commercial winners, versus those with standalone me-too products.