WhatsApp's hidden disruption - driving pseudo-"number portability"

I haven't done a full post about Facebook acquiring WhatsApp - there's been 100's from other places and mine would be lost in the noise. I expect that we'll hear a lot more in coming months anyway, given the CEO Jan Koum's announcement at MWC that it will be adding some form of voice communications in Q2'2014. (Interestingly, Facebook has been ramping up its own embedded VoIP feature in its Messenger app recently, as well).

Obviously I'm curious as to whether we'll see something WebRTC-like from either company as well. My suspicion is that it will be proprietary for now, but perhaps use certain aspects of WebRTC-like behaviour, perhaps in terms of the codecs or firewall/NAT-traversal. We will probably also see a PC-based browser endpoint for WhatsApp using WebRTC before the mobile app.

But that is separate to my thoughts for this post.

I'm wondering whether WhatsApp has another important role to play, which may also prove to be a game-changer for mobile. It is the largest of the so-called OTT players to link its IDs to your mobile phone number. (Viber and others do this too, while Skype and Facebook use a separate address-space).

I've actually been fairly scathing about the use of E164 (the international standard for both fixed and mobile phone numbers) by Internet and app players in the past, as it has tied users to a specific access provider, and not been easily extensible to PCs and tablets without SIM cards.

But WhatsApp is a bit more subtle. While the app keys your identity to your originally-entered phone number, you can also access your "account" from another device with a different phone number. This means you can use WhatsApp on a second phone, when you buy a local SIM card on arrival in a new country (I do this a lot), or just SIM-swap on your primary phone if it's unlocked.

What this means is that you can effectively do a basic form of mobile number portability "by the back door", even in countries where it's not mandated or has a complex/slow process for users to follow. You can get a new SIM or new phone contract - *with* a new number, but all your friends (if they use WhatsApp) don't need to change your contact details in their addressbook.

I still "appear" and can be contacted at +44 794xxxxxxx on WhatsApp, even when I'm in Singapore on +65 9xxxxx 

In effect, WhatsApp decouples your E164 phone number from your access provider and turns it into an OTT ID. It does mean that you need to keep your old number "live" eg sending one SMS per month on a prepay PAYG account, though - presumably it all gets a bit messy if the number expires and gets re-allocated to someone else, although that could probably be worked out in the cloud by looking at your social graph.

My sense is that this will drive continued growth and stickiness of WhatsApp in countries without MNP, or where it is cumbersome. It also means that every incidence of churn will likely further entrench its use.

One other comment about WhatsApp - it (or its various competitors like LINE) is indispensable for people with friends living abroad. International SMS pricing is still, for the most part, ludicrously high and often opaque to end-users. It took me 5 minutes to find that my UK operators charges me 30p (c$0.50) for sending texts to non-UK numbers. There isn't even a price listed on the website for international MMS/picture messages. Obviously, I message my friends in Singapore or the US or Germany via another chat application or email instead, as I'm sure most other people do as well.

It will be interesting to see how the still-minor telco RCS community handles this dilemma - it's pointless to discuss multi-operator interoperability, or RCS "hubs" or the IPX interconnect network, if it is driven by silly wholesale termination fees for messages. And yet I see little indication that there will be global, free RCS peering any time soon. And if users prefer WhatsApp to RCS some of the time (ie chatting to international friends) then they'll likely use it all of the time, especially if they churn as well.

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.

The big problem for VoLTE...

... is that there are at least 10 completely separate problems for VoLTE.

I've long said that VoLTE is a good idea in principle (ie having a standardised "plain vanilla" carrier telephony service for wireless IP networks). Over six years ago, I predicted this was necessary, but would face many practical difficulties, so getting started ASAP was important, even on old HSPA networks before LTE.

It took years before fixed VoIP worked well. It was invented around 1997, but it was a least 7 years later that it even started to be reliable on enterprise Gigabit Ethernet LANs, where the CIO was free to use whatever equipment and QoS tools were needed. The first carrier broadband VoIP was launched by Softbank Yahoo in Japan in 2002. Twelve years later, we're still at less than 30% replacement of global circuit PSTN today.

The idea that adding not just cellular and mobility, but a completely new radio, RAN & EPC architecture to the mix would make 4G VoIP any quicker to launch/deploy/adopt is wishful thinking of the highest order.

And so it goes.

I keep getting pitched by vendors with solutions to bits of the VoLTE puzzle I hadn't even realised existed. Yesterday was the turn of Stoke, talking about latency inside routers and gateways from packets having multiple hops between functional blades doing DPI, encryption, routing and so on. Apparently the impact on small packets (step forward, voice calls) is particularly bad. I'm not a router-architecture specialist, but it sounds plausible. Apparently it's also a problem that will get worse as NSA-inspired paranoia inspires telcos to put harder crypto in various bits of their IMS/voice networks in future. 2048bit-wrangling won't be quick or easy, especially if it needs to be done sequentially with all the other functions in the chassis.

I'm just adding that to the ever-growing list of serious obstacles that VoLTE faces in actually getting to widespread launch and adoption.

An incomplete list of VoLTE's problems, some technical & some non-technical, includes:

