The Number 1 problem for "seamless" models of WiFi offload / network selection

I frequently argue against the assumption that "seamless" connection to WiFi is practical or desirable, especially for the general case of smartphones or tablets being "pushed" automatically to connect via a combination of technologies and new standards like Passpoint, Hotspot 2.0, ANDSF and EAP-SIM.

I thought it was worth stressing and clarifying the single most problematic use-case:

Worst case scenario: A device automatically being connected to paid or overly policy-managed carrier-WiFi, when a free alternative is readily available

Nothing will cause customer dissatisfaction & churn faster than incurring additional costs (or additional usage against a quota) than this. Expect lawyers, regulators, consumer press & commentators to throw very large & painful bricks at you if it occurs. And probably device & OS vendors too.

The classic example that most readers of this blog will be familiar with is attending a conference in a hotel with expensive WiFi, but where the event organisers give you a free code, or even set up their own APs for better performance/lower cost. We'd be deeply annoyed if our phones "roamed onto" the local WiFi automatically, unless the usage was 100% free as well. Similar story if your frequent-flyer lounge has free WiFi, but your devices magically jumped onto the paid/roamed WiFi in the main airport hall.

I am writing this on a laptop, with two phones by my side, in Starbucks in London. There is free WiFi (provided by BT Openzone in this case). You typically log on via a very simple splash page and selecting an obvious Openzone-Starbucks SSID. A very small "seam" indeed. Alternatively, I can use the BT WiFi app I have on my phones for free, or login on the "normal" BT Openzone SSID page, because I have BT Broadband at home. I'd be irritated if I was automatically shunted to one of my CellCo's SSIDs instead, with their charging and policy being applied.

Same thing in hundreds of other situations too - restaurants, pubs, offices, friends' homes, public buildings and so forth. There is free WiFi - often very good too - easily obtainable from a source other than the cellular operator. There are multiple stakeholders here - the venue, advertisers, content companies, fixed operators, your device supply, your employer and so forth. All might have negotiated a better "private" WiFi experience than your cellular provider at that location.

Not only that, but the cellular WiFi option might be subject to onerous policy restrictions (eg VoIP blocking) which don't apply when you use WiFi in "private" mode. 

There must be an easy and obvious way to manage this - and not just buried 7 layers down in the menus with some obscure configuration settings. The alternative is that the carrier WiFi is 100% free, 100% unmetered, in which case people won't care about the other options. That is why Apple is happy with AT&T and some other operators doing automated WiFi log-on, as it's in a customer-friendly form. One other possible option is that the operator (instead of charging you) gives you extra free stuff such as exclusive content to tempt you onto its WiFi option.

Seams are often there for good reasons, as well as bad. Seams can be monetised; seams can present the user with important information or choices. In some cases automation and "frictionless" connection in desirable, while in other cases it's not. Mobile operators are just one (often minor) stakeholder in the overall WiFi ecosystem, and need to stop arrogantly assuming that their WiFi choices trump either users', or other parties. Unless and until Hotspot 2.0 and its related standards fully and explicitly recognise these choices, it's dead in the water.

WebRTC - how to get support into old browsers?

I'm currently updating the WebRTC forecast model used in the Disruptive Analysis research strategy report & update subscription service. A core part of it examines the likely penetration of WebRTC capabilities into different classes of device, via browsers or other paths.

Most in the industry will know that Chrome browsers already support WebRTC switched-on by default (albeit in its current pre-standard form), with Firefox support close behind in its Beta version. There is much speculation about if/when Apple and Microsoft might follow. I've got my own views on that, with my assumptions stated and baked into my forecasts.

But there is a critical difference here - there is a very large legacy installed base of IE browsers, and to some extent Safari as well - that doesn't auto-update to the latest version. IE9, 8, 7 and even 6 are still lurking around, especially in certain countries either with lots of old PCs, or for corporate users whose CIOs lock down application updates and installs.

How is WebRTC going to be extended to those last hold-outs, even if IE11/12 or future versions of Safari support it?

One option commonly discussed is Google's Chrome Frame plug-in for IE. However, it is unclear whether anybody who still uses an old version of IE is going to readily want - or be allowed - to install a new plug-in. The whole point of WebRTC is to avoid plug-ins, especially for occasional audio/video tasks such as conferencing.

(Sidenote: I have a growing hatred of all the various web conference tools that vendors briefings or clients/contacts force me to use - no, I don't want to have to sign in 15 minutes in advance to make sure it all works and I've downloaded whatever chunks of software are supposed to help. Increasingly I turn down such requests, asking instead for a PSTN dial-in and emailing me the PDF presentation - or, alternatively, force *them* to use my choice: Skype).

So, I'm doubtful that Chrome Frame is going to do much to extend the reach of WebRTC to many of the old-browser community. Maybe Google can cunningly force its use by pushing it as a way to enable/enhance GMail or Hangouts, but it's not obvious that's the case.

I had an interesting thought yesterday though - most of those old browsers will already have Flash and Java plug-ins (as well as maybe Silverlight and others). Maybe the "vector" for WebRTC support on "old IE" will turn out to be Adobe or Sun (ie now Oracle), if they include it within the next updates of users' current plug-ins? Obviously Adobe still has its own competing RTMP & RTFMP protocols, but it must surely by now see the writing on the wall, much as it has with Flash vs. H.264? Could it gain relevance by being a lead provider of WebRTC APIs? Provide a combination of the two with RTFMP as a fallback or way to manage certain scenarios? Maybe even get subsidised by Google to help extend WebRTC's reach more quickly....

The Oracle/Sun/Java pitch is perhaps easier - it wouldn't surprise me at all, and there are some obvious synergies with the acquisition of Acme Packet.

(Note - I have no inside knowledge of either of these; both are total speculation on my part. I'm actually embarrassed I didn't ask Oracle or Acme about it - or even just suggest it - when I met them recently).

One question I haven't thought through though - what would this mean for PCs which end up with two or more WebRTC implementations? Native browser capability, plus plug-in, plus maybe the sort of web-app Javascript/API approach we see from AddLive or Plivo and others? Will there just be a "default WebRTC engine" or will it be managed in another way? It strikes me that we'll definitely see smartphones and tablets with 2+ implementations of WebRTC, so this issue will need to be addressed anyway.

Telcos need to offer 2+ separate voice applications & decouple RCS + VoLTE

