RCS messaging: still a zombie, but now wearing a suit

This post originally appeared on October 4 on my LinkedIn feed, which is now my main platform for both short posts and longer-form articles. It can be found here, along with the comment stream. Please follow / connect to me on LinkedIn, to receive regular updates (about 1-3 / week)

Yesterday I followed the Mobile Ecosystem Forum stream of its #RCSWorld conference, on #RCS #messaging, especially business messages. I thought it was time to get an update.
 
As regular followers know, I’m a long-time critic of RCS. I saw it announced in 2008, wrote reports & advised telco clients about its many problems in 2010-2013, called it a zombie tech in 2015 (“28 quarters later”) and have been sniping at it ever since, including at Google’s acquisition of Jibe and its attempt to turn it into Android’s equivalent of Apple #iMessage.
 
Some flaws have been addressed (it finally uses E2E encryption), while Google’s tightening control of its features has maybe fixed its “design by committee” paralysis and historic fragmentation. Google is now hosting the whole application for many MNOs, rather than telcos relying on (and paying for) in-network IMS integration, but with an implicit threat of end-running them if they don’t support the services to customers.

There's about 1.2bn phones with RCS active - mostly Google #Android but also about 200m in China. This has been driven by its adoption as the default messaging client on new phones, rather than by consumer download.

I didn't hear any stats on genuine active use - ie beyond just using it as a pseudo-#SMS/MMS app because it's the default. Numbers always seem to be monthly MAUs rather than meaningful DAUs. No anecdotes of teenagers who swapped from FB / WA / iMessage / WeChat / TikTok / whatever because RCS is cooler with better emojis, birthday greeting fireworks or cat-ear image filters.
 
To be fair, the conference name was misleading. Almost the entire event was about RCS Business Messaging (RBM) rather than personal or group messaging. It was about targeted marketing campaigns (that’s spam to most of us), customer interaction with so-called “brands”, multichannel whatnot, and blather about engagement and “digital” marketing

Apparently A2P revenues for SMS are flattening, but the addition of "rich" interactive in-messaging customer experience functions will reignite growth. One operator in the audience asked why the same forecasts have been shown (and not come true) for the past 4-5 years. Apparently it's too complex for most developers.

So the big innovation is "basic RCS" with 160 characters. SMS with a brand logo, a verification tick and read receipts. It's aiming at the #cPaaS market to get more devs/marketers onto the first rung & hope to catalyse more fancy use-cases later.
 
IMO this is why Apple isn’t going to support it anytime soon, despite Google's cringey social media exhortations. The notion RCS is a standard for P2P messaging is a smokescreen. It’s an ad & CRM platform, not an SMS replacement or default way to chat with friends. It’s not going to be the messaging equivalent of USB-C chargers & forced on Apple by the European Commission
 
In a nutshell, it’s still a zombie. But now it’s a zombie in a suit spamming you with ads and "engagement" while it eats your brain

 

.

Update: Telecom & Network Cryptocurrencies, Tokens & ICOs

Introduction

Back in August I wrote a post on blockchain-based ICOs and tokens/coins for the telecoms space (link). Quite a lot has happened since then - including a huge boom in Bitcoin and "AltCoin" valuations and public awareness - so I thought an update was useful. 

In a nutshell - there's a growing number of telecom/networking "coins" available, with a wide variety of concepts, team backgrounds and business models. Some are very interesting, but some others are... let's say, "ambitious".  And a few look like utter nonsense, seemingly lacking understanding of the relevant technology or marketplace dynamics. It's possible there's a couple of outright scams as well.

I'm not making recommendations, or giving warnings, about specific tokens here. But in the spirit of "caveat emptor", I also give a list of cautions and possible problems, that investors should think about, or ask the various currencies' teams. Telecoms is a lot more complex than many people think - especially  the "behind the scenes" bits of technology.

 
Note: If you've found this post via an ICO/cryptocurrency site, an introduction: I'm primarily a mobile and telecoms analyst. I advise on technology and business-model trends for networks and communications, eg 5G, IoT systems, Wi-Fi, voice & video & UC, regulatory policy, the future role of carriers/CSPs, and the impact of "futures" innovations like AI / ML, blockchains (public & private), quantum computing and drones on telecoms. Most of my clients are telcos or network equipment/software vendors. I'm not a fintech, crypto or blockchain generalist - I look at blockchains & tokens where they intersect with the telecom world. Please get in touch if you are interested in my research & advisory work, or if you are looking for a keynote speaker or moderator.


What's been happening with telecom cryptocurrencies?

I'm not going to repeat my previous posts on ICOs, tokens and the wider telecom blockchain space. You can read blog posts here and here, or download a full white paper I wrote for Juniper Networks, here and listen to an associated webinar here.

