Interoperability is often good – but should not be mandated

Note: this post was first published via my LinkedIn Newsletter. Please subscribe (here) & also join the comment & discussion thread on LI

Context: I'm going to be spending more time on telecom/tech policy & geopolitics over the next few months, spanning UK, US, Europe & Global issues. I'll be sharing opinions & analysis on the politics of 5G & Wi-Fi, spectrum, broadband plans, supply-chain diversity & competition.

Recently, I've seen more calls for governments to demand mandatory interoperability between technology systems (or between vendors) as a regulatory tool. I think this would be a mistake - although incentivising interop can sometimes be a good move for various reasons. This is a fairly long post to explain my thinking, with particular reference to Open RAN and messaging.

Background & history

The telecoms industry has thrived on interoperability. Phone calls work from anywhere to anywhere, while handsets and other devices are tested & certified for proper functioning on standardised networks. Famously, interoperability between different “islands” of SMS led to the creation of a huge market for mobile data services, although that didn't happen overnight in many countries.

Much the same is true in the IT world as well, with everything from email standards to USB connections and Wi-Fi certification proving the point. The web and open APIs make it easier for cloud applications to work together harmoniously.

Image source: https://pixabay.com/illustrations/rings-wooden-rings-intertwined-100181/

 But not everything valuable is interoperable. It isn't the only approach. Proprietary and vertically-integrated solutions remain important too.

Many social media and communications applications have very limited touch-points with each other. The largest 4G/5G equipment companies don’t allow operator customers to mix-and-match components in their radio systems. Many IT systems remain closed, without public APIs. Consumers can’t choose to subscribe to network connectivity from MNO A, but telephony & SMS from ISP B, and exclusive content belonging to cable company C.

This isn't just a telecom or IT thing. It’s difficult to get different industrial automation systems to work together. An airline can’t buy an airframe from Boeing, but insist that it has avionics from Airbus. The same is true for cars' sub-systems and software.

Tight coupling or vertical integration between different subsystems can enable better overall efficiency, or more fluid consumer experience - but at the cost of creating "islands". Sometimes that's a problem, but sometimes it's actually an advantage.

Well-known examples of interoperability in a narrow market subset can obscure broader use of proprietary systems in a wider domain. Most voice-related applications, beyond traditional "phone calls", do not interoperate by default. You could probably connect a podcast platform to a karaoke app, home voice assistant and a critical-communications push-to-talk system.... but why would you? (This is one reason why I always take care to never treat "voice" and "telephony" synonymously).

Hybrid, competitive markets are optimal

So there is value in interoperable systems, and also in proprietary alternatives and niches. Some sectors gravitate towards openness, such as federation between different email systems. Others may create de-facto proprietary appoaches - which might risk harmful monopolies, or which may be transferred to become open standards (for instance, Adobe's PDF document format).

And even if something is based on theoretically interoperable underpinnings, it might still not interoperate in practice. Most enterprise Private 4G and 5G networks are not connected to public mobile networks, even though they use the same standards.

Interoperability can be both a positive and negative for security. Open and published interfaces can be scrutinised for vulnerabilities, and third-parties can test anything that can be attached to something else. Yet closed systems have fewer entry points – the “attack surface” may be smaller. Having a private technology for a specific purpose – from a military communications infrastructure to a multiplayer gaming network – may make commercial or strategic sense.

In many all areas of technology, we see a natural pendulum swing between openness and proprietary. From open flexibility to closed-system optimisation, and back again. Often there are multiple layers of technology, where the pendulum swings with a different cadence for each. Software-isation of many hardware products means a given system might employ multiple layers at the same time.

 Consider this (incomplete and sometimes overlapping) set of scenarios for interoperability:

• Between products: A device needs to be able to connect to a network, using the right radio frequencies and protocols. Or an electrical plug needs to fit into a standardised socket.
• Within products or solutions (between components): A product or service can be considered to be just a collection of sub-systems. A computer might be able to support different suppliers’ memory chips or disks, using the same sockets. A browser could support multiple ad-blockers. A telco’s virtualised network could support different vendors for certain functions.
• Application-to-application / service-to-service: An application can link to, integrate or federate with another - for instance a reader could share this article on their Twitter feed, or mobile user can roam onto another network, or a bank can share data access with an accounting tool.
• Data portability: Data formats can be common from one system to another, so users can own and move their "state" data and history. This could range from a porting a phone number, to moving uploaded photos from one social platform to another.

There’s also a large and diverse industry dedicated to gluing together things which are not directly interoperable – and acting as important boundaries to enforce security, charging or other functions. Session Border Controllers link different voice systems, with transcoders to translate between different codecs. Gateways link Wi-Fi or Bluetooth IoT devices to fixed or wireless broadband backhaul. Connectors enable different software platforms to work together. Mapping functions will eventually allow 5G network slicing to work across core, transport and radio domains, abstracting the complexities at the boundaries.

Added to this is the entire sphere of systems integration – the practice of connecting disparate systems and components together, to create solutions. While interoperability helps SIs in some ways, it also commoditises some of their business.

Coexistence vs. interoperation

Yet another option for non-interoperable systems is rules for how they can coexist, without damaging each other’s operation. This is seen in unlicensed or shared wireless spectrum bands, to avoid “tragedies of the commons” where interference would jam all the disparate systems. Even licensed bands can be "technology neutral".

Analogous approaches enable the safe coexistence of different types of road users on the same highway - or in the voice/video arena, technologies such as WebRTC which embed "codec negotiation" procedures into the standards.

Arguably, improving software techniques, automation, containerisation and AI will make such interworking and coexistence approaches even easier in future. Such kludginess might not please engineering purists who value “elegance”, but that’s not the way the world works – and certainly shouldn’t be how it’s regulated.

In a healthy and competitive market, customers should be able to choose between open and closed options, understanding the various trade-offs involved, yet be protected from abusive anti-competitive power.

A great example of consumer gains and "generativity" in innovation is that of the Internet itself, which works alongside walled-garden, telco or private-network alternatives to access content and applications.

Customers can have the best of both worlds - accelerated, because of the competitive tensions involved. The only risk is that of monopolies or oligopolies, which requires oversight.

Where does government & regulatory policy fit in this?

This highlights an important and central point: the role of government, and its attitude to technology standards, interoperability and openness. This topic is exemplified by various recent initiatives, ranging from enthusiasm around Open RAN for 5G in the US, UK and elsewhere, to the EU’s growing attempts to force Internet platform businesses to interoperate and enable portability of data or content, as part of its Digital Services Act.

My view is that governments should, in general, let technology markets, vendors and suppliers make their own choices.

It is reasonable that governments often want to frame regulation in ways to protect citizens from monopolists, or risks of harm such as cybersecurity. In general, competition rules are developed across industries, without specific rules about products, unless there is unfair vertical integration and cross-subsidy.

Governments can certainly choose to adopt or even incentivise interoperability for various reasons – but they should not enshrine it in laws as mandatory. If you're a believer in interventionist policies, then incentivising market changes that favour national champions, foster inward investment and increase opportunities can make sense - although others will clearly differ.

(Personally, I think major tranches of intervention and state-aid should only apply to game-changers with huge investment needs - so perhaps for carbon capture technology, or hydrogen-powered aviation).

Open RAN may be incentivised, not mandated

A particular area of focus by many in telecoms is around open radio networks. The O-RAN Alliance and the TIP OpenRan project are at the forefront, with many genuinely impressive innovations and evolutions occurring. Rakuten's deployment is proving to be a beacon - at least for greenfield networks - while others such as Vodafone are using this architectural philosophy for rural coverage improvements.

Governments are increasingly involved as well - seeing a possible way to meet voters' desires for better/cheaper coverage, while also offsetting perceived risks from concentrations of power in a few large integrated vendors. This latter issue has been pushed further into the limelight by Huawei's fall from favour in a number of countries, which then see a challenge from a smaller number of alternative providers - Nokia, Ericsson and in some cases Samsung and NEC or niche providers.

This combination of factors then gets further conflated with industrial policy goals. For instance, if a country is good at creating software but not manufacturing radios, then Open RAN is an opportunity, that might merit some form of R&D stimulus, government-funded testbeds and so on.

So I can see some arguments for incentives - but I would be very wary of a step to enshrine any specific interop requirements into law (or rules for licenses), or for large-scale subsidies or plans for government-run national infrastructure. The world has largely moved to "tech neutral" approaches in areas such as spectrum awards. In the past, governments would mandate certain technologies for certain bands - but that is now generally frowned upon.

No, message apps should not interoperate

Another classic example of undesirable "forced interoperability" is in messaging applications. I've often heard many in the telecoms industry assert that it would be much better if WhatsApp, iMessage, Telegram, Snap - and of course the mobile industry's own useless RCS standard - could interconnect. Recently, some government and lobbying groups have suggested much the same, especially in Brussels.

Yet this would instantly hobble the best and most unique features of each - how would ephemeral (disappearing) messages work on systems that keep them stored perpetually? How would an encrypted platform interoperate with a non-encrypted platform? How could an invite/accept contact system interwork with a permissive any-to-any platform? How would a phone-number identity system work with a screen-name one?

... and that's before the real unintended consequences kick in, when people realise that their LinkedIn messages now interoperate with Tinder, corporate Slack and telemedicine messaging functions.

That doesn't mean there's never a reason to interoperate between message systems. In particular, if there's an acquisition it can be useful and imporant - imagine if Zoom and Slack merged, for instance. Or a gaming platform's messaging might want users to send invitations on social media. I could see some circumstances (for business) where it might be helpful linking Twitter and LinkedIn - but also others where it would be a disaster (I'm looking at you, Sales Navigator spamming tools).

So again - interoperability should be an option. Not a default. And in this case, I see zero reasons for governments to incentivise.

Conclusion

Interoperability between technology solutions or sub-systems should be possible - but it should not be assumed as a default, nor legislated in areas with high levels of innovation. It risks creating lowest-common denominators which do not align with users' needs or behaviours. Vertical integration often brings benefits, and as long as the upsides and downsides are transparent, users can make informed trade-offs and choices.

Lock-in effects can occur in both interoperable and proprietary systems. I'll be writing more about the concept of path dependence in future.

Regulating or mandating interoperability risks various harms - not just a reduction in innovation and differentiation, but also unexpected and unintended consequences. Many cite the European standardisation of GSM 2G/3G mobile networks as a triumph - yet the US, Korea, Japan, China and others allowed a mix of GSM, CDMA and local oddities such as iDen, WiBro and PHS. No prizes for guessing which parts of the world now lead in 5G, although correlation doesn't necessarily imply causation here.

There's also a big risk from setting precedents that could lead to unintended consequences. Perhaps car manufacturers would be next in line to be forced to have open interfaces for all the electronic systems, impacting many automakers' potential revenues. Politicians need to think more broadly. As a general rule, if someone uses the obsolete term "digital" in the context of interop, they're not thinking much at all.

I've written before about the possible risks to telcos from the very "platform neutrality" concept that many have campaigned for. Do they imagine regulators wouldn't notice that many have their own ambitions to be platform providers too?

In my view, an ideal market is made up of a competitive mix of interoperable and proprietary options. As long as abuses are policed effectively, customers should be able to make their own trade-offs - and their own mistakes.

As always - please comment and discuss this. I'll participate in the discussions as far as possible. If you've found this thought-provoking, please like and share on LinkedIn, Twitter and beyond. And get in touch if I can help you with internal advisory work, or external communications or speaking / keynote needs.

Note: this post was first published via my LinkedIn Newsletter. Please subscribe (here) & also join the comment & discussion thread on LI

#5G #openran #regulation #telecom #mobile #interoperability #competition #messaging #voice #innovation

Platform regulation? Are you *sure*?

There's currently a lot of focus on regulation of technology platforms, because of concerns over monopoly power or privacy/data violations.

It's a central focus of the Digital Services Act proposed by the European Commission

It's under scrutiny as part of the US Congress House Judiciary Committee report on antitrust

Other governments also focus on "platforms", especially Amazon, Facebook, Google, Apple and a few others.

Typically, traditional telcos cheer on these moves against companies they (still!) wrongly refer to as "OTTs".

Yet there's a paradox here. While there are indeed concerns about big-tech monopoly abuse that must be addressed by regulators... they're not the only platforms that could be captured by the law.

I've lost count of the times I've heard "the network as a platform", or 5G is a platform" with QoS, network slicing etc often hyped as the basis for the future economy.

Yet telcos can have as much lock-in as Apple or Amazon. I can't get an EE phone service on my Vodafone mobile connection. I can't port-out my call detail records & online behaviour to a new operator. There's no "smart home portability law" if I sign up to my broadband provider's service. Or slice portability laws for enterprises.

 

On my LinkedIn version of this post [link], a GSMA strategist commented that unbundling some telco services "does not solve a customer pain point". Yet unbundling *does* often enable greater competition, innovation & lower consumer prices. You only have to look at the total lack of innovation in MNO/3GPP telephony & messaging services in the last 20 years to see the negative effects of lock-in & too-tight integration here. (VoLTE is not innovative, RCS is regressionary). 

 

Even more awkwardly, most of the mobile industry is currently using the exact same arguments in its push to get vendors to disaggregate the RAN.

 

Want 5G to be a platform? You'll be subject to the rules too. Be careful what you wish for... 

 

(By the way, I first wrote about this issue 6 years ago. The arguments haven't changed much at all since then: https://disruptivewireless.blogspot.com/2014/07/so-called-platform-neutrality-nothing.html )

 

Emerging risks to telcos from "Cuckoo Platforms"

Summary

• Telcos want to be platform players at varying points in their network architecture and service offerings. 
• But successful platforms generally need "anchor tenants" to gain scale.
• The problem comes when anchor-tenants are themselves other 3rd-party platforms.
• There is a risk of platforms-on-platforms acting as "cuckoos", pushing the native owner's eggs out of the nest.
• Telcos face a risk from major cloud platforms overwhelming their MEC edge-compute platforms.
• ... and a risk from major AI-based commerce platforms overwhelming their messaging, voice and IoT platforms.
• Other future platforms also face similar challenges.
• To succeed as platform providers, telecom operators need to have their own anchor-type services, and to have a well-designed approach to combating the risk of parasitic cuckoo platforms.

Background: the Internet overcame its broadband host

The cuckoo bird is infamous for laying its eggs in other birds' nests. The young cuckoos grow much faster than the rightful occupants, forcing the other chicks out - if they haven't already physically knocked the other eggs overboard. (See "brood parasitism", here).

Analogies exist quite widely in technology - a faster-growing "tenant" sometimes pushes out the offspring of the host. Arguably Microsoft's original Windows OS was an early "cuckoo platform" on top of IBM's PC, removing much of IBM's opportunity for selling additional software. 

In many ways, Internet access itself has outgrown its own host: telco-provided connectivity. Originally, fixed broadband (and the first iterations of 3G mobile broadband) were supposed to support a wide variety of telco-supplied services. Various "service delivery platforms" were conceived, including IMS, yet apart from ordinary operator telephony/VoIP and some IPTV, very little emerged as saleable services.

Instead, Internet access - which started using dial-up modems and normal phone lines before ADSL and cable and 3G/4G were deployed - has been the interloping bird which has thrived in the broadband nest instead of telcos' own services. It's interesting to go back and look at the 2000-era projections for walled-garden, non-Internet services.


The need for an anchor tenant

The problem is that everyone wants to be a platform player. And when you're building and scaling a new potential platform, it's really hard to turn down a large and influential "anchor tenant", even if you worry it might ultimately turn out to be a Trojan Horse (apologies for the mixed metaphor). You need the scale, the validation, and the draw for other developers and partners.

This is why the most successful platforms are always the one which have one of their own products as the key user. It reduces the cannibalisation risk. Office is the anchor tenant on Windows. iTunes, iMessage and the camera app are anchors on iOS. Amazon.com is the anchor tenant for AWS.

Unfortunately, the telecoms industry looks like it will have to learn a(nother) tough lesson or two about "cuckoo platforms".


MEC is a tempting nest

The more I look at Multi-Access Edge Computing (MEC), the more I see the risks of a questionable platform strategy. Some people I met at the Small Cells event, in the US a couple of weeks ago, genuinely believe it can allow telcos to become some sort of distributed competitor to Amazon AWS. They see MEC as a general-purpose edge cloud for mainstream app and IoT developers, especially those needing low-latency applications. 

I think this is delusional - firstly because no developer will want to deal with 800 worldwide operators with individual edge-cloud services and pricing, secondly because this issue of latency is overstated & oversimplified (see my recent post, link), and thirdly because a lot of edge-computing tasks will actually be designed to reduce the use of the network and reliance/spend on network operators.

But also, this "MEC as quasi-Amazon" strategy will fail mostly because the edge/distributed version Amazon will be Amazon. The recent announcement by Nokia that it will be implementing AWS Greengrass in its MEC servers is a perfect example (link). I suspect that other MEC operators and vendors will end up acting as "nests" for Azure, IBM Bluemix and various other public cloud providers.

Apologies for the awful pun, but these "cloud-cuckoos" will use the ready-made servers at the telco edge to house their young distributed-computing services, especially for IoT - if the wholesale price is right. They will also build their own sites in other "deeper" network locations (link). 

In other words, telcos' MEC deployments are going to help the cloud providers become even larger. They may get a certain revenue stream from their tenancy, but this will likely be at the cost of further entrenching the major players overall. The prices paid by an Amazon-scale provider for MEC hosting are likely to be far lower than the prices that individual "retail" developers might pay.

(The real opportunity for MEC, in my view, lies in hosting the internal network-centric applications of the operators themselves, probably linked to NFV. Think distributed EPCs, security gateways, CDN nodes and so on. Basically, stuff that lives in the network already, but is more flexible/responsive if located at the edge rather than a big data centre).


End-running Messaging-as-a-Platform (MaaP)

Another example of platform-on-platform cannibalisation is around the concept of "messaging as a platform", MaaP. Notwithstanding WeChat's amazing success in China, my sense is that it's being vastly over-hyped as a potential channel for marketing and customer interaction. 

I just don't see the majority of people in other markets forgoing the web or optimised native apps, and using WhatsApp or iMessage or SnapChat or SMS as the centrepiece of their future purchases or "engagement" (ugh) with companies and A2P functions. But where they do decide to use messaging apps for B2C reasons, the chatbots they interact with will not be MaaP-dedicated or MaaP-exclusive. 

These chatbots will themselves be general "conversational platforms" that work across multiple channels, not just messaging, with voice as well as text, and with a huge AI-based back-end infrastructure and ongoing research/deployment effort. They'll work in messaging apps, browsers, smart speakers, wearables, car and general APIs for embedding in apps and all sorts of other contexts.

Top of the list of conversational platforms are likely to be Google Assistant, Amazon Alexa, Apple Siri, Microsoft Cortana and Facebook M, plus probably other emergent ones from the Internet realm.


MaaP is "just another channel" for broad conversational/commerce platforms

In other words, some messaging apps might theoretically become "platforms", but the anchor tenants will be "wholesale" conversational platforms, not individual brands or developers. In some cases they will again be in-house assistants (iMessage + Siri, or Google Allo + Assistant for instance). In other cases, they may be 3rd-party bot ecosystems - we already see Amazon Alexa integrated into numerous other devices.

Now consider what telcos are doing around MaaP. As well as extending their existing SMS business towards A2P (application-to-person), they have also allowed third-parties like Twilio to absorb much of the added value as cPaaS providers. And when it comes to RCS* which has an explicit MaaP strategy, they have welcomed Google as a key enabler on Android, despite its obvious desire to use it mainly as a free iMessage rival. (*obviously, I'm not a believer in RCS succeeding for many other reasons as well, but let's leave that for this argument).

What the GSMA seems to have also missed is that Google isn't really interested in RCS MaaP per-se - it simply wants as many channels as possible for its Assistant, and its DialogFlow developer toolkit. To be fair, Google announced Assistant, and acquired API.AI (DialogFlow's original source) after it acquired Jibe. It's moved from mobile-first, to AI-first, since September 2015.

The Google conversational interface is not going to be exclusive to RCS, or especially optimised for it. (I asked the DialogFlow keynote speaker about this at last week's AI World conference in Boston, and it was pretty clear that it wasn't exactly top-of-mind. Or even bottom-of-mind). Google's conversational platform will be native in Android, in other messaging apps like Allo, Chrome, Google Home and presumably 1000 other outlets.

From an RCS MaaP perspective, it's a huge cuckoo that will be more important than the Jibe platform. There is no telco "anchor tenant" for RCS-MaaP as far as I can tell - I haven't even seen large deployment of MNOs' own customer-care apps using it. If I was an airline's or a retailer's customer experience manager, and I was looking beyond my own Android & iOS apps for message-based interactions, I wouldn't be looking at creating an RCS chatbot. I'd be creating an Assistant chatbot, plus one for Alexa and maybe Siri.


Can you cuckoo-proof a platform?

Apple, incidentally, has a different strategy. It tends to view its own services as integrated parts of a holistic experience. It tries to make its various platforms cuckoo-proof, especially where it doesn't have an anchor tenant app. This is a major reason for the AppStore policies being so restrictive - it doesn't want apps to be mini-platforms in their own right, especially around transactions. Currently, Google and Amazon are fighting their own mutual anti-cuckoo war over YouTube on Fire TV, and sales of Google Home on Amazon.com (link). Amazon and Apple are also mutually wary.

It's worth noting that telcos are sometimes pretty good at cuckoo-deterrence too. In theory, wholesale mobile networks could have a been a platform for all manner of disruptive interlopers, but in reality, MVNO deals have been carefully chosen to avoid commoditisation. A similar reticence exists around eSIM and remote SIM provisioning - probably wisely, given the various platform-on-platform concepts for network arbitrage that have been suggested.


Conclusions

In my view, both MEC and (irrespective of its many other failings) RCS are susceptible to cuckoo platforms. I also wonder if various telco-run IoT initiatives, and potentially network-slicing will become a platform for other platforms in future too.

One of the key factors here is a "the rush to platformisation". Platforms only succeed when they evolve out of already-successful products, which can become inhouse anchor tenants. Amazon's marketplace platform grew on the back of its own book and other retail sales. AWS success grew on the back of Amazon using its own APIs and cloud-computing.

MEC needs to succeed on the basis of telcos' own use of their edge-computing resources - which don't currently exist in a meaningful way, partly because NFV has been slower than expected. MaaP needs telcos' own messaging services and use-cases to be successful before it should look at external developers. With RCS, that's not going to happen.

Network-slicing needs to have telcos' own slices in place, before pitching to car manufacturers (or Internet players, again). IoT is the same too. Otherwise, expect even more telco eggs to be pushed out of the nest, as they help to foster other birds' offspring.

Communications apps, APIs & integrations: Import vs. Export models

There is a huge and growing interest in blending communications apps/services with other software capabilities. We are moving from a world of standalone voice, video and messaging to a range of contextualised, workstream-based and embedded alternatives.

But there are two very distinct philosophies emerging for app/comms integration:

• Export: this involves extending communications capabilities out from a central system (phone system, UC, messaging app, videoconferencing etc) into other applications or websites via APIs, or by offering granular service-components (eg WebRTC gateway, transcoding, recording etc) via a PaaS approach. Numerous examples exist, from
• Vendors (eg Unify's Circuit APIs, Genband Kandy, Xura Forge, Cisco Tropo, ALU's Rapport APIs, BroadSoft, Vidyo etc)
• Dedicated PaaS providers (eg Twilio, SightCall, Temasys) or niche specialists such as Voxbone (which does numbering for example)  
  
• Telcos' API platforms, which may be network-integrated like AT&T's Developer Platform, standalone PaaS like Telefonica Toxbox, or even just web-embeddable objects like Telenor appear.in
• Import: this involves treating the communications application or service as the user's primary experience, and bringing in other applications as "integrations" or mini-apps. These can be other communications tools (eg WebRTC video windows in a messaging app) or other functions (eg social or process-based integrations). This particularly fits with the "timeline" or "workstream" model, or perhaps a "dashboard". Examples exist in a number of areas:
• Enterprise is moving towards "workstream collaboration and communications" (WCC) apps, such as Slack, Cisco Spark, Unify Circuit and various others which can embed external services into a timeline. BroadSoft's Tempo concept looks more like a dashboard model than a timeline, but also brings in sources like DropBox.
• Consumers are moving towards "Messaging as a Platform" apps, notably in Asia with WeChat, which embeds mini-apps such as taxi-ordering into the message stream. Facebook is taking Messenger in the same direction, and even telcos want to replicate this - Deutsche Telekom is trying to reinvent RCS to take it in that direction, for example.

The API-led "export" model has been the primary trend in WebRTC, SMS and telcos' network/IMS strategies in recent years. We hear a lot about the "consumption" of APIs, "embedding" of communications or the "exposure" of a core system. It is definitely growing rapidly, in numerous guises. Click-to-call buttons embedded in websites or apps are a typical manifestation. (Video below is embedding AT&T capability into Plantronics' website)

But the success of apps such as Slack and WeChat have led to a resurgence of the idea of "unifying" communications, or using a "hub" approach, where a messaging/voice/video app becomes the central anchor of a user's "online life", either as a dedicated application or browser home-page.

Some vendors are trying both approaches - Unify and Cisco seem to be looking at both import and export models. It might be where Google is intending to take Jibe along with telcos and Android as well. Some UCaaS players seem to be taking a similar path (eg with ThinkingPhones acquisition of Fuze) as well as WCC specialists like Atlassian's HipChat.

Others are taking different angles - Microsoft seems to be using Office 365 as the anchor, importing its own Skype4Business UC application as well as maybe others in future, probably via ORTC. I suspect it will "export" more communications as well, in future. Apple (as usual) is different, still using iOS as its main platform for very selective import of a few comms/social tools such as Facebook and Twitter, and largely avoiding any export models at all. (There is no way to embed FaceTime or iMessage in a website, for example). Apple also tends to dislike apps acting as subsidiary platforms on mobile, especially if there are payments involved.

It is too early - and too polarised - to determine whether import or export will be most significant, and for which use-cases and customer segments. We may see different "balances of payments" for different vendors and service providers. However, there are a number of early conclusions to draw:

• Import models need a good and usable / well-liked core product, before they can become a platform
• Export models need the right "raw ingredients", eg simple video or SMS APIs, with the right (typically freemium) commercial model to attract developers
• Import models tend to work best with a core that is text/timeline-based, ie non-realtime
• There is a risk that some import models appear as "arrogant": I can imagine some users thinking "What, you expect me to spend the core of my day in your app?! You must be joking"
• Export models face a lot of competition - external developers have many APIs to choose from, or can implement their own capabilities from scratch.
• Import models involve competition between comms tools and other apps as the "anchor" - eg a UC tool, vs. social networks, or an Office/Google Apps suite as hub, or major enterprise products like SAP/Salesforce, or a vertical-specific platform like a medical practice-management app.
• Import and export approaches often vary in implementation between Android, iOS, Windows and native chipset-level
• Telcos have been trying export models for a long time, with limited success. Often, 3rd party platforms that act as aggregators / or "export agents". Cable / IPTV companies are closer to the import model as they own the set-top box interface to "on-board" other solutions
• We might see NFV / VNF architectures helping with telco-grade import & export in future, but for communications services it's still a long way off
• Mobile app usage tends to be fragmented. With the notable exception of WeChat, it's not clear that a full import model works well with the app paradigm on smartphones. That said, we may see greater cross-linkage between apps in future.
• Certain groups of knowledge-workers may be more well-suited to "import" comms apps, especially if they are either communications-primary users (eg call centre agents) or heavily-collaborating teams.
• Design skills are paramount throughout, for integrations to be usable. 
• We will see some "importers" acquiring companies to extend the core app functions. Slack/Screenhero is a good example. This may compete with some 3rd-parties' integrations, but may also make life easier for iOS appstore approvals.
• Both import and export models make life much harder for network policy-management (or industry regulation) as mashups are by their nature hard to pigeon-hole. 
• Every export implicitly also means an import from the other side - sometimes into "product", but in many ways horizontal apps such as SAP and Saleforce are turning into full import platforms in their own right, especially where they support multiple communications integrations.

I think that 2016 is going to see some epic battles between import and export philosophies for communications in general, and WebRTC in particular. The shift of communications to the cloud facilitates both directions. Worth watching very closely indeed.

Stop Press: just as I was about to publish, I read that Facebook is trialling Uber-in-Messenger, as part of its "Transportation on Messenger" initiative. This is a great example of an import model, and "messaging as a platform". Details are here.

The Internet is now attacking those that try to damage it, not just avoiding them

It used to be said that "The Net interprets censorship as damage and routes around it" - a quote by John Gilmore, in 1993.

In my view, the Internet community is now maturing to a state where it is going on the offensive rather than just taking defensive avoidance strategies. 

When it is threatened, rather than just looking for ways to mitigate or "route around" potential damage, it is now going after the source of that damage (& its promoters). It is going beyond mere nullification to actually escalating the battle - either codifying methods pre-empting further problems from the same source, or actually attacking that group more broadly.

A prime example has been the rise of ad-blocking. Most Internet users are OK with the general principle of passive, neutral, non-invasive advertising. It's a bit annoying, but no more so than ads in public spaces like poster hoardings. But what gets resented is where those ads are privacy-invasive (eg with tracking), hugely interruptive (pop-ups) or consume a lot of resources (eg auto-playing video).

As a result, the Internet has given birth to a variety of tools which don't just block the annoyances, but take out the basic, more-acceptable formats too, as collateral damage. The Internet ad industry has over-reached the boundaries towards a form of pseudo-censorship (or at least, "mucking around with content" in undesirable ways), and found its fundamentals under attack. The idea that telcos will charge advertisers for traffic, on threat of blocking, is another example of something that will backfire even more strongly, as I wrote recently.

Another area is telcos'/ISPs' attempts to "monetise" Internet connections, or "optimise" traffic, in wholly self-serving fashion. The use of DPI for filtering, advert insertion with HTTP man-in-the-middle proxies, and various other unwanted forms of interference, has led to the wholly-predictable rise of encryption everywhere. We see HTTP2 with Google's SPDY baked-in, wider use of VPNs and so forth. The irony here is that this also has collateral damage, preventing some forms of actually-useful forms of network management. Again, strategic over-reach has resulted in the Internet not just defending its basic utility against a form of censorship, but escalating the battle.

What prompted this post was reading a new IETF Draft (see here) which explicitly "mandates end-users as the highest priority constituency for Internet standards". The needs of users (who generally aren't well-represented / advocated in standards) are now being absolutely prioritised above ISPs, vendors, developers, "implementors", governments and so forth. Theoretical considerations of technical "purity" or "elegance" come right at the bottom of the list.

It means that new IETF standards ought to check - and explicitly state - that user welfare is not harmed at the expense of other groups' gain. It's a bid to stop some of the back-room chicanery that goes on inside a lot of standards development (many groups are a lot worse than IETF - I'm sure readers will be able to identify the real culprits here). Small technical details are sometimes deliberately made to capture value on behalf of other constituencies, to the detriment of users (or rival groups). 

This forces the principle of "design thinking" onto the normal engineering-led (and perhaps commercially-influenced) process.

This move appears to have been catalysed, in part, by the ham-fisted opposition to HTTP2/SPDY by the ironically-named "Open Web Alliance" set up by various (mostly US) telcos and vendors as part of ATIS. This group came up with the risible notion of "trusted proxies" which did not just allow useful traffic-management, but started with the premise of allowing ISPs free rein to break encrypted streams for a variety of use-cases, including ad-insertion, big-data collection, application discrimination and various other questionable practices.

In other words, the Internet is not just neutralising a specific example of "damage", but it's trying to ensure that those that attempted to damage it are de-fanged for the future as well. 

The US battle against Net Neutrality was another instance. An attack by the ISP/telco industry on a relatively straightforward legal rule ended up with a much larger fight-back: culminating in the FCC implementing Title II for broadband, with help along the way from the likes of John Oliver and a major grass-roots campaign. What could have been a minor defeat turned into a major strategic rout, because of push-back to the way the US regulatory and lobbying system works. Whether it has learned its lesson is yet to be seen.

Various repressive regimes have also learned to their cost that attempting to harm the Internet can result in disproportionate retribution from it in response.

Over-doing the use-cases for zero-rating has also attracted the Internet community's ire, meaning that valid use-cases may suffer along with questionable ones, as some regulators ban the concept entirely.

Then there's the spies. Bodies like the NSA & GCHQ have had to deal with far more, and stronger, crypto, because recalcitrant vendors, whose reputations and exports have been hurt by intercepted data or underhand hacks, responded to users' demands uncompromisingly. The intelligence agencies - who have a difficult and thankless task - committed the cardinal sin of over-reach, and then had to deal with the consequences.

It seems likely that some of the push for LTE-U (4G in the same spectrum as WiFi) may go the same way. By angling for a version called LAA which needs licenced spectrum as a pre-requisite, the industry may well find itself unable to use LTE-U at all once the regulator gets involved. Plus it might even get worse - by suggesting WiFi and LTE can "play nicely" together (with coexistence protocols) in unlicenced bands, perhaps we'll get escalation. Surely this means private WiFi could run in today's licenced bands as well, as the evidence shows it could be implemented in ways that wouldn't interfere? That could hypothetically aid overall efficiency of spectrum utilisation, whilst not damaging the value of carriers' own spectrum.... 

The strategy of arguing "Who, me? Innocent little me? My intentions are good, honest!", with fingers crossed behind ones back, is no longer a viable one.

It could be argued that with these new powers, the Internet is in danger of becoming more than just petulant, but risks sometimes throwing the baby out with the bathwater. That seems to be the case with some of the genuine security risks that might emerge as an unintended consequence of crypto. It's possible that the Internet will need to control its own power better, a bit like the Incredible Hulk. 

But for now, until it gets that self-control, the lawyers and lobbysists, telcos and ISPs, advertisers and snoops all need to imagine the Internet saying "You wouldn't like me when I'm angry" before pushing their luck too far. If you "try it on" with the Internet, prepare for a bigger slap than you expected. So for example, all this nonsense about "level playing fields" (see here), erecting toll-gates (here), or sly attempts to influence lawmakers about spurious notions of "platform neutrality" (here) will make the Internet bite back. Hard.

Will more network/IT vendors launch their own WebRTC PaaS?

One of the most vibrant domains within WebRTC is that of "platform as a service", PaaS. There are numerous providers of cloud infrastructure, mobile SDKs and ancillary services that allow developers to embed WebRTC functions more easily than using "raw" JavaScript. Tokbox, Temasys, Twilio, acquired players AddLive and Requestec, telcos like AT&T and NTT and so on. 

There is a particular need for PaaS to support mobile devices which use WebRTC in apps rather than browsers (eg with iOS SDKs), or where specialised cloud functions are needed, such as video-mixing. They also appeal to developers unable to cope with complex or clunky aspects of WebRTC, such as the much-derided SDP protocol for connection setup.

But one emerging category I'm seeing is slightly different - it's where technology vendors are launching their own PaaS propositions, reaching out directly to developers with hosted platforms, rather than attempting to sell gateways or SBCs or media servers as products.

The most prominent examples are:

• GenBand's Kandy platform
• Acision's Forge SDK & PaaS [itself based on the acquired Crocodile platform]
• Intel's investment into CafeX
• Digium's Respoke
• (Primarily a virtualised IMS PaaS, Metaswitch Clearwater also offers some cloud-based WebRTC gateway capabilities)

What differentiates these from the various other client SDKs is that they are moves by "product" companies into the "service" arena, with subscription or pay-per-use business models. That runs counter to the normal vendor model of upfront product license + maintenance/support contract.

Now clearly, in other parts of the technology industry that transition is fairly common - the large network vendors like Ericsson, Huawei and ALU all make large sums from "managed services" contracts for radio networks or other bits of telco infrastructure. Cisco owns WebEx for conference services, while many mainstream software companies have transitioned to SaaS/PaaS offers for business users.

Yet it is one thing selling a "cloud" or outsourced version of a product to your existing customers (telcos or enterprises) as a service - but quite another trying to derive revenues from an entirely new audience of web or application developers. Clearly, this in an attractive idea - but it doesn't mean that it's easy to achieve in reality.

In WebRTC, it is instructive to consider which vendors are not offering PaaS propositions to developers - it includes most of the main gateway or media-server providers. While Oracle, Ericsson, Sonus, Dialogic, HP, Broadsoft, ALU et al might offer client-side SDKs, they are not offering hosted, subscription-based platforms for WebRTC developers at present. (Notably, all the previous product/service crossover vendors above also sell gateways or provide SDKs on a "product" basis, too).

My belief is that the others do not, for the most part, want to take the upfront risks of setting up infrastructures and billing systems for PaaS (especially internationally), nor incur the marketing overhead of reaching the "long tail" of developers. Not only is there a lot of competition here (with services firms having existing customers, or specialised capabilities), but there would be a risk of channel conflict if (for example) they ended up competing vs. firms that themselves are launching PaaS services, but which are also customers for core-network infrastructure or SBCs. 

For telco-facing vendors, I don't expect to see too many more launching WebRTC-based PaaS platforms, unless either (a) it ties into a much bigger NFV/SDN strategy offering telco infrastructure on a managed-service basis, or (b) it's a completely separate, rebranded initiative like Kandy, primarily targeting enterprise software ISVs. Broadsoft's Labs arm is offering an "incubation environment" for developers, but it's not the same as a full PaaS.

On the enterprise side, I can see Cisco, Avaya, Unify and others increasingly offering API access to their own cloud-based UCaaS offers. However, I'm not expecting them to offer subscription-based WebRTC gateway functionality or similar propositions aligned with Respoke. Notably, Voxeo split off its PaaS business (Tropo, formerly Voxeo Labs), before being acquired by Aspect. The deal that Avaya has done with Google for hosted contact centres & Chromebooks is a step in this direction, but isn't really a formal PaaS. It also has a platform called the "Collaboratory" which seems similar in principle to Broadsoft Labs - ie a "PaaS for prototypes" rather than a "production PaaS".

All that said, there may be some future acquisition opportunities and disruptions here over time. I could perhaps believe a major vendor might try its luck acquiring Twilio or Temasys or CafeX or another cloud player, perhaps seeing it as a way to start generating more recurring revenues, and higher-margin services. However, such actions are perhaps more likely to come from the IT side of the industry (IBM? Microsoft? Google?) than network vendors.

For now, I think the vendor/PaaS crossover phenomenon is a relatively rare one - I suspect many others will just watch from the sidelines to assess whether any of the existing batch start getting notable traction and growth, or else they might go down the route of offering selected partners a "prototyping environment" rather than a full pay-by-credit-card cloud offer.

Evangelising WebRTC: Conferences, Hackathons and more

Last week I was asked to help judge a WebRTC hackathon run by Acision, for apps based on its Forge cloud platform. (It was called Forgeathon, and run by a company called BeMyApp. Apparently, I am now a "Celebrity Guest Judge", which I shall be adding to my business cards and LinkedIn profile in due course).

It was won by an app called "Yoroshiku" which was a fun concept of Tinder-style "swiping", but to find language-exchange partners rather than dates, find out if they're online, message them, and then set up a video-call inside the app, speaking Japanese or Welsh or Klingon to each other as appropriate. It is a great example of contextual communications - voice/video which is both inside a given context (app/website) and which is given extra function and meaning by that context (eg language-matching). 

Yoroshiku is precisely the sort of use-case that WebRTC is designed for - and the fact here it's bundled into an iOS app, rather than a browser, also points to the role of cloud-based APIs and the growing importance of mobile use-cases. I also liked the 2nd-placed entry Codemate which was aimed at collaborative coding between developers, and the 3rd-place one, Trippr, about recommending travel destinations. All interesting examples of what's possible - and written in 6 weeks by individuals or small teams.

I'll be writing a lot more about contextual communications in coming posts, but there's an important caveat about its evolution: most developers spending their lives in a given "context"- language tuition, human resources, travel agency, games, photography, real-estate or whatever - don't know much about communications. Especially if they're solo app developers, they will never have heard of SIP, video codecs, NAT-traversal, latency/jitter, echo cancellation or any of those other things that comms people talk about every day.

Not only that, but many of them haven't even thought of the possibilities of using contextual communications, just as many haven't thought about other new APIs or technologies. If you're developing something for language students - or lawyers or oilfield engineers - you don't necessarily have a checklist of "cool stuff that might help" - whether that's realtime voice/video, or other HTML5 APIs for 3D Graphics or whatever (did you know there was a W3C Vibration API? No, me neither). Then there's a ton of non-web stuff clamouring for attention  wearables, drones, 3D printing and so on.

Basically, there's a never-ending list of cool stuff (and APIs) for developers to exploit to add coolness and functionality to their apps and websites.

So WebRTC has to cut through all the other worthy possible additions and get to the top of the developers' priority list of things to implement. The simplest cases will be those where they already know they want to add realtime comms, and they go looking for the best/easiest way to do it. But in others, it's an "unknown unknown" - they don't even recognise the possibilities from using voice or video, and haven't heard of WebRTC - it's not even on their radar.

This is where evangelism comes in. I'm seeing a steady increase in outreach by the WebRTC industry to new constituencies - especially general web and app developers, and those focused on particular industry sectors. Hackathons are good examples, as are the various Meetups (including the one in Barcelona next week), and presentations at general web conferences and vertical-industry events. But more is needed, to raise awareness and understanding.

The problem is that most such developers won't be buying WebRTC infrastructure - gateways, SBCs and the like. They will mostly be using open-source components, or cloud PaaS offers like Forge (or Tokbox, Kandy, Respoke, Twilio, Temasys, SightCall, AT&T, appear.in and a long list of others). And those players - apart from an obvious few - don't have much marketing clout.

There are many more WebRTC marketing dollars aimed at people "adding web to their existing comms" than there are for those "adding comms to their existing web". There's also a wariness among some vendors about over-promoting the PaaS platform concept, as it may reduce their addressable market for direct sales to individual customers - not least because some of those providers "roll their own" components rather than use off-the-shelf gateways or SBCs or media-servers.

What I'd like to see - as well as more direct initiatives like Acision's here - is the formation of some sort of coordinated WebRTC Forum body, which exists to promote the technology to a wider audience of developers, rather than define standards internally. Such a forum could host demos & showcases, run competitions, write white papers, field speakers or workshops at events, align web resources (maybe even based on WebRTC...) and so on. There's plenty of these types of things for other bits of the Internet and communication industry, but nothing specific to WebRTC. (One exception may be Google's own efforts on its G+ forum, run by the Chrome team).

I'll be at the Barcelona Meetup next week, and also Enterprise Connect in Orlando. I'd be keen to have some discussions about how a WebRTC Forum might get started, funded, sign up members and so on. I'm probably not the right person to coordinate at, but I'm happy to help work to bring together interested parties.

In the meantime, I'll be keeping an eye on other WebRTC hackathons and events, and see if any examples of best practice jump out, as well as interesting case-studies and usage ideas. And if you're looking for a judge, advisor, analyst or event facilitator, please get in touch. Ideally, not in Hungarian, as I swiped left on that.

The myth of "Telcos winning back revenue from OTT players"

In the run-up to MWC, I'm seeing a spate of news articles in the telco press/blogosphere, or vendor press releases, which are titled something like: 

"How Telcos can Win Back Revenue From OTT Providers"

These are almost all uniformly wrong or at least, misleading marketing hype or clickbait.

Let's parse that sentence "win back revenue from OTT providers". I'll tackle the continued use of "OTT" later in the post - but it's a legacy term that has no place in the telecom industry going forward.

But first, whatever you name them, so-called OTT providers generally do not take revenue from telcos. They take customers or usage, by offering either cheap/free or better services - often both. People use Whatsapp or SnapChat as a free, more-functional and cooler upgrade to SMS. They use Skype as an improved user-experience to telephony, and we're seeing switching to myriad new voice/video apps and WebRTC-powered services (my report here), for contextual comms. Internet app providers often derive value in other ways (ecosystem, advertisers, stickers, recording, cloud services etc) by giving away message or voice transport for free. There is no - or very little - revenue to "win back".

Telephony and SMS are not going to disappear entirely, but they are old and clunky lowest-common denominator services in a world of unlimited choice, and best-of-breed applications targeting individual use-cases and preferences. "Winning back revenue" requires there to be revenue to win, and renewed consumer appeal competing against alternatives to a sufficient degree somehow to encourage payment.

Person-to-person SMS has historically been a rip-off. It's never been "value-based pricing", it's been grudge- or resentment-based pricing. We used to hear people say it allowed $10000/MB - and that's the problem. It was orders of magnitude too expensive for a service that never evolved over a 20-year period. Sending 160 characters from A to B was cool in 1995. It's not rocket science in 2015. Similarly, telephony transport is priced expensively compared to costs and value (for most uses) too. That said, VoLTE puts the implementation & production costs back up, in the unproven hope of future gains from spectrum re-farming.

The  telecom industry used to make over $100bn a year from SMS. It still makes a decent fraction of that, although the exact amount depends much on accounting and bundle-allocation chicanery. Excess SMS profits of close to a $trillion over the last decade or two seem probable - with minimal service innovation from reinvested cashflow. To put that in context, it's probably larger than all banking bonuses worldwide over the same period.

That $100bn+ revenue is not coming back from simply sending mobile messages. It might partly come back from adding value to other ecosystems, or enabling particular purposes through A2P messaging integrated into business processes, but in terms of straightforward A-to-B transmission of text or pictures, it's gone. An SMS is not much more valuable, inherently, than an email, and will converge with email in terms of pricing. 

In any case, increasing A2P revenues is not "winning back" revenues lost from P2P. It's completely distinct, and isn't occurring at the expense of Internet-based alternatives.

(Obviously, RCS just worsens the situation, by consuming extra costs & staff resources, for zero extra usage, zero extra revenue, a major opportunity-cost impact, and possible brand damage. It is worse than useless and needs the industry to capitulate entirely. I believe RCS needs to die with an obvious bang, not a whimper, for everyone to "accept & move on").

Similarly, the decline in mobile telephony revenues isn't going to be slowed much by VoLTE, and certainly not reversed. It's just telephony v1.1, and although HD voice and fast call-setup are nice, they don't provide an obvious basis for billions in new revenue. VoLTE (and WiFi calling as well) are moderate feature upgrades - they don't change the value proposition of telephony, or the use-cases to which it can be applied. They will not "win back" revenue that has shifted from "vanilla phone calls" to other modes of communication.

Enterprise services are slightly more complex - but there the "OTT" services are essentially just IP-PBX or UC platforms from major vendors, or else they are 3rd-party cloud services for conferencing, contact centres and so on. Those have been in place for years, and while telco-hosted UC or SIP-trunking have important roles, few in the industry would suggest they are seriously "winning back" revenues from WebEx or Microsoft Lync.

We can also forget about the silly ideas that some suggest, about arbitrarily charging/taxing the Whatsapps and Skypes of this world - as for example Dutch, Indian and Singaporean operators have tried to propose in the past, before getting intense public and regulatory push-back.

Firstly, most Internet app providers and developers don't have the ability to pay 10's or 100's of billions of dollars. Secondly, unless compelled by telco-lobbied (bribed?) regulators, they have no reason to do so. They don't need interconnect, nor QoS, nor sponsored data. They simply need half-decent Internet access, to offer applications that consumers deem to be valuable. Thirdly, there are no obvious mechanisms for this - especially for peer-to-peer communications, or new formats. In many cases, interconnect doesn't make sense, as there is no feature-parity with humdrum "standard" services like SMS and telephony. There is no pot of money in saying "we're dumb, so please tax the clever people" - if telcos want to make money from selling Internet access, they need to balance it against the likelihood that users will shift some of their communications away from monopoly, legacy, unappealing services.

If operators want to "regain revenue from Internet players" there is only one way to do it: innovate at a service/application level, either internally or with specialist external help, and compete. Probably, that innovation will itself require the open Internet, the web, mobile apps - or perhaps, proprietary communications platforms for certain uses. 

It will need a combination of both service development (for direct monetisation) and platform innovation (to attract developers). Both require a culture of risk-taking, software development, innovation management, partnership, and a willingness to "act first, standardise later, if ever". It's possible that VoLTE, or network-based telecom app & API platforms, or A2P SMS might form a role, but they still need multiple layers of genuine novel service elements that add value and differentiation. 

Telcos need to solve specific user or business problems. There are no new generic, standardised services that will pass muster on a standalone basis. (No, ViLTE video-calling won't make a difference).

And yes, some vendor solutions might help here. Telecom application-development platforms, new billing and OSS systems, gateways and WebRTC systems (my report here) of various types, SDPs and their evolutionary descendants, virtualised NFV components that are flexible and scalable and so on. 

And potentially, all of these allow operators to create new services - as discussed in yesterday's post on NFV and SDN. But those will be incremental revenues - not somehow displaced from Facebook or Google, unless they specifically address the online advertising sector. The telecom & Internet business is not a zero-sum game. Revenues for plain-vanilla standalone phone calls and SMS are declining. Other things will rise, but the idea that telcos will "win back" revenues that have evaporated from services nearing obsolescence is a flawed and false narrative.

Not only that, but most operators are hoping to offer API-based capabilities to Internet firms, and act as developer platforms. And a golden rule of such business models is that the platform owner has to help the developers make more money even if they then take a cut. If telcos want to make money from Facebook, WeChat, Skype, they will need to help them earn yet higher revenues. They will have to employ developer-relations or partner management staff whose job will be increasing Viber's and YouTube's and Netflix' and SnapChat's scale and value.

So a more reasonable slogan might be "Telcos can win a share of OTT's future accelerated growth". They won't "win back" revenue unless they compete head-on and win.

Back to the terminology: as a general guideline, anyone who uses the term "OTT" is in the wrong job, especially if talking about voice/video/messaging. It betrays an antiquated sense of "entitlement" and "network privilege"- and a lack of understanding of the Internet and software development. (People in the IPTV/online video sector tend to use OTT in a different way that is less belligerent and confrontational).  All telcos have so-called "OTT" activities - none could even exist without their telco.com website on the Internet, for sales, customer service and even investor relations. To say otherwise is hypocrisy and ignorance.

Internet app providers are just peers and equals to telcos, at an application level. To "win back" revenues, telcos need to compete with them, not just mildly refresh ancient services or transfer them to virtualised infrastructure.

Note: Dean Bubley is a telecoms industry analyst & strategy consultant, working with many of the world's leading operators, vendors, regulators & innovative startups. Please get in touch if you would like to discuss advisory work, internal workshops or public speaking engagements. (Also see WebRTC report here & Mobile Broadband report here)