In yesterday's post about RCS, I mentioned in passing that VoLTE and RCS must be 100% separated if either is to stand a chance of success. At present, attempts to combine them in RCS5  are, depending on your viewpoint, either: (a) a rather Machiavellian attempt to force deployment of RCS even among skeptical carriers, or (b) because a few use-cases of IM/chat benefit from being integrated with voice communications. There is also the vendor bundling argument of "Get 2 apps for the price of 1 on our IMS platform".

The net effect is shackling the already-hobbling VoLTE to the corpse of RCS, making it drag its deceased counterpart along for the entire distance of a marathon. Not a strategy for success, for either (a) or (b) scnearios. To mix my metaphors - just because you share IMS DNA with your sibling, you should still remember that incestuous marriage is banned for good reasons: your offspring will likely have undesirable genetic traits. Far better to look for fresh genes elsewhere and cross-breed with Internet species, for example.

That led to me to a broader set of thoughts about voice/messaging integration, and also fragmentation of the voice experience. I've often used this chart (or variations) for the past few years, and it encapsulates what is happening as voice goes "beyond telephony":

In a nutshell, voice communications is changing from standalone telephony, to a more complex and dynamic market in which voice gets embedded into many applications and contexts, often in forms that don't look like traditional "phone calls". WebRTC accelerates this, although it is already happening via apps and APIs in any case.

This also means that typical phones and PCs will have multiple "voice apps" in future, besides the dialler. Obviously this is already becoming true for many users today, who have VoIP capabilities from Skype, Google, Telco-OTT apps, corporate UC systems, embedded voice in games or Facebook and so forth. With the advent of WebRTC we'll see even more fragmentation of the voice experience, with websites and mobile apps featuring voice functions internally. Often, the experience of voice will often be nothing like a phone conversation - no "Hello, is that Dean?" or the normal interruptions, ringing, stilted etiquette and other bits of 130-year old furniture that make up this thing we recognise as a "call".

While we already see cloud providers and operators provide telephony APIs to developers (some do already), many of those still have the same "raw ingredient" as the basic phone call, using the same voice engine and numbering as the handset's main dialler. That's not good enough.

There needs to be much greater flexibility and imagination. For example, if I'm calling from a call-centre there needs to be Grade-A background noise suppression so you can't hear the inane chatter of my colleagues, while I try to sell you double-glazing. But if I'm on a beach making a "wish you were here!" call to a friend, it would be nice to have the gentle sound of waves in the background, not deathly silence. There are many other parameters and interaction models for developers to tune too - that's just a simple example.

For video, there are actually more options, because firms like AddLive, Plivo, Telefonica/TokBox and others are offering video APIs and back-end cloud services, based either on WebRTC or proprietary alternatives. But as far as I know, there aren't many easy APIs for non-telephony forms of voice communication yet, although Twilio, Rebtel, Voxeo Labs and others enable in-app voice with some control over interaction logic.

Coming back to the RCS/VoLTE debacle, this points to an uncomfortable conclusion - rigid, standard phone calls are precisely the wrong sort of voice to include in RCS-type use cases anyway. Even if RCS miraculously became a success, developers would probably want to mash it up with non-VoLTE voice a lot of the time. You'd want stereo for a karaoke app, and the capability to deal with a lousy external microphone, for example. Some might want to trigger a traditional phone call, but others would not. Even then, developers will want a choice of 3rd-party telephony/VoIP APIs and not just the carrier's, for example if they want to use different phone numbers.

So if telcos and their vendors decide to put voice capabilities into RCS anyway, they need to start from square one, and think "Why are we putting voice here? Is it for phone-type calls similar to Skype? or is it for other use-cases? What do users and developers actually want to do?". As with my post on messaging, they need to think about Intent & Purpose, and not just get blind-sided because they can get both sets of (independent) capability from the same platform.

A similar argument applies to VoLTE adding RCS. If LTE phone calls can benefit from associated messaging, presence or other features, is RCS really the right/only product to deliver that, for the specific use-cases that carrier feels are important?

Operators should be looking more at mashup / orchestrated approaches. And they need to be happy to have multiple voice experiences on their customers devices - and not only that, but they ought to be developing multiple voice apps/services/APIs, not just clunky old telephony warmed-over in VoLTE guise.

So if you want voice in RCS, then there's a big choice out there. Bolting it to VoLTE makes no sense whatsoever - it would even be better to have a second, different VoIP app-server on the same IMS and use that instead, especially as half the time it's likely to be running over 3G or 3rd-party uncontrolled WiFi anyway.

An RCS use-case I'd actually support & see as viable

It's now more than 2.5 years since my publication of a report on "RCS is Dead" in September 2010. While RCS has shambled on as an undead Zombie technology since then, and we've still got a few lonely operators kicking over its rotting corpse at the moment, I thought I should reflect on a couple of points I'd mentioned.

I maintain my position that there is zero benefit - and quite a lot of cost - to RCS (either the general version or the Joyn-branded GSMA-approved one) as a standalone app. The contention that it will somehow encourage people to give up using WhatsApp, KakaoTalk, Line and the other messaging platforms is risible. Worse, expounding the notion that RCS might sway people away from using embedded messaging capability in apps such as Facebook should be grounds for firing someone for gross incompetence. Blending it in with VoLTE will further delay and complicate an already-struggling (and much more important) system - the two should be kept 100% separate until either/both are well-established.

In my 2010 report, I suggested that one way to salvage something from the wreckage of RCS was for operators to offer fully-OTT versions of the app or API. MetroPCS is fairly close to that, announcing a related capability at MWC . I  also suggested that operators consider using RCS for their own customer-service and self-care function, and mandating their own employees to use it for IM (not eating your own dogfood is never a good sign). A fourth option was using RCS within operator-branded vertical-community apps, perhaps for sports or movies or home-automation.

In many ways, the GSMA Joyn branding, which has to be paid for (!!!!) by operators wishing to subjugate any hope of differentiation, has made matters a lot worse. It just highlights the fact that it is a clumsy multi-operator service that has little value until 80%+ of a given population can use it. (For MetroPCS, it's perhaps not so bad as it's the only RCS player of any sort in North America at present, so it has the logo to itself for now at least).