The second half of 2017 saw continued emphasis on private blockchain use-cases for telecoms and networks, although despite a few high-ish profile initiatives and press releases, there's not much in the "real world" yet besides pilots. I've been doing some interesting consulting work in this area, though - 2018 should throw up a lot more news.

But there has been far more noise - albeit often superficial - about public blockchain and token technologies. Few major telcos have (publicly) announced involvement, but there's growing attention from the type of smaller, competitive types of service provider. Think tier 2/3 MVNOs, travel-SIM providers, VoIP companies, messenger & mobile advertising providers and so on, rather than big carriers. [Telenor is working with a content-oriented token provider - link]

Obviously, that fits against a wider background of interest and investment in cryptocurrencies. Whether we're witnessing the birth of a new financial/transactional system, or a possible bubble, I'll leave for others to debate. To me, it looks a bit like 1995 - lots of innovative web companies, but also a lot of ridiculous concepts, with valuations to match. Which are the Amazons of the future - or the Altavistas, or the pets.com's - I'll leave to others to work out.

There has also been a corresponding rise in regulatory concern, and growing focus on so-called "utility tokens", where in theory a given coin isn't just a store of value or a payment mechanism, but has some underlying property that makes it of broader use to consumers or businesses. Typically this means that some other capability can be "tokenised" - which could be anything from property to an artist's work, and used within that business activity. 

Incidentally - one interesting comms-related trend that's appeared recently is the use of Telegram* (and some other group-messaging apps) as a mobile-friendly and anonymous/encrypted discussion & announcement forum for cryptocurrency teams. Many of the tokens use Telegram as an addition to public (often spam-infested) chat on Twitter, and private internal Slack channels, plus assorted blogging and forum tools. I haven't seen any with an RCS messenger link, obviously.

*EDIT: Telegram has just announced its *own* ICO plans, literally hours after I posted this. Details here (link)


What telecoms/networking tokens are available?

A growing number of tokens relate to things which look "telecoms-like" - whether that's data connectivity provided via cellular or WiFi, SMS or instant-messenger functions, voice-call minutes, SIM identities or something else similar. 

Some are trying to resell existing users' quotas or attention or connectivity, while others are trying to build new hardware platforms. Some are trying to create meshes or secure peer-to-peer connectivity, while others are looking to be wholesale marketplaces for service providers to offer smart-contracts to consumers (or other SPs).

(There's also another huge set of tokens for IoT-related functions and applications, but I'll consider those another time). 

Note: I'm using token, coin, cryptocurrency, altcoin etc interchangeably. Various people will assert differences vigorously, but it's not something that is relevant here.

Note 2: This is being written on 7th January 2018, so dates / funding & issuance status are accurate as of today, but obviously changing at a rapid pace.

Note 3: I am NOT making any recommendations by mentions here. Various ICOs and tokens have been of questionable quality, valuations are volatile & sometimes ridiculous, and some are rumoured to be outright scams. Be extremely careful.

Note 4: I've probably missed some out. Get in touch if you want to tell me about your telecom/network coin, or give me a detailed briefing on the ones below.

