Monday, March 25, 2013

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.

Monday, March 18, 2013

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:

Pretend the problem doesn't exist

Hope to persuade more operators to adopt/launch RCS in vain hope it might be useful

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:

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.

Develop some clearly differentiated use-cases for the app

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.

Thursday, March 07, 2013

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.

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.

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.

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.

Disruptive Analysis Workshops

- Mobile broadband traffic management strategies- Technology and market evolution- Business model development & unique propositions- Pre-launch feedback on new products and services- Business plan due diligence- Leadership team development