No, the Metaverse is not the killer app for 5G

(This article was initially published on my LinkedIn Newsletter - click here to see the original, plus comment thread. And please subscribe!)

Let's stop the next cliche before it even starts.

Most knowledgeable people now roll their eyes in derision whenever they hear the words 5G and autonomous driving (or robotic surgery) mentioned in the same sentence. But the mobile industry's hypesters are always casting around for some new trope - and especially the mythical "killer app" that could help to justify the costs and complexity.

And as if on cue, the Metaverse - essentially a buzzword meaning a hybrid of AR/VR with the social web, collaboration and gaming - has captured the headlines.

The growing noise around Metaverse technologies - and especially Facebook's recent rebrand to Meta - is attracting a whole slew of bandwagon-jumpers. The cryptocurrency community has been the first to trumpet its assumed future role - perhaps unsurprisingly, since they tend to be even more fervent and boosterish than the mobile sector. But we're also seeing the online shopping, advertising and gaming worlds hail the 'Verse as the next big thing.

Next up - I can pretty much guarantee it - will be the 5G industry talking about millisecond latency and buying a "Metaverse network slice". We'll probably get the edge-computing crowd popping up shortly afterwards too. I've already seen a few posts hailing the Metaverse as the possible next big thing for MNOs (mobile network operators).

They're wrong.

The elephant in the room

If you've found this article without knowing my normal coverage themes, you might be surprised to read that the single biggest issue for connecting Metaverse devices and users will be real, physical walls.

If you go through Mark Zuckerberg's lengthy video intro to Meta and his view of future technologies, you'll notice that a high % of scenarios and use-cases are indoors. Gaming from your sofa. Virtual living rooms. Hybrid work environments blending WFH with in-person meetings, and so on.

This shouldn't be a huge surprise. The more immersive a technology is - and especially if it's VR rather than AR based - the more likely people will take part while seated, or at least not while walking around an outdoor environment with obstacles and dangers. Most gaming, and most business collaboration takes places indoors too.

And indoor environments tend to have particular ways that connectivity is delivered to devices. Generally, Wi-Fi tends to be used a lot, as the access points are themselves indoors, at the end of broadband connection or office local area network.

Basically, wireless signals at frequencies above 2-3GHz don't get inside buildings very well from outside, and the higher the performance, the worse that propagation tends to be. Put simply, 5G-connected headsets and other devices will generally not work reliably indoors, especially if they have to deliver consistent high data speeds and low latencies which need higher frequencies. We can also expect the massive push for Net Zero in coming years to mean ever-better insulated buildings, which will make matters even worse for wireless signals as a side-effect.

For sure, certain locations will have well-engineered indoor 5G systems that will work effectively - but software developers generally won't be able to assume this. Airports, big sports venues, shopping malls and some industrial sites like factories will be at the top of the list for these types of solutions. For those locations, 5G Metaverse connections may well be widely used and effective. However, those are the exceptions - and it will take many years to deploy new in-building systems, or upgrade existing infrastructure anyway.