Overall, I see no grounds for a general-purpose, cross-operator standardised messaging app. Pointing to SMS as a success "proving" federated standards are worthwhile, ignores 20 years of innovation on the web, smartphones, cloud and apps in the meantime. Standalone Joyn is worse than useless, sucking up money and resources that could be better used by operators on design and innovation, or partnering with Internet/app providers who "get it".

I've got more sympathy - to a limited extent - for RCS as an API, or with various forms of web mashup which might create new messaging experiences and user-interaction models. Because the web integration would likely be single-carrier, ideally offered on an OTT basis rather than federated across multiple telcos, there is a chance to differentiate and make some money. (I'm not going to cover WebRTC integration here, which I address that in quite a lot of depth in my recent report ).

But in the spirit of my original report, I've actually thought through a variant of RCS which I'd actually be prepared to support, and even use myself if it worked well. Yes, you read that correctly.

For *some* of my messaging interactions, it would be useful to have a common-denominator app that's better than SMS and more convenient than email. I've thought of a version I'd actually be prepared to use.

I hate unsolicited SMS and spam emails with a vengeance. I want any future messaging services to be white-list capable, with sophisticated controls and policies. I'm not convinced that Facebook or Twitter - if they ever released an open messaging API - would be in a position to control their advertisers to the extent I'd like.

So, thinking about my "perfect generic messaging app", I want something which is able to:

- accept inbound messages from my Facebook & LinkedIn contacts only (including groups & events, not just people, but excluding brand pages). I want that configurable so I can add/drop other social services - and subsets of affiliations within them - in the future.
- accept inbound messages from people in my handset addressbook (these days, that's far fewer than FB & LI contacts - I rarely take peoples' phone numbers).
- charge £5 a time for inbound messages from unknown people or organisations, based on a combination of number + social connections. I'll even give a rev-share on this! (There's your new business model, telcos, protecting my privacy and acting as my "interruption agency").
- give me the ability to refund the fee if I want (eg a friend loses their phone & contacts me from someone else's, or a prospective client gets in touch)
- have a "report as spam" and "block" button, which also (& quite specifically) will block all marketing messages from my service provider if I choose
- has a sensible price structure - maybe not quite as cheap as WhatsApp, but £5-10 a year flat is reasonable, excluding the value-adds like the pay-to-interrupt feature. No international or roaming premiums
- has a good UI and features that evolve on a monthly basis
- Service is offered on a fully-OTT basis, usable from all my devices, irrespective of connection method. I want it to work on my PC without installing an application, via the web with a password login (or FB / LI / Twitter authentication)
- Decoupled from SIM and mobile phone number, using a separate identifier range, so there is no need to "port" it if I switch access providers, and it works easily when I travel and use a local SIM in a spare phone
- Integration with my preferred voice applications (eg click-to-speak/call), especially Skype at the moment, but maybe WebRTC ones in future too.
- A good / clever UI. Facebook's new "chat-heads" is fantastic
- Doesn't do anything creepy in terms of "big data" through analysis of my social graph / usage patterns
- EDIT: Doesn't kill my battery with clunky presence / always-on implementations. (Hat-tip to Kevin Holley on Twitter for that!) Whatsapp's"last seen online" is probably the best current version of presence, rather than online/offline/busy which nobody uses properly.

Anyone prepared to step up for that? Is it easier to do with RCS, or does that add little to the solution? For me, the "no unwanted interruptions" feature is critical, as is "report as spam".

Standalone, and pitched as some unconvincing "SMS 2.0" or direct clone of Whatsapp, RCS & Joyn are worse than useless. But if you can use it to create something unique that improves the user-interaction model, then I'm willing to listen.

(Sidenote: in the past 6 months, my worst SMS spam offenders have been the UK's pestilential PPI-refund lawyers, my own operator Vodafone UK, and the GSMA sending me unsolicited nonsense about MWC).

There is no "messaging market"

I keep reading ridiculous articles talking about SMS, so-called OTT applications like WhatsApp & KakaoTalk, Facebook, and of course my favourite RCS/RCSe/Joyn family of services.

A central theme in these articles is a supposed battle for the "messaging market", with lazy journalists or vendor marketeers painting a dark picture of mortal combat between the righteous fortress of SMS revenues, the marauding hordes of barbarian OTT players at the gates, and the Knights of Joyn riding to the rescue in their shining armour of interoperability.

This is all palpable nonsense - a strawman argument to reframe a complex and dynamic situation into the usual fatuous and imaginary Us vs. Them, Telcos vs OTTs narrative, coupled to a desperate attempt to make RCS and its GSMA-branded offspring look relevant.

Not only is this argument flawed, the likely outcomes will in many cases be worse than useless.

There is no "messaging market" today, and there certainly won't be tomorrow. We have multiple different mechanisms to send "messages" across the Internet and between phones today - and more to the point, many, many reasons and contexts for wanting to do so.

The idea that a "he said, she said" gossip via SMS is in any way equivalent to sending a signed NDA via email is ridiculous. Almost as ridiculous as equating a WhatsApp chat between friends, to a online-customer support IM session embedded in a software company's web-page.

You might as well say that there's a market for "sending things coloured blue", as it makes no less sense than a market for "sending messages". It's just more difficult to count.

For most of the last 15 years, the bulk of messages have been sent by SMS (mobile-to-mobile or server-to-mobile), Internet email (PC-to-PC, server-to-PC, or PC-to-mobile) and Internet IM (mostly PC-to-PC). And because emails are generally longer and "richer" than SMS, nobody has bothered to talk about the risks of messaging substitution between them.

As Internet access and apps have appeared on mobile phones, unsurprisingly we've seen an upsurge of both email and IM on devices. We've also seen a massive growth of other ways of sending messages such as push notifications, and especially in-app messaging for social, enterprise or gaming purposes. Quite often, we'll get the same message - or a notification - sent through multiple channels simultaneously, or to multiple devices, so there is rampant double-counting too.

There are actually three- or perhaps more - completely separate trends occurring:

1) SMS is losing its crown as the "standalone" mobile short-message platform of choice, because it is overpriced by around 100x, and hasn't evolved in feature-set in 20 years.
2) Standalone messaging is starting to diminish as it becomes easier and better to send contextualised messages
3) People only need any-to-any interoperable messaging when there's nothing better available. Most of the time, they're contacting friends or colleagues who'll have whatever app of choice works best in that group.

The key thing here is "purpose". SMS and email are (to a fair degree) general-purpose tools. Jacks of all trades and masters of none. An SMS can be a notification of a delayed flight, directions to meet your friend in the pub, a spam advert, or a way to send configurations & settings to your phone. Emails are similarly diverse.