- LTE coverage & capacity being good enough (including indoors)
- LTE backhaul being good enough
- SR-VCC not working very well
- Handset availability
- Handset battery life
- Handset client UI
- The need for some sort of IMS platform & all that entails
- Roaming- 911 / 999 / 112 emergency calling
- Internal VoLTE network security (vs hacking, DDoS etc)
- Integration with billing & OSS & support systems
- Multiple layers of QoS mechanisms, from the radio to the core
- DIAMETER to handle all the signalling from all of the above bits & pieces
- Making all the "furniture" like ringtones & voicemail work OK
- API exposure platforms if needed
- Handoff back to 2G/3G circuit (& coverage, RF etc etc)
- The normal interop issues between vendors' & OEMs' gear
- How does a VoLTE MVNO work, exactly? (Anyone heard of one? No, me neither)

Oh, and if fixed-VoIP is anything to go by, we'll probably be dealing with a host of new & exciting acoustic failure modes that require a black-belt network & device media-engine ninja to diagnose.

Most of these issues are completely orthogonal to each other - and are being fixed by vendors who are probably mutually unaware of the existence of each other, or each other's problems. The likelihood of inter-dependence is probably high. All the fun new stuff coming down the 4G/5G pipeline like coordinated multi-point networks, small cell overlays, carrier aggregation & so forth probably won't help either.

Meanwhile, in most advanced markets there is now flat or declining demand for vanilla telephony (& revenues/profit associated with it), even in perfectly-working GSM guise. Except where previous high prices & elasticity means a bit of latent demand still lurking, usage minutes are going to fall in future. And no, so-called "HD" voice won't make a blind bit of difference - it's available for 3G already, if it mattered that much ,and it doesn't.

In other words, VoLTE is now very late, with new problems emerging all the time, which are likely to be ever more expensive to fix. It's serving a declining market for a 120-year old product that consumers are starting to desert and dislike. It's based on a clunky, expensive and complex application platform (IMS) which isn't fit for the 21st century's communications trends. And all the old networks & CS systems will need to be kept in place for at least a decade (maybe two) in most countries, adding to the overall OPEX.

Not pretty.

And in other news, I've had inbound calls on both FaceTime Audio and Skype on my LTE iPhone in the last couple of days. Both needed a couple of seconds juggling with the UI to unlock the screen & answer the call, but seemed to work fine (with HD & optional video, obviously) once they got going. And I'm not even going to mention WebRTC's inevitable rise over the next couple of years.

I'm sure we'll hear lots about VoLTE in Barcelona. But as of yesterday there were 268 LTE networks operating in 100 countries (source: GSA), yet I count only 4 "proper" VoLTE (3 Korean telcos + MetroPCS) launches and a couple of press-release face-savers. That's a big enough red flag.

So, how many more "big problems" still need to be fixed for VoLTE? That's the problem. We don't know. And worse, most of the problem-solvers don't even know each other. I wouldn't want to be a vendor dependent on this space, as you're relying on many many other peoples' ingenuity rather than your own. I'd be investigating alternative sources of business too.

"Sender-pays" is a ridiculous 19th-Century idea misapplied to the Internet

I'm currently doing a fair amount of work looking at next-generation fixed and mobile data tariffs and business models.

One of the concepts I still see expounded is the idea of "sender-pays" models, where a third party (typically a content or application company) pays for a consumer's data usage for a given website or app.

Usually, this is given equivalence to either 1-800 phone numbers, or maybe the original model for the postal service, where the sender (generally) pays for the postage for a product, rather than the recipient. Occasionally, people talk about the Amazon Kindle or some other dedicated hardware such as smart-meters or in-vehicle telematics, where the network provision is vertically-integrated into the offer.

This has recently come to the fore with AT&T's suggested "sponsored data" model, which I believe will fail. It is also a recurrent theme among certain lobbying and industry groups, which keep trying to come up with ways for Internet access to be paid for "twice", usually with spurious references to "sustainability".

