Telecom vendors should not couple WebRTC too closely to their IMS strategy

A regular theme at WebRTC conferences, especially in the telco/service provider tracks, is "To IMS or not to IMS". There's usually a quick discussion of 3GPP standards progress, a presentation from a vendor or two, and an operator core-networks specialist talking about a trial they've run in a lab. There might also be an API management company, trying to pitch their tools as a way to expose IMS-anchored capabilities to developers.

All of which is fair enough. I expect that some of the telco use-cases for WebRTC will (eventually) involve IMS in some regards. An obvious one is extending VoLTE to non-LTE devices, as a form of "web-phone" rather than the dedicated softphone applications of the past. We might also see some variants on hosted PBXs, the long-mythical telco video-calling services, or some pointless RCS APIs that none of the roughly 17 active Joyn subscribers will ever use.

But my normal advice to operators - whether on conference panels, during private workshops or in my published research - is to diversify WebRTC across multiple units and teams. While the core networks/telephony team battles to add it to IMS, the enterprise unit should be looking at it in a completely separate way, as should the digital/OTT team, the IPTV arm, the developer-platforms initiative, the M2M unit, the internal CRM project, vertical-specific partnerships, wholesale, arms-length MVNOs and all the various local OpCos.

In other words, IMS-related work should only make up maybe 20-30% of a typical operator's overall WebRTC investment, focus and resources. It's a part of the story, but a slow-moving and mostly unsexy part. It might be generating a few extra features, but nothing to move the needle. The usual mantra among the IMS/WebRTC contingent is "it's just another access", which pretty much defines the limits of their vision and ambition straight away.

But there's another dimension here, on the supplier side. Certain vendors only ever reference WebRTC in the context of their IMS solutions and products. Again, it's "just another access", with a fairly unsubtle corollary message of "it's just another function of our IMS, so please buy it".

I'll call out Huawei in particular here. I don't think I've seen anything about WebRTC from the big Chinese vendor that didn't have a IMS slant - even its otherwise cool M2M Telemedicine demo, which inexplicably tries to kludge in an RCS angle. This may be reflective of the Chinese market as a whole - despite heavy presence of companies in the standards bodies, I'm not aware of many actual consumer-web or enterprise-centric WebRTC deployments and apps coming from China.

Alcatel-Lucent is almost as polarised, although sometimes with a veneer of API glue between the two. It even has a white paper distinguishing IMS-based options from "islands", which is set up on a straw-man premise asking whether WebRTC could ever replace the PSTN and demanding that "action must be taken to incorporate IMS with WebRTC immediately". The paper has all sorts of extremely-questionable assertions, including "People must be universally reachable though voice, video [!] & messaging". Written by George Orwell's great nephew, I assume, and possibly worthy of a full dissection in another post. (Full unintentional-irony marks to ALU for the download web-form asking for Twitter handle rather than phone number, though). 

Mavenir seems to be solidly planted at the IMS-only end of the WebRTC spectrum too, although that is unsurprising given its focus as a company. NSN is pretty much "missing in action" with regard to WebRTC, but the only recent mention on its website is in a reference to an IMS session controller.


(Semantic sidenote: at the moment, IMS is merely an archipelago of small islands connected by wooden canoes, compared to the Australias & Greenlands of Internet apps)

Conversely, while Ericsson is obviously an IMS believer, it seems willing to go off-message on WebRTC - here's a prototype it's been playing with on Google Glass, complete with Node.JS for signalling. Cisco has a big enterprise presence, so it's no surprise to see it being at least as enthusiastic about WebRTC in an UC and conferencing context as it is in the telco domain. 

GenBand, Oracle, Sonus and Dialogic are also fairly agnostic, looking at both IMS and non-IMS use cases (and varying their messages depending on the audience and event concerned). Metaswitch targets both IMS and non-IMS service providers with its WebRTC gateway capability, as well as integrating into its open-source NFV-IMS Clearwater platform. Acision seems to be looking at both telco and enterprise domains with WebRTC, and while some of the messaging angles derive from its SMS heritage with a faint whiff of RCS, it's all quite well-buried under a cloak of "interoperability where wanted".

I'll do a deeper analysis of this (plus various other vendors) in an upcoming update of my WebRTC report, but it's really jumped out at me in the last few weeks.


