WebRTC: we're starting to see the "big guns" emerge into the real world. First up, Zendesk, Vonage & Siemens

While the internal WebRTC world has seen a lot of famous company names attending conferences, participating in standards bodies, issuing press releases, or selling tools, SDKs or enablers to each other, relatively few have actually put out "powered by WebRTC" products into the real world for users.

Obviously, Google and Mozilla have both launched browsers, but that doesn't really count as that's still an "enabler" rather than an end-user product or service. There's also a ton of plucky startups like Bistri, Solaborate, Uberconference, Twelephone and others that have entered niches like conferencing and social networks, but none have yet hit maturity or been seen as major disruptions to the status quo in their sectors.

Buy the Disruptive Analysis WebRTC strategy report & market forecasts - now including the Q2 June 2013 update

To my mind, there are now three "traditional" big players that have walked the walk, and put WebRTC into their mainstream products:

• Zendesk is a major player in SaaS-based customer support, enabling helplines or mail/IM interaction for big web companies and others. It has 30,000 customer companies and has facilitated support for over 200 million "customers' customers". It started to defaulting to WebRTC for voice calls a couple of months ago, on relevant browsers, while others still use Flash or other options. (It's worth noting that other startups such as Zingaya also have WebRTC-based B2C click-to-call buttons deployed for some large companies for support & CRM)
• Vonage created quite a stir at the WebRTC Expo in Atlanta last month. As one of the best-known VoIP players spanning home phonelines to mobile apps, it is the first of the big consumer communications brands to adopt the technology openly. It is also the first massmarket company to commercialise a non-browser, app-integrated variant of WebRTC, optimised for working on mobile devices. (Good interview with the CTO here). It's also pitching to provide white-label/partnered plaftorms for telcos. Outside the main scope of this blog post, but Vonage is apparently using the WebRTC Native Stack - the code mostly intended for browser suppliers - to build WebRTC into a non-browser app instead. It also claims several million users already, on both iOS and Android.
• Siemens Enterprise Communications is the first major enterprise UC player to throw its hat into the WebRTC ring with a (beta, pre-commercial) offering, called Project Ansible . At first sight, Ansible looks remarkably well-thought through, with social integration, fixed and mobile implementations, Hypervoice-type features ("Thought Trails") and, importantly, as much emphasis placed on design (courtesy of specialists frog) as engineering. The website discusses things like "joy of use" and "freemium models" - unusual for business comms tools from major vendors. Siemens has stolen a march on its big UC peers (albeit it with a beta) - despite Cisco being involved in WebRTC since Day 1, and an Avaya employee quite literally "writing the book". As yet, they haven't announced actual WebRTC products, though. Others like Microsoft are pursuing other strategies for now (Skype/Lync integration etc).

So what can we learn from this?

First, the "big guns" are now coming out of hiding (or at least, out of their labs). One is an outlier, two is a coincidence, but three is a trend. I'd expect many of the others in each of these categories' peer groups to start using WebRTC over the next 6-9 months.

Second, there are no telcos in this list. The closest we've seen to market-ready WebRTC offers from SPs are AT&T's API work, and Telefonica's OpenTok and Mantis tools/platforms for developers. However, we haven't yet seen an end-user telco WebRTC proposition, although Telefonica is "eating its own dogfood" with its use of the TokBox-powered Oscar videoconferencing application internally.

Third, a lot of real-world WebRTC use is going to be hidden. There may well be a bunch of companies - banks, healthcare providers and so forth - using WebRTC "under the hood" in their websites, perhaps using call-me buttons, or gateways from Thrupoint or Oracle or Genband or others, without trumpeting it to the wider market.

Fourth, although enterprise deployments are still in the vanguard for WebRTC, the emergence of Vonage's solution raises the possibility that consumer mobile apps will rapidly deliver millions of active users. It's not just Chrome and Firefox browsers that update easily or automatically - most mobile apps do as well. It only takes one major social network to adopt WebRTC - not even for "calling" but maybe something data-related or other video use-cases - and I'm going to be reworking my forecast model again. To my mind, Vonage has been the big light-switch for a lot of people - mobile WebRTC isn't necessarily going to be browser based, but embedded into apps.

Fifth, startups are going to have to either act fast or differentiate solidly. Incumbents in most WebRTC-centric applications aren't going to be taking years to procrastinate and respond to disruptors. This puts a premium on marketing, distribution and sales, especially where newcomers are pitching directly against established players - videoconferencing, I'm looking at you! (I'll reserve judgement on some of the telecom use-cases' ability to accelerate though: let's see what happens).

Overall, it's good to see well-known players like Zendesk, Vonage & Siemens adopting WebRTC. It gives gravitas to the market and gives something for a couple of naysayers to chew on. 

Let's see who's next: my money would be on the other UC vendors looking to spike Siemens' guns with brought-forward announcements, although we could conceivably see a VoIP/IM brand like Viber or Whatsapp surprise us as well.

If you're reading this and want more details about Disruptive Analysis' predictions for WebRTC, you should definitely buy the report - now available including the Q2 June 2013 update.

Broadband, Internet, Voice, Telephony, Messaging etc: Words & semantic matter

I had two conversations about fax machines and security-alarms yesterday.

Very 1980s, you might think. Yet both cropped up in conversations about FTTH, IP networks and the future of communications. My two discussions were with colleagues and peers Benoit Felten and Martin Geddes.

The conversations highlighted the importance of a few words that we use in the telecoms industry without really thinking what they mean properly. "Phone lines", for example, are not just used to make phone calls. Obviously they are used for DSL too (more on broadband below), but also fax machines, alarm systems, point-of-sale terminals, elevator emergency phones and all sorts of other things.

Historically yes, phone calls have been the main use of narrowband phone lines. But as telephony revenues fall ever lower, and we start to look at IP replacements via fibre or perhaps wireless, a bunch of other issues start to become disproportionately important.

"Oh, we can run fax over IP if it's really needed". Yes, true - but what about fire alarms & the elevators? Even if those systems can be reworked over IP, what is the cost of switchover? How much does a "truck roll" for the safety certification guy from Otis cost?

So it's worth being careful about talking about switching off the "phone" network, as it's not just about phones.

Similarly, I've often drawn a distinction between "voice" and "telephony". Apart from a little bit of push-to-talk, and maybe conferencing, telcos only do the latter. They don't have "voice" revenues, they have "telephony" revenues. There's a broad and growing set of voice communications models and applications that are nothing to do with phone calls. However, few executives - or regulators or investors - have quite woken up to this yet. Given the likely downward trajectory of telephone revenues (including mobile calls) over the next few years, this is going to become suddenly important.

The ways we manage, record, bill, present, regulate, intercept non-telephony voice is currently off of most peoples' radar screens. Do we need 911 and lawful-interception for baby monitors, business "hoot'n'holler" intercoms, networked karaoke or in-game chat? Do we count baby gurgles and songs in minutes and report the stats? Will PRISM have to listen to the snores of someone under remote-diagnosis for sleep apnea?

Broadband vs Internet is another critical semantic distinction. Internet access is just a very specific - albeit special - application of broadband access networks. For consumers, broadband today often also has carrier VoIP and IPTV delivered alongside Internet access, and in future we may get various digital lifestyle services, remote metering and so forth delivered, which do not transit the public Internet. This has implications for both how we quantify economic costs and benefits, but also how rules such as Network Neutrality get applied. Sloppy use of the wrong terminology can lead to poor investment and regulatory decisions.

The Internet/Web distinction is well known but also widely overlooked.

"Messaging" is a fairly nebulous concept too, as I've discussed before.

Lastly, we have "mobile" which can refer to mobile networks (3G/4G cellular vs. WiFi), mobile devices (smartphones yes... but are tablets "mobile"?) or mobile users (moving about vs. nomadic vs. stationary). Whenever you see stats claiming "X% of web use / data traffic / Internet users is mobile", you can guarantee that there's no clear definition. Frequently, people will pick whichever definition gives them the largest number to try to make their point stronger. The argument that a WiFi-only tablet that never leaves the sofa - never mind leaving the house - contributes to "mobile web advertising" is somehow "mobile" is ridiculous.

Mobile vs. Wireless is another troublesome one, especially as the telecom industry has historically designed complex and expensive networks specifically to meet the needs of people "moving about", but then happily sold most of their services - and gained most of their revenues - from people who are wirelessly-connected but stationary. That was fine in the past, but is starting to be a questionable assumption as perfectly-good wireless networks start to become available for free as an "amenity" rather than a "service".

We've also got "application" which can means 100 different things depending on who you're speaking to. User vs. subscriber is good one too.

Overall, I think it is incumbent on all of us to become much less sloppy with our telecom semantics. In the past, the world was simpler and we could get away with saying "voice" when we meant "telephony". Lobbyists could conflate Internet and Broadband, twisting words to hide flawed arguments against Neutrality.

But now, the industry is facing laser-like challenges, as well as narrow and well-defined opportunities. Picking the wrong words, making flawed generalisations and comparisons, confusing subsets and supersets - all these will lead to poor decision-making and flawed analysis.

Think twice before you open your mouth....and correct other peoples' sloppiness and push them for definitions of what they mean.

What I'm looking for at this week's WebRTC Conference & Expo in Atlanta

I'm now in Atlanta, catching up from jetlag and preparing for what I expect is going to be a landmark event for WebRTC - probably the year's largest conference and exhibition on the technology, with rumours of 600+ attendees and a sold-out roster of sponsors.

I'm speaking this afternoon at the Business workshop along with organiser Phil Edholm, and fellow analysts Chris Vitek and Brent Kelly. I'm also moderating four panels over the next few days, on topics like SIP/WebRTC coexistence, WebRTC "game-changers" & the impact on telco business models. I'll also be on the wrap-up panel on Thursday, "beyond the call". Add to that being a judge for 50 or so 10-minute demos, numerous client meetings, briefings and dinners, and I think by the end of the week I'll be saturated in the current status of the WebRTC marketplace.

I've got a number of questions to answer, that I'll be looking for input for both directly and indirectly. It's often telling to see what people don't say, who is/isn't present, and meta-themes emerging when comparing multiple presetations or panel responses that gives a real clue.

Some of the topics to watch:

• EDIT (forgot the obvious!) is WebRTC going to be driven more by adding Web-based access to existing types of RTC, or by adding RTC to the Web? eg Web-enabling RTC = browser front end to UC, IMS, contact centre; RTC-enabling Web = click-to-speak on a B2C site, or a million niche things like streaming sensor data, or adding karaoke to a music-download site
• At the moment, I think enterprise use-cases have a narrow real-world lead over both consumer web & telco applications of WebRTC. Will that be sustained?
• How far are we from seeing real, innovative applications of WebRTC actually in the world and being used? I don't mean just using it instead of a SIP softphone or as a cheaper call-centre agent desktop, but something really unexpected or headscratching
• Is the datachannel aspect of WebRTC really the hidden gem?
• How can I categorise and segment the WebRTC Gateway vendor space? Who's real and who's just playing Powerpoint-and-press-release? It's getting really competitive, and I suspect it'll end up as a few big players, plus niche focused specialists, plus a lot of "WebRTC-as-tickbox-feature". And some dead me-toos.
• How can I categorise the API/SDK/cloud bit of WebRTC vendor-land? I've lost count of the number I've encountered here - between 10-15 I think. Is it all about mobile? Is anyone doing anything *real* with WebRTC cloud platforms yet, or will it take developers a few more months to churn out the good stuff?
• Any news on the "missing"? Microsoft, Apple, IBM, Samsung, Amazon - please stand up! Bonus points for anyone doing a WebRTC mashup with face-recognition camera & LinkedIn profiles to spot any stealthy undercover representatives.
• Which telcos are lurking around? Who's willing to actually pipe up  and say something beyond the usual culprits like AT&T & Telefonica/Tokbox?
• Who's here from Asia? All the signs are that WebRTC is under lots of scrutiny in China, Japan, Korea & Singapore. But little news on exactly what's being done....
• Where is Google taking all this? What can be inferred from what's left unsaid?
• Ditto for Cisco, Ericsson, Oracle - do they have big strategic games afoot? Or are they following the NSN & ALU view that WebRTC is just another front-end for IMS/VoLTE/(RCS)
• How much of the WebRTC vendor market will Open Source eat?
• What are the appropriate WebRTC market metrics for me to forecast in the future?
• Are my forecasts for devices support & user base growth too aggressive, or will I need to upgrade them again as I'm actually conservative?
• Will there be any seriously big unexpected announcements?

Plus also a couple of other topics I'm keeping under wraps, either for clients or my own research into WebRTC.

Overall, it's going to be a gruelling week, but by the end of it I expect to have got a much better "world view" of where WebRTC is, and where it's likely to be be by the end of 2013 and beyond. Feel free to come and say hello and/or chat over coffee or beer - and apologies if I'm dashing around like a lunatic for my next session.

On that topic: if you buy a licence for my WebRTC report before July 1st, I'll throw in the Q2 update I published a couple of weeks ago. And if you stump for an enterprise licence or a subscription to the updates (contact me for details), and I'll also add a 1-hour conference call to update on my thoughts from this week's show.

Details / payment here or else contact me via information AT disruptive-analysis DOT com

WiFi - the coming indoor vs. outdoor divide

I've been speaking to assorted vendors recently about their plans for carrier WiFi, linked to the usual rhetoric about Hotspot 2.0, ANDSF, so-called "seamless" authentication and so forth.

I still contend that a lot of this is nonsense - the mobile operators are only one group in an increasingly complex ecosystem of stakeholders interested in WiFi. The end-users, venue-owners, tenants, fixed/cable ISPs, device vendors, OS suppliers, content players, app providers, employers, advertisers and local government all have "skin in the game" with helping users connect to WiFi. Mobile operators are not "special flowers" among that group - and certainly have no likelihood of enforcing their will about when and where users will connect; much less charge them or subject them to onerous policy controls.

But I'm starting to spot a subtle distinction: indoor vs. outdoor use.

In an indoor environment,  users are used to WiFi being provided by their hotel, cafe, airport, home, office or other sponsor. Increasingly it is free, but perhaps with a small "hoop" to jump through such as watching an advert, or asking a barista for a code. Usually, the access point and backhaul are controlled by the venue or tenant, although a 3rd-party like a wireless ISP might be contracted to provide these. There will be an expectation that any person in that venue - irrespective of which cellular operator(s) they might use - will have access to WiFi, especially as many devices like PCs and tablets are WiFi-only anyway.

This is very different from outdoors.

Outdoors, people are properly "mobile", ie moving-about. They get access from only one provider - their cellular operator. Any other stakeholders like MVNO hosts, network-sharing consortia, site owners and so forth are hidden behind the "Operator X" logo displayed on the phone's screen. People accept and except that different operators will have different coverage, and that they do indeed expect "seamless" handoff from cell to cell.

Outdoors, the HetNet vision makes more sense - macrocell, picocell, femtocell - and, yes, maybe WiFi - owned and operated by the telco, may be used to provide decent data connectivity, as well as telephony and SMS.

While a few cities now have outdoor WiFi provided by a local council or company, that remains rare. People don't have expectations about outdoor WiFi behaviour the same way they do inside a building. A smartphone's WiFi essentially becomes a single-stakeholder environment (or two including the user) in the street, or perhaps a few special locations like aircraft.

In summary;

Indoor WiFi = multi-stakeholder, too complex for the 3GPP/WBA/OMA/GSMA model of operator control and network integration. Limited relevance of ANDSF, carrier-driven Hotspot 2.0, SIM authentication. Largely a UX problem.

Outdoor WiFi = fewer stakeholders, more chance for direct integration & seamlessness. Although complexities where the user could access WiFi as well as 3G/4G metrocells & macrocells. Largely a RAN/policy problem.

The other meta-problem comes from how to know when to switch from carrier-WiFi mode to multi-stakeholder WiFi mode as you enter or exit a venue. Linked to all this is a rather thorny issue of pricing and perceived value.

For many years, the mobile industry has assumed that "nomadic" use of its network was a core part of its proposition, as well as when users are "truly mobile". While that might have been the case for telephony - an indoor mobile call is "worth" as much as an outdoor one - that no longer holds true for data. The assumption (increasingly, although varying by country) is that indoor data is free - provided as an amenity, equivalent to air-conditioning or lavatories. Carrier-provided indoor WiFi will be accepted by end-users as long as it is not charged against data plans, or subject too stricter policy controls than "native" WiFi. This is going to be as much a challenge for billing & charging systems as it is for the network.

WebRTC partnerships and ecosystems

One of the things I'm expecting to hear a lot about at the upcoming Atlanta WebRTC conference & expo is partnering and the formation of vendor ecosystems.

Most enterprises and telcos putting together WebRTC solutions – even simple ones such as extensions of VoIP or messaging, or basic customer-service apps – will be reliant on multiple vendors. To this end, we are starting to see the emergence of several “ecosystems” or groups of partnerships. Disruptive Analysis views this as a critical factor for vendor success in the near term.

Some examples include:

·        Oracle/Acme works with Quobis & others

·        Ericsson partners with Mozilla

·        Crocodile is working with Telestax (Mobicents)

Over the next 3-6 months, expect to see many more similar alignments between complementary players, as well as further tactical acquisitions. Specialists such as Zingaya and Thrupoint are likely to carve important roles here, as well as a number of the API providers such as Twilio and AddLive.

I actually wrote the paragraph above in the quarterly WebRTC update I published last week for Disruptive Analysis research report subscribers. Looks like I scored a direct hit - Today I've just seen this announcement and demo from one of the companies mentioned - Zingaya - working with Cisco and another specialist firm, for a clever retail-banking WebRTC demo. See http://www.youtube.com/watch?v=hRbLnj4r71M&feature=youtu.be and more info at http://www.thrupoint.com/2013/06/thrupoint-cisco-syngrafii-light-up-mobile-banking-app/

I think this will be especially important for the growing number of vendors providing WebRTC gateways to telco or enterprise infrastructure. On its own, a gateway is going to be rather useless. It will need to be blended into particular solutions, with specific feature-sets optimised for particular use cases. It will also need to be deployed with the end-user experience in mind, and the realities of mobile apps as well. This will mean design and client-side expertise, as well as testing, security and assorted other realms of software and consulting. 

Few vendors - if any - will be able to do all of this on their own. And as yet, we haven't really seen big system integrators wake up to WebRTC, although surely that is just a matter of time. What will be important in the very short term is the establishment of concrete partnerships and developer ecosystems - I think that will be a key determinant of which vendors emerge as actual commercial winners, versus those with standalone me-too products.

Disruptive Analysis WebRTC Q2 Update: Forecasts upgraded & New Companies/Use-Cases

I've just published the Q2 Update for the Disruptive Analysis WebRTC report, the first edition of which came out in February. That report was the first comprehensive study of the market for WebRTC, spanning telco, enterprise and consumer domains. Having covered WebRTC since Day 1 almost two years ago, my intention is to keep Disruptive Analysis in the position of leading analyst & consulting house in this sector.

The new 29-page update document is available to clients who buy the full report with the optional ongoing subscription, but some highlights are provided here. (Those who bought the standalone report can upgrade to get the updates as well - please contact me for details)

Firstly, I've upgraded most of my forecasts for both device support and expected active usage, as the original numbers looked a bit conservative in the light of recent developments. The speed of emergence of WebRTC in Firefox and Chrome-for-Android has been impressive, in particular. Also, overall smartphone growth is accelerating, while WebRTC support is being enabled by a growing range of API/cloud players as well, which aim to simplify the technology for mobile developers.

I'm now expecting:
• 875m devices with WebRTC vs. original forecasts of 810m for end-2013

• 1 billion device threshold crossed in Q1'2014 rather than Q2'2014

• 3.9bn devices supporting WebRTC, upgraded from 3.4bn, for end-2016
• Active user base (individuals) for WebRTC to exceed 1.5bn people by end-2016

Note that Disruptive Analysis' forecasts differ from some others in that estimation of primary browsers is a core step. Many users have multiple browsers installed on PCs or devices, but only use one regularly - a gating factor on realistic addressable WebRTC users for developers.

The report update also includes discussion of the fast-evolving, already-crowded market for WebRTC gateways, and the need for vendors to look for differentiation based on specific use-cases or partnerships/ecosystems to stand out. In the last 3 months numerous vendors have announced products and strategies, some aimed at carriers, some at enterprises and others with general platforms. The market is already crowded, and the addition of various open-source alternatives as well as "WebRTC as a service" cloud platforms will make it even harder for generic me-too gateways to gain traction.

In terms of strategic issues, there's an update on what Microsoft's intentions might be, as well as a viewpoint on the VP8 vs. H.264 impasse. My view is that MS is focused mainly on Lync/Skype/XBox integration as a strategic corporate opportunity, but will also start progressively adding support for WebRTC as it gets standardised - perhaps as well as its own CU-RTC-Web proposed alternate version. The video codec situation is messy and has no obvious near-term resolution. It's worth noting that two major H.264 advocates (Apple & Microsoft) are losing both credibility and moral authority with late provision of WebRTC-enabled browsers compared to Chrome and Firefox, which are helping define VP8 as the de facto video codec for web developers irrespective of the "official" standards work.

This highlights the difference between "adding RTC to the Web" vs. "adding Web to RTC" - the former use cases and players move at web-speed, while the latter group tends to be constrained by the pace of traditional comms-business proceses (telco or enterprise).

The document also looks at the current real-world use-cases (eg contact centre agents) and predicts the trends over the next 6-12 months. The proliferation of a startups in broad class of cloud/API-enablement players points to a coming rush of consumer-web applications for video-chat or integrated comms in H2'2013. Datachannels support in new browsers suggest innovation in domains like content-sharing and collaboration (including coding for developers). In addition, I'm expecting WebRTC-enabled adverts to be a major part of the future landscape.

Telco use of WebRTC is bubbling under the surface - there's clearly a lot of interest, but I expect it to emerge relatively slowly because of the need for new "furniture" like BSS/OSS and testing solutions. Over-focus on standards will also cost telcos the lead, as I disussed in this recent post. And while IMS-integrated WebRTC is interesting, it is only one of 5 or 10 possible telco use-cases - operators' executives should ensure that numerous departments consider the opportunities for the technology, not just the core/voice network and labs teams which may be too slow and conservative. If necessary, telcos' innovation arms should be prepared to disintermediate their own voice/messaging teams and "BYOWebRTC" instead.

The update also gives quick commentary on about 50 vendor/service players in the WebRTC marketplace, including the addition of 20-30 companies not mentioned in the original report.

If you are interested in purchasing the original main WebRTC report, details are here  

For more details on the quarterly update subscription or other WebRTC advisory services, please email/message information AT disruptive-analysis DOT com

Is Israel about to ban carrier WiFi offload?

I didn't see this coming at all - according to this article on Azi Ronen's blog, the Israeli government wants to ban carrier WiFi in public places, and has been consulting on this for some time, and will publish an official statement this week. I have to admit it's the first I've heard of it.

"The reason for banning the use of Wi-Fi is spectrum shortage, and letting CSPs to use these frequencies will limit the public access to the internet. Nevertheless, municipalities and other public organizations will be allowed to offer free public Wi-Fi services"

The article Azi links to (put through Google Translate) suggests that Israel has allocated less spectrum to WiFi than most of the rest of the world and as a result there is a lot more contention for it. The two tables and notes on this Wikipedia page shows that the country does indeed block certain channels in both 2.4GHz and 5GHz bands. The article also hints that the Ministry would like to clear other chunks of spectrum to use for WiFi in future.

Having been to Tel Aviv recently, it's worth commenting that there is free WiFi pretty much everywhere. Any restaurant or bar, as well as the airport, a lot of shopping malls and other public places, had free WiFi - either totally open or with a code provided for those who ask.

(This isn't the first instance of WiFi regulatory weirdness in Israel - 4 years ago it stopped iPads being brought into the country temporarily because of fears over congestion from too-powerful radios, or perhaps inability to lock-out certain channels)

While this might be a country-specific isolated law, it raises an interesting set of general issues and points.

Firstly, it could be argued that Carrier WiFi offload is a less-valuable use of unlicenced spectrum than venue/app-sponsored free WiFi, because it doesn't add to the overall amount of (free) Internet Access available to citizens in public places. Instead, it just substitutes one form (3G/4G) for another (WiFi), with the benefit of "offload" accruing to the operator, rather than end-users or (implicitly) the economy. Yes, offload WiFi is often "free" or excluded from mobile broadband quotas to subscribers, but it is typically locked-out or fee-based for non-subscribers.

Secondly it points out that WiFi used for (free) public Internet access is rapidly becoming a public amenity and that governments are starting to protect it. As well as various municipal WiFi projects provided by authorities themselves, we also have other legal rules on commercial provision of WiFi - for example Kuala Lumpur mandates that restaurants offer free WiFi. I also had a chat with a telecoms regulator a couple of years ago that mused that if WiFi use became sufficiently important and valuable, it might need laws to protect it - for example, against other uses of 2.4GHz such as leaky microwave ovens or garage door-openers. Increasing usage and popularity of WiFi points to the fact that a lot of smartphone/tablet use is "nomadic" rather than properly moving-about mobile - and therefore not really cellular operators' supposed target market anyway. Is "non-mobile" WiFi really a service? Or is it an amenity like air-conditioning and public bathrooms, or even electrical sockets in cafes?

Thirdly, it points to a dilemma for telcos - if they start using WiFi and unlicenced spectrum aggressively, it becomes very hard - hypocritical even - for them to lobby against more spectrum being made licence-exempt in future. Obviously they would prefer to have licenced bands allocated to individual operators, but just without expensive auction fees.

Fourth, this type of law is going to be quite hard to frame. Does it just ban carrier WiFi offload (ie actual substitution of 3G/4G traffic for WiFi) or does it also apply to all the other operator-led WiFi business models and purposes? My view has long been that "offload" is probably only the 3rd or 4th most important thing that telcos can do with WiFi anyway - more interesting models are open-to-all "onload", managed WiFi for venues, wholesale WiFi for other service providers, "shared WiFi" models like FON, location analytics and so on. WhileWiFi offload itself doesn't improve public amenity of Internet access, some of the others generally go.

Fifthly, there's always the outside chance of a "conspiracy theory" here - or at least some well-crafted game theory. If extra carrier WiFi in public places does congest unlicenced bands and interfere with other providers such as free hotspots in cafes, then implicitly it raises the utility and value of managed/licenced spectrum and mobile broadband plans. It would also make things like small cells much more attractive to end-users and venue owners. But surely nobody in the mobile industry would be that Machiavellian or cynical (or that smart) to do such a thing?

Lastly, this throws into question the legality/acceptability of various "seamless" WiFi log-on technologies like ANDSF and Hotspot 2.0. As I wrote last week, I already think that these are problematic from an end-user point of view, but this adds a whole other angle.

Overall, I'm a bit wary of this proposed legislation. While I certainly think that "seamless offload" and WiFi-integrated HetNets are problematic for all sorts of reasons, I'm definitely a supporter of what I'd call "WiFi Neutrality" - that users should be able to connect to whichever wireless ISP they wish and not be forced/blocked by external forces. I had telcos restricting "private" WiFi in mind, but this could equally apply to governments as well. (Employers and parents enforcing restrictions are OK for obvious reasons). I regularly use various forms of carrier WiFi - although in the UK this is usually provided by fixed rather than mobile operators. What would happen with hybrid fixed/cellular telcos, eg BT now has LTE spectrum - would Openzone be banned under the Israeli proposals, or just any use of it for offload?

This is a complex area and while (as far as I can tell from a brief article) the Israeli government's intentions are sound, there is a lot of complexity in the details.

Delayed WebRTC standards may have unexpected side-effects

Overall, it seems that the standardisation of WebRTC is taking somewhat longer than I anticipated at the time of my strategy report’s publication in February. According to the group’s home page, at 1^st June 2013:

·         Last Call Working Draft: re-scheduled for Q1 2013, but will be further delayed (Q3 2013?)

·         Candidate Recommendation: initially scheduled for Q4 2012, but delayed probably until Q1 2014

 

I'm currently writing up the first of the quarterly updates for the report's subscribers. (What do you mean you haven't bought it yet? Sort it out....!) and one of the conundrums is that while standards are slower than I anticipated, uptake and various fields of innovation seem to be happening even faster than I'd envisaged. I'm upgrading my forecasts.

Standardisation is slow both overall in terms of finalising the IETF/W3C drafts, and specifically with certain elements within them. I'm not going to rehash the video codec debate in this post, but that's still lurking. There's also a lot of to-ing and fro-ing in the email discussion lists about the "offer/answer" approach to setting up or tearing down WebRTC sessions, especially around large multi-party conferences, which may have to endure a lot of setup latency. Add in security, enterprise considerations, needs to support various telco use-cases and techniques like network QoS, and it's unsurprising that  things are becoming more complicated. There are also a lot more stakeholders involved, many from "legacy" worlds of communications as well as the more free-wheeling web community.

But ironically, one of the side-effects of slowed standards finalisation appears to be a disproportionate effect on the telecom and “conservative enterprise” segments for WebRTC. Those groups are typically the slowest and most constrained to wait for specifications to settle down before taking action on implementation. It seems unlikely that too many operators will want to release "live" WebRTC-extended VoLTE or RCS while the standards and implementations are in a state of flux.

Conversely, web-based companies tend to be much happier with fluid pre-standard versions of APIs or capabilities. They either re-work code as new versions emerge, or rely on a host of intermediate API/cloud providers to do it for them. In the case of WebRTC, for example, there are already more than a dozen companies “wrapping” WebRTC video-chat in forms suitable for embedding into websites, providing developers with SDKs, libraries (chunks of pre-coded software downloaded with a page) and  cloud back-ends. Numerous early applications and services are using VP8 implementations for video in Chrome or Firefox - irrespective of whether we end up with a defined standard or not. 

It is the tier of enabling cloud/API providers that will bear much of the pain of standard tweaks or eventual fragmentatation – but as experts focused on the changes, they are capable of doing that with alacrity.

If anything, slowing down standards for WebRTC may only end up harming those most responsible for delaying them. For everyone else, there's already "enough to be getting on with". In my view, telcos and network equipment vendors need to try to *accelerate* the first round of WebRTC standards, as otherwise they'll get bogged down in layers of SIP-like extensions and regulatory "what-ifs". Save that stuff for 2.0. 

Separately, divisions of telcos that are not linked into the core-network/standards process should just "get on with it" and develop their own early WebRTC prototypes, sites, apps and products immediately - if necessary, disintermediating their own official "comms" platforms like IMS if they're not prepared to work on the basis of day & week cycles, rather than quarters and years.

The Number 1 problem for "seamless" models of WiFi offload / network selection

I frequently argue against the assumption that "seamless" connection to WiFi is practical or desirable, especially for the general case of smartphones or tablets being "pushed" automatically to connect via a combination of technologies and new standards like Passpoint, Hotspot 2.0, ANDSF and EAP-SIM.

I thought it was worth stressing and clarifying the single most problematic use-case:

Worst case scenario: A device automatically being connected to paid or overly policy-managed carrier-WiFi, when a free alternative is readily available

Nothing will cause customer dissatisfaction & churn faster than incurring additional costs (or additional usage against a quota) than this. Expect lawyers, regulators, consumer press & commentators to throw very large & painful bricks at you if it occurs. And probably device & OS vendors too.

The classic example that most readers of this blog will be familiar with is attending a conference in a hotel with expensive WiFi, but where the event organisers give you a free code, or even set up their own APs for better performance/lower cost. We'd be deeply annoyed if our phones "roamed onto" the local WiFi automatically, unless the usage was 100% free as well. Similar story if your frequent-flyer lounge has free WiFi, but your devices magically jumped onto the paid/roamed WiFi in the main airport hall.

I am writing this on a laptop, with two phones by my side, in Starbucks in London. There is free WiFi (provided by BT Openzone in this case). You typically log on via a very simple splash page and selecting an obvious Openzone-Starbucks SSID. A very small "seam" indeed. Alternatively, I can use the BT WiFi app I have on my phones for free, or login on the "normal" BT Openzone SSID page, because I have BT Broadband at home. I'd be irritated if I was automatically shunted to one of my CellCo's SSIDs instead, with their charging and policy being applied.

Same thing in hundreds of other situations too - restaurants, pubs, offices, friends' homes, public buildings and so forth. There is free WiFi - often very good too - easily obtainable from a source other than the cellular operator. There are multiple stakeholders here - the venue, advertisers, content companies, fixed operators, your device supply, your employer and so forth. All might have negotiated a better "private" WiFi experience than your cellular provider at that location.

Not only that, but the cellular WiFi option might be subject to onerous policy restrictions (eg VoIP blocking) which don't apply when you use WiFi in "private" mode. 

There must be an easy and obvious way to manage this - and not just buried 7 layers down in the menus with some obscure configuration settings. The alternative is that the carrier WiFi is 100% free, 100% unmetered, in which case people won't care about the other options. That is why Apple is happy with AT&T and some other operators doing automated WiFi log-on, as it's in a customer-friendly form. One other possible option is that the operator (instead of charging you) gives you extra free stuff such as exclusive content to tempt you onto its WiFi option.

Seams are often there for good reasons, as well as bad. Seams can be monetised; seams can present the user with important information or choices. In some cases automation and "frictionless" connection in desirable, while in other cases it's not. Mobile operators are just one (often minor) stakeholder in the overall WiFi ecosystem, and need to stop arrogantly assuming that their WiFi choices trump either users', or other parties. Unless and until Hotspot 2.0 and its related standards fully and explicitly recognise these choices, it's dead in the water.

WebRTC - how to get support into old browsers?

I'm currently updating the WebRTC forecast model used in the Disruptive Analysis research strategy report & update subscription service. A core part of it examines the likely penetration of WebRTC capabilities into different classes of device, via browsers or other paths.

Most in the industry will know that Chrome browsers already support WebRTC switched-on by default (albeit in its current pre-standard form), with Firefox support close behind in its Beta version. There is much speculation about if/when Apple and Microsoft might follow. I've got my own views on that, with my assumptions stated and baked into my forecasts.

But there is a critical difference here - there is a very large legacy installed base of IE browsers, and to some extent Safari as well - that doesn't auto-update to the latest version. IE9, 8, 7 and even 6 are still lurking around, especially in certain countries either with lots of old PCs, or for corporate users whose CIOs lock down application updates and installs.

How is WebRTC going to be extended to those last hold-outs, even if IE11/12 or future versions of Safari support it?

One option commonly discussed is Google's Chrome Frame plug-in for IE. However, it is unclear whether anybody who still uses an old version of IE is going to readily want - or be allowed - to install a new plug-in. The whole point of WebRTC is to avoid plug-ins, especially for occasional audio/video tasks such as conferencing.

(Sidenote: I have a growing hatred of all the various web conference tools that vendors briefings or clients/contacts force me to use - no, I don't want to have to sign in 15 minutes in advance to make sure it all works and I've downloaded whatever chunks of software are supposed to help. Increasingly I turn down such requests, asking instead for a PSTN dial-in and emailing me the PDF presentation - or, alternatively, force *them* to use my choice: Skype).

So, I'm doubtful that Chrome Frame is going to do much to extend the reach of WebRTC to many of the old-browser community. Maybe Google can cunningly force its use by pushing it as a way to enable/enhance GMail or Hangouts, but it's not obvious that's the case.

I had an interesting thought yesterday though - most of those old browsers will already have Flash and Java plug-ins (as well as maybe Silverlight and others). Maybe the "vector" for WebRTC support on "old IE" will turn out to be Adobe or Sun (ie now Oracle), if they include it within the next updates of users' current plug-ins? Obviously Adobe still has its own competing RTMP & RTFMP protocols, but it must surely by now see the writing on the wall, much as it has with Flash vs. H.264? Could it gain relevance by being a lead provider of WebRTC APIs? Provide a combination of the two with RTFMP as a fallback or way to manage certain scenarios? Maybe even get subsidised by Google to help extend WebRTC's reach more quickly....

The Oracle/Sun/Java pitch is perhaps easier - it wouldn't surprise me at all, and there are some obvious synergies with the acquisition of Acme Packet.

(Note - I have no inside knowledge of either of these; both are total speculation on my part. I'm actually embarrassed I didn't ask Oracle or Acme about it - or even just suggest it - when I met them recently).

One question I haven't thought through though - what would this mean for PCs which end up with two or more WebRTC implementations? Native browser capability, plus plug-in, plus maybe the sort of web-app Javascript/API approach we see from AddLive or Plivo and others? Will there just be a "default WebRTC engine" or will it be managed in another way? It strikes me that we'll definitely see smartphones and tablets with 2+ implementations of WebRTC, so this issue will need to be addressed anyway.

Telcos need to offer 2+ separate voice applications & decouple RCS + VoLTE

In yesterday's post about RCS, I mentioned in passing that VoLTE and RCS must be 100% separated if either is to stand a chance of success. At present, attempts to combine them in RCS5  are, depending on your viewpoint, either: (a) a rather Machiavellian attempt to force deployment of RCS even among skeptical carriers, or (b) because a few use-cases of IM/chat benefit from being integrated with voice communications. There is also the vendor bundling argument of "Get 2 apps for the price of 1 on our IMS platform".

The net effect is shackling the already-hobbling VoLTE to the corpse of RCS, making it drag its deceased counterpart along for the entire distance of a marathon. Not a strategy for success, for either (a) or (b) scnearios. To mix my metaphors - just because you share IMS DNA with your sibling, you should still remember that incestuous marriage is banned for good reasons: your offspring will likely have undesirable genetic traits. Far better to look for fresh genes elsewhere and cross-breed with Internet species, for example.

That led to me to a broader set of thoughts about voice/messaging integration, and also fragmentation of the voice experience. I've often used this chart (or variations) for the past few years, and it encapsulates what is happening as voice goes "beyond telephony":

In a nutshell, voice communications is changing from standalone telephony, to a more complex and dynamic market in which voice gets embedded into many applications and contexts, often in forms that don't look like traditional "phone calls". WebRTC accelerates this, although it is already happening via apps and APIs in any case.

This also means that typical phones and PCs will have multiple "voice apps" in future, besides the dialler. Obviously this is already becoming true for many users today, who have VoIP capabilities from Skype, Google, Telco-OTT apps, corporate UC systems, embedded voice in games or Facebook and so forth. With the advent of WebRTC we'll see even more fragmentation of the voice experience, with websites and mobile apps featuring voice functions internally. Often, the experience of voice will often be nothing like a phone conversation - no "Hello, is that Dean?" or the normal interruptions, ringing, stilted etiquette and other bits of 130-year old furniture that make up this thing we recognise as a "call".

While we already see cloud providers and operators provide telephony APIs to developers (some do already), many of those still have the same "raw ingredient" as the basic phone call, using the same voice engine and numbering as the handset's main dialler. That's not good enough.

There needs to be much greater flexibility and imagination. For example, if I'm calling from a call-centre there needs to be Grade-A background noise suppression so you can't hear the inane chatter of my colleagues, while I try to sell you double-glazing. But if I'm on a beach making a "wish you were here!" call to a friend, it would be nice to have the gentle sound of waves in the background, not deathly silence. There are many other parameters and interaction models for developers to tune too - that's just a simple example.

For video, there are actually more options, because firms like AddLive, Plivo, Telefonica/TokBox and others are offering video APIs and back-end cloud services, based either on WebRTC or proprietary alternatives. But as far as I know, there aren't many easy APIs for non-telephony forms of voice communication yet, although Twilio, Rebtel, Voxeo Labs and others enable in-app voice with some control over interaction logic.

Coming back to the RCS/VoLTE debacle, this points to an uncomfortable conclusion - rigid, standard phone calls are precisely the wrong sort of voice to include in RCS-type use cases anyway. Even if RCS miraculously became a success, developers would probably want to mash it up with non-VoLTE voice a lot of the time. You'd want stereo for a karaoke app, and the capability to deal with a lousy external microphone, for example. Some might want to trigger a traditional phone call, but others would not. Even then, developers will want a choice of 3rd-party telephony/VoIP APIs and not just the carrier's, for example if they want to use different phone numbers.

So if telcos and their vendors decide to put voice capabilities into RCS anyway, they need to start from square one, and think "Why are we putting voice here? Is it for phone-type calls similar to Skype? or is it for other use-cases? What do users and developers actually want to do?". As with my post on messaging, they need to think about Intent & Purpose, and not just get blind-sided because they can get both sets of (independent) capability from the same platform.

A similar argument applies to VoLTE adding RCS. If LTE phone calls can benefit from associated messaging, presence or other features, is RCS really the right/only product to deliver that, for the specific use-cases that carrier feels are important?

Operators should be looking more at mashup / orchestrated approaches. And they need to be happy to have multiple voice experiences on their customers devices - and not only that, but they ought to be developing multiple voice apps/services/APIs, not just clunky old telephony warmed-over in VoLTE guise.

So if you want voice in RCS, then there's a big choice out there. Bolting it to VoLTE makes no sense whatsoever - it would even be better to have a second, different VoIP app-server on the same IMS and use that instead, especially as half the time it's likely to be running over 3G or 3rd-party uncontrolled WiFi anyway.

An RCS use-case I'd actually support & see as viable

It's now more than 2.5 years since my publication of a report on "RCS is Dead" in September 2010. While RCS has shambled on as an undead Zombie technology since then, and we've still got a few lonely operators kicking over its rotting corpse at the moment, I thought I should reflect on a couple of points I'd mentioned.

I maintain my position that there is zero benefit - and quite a lot of cost - to RCS (either the general version or the Joyn-branded GSMA-approved one) as a standalone app. The contention that it will somehow encourage people to give up using WhatsApp, KakaoTalk, Line and the other messaging platforms is risible. Worse, expounding the notion that RCS might sway people away from using embedded messaging capability in apps such as Facebook should be grounds for firing someone for gross incompetence. Blending it in with VoLTE will further delay and complicate an already-struggling (and much more important) system - the two should be kept 100% separate until either/both are well-established.

In my 2010 report, I suggested that one way to salvage something from the wreckage of RCS was for operators to offer fully-OTT versions of the app or API. MetroPCS is fairly close to that, announcing a related capability at MWC . I  also suggested that operators consider using RCS for their own customer-service and self-care function, and mandating their own employees to use it for IM (not eating your own dogfood is never a good sign). A fourth option was using RCS within operator-branded vertical-community apps, perhaps for sports or movies or home-automation.

In many ways, the GSMA Joyn branding, which has to be paid for (!!!!) by operators wishing to subjugate any hope of differentiation, has made matters a lot worse. It just highlights the fact that it is a clumsy multi-operator service that has little value until 80%+ of a given population can use it. (For MetroPCS, it's perhaps not so bad as it's the only RCS player of any sort in North America at present, so it has the logo to itself for now at least).

Overall, I see no grounds for a general-purpose, cross-operator standardised messaging app. Pointing to SMS as a success "proving" federated standards are worthwhile, ignores 20 years of innovation on the web, smartphones, cloud and apps in the meantime. Standalone Joyn is worse than useless, sucking up money and resources that could be better used by operators on design and innovation, or partnering with Internet/app providers who "get it".

I've got more sympathy - to a limited extent - for RCS as an API, or with various forms of web mashup which might create new messaging experiences and user-interaction models. Because the web integration would likely be single-carrier, ideally offered on an OTT basis rather than federated across multiple telcos, there is a chance to differentiate and make some money. (I'm not going to cover WebRTC integration here, which I address that in quite a lot of depth in my recent report ).

But in the spirit of my original report, I've actually thought through a variant of RCS which I'd actually be prepared to support, and even use myself if it worked well. Yes, you read that correctly.

For *some* of my messaging interactions, it would be useful to have a common-denominator app that's better than SMS and more convenient than email. I've thought of a version I'd actually be prepared to use.

I hate unsolicited SMS and spam emails with a vengeance. I want any future messaging services to be white-list capable, with sophisticated controls and policies. I'm not convinced that Facebook or Twitter - if they ever released an open messaging API - would be in a position to control their advertisers to the extent I'd like.

So, thinking about my "perfect generic messaging app", I want something which is able to:

- accept inbound messages from my Facebook & LinkedIn contacts only (including groups & events, not just people, but excluding brand pages). I want that configurable so I can add/drop other social services - and subsets of affiliations within them - in the future.
- accept inbound messages from people in my handset addressbook (these days, that's far fewer than FB & LI contacts - I rarely take peoples' phone numbers).
- charge £5 a time for inbound messages from unknown people or organisations, based on a combination of number + social connections. I'll even give a rev-share on this! (There's your new business model, telcos, protecting my privacy and acting as my "interruption agency").
- give me the ability to refund the fee if I want (eg a friend loses their phone & contacts me from someone else's, or a prospective client gets in touch)
- have a "report as spam" and "block" button, which also (& quite specifically) will block all marketing messages from my service provider if I choose
- has a sensible price structure - maybe not quite as cheap as WhatsApp, but £5-10 a year flat is reasonable, excluding the value-adds like the pay-to-interrupt feature. No international or roaming premiums
- has a good UI and features that evolve on a monthly basis
- Service is offered on a fully-OTT basis, usable from all my devices, irrespective of connection method. I want it to work on my PC without installing an application, via the web with a password login (or FB / LI / Twitter authentication)
- Decoupled from SIM and mobile phone number, using a separate identifier range, so there is no need to "port" it if I switch access providers, and it works easily when I travel and use a local SIM in a spare phone
- Integration with my preferred voice applications (eg click-to-speak/call), especially Skype at the moment, but maybe WebRTC ones in future too.
- A good / clever UI. Facebook's new "chat-heads" is fantastic
- Doesn't do anything creepy in terms of "big data" through analysis of my social graph / usage patterns
- EDIT: Doesn't kill my battery with clunky presence / always-on implementations. (Hat-tip to Kevin Holley on Twitter for that!) Whatsapp's"last seen online" is probably the best current version of presence, rather than online/offline/busy which nobody uses properly.

Anyone prepared to step up for that? Is it easier to do with RCS, or does that add little to the solution? For me, the "no unwanted interruptions" feature is critical, as is "report as spam".

Standalone, and pitched as some unconvincing "SMS 2.0" or direct clone of Whatsapp, RCS & Joyn are worse than useless. But if you can use it to create something unique that improves the user-interaction model, then I'm willing to listen.

(Sidenote: in the past 6 months, my worst SMS spam offenders have been the UK's pestilential PPI-refund lawyers, my own operator Vodafone UK, and the GSMA sending me unsolicited nonsense about MWC).

There is no "messaging market"

I keep reading ridiculous articles talking about SMS, so-called OTT applications like WhatsApp & KakaoTalk, Facebook, and of course my favourite RCS/RCSe/Joyn family of services.

A central theme in these articles is a supposed battle for the "messaging market", with lazy journalists or vendor marketeers painting a dark picture of mortal combat between the righteous fortress of SMS revenues, the marauding hordes of barbarian OTT players at the gates, and the Knights of Joyn riding to the rescue in their shining armour of interoperability.

This is all palpable nonsense - a strawman argument to reframe a complex and dynamic situation into the usual fatuous and imaginary Us vs. Them, Telcos vs OTTs narrative, coupled to a desperate attempt to make RCS and its GSMA-branded offspring look relevant.

Not only is this argument flawed, the likely outcomes will in many cases be worse than useless.

There is no "messaging market" today, and there certainly won't be tomorrow. We have multiple different mechanisms to send "messages" across the Internet and between phones today - and more to the point, many, many reasons and contexts for wanting to do so.

The idea that a "he said, she said" gossip via SMS is in any way equivalent to sending a signed NDA via email is ridiculous. Almost as ridiculous as equating a WhatsApp chat between friends, to a online-customer support IM session embedded in a software company's web-page.

You might as well say that there's a market for "sending things coloured blue", as it makes no less sense than a market for "sending messages". It's just more difficult to count.

For most of the last 15 years, the bulk of messages have been sent by SMS (mobile-to-mobile or server-to-mobile), Internet email (PC-to-PC, server-to-PC, or PC-to-mobile) and Internet IM (mostly PC-to-PC). And because emails are generally longer and "richer" than SMS, nobody has bothered to talk about the risks of messaging substitution between them.

As Internet access and apps have appeared on mobile phones, unsurprisingly we've seen an upsurge of both email and IM on devices. We've also seen a massive growth of other ways of sending messages such as push notifications, and especially in-app messaging for social, enterprise or gaming purposes. Quite often, we'll get the same message - or a notification - sent through multiple channels simultaneously, or to multiple devices, so there is rampant double-counting too.

There are actually three- or perhaps more - completely separate trends occurring:

1) SMS is losing its crown as the "standalone" mobile short-message platform of choice, because it is overpriced by around 100x, and hasn't evolved in feature-set in 20 years.
2) Standalone messaging is starting to diminish as it becomes easier and better to send contextualised messages
3) People only need any-to-any interoperable messaging when there's nothing better available. Most of the time, they're contacting friends or colleagues who'll have whatever app of choice works best in that group.

The key thing here is "purpose". SMS and email are (to a fair degree) general-purpose tools. Jacks of all trades and masters of none. An SMS can be a notification of a delayed flight, directions to meet your friend in the pub, a spam advert, or a way to send configurations & settings to your phone. Emails are similarly diverse.

General-purpose tools are fine when specialist tools are unavailable, expensive or inconvenient.

Do you think anybody would use a Swiss-Army Knife to open a bottle or cut a log, if the person had a magic app on their phone, or in their browser, that could instantly manifest a proper corkscrew or saw, at zero extra cost?

Moreover, would anyone other than Victorinox & Leatherman care about the demise of the pocket multi-tool market? Would they be stupid enough to try to create a new "Rich Tool Suite" standard between them, with interoperable and modular scissors and blades that could fit into a new generic multi-purpose tool body? And would industry analysts start adding together manifestations of tweezers and hacksaws to try to draw numerical comparisons with the legacy multi-tool market?

Just as I've previously mentioned that there is no "video" market, and increasingly no single "voice" market, there is already a clear fragmentation in messaging as well.

Yes, for any given use-case there are overlapping Venn diagrams which demonstrate substitution. I can tell my friends which pub I'm in using SMS, Facebook chat, WhatsApp or Twitter DMs if I wanted to. I could send my signed & scanned NDA to a client via email, Dropbox - or even fax or by mail.

Adding together some arbitrary subset of messaging tools - SMS + OTT apps, for example - but missing out push-notifications, emails, HTTP in-browser IM and so forth AND neglecting to de-duplicate where single messages...

... are cut into...

... chunks for convenience & readabilty...

or where the same message is sent & notified by multiple paths, just means that the data is spurious and the analysis sloppy. You never see any segmentation of messaging by purpose, except perhaps for person-to-person vs. app-to-person.

Any worthwhile analysis would look at various ways to slice up this supposed monolithic market into separate buckets reflecting context or intent. Perhaps social messaging vs. advertising vs. standalone information vs. gossip vs. B2B meeting arrangement vs. one-way app updates. Or sliced by length of a messaging "session" or number of participants, or a hundred other ways.

That type of analysis would also point out why the rhetoric around RCS and Joyn is a mistake. The market for general-purpose messaging is fragmented, declining in relevance, and simply not going to be very valuable in the future. WhatsApp's 1$-per-user-per-year price point is a good indicator of where it's going. Operators ought to be segmenting the messaging space by intent and developing laser-like tools where they can differentiate, not wasting time and resources on creating a lowest-common denominator Rich Tool Suite with the added costs and politics of IMS and vendor hype.

Moreover, the random selection of "capabilities" in RCS is the same set of pointless ideas for services that have been around for at least 10 years. "See what I see", "File Transfer", and old-fashioned and useless forms of presence? That's Yahoo Messenger from 2003, not a modern mobile communications app - see Vine's video clips, or Facebook's chat-heads, or WhatsApp's "last seen online" for some ideas about application *design* rather than engineering.

The irony is that the telecoms industry has been greedily absorbing $100bn+ a year from SMS and MMS, yet has plowed back almost zero into R&D and messaging application design. No sympathy or regulatory recourse whatsoever is due for telcos, as that market collapses - it has been a dead man walking for years. It has been neglected by companies asleep at the wheel and unwilling to innovate - there isn't even an easy "report as spam" function, or a way to switch to whitelist-only.

To be honest, I think WhatsApp and its peers will face challenges too - not only is it targetting a standalone messaging market that will implode in value, but it's doing so with constraints like using phone numbers as identifiers. That's already looking clunky in a multi-device user world, especially where many are WiFi-only.

Just as with voice communications, it is wrong to think of messaging as a meaningful and homogeneous "market". In most cases, messages will be sent as a feature or function of something else, not as a "service". There will be diminishing need - and diminishing value - in standalone, general-purpose applications. The true value will lie in many separate areas and business models, reflecting the myriad reasons why people or machines want to send messages in the first place.

So stop talking about the "messaging market", stop counting messages and drawing faulty conclusions from easy/lazy-to-quantify numbers, and start thinking about Purpose, because that's where the value lies.