(I wrote a full report on the near-certain failure of prospective 1-800 models for mobile data some time ago - http://disruptivewireless.blogspot.co.uk/p/1-800-dataplans-report.html )

I thought it was worth reiterating a few of the reasons why "sender-pays" is a pointless, misleading or maybe even dangerous metaphor to use:

• With very few exceptions, there are multiple "senders" in any given Internet interaction. Most obviously, there is upstream traffic as well as downstream. Who is responsible for the upstream?
• The nature of the web is very bi-directional. Your web-browser sends (and receives) various data in the background, using technologies such as JavaScript.
• Unlike 1-800 and postal models, users frequently use alternative connection mechanisms, especially 3rd-party WiFi. Few content companies will be happy to have different business models depending on how a user connects with their phone/tablet to their servers, especially as they have no control. It will also be in their interest to push users to free WiFi rather than sponsor cellular data
• No content/app companies would want to have 800 different "sender-pays" arrangements with every network operator, and possibly multipliers of that given each has many different plans.
• No content/app company is going to want to pay extra sponsor data where users have more-than-enough in their monthly/PAYG quota. 
• On a typical web-page, many elements are served from CDNs, advertisers and other sources. Except for standalone downloads, it will be very difficult for users to ringfence which bit is sponsored - and even harder to demonstrate this in-app or in-webpage
• There will need to be very strong controls for the sponsor - eg managing fraud & abuse (eg if a competitor tries to rack up bills by downloading excess volumes), dealing with network problems which drive users to hit refresh (or re-download) for problems which are the service provider's responsibility
• Entirely unclear how "sender" models (eg notifications of sposored use) maps onto app-based models, especially in iOS. Many, many "gotchas", eg push notifications
• Poor fit with adapative-rate codecs & other solutions, which will vary the amount of data depending on network conditions and therefore make predictions of volume/cost impossible.
• The content/app company will often be at the mercy of the device/OS choice of the user and how it requests / caches / transmits / compresses data. This is utterly different to a 1-800 number where a phone is a phone is a phone, and a "minute" doesn't differ based on what type of device the user owns

There are many other pitfalls, erroneous assumptions and outright fallacies here. There is also a huge moral hazard around transparency, neutrality and potential damage to the wider Internet model which is a multi-trillion dollar benefit to the global economy and democracy. While AT&T has been very careful to stay on the right side of Net Neutrality for now, it is entirely possible that other operators will be consumer-unfriendly or simply fail to think through the ramifications.

The bottom line is that the sender/recipient model is not the way the Internet works. It is fine as a piece of rhetoric to talk about sponsored / 1-800 / third-party pays models for data services (especially outside Public Internet Access), but it must be remembered that a lot of the metaphors employed are archaic and do not translate to the reality of HTML or application design.

In particular, the use of 3rd-party WiFi puts a coach & horses (deliberate 19th Century reference!) through most of these type of models, as it gives both users and content/app companies a great incentive to arbitrage away even the current use of quota-driven broadband. I've also seen sponsored WiFi from app companies ("Free WiFi if you use Office 365"), which is likely to be better-value & better-publicity for Internet firms.

WebRTC Asia-Pacific Forums: conference report

Last week I attended the first two public WebRTC conferences in Asia, co-organised by TRPC and Inspira Events, in Hong Kong and Singapore. While other Asian events have had presentations and sessions on WebRTC (I’ve spoken myself at Communicasia, ITUWorld & TADS in the last year), these were the first dedicated shows I'm aware of. 

I was heavily involved with both, book-ending the events with two presentations on “What is WebRTC & Why is it Important”, and “What’s next in Asia for WebRTC?”. I also moderated a panel on telecoms/OTT issues around WebRTC, and sat as a panellist on the enterprise session.

Overall, the two events went well, especially given the very short notice with which they were arranged and marketed (there was no website until mid-December!). I think there were about 70-80 people at each, with sponsorship from Temasys (itself from Singapore), Oracle and Cisco.

The two days had a very different “feel” to them. Partly this may have been logistics – I generally find square-ish rooms with “cabaret” seating at round tables to have a better atmosphere than long/thin rooms with rows of chairs. But I’d say that the Singapore audience seemed more knowledgeable and engaged than the HK one, especially in terms of questions and participation/discussion in the breaks.

HK seemed to have quite a lot of enterprise and system-integrator/VAR folk who had heard about the “next big thing” and were there to see if it could be packaged up and sold as a product in the short term, like a videoconferencing or UC solution. There were also some of the local telcos in the room, who seemed more on a fact-finding mission than with existing strategies. 

However, there were no (obvious) local startups or developers or disruptors - something which a couple of other people have concurred with subsequently. Some of the telcos are quite advanced on areas like connectivity (pervasive telco-administered venue WiFi, for example), but I was disappointed not to encounter Digital Services / Telco-OTT folk more.

Singapore, on the other hand, seemed to be more solidly web and telco-centric, as well as some people from UC/conferencing backgrounds, plus a few investors, consultants and industry luminaries. It is also the home of Temasys (disclosure: I am an advisor) which has obviously built some local awareness, and brought in some of its clients/partners.

There were also some vocal and knowledgeable SP participants both from Singapore itself and other places such as Malaysia. There were also a few "big vendor" participants and a few web players.

The three sponsors presented in both cities:

• Oracle gave a counterpoint to my own upbeat introduction, by examining the problems & issues faced by WebRTC in real-world deployments, obviously with a focus on areas assisted by its own gateway/SBC platforms. It covered aspects such as security (eg protecting against WebRTC DDoS attacks), scalability of key infrastructure domains (eg media handling in large-scale NAT traversal use-cases), ID management and application management across multiple network transitions ("rehydration"). While I agree with some of my more scornful peers that some of these issues might well be dealt with in alternative fashion (including using open-source elements), it seems likely that many SPs, large enterprises and platform players will look for packaged and integrated vendor offers.
• Temasys focused on the emergence of "embedded communications". (Slideshare presentation here), with both background and client examples. This broadly aligns with my own view that embedded / platform-based voice and video will become ever-more important, and that WebRTC is the catalyst to take it to massmarket. Using an analogy with a "slice of pizza" it pointed out that WebRTC will manifest in various ways, such as mobile SDKs, It also covered an element I'm seeing more & more - plug-ins for IE & Safari to enable WebRTC before official support. A couple of interesting customer prospects/projects were highlighted - including embedding video into a social/dating app.
• Cisco talked mainly from the perspective of collaboration - essentially talking about the evolution of the environment for its products such as WebEx and Jabber. It indicated upcoming support for WebRTC - not just for conferencing access, but also features such as "co-browsing" for areas such as B2C support, and "social collaboration". I've already seen a demo of a "guest access" version of the Jabber client, albeit one using a dedicated plug-in for creating SIP in the browser, rather than "proper" WebRTC. Apparently there's been a Jabber SDK for years, but few app developers have exploited it - there is a hope that WebRTC should solve that in future with a friendlier SDK. The speaker also referenced ongoing work on QoS mechanisms for WebRTC, both in SP and enterprise networks. He predicted 2014 as a year of early releases and a lot of work on UIs and related elements, with proper take-off next year.

A rival analyst from Ovum in HK presented his view that, while enterprise WebRTC might happen sooner, in the broader telecom services space it would be "confined to low end services" and probably had a 3-5 year time horizon, because of delays in standardisation & interoperability. He also tried (rather bizarrely in my view) to estimate WebRTC market size as a fraction of Ovum's figure of "amount lost by operators to OTT VoIP", ie how much can be "blamed" on this technology. I'm not 100% convinced that it's been properly factored into many general "voice and messaging" forecasts at all yet.

Overall, my perception was that he was seeing telco WebRTC through the lens of conventional services (SS7/IMS integration) which I agree will take a lot of time to emerge, but missing the various other operator involvements through enterprise units, developer platforms, digital services and so forth. This is why I advise telcos to focus no more than 20-30% of their total WebRTC effort & investment on areas like core/IMS integration.


Perhaps the most disappointing speakers for me were from Google, who resolutely pitched the company's enterprise cloud suite, with virtually no mention of WebRTC, even when prodded during the Q&A. It's possible that the developer/WebRTC/HTML5 team just weren't available to speak, but it was deeply disappointing that there was no evangelism, given what I've seen from them before. That said, the presentations themselves were pretty interesting on a standalone basis - just not especially relevant to the main theme of the events.


In my view, it is this lack of HTML5/WebRTC evangelism (and, perhaps, developer appetite for it) that may hold back Asia-Pacific development of WebRTC, outside discrete arenas such as service providers in Japan (eg NTT's Skyway platform) and big projects led by the likes of the events' sponsors. I'm not seeing an awful lot of grass-roots web and app development and tinkering with voice and video, in the same way we're seeing WebRTC innovation in the US, Europe and a couple of other pockets. It might be that the catalyst will be one of the big regional Internet players - Tencent, Alibaba, LINE and so on - adopting it first. (It's worth noting that the events were inexpensive to attend - $100 level or so - so that should not have been a major barrier to startups).


I'd like to see Google, Mozilla and others get more involved in WebRTC developer engagement in the region, trying to run the types of halfday tutorials or hackathons I've seen well-attended at events elsewhere. It would be nice to the other Western platform players such as Tokbox, Plivo and Twilio paying attention as well, as they tend to have good outreach to their existing communities.


Overall, I found both events interesting, and illuminating both about the general state of WebRTC and specifically where (some parts of) Asia is in its evolution. The co-organisers need credit for bringing the forums together so rapidly - both over Xmas and with Chinese New Year looming this week. Ideally, I'll get a chance to take the temperature in other parts of the region soon - especially Japan, South Korea and China, all of which seem to be putting a lot of attention on the technology in terms of research and standards participation, but with only limited visible output so far. On other general aside: in my view the companies based in Asia which are most vocal about WebRTC (thus far) are NTT, Temasys and Huawei. It will be interesting to observe which players come next.

WebRTC DataChannel: Yahoo acquires PeerCDN. 2014 just got more interesting....

There were two disappointments for me from last week's WebRTC conference in Paris & recent ongoing news:

a) Still no major public WebRTC involvement from other big Web players beyond Google (unless you count Amazon Mayday which is still unconfirmed as WebRTC or not)
b) No really exciting new things happening in WebRTC DataChannel for the past 6 months

Both changed yesterday, with Yahoo! buying WebRTC startup PeerCDN. 

In my presentation at the Paris conference, I predicted that 2014 (see Slide 22 here) would see "major Internet players using WebRTC" and "Surprises, especially around data use of WebRTC". Looks like even I've been caught out by the speed of WebRTC evolution - they've both happened with 2 weeks of 2013 still left.

Silicon Valley jokes about Yahoo! acquisitions aside, this is a really interesting move. PeerCDN is one of a handful of startups trying to use WebRTC's browser-to-browser data communications ability, to reduce bandwidth/CDN costs for content companies - and ideally to reduce latency as well. Peer5 and StreamRoot (which was in Paris last week) are also in this space.

The idea is simple - rather than having all users download content from the company's own servers, or that of a commercial CDN like Akamai or Limelight, have some of it downloaded from each other. If two people are on the same site at the same time (or perhaps with cached content in their browsers), connect the two browsers together using WebRTC's less well-known DataChannel API, and deliver certain chunks of content like that instead.

There are various implications:

- Reduce the outbound bandwidth costs (or CDN delivery costs) of the content company
- Improves website response times, especially if the users concerned are geographically close to each other
- Indirectly increases uplink local-access bandwidth consumption, as the users transmit some of  their data back "upstream" to the other peers
- Represents a legal use-case for P2P data, as the content company is in control, and indeed in approval.
- Impacts the potential revenues and margins for traditional CDN players, and massively reduces entry barriers to that market
- Makes it harder for telcos to monetise on-net CDNs - although perhaps easier to launch them, if they white-label services such as StreamRoot's.
- It doesn't matter if only a % of browsers are WebRTC-capable. Where it's not supported by a given user's device, the content delivery reverts to Plan A - some reduction in bandwidth costs is definitely better than nothing.

Now, it's one thing doing all this on a small scale and demonstrating it at WebRTC conferences. It's quite another building it into a service that competes meaningfully with the likes of Akamai, which have global footprints, established salesforces and customer relationships, and many other value-added services - and also a fearsome army of IPR lawyers and an arsenal of patents. 

Yahoo!, for all its problems, is at least in the category of companies that can play those games - or else perhaps it may prefer to use the technology internally, rather than exposing it as a 3rd party service. Various commentators have suggested it might speed up its notoriously laggy webmail, but I don't think that's the key application here, as little content is shared between users. It's also possible that the CDN project will get lost in the background, with Yahoo! actually just buying the three engineering innovators behind the work, for more general development on WebRTC.

As for DataChannel, this is one more signal that it's perhaps even more important and disruptive than the voice and video bits of WebRTC. We've already seen it used for various types of screen-sharing, Google's Chromecast dongle and a few other early attempts. If the CDN use-case proves properly commercialisable by Yahoo/PeerCDN or others, then it's another landmark.

Other use-cases for DataChannel are also being widely talked about - certainly app/screen-sharing will be a major (if unspectacular) one, most likely bolted onto conferencing and UC solutions. But the real "fun stuff" will occur when it enables realtime data streaming for things like sensors, Internet-of-Things objects, health monitoring and so forth. Let's see what happens - but I have a feeling that we'll get a lot more than just yet another "Skype in the Browser" clone from DataChannel. 

This is also an area that telcos should pay attention to - well away from the ongoing IMS/WebRTC integration for VoLTE or anything else. I've said for a while that WebRTC needs to be dispersed across multiple business units in operators, and not just left to the voice/core-networks group. Opportunities for exploiting WebRTC DataChannel should be high on the priority lists of the CDN group, content/video optimisation, M2M, healthcare & other verticals, devices and numerous other telco business units. If operators don't get going on this immediately - at least in the labs or other skunkworks - then who knows what other 3-person startups will create independently.

Overall, I think this acquisition is a very interesting move. It marks the first overt buyout of a WebRTC player by a Silicon Valley behemoth (Telefonica/Tokbox was something else). That could trigger more VC attention, as well as focus attention on whether Google or Apple or Facebook or LinkedIn also start spending money on the next stage of the web. It's also a wakeup call for all those in the WebRTC community who forget that data is often at least as important as voice or video.


Interested in reading more analysis & comment about WebRTC? I am the only analyst who has done a full, cross-sector research report, covering all major use-cases, with conclusions and forecasts updated regularly. Click here for details of the Disruptive Analysis WebRTC report & update subscription.

The beginning of the end for IMS. WebRTC is the catalyst

I've been skeptical about IMS - especially in mobile - for a long time. But while I'm wary of confirmation bias, recent events mean that I am now confident the telecoms industry is internally recognising IMS's limits. Over time its relevance will dwindle, although conservatism and forced-need will give it some residual short-term momentum.

I started writing about IMS in 2005 and published a report in mid-2006 pointing out that nobody had bothered defining what an IMS-capable handset was, and that as a result it would be at least 2010 before commercial massmarket mobile IMS services were likely. Clearly, that was an over-optimistic view, as it's now the end of 2013, and probably less than 0.5% of handsets are properly IMS-capable, and a much smaller % of customers actually use the services.

Since 2006, my stance on the technology has hardened, especially with the ongoing farce that is RCS/joyn. While basic IMS platforms make some sense for replacing 40-year old fixed networks' switches with circuit telephony-equivalent VoIP for opex saving, the same does not apply in mobile, where new and cost-optimised circuit cores are a long way from the ends of their depreciation cycles.

There is not a single service that IMS can do that other platforms cannot - typically with greater flexibility, lower cost and much faster time-to-market. Furthermore, IMS's developer base is woefully small, while telco CFOs view investing in it - at absolute best - as a necessary evil. Its current role seems to be for operators that have painted themselves into a corner on VoLTE, where they can't spare the spectrum to maintain CSFB or SV-LTE any more. A few have drunk the RCS koolaid, but even there, outsourcing or cloud platforms means that little internal investment in IMS platforms is needed for a minor experimentation or deployment. A handful of stalwarts still seem evangelical, much to the skepticism of other operators - and often many of their own staff in other departments as well.

In 2009, I light-heartedly mused whether the mobile industry had essentially "nailed the dead parrot of IMS to the perch of LTE" - ie tried to tie the standards so closely together that operators would be forced to deploy IMS anyway, despite it being a dead & moribund platform for innovation. (If you're a Monty Python fan, have a laugh at my fairly notorious blog post closely referencing the famous sketch). 

It seems I may have been prescient. This weekend marked the 4th anniversary of the first LTE launch, and yet only a handful of operators have deployed VoLTE in the wild - conspicuously not including TeliaSonera, whose 2009 network set the 4G ball rolling (Norwegian VoLTE is as rare as Norwegian Blue parrots, it seems). 

The South Koreans have it running, as does MetroPCS in some areas, although its new owners T-Mobile are more equivocal about deployment schedules elsewhere. O2 Germany has it "at a few base stations" (ie a face-saving press release) and two HK operators have made announcements of imminent launch. Only this week, UK LTE operator EE said it would "trial" VoLTE in 2014. This fits with my oft-stated summary that:

"VoLTE was the right idea but 5 years too late; RCS was a stupid idea to begin with". 

VoLTE has been plagued by myriad complexities, such as the SR-VCC handover to 2G/3G, the need for full coverage (& often small cells and fibre backhaul) to support it, innumerable integration issues, and perhaps above all the basic economic costs of the IMS platform and devices/clients needed to make it work. In many countries, voice telephony revenues are already flat or declining - which makes investment in a complex new platform, for a potentially declining service, a difficult business case to justify. Add in uncertain support from Apple and the need for a Grade-A network including indoor coverage, and the argument looks weaker still.

Even in the fixed telecoms world, there is very little non-telephony use of IMS. Network-based videoconferencing, enterprise unified comms, IM and a handful of other services are deployed but little-used. In most instances, telcos resell non-IMS third-party conferencing or UC solutions instead, while far more have partnered with Internet/app companies like Whatsapp than have launched RCS.

IMS has increasingly been made obsolete - both for applications and as a control-plane solution - as a concept by:

• Widespread use by billions of people of the open Internet
• Wide availability of fast fixed and mobile broadband, allowing third-party VoIP and video services to emerge at low cost, offering free/cheap services
• User behaviour indicating that "quality of service" only matters some of the time, and that often quality is easily ignored if the price is right/zero
• User behaviour indicating that "islands" are often seen as more valuable than interoperable standardised services, for many use cases. "Walled gardens" are fine as long as the users are themselves willingly climbing in over the walls
• Smartphones, initially from Nokia but now Apple & Samsung have made it easy for alternative communications applications to be accessed and installed. Apple has some of its own, in particular.
• Hopeless timescales for IMS standards development, especially for applications. The committee-led bureacracy of RCS, with lengthy monthly/annual cycles, has to compete with app players that can make decisions on new features in an afternoon, and deploy them the week after.
• The most vibrant telecom service domains are largely outside of IMS's grasp - content, IPTV, cloud SaaS, hosting, vertical initiatives and so forth. Conversely, "session-type" communications such as telephony and SMS/IM are declining in revenue (and often, relevance).
• The low relevance (and or focus) placed on IMS by telcos' Digital Services groups - whether they are doing Telco-OTT VoIP, content/entertainment offers, or vertical services for healthcare, transport, energy and so forth.
• The need for telcos to accept multiple identity models rather than key everything to phone numbers and subscriptions
• Wide use of 3rd party WiFi on mobile devices, meaning that centralised policy-control is mostly irrelevant, while operator-managed services need to work over generic connections as well as "on-net". If services are used OTT-style some of the time, then why not all of the time?

Yet despite all this, there is still a huge part of the telco and vendor community that doggedly sticks to the view that IMS's time will come. That VoLTE and RCS, and maybe some lipstick-on-a-pig API exposure layered on top, will lead to its rightful and "ubiquitous" implementation across all operators. That fully-interoperable, QoS-managed, access-integrated communications services of the future will be based upon it.

The reason for this is simple: it is standardised, and "therefore" it is the only choice. A generation or two of telecoms engineers and architects have been brainwashed into believing that standardisation is essential, innovation is done by vendors/committees, and "interoperability" at a service level is paramount - and transcends "minor" issues like user preferences, wants and needs. Now clearly, certain aspects of interop are essential - notably in the radio network to make sure that device A works with network element B - but for actual end-user services, interop is only needed for basic lowest-common denominator offers. (See here for an earlier blog post on the limits of interoperability)

In other words, the reason that IMS has been grinding on for so long - despite its limitations being obvious, and numerous "refugees" publicly denouncing it - is because the telecoms establishment can't bring itself to admit that it got the last decade so spectacularly wrong. This is understandable - it's a well-known psychological syndrome called the Endowment Effect which means you tend to like what you already have, more than is reasonable or logical. People have invested a lot of time and money in IMS - careers, even - and are reluctant to acknowledge that it's been mostly wasted. 

We also tend to have another cognitive tendency to defend our own belief systems, in spite of overwhelming evidence that they're flawed. There is even a neuroscientific reason for pushing back against the blindingly obvious, to the extent of even lashing out at it - our brains are programmed not to change complete frameworks of perception.

Which is why last week's WebRTC conference marked a turning point for me. Parts of the "establishment" are now shifting. Most notably, the term "Post-IMS world" was used by a senior operator labs representative from Portugal Telecom, as well as another from Orange showing slides with IMS potentially being an add-on to a WebRTC-centric domain, and not vice-versa. IMS is still there, but it is relegated to the same sort of "legacy interop" category as the PSTN. In other words, IMS will be about for a while, but will decline in importance, and certainly will not be where the innovation or new revenue happens. (PT has been working with Deutsche Telekom on an experimental WebRTC platform called WONDER, standing for "Webrtc interOperability tested in coNtradictive DEployment scenaRios").  

Now at the moment, these noises are coming more from the Labs and CTO offices of operators, not the architects deploying today's infrastructure. I'm sure that all those operators have IMS loyalists as well, but open dissent is often necessary before a coup. These are experiments and ideas about the future. Nevertheless, they represent an important sign that the mindset is shifting. As per the title of this post - it's the beginning of the end, not the death knell quite yet.

Perhaps more significant was a vendor speaker who is also on the 3GPP project to integrate WebRTC and IMS. Some of this was about straightforward gateway specifications & timelines, but other aspects of it seemed similar to the WebRTC-first world-view espoused by PT and Orange. There is tacit recognition that services will often be anchored primarily on the web (or enterprises' IT), but will sometimes need to interact with PSTN/IMS as a secondary role. This is a first in my view - the 3GPP acknowledging that some communications services, deployed or sold by telcos, may not be IMS-based in the future. We all know it's true - many Telco-OTT propositions are built oustide the reach of IMS - but it's rare to get "official" statements recognising it.

One other thing was around authentication and access to telcos' WebRTC services. Obviously, many vendors and some operators want to re-use the phone number, SIM credentials and so on. This makes sense for certain use cases, although the phone number remains totally inappropriate for most such instances on the web, where users may be anonymous, temporary users, "guests" and so on, rather than "subscribers". One of the possible items for the second version of the 3GPP standard is called "large-scale 3rd party access". As the event chair, I challenged the speaker to define that more clearly - I asked "Is that a euphemism for 'log on with Facebook'?". The answer? An unequivocal, one-word response: "Yes". Again, that to me is a landmark of realism from 3GPP.

The brutal truth is that many telcos will keep banging their heads on the IMS wall, because they do not have the resources or vision to see beyond standards, even if they are clunky, expensive or obsolete. Then, they will complain about more-nimble Internet competition. Some will set up Digital Services groups to build their own equivalents, or partner with Internet/app winners. But others will continue down the blind alley regardless. Having the 3GPP at least acknowledge the existence of IMS alternatives is a good start, although not enough. More clear-thinkers willing to challenge entrenched legacy viewpoints in Labs and CTO Offices is also needed - perhaps a tough task in some of the more stubborn operators like Vodafone and AT&T, which are still doggedly trying to push legacy-IMS into the 21st century.

I'd say that there is a strong argument that investors, CEOs and boards need to fire those responsible for wasting time and money on an unworkable technology. Those who have abdicated the responsibility for platform innovation to vendors and standards groups have squandered 10 years, versus the Internet players. I can't recall the last time a telecoms CTO was fired for making a poor technology choice - because usually the "choice" isn't theirs to make - it's predefined by a group of people who never talk to end-customers or developers. I still meet people saying "Ah, but you can't send a message from Facebook to LinkedIn, or a make a video call from Skype to Facetime"

My view is that IMS is reaching its zenith. It still has some brief upward momentum left - but the rockets have run out of fuel, and gravity is starting to pull it back. Whether it has reached a stable orbit, or will break up on re-entry is unclear. Some more VoLTE deployments will probably keep vendors happy in 2014 and 2015, although it is abundantly clear that it will not be the "default" telephony solution of the future. I'd be surprised if VoLTE ever gets beyond 10% penetration of the global mobile user base, given everything else that is going on with communications and voice and the moment. RCS will struggle to gain active use by 2%, I'd expect, and most likely much lower. The API argument for IMS/VoLTE/RCS is also pretty ugly, especially as IMS-capable device penetration will never get to the "ubiquity" that evangelists are promising. Again, there may be some exceptions, but the bottom line remains that IMS is providing the wrong "raw ingredients" for many use-cases, so exposing them via APIs won't help, except for some niches. It's also possible that some countries will become "IMS islands" because of local specific issues - China, perhaps.

But I expect that many operators will simply decide to avoid IMS entirely, or deploy a bare minimum for roamers and a couple of point features. Even open-source efforts like Metaswitch's Project Clearwater won't change the end-game. Lower infrastructure costs are good news, but the lack of developer enthusiasm - and the dependence on the same tired legacy interop model - is a major limiting factor. That said, helping telcos to fail faster and more cheaply is at least in line with the Internet/app ethos they'll need to learn anyway.

Overall, we're now at the beginning of the end for IMS as an application platform, while its control-layer aspects are also a poor fit with coming network realities and user behaviour. It won't go quickly, but then neither did fax or telex. 

The parrot is still nailed to the perch. But it's still dead.

(If this topic is of interest, please contact information AT disruptive-analysis DOT com for details of workshops, speaking engagements, consulting projects & published research. Or click here for details of Disruptive Analysis' WebRTC report  & update subscriptions)

Many telcos' service innovation & partnering strategies are held back by internal processes

This year I've spent a lot of time with operators around the world. Some of this has been at public workshops such as those I co-run with Martin Geddes, while other engagements have been private strategy sessions about the future of voice, WebRTC or Telco-OTT/service innovation, either solo or with a range of other partners. In addition, I've also sold many operators my research reports and other services, and attended numerous exec-level telecom events like ITU World and ICIN.

Unlike a lot of larger consulting businesses, or major analyst houses, this exposes me directly to an important factor for future success:

How easy is it to do business with a telco, especially as a small company?

As I run most of Disruptive Analysis' administration myself, I am acutely aware of some of the practical issues that others don't see. Top of my list is how easy it is to get paid by a company - how procurement, invoicing and remittance of funds works. More on that below. I also get to see:

• How companies act in terms of internal silos and fiefdoms, with different groups either not communicating, or actively competing and undermining each other.
• How hard it is getting meetings set up - and whether they are useful, productive meetings or an exercise in politics
• Whether "not invented here" syndrome still exists, inhibiting new services and ideas
• The relative power of "conservative" groups vs. the innovators. (Try suggesting the phrase "open source" and watch what happens)
• The lack of willingness to take shots at "sacred cows" and question assumptions - the need for, and value of, QoS is a good one here.
• How few people are focused on the real needs and wants of consumers. Forget all the fancy stuff about having behavioural psychologists and UX specialists - many operators don't even have have product managers for voice telephony.
• Inability to think critically about vendor marketing and hype. I regularly get pitches regurgitated straight back at me.
• Institutionalised need for adding unnecessary process steps. I've recently been asked to write a short 2-page article on a topic I know well. No, it doesn't need a 5-stage effort submitting a draft of the "flow", having conference calls & iterating repeatedly.
• Omni-present shadow of (very slow) legal processes. Yes, telcos are big regulated companies and need to be aware of the fine print. But that doesn't mean that every tiny detail & contract needs to be re-written - often at an internal cost greater than the amount I'm actually getting paid. Be pragmatic, already.
• Technology-related issues such as vendor selection processes.

Often, operators want to talk to me about partnering, or developing new applications and services. Frequently, the conversation turns to attracting web or mobile developers, creating and marketing own-brand Telco-OTT apps, or partnering with existing Internet/OTT players.

But while all this is very worthy, it is often critically dependent on those operators interacting with small firms, often acting as suppliers. They might be individual web developers, small consultancies helping with user-interface design, startups with a cool product that could be added to a telco's bundle for certain segments and so forth.

Companies that telcos might want to do business with are getting smaller. Whatsapp - with 300m+ users - has about 50 employees. Many "established" WebRTC players have fewer than 10 staff. Tsahi Levent-Levi had a great post on this a couple of months ago - it needs about 4 developers to make a decent WebRTC service. That, for example, a telco might scout and decide was a really neat differentiator and cool to resell as an innovative option for their "enthusiast" users, perhaps. 

Same deal for various new forms of infrastructure equipment or software - NFV/SDN startups perhaps, or firms with a clever idea for a value-added voice app. Maybe a next-gen billing system suitable for digital services, based on users rather than subscribers.

You get the idea. While a lot of innovation does come out of big players like Ericsson & Huawei & NSN & Oracle & IBM and their peers, increasingly telcos need to go back to be able to deal with small companies too. Especially developers, both telco-centric specialists and "long tail" software houses for web and mobile.

Yet for most telcos, doing business with small companies is beneath their radar, because the COO and CFO don't really think about these issues - they are struggling with minimising internal costs, maximising internal process efficiency, and perhaps outsourcing "non-core" functions. The knock-on impacts of this on areas such as innovation capability, or business agility, or flexible partnering, don't see much influence.

A specific example is top-of-mind for me. For many operators, procurement is fundamentally broken. It is bureaucratic, slow, and based on the assumption that telcos have a few long-standing vendor partnerships, with companies with teams of lawyers and form-fillers.

I've now faced the following "process" several times:

a) Inquiry from an operator asking about Disruptive Analysis products/services
b) Have a conference call, write a proposal, negotiate, agree the work
c) Have a call/email about logistics & practicalities - travel, location & format, and whether I need to get started on any paperwork upfront. 
d) "Oh no, just send me the invoice, I'll make sure it gets paid promptly"
e) A month or so later, do the workshop or seminar or present the project's conclusions
f) Submit invoice/expenses
g) A week later get an email from purchasing/finance "You need to fill in this form to apply to be on the supplier database". Something that could have occurred a month earlier.
h) Look at form. It asks for every conceivable piece of information, from certificates of incorporation, to bank statements, to shareholder names & details. I've got one in front of me that wants to know full details of any overdraft or loan facilities offered by my bank to my company. And the square footage of my factories and offices. Oh, and it needs an official company stamp (What?) & to be submitted by mail/courier.
i) Read the covering email. I missed the other form asking for a registration fee. Yes, that's right - they want me to pay them money, so they can pay me. Somewhere between a joke and an insult. This has now happened several times.
j) I go back to my client and raise hell. Luckily, as a reasonably-visible analyst I can wield a little influence when necessary, even without having to descend to threats of naming-and-shaming
k) Maybe there's a back door somewhere. A way to expedite invoicing and payment for "exceptions" that just need to get sorted. Go up high enough in the organisation and you can pull some strings. This may still need a shorter form, and a still-onerous purchase-order registration process though.
l) Chase up for actual payment, or suffer 60/90/120-day payment cycles.