• Airfox, Airtoken $AIR (link): Attempts to draw a link between mobile prepay credits, advertising, user-data and potentially micro-loans in future. It extends the current model of gifting or sending "recharges" to many international mobile operators' prepay customers, by shifting from normal payments to a cryptocurrency bought in a marketplace or earned by viewing ads. 
• Althea (link): Aiming to build a network of WiFi and other wireless networks, underpinned by cryptocurrency micropayments and incentives. Recently decided against an ICO, in favour of being "cryptocurrency neutral" - see blog here
• Ammbr [DISCLOSURE: I am an advisor], Ammbr, $AMR (link). Private investor funded, but tokens being listed on exchanges soon. Developing a hardware mesh networking system [Wi-Fi & other technologies], linked to blockchain-based micropayment and self-sovereign identity platform. Aiming first at locations with "unconnected" or poorly-connected communities, but with broader applicability.
• Birdchain, $BIRD (link): Pre-ICO. Developing a messaging app & platform for users to re-sell their SMS allocation for application-to-person messaging 
• Blocknum, $GIGA token (link) Token sale currently occuring. Looking at using the telephone network (PSTN), SIP signalling [used for VoIP] and phone numbers as a basis for a new blockchain for transactions.
• Bubbletone, Universal Mobile Token, $UMT (link). Currently doing pre-sale before ICO. Intending to be a marketplace for MNOs/MVNOs to publish data-plans or content services as smart contracts, with the plans/identities pushed down to users via multi-IMSI SIM cards, or as eSIM profiles. Aims to remove premiums for roaming. 
• Crypvisr, $CVN (link): ICO in 2017, listing on exchanges due soon. Encrypted messaging/communications platform, aimed at both consumers and enterprises.
• DENT Wireless Dent-coin, $DNT (link). Platform for mobile data plan & allowance purchase and sale. Aiming to remove roaming fees. Early app version is live.
• EncryptoTel, $ETT (link): Token-based enterprise "cloud PBX" communications system. 
• Mobilink, Mobi-Coins $MOBI (link). Upcoming ICO. Attempting to create an ad-funded mobile voice and data service, with a custom SIM card and network of MNO/MVNO relationships.  
• Mysterium, $MYST, (link) Decentralised VPN aiming to allow people to share unused network capacity, and use encryption to reduce the risk of intrusive data analytics of Internet usage by ISPs. It's a bit similar to Tor, but more flexible
• Qlink, $QLC (link): Token sale ongoing. Platform for sharing & micropayments for a variety of telco "assets", starting with WiFi access & then aiming for cellular data, SMS and content. Also planning own access points, including LTE-U unlicenced cellular.
• Rightmesh, $MESH (link): Upcoming ICO. Creating an incentivised device-to-device mesh (WiFi, Bluetooth etc). The company operating it (called Left.io) also offers another device-to-device communications/sharing app called Yo.
• Smartmesh, $SMT (link) Tokenised device-to-device mesh based on WiFi, Bluetooth LE etc., starting with smartphones connecting via an incentivised peer-to-peer mechanism.
• SMSChain, $SMSTO, (link): Creating a decentralised SMS gateway for application-to-person text messages. Incentivises users to donate their unused SMS quotas, via a mobile app. Cancelled proposed ICO (link) & may list tokens on exchanges at later date.
• Telcoin, $TEL, (link): Payment/money-transmission token intended to be distributed through existing mobile operators, and aggregators.
• Telegram, Grams: [Added as this emerged shortly after I published this - see link] The messenger app is considering a huge ICO and token sale, which could allow it to embrace payments and money-transfer, and perhaps other applications to become a cryptocurrency-enriched competitor to WeChat and FB Messenger.

What could possibly go wrong? A lot.

A lot of my work as an analyst and consultant involves "stress-testing" ideas and business-plans. Many concepts sound interesting, but face challenges of practicality - whether that's technical, commercial, legal or other. Reading through a lot of the tokens' documentation, or speaking to project teams, I see a lot of aspirations that are going to bang heads against reality.

Some problems can be fixed with time, or clever developers. Others are going to be intractable, and will need workarounds, or completely different strategies.

In this post, I'm not offering opinions or reviews of individual tokens, although I have private opinions on a number of them. A lot of what I read could be best described as "aspirational" - and in some cases, there are many layers of complexity or problems ahead, and I anticipate pivots and revised expectations, as practical issues come to light. Some that I've seen look completely naive or muddle-headed (or even, whisper it, fraudulent).

Some of the issues that could derail the various tokens' opportunity and prospects include:

• Most existing telecom plans (fixed and mobile) have terms and conditions that prohibit resale of "unused capacity" - and are likely to be updated with new token-proof T's & C's if risks are seen.
• Most MVNOs will also have a range of limitations in their contracts, from their host MNOs.
• Security - everything new comes with its own novel risks, even if the blockchain itself is secure. For instance, would you fancy having your 2FA password codes sent via SMS, that transits some random person's phone and app?
• Nobody likes paying for stuff (even micropayments) if it's also available for free via a different path. That means that there will be a lot of arbitrage - for example, it's hard to compete against free WiFi, or against the newer "roam like home" packages.
• Nobody likes paying for stuff in a "currency" that changes in value compared to normal money. I don't want to use some sort of converter to know how many pennies it'll cost for a phone call or Wi-Fi connection.
• There's all sorts of regulatory horribleness around telcos, at national, regional and global levels. Trying to assert "it's all decentralised, we don't need to follow the rules" won't work if it involves licensed spectrum, or messing with legal rules on registering network users' identities, lawful intercept etc.
• Running anything blockchain-related on a smartphone uses power & battery - especially if it needs to keep radio connections active as well. Power-management is always a challenge.
• Traditional telecom networks have complex operational and billing software. While some is too-inflexible and very expensive, most is a necessary evil to deal with performance management, customer service, creating innovative plans, deal with inter-party revenue-sharing and so on. In a decentralised world, how do you query charges, or call when something fails? How can you watch for problems emerging? (And who watches?)
• The hard part of getting data connections working is often "backhaul", linking a base station or WiFi access point to the main Internet, especially from remote areas. It's quite hard to tokenise digging up roads to install fibres.
• Slow deployment of eSIM-capable devices & back-end infrastructure, and willingness of carriers to offer remotely-provisioned "profiles" to third parties.
• Private cellular networks (even in unlicensed / shared spectrum) need core-network software and numerous other "moving parts". Deploying LTE-U isn't like buying a Wi-Fi access point from a store & setting it up.
• A lot of existing consumer Wi-Fi access points are provided by cable operators & broadband telcos, and integrated with a modem/router. Most people won't want to replace them, or daisy-chain a second device, or re-flash the hardware. Business Wi-Fi systems are usually locked-down by IT departments.
• Anything using a mobile app for control, mining, transaction or advertising is at the whim of Apple's AppStore rules, and to a lesser degree Google's. They also need to deal with updates to features in new versions of iOS and Android, which may break things, or compete with them.
• All of the various parallel schemes will need to inter-work with each other at some point, if they're successful.
• Adding extra latency because of extra network hops (or worse, payment negotiations) is going to be a lousy user-experience. 
• The Internet and telecoms are very bi-directional. Do packets (or SMSs or calls) in both directions get charged the same amounts?
• Advertising-funded mobile connectivity has been tried multiple times, and has multiple problems. In particular, you can't insert ads into most apps, and use of encryption/privacy tools like VPNs mean that cookies in mobile browsers may not work properly forever.