In particular, most homes and offices will have patchy or sometimes no 5G coverage, especially in internal rooms, elevators or basements. (There might be a 5G signal or logo displayed on the device, but that doesn't mean that the famously-promised gigabit speeds or millisecond latencies will actually be deliverable).

In those locations, expect Metaverse devices to use Wi-Fi as a baseline - and increasingly the Wi-Fi 6/6E/7 generations with better capabilities than previous versions.

What the Meta video tells us

I'm aware that the Metaverse is more than just Facebook / Meta, but the 1h17 video from Zuck (link) is not a bad overview of what to expect in terms of experiences, devices and business models. Obviously there will be different views from Epic Games, Microsoft's various initiatives around Hololens and Mesh, plus whatever Apple is quietly cooking up, but this is a decent place to start.

The first thing to note is the various Horizon visions that Meta is pitching - Home, Worlds and Workrooms. These are (broadly) for close social interaction, gaming/larger-scale social and business collaboration - especially hybrid work.

Mostly, the demos and visions are expected to take place from the participant's home, office, school or similar venue. There's a couple of outdoor examples of enhanced sports, or outdoor art/advertising as well. Virtual desktops, avatars that mimic eye and facial movements and so on.

In terms of devices, there's a large emphasis on headsets (obviously the Oculus Quest, and also the new high-end Cambria device promised for 2022) as well as discussions of AR glasses, from the RayBan Stories recently launched, to a forthcoming project called Nazare.

The technology discussion is all around the functional elements, not the connectivity. Optics, sensors, batteries, displays, speakers, cameras and so on. There are developer tools for hand and voice interaction, and presence / placement of objects in the virtual realm. There's lots of discussion around creators, advertising and the ability to own (and interoperate) virtual avatars, costumes and furniture. There are also nods to privacy, as would be expected.

There's no mention of connectivity, apart from noting that Cambria will have radios of some sort. The section on the "Dozen major technological breakthroughs for next-gen metaverse" doesn't mention wireless, 5G or anything else.

It's worth noting that Oculus devices and the RayBan glasses today use Wi-Fi. We can also expect the gesture-control in future will likely lean on UWB sensors. Outside of Facebook / Meta essentially all of today's dedicated AR/VR headsets connect with Wi-Fi or a cable, to a local network or broadband line. (That might be 5G fixed-wireless to the building for a few % of homes, but that will still use Wi-Fi on the inside).

Where cellular 4G/5G takes a role in XR is where the device is tethered to a phone or modem, or is experienced actually on the smartphone itself - think Pokemon Go, or the IKEA app that lets you design a room with virtual furniture.

We can expect the same with the Metaverse. If you're using a smartphone to access it, then obviously 5G will play a role, just as it will for all mobile apps in 3-4 years time when penetration has increased.

Will Cambria and future iterations feature 5G built-in? Maybe but I doubt it, not least because of the extra cost and engineering involved, as well as multiple versions to support different regional frequency options. Would a future Apple AR/Metaverse headset feature cellular, like some versions of the Watch? Again, that's possible but I wouldn't bet on it.

In the second half of the decade, later versions of 5G (Release 17 & 18) will have useful new features like centimetre-accuracy positioning that could be useful for Metaverse purposes - but again, that's reliant on having decent coverage in the first place. There will likely be some useful aspects outdoors though - for instance accurate measurement of vehicles on roadways.

Facebook Connectivity becomes Meta too

One other thing I noticed is a reference on LinkedIn to Facebook's often-overlooked Connectivity division, which does all sorts of interesting programmes and initiatives like TIP (which does OpenRAN and other projects), Terragraph 60GHz mesh, Express Wi-Fi and the low-end Basics "FB-lite" platform for developing markets with limited network infrastructure.

Apparently it's now being renamed Meta Connectivity - partly I guess because of the reorganisation and rebranding of the group overall, but also as a longterm part of the Metaverse landscape.

To me, that also indicates that the Metaverse is going to use multiple wireless (and wired) technologies - which aligns with Zuckerberg's view that it's more of a reinvention of the Internet/Web overall, rather than a particular app or experience.

Bandwidth-heavy? Or perhaps not....

One other thing needs to be considered around the Metaverse and connectivity. The immediate assumption is that such a "rich" environment, either full-virtual or overlaid onto a view of the real world, will need lots of data - and therefore the types of bandwidths promised by 5G. If we all use Metaverse devices to project "virtual TV screens" onto virtual surfaces, it will use lots of capacity, supposedly.

But it strikes me that avatars (even photo-realistic ones) & 3D reconstructions of real-world scenes will likely need less bandwidth than actual video. Realtime rendering will likely be done on-device in most cases, just sending the motion/sensor data or metadata about objects over the network.

Clearly this will depend on the exact context and application, but if your PC or phone or headset has a model of your friend's virtual house, or your virtual conference room - and all the objects and people/avatars in it - then it doesn't actually need realtime 4K video feeds to show different views.

In addition, the integration of eye-tracking allows pre-emptive downloads or actions, so "pseudo-latency" can seem very low, irrespective of the network's actual performance. If the headset sees you looking at a football, it can start working on the trajectory of a kick 10's or even 100's of milliseconds before you move your virtual leg.

That said, the sensor data uplink & motion control downlink will need low latency, but I suspect that will be more about driving localised breakout and peering rather than genuine localised compute. If you're in a hybrid conference with distant colleagues, the main role for edge-computing is to offload your data to the nearest Internet exchange with as few hops as possible.

(Some of the outdoor scenes in the Meta video from Connect seem rather unrealistic. They show groups of people playing table tennis and a virtual basketball match with "friends on the other side of the world", which would involve some interesting issues with the speed of light and how that would impact latency.)

Conclusion

In a nutshell - no, the Metaverse isn't the killer app for 5G.

The timelines align between the two, so where 'Verse apps are used on smartphones they'll increasingly use 5G if it's available and the user is out-and-about. But that's correlation, not causation. Those smartphones will typically be connected via Wi-Fi when at home, school or work. I suspect the main impact on smartphones will be on the need for better 3D graphics capability and enhanced sensors and cameras, rather than the network side.

Will we see some headsets or glasses with built-in cellular radios, some with 5G support? Sure, there will certainly be a few emerging in coming years, especially for enterprise / private network use. I'd expect field-workers, military, or industrial employees to exploit various forms of AR and VR in demanding situations well-suited to cellular, although many will tether a headset or glasses to a separate modem / module to reduce weight.

Many devices will also include various other wireless technologies too - Wi-Fi, Bluetooth, maybe Thread/Matter, UWB and so on.

But if anything, I suspect that the Metaverse may turn out to be the killer app for WiFi7, especially for home and office usage. That doesn't mean that 5G won't benefit as well - but I don't see it as a central enabler, given the probable heavy indoor bias of the main applications. (I don't think that cryptocurrency or edge-computing are key enablers either, but those are debates for another day)