The key point here is that vendors - even if they are IMS "true believers" need to follow in the footsteps of the telcos. WebRTC activity and product development MUST NOT be "just another bit of the IMS product", but must be democratised across the entire organisation and its affiliates. All the vendors have big integration, support and professional services teams - these should be using WebRTC as part of their internal and client communications. The OSS/BSS functions should pragmatically employ it. 

The R&D teams should be using video and screen-sharing. Vendors' new product teams should be looking at opportunities around cloud platforms & API management tools for telcos that wish to emulate Telefonica Tokbox. They should be thinking about re-entering the enterprise market, even if they sold off their old PBX businesses. Interactive TV systems, set-top boxes, M2M infrastructure and vertical/government solutions should embrace WebRTC where relevant. None of these should be beholden to IMS integration as a core strategy, even if it intersects at relevant points.

Maybe a higher fraction of WebRTC efforts - say 30-40% of total investment & resources - should be based around IMS integration for some vendors. But it is exceptionally risky to put all WebRTC eggs in a fragile, slow and unambitious WebRTC basket.

Ultimately, IMS needs WebRTC more than WebRTC needs IMS, both for service providers and the web at large. If vendors like ALU & Huawei continue to deliberately ignore (or worse, denigrate) non-IMS use cases for WebRTC, they are disenfranchising themselves from a huge chunk of the future communications industry.

So-called "Platform Neutrality": nothing to do with Net Neutrality, and a minefield of unintended consequences

One of the things I've noticed cropping up over the last year has been the concept of "platform neutrality". It's a line of argument used by telecom lobbyists and executives to shed light on perceived unfairness stemming from Apple and Google's control of their respective ecosystems (and, to a degree, Microsoft and Amazon and others).

It seems innocuous at first - I've seen it defined as "consumers should be free to procure and use legal apps and contents on any platform from any source".

In other words, the telecoms industry doesn't like the control that Apple has over its AppStore and iTunes and similar platforms, nor Google over the Play Store and other properties. Some of this is fairly reasonable - Apple has some rather arcane, non-transparent and inconsistent policies about apps it allows in its store, while Google could be accused of manipulating its search results in ways to maximise revenues. There are also persistent rumours that only favoured developers get access to "private APIs" as well.

It's not obvious to me, however, that such practices warrant either huge regulatory intervention, nor conflation with the more prominent concerns about Net Neutrality. There might be some unfairness - perhaps even questions over competition - but they are both entirely separate from, and of a different magnitude to, various network practices that telcos have been lobbying for. Apart from anything else, all iOS and Android devices have open access to the web, which many market participants keep claiming to be the equal (or at least equivalent) of native apps.

I would certainly concur that extra transparency from Apple and Google about their app policies would be beneficial, as well as some guarantee of consistency and right-of-redress. Lack of portability of apps, music and other material could also be an angle where competition authorities might probe. 

Yet I find it deeply hypocritical that telcos are trying to position themselves as champions here, as they don't really have a particular axe to grind and many practice egregious examples of application lock-in themselves. I'm also not aware of any operator apps that have been blocked from appstores, although some may still be smarting from their own failed attempts at launching stores and application platforms like the ill-fated WAC.

But there are deeper problems here, if you start thinking about the possible legislation of "platform neutrality". Given that increasingly "everything is software", any such rules would have very widespread ramifications - as well as all manner of ironic unintended consequences which could harm telcos even more than the device/Internet giants.

So while the intention might just be to allow customers to buy digital music from any online store to install on an iPhone, rather than just iTunes, extending that to a general rule would also imply:

• Forcing telcos to ensure that other telcos (or Internet companies') telephony and messaging systems were available as alternatives to their in-house "primary voice" offers. In other words, users should be able to select Orange or AT&T or Skype as primary telephony providers on a Vodafone or Telefonica-provided handset.
• Force telcos to allow users to replace connection-management software with any similar apps of choice. This would wipe out any future attempt to force devices to specific WiFi networks, for example.
• If consumers are able to procure any content or app, they should also be able to remove or delete any app. This would work out badly for operators selling customised handsets, pre-loaded with their own apps or extra features. It could also mean that re-flashing an operator handset with legal (but vanilla) OS variants would also be expressly permitted in law, without sanction from the operator.
• Forcing network vendors to allow 3rd party software to run on routers or switches - or their future SDN/NFV platforms. So Cisco might be forced to release APIs for Huawei & Ericsson Oracle to use, and vice-versa
• Forcing providers of set-top boxes for cable/IPTV to allow Netflix, Hulu, Amazon and Apple software to be installed onto their platforms
• Forcing cloud SaaS providers to accept rivals' applications on their platforms - maybe hosted Office 365 on Google, or Microsoft CRM on Oracle's cloud, or Twilio on Verizon's cloud.
• Forcing games console providers to deny exclusive deals, or special versions that cannot play on rival systems
• Forcing car manufacturers to accept each others apps on in-vehicle systems - say, a Ford-branded navigation app in a BMW, or Mercedes engine-management software in a Jaguar.
• Forcing TV manufacturers to allow users to install ad-blocking software.

I'm sure there are many other awkward cases where "allowing any legal software to be procured" could back-fire with fairly catastrophic effects on the operator.

And all this is before you get to issues around exactly how all this gets enforced, especially with platforms that are part-cloud, part-OS, part-Web and part-silicon/firmware. There's also all sorts of bear-traps about how all this actually manifests in APIs, what happens when "porting" stuff to new platforms incurs extra IPR costs (eg because on platform has licenced a patented technology, but another hasn't) and innumerable others.

In short, a lot of this is just usual telco whining about Apple and Google being smarter and faster than 3GPP and GSMA. And, as usual, the lack of understanding of the nature of software risks huge unintended consequences - especially around the forced "neutrality" of telcos' own platforms.

There possibly is a case to be made for application or content portability between different devices and OS's, to reduce switching costs from one platform to another and reduce lock-in risks to consumers. And I do agree that AppStore policies should be more transparent and enforced consistently.


But notably, none of this is something that consumer groups get especially riled about, especially to the same degree as Net Neutrality. Linking the two areas is mendacious and irrelevant. And above all, the "principles" of so-called Platform Neutrality exhibit seriously woolly thinking and a complete misunderstanding of the roles of software platforms. Some measure of lock-in or platform control is often desirable - including for the telecoms industry at itself. 

The main similarity between supporting Platform Neutrality and opposing Net Neutrality is that both have the potential to have huge and damaging unintended consequences for the telecoms industry. Be careful what you wish for.

WebRTC applications: are we expecting too much radical innovation, too soon?

One of the recurring themes at WebRTC conferences and demo sessions is a slight air of crestfallen anticipation, when those of us who are "old hands" are shown YAVA - "Yet Another Video-chat Application" or YACC - "Yet Another Contact Centre".

I've been watching WebRTC evolve for over 3 years now, and I'm really looking forward to the "new stuff" which is going to replace the old paradigms of the "phone call" or the "videoconference". I love seeing things that are genuinely new, such as some of the emerging ideas for data sharing between browsers - WebRTC CDNs, or privacy-protectinng web searches.

But those are the exceptions. Back in the real commercial world, I keep getting shown YAVAs & YACCs rather than all the cool new toys. I want to see facial-expression reading video analysis, which automatically draws a smiley face on my caller if they're sad. I want to see my own face used as an avatar in social media, with data-channel sharing of sensor information to show if I'm warm or just embarrassed. I want infra-red CCTV of cute squirrels in Regents Park & to be able to confuse them by feeding them 3D holographic peanuts*. I want a WebRTC drone, dammit, even if I can't use it legally & don't have any applications for it!

Yes, there are some cool things starting to emerge - but most of these are applications or twists on existing ideas. Video-chat in healthcare. Video-chat for online consultations & training sessions. Video-chat in contact centres, including one-way video for Amazon Mayday. Video-chat with co-browsing of a website. Video-chat with Instagram-style filters. Video-chat with web cookies and speech analytics.

So yes, they're all video-chat. But in useful forms, often where no use of video existed before, or which required separate Skype or Hangouts sessions with minimal integration. This is all a good set of developments, yet we're too easily bored by it.

Part of the issue here is that the broader mass of web/app/enterprise developers aren't really sure how to think about communications yet. In particular, they are unlikely to both think about a new feature (embedded video/voice) AND ALSO think about using it in new ways. Ask most people about forms of communication, and you'll just hear "phone calls" or "Skype" or "Whatsapp" or "email".