There's probably another 20-100 similar "gotchas" out there, applying to some or all of the token concepts. Part of my work is trying to predict these types of problem before they arise, and have an idea of how tractable they are, and what workaround might exist. If you're an innovator in this space, or an investor, and want someone to cast a critical eye over a project, get in touch. (information AT disruptive-analysis DOT com, or on LinkedIn)

Ironically one area that's almost certainly overestimated as a problem is anything to do with Net Neutrality, though. I've covered various examples of such nonsense in prior posts, such as this one (link).

It should be noted that many of these tokens are thinly-traded, or even unlisted on any major cryptocurrency exchanges. Some are pre-ICO / private-funding. Please note that I offer no recommendations on investing in anything, especially cryptocurrencies. Do your own research and use extreme caution if you're tempted. 


Summary

The tokenisation of telecoms and networks is evolving rapidly. It's genuinely fascinating, as are the potential uses of private/permissioned blockchains inside telcos. However, anyone expecting decentralisation to change the networking world in 2018 (or 2019) is going to be disappointed. 

There's lots of enthusiasm, but many roadblocks in the way. Many of the concepts are likely to prove unworkable - and while some projects may raise enough funds through ICOs or private investors to allow them to pivot, others will likely fail. If you're speculating in the short term, that might not matter. But be aware that harsh realities will come along with the new opportunities.

Please get in touch if you'd like to get deeper analysis, or if you're looking for advisory input as a project team or investor (although I'm not able to give investment recommendations).   

Google buying Jibe Mobile is aimed at turning RCS into Android's iMessage

Like a lot of people, I was surprised by Google's acquisition of RCS specialist Jibe Mobile yesterday. Lots of theories were advanced on Twitter and blogs about this last night:

• Wow, Google is recognising that carrier standards, RCS and IMS are the future!
• Meh, it's an acqui-hire for people who understand messaging on Android
• Hmm, forget RCS device-side apps, Jibe offers cloud-based RCS servers to operators - it's Google's opening NFV play! (me)
• It's Google trying to get US carriers to push Android devices more, by acquiescing to demands for native RCS support (even if Google privately thinks it's rubbish)
• It's Facebook- and TenCent-envy. Google thinks it's missing out on messaging-as-social-platform as its previous efforts have been failures (also me)

On reflection I actually think there's a different story here. 

Forget telcos, the GSMA and 3GPP. Google buying Jibe Mobile isn't about carriers at all. They're a sideshow, or perhaps "useful idiots" in this scenario.

Google (I think) has three competitors in mind: Mostly Apple, but also Microsoft and Twilio.

First, let's step back. There are various uses for "messaging" apps on smartphones:

• Basic P2P or A2P text messages, ideally with features like read-receipts & pictures. And ideally free
• Enhanced messaging (not "rich") with better support for things like groups, white/black-lists, security, maybe "ephemerality" etc. Think of WhatsApp, BBM, Telegram and so on.
• Cool messaging (again not "rich" although they might use pictures or video) - things aimed at "lifestyle", flirting, self-expression, teenagers, and perhaps content streams. Instagram and SnapChat go here.
• Messaging as a platform, where users don't just send messages but can also use mini-apps or plug-ins inside the system for purchases or collaboration. WeChat and arguably Slack (in enterprise) fit in this category
• Messaging-as-a-feature, where messages get embedded into other applications or services via APIs, or are implemented natively. Twitter direct-messages are an example, but there are many others - perhaps even including iOS and Android push notifications.

