Microsoft and WebRTC - well, this is awkward

**NEW Feb 2013 - Disruptive Analysis WebRTC report - details here**

I'm in two minds here.

It's deeply awkward for the "mainstream" WebRTC community that Microsoft appears to have demo'd cross-browser support first, using its alternative proposed standard, CU-RTC-Web.

(If you're new to WebRTC, it's worth noting that at the time of writing in January 2013, development of the "core" IETF standard is progressing, and browser support is improving, but there are still a lot of issues around stability and interoperability that need to be resolved. Notably, as far as I know, nobody has demonstrated a call directly between Chrome and Firefox browsers, both of which support early implementations of the standard. Microsoft arrived late to the party with a different and more flexible-but-complex technology which claims to fix some of the issues, and there is considerable hand-wringing about this. Some worry about a delaying plan to protect Skype, others fear fragmentation. A good articulation of the arguments is here).

On the other hand, it's easy to argue the "traditional WebRTC" corner: Having a single, easy-to-implement standard is essential for the vision of extending WebRTC to the mass of "normal" web developers, even if VoIP/video specialists and some enterprise IT developers would rather have a bit more flexibility in choosing codecs, managing the vagaries of the network and so forth.

The current argument for the draft WebRTC standard is that web-developers will be "disenfranchised" - or at least deterred - by more complex options like CU-RTC-Web, which give more choices and decisions, such as picking codecs rather than just using an "official" one.

But this is rather undermined by the fact they're also being disenfranchised by the current version, which is certainly not as easy to use as many hoped. A quick look on the Google or IETF forums, or on Twitter, shows that experienced developers are often struggling to get the technology to work properly. Yes, there's a lot of cool demos about - but relatively few "mature" products, and even fewer that are stable. And, it seems, none that are properly interoperable.

And if you look at who's doing WebRTC app development today, it is primarily "VoIP guys", either from Internet or enterprise or telco backgrounds. You can spot this easily, as they're debating about whether WebRTC enhances SIP's applicability, or makes it obsolete. These are communications experts, not Mr Average Web Developer. Again, there are some exceptions such as Wello (Tsahi Levent-Levi has a good interview here), but they are heavily reliant on 3rd-party frameworks such as AddLive's to make it work.

Indeed, the fact that the most vibrant bit of WebRTC at the moment seems to be the SDK/API guys (AddLive, Hookflash, TokBox/Telefonica, Voxeo Labs etc) who are ultimately just about "making it easy" for developers rather proves the point - it isn't that simple to begin with.

There don't appear to be many people playing with WebRTC who've never heard of, nor used, SIP. Yet that's the constituency it's supposed to appeal to. People who've never even considered putting real-time comms in their websites or apps, or who briefly considered it and then gave up because it was too hard.

It's all very well saying "look what you can do with just 5 lines of code!" as long as it actually works properly afterwards, rather than just being a wobbly demo that works long enough to get a video to put up on YouTube.

I'm not going to pretend that I understand all the politics going on behind the scenes. But what it comes down to, I think, is this:

Google, Mozilla and other supporters of the current IETF WebRTC standard need to *prove* that cross-browser development of web-apps is not just feasible, but easy. And soon. Like in the next few weeks.

Otherwise, there is a risk that others will start to ponder whether Microsoft has in fact got a good point. It's also worth noting that some of the more classical "telco" participants here (both operators and vendors) have a bit of a vested interest in minimising the ease - and maximising timelines - for widespread browser-to-browser WebRTC app development, as they ultimately make money from servers/gateways and services in the middle. If, or how, that plays out from a standards point of view is anyone's guess, especially as many are genuine enthusiasts, not Machiavellian schemers.

My personal view is that Microsoft is playing a clever game here: deliver something useful, but late. By forcing Google's hand on getting interoperability between browsers sooner, they are performing a useful service for the WebRTC community, which should earn them some grudging thanks. If that leads to a couple of elephants in the room being addressed - perhaps with elements of CU-RTC-Web - then they win as well. And if that forces a couple of bits back to the drawing board and causes a bit of delay, that's beneficial for Skype and other products.

**NEW Feb 2013 - Disruptive Analysis WebRTC report - details here** 

WebRTC - not just about browsers

At the moment, most observers' commentary about WebRTC involves asking about "browser support", which is understandable given that it comes under the HTML5 and W3C banner.

**NEW Feb 2013 - Disruptive Analysis WebRTC report - details here**

So we see support for WebRTC in the current "public" desktop versions of Google Chrome and - just this week - Firefox. The implementations could still be referred to as "early", but they're out there in real users' hands, not just developers using beta versions. (You'll also sometimes see references to WebRTC being "behind a flag" which means that it's available as an advanced feature if you fiddle around with settings).