General-purpose tools are fine when specialist tools are unavailable, expensive or inconvenient.

Do you think anybody would use a Swiss-Army Knife to open a bottle or cut a log, if the person had a magic app on their phone, or in their browser, that could instantly manifest a proper corkscrew or saw, at zero extra cost?

Moreover, would anyone other than Victorinox & Leatherman care about the demise of the pocket multi-tool market? Would they be stupid enough to try to create a new "Rich Tool Suite" standard between them, with interoperable and modular scissors and blades that could fit into a new generic multi-purpose tool body? And would industry analysts start adding together manifestations of tweezers and hacksaws to try to draw numerical comparisons with the legacy multi-tool market?

Just as I've previously mentioned that there is no "video" market, and increasingly no single "voice" market, there is already a clear fragmentation in messaging as well.

Yes, for any given use-case there are overlapping Venn diagrams which demonstrate substitution. I can tell my friends which pub I'm in using SMS, Facebook chat, WhatsApp or Twitter DMs if I wanted to. I could send my signed & scanned NDA to a client via email, Dropbox - or even fax or by mail.

Adding together some arbitrary subset of messaging tools - SMS + OTT apps, for example - but missing out push-notifications, emails, HTTP in-browser IM and so forth AND neglecting to de-duplicate where single messages...

... are cut into...

... chunks for convenience & readabilty...

or where the same message is sent & notified by multiple paths, just means that the data is spurious and the analysis sloppy. You never see any segmentation of messaging by purpose, except perhaps for person-to-person vs. app-to-person.

Any worthwhile analysis would look at various ways to slice up this supposed monolithic market into separate buckets reflecting context or intent. Perhaps social messaging vs. advertising vs. standalone information vs. gossip vs. B2B meeting arrangement vs. one-way app updates. Or sliced by length of a messaging "session" or number of participants, or a hundred other ways.

That type of analysis would also point out why the rhetoric around RCS and Joyn is a mistake. The market for general-purpose messaging is fragmented, declining in relevance, and simply not going to be very valuable in the future. WhatsApp's 1$-per-user-per-year price point is a good indicator of where it's going. Operators ought to be segmenting the messaging space by intent and developing laser-like tools where they can differentiate, not wasting time and resources on creating a lowest-common denominator Rich Tool Suite with the added costs and politics of IMS and vendor hype.

Moreover, the random selection of "capabilities" in RCS is the same set of pointless ideas for services that have been around for at least 10 years. "See what I see", "File Transfer", and old-fashioned and useless forms of presence? That's Yahoo Messenger from 2003, not a modern mobile communications app - see Vine's video clips, or Facebook's chat-heads, or WhatsApp's "last seen online" for some ideas about application *design* rather than engineering.

The irony is that the telecoms industry has been greedily absorbing $100bn+ a year from SMS and MMS, yet has plowed back almost zero into R&D and messaging application design. No sympathy or regulatory recourse whatsoever is due for telcos, as that market collapses - it has been a dead man walking for years. It has been neglected by companies asleep at the wheel and unwilling to innovate - there isn't even an easy "report as spam" function, or a way to switch to whitelist-only.

To be honest, I think WhatsApp and its peers will face challenges too - not only is it targetting a standalone messaging market that will implode in value, but it's doing so with constraints like using phone numbers as identifiers. That's already looking clunky in a multi-device user world, especially where many are WiFi-only.

Just as with voice communications, it is wrong to think of messaging as a meaningful and homogeneous "market". In most cases, messages will be sent as a feature or function of something else, not as a "service". There will be diminishing need - and diminishing value - in standalone, general-purpose applications. The true value will lie in many separate areas and business models, reflecting the myriad reasons why people or machines want to send messages in the first place.

So stop talking about the "messaging market", stop counting messages and drawing faulty conclusions from easy/lazy-to-quantify numbers, and start thinking about Purpose, because that's where the value lies.

Why interoperability isn't as important as you think it is

Often when I'm discussing communications services or applications with clients or online, I end up debating  "interoperability", sometimes along with "federation".

Especially around the areas of SIP, IMS and sometimes WebRTC, I'll frequently hear comments that "interoperability is essential" as otherwise we risk ending up with lots of "silos", "walled gardens" or "islands".

I think the discussion needs to be a bit more forward-thinking, and also more critical, aware of implicit assumptions. I hear a lot of confirmation bias, rooted in old - and crumbling - views of what "voice" or "messaging" are about.

Firstly, there are two main types of interoperability here:

• UNI or user-network interop. Basically this means that the device or application needs to work with reliably the server. Often, it is used to mean that there's a standard, which means any client can work with any server, for a given service or function.
• NNI or network-network interop. This relates to the standardisation of interconnection of different services, managed by different service providers. The classic example is being able to make phone calls or send SMS's between two telcos' networks, because the numbering and signalling is all common.

There's also a number of critical subtleties here that are often overlooked:

• Interoperability on the access network is clearly important for public networks - it's almost always good to have a choice of end-equipment (think phones, tablets, set-tops, routers) to work with a given cellular radio network or fixed broadband system. The costs of building an infrastructure are so high that it makes sense to allow a diversity of things to connect to it easily - especially as there's an ever-wider range of "things" for customers to choose from.
• NNI is actually mis-named. Increasingly it's really just SSI, service-service interop. The service provider doesn't need to own or operate a physical access network - it might just own switches or routers or web-servers, which may increasingly be running in software, or "in the cloud". The service provider themselves might be an MVNO, or a competitive fixed carrier using another telco's wholesale infrastructure for transport and/or switching.
• NNI/SSI only makes sense for services that are functionally similar - and which can be described fairly simply. A standalone phone call fits this description, as does a basic SMS or email. But increasingly, communications is going "in context" and so this concept will often not make sense in future. There's no value having "context-context interop" between in-game chat, and a doctor's remote MRI-scan video tool. And I really don't care if my mobile karaoke app can connect to your WebRTC banking call centre or not.
• Unlike access connections, there is an ever-lower barrier to entry to offering or obtaining communications services or features - and no limit to how many you can get. If a friend or business contact is using a new comms app or services, I can download the app in 20 seconds. Or connect via a WebRTC-enabled site and let Javascript sort it out in 20 milliseconds. You don't need Twelephone or TUMe to connect with Skype - it's a nice-to-have, not a must-have.
• In fact, often interop is nice-not-to-have. The benefit of silos/islands/walled-gardens is a lack of spam. And more control over how you define connections, friends or equivalent metaphor. You're not "reachable" by everyone, unless you want to be. You can force people to use *your* preferred service. For example, I'm starting to insist on doing vendor briefings via Skype - unless you're a paying client in which case it's your choice, as the power dynamic shifts. Less interop can also mean more security and privacy - and also much more control and monetisation potential for the service provider, if there is one.