These are imprecise categories. They overlap, and app providers try to push up from one type to the other - for example the content channels on SnapChat.

But right at the bottom of the list is basic P2P messaging. Traditionally the home of SMS (& MMS). It's been cannibalised in a lot of places by WhatsApp or close equivalents, although in places with flat-rate charging for SMS it's been more robust. But there is one important other player here: Apple iMessage, which gives an SMS-integrated experience built into iOS. iMessage is a well-designed, moderately "enhanced" version of SMS that is free between Apple users and has some better features (delivery notice & typing-awareness) than ordinary SMS whilst having a near-identical UI.

While Apple doesn't monetise iMessage, it makes usng iPhones a bit nicer. It does what the telecom industry should have done 10 years ago, and improved SMS without focusing on "multimedia" as a first step. It's the little things that count in messaging - ticks when someone has read something, an indicator that they're composing a reply and so on. Fripperies like file-sharing and "see what I see video" are irrelevant in 99.99% of use-cases. Get the basics right - usable texts & the occasional picture. Maybe an audio-message function for people with awkward languages that don't fit keypads & predictive text very well.

Now Google has had its own Hangouts messaging app on Androids in the past, which can be used as a default SMS app as well. But compared to iMessage, it hasn't been especially well-received, as it's optional. This means that Apple's automated and familiar green-becomes-blue messaging experience for Apple-to-Apple communications hasn't really been replicated in Android.

I suspect that acquiring Jibe Mobile (with RCS) is an attempt to change this. I think Google wants to use a service which handset vendors already accept being integrated "natively" to become its own free Android-to-Android messenger.

The fact that the mobile operators want RCS to be natively implemented is even better - Google gets the telcos to lean on all the handset OEMs to accept it. 

But of course, the devil is in the detail of the implementation. I suspect that a future version of Android will support RCS as a default app not because of its "richness", and not because of its "interoperability", but because it allows Google to compete with Apple on basic device-to-device enhanced and free texting. Messaging that goes via its own cloud most of the time, or which might interact with the telcos' networks either for "AndroidRCS-Out" or fallback to SMS. 

In other words, this turns RCS from being a "service" into being a basic messaging function within Android. It's not about "richness", either - video chat on Android will still be on Hangouts and via its WebRTC support 99.9% of the time. Google undoubtedly knows that RCS isn't really the basis of a "cool" messaging service either - I highly doubt it wants to compete with SnapChat, at least to begin with. It's not about lifestyle or messaging-as-platform - just a well-integrated way to do free basic messages.
 
So my views is that this is all about creating Google's iMessage, not a ringing endorsement of telco-run RCS or IPX or any of the other industry machinery. The telcos may get the scraps of RCS-in or RCS-out, most of which will be converted back to plain old SMS to terminate on iPhones, or older Androids.


There's also a secondary set of targets here, I think: B2C, B2B and A2P messaging. I'm sure that Google has noticed Microsoft linking Skype and Skype4Business and its other cloud properties. In future, businesses running Microsoft-powered UC or contact-centre software will be able to directly reach out to end-users via Skype, bring messaging, video, presence and so on. I don't think MS really cares so much about person-to-person Skype any more - it's nice, but not really monetised and faces lots of competition. But B2C Skype is different, if it entrenches Microsoft's enterprise platforms and gives businesses a rich (and free) way to talk to customers. Goodbye toll-free numbers, for a start. It also helps Microsoft become a more full-fledged UC player for internal enterprise communications.

I think that Google wants to do the same thing, linked to Google Apps for Work and other services. And having a native "AndroidRCS" (not "TelcoRCS") capability in every device will help. So perhaps, Jibe is intended to become Google's equivalent of Skype. And again, the likely majority scenarios would be internal within the Google ecosyste, plus a small minority of in/out to the telco (or enterprise SIP) domains.

Lastly, I wonder if this is an oblique way to compete with Twilio and a few other PaaS providers. Using a cloud-based messaging platform linked to a native client in Android gives a whole set of possibilities for developers to do free A2P messaging - basically a version of push notifications for people who don't have an app installed. Or easy, free web-to-device notifications (something missing in WebRTC when the user is outside the browser). And again, there is little reason to involve the phone networks except as exceptions or gateways to/from SMS on other devices.