(This article was initially published on my LinkedIn Newsletter - click here to see the original, plus comment thread. And please subscribe!)

#Metaverse #Facebook #Meta #AugmentedReality #VirtualReality #5G #WiFi #MixedReality #Mobile #Wireless #Devices #Gaming #Collaboration #HybridWorking

Microsoft / LinkedIn helps kill the phone number as a primary B2B identifier

I'll keep this focused, as there will be hundreds of articles dissecting the MS / LI acquisition that will no doubt cover most angles.

For me, the key element is that LinkedIn has one of the only "identity spaces" that allows people from different companies to connect. The two other most-popular ID types, which cover company-to-company communications, are phone numbers and email addresses. Unlike those, LinkedIn actually has a functioning searchable directory, with real names and mutual-connection "opt-in" model to reduce spam. It also follows people from job to job.

Other options are very minor - some business-people connect via Twitter's messaging function, some have industry-specific IM systems like Bloomberg & Symphony in finance, and some interact via channels on Slack and similar services niche collaboration platforms. 

Three other identities stand out - Google ID (used for HangOuts and a few strange folk on G+), Skype, and Lync/Skype for Business. Some business-people probably end up communicating via iMessage but that's usually triggered via an initial phone-number exchange, as is WhatsApp and pretty much all the other major mobile messaging services.

None of the other UC/UCaaS services from Cisco, Avaya, Unify, Mitel or Broadsoft-enabled operators really have their own inter-company addressing, directory and search/discovery function, although they can sometimes use specific federation techniques, or indeed integrate with Microsoft's Office365 and other systems.

If it can put the pieces together, Microsoft now has:

• LinkedIn's real-name addressing
• Outlook / Office365's ability to link email addresses to presence and Microsoft's own identity space
• Skype IDs for both consumers and individual business-people
• Phone numbers provided for SkypeIn and PSTN Calling in Skype4B
• WebRTC/ORTC for "guest access"
• Dynamics for CRM / sales automation

It is thus now the only company that can legitimately claim to control directories for both internal and external connections among business users, plus a fair number of consumers as well. It is already quite common for people to use LinkedIn as a surrogate contact database, when they cannot immediately find someone's phone number or remember their email address - especially when they move jobs.

(It should however be noted that LinkedIn tends to polarise opinion quite a lot - while it has a proportion of regular users who exploit it for networking, recruitment, groups and articles, it also has many members that have neglected profiles and limited active use. I'd been expecting LinkedIn to add realtime communications with WebRTC for some time but nothing has appeared - although it will be interesting to see if there's been anything behind the scenes that Microsoft will accelerate).

That has big implications for two groups:

• Telcos will see the role of the phone-number diminish further in a B2B context, as it becomes ever-closer to being just a lowest common-denominator fallback option. Added to its diminishing scope for B2C (because of in-messaging chat, app notifications etc), this doesn't augur well for E.164's continued primacy
• Cisco, Broadsoft and others need to think closely how to tie together inter- as well as intra-company connections. I'll be interested to see if Cisco tries to leverage its Apple relationship, or if the UCaaS platform-players try to lean on Google [Which has been cropping up regularly at events, pitching Android for Work]. We could also see attempts by competitors to federate their various cloud platforms - perhaps using something like Matrix.org as an intermediary.

This also puts the pressure on Facebook to step up with its long-promised enterprise offer, and means that any sign that Slack, HipChat or peers are gaining viral adoption will be greeted with enthusiasm (and perhaps acquisition offers). We will also see redoubled interest in industry-specific federated messaging in healthcare or finance or government verticals.

[There are also impacts on other companies like Salesforce in the CRM arena, but I'll leave that for others to discuss]

Of course, all this is contingent on Microsoft/LinkedIn gaining approval from competition authorities - and of course also assumes Microsoft can do a rather better job with integration than it managed with Skype in the first place.

But overall, this is hugely important - and has ramifications that extend across the business communications sphere, and may ultimately prove to be (another) nail in the coffin of the phone number & PSTN as the primary B2B identity-space.

Google buying Jibe Mobile is aimed at turning RCS into Android's iMessage

Like a lot of people, I was surprised by Google's acquisition of RCS specialist Jibe Mobile yesterday. Lots of theories were advanced on Twitter and blogs about this last night:

• Wow, Google is recognising that carrier standards, RCS and IMS are the future!
• Meh, it's an acqui-hire for people who understand messaging on Android
• Hmm, forget RCS device-side apps, Jibe offers cloud-based RCS servers to operators - it's Google's opening NFV play! (me)
• It's Google trying to get US carriers to push Android devices more, by acquiescing to demands for native RCS support (even if Google privately thinks it's rubbish)
• It's Facebook- and TenCent-envy. Google thinks it's missing out on messaging-as-social-platform as its previous efforts have been failures (also me)

On reflection I actually think there's a different story here. 

Forget telcos, the GSMA and 3GPP. Google buying Jibe Mobile isn't about carriers at all. They're a sideshow, or perhaps "useful idiots" in this scenario.

Google (I think) has three competitors in mind: Mostly Apple, but also Microsoft and Twilio.

First, let's step back. There are various uses for "messaging" apps on smartphones:

• Basic P2P or A2P text messages, ideally with features like read-receipts & pictures. And ideally free
• Enhanced messaging (not "rich") with better support for things like groups, white/black-lists, security, maybe "ephemerality" etc. Think of WhatsApp, BBM, Telegram and so on.
• Cool messaging (again not "rich" although they might use pictures or video) - things aimed at "lifestyle", flirting, self-expression, teenagers, and perhaps content streams. Instagram and SnapChat go here.
• Messaging as a platform, where users don't just send messages but can also use mini-apps or plug-ins inside the system for purchases or collaboration. WeChat and arguably Slack (in enterprise) fit in this category
• Messaging-as-a-feature, where messages get embedded into other applications or services via APIs, or are implemented natively. Twitter direct-messages are an example, but there are many others - perhaps even including iOS and Android push notifications.

These are imprecise categories. They overlap, and app providers try to push up from one type to the other - for example the content channels on SnapChat.

But right at the bottom of the list is basic P2P messaging. Traditionally the home of SMS (& MMS). It's been cannibalised in a lot of places by WhatsApp or close equivalents, although in places with flat-rate charging for SMS it's been more robust. But there is one important other player here: Apple iMessage, which gives an SMS-integrated experience built into iOS. iMessage is a well-designed, moderately "enhanced" version of SMS that is free between Apple users and has some better features (delivery notice & typing-awareness) than ordinary SMS whilst having a near-identical UI.

While Apple doesn't monetise iMessage, it makes usng iPhones a bit nicer. It does what the telecom industry should have done 10 years ago, and improved SMS without focusing on "multimedia" as a first step. It's the little things that count in messaging - ticks when someone has read something, an indicator that they're composing a reply and so on. Fripperies like file-sharing and "see what I see video" are irrelevant in 99.99% of use-cases. Get the basics right - usable texts & the occasional picture. Maybe an audio-message function for people with awkward languages that don't fit keypads & predictive text very well.

Now Google has had its own Hangouts messaging app on Androids in the past, which can be used as a default SMS app as well. But compared to iMessage, it hasn't been especially well-received, as it's optional. This means that Apple's automated and familiar green-becomes-blue messaging experience for Apple-to-Apple communications hasn't really been replicated in Android.

I suspect that acquiring Jibe Mobile (with RCS) is an attempt to change this. I think Google wants to use a service which handset vendors already accept being integrated "natively" to become its own free Android-to-Android messenger.

The fact that the mobile operators want RCS to be natively implemented is even better - Google gets the telcos to lean on all the handset OEMs to accept it. 

But of course, the devil is in the detail of the implementation. I suspect that a future version of Android will support RCS as a default app not because of its "richness", and not because of its "interoperability", but because it allows Google to compete with Apple on basic device-to-device enhanced and free texting. Messaging that goes via its own cloud most of the time, or which might interact with the telcos' networks either for "AndroidRCS-Out" or fallback to SMS. 

In other words, this turns RCS from being a "service" into being a basic messaging function within Android. It's not about "richness", either - video chat on Android will still be on Hangouts and via its WebRTC support 99.9% of the time. Google undoubtedly knows that RCS isn't really the basis of a "cool" messaging service either - I highly doubt it wants to compete with SnapChat, at least to begin with. It's not about lifestyle or messaging-as-platform - just a well-integrated way to do free basic messages.
 
So my views is that this is all about creating Google's iMessage, not a ringing endorsement of telco-run RCS or IPX or any of the other industry machinery. The telcos may get the scraps of RCS-in or RCS-out, most of which will be converted back to plain old SMS to terminate on iPhones, or older Androids.


There's also a secondary set of targets here, I think: B2C, B2B and A2P messaging. I'm sure that Google has noticed Microsoft linking Skype and Skype4Business and its other cloud properties. In future, businesses running Microsoft-powered UC or contact-centre software will be able to directly reach out to end-users via Skype, bring messaging, video, presence and so on. I don't think MS really cares so much about person-to-person Skype any more - it's nice, but not really monetised and faces lots of competition. But B2C Skype is different, if it entrenches Microsoft's enterprise platforms and gives businesses a rich (and free) way to talk to customers. Goodbye toll-free numbers, for a start. It also helps Microsoft become a more full-fledged UC player for internal enterprise communications.

I think that Google wants to do the same thing, linked to Google Apps for Work and other services. And having a native "AndroidRCS" (not "TelcoRCS") capability in every device will help. So perhaps, Jibe is intended to become Google's equivalent of Skype. And again, the likely majority scenarios would be internal within the Google ecosyste, plus a small minority of in/out to the telco (or enterprise SIP) domains.

Lastly, I wonder if this is an oblique way to compete with Twilio and a few other PaaS providers. Using a cloud-based messaging platform linked to a native client in Android gives a whole set of possibilities for developers to do free A2P messaging - basically a version of push notifications for people who don't have an app installed. Or easy, free web-to-device notifications (something missing in WebRTC when the user is outside the browser). And again, there is little reason to involve the phone networks except as exceptions or gateways to/from SMS on other devices.


In summary - this isn't a win for GSMA and RCS. It's not "fighting back against the OTTs". It's not going to suddenly revolutionise the market for messaging and promote the hoped-for renaissance of subscribers paying for "richness". It's not about video-chat or filesharing. It's not about QoS. It's not going to compete against SnapChat or Instagram or WeChat. (That traffic has gone to apps that are simply better and cooler. It might get a bit of basic text back from WhatsApp, but not much, as that's the cross-platfom winner in markets with a mix of Androids and iPhones).
I believe that, in fact, this is Google "stealing" RCS for its own purposes - free basic Android-to-Android messaging, with free B2C and A2P messaging to follow. It can vault into the big league with a billion AndroidRCS text users. The amount likely to touch the telcos' IMS's will likely be minimal. And the GSMA has done all the hard work encouraging the handset OEMs to support it. Thanks guys.

(And of course, there's also the very high probability that the whole thing is a total dud, or that users just ignore it, or only gets implemented in a sub-set of Android devices. Google's record here isn't great - think about Wave and Google+ debacles)

Dean Bubley & Disruptive Analysis specialise in analysing the future of voice, video & messaging, including VoLTE, WiFi-Calling, WebRTC and Contextual Communications. If you are interested in a private advisory workshop or project, please contact information AT disruptive-analysis DOT com

WebRTC, Microsoft/Skype, Apple & Google... some quick thoughts

I'm going to hold myself hostage to fortune here.

This week is the big WebRTC Expo event in San Jose in California. I'm moderating various panels and probably making a general nuisance of myself asking questions and picking everyone's brains about the trends they're seeing. But I'm going to risk making an analytical point in advance, and hope that the next 72 hours-worth of announcements don't make me look silly.

One obvious talking point - and probably presentation point - is around Microsoft's strategy, given its support for ORTC and the recent announcement of Skype for Web. There's also no doubt going to be a lot of talk about video codecs, and the IETF's cleverly-crafted compromise position.

But here, I just want to touch on something else. What exactly do the big ecosystem players want from voice/video/messaging, and how does that impact WebRTC? I've been stimulated by Tsahi's good analysis of the Skype/WebRTC plans, as it's made me realise something quite important:

Microsoft and Apple both seem to want to "own" certain aspects of communications services themselves, before throwing them open to all-comers via developer APIs.

Most obviously, Apple now has:

• FaceTime Audio & Video for "calls"
• Siri for voice-concierge capabilities
• Video/voice messaging inside the current iMessage
• iMessage itself for text messages
• The upcoming walkie-talkie function in its Watch ("for a fun alternative to phone calls!")
• Apple's push-notification service, which I think has the potential to seriously erode the A2P SMS market over time, especially if interactivity is enhanced

And Microsoft has:

• Skype for audio/video calls
• Skype for Business (ie Lync) for enterprise conferencing, IM & UC functions
• Cortana (voice concierge)
• Qik video-chat
• Messaging (former MSN, now integrated with Skype)
• Xbox Live Chat, Messaging & Parties
• Video Kinect
• Kinect Voice Command

In other words, both companies seem to view communications at least as much in terms of potential for complete products, as they do in terms of platforms.

Conversely, Google just has a few full-fledged communications applications:

• Hangouts (including Google Talk)
• Google Voice (US only)
• Google Now & Voice Control

(And Firefox has just done a deal with Tokbox to integrate WebRTC conferencing into Firefox as "Hello") 

In other words, Apple and Microsoft are perhaps delaying WebRTC (or seem a bit ambivalent), in part because they want to cherry-pick certain voice/video use-cases for their own branded applications, adding value to hardware devices like phones, wearables and game consoles as well as directly monetising via their enterprise activities. Google seems less-concerned (or perhaps less-capable) of deriving revenue from communications products directly.

It will be interesting to see if this week's WebRTC conference gives further weight and shape to this view.

Microsoft now definitely supporting ORTC / WebRTC

Big news today - Microsoft has officially confirmed that it will be implementing ORTC (Object Realtime Communications) in future versions of IE, and that it will be integrating it with Skype. It's not planning to support WebRTC 1.0 it appears, but that has been pretty clear for a long time. (At least, it's what I've assumed in my own forecasts anyway). ORTC has been labelled as WebRTC 1.1, although it's still not an "official" standard but a "community" enhancement.

Details are still only in outline. The most controversial aspect will be the support of H.264 video codec rather than VP8, although that's hardly surprising given that (a) there has been no agreement on mandatory codecs yet anyway, and (b) VP8 is obviously a very Google-centric technology. Given that Firefox is supporting both, and Apple is definitely an H.264 fan, some will find this annoying but hardly surprising.

My take has long been that a certain level of fragmentation is OK for most WebRTC use-cases and developers. It's a bit of a pain, but it's not the end of the world. Yes, there will be questionmarks about licensing / royalty fees, but if that's picked up by the browser supplier (or third parties like Cisco) that should be tractable. 

I'd expect most of the WebRTC cloud platform providers to support ORTC endpoints - which may mean that the cloud/gateway model of WebRTC gains even more traction vs. pure peer-to-peer use cases. (The cloud approach was growing anyway, as it's the main way to support WebRTC-type voice/video inside iOS and Android apps).

Frankly, the details are important but manageable. We can safely ignore the usual anti-Microsoft brigade's whining about this; Google has worked on the ORTC spec alongside Microsoft and Hookflash, and it is widely (albeit not universally) seen as a good approach, especially as WebRTC 1.0 uses an arcane approach called SDP (a legacy of SIP) to set up connections. 

There are still unanswered questions, which should hopefully get clarified in due course:

• Will ORTC pop up in IE12 or IE13 first? Will it initially be launched in beta, and under what conditions?
• Will ORTC support DataChannel properly?
• What happens with Lync? How does that fit into the ORTC/IE landscape?
• Might Microsoft support VP8 in a future release, anyway? Or does that depend on how the market evolves?
• When will ORTC make its way into Windows Phone, and how?
• Will Microsoft use its Azure cloud platform to offer WebRTC as some form of managed service to developers?
• What toolkits and support will Microsoft offer to developers for ORTC?
• Will we see WebRTC/ORTC support in Dynamics CRM, X-Box or other Microsoft properties?
• Does this limit the scope for 3rd-party IE WebRTC plug-ins (eg Temasys') or does it legitimise them, as a way of getting RTC capability into IE11 and below?

The bottom line is that this is a good day for the "democratisation of voice and video communications" - one way or another, most browsers from mid-2015 onward will be able to support embedded communications directly into websites. Given the various cloud platforms and plug-ins available to smooth the path for developers, this is yet another sign that WebRTC (including ORTC) is proceeding along the right path.

I'm maintaining my view that there will be upwards of 2 billion active individual users of WebRTC by 2019 - a large proportion of the overall Internet and smartphone app user-base. For more details about use-cases, strategic analysis of Microsoft's & Apple's roles, see my full report published recently. Purchasing details are here.

Quick thoughts from WebRTC Expo last week

I've already written about the telco aspects of the big WebRTC conference & exhibition last week.

This is just a quick summary of some of the other things that have stuck in my mind. It doesn't cover all the companies or trends I saw - a more holistic analysis will be included in forthcoming updates of my paid WebRTC research. Also, there were sections of the event (in multiple streams) that I couldn't attend personally - hopefully there will be other articles on healthcare apps, for example.

Top of mind themes emerging are:

• Customer service & call centre use-cases are everywhere, and definitely the most "commercial" part of WebRTC at present. The show featured a lot more integrated solutions, plugging WebRTC into existing platforms & industry structure - and adding in the power of the web in mashups for both agents & end-users. Various vendors had ways to analyse WebRTC speech, annote the agent's information via a browser etc. It all has an aura of "realness" around it, especially for finance and retail sectors.
• There's a whole range of other actually-deployed services, especially around distance-learning/training, video chat and conferencing. That said, a lot of UC and collaboration use-cases are more "now WebRTC-enabled!" rather than "designed from the ground-up for WebRTC".
• There's still a bit of a gap for innovative "pure WebRTC" use-cases that don't lean on traditional forms of communications, or just move beyond legacy telephony APIs. There's some fun music-jamming things, or a handful of games, but I haven't seen a (desktop) WebRTC-based equivalent of Chatroulette or anything clearly "viral". I'm also a bit perturbed that the adult industry seemingly hasn't bothered to turn up to the WebRTC party - usually it's first in line for any new web technology, and its absence is a bit of a puzzler.
• Where WebRTC innovation does turn up, it may well be in specific industry verticals. We know about finance and healthcare and real-estate demos and deployments - but I'm starting to wonder about government, media, utilities and so on. That said, an interesting chat at a separate event yesterday opened my eyes some possibilities around public safety.
• Many of the other use-cases are going to be heavily mobile-centric. This implies a need for 3rd party APIs/SDKs/platforms, as few consumer mobile apps use the browser, even on Android devices where WebRTC can be properly supported. On iOS, a 3rd-party approach is almost mandatory to embed voice/video into native apps. Purists complain that it "isn't proper WebRTC", but that's an irrelevant technical religious debate and doesn't detract from the opportunity. One company (Imagination) was even suggesting to rip out the Google/GIPS media engine from WebRTC and use theirs instead, as it's apparently mobile-optimised and can deal with the acoustic and silicon idiosyncrasies of smartphones better.
• Actually, the WebRTC purists (especially the "web" bit) were wincing a lot last week. Plug-ins are back with a vengeance, with at least 3 companies offering products. Temasys and Priologic had a bit of a barney about closed-but-free vs. open-source. I'm not a security specialist, but I can appreciate why tighter controls over what accesses the camera/mic are desirable. In my view, the purists have a lot more wincing ahead, as even if Apple & Microsoft adopt WebRTC (see below), both have millions of legacy version users who don't update.
• In a nutshell, RTCWeb (the IETF standard for nuts-and-bolts protocols) is looking ever-more important than WebRTC (the W3C API exposing all that stuff to web developers). Frankly, making the technology of nasty, complex bits of realtime communications infrastructure all work nicely, is rather more important than the precise way it's presented to developers. The "ends" of democratising voice, video & data into apps and websites and devices easily justify occasionally fudging the "means".
• For companies or developers that don't have longstanding communications expertise, the route to adoption of WebRTC is likely to be via one a platform / WebRTCaaS provider of some sort. There's a lot to choose from - some voice-centric, some video-oriented, some integrated with existing call centres or messaging, some more interested in QoS / scalability, some more around pre-built apps, some more mobile-oriented and so forth. Each developer will have to navigate a long list to see which are the best fits with their specific needs.
• Part of the problem is that some people read "MS & Apple don't support it" headlines and don't look beyond that. Most people I speak to don't realise what it is that all the WebRTCaaS API/SDK providers like Tokbox & Temasys & Requestec etc are actually doing. I think there needs to be a neater "category" and some serious evangelism - at the moment, I get the impression that the standards guys are a bit irked by their relevance and growing importance, just as they are with the SBC/gateway proliferation rather than P2P use-cases.
• The big discussion about silos vs. integration with legacy systems, via gateways, is largely confined to voice-primary uses, given that's what legacy telephony, UC and contact centres do almost exclusively. Video communications today is basically enterprise conferencing, plus Skype/FaceTime/Hangouts/consumer mobile apps. That's not to say that video-gatewaying won't be more important in future - and will likely need a lot of heavy-lifting infrastructure - but today, interop is about plain-old phone calls.
• Microsoft gave a presentation which (in a nutshell) said that (a) it's deeply engaged in this area, but (b) don't expect IE to support WebRTC 1.0 any time soon, except GetUserMedia APIs. There's a long list of other HTML5 bits & pieces waiting to be implemented by the IE team, so WebRTC has to battle for engineering resources against all of those, as well as undoubted pressure from Skype & Lync teams. However it appears ever-more enthusiastic about ORTC, which is showing so many signs of forming the basis of WebRTC 2.0, that various of the 1.0 advocates are getting a little irked at its jumping the gun.
• Various people were pessimistic/optimistic about Apple. "They won't bother", "But they joined the working group", "They'll wait for the standard" etc. In essence - nobody knows, everyone's got a theory. And we'll probably all be wrong. Happy to give you my own guesses if you want....
• Datachannel was around more as a "supporting actor" than as a headline act. Various use-cases had messaging or co-browsing or screen-sharing incorporated, but there seemed to be relatively few "pure" datachannel use-cases. I didn't see much M2M or IOT stuff around. A bit disappointing
• I think some people are getting impatient and expecting things overnight. It is only literally 3 years since WebRTC was even spoken about publicly - I remember it from the eComm in San Francisco in June 2011, the day before my & Martin Geddes' first Future of Voice workshop in Santa Clara. It's worth noting that with Snapchat/AddLive & the probable imminent arrival of WebRTC Hangouts, as well as various customer service functions, we're probably not far off 100m active users. Much as I hate  "Fastest growing web/comms thing EVER!!!!" articles, I could probably imagine writing one in a few months' time. Let's just put it this way - I expect there are already more active WebRTC users than RCS or VoLTE users, and it's certain to stay that way.

Overall, I'd say the Expo was more "grown up", with real use-cases, but perhaps a dearth of truly surprising "Web whiz-bangs". And I still haven't seen a WebRTC-enabled drone, despite the cavernous hangar-like venue used for the event being perfect for one.