In the past, telephony and SMS have been integral parts of the network so conflating NNI and SSI made sense. Phone numbers in particular still link to both Access-NNI and Service-NNI (and via the SIM card, to UNI). But over the last 20 years, various new services and products have evolved that don't require that link - the most important being email and HTTP.

Email is interoperable, clearly. But for most people, it's not tied to an access line. Yes, I've got @BTinternet and @vodafone addresses, but I don't use them. 

We're already seeing the ancient practice of tying phone services to an access line starting to break down - various telcos allow you to access your E164 phone number and its services from another access connection, as a Telco-OTT extension such as Telefonica TUGo or Rogers OneNumber. The NNI in those cases is done via normal Internet peering (and probably an IPsec tunnel for security), but the SSI remains traditional phone-style SIP or SS7. More recently, MetroPCS has done the same for RCS, launching an OTT version for other devices, and more importantly also accessible to your friends on other networks.

I've written before about the difference between interoperability and federation, and why an email-style model makes more sense. (You can have multiple accounts, running on the same device/access). At the moment we see Internet players selling E164 phone numbers decoupled from access (eg SkypeIn numbers) but I'm not aware of any telcos doing the same. I ought to be able to buy an AT&T number, plus AT&T phone service, without an AT&T SIM or home broadband, while I'm sitting here in London.

Although it's inelegant, it's becoming ever more possible to do interop via gateways, SBCs and other middle-points. Moore's Law is making the availability of "glue" and "welding-torches" much easier. We no longer have to beat out a single panel slowly, with a standards "craftsman" meticulously bending over his anvil with a hammer. In particular, we can develop silos rapidly and inexpensively, and then bolt them together afterwards only if and when it makes sense.

I still hear people saying "SMS only took off when all the networks interconnected". That's often wrongly interpreted to mean "interoperability is obviously always valuable", when actually it means that "services tied to specific network IDs are very constrained in value, although interop can sometimes help".

For telcos, "Monetising OTT" is about distribution partnerships & revshare, not QoS or termination fees

A couple of years ago, I moderated a panel session at a conference on broadband business models and "traffic management". It was one of the many sessions the industry offers about the old cliche of "Telcos vs. OTTs".

(Obviously, we know now that this is an arbitrary, fatuous and meaningless distinction - most telcos are also so-called OTTs, and some OTTs are also telcos)

This panel, however, was a little different, as I had two senior executives participating from very different perspectives. One was from Deutsche Telekom, looking after wholesale. The other was the head of global alliances for YouTube. For once, I thought, we might actually be able to find some common ground, rather than rehashing old arguments. There were also a couple of vendors represented, coming from policy/DPI and charging angles.

This was not to be. The DT guy was the first speaker, and he launched into what could only be described as a lecture entitled Jurassic Telco 101. It was a full-on, dino-tastic tirade about "putting their data on our pipes", referencing what was then an attempt at persuading the EU to levy what was being called a "Google Tax". It pre-dated the more recent and equally-incoherent nonsense from ETNO and ITU WCIT about some proposed "termination fees" for Internet data, amounting to the largely same thing.

I'm pretty sure even the PCRF folk raised an eyebrow or two - they were pushing the more-common (and more reasonable) line about offering paid premium QoS for Internet companies. The DT guy was uncompromising, and was insisting that Internet companies should pay again for what already worked perfectly well - and what already was being paid for by DT's retail customers: best-effort (and capped) Internet access.

Initially, the YouTube speaker's response was what could be expected - a polite reiteration about how the Internet worked, and that part of the value that DT's customers paid for was the ability to access services like YouTube.

In the spirit of reconciliation, I proposed another suggestion - that maybe telcos like DT could help YouTube earn more money, either by QoS encouraging more viewing of content/ads, or by better advert targetting using customer databases, or other mechanisms. And that if they could prove to YouTube that they were responsible for revenue uplift, they deserved a share of the incremental extra.

In other words, a monetisation model could exist - but it would be based on sharing (attributable) revenues rather than ascribing an arbitrary fraction of (shared) costs.

When I floated this idea, the YouTube guy appeared interested. While clearly not jumping into offering money, he certainly didn't dismiss the idea - as makes perfect sense. Which business person would not consider paying a commission or bounty to a third party that can increase revenues without cannibalisation risk? Obviously there is a negotiation to be had, but in this case Google already has a model of affiliates, who get paid a share of revenues linked to click-throughs.

The DT speaker, however, was intransigent, even when it was pointed out that only a fraction of Google's video traffic is actually monetised. (It is very difficult to place adverts in true long-tail content).

But despite that ante-diluvian stance, since then I've firmly believed that many deals between telcos and Internet content/app players would fall into this "distribution" model: operators can help improve reach, billing and uptake of (paid) OTT services, and that they would receive a revenue-share as a result, based around success of that distribution partnership.

Interestingly, DT itself seems to have shifted significantly to that mode of thought as well. It has announced various partnerships to offer paid OTT-style services to its customers as part of its bundles. For example, it is now offering Evernote premium access to its subscribers, as well as Spotify.

In this model, DT is paying Evernote and Spotify, not the other way around. I'm sure it gets a good wholesale price deal compared to users buying "retail Evernote premium" directly, but the net effect is the same. DT will be sending a cheque to Evernote, not the other way around. It is then up to DT as to whether it zero-rates the data traffic for its customers, applies QoS to improve the experience, or otherwise plays around with the delivery approach.

This is the model for "OTT monetisation" that seems to be working, not the "termination fee" or "paid QoS" models, nor the unworkable "1-800" model for apps, that I comprehensively demolished last year. A long list of Internet companies now works with telcos (fixed and mobile) to put their apps or content on-board the operators' platforms or phones: Skype, WhatsApp, Viber, Facebook and many others.