In summary - this isn't a win for GSMA and RCS. It's not "fighting back against the OTTs". It's not going to suddenly revolutionise the market for messaging and promote the hoped-for renaissance of subscribers paying for "richness". It's not about video-chat or filesharing. It's not about QoS. It's not going to compete against SnapChat or Instagram or WeChat. (That traffic has gone to apps that are simply better and cooler. It might get a bit of basic text back from WhatsApp, but not much, as that's the cross-platfom winner in markets with a mix of Androids and iPhones).
I believe that, in fact, this is Google "stealing" RCS for its own purposes - free basic Android-to-Android messaging, with free B2C and A2P messaging to follow. It can vault into the big league with a billion AndroidRCS text users. The amount likely to touch the telcos' IMS's will likely be minimal. And the GSMA has done all the hard work encouraging the handset OEMs to support it. Thanks guys.

(And of course, there's also the very high probability that the whole thing is a total dud, or that users just ignore it, or only gets implemented in a sub-set of Android devices. Google's record here isn't great - think about Wave and Google+ debacles)

Dean Bubley & Disruptive Analysis specialise in analysing the future of voice, video & messaging, including VoLTE, WiFi-Calling, WebRTC and Contextual Communications. If you are interested in a private advisory workshop or project, please contact information AT disruptive-analysis DOT com

Decoding Apple's VoIP, WebRTC, UC and VoLTE strategy

Like everyone else in the mobile industry, I'm curious about Apple's future direction and possible launches and strategic intentions. In particular, I'm interested in its involvement in voice, video and messaging-based communications. We've had both iMessage and FaceTime video-calling for a while... but what about voice? And what about APIs? WebRTC? And what about the impact on telcos' services? And will it get explicitly involved in enterprise comms & UC?  [Quick sidenote: I'm speaking at this hosted-UC vendor event in Frankfurt this week]

First, let's recap. There are (broadly) three sorts of voice communications:

a) Standalone "classic" phone calls, or something very functionally-close to primary telephony. This is basic "Person A calls Person B for X minutes" (or goes to voicemail). Telephony is the bulk of "voice" today, to the extent that people often wrongly use the two terms interchangeably. VoLTE fits here as well. Traditional business PBX systems fit here too, mostly.

b) Alternative forms of standalone voice communications that are not really "phone calls". Classically push-to-talk (walkie-talkie) service has been a good telco example, or conferencing - but there are also new types of realtime audio communication from the developer community. Encrypted secure calls with a dedicated app fit here. Some forms of enterprise mobile UC. One I heard about recently was "networked jamming" for band-members playing or singing in different places. Arguably Skype falls here rather than (a) as calls are often prefaced by an IM session and then "escalated" to voice - a very different user-interaction model than a normal interruptive phone call. Apple's Siri is also clearly a non-telephony voice application as well, albeit with one party as a robot. This domain is growing fairly fast.

c) Embedded voice communications, in which speech/audio gets embedded into a website or application. This is where the action - and future disruption - is mostly going to come from. Well-known examples include voice-chat inside multi-player games, IM/voice hybrids (although these have gone out of fashion somewhat), call-me buttons in websites and a broad array of API- and WebRTC-based applications that are emerging, often with video as well. This model is likely to extend to mobile voice-enhanced applications in the near future - imagine a taxi app with a "speak to the driver" button, rather than sending an SMS with a phone number. In the enterprise space, "proper" collaboration via UC, plus concepts like Hypervoice mostly fit here as well. 

A similar split of use-cases applies to both messaging and video, for example with SMS and Apple iMessage being in equivalent category a), Whatsapp & LINE in b), and Facebook messaging originally as c) but now moving towards b) a bit as well. For video, Skype, Tango and Apple FaceTime are in a), assorted telepresence and CCTV apps in b), and most of the WebRTC and Flash-based video in c), especially in browsers but increasingly in apps as well.

Notably, Apple has shown fairly little overt interest in category (c) to date - embedded communications to date. There are no easy iMessage or FaceTime Video APIs to incorporate them into apps, nor WebRTC support in Safari for websites. However, Apple has now finally joined the W3C's WebRTC working group, so perhaps we'll see some more concrete moves, as it realises that alternate 3rd-party approaches are putting the technology on iPhones, iPads & Macs anyway.

Google, by contrast, focuses more on b) and c) for messaging, voice and video (eg with Hangouts and its WebRTC evangelism), while assorted others can also be plotted on a (rough, first-pass, to-be-refined-comments-welcome) 3x3 chart:

(As an aside , this gives another clear view of where RCS goes wrong - trying to do too many things rather than focusing on actual user requirements. Also worth noting that category c embedded-comms platforms are usually those that have evolved from successful products first)


But back to voice comunications...

FaceTime Audio