I have enough trouble educating the telecoms industry that there's more to communications than a "call". The idea that the broader developer universe (focused on solving other business problems) is going to leapfrog 120 years of learned behaviour and go straight to free-form, unproven ways of setting up realtime interactions is a tall order. Especially as they also have to think about getting the WebRTC machinery working. Very few are going to go straight from uncommunicative websites/apps, to entirely new concepts with push-to-talk video or media-processed & auto-initiated audio streams with inbuilt lie-detection & realtime translation.

I think we're in danger of setting unreasonable expectations for WebRTC. All of us jaded old communications veterans, who've "been there, done that" with assorted flavours of videoconferencing, might just overlook how much value there is in many more useful and cheap forms of videoconferencing that have been tuned specifically for doctors or TV broadcasters or insurance loss-assessors.

I guess that original inventors of, or commentators on, petrol and diesel internal combustion engines must have got a bit bored by the year 1890. "Oh. It's yet another car. Only with 4 wheels this time. Whoopee". 

But then eventually the Wright Brothers showed up (and the tank-builders of WW1) and things moved on. Yet mundane petrol-powered cars were what led to Henry Ford and the dynamics of the 20th Century.

Remember, there's only a handful of easily-conceived interaction models and variables here. Forward-facing or rear-facing camera. One way or two way. One person initiates, the other accepts, two people "meet" consensually, or something random. What-you-see-is-what-you-get, or media-processed in some way. Audio, video, a mix of both. A conversation with one or both people speaking, or images/sounds of other objects or hybrids. 

You get the picture - most folk will tend to revert to the most obvious models such as two talking heads, at least initially. And there's plenty of value to be found in extending that model.

It's up to all of us to try to catalyse truly "new stuff" - either by dreaming about it and making it happen, or by highlighting cool stuff when it does appear. But let's not denigrate the bread-and-butter, especially if someone has realised it's actually a bit better as a sandwich, or as toast with Marmite on it. So YACC away, YAVA's alright in my book. Just make it a bit different and better than whatever has existed before.


*no squirrels were harmed in the writing of this blog post

Mobile Net Neutrality - Exploiting the Grey Areas

There is no one definition of Net Neutrality. It is a concept rather than a technical or legal definition. It is not even clear in many eyes whether it applies to all networks (no) or just the Public Internet (yes) - and what happens where they both share infrastructure such as broadband access (err... good question). 

Certain things are definitely "not neutral" under any definition, such as deliberate degradation or outright blocking of legal Internet content or applications, on otherwise uncongested networks. Conversely, other aspects such as capped data plans, the use of CDNs or protections against denial-of-service attacks are viewed as completely acceptable, by all but the most hardcore "activists". 

Much of the current furore is around the prospect of paid-priority "fast lanes", otherwise known euphemistically as "specialised services", and whether they force other non-partnered traffic onto unusable "slow lanes". This also tends to draw distinctions between fixed and mobile data broadband, because the former already have dedicated QoS-managed pathways for carrier VoIP and IPTV, while mobile broadband generally does not, except for a few tough-to-implement VoLTE instances. 

Given this blog's focus, the main emphasis here is on mobile data models rather than fixed broadband.

The vagaries of mobile networks such as interference, mobility, devices & coverage, and the fact that most traffic to smartphones goes via 3rd-party WiFi anyway, tend to make discussion of general 4G paid-QoS mostly irrelevant. You can also add in the lack of any obvious willingness of market participants to pay for "unprovable but slightly better than average QoS, honest" and the ever-better capability of most software to deal with occasional network variability and glitches.

Some market participants try to steer discussion towards totally irrelevant topics, such as paid peering arrangements, or "discrimination" by Apple or Google in their app-stores or access to OS APIs - usually to try to create strawman arguments about their own preferred stance on real Net Neutrality. While both might be examples of "unfairness" in an abstract sense, they are completely decoupled from broadband access to the Internet or other services.

Such "red herrings" are simply used to deflect the Neutrality discussion. But a more interesting set of developments can be considered "grey areas". Many mobile operators are trying to nibble around the edges of Net Neutrality - partly to see how far they can push regulators' boundaries, but also in an effort to differentiate their broadband propositions. They are testing the waters with approaches such as:

• User-defined prioritisation, where the customer rather than telco defines their own Internet connection's "non-neutrality", or chooses ISP-managed offers like "gamer broadband", or various child-protection content-filtering options.
• Various "worse-efforts" concepts, where "unimportant" traffic can be delayed until, or sent pre-emptively during, network quiet periods.
• Zero-rating of certain content types, i.e. exempting specific data from users' quotas. (I posted a detailed post here a few weeks ago). In this scenario, nobody pays per-MB for the data, although there may be revenue-share or other partnership models involved.
• Sponsored-data / "sender-pays" models, such as that proposed by AT&T, where (in theory) 3rd-party application or content firms pay to offset users' traffic consumption. I wrote a fairly scathing post here
• Application-based charging, for example a flat-rate per day for using Facebook or Whatsapp.
• User-based prioritisation, where certain customers (eg business users) receive better speeds or QoS than other users. While this does not explicitly differentiate between applications or content, in most instances businesses don't watch Netflix, and consumers don't use SAP.
• Differential treatment or pricing of data that goes via proxy-based platforms (eg Opera Mini, BlackBerry) rather than direct to the Internet
• M2M services managed differently to their consumer-centric data plaforms
• Dedicated MVNO-type deals, such as those used by Amazon with its early Kindles, which look similar to "sponsored data" models. 

It can be seen that most of these "grey areas" involve differential pricing, rather than more "invasive" network-based QoS and prioritisation. Such approaches are easier both technically and in discussions with regulators. They also allow the operators' marketing teams to work (fairly) swiftly to construct plans and deals, without getting mired in the cumbersome technical and organisational realities of network operations.

Two of the most high-profile approaches to "Grey Neutrality" are the zero-rating and sponsored-data approaches. AT&T's January announcement of its Sponsored Data API programme has been a catalyst, and also in the US recently, T-Mobile has launched its "Music Freedom" plan as well as zero-rating speed-test data. 

Orange zero-rates traffic to its personal cloud service for consumers, Telia zero-rates Spotify and DT zero-rates its German mobile TV service. Of course, many other internal operator services such as MMS or closed-garden portals have long been available without incurring extra data usage costs, while BlackBerry plans have often been subscription-based rather than per-MB.  

Numerous emerging-markets operators have free offers to access Facebook/Twitter/Wikipedia/Whatsapp/Viber and numerous other services, including some giving free access to educational materials - although often this is in countries which don't have Neutrality legislation anyway.

To be fair, the original vision for mobile data services was that they would be "on net" and billed in various modes, rather than volume-based Internet access. To a large extent, "raw" Internet access was only offered on mobile after most of the other 3G service models failed to gain any traction.

It is therefore unsurprising to see operators look to go back to the model of bundled or separately-billed services - although the main question is how this fits with the app-download paradigm, which normally implies a need for "vanilla" Internet access rather than hooks into a telco-resident server.

While the lawyers and lobbyists continue to argue over "fast lanes" in a black-and-white fashion, Disruptive Analysis believes that these tend to miss the point anyway, at least in mobile. There are only a few realistic use-cases for such QoS-optimised propositions, and they are unlikely to ever contribute more than a couple of percentage points to total mobile broadband revenues.

The action is going to be in the "grey areas". Disruptive Analysis new report predicts over 1.5bn users of zero-rating by 2019, for example. In the sponsored data realm, the most promising category is in advertising, where it seems relatively non-controversial (and consumer-friendly) for unsolicited promotional content to be paid for by a third party, rather than consuming the user's quota. 

Sponsored data and zero rate charging - Non-neutral mobile broadband models from Dean Bubley

There may be a few other "grey areas" emerging as well - expect interesting variants to emerge as SDN/NFV takes hold over the next 5 years - perhaps with CDNs or caching to be pushed down to the radio network. This will enable many services to be delivered "not directly from the Internet", although whether the APIs are available to mainstream mobile app developers is questionable.  New forms of MVNO may emerge, as well as capabilities delivered via private cellular networks, WiFi or via telcos' API platforms.

Regulators and others will find these challenging to deal with, so need to ensure that rules are framed flexibly and clearly.

In any case - they key thing for Net Neutrality isn't the fireworks at the FCC or in Brussels. It's the smaller instances of edging closer to the rules' limits, especially around charging. Conversely, we should expect a lot more push-back and unintended consequences, where operators try to unilaterally block or degrade mainstream web services. We already see Netflix "outing" Verizon's perceived/alleged games - that type of naming & shaming (and perhaps lawsuits) will be much more common, as well encryption and obfuscation.

FOR MORE ON NON-NEUTRAL MOBILE BROADBAND MODELS, CLICK HERE