There is no evidence that any of them are paying "cold hard cash" for either access, nor QoS. Instead, they offer the telcos a bulk deal for distribution in-bundle, or a commission on premium-tier incremental sales. The operator either gets a more attractive bundle to win market share, or maintain premium pricing - or else gets a direct revshare on additional sales.

In other words, the balance of payments pretty much goes in one direction only. There may be a few other balancing items such as telcos' on-net CDN delivery of content, or some contentious peering/transit fees, but I have yet to see these at a level to reverse the money flow towards the network owners. Maybe in future, exposure of other - more useful - APIs, or provision of cloud-based enablers might help. But at the moment, telcos appear to be "net importers" with a sizeable trade deficit with the Internet, as I suggested a couple of years ago.

Joyn a world of delusion

In Douglas Adams' famous novel The Hitchhikers' Guide to the Galaxy, the protagonist Arthur Dent responds to someone saying "Don't worry, we're safe" with the line:

"Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of"

I was reminded of this sentiment yesterday, when I heard a radio advert from US operator MetroPCS (currently being acquired by T-Mobile) while driving around the Bay Area. While discussing its 4G network and plans, the voiceover came out with this gem of a quote:

"The only network featuring Joyn, the amazing social sharing app sweeping Europe"

Which is, obviously, some strange usage of two words, "amazing" and "sweeping", that clearly I wasn't previously aware of. Being less charitable, I'd say they cross the boundary between acceptable-if-cringeworthy marketing hyperbole, and an outright lie. (Ironically, MetroPCS has actually done something interesting with Joyn, offering it as a Telco-OTT app for non-Metro subscribers, but the advert didn't mention that).

This type of ridiculous puffery is becoming the signature of RCS/Joyn. Obviously, the spinning started with the risible "it's just there, it just works" tagline, although that could almost be put down merely as a crass attempt to "fake it till you make it", imbued with the naive wishful thinking that it might create a self-fulfilling prophecy.

Then pre-MWC, there was the loud trumpeting that South Korea's SKT had signed up 1 million users for its JoynT service, albeit with precious few details about active usage, or whether this was just counting bundle subscribers. There was also conspicuous silence about how this compared with the 1.2 million early-RCS users trumpeted in May 2010.

Then in the last few weeks, Deutsche Telekom announced support of a downloadable Joyn app in Germany, alongside the existing effort from Vodafone. Cue various spurious comments such as "Telefónica also plan to launch Joyn in the market later this year, at which point the service will then be available to over 80 per cent of all mobile customers in Germany" which conveniently overlooks the current (and baffling) lack of iPhone versions, and the fact that Germany still only has 50-60% smartphone penetration anyway.

All of this epitomises the RCS/Joyn community's continuing sense of both self-delusion and entitlement. Participating in various discussions on LinkedIn and elsewhere, I still keep picking up the sense that Joyn is perceived as somehow different or special to the 100's of other messaging apps, merely because it's been "standardised" by a committee.

There continues to be be an undercurrent of wishful thinking that the large handset vendors will pre-install Joyn by default in all devices, because telcos will demand it in their published specs - ignoring the fact that globally many devices are sold through non-carrier channels. Plus obviously all the major players have their own messaging platforms like iMessage, Chat-On, BBM and so forth - as well as a variety of partnerships with Facebook, Twitter and others.

Also absent from most of the discussion is another very important constituency - the user. I still have not seen any reason why users will plausibly want to switch from WhatsApp or similar standalone services, while increasingly we are seeing messaging/sharing being "contextualised" into vertical social or business applications like Facebook or Yammer anyway. The best that the telcos can come up with is zero-rating of data traffic for Joyn - not really a big deal when you consider that almost all video-sharing or big file-sharing instances will occur in the presence of non-metered WiFi anyway.

As I've said before, I can see slightly more scope for RCS as an API, rather than an app. B2C messaging could benefit from something richer than SMS/MMS. But to get to that point of utility, the telecoms industry needs to sort the chicken/egg problem - an RCS API is only useful when it provides access to most people. But most people (or, by proxy, their device suppliers) will only adopt RCS if/when it does something useful for them.

Operators' strategy for fixing this dilemma seems to be three-fold:

1. Pretend the problem doesn't exist
2. Hope to persuade more operators to adopt/launch RCS in vain hope it might be useful
3. Hope to force handset vendors to embed or pre-install Joyn and underlying APIs

Personally, I can't see this working until and unless RCS/Joyn offers something concretely important, innovative and differentiating to end-users. There is no reason for OEMs to embed Joyn in "open market" phones sold through non-telco channels. And even less reason to embed Joyn in WiFi-only tablets. In the meantime, operators are aggressively partnering with other so-called OTT players like WhatsApp, Skype and Facebook, while device vendors are pushing their own options. There is much more "ubiquity" to be had from a Twitter API (or Facebook Messaging API if one launches) - when Joyn has 300m+ active users, it has a story to tell.

Notably, Telefonica has announced that it will embed its own TUMe telco-OTT voice & messaging app in its South America handsets. To my mind, this is a much smarter move than pushing humdrum, low-value-commodity RCS as the Spanish and German Telefonica units are trying.

Either way, the telecom operators clearly need to get a sense of reality about Joyn - and start to think about how to exploit the increasingly sophisticated user base for advanced and contextualised messaging. The best thing for them to do it stop wasting time, money and resources on RCS/Joyn immediately, and abandon it. It is a distraction and inevitable failure - and given the huge opportunity costs from not "doing something more useful instead", it is a bizarre act of self-delusion to keep clinging to it, at this point.

If operators do want to continue pursuing the  RCS "opportunity", they need to do 5 things immediately:

1. Get the iOS version out within the next month
2. Drop the silly slogans & advertising - focus on driving real virality and adoption
3. Follow MetroPCS and aggressively push OTT variants of Joyn. Vodafone Germany should have been pushing its branded Joyn app to T-Mobile and O2 DE customers already.
4. Develop some clearly differentiated use-cases for the app
5. Move to iterating and updating Joyn features at least quarterly, and ideally have a rolling 2-4 week app upgrade cycle adding new features, fixing bugs etc

There's also various things around WebRTC extension, and API exposure, but I'll save those discussions for private advice and consultation sessions.

As I've said before, RCS/Joyn is a zombie technology - dead, but still walking around and apt to try to eat your brain if you let it get too close. It seems that the first sign of infection is self-delusion.

Is the telephony "threat" from VoIP & WebRTC about competition or contextualisation?

I've been using my voice-fragmentation bubble chart in presentations for a couple of years now. It points out that "voice" is not the same as "telephony", despite the fact that in the past almost all voice-based communications has been made up of standalone phone calls. 

In future, we will see an increasing amount of voice capability become embedded into other applications and services, often using different technology and user interaction models to a traditional "call". The best example of this has been in-game voice chat between players, which bears little resemblence to a phone call, and adds extra features like stereo/3D-audio capability so users can tell if team-mate is behind them or in front. There has also been a rise in new forms of audioconferencing which are not strictly phone calls, as well as a broader (but still quite slow) move towards application-embedded telephony using various API platforms.

[NEW REPORT ON WEBRTC - CLICK HERE]

This is important to understand, especially for telecom operators wanting to retain relevance in voice communications. Many in the industry do not understand the difference - many use the two terms (voice & telephony) interchangeably, and believe that operators have a cornerstone role in voice communications overall, rather than just telephony. This is even reflected in the misnaming of VoLTE, which should really be called ToLTE.

The big question is whether the standalone phone call - and the bulk of the global trillion-dollar telephony market - will be threatened by contextualisation as well as competition. 

This is an important distinction:

• Competition for telephony comes from other cheaper/better standalone calling services and applications used for similar purposes as a phone call. This includes most call-oriented VoIP services such as Viber and some (but not all) use of Skype. To the user, the experience is similar - person A calls person B, perhaps with a bit of pre-negotiation via IM/presence about convenient timing. The intent & context is similar, although the mechanics and features might differ a bit. This is direct competition, often based on free/freemium models. In some cases such as SkypeOut, we see hybrids.
• Contextualisation for telephony is more subtle. This is where certain conversations are siphoned off from being standalone calls, into being "in-app" or "in-context". In some cases the ultimate user-interaction is similar enough to a phone call to permit APIs to be used (from a telco or a 3rd party like Voxeo or Twilio) to embed calling capability. In others (such as gaming, or an intercom-type function), a phone call is not a good enough "raw ingredient". A critical element here is whether the voice part remains a "service" (billed, linked to a subscription etc) or whether it is just a feature or function. This is an area where WebRTC will have a major impact, as it allows easier contextualisation of voice into web and app activities.

[NEW DISRUPTIVE ANALYSIS REPORT ON WEBRTC - CLICK HERE]

There are also a couple of other related trends:

• Upgrading phone calls involves adding video or some other feature, but leaving the call as a standalone activity (eg much of Skype video fits here). Sometimes this is grouped together with contextualisation - for example, in-app or in-website video calling. Again, WebRTC will have a major impact here.
• Substituting phone calls is the use of another mechanism to deliver the same intention & outcome instead of a call. For example, sending an SMS or IM to say "I'm running late" rather than calling, or using an app to book a taxi - rather than calling a dispatch office. There is also a broad trend of people disliking phone calls and other forms of voice altogether, and seeking a non-voice alternative.

It is also important to consider whether the communication is person-to-person, or application-to-person. There is a secondary distinction to be made here - P2P voice taking place inside an app is fundamentally different to A2P voice (eg talking to an IVR system). One may lead to another - eg navigating an IVR before speaking directly to an agent.

At present, contextual voice has been relatively restricted. Some niches (games, conferencing) are large and specialised enough to justify well-integrated solutions. In the past, we've had some voice-chat between IM buddies, which is somewhere between competition and substitution, depending precisely how and when it is used. But we haven't seen much true "social voice", for example - until Facebook's recent forays into adding VoIP in North America.

Messaging is some way ahead of voice in terms of both contextualisation and competition. There's already a ton of competitive standalone-messaging services like WhatsApp and iMessage, which are having an impact on SMS. We also see a huge and growing use of app push-notifications, which are clearly contextual, but one-way only. And, increasingly, we're seeing messaging linked to existing social networks (Facebook, Twitter, LinkedIn) or embedded into customer-service websites (live-agent chat). But while we've seen a lot of A2P SMS, we haven't seen a lot of P2A2P SMS - ie personal SMS's driven from within other apps or websites.

(Sidenote - messaging also has a critical non-voice like characteristic, in that the same message often gets delivered via multiple paths, such as in-app, plus via SMS or email or push notification. This means a lot of double-counting in the stats too)

This is all happening sooner for text-type communications, because it has been comparatively easy to contextualise messaging for a while. Adding an IM function to an app or website is fairly simple technically for developers, and relatively undemanding of both network and device. It is also much easier to use the application's own identity-space for messaging, or indeed none at all. 

That said, there is essentially no need for P2A2P SMS - it would be silly to use (paid-for, subscribed, number-based) SMS between users of a game or social app, for example, although "SMS-out" is more common.

Voice (and especially video) is much harder than messaging to contextualise and add into apps or websites. In particular, voice mainly comes both in the form of circuit telephony (anchored in a telco) and various classes of VoIP. This explodes into a whole range of complex issues around user interaction, billing model, network quality, codecs, firewall traversal and so forth.

So we have had (broadly) two approaches to voice-contextualisation in the past:

• API-led approaches to CS call control, such as adding a "call me" button on a website, which initiates a standard PSTN call to a phone
• Custom VoIP implementations such as that seen in web-conferencing, gaming, healthcare (eg nurse-call) and so on.

In general the API-type approaches have not been "symmetrical", eg using an ordinary phone call within an app used by two users. You wouldn't see a multiplayer mobile karaoke app, with embedded phone calls used to transport the singing. They have tended to be used for contact-centre style use-cases, such as customer service (call-me) or automated surveys.

Conversely, the custom VoIP approach has been expensive and confined to areas where developers are communications specialists, using SIP or web plug-ins like Flash.

WebRTC democratises the creation of contextualised VoIP-style voice - certainly on the web via browsers, and increasingly mobile via 3rd-party SDKs. Disruptive Analysis believes that this will ultimately prove to be more important than new "standalone calling" use-cases for WebRTC, although the ease of creating those may mean they happen first.

WebRTC is likely to be the main enabler of "social voice", rather than some new form of telephony API exploiting carrier VoIP or VoLTE. Those come with the baggage of real phone numbers, whereas the whole point of communicating inside a social network is about using that community's ID and naming/reachability conventions. We already see the first of these with Twelephone.

That said, there may still also be an argument for vertical, custom-integrated contextual VoIP as well. Facebook doesn't need to use WebRTC, although its use of web-based HTPP messaging for chat suggests that would make sense. Similarly, Microsoft is connecting its enterprise Lync system to Skype, to enable contextual in-app customer service and other B2C communications functions. That might transition to WebRTC (or CU-RTC-Web) but doesn't need to.

[NEW DISRUPTIVE ANALYSIS REPORT ON WEBRTC - CLICK HERE]

For operators, the real issue is this: in the past, the voice marketplace has almost entirely been made up of standalone telephone services & calls. That has faced competition on both price and features from Skype already. 

But the real battle is ahead, as standalone calling starts to get nibbled away by context-based voice, for which a broad range of creation options exist - WebRTC being the most notable and fast-moving. It is far from clear that telephony - CS or telco VoIP - is the right raw ingredient. SMS certainly hasn't been the driver for in-app or in-website messaging, so it seems unreasonable to assert that telephony will have any more success.

Standalone calls are not going to disappear. But it's much less clear that the rump of out-of-context telephony will be worth more than a tiny fraction of today's market.

New report published! WebRTC Market Status & Forecasts: The hype is justified: it *will* change telecoms

NEW! First major analyst study & forecasts for the WebRTC Market and Value Chain
Disruptive Analysis has been the key analyst company following WebRTC  since June 2011, only weeks after Google first open-sourced the key audio/video components for web browsers. Since then, WebRTC has featured prominently on this blog, in Disruptive Analysis research reports & consulting, conferences and in Future of Voice workshops.

The report is 160 pages in length, including detailed commentary, analysis, forecasts and over 50 tables and charts - and forms the cornerstone of ongoing coverage throughout 2013 and beyond. More than 70 companies involved in WebRTC products & services are discussed.

Key takeaways

- WebRTC adds easy, flexible voice & video into websites and apps

- Applicable across sectors: telecoms, consumer web, enterprise etc

- One of most disruptive web/telecoms innovations for years

- Extremely fast pace of evolution: weeks and months, not years

- Microsoft & Apple slow, but unlikely to cause major roadblocks

- 3bn capable devices & 1bn individual users by end-2016

- 50% penetration of PCs by end of 2013

- Smartphone & tablet WebRTC will ramp from 2H 2014 on

- PCs adopt WebRTC through browser; phones/tablets more complex

- Early use-cases for web calling, conferencing, e-learning & verticals

- Strong interest for UC, contact centres & IMS, but will take time...

- .... so telcos must start work now, to work through the issues

- Magnifies “OTT” threat for telcos, but also helps Telco-OTT

- Numerous “gateway” sub-types for vendors to target

- Peer-to-peer use of WebRTC to drive unexpected new web innovations

- Monetisation of WebRTC will be heavily use-case dependent

- Still early pre-standard implementation. Caution/patience needed

- But for once, the hype is justified

Disruptive Analysis is known for its contrarian stance on many technologies. Sometimes this is negative, and sometimes it is positive. In this case, it seems that the true scale and impact of WebRTC are being underestimated by many. While there is already a measure of hype around the technology, that is more “general buzz”, rather than a more forensic analysis of the potential implications on a sector-by-sector basis.

Over the years, we have been accustomed to seeing new features appear in our web browsers – streaming video, scrolling timelines, auto-completing forms, in-page IM chat and so on. Typically we think “that’s neat!” and start using it without much further thought. Soon, we see it crop up in all sorts of different websites – and also in hybrid native/web apps on our smartphones and tablets.

The next feature is realtime, high-quality, voice and video communication. It will extend beyond standalone “calls” that are typical of today’s VoIP services and telephony. The “bare-bones” flexible nature of WebRTC means that developers will not be constrained by the user interaction types or business models or the past.

While WebRTC still faces some formidable challenges to perfect and standardise, it is displaying many signs that suggests that it is close to becoming an inevitable winner. There are no obvious deal-breakers on the horizon – even Apple’s much-trumpeted “no comment” position, or Microsoft’s rival CU-RTC-Web proposal, have workarounds, and are unlikely to be long-term obstacles.

The breadth of companies involved – including Google, Ericsson, Cisco, Telefonica and AT&T – spans both traditional telecoms, enterprise communications and the web. We will see web access added by telcos, for example for IMS access from the browser. And we will also see realtime voice and video communications added by to the web inside social networks, or allowing informal “call centre” functions on normal websites.

But the aspect that impresses Disruptive Analysis the most is the sheer speed of development. Imaginative prototypes, demos and early commercial offers are appearing, even before the standards are finalised. Problems are being resolved in weeks or months, not years. Unlike most telecom-only solutions, developer interest seems to be accelerating, fed by Google’s evangelism and WebRTC’s appearance on the list of cool new additions to HTML5.

To those in the industry, it is easy to forget that it is still “early days”. The first public, mainstream support of WebRTC in browsers is only a few months old. By the end of 2013, the picture should be very different indeed, with much greater clarity about different OS and browser support, and the first “stars” of the new technology starting to coalesce.

This report is an attempt to bring together an analysis of the key strategic issues, make some bold predictions about major milestones, and put some first-cut numbers on this nascent industry. Disruptive Analysis will be covering WebRTC on an ongoing basis, and will be issuing updates to subscribers on a quarterly basis, as well as commenting regularly through Twitter (@disruptivedean & @DApremium), the Disruptive Wireless blog, and various events including WebRTC Expo in June 2013. 

Contents pages are here

To buy one-off reports please either pay online by card/Paypal using the links below, or email information AT disruptive-analysis DOT com to arrange payment via purchase order + invoice.

Reports will usually be delivered within 24 hours as PDFs by separate email.

Also available on request (please contact via email)
- Annual subscriptions, including quarterly updates to forecasts, company trends & market status
- Private internal workshops on WebRTC strategy
- Roadmap for Voice public workshops, including WebRTC

WebRTC report (PDF) 1-3 users

Non-UK/EU $1,500.00 USD UK/EU (+20% VAT) $1,800.00 USD Non-UK EU (only if you send EU VAT# via email) $1,500.00 USD

 

WebRTC report (PDF) Corporate Licence

Non-UK/EU $2,500.00 USD UK/EU (+20% VAT) $3,000.00 USD Non-UK EU (only if you send EU VAT# via email) $2,500.00 USD