Although it has gathered surprisingly little attention, Apple launched FaceTime Audio with iOS7 in September 2013. Despite the name being similar to the video product, it is specifically an audio-only voice calling product, that is very similar to a traditional phone call, with a similar UI/UX. It fits firmly into category a), although at present it is only available on LTE-enabled iPhones/iPads via cellular, or older devices like iPhone 4 via WiFi.

At the moment, FaceTime audio is almost but not quite seamless. It has a separate icon to "ordinary" phone calls, and a separate ringtone. There also seems to be a bit of a lag from swiping the lock screen to audio actually starting, when answering a call. But it's quite close - because it is integrated into the main contact and dialler UI, it's even possible to use it by mistake instead of a normal phone call. I've had a couple of calls via FaceTime audio and been impressed by the clarity, and its good functioning over (probably fairly uncongested) LTE in central London. But it's not quite ready for primetime yet, given the relatively low numbers of both 4G users so far, and the patchy nature of LTE coverage in much of the world.

In other words, it isn't quite as much an in-your-face slap to the telcos as iMessage was with SMS. It's also not usable with the sizeable base of iPhone 4/4S users unless they're on WiFi.As with iMessage, it only works between Apple users - otherwise it defaults to a normal circuit call (typically itself using CSFB, circuit-switched fallback). I suspect Apple is treating it as a large-scale beta at the moment, and monitoring both user behaviour and the app's performance in real-world conditions.

 
Apple & VoLTE

The interesting question arises later this year (or maybe later if my doomsday predictions prove accurate) when more operators, especially in the US, start rolling out VoLTE. I'd say there's at least a 70% chance that the iPhone 6 and iOS 8 won't support VoLTE at all, but that's possibly a function of pressure from AT&T, Verizon, China Mobile and a couple of others. One of the key variables will be whether real-world VoLTE works as well as FaceTime Audio, as well as more strategic issues that Apple needs to consider around IMS. Personally, I expect Apple to procrastinate as long as possible over VoLTE especially if it involves any compromises in terms of user experience or its own control of its users. 

What I do expect is that if FaceTime Audio gets favourable feedback over the next few months, it will be pushed higher in the stack towards becoming the default category-a telephony experience. That will be especially true for markets with decent LTE networks and sufficient iPhone user base to make FT-to-FT calls a decent probability. It may also be dependent on Apple indicating to users that it's consuming data allowance, and that niggling aspects of user experience like the lag in answering are fixed. As with VoLTE, it's also dependent on coverage, although Apple tends to make WiFi use easy on its devices.

One possible scenario is that iPhones become FaceTime Audio-primary, with either VoLTE or CSFB as a fallback, either if coverage is poor or for iOS-to-non-iOS customers. The interesting thing there is it implies a double fallback - there always needs to be CS telephony if there's no LTE coverage. (Although I suspect Apple will be more willing and able to use decent HSPA for VoIP than the operators).

One other interesting question is whether Apple might be able to improve/hack the radio aspects of all of this. The main problem with CSFB is the long call setup times - the network has to push the connection down from LTE to 2G/3G when the user makes a call, which takes some considerable time. Yet plausibly, Apple might be able to pre-empt this if the OS notices the user composing a phone number, or looking at the call register - perhaps only if there is no concurrent data traffic to disrupt. 

Similarly, if the user is already doing an intensive data task, maybe it might allow them to stop the phone shunting the connection down to 3G, just to receive an inbound call. It's wrong to imagine that all phone calls are more important than all data applications and should automatically have the right to override an ongoing 4G data session.

In other words, Apple might try to reinvent and enhance category-a primary telephony, using a combination of FaceTime, CSFB, VoLTE etc, in order to make the experience of calling better. It could develop FaceTime Audio with "interruption controls" for the user, rejig the awful voicemail experience (remember the original Visual Voicemail?) and try to tune the device-based user-experience of telephony, which is something that GSMA, OMA and others have woefully failed to attempt.

In many ways, iMessage is "like SMS, but better". I can imagine FaceTime Audio being positioned as "like voice calls, but better" in future too. (VoLTE is pretty much just PSTN-for-IP in terms of UI/UX, except where vendors try to blend it with video in a "communicator" product, or, laughably, couple it to RCS).

In this way, Apple could be the company that stems the tide of (some) users from clunky-old telephony to categories b & c, especially "nearby" substitutes like Skype.

To sum up, I expect Apple to monitor how FaceTime Audio works in practice, and then push it towards the primary telephony engine for iOS8 if it performs in way that's better for the end-user. CSFB will be the main fallback, although there is a slim chance of using VoLTE at the end of 2014. I could also possibly imagine an FT-A/IMS gateway and transcoder of some type. 


Non-telephony voice