Unsurprisingly, conversation then tends to turn to when WebRTC might be supported in Microsoft IE, Safari and so on, for PCs and Macs. Mobile browsers then tend to get discussed next, with mutterings about users' reticence to download and install second browsers on phones and tablets - generally, most "normal" users stick to whatever the phone is equipped with "out of the box" today. So then the predictions start to ponder when the Android browser might support WebRTC, people bemoan Apple's apparent slow pace of adoption ("hmm, they don't want it to compete with FaceTime"), or Microsoft's perceived slowness.

Actually, the picture is more complex than that, especially on mobile, but also on the desktop.

Looking at smartphones, there are actually 4 main possible paths for getting WebRTC support onto mobile devices:

• Support by the default browser that the phone ships with
• Support by a downloadable secondary/replacement browser (complicated on iOS because Apple doesn't allow a separate web-rendering "engine" - they need to be built around Webkit). Ericsson's Bowser is already out, and expect Chrome/Opera/Firefox etc in future as well.
• Support in the OS. This hasn't happened yet, but many expect to see native support for WebRTC APIs in the platform itself, allowing apps to exploit the capabilities, not just web-pages. I'm having lots of interesting debates about which OS vendors might do this first.
• BYOWebRTC approaches, where individual apps actually integrate WebRTC elements - media engine & all - typically provided by using an SDK from one of a growing number of providers offering APIs, cloud "enablers" and other building-blocks

All this is further clouded by upcoming web-based OS's like Firefox OS, BB10 and Tizen, where it's not entirely clear where the boundary is between OS and browser anyway. There's also no guarantee that future phones will always ship with the platform's "normal browser" - so for example Samsung could ship Galaxies with a tweaked version of the basic Android browser, use Chrome-for-Android instead, or even develop its own from the ground up. (There's also a small matter of supporting all of the WebRTC APIs, or just some of them).

Then there are some other wildcards - we may see WebRTC acceleration performed in silicon at some point (eg video codecs and media processing). Also - and I think I'm the first person to mention this - there's no reason that WebRTC needs to be confined to the browser or aftermarket apps on the phone. Maybe we'll see it crop up elsewhere, such as in email clients, enabling direct interaction with HTML5 emails inside the message. Standby for two-way video spam....

A similar is story is also true on the desktop, but I expect that browsers will "get there first" for the most part. So we could see downloadable applications (Enterprise softphones? Games? Skype? Outlook?) that incorporate bits of WebRTC rather than, or in addition to, their normal media engines. This would allow much tighter control of the experience than relying on browser tabs and windows, and probably make it easier to integrate comms with enterprise apps, security and assorted other features.

Overall, anybody asserting that WebRTC will only take off "when all the browsers support it" is missing half the story, especially on mobile. The reality is considerably messier - and should mean things happen a bit faster than they otherwise might.

**NEW Feb 2013 - Disruptive Analysis WebRTC report - details here**

Musing: exploiting under-used network capacity or plan quotas

One of the things I like about technology in general, and the Internet and increasingly mobile apps in particular, is the ability to find value in stuff that otherwise gets wasted.

Companies like AirBnB and assorted clones allow people to rent out their homes easily, when they're away.

WhipCar allows you to rent out your car when it's not being used.

eBay and Freecycle allow people to sell or donate unwanted goods.

OptionTown.com allows airlines to exploit unused "assets" like empty seats on flights (pay a small fee to get the empty seat next to you, or buy an option for an upgrade).

There are many more examples in a similar vein, sometimes aimed at helping business get incremental revenue to improve return on capital, and sometimes aimed at consumers to monetise their time or personal possessions. The latter can have an impact on suppliers, either by creating a more efficient second-hand market (and thus slowing "new" sales) or introducing alternatives and reducing achievable prices (eg hotel vs. home-rental).

But we're still not seeing the equivalents emerge in telecoms. Various companies have proposed ways to exploit quiet, uncongested networks, by distributing bulk data overnight, for example. To be fair, some telcos do dynamic pricing to encourage users to time-shift (or place-shift) their usage, but it's still all a bit clunky and rarely communicated or sold to users in an effective way.

And the other bucket of "value" is from the end-user perspective. Postpaid users - and increasingly prepaid accounts too - get offered large quotas of minutes, SMS's and data, much of which goes to waste. I'm surprised we haven't worked out ways to "scavenge" value from this somehow. I've often used the concept of "social tethering" to stir debate ("share up to 200MB a month with my Facebook friends when they're in WiFi range"), but not much has happened there either.

Given economic pressures on both telcos and consumers, one or both of these sources of efficiency will undoubtedly be tapped sooner or later. In my view, network operators need to push harder with exploiting their own under-utilised assets, as otherwise they will get caught out when end-users start their own secondary markets in unused minutes and MB.

Retrospective: My most-read posts of 2012

Just having a look through my Blogger stats to see which of my posts have been read the most from the past year. Because of RSS, people reading via email etc, these stats are never entirely accurate, but it's still interesting (for me at least) to see what's popular. It's also obviously the older posts that have had time to accumulate more views after the initial burst.

1. How to save NFC: Kill the idea of mobile payments

2. Some of my current thinking about RCS/Joyn

3. New report: 10 Reasons why the "toll-free" 1-800 apps concept won't work

4. Telcos will suffer because of "subscription myopia". WebRTC & WiFi don't need subs

5. The telecoms industry & a dual-dilemma problem

6. The concept of the "minute" is killing the phone industry

7. Mobile data growth - a thought experiment

8. Operator WiFi - Seamless is the wrong approach

9. The death of communications ubiquity - and why GSMA has got it wrong


10. Reverse-engineering Ericsson's mobile data numbers

11. Telefonica TUMe - the first salvo in full-scale inter-operator TelcoOTT warfare

 I'd also add in that my recent "Anti-Forecasts for 2013" is probably the fastest-growing recent post, while my guest post about Telcos/OTT on Acme Packet's blog is currently at #2 in their most-read list (#1 is about WebRTC - which is something I'm expecting to drive a lot of views here - although my Slideshare presentation on WebRTC is currently a long way behind the messaging one)

There really needs to be a "User tariff API" for developers

Generally speaking, app developers and website owners know what device you've got, what OS, and what browser. Furthermore, they know what country you're in, and a ton of other information from cookies or that you've filled in through registration. The more sophisticated companies can also work out how fast your connection is, and also already know if it's WiFi or cellular.

Using all this information, they can tailor their software or site to give a good experience - as well as using it to manage their own operational costs and resources.

But what they currently don't know is what all this is costing you, and how that might drive your preferences and behaviour:

• What data plan do you have? Unlimited or capped?
• How much data do you have left? When does the new month start? Are you in any danger of getting close to overage fees?
• What policies are in place? Bandwidth limits, peak/off-peak differences, certain things being blocked or charged extra?
• Are you a postpaid contract user, or a prepay user either with infrequent top-ups, or US-style monthly plans?
• Do you get unlimited telephony & SMS? Or do you get a "big bucket" you never use?
• Are you roaming (and do you roam often, and how much does it cost?)
• What international call destinations are included in the user's plan?

If developers had access to this information in a better (and ideally consistent) way, they could design an app's experience to work better for individual customers. They could suggest using WiFi for large downloads, or double-check that the user really wants to spend 30% of their monthly data use by streaming a movie. They could know if the user is happy to send SMS's via the app, rather than using alternative messaging options. They could potentially know if "carrier billing" for in-app payments was realistic, or whether it would use too much of the user's outstanding prepay balance.

They could work out whether it was better for person A to call person B - or vice versa, with the app setting up a dial-in. Or if the data connection was good (or cheap enough), use a VoIP app instead, or WebRTC if browsers or gateways support it.

In other words, they could make their apps or websites better, by personalising them to their users' network tariffs and spending preferences.

There are however a couple of obvious problems here. Firstly, there is a huge diversity of plans, with increasingly clever variables involved (time, date, location etc). Some of those will become dynamic over time, eg giving notifications of "happy hours" as a promotional tool. Secondly, customers often don't know or can't remember accurately what plan they've got. Lastly, telcos are going to be very hesitant to give a clean and convenient API that essentially enables better and smoother arbitrage plays, or allows customers to get "as close as they dare" to thresholds but not cross them.

For these reasons, I'm not expecting to see "official" tariff APIs from many operators. But it wouldn't surprise me at all if we didn't see intermediaries or third parties spring up, who have at least *some* of this data available - especially basic information about data plans and voice minutes.

There's probably a great two-sided business model here in fact - if you collected details about millions of users' plans and usage (and kept it updated), you could supply both developers with an API, and you could advertise better/cheaper/more suitable plans back to the users themselves.

I already know about several apps that monitor / help users control their data usage (Onavo, My Data Manager etc) but I'm not aware if any of them have developer APIs, or also watch voice/SMS plans too.

Ultimately, something like this might even help telcos' own efforts to sell things like "sender pays" - if a content company knew for certain that you didn't have enough data-allowance to download a movie (or were getting close to your quota), it might be more inclined to subsidise it for you. On the other hand, if it knew that you've got plenty to spare, it could also let you know not to worry.

Someone will get this right, I suspect - although possibly it would make most sense to bake into iOS, Android and other OS's, particularly for the telephony aspect. However, billing/OSS players like Amdocs or Ericsson or Convergys should give it some serious thought. It could also be a fascinating Telco-OTT play, with great synergies for whatever operator developed and hosted it - how much would you like to know what plans all your competitors' customers have?