New: Future of Video & RTC Workshop Series, starting May 19th

 "Why do people make phone calls?"

... the opening question at my old Future of Voice workshops. 

 It stumped many attendees and also many of my telco consulting clients during private engagements.

Most just looked blank, or perhaps suggested "to speak to people?". To be fair, the answer isn't obvious. Which is rather odd, given the need or desire for phone calls is the basis for the entire industry.

Few people think broadly about "purpose" of communications. What is the participant trying to achieve? How does the service or application help them do that? How can it be improved? What are the real sources of value?

In reality, there are 100s of uses for phone calls: To get information. Catch up with a friend. Buy something. Complain. Get help. All deserve a different, optimised experience. Yet a phone call is basically a one-size-fits-all, common denominator product. 

Telco's don't do "voice". They just do "telephony" - a single 140-year old, clunky, unnatural, heavily-regulated voice applications

Instead, they should have considered the 1000s of types of voice communication that are NOT phone calls. Audio chat, push-to-talk, karaoke, voice assistants and so on. All designed for particular purposes, with user-interaction models and technology stacks. Some dependent on the network, some on apps, some on devices, some in learned human behaviour.

The same is happening now for video. It's more than just video conferencing.

It's training, collaboration, security, education, medicine, machine vision, infra-red, social broadcast or 1000s of other uses, applications & business models.

There are platforms, enablers & APIs. Developer tools & design & test capabilities. WebRTC is important but not alone.

If telcos, service-providers, cloud/platform players, developers, enterprises and investors really want to understand the value and timelines for future communications - they need to ask the real questions. Not get blinded by ancient standards, or regulatory mandates to measure things in "minutes".

RTC (realtime communications) is getting more complicated, diverse - and has huge opportunities, as well as risks to incumbent providers of old/poor products. We all know which are the good/bad WFH conferencing products, or messaging services these days. 

What does the future bring? New models for UCaaS & cPaaS? Innovative video services for the smart home? New audio drop-in chat apps? AR/VR conferencing? What are the impacts of 5G, edge-computing and AI?

So I'm announcing: 

A new 3-part / 2-timezone "Future of Video & RTC" workshop series with WebRTC maven Tsahi Levent-Levi from May 19th. Early-bird rates end soon.

 

Sign up here.

 

Interoperability is often good – but should not be mandated

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

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

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

Background & history

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

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

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

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

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

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

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

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

Hybrid, competitive markets are optimal

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

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

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

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

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

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

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

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

Coexistence vs. interoperation

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

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

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

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

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

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

Where does government & regulatory policy fit in this?

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

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

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

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

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

Open RAN may be incentivised, not mandated

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

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

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

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

No, message apps should not interoperate

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

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

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

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

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

Conclusion

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

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

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

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

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

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

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

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

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

Voice: So much more than Phone Calls

 [Originally published on LinkedIn. Please subscribe to my new LinkedIn Newsletter here]

Trivia Question: When was the first example of network-based music streaming launched?

I'll bet many of you guessed that it was Spotify in 2006, or Pandora in 2000. Maybe some of you guessed RealAudio, back in 1995.

But the actual answer is over a century earlier. It was the Théâtrophone, first demonstrated in 1881 in Paris, with commercial services around Europe from 1890. It allowed people to listen to concerts or operas with a telephone handset, from another location across town. It even supported stereo audio, using a headset. It finally went out of business in the 1930s, killed by radio. Although by then, another form of remote audio streaming - Muzak, delivering cabled background music for shops and elevators - was also popular.

Why is this important? Because these services used "remote sound" (from the Greek tele+phonos) over networks. They were voice/audio communications services.

Yet they were not "phone calls".

Over the last century, we've started to use the words "voice communications", "telephony" and "phone calls" interchangeably, especially in the telecoms industry. But they're actually different. We often talk about "voice" services being a core component of today's fixed and mobile operators' service portfolios.

But actually, most telcos just do phone calls, not voice in general. One specific service, out of a voice universe of hundreds or thousands of possibilities. And a clunky, awkward service at that - one designed 100+ years ago for fixed networks, or 30+ years ago for mobile networks.

*Phone rings, interrupting me*

"Hello?"

"Oh, is that Dean Bubley?"

"Yes, that's me"

"Hi, I'm from Company X. How are you today?"

"I'm fine, thanks. How can I help you?"

... and so on.

It's unnatural, interruptive and often unwanted. A few years ago a 20-something told me some words of wisdom "The only people who phone me are my parents, or people I don't want to talk to". He's pretty much right. Lots of people hate unsolicited calls, especially from withheld numbers. They'll leave their phones on silent. (They also hate voicemails even more).

I used to go into meetings at operators and ask them "Why do people make phone calls? Give me the top 10 reasons". I'd usually get "to speak to someone" as an answer. Or maybe a split between B2B and B2C. But never a list of actual reasons - "calling a doctor", "chatting to a relative", "politely speaking to an acquaintance but wishing they'd get to the point".

Now don't get me wrong - ad-hoc, unscheduled phone calls can still be very useful. Person A calling Person B for X minutes is not entirely obsolete. It's been good to speak to friends and relative during lockdown, or a doctor, or a bank or prospective client. There's a lot of interactions where we don't have an app to coordinate timings, or an email address to schedule a Zoom call.

But overall, the phone call is declining in utility and popularity. It's an undifferentiated, lowest-common denominator form of communications, with some serious downsides. Yet it's viewed as ubiquitous and somehow "official". Why do web forms always insist on a number, when you never want to receive a call from that organisation?

Partly this relates to history and regulation - governments impose universal service obligations, release numbering, collect stats & make regulations about minutes (volume or price), determine interconnect and wholesale rates and so on. In turn, that has driven revenues for quite a lot of the telecom industry - and defined pricing plans.

But it's a poor product. There are no fine-grained controls - perhaps turning up the background noise-cancellation for a call from a busy street, and turning it down on a beach so a friend can hear the waves crashing on the shore. There's no easy one-click "report as spam" button. I can't give cold-callers a score for relevance, or see their "interruption reputation" stats. I can't thread phone calls into a conversation. Yes, there's some wizardry that can be done with cPaaS (comms platforms-as-a-service) but that takes us beyond telephony and the realm of the operators.

Beyond that, there's a whole wider universe of non-call voice (and audio) applications that operators don't even consider, or perhaps only a few. For instance:

• Easy audioconferencing
• Push-to-talk
• Voice-to-text transcription (for consumers)
• Voice analytics (e.g. for behavioural cues)
• Voice collaboration
• Voice assistants (like Alexa)
• Audio streaming
• Podcasts
• Karaoke
• One-way voice / one-way video (eg for a doorbell)
• Telecare and remote intercom functions for elderly people
• Telemedicine with sensor integration (eg ultrasound)
• IoT integrations (from elevator alarms to smartwatches)
• "Whisper mode" or "Barge-in" for 3-person calls
• Stereo
• De-accenting
• Voice biometric security
• Data-over-sound
• In-game voice with 3D-positioning
• Veterinary applications - who says voices need to be human?

There are dozens, maybe hundreds of possibilities. Some could be blended with a "call" model, while others have completely different user-interaction models. Certain of these functions are implemented in contact-centre and enterprise UCaaS systems, but others don't really fit well with the call/session metaphor of voice.

I've talked about contextual communications in the past, especially with WebRTC as an enabling technology, which allows voice/video elements to be integrated into apps and browser pages. I've also written before about the IoT integration opportunities - something which is only now starting to pick up (Disclosure: I'm currently working with specialist platform provider iotcomms.io to describe "people to process" and event-triggered communications).

But what irritates me is that the mainstream telecoms industry has just totally abdicated its role as a provider and innovator of voice services and applications. You only have to look at the mobile industry currently talking about Vo5G ("5G Voice") as a supposed evolution from the VoLTE system used with 4G. It's basically the same thing - phone calls - that we've had for over 100 years on fixed networks, and 30 years on mobile. It's still focused on IMS as a platform, dedicated QoS metrics, roaming, interconnection and so on. But it's still exactly the same boring, clunky, obsolescent model of "calls".

There was a golden opportunity to rethink everything for 5G and say "Hey, what *is* this voice thing in the 2020s? What do people actually want to use voice communications *for*? What interaction models and use-cases? What would make it broader & more general-purpose?" In fact, I said exactly the same thing around 10 years ago, when VoLTE was being dreamed up.

Nothing's changed, except better codecs (although HD voice was around on 3G) and lame attempts to integrate it with the even-worse ViLTE video and perennially-useless RCS messaging functions. The focus is on interoperability, not utility. Interop & interconnection is a nice-to-have for communications. Users need to actually like the thing first.

Some of the vendors pay lip-service to device integration and IoT. But unless you can tune the underlying user interface, codecs, acoustic parameters, audio processing, numbering/identity and 100 other variables in some sort of cPaaS, it's useless.

I don't want a phone call on a smartwatch - I want an ad-hoc voice-chat with a friend to ask what beer he wants when I'm at the bar. I want tap-to-record-and-upload of conversations, from my sunglasses, when someone's trying to sell me something & I suspect they're scamming me. I want realtime audio-effects like an audio Instagram filter that make me sound like I'm a cartoon character, or 007. (I don't want karaoke, but I imagine millions do)

So remember: the telecoms industry doesn't do "voice". It just does one or two voice applications. VoLTE is actually ToLTE. It's not too late - but telcos and their suppliers need to take a much broader view of voice than just interoperable PSTN-type phone calls. Maybe start with Théâtrophone 2.0?

This post was first published via my LinkedIn Newsletter - see here + also the comment stream on LI

#voice #telecoms #volte #phone #telephony #IMS #VoLTE #telcos #cPaaS #conferencing

If you're interested in revisiting your voice strategy, get in touch via email or LinkedIn, to discuss projects, workshops and speaking engagements. We can even discuss it by phone, if you insist.

How will voice be delivered on private 4G / 5G & CBRS networks? Private VoLTE?

An area I've seen little discussion about is the intersection of new private 4G / 5G networks, with voice and unified communications, UC. Most debate is about either local IoT (i.e. data) connectivity, or neutral-host / wholesale approaches for in-building or rural coverage.

But where enterprises deploy "pure" private networks aimed at employees or visitors, they are likely to want voice / telephony capabilities, plus more advanced communications capabilities. While this is already done for highly-specialised local cellular deployments for mines, military or maritime, it is much less clear how this could scale to more general enterprise users. 

Many of the existing local-cellular users are also just based on 2G/3G, for which simple circuit-switched infrastructure has been available for years (I had a client supplying softswitches for private voice with pico-cells, as early as 2006).

My view is that UCaaS, cPaaS, cloud telephony, IP-PBX & collaboration solution providers should be looking much more closely at the impact of CBRS, and its international equivalents, providing localised 4G/5G wireless in new spectrum, and neutral-host models. 

It is unclear whether enterprises will want to deploy "private IMS" solutions, cloud-based VoLTE & SMS, or use some simpler forms of wireless-capable VoIP in their own domain. There are various deployment scenarios I can see, each of which will require careful thought & focused strategies: 

• Transition from two-way radio (eg TETRA) to cellular push to talk
• Integration of existing UC/UCaaS/PBX with private cellular voice
• IoT integration of realtime voice/video (for example "speak to an engineer" functions)
• Fit with conferencing, collaboration & messaging platforms
• Interoperability / roaming scenarios with public PSTN & mobile calling
• cPaaS scenarios & APIs tailored for private mobile networks
• Will private 5G networks using slicing techniques to prioritise QoS for non-3GPP VoIP?
• For neutral hosts, how will they enable roaming telephony / messaging / other voice & video applications
• What happens with numbering & identity?
• Can private cellular work for contact centres?
• Are there "IMS lite" options for enterprise, that cuts down some of the features and integration seen in telcos?
• Is this a prime candidate for multi-tenant "VoLTE-as-a-service" cloud propositions?

I'm going to be watching this whole area more closely in coming months, as it seems to be rather overlooked, at least publicly. Given that a number of companies in the UCaaS / cPaaS space also have footholds in CBRS or mobile core networks (eg Amazon, Google, Twilio) it wouldn't surprise me if there's a lot going on beneath the surface here too....

(Please contact me if you're interested in exploring this domain, have existing solutions, or would like to engage me on private advisory work)  

#5G, #cloudcommunications, #neutralhost, #UCaaS, #cPaaS, #voice, #collaboration

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.

The rise of Managed Voice Infrastructure... or perhaps VIaaS or UCaaSaaS ?

Over the last year or so, I've watched the emergence of a new category of communication service - but it's quite hard to define a decent name for the trend.

In essence, it's where telcos/SPs offer some form of VoIP, either for consumer telephony or enterprise UC/hosted-PBX... but don't actually manage the infrastructure internally themselves. Instead, a vendor manages and delivers the capability via its own software/cloud-based platform. The SP sells (perhaps customising / integrating / bundling) the "outsourced" service to final end-users. It's not really the same as a straightforward channel play (eg resale of SaaS applications), because there's typically various network and OSS integration aspects, such as the need for SBCs, link with numbering and perhaps QoS, coupling with emerging NFV strategies etc.

The most prominent providers are probably:

• BroadSoft BroadCloud
• GenBand Nuvia
• Alianza Cloud Voice Platform
• Metaswitch MetaSphere Cloud Services

In addition to these, there are probably more that I'm not fully aware of. Alongside this, various other vendors are offering managed/hosted VoLTE, API/PaaS platforms and other applications (yes, even Jibe's hosted-RCS, now owned by Google) also intended to be offered through SP channels.

But for me, the main event here is service providers outsourcing their "core" telephony functions - including business-oriented comms which typically go beyond just voice - to vendor-controlled cloud platforms.

If you take the view that it's too difficult for SPs to develop their own innovative and differentiated consumer-voice or UCaaS platforms, then the next question is whether they really add any value by deploying their own servers for somebody else's application either. This is especially true for "vanilla" applications like PSTN telephony, SIP trunking and basic hosted-PBX functionality.

The answer is probably one of scale, risk-appetite, and the ability and willingness to attract software developers - as well as the target audience of end-users that a given SP faces. Larger operators ought to be able to have the resources to develop unique and well-customised propositions, even if they are based on a vendor's application platform or straightforward standardised telephony functions. 

Smaller providers - especially in rural areas - may find the idea of such hosted/wholesale offers more intriguing, especially as the cost-models may allow then to phase in such products over time without heavy upfront investmentment. 

In developing countries, the initial user-base for UCaaS might be very low as well - especially if broadband infrastructure is still being built-out and adopted by small businesses. Again, a wholesale offer might make sense, assuming the data-centres are close enough and long-haul links suitable.

There may also be a fixed/mobile divide here - it could be argued that residential fixed/cable operators have better things to focus on than infrastructure for delivering a commodity telephone service that few people use. Or, perhaps, mobile-centric operators may not have the ability and willingness to deal with the hybrid fixed/mobile nature of most UCaaS.

I think we're still at early stages here. Vendors are mostly being quite cautious, to avoid looking as if they compete with their SP customers, or are taking too much of the available profit-pool in that sector. Yet as NFV matures, both telephony and UCaaS do start to look a bit more like today's other SaaS offers - which can be hosted in telcos' own data-centres, but are more often anchored in Microsoft's or Amazon's.

It's also hard to come up with a pleasing category-name for this. Some people have suggested "wholesale telephony", but that's too closely-similar to various other traditional bits of the wholesale/transit market. "White-label voice & UC" is another option, but I've spoken to some people who recoil from that. "Cloud voice" can apply to about a dozen separate intersections of communications and cloud, so is too vague in my view. For the business side, I quite like UCaaSaaS but that's too much of a mouthful, although it looks fun on screen.

Maybe "VIaaS"? Voice-Infrastructure as a Service? Or my current favourite: MVI, Managed Voice Infrastructure? Some will grumble that it makes the video and messaging/collaboration bits look like second-class citizens, but I think it perhaps captures the essence of what's occurring - and it also spans both consumer VoIP telephony and UCaaS.