How will Apple play directly in "category B", the non-telephony standalone voice comms category? I suspect that Siri will remain the centrepiece here, using it as a gateway to various forms of cloud-based comms interaction. We already see Siri as assistant; I wouldn't be surprised to see it evolve towards concierge- or interpreter-type roles.


WebRTC

As for WebRTC or other ways to category-c embedded voice and video, I think that Apple is probably acutely aware of its "unofficial" appearance on various of its devices already, despite no explicit support. WebRTC is being enabled either via browser plug-ins (yes, I know WebRTC isn't supposed to need them, but they're emerging anyway), or mobile SDKs from the likes of Tokbox, Twilio et al. I can't see these being blocked by Apple, despite Google's fingerprints all over WebRTC, because it is also supported by pretty much all telcos, all network vendors and most of the IT industry already. Moreover, early signs are that WebRTC will drive a lot of new user-satisfying applications, or enhancements of existing ones. I'd imagine Apple has take a close look at Amazon Mayday as a case-study, too.

I don't think that Apple is able to create its own WebRTC competitor (perhaps unlike Microsoft), because it doesn't have the starting-point assets in productivity software, full-scale conferencing, UC, telco infrastructure, contact centres and the like. It could (indeed arguably should) release FaceTime audio/video APIs for native iOS app developers. But given that Apple has itself been the main culprit driving the dagger into Flash, it must also realise that the browser/PC use of embedded comms will only go WebRTC's way in future, especially give its still-small share of PC installed base, and the fact that Safari doesn't reach onto Windows devices. (In fact, I'd be surprised if more than 50% of Mac users still treat Safari as their primary browser, rather than Chrome or Firefox).

Given its new membership of W3C WG, it wouldn't entirely surprise me if a future Apple iOS used WebRTC APIs or something very close to them, to give developers some way to embed FaceTime Audio and/or Video into apps. (It also wouldn't surprise me to see it acquire one of the cloud comms/SDK players too). There are some open questions over codecs (Apple likes H.264 for video, but has been silent about the "done deal" of Opus and G711 for audio) but I don't see that as a showstopper. I also suspect Apple is slightly worried what might happen when Google (inevitably in my view) puts WebRTC APIs right into Android, meaning that developers could not develop feature-equivalent iOS apps without relying on 3rd party APIs.

As always, deeper analysis of all trends in WebRTC is available to purchasers & subscribers of Disruptive Analysis' WebRTC strategy report & updates. Details here

(Sidenote here: I wonder if Rakuten's CEO or its investment bankers have heard of WebRTC. $900m seems like an awful lot to pay for Viber, given the likely future direction of mobile VoIP)


UC, Unified Communications

Before I started focusing more on mobile, I used to spend more time as an enterprise comms and networking analyst. WebRTC and my Future of Voice research has taken me back into that sphere more deeply in recent years.

Clearly, Apple has been making a more concerted effort in the enterprise recently, with a dedicated developer programme, and rather more overt marketing and positioning of iOS for business/government users. It is no doubt aware that many large companies are moving to iPhones, as well as iOS devices being likely a popular choice for BYOD programmes. iPads are also gaining strong adoption across the business landscape, for diverse use-cases.

However, as yet Apple has shied away from anything resembling a full UC strategy, instead leaving that space for its developers to exploit. But if FaceTime Audio and Video become more-used by employees, might that change? In particular, there may be issues around call-recording that emerge in some sectors like finance.

There is also a B2C angle here, especially where iPhone users interact with a business that also uses Apple devices - Microsoft appears to be grooming Skype & Lync as a way to enable direct connection from customer to business without a 1-800 or similar mechanism.

I don't really see Apple wanting to compete head-on with Cisco or Microsoft or Avaya or BroadSoft and peers in this area. Apart from anything else, the hardware margins aren't there. But I can certainly imagine an attempt to blend or gateway FaceTime (and maybe Siri for cloud voice like recording) with select partners. Unlikely to happen too quickly though - but I'm keeping a close eye.


Summary

Overall, I think the next 12 months will yield much greater clarity on Apple's stance on voice communications, as well as video or messaging. I wouldn't be surprised to see WebRTC (or almost-WebRTC) emerge as an important part of the overall experience, but I think FaceTime Audio is the bit which will suddenly be noticed by customers. VoLTE - if and when Apple implements it in late 2014 or more likely 2015 - will probably be pushed down to a supporting role, when neither FaceTime nor embedded communications is appropriate, similar to SMS's secondary role to iMessage and push notifications today. Siri might be pressed into broader service as a general gateway to "cloud voice" functions, while enterprise UC will still probably not be tackled directly by Apple on a standalone basis - although elements like conferencing might be carved off to compete more with Google.