This nonsense needs to stop. In the words of one of my colleagues/partners, "Someone in procurement needs to be fired".

Not just because it's a pain for me, but because it's even more of a pain for the companies that operators NEED to work with, if they're going to innovate and partner/develop new services. Honestly - the process tends to be worse for those telcos that don't have in-house resources like software development, and that critically need to work with small and flexible external shops to get things done.

The sad thing is that I'm seeing telcos who are doing the right things - setting up innovation teams, building digital or OTT services, going out and meeting Internet players or content firms to cut deals. But all that risks being window-dressing, if those same "partners" get as far as the internal business processes, take one look and walk away. Or worse, do work, fail to get paid easily and promptly, and suffer cashflow problems as a result. They won't be working with that operator ever again.

(Incidentally, I'd say that some vendors are almost as bad as the operators. But they often do have multiple systems because they're more used to dealing with local contractors, software specialists and so forth).

So if you're a CFO/COO/strategy head - put yourself in the shoes of a small company trying to do business with your organisation, and see how bad or easy it is. Then try the same, signing up to become an Amazon Affiliate, or eBay Seller, or using Google Adsense. Getting paid by Internet companies (or indeed, paying them) is easy. This is why I now prefer to sell reports by credit-card online. I mentally wince whenever someone says "you need to be on the supplier system" just to buy a report.

It's not just the procurement aspects either - it's the long list above.

This is why telcos seriously need to consider setting up fully autonomous new business units to deal with digital and Internet services. And executives need to empower them to ignore all the stupid forms and rules that the mothership clings to. Just as right-thinking "vanguard" telco units are disintermediating their own core network platforms, they need to bin as many of the useless, innovation-inhibiting processes too and start from the ground-up, with agility and flexibility in mind. 

Never mind a decade of MBA-addled nonsense from big-name so-called "strategy consultants"  about how telcos should reducing their number of suppliers. That might be true if you're building huge radio networks (& even then I'd argue it's flawed). It's certainly not applicable to service creation, developer engagement and true innovation in a fragmented, fast-paced Internet world. There, having more and smaller partners and suppliers is essential to survival. Make sure you're not putting them off.