Posts

RCS in Android and Its Impact On Messaging and Operators

Topic of the month covered by WebRTC “activists”

For this month the topic is: How will Google’s acquisition of Jibe Mobile and their plans to add RCS to Android devices impact the messaging market (OTT and operators) and does it have any impact on WebRTC?

Google acquires Jibe Mobile to bring RCS to Android

Starting with my opinion on this topic.

Amir Zmora

Link: TheNewDialTone

With the acquisition of Jibe Mobile and by adding RCS to Android, Google is bringing RCS back to life. Google is doing so because of 2 problems it has:

  • Google didn’t really succeed as it probably hoped with Hangouts. It is not the App of choice for users when they want to IM or voice/video chat with a friend.
  • Google is way behind Facebook in growth (%) of mobile advertisement revenue. Google is paying dearly for traffic acquisition on mobile. For example, Google is paying Apple to be placed as the default search option on iOS Safari.

Google hopes that launching a cross device, cross network RCS like service and giving developers the SDKs to use this service in their applications will make them a significant messaging player. If this happens, it will help them solve both of these problems.

I reviewed the gaps Google has in mobile advertisement revenue and provided some numbers of Facebook’s success in this space on my blog: http://thenewdialtone.com/googles-rcs-android/

Alan Quayle

Link: Alan Quayle

The arguments will continue to rage based on the religion of the person. From ‘Google is grave-robbing zombie technology’, to ‘see RCS will be everywhere, just wait one more year.’ In the limit two statements will hold true,  ‘Google does what’s best for Google’ and ‘only time will tell as Google is not perfect in execution.’ At the start of the year I called for an RCS reset, http://alanquayle.com/2015/01/time-rcs-reset/, read the comments, its a great summary of RCS with may heartfelt reviews. This is a RCS reset, I hope Google takes a pragmatic approach in making aMessage (Android’s version of iMessage) a federation point for all messaging platforms, not just those in a QoS-obssessed club.

Tsahi Levent-Levi

Link: BlogGeek.me

Google is an ecosystems company.

To that end, adding RCS to Android means making it as open as possible. This means:

  • It can’t be limited only to Android or even Chrome OS – it should be available wherever possible
  • It needs to put Google in a point of control – the aggregator/gateway of the messages

This acquisition places Google smack in the middle of two ecosystems:

  1. The carrier’s one, where they can offer inter connectivity
  2. The smartphone, where they now “control” a larger portion of the telco’s messaging part – and that control means better capability of affecting roadmaps of chipset vendors and OEM vendors

I’d expect it also to interwork with Google’s other puzzle pieces – Hangouts and maybe even Firebase or… Nest?

A long form article on it can be found on my website: https://bloggeek.me/android-rcs/

Mark Winther

Link: IDC

Jibe is positioned as Apple iMessage for Android.  For carriers who support it, the Jibe messaging icon is pre-loaded on the Android devices.  For Android to Android messages, it goes through the Jibe server rather than through the carrier’s SMSC so there are no messaging charges.  If the message is going off-net, i.e. to a non-Android device or to a user with doesn’t have the Jibe icon, it connects to the carrier’s server and incur normal SMS charges.

JIbe has had some success with European carrier and is pre-installed on Android devices in selected Deutsche Telekom, Orange, KPN, SFR properties.

With Google now backing Jibe, there is a potential to expand the Adroid native IP messaging opportunity.  But Google will be limited by carriers’ decision-making on how to offer this.  They could turn off the feature and force everybody to go SMS, or they could offer it as a separate messaging environement, but charge a small transit fee for the service.

Jibe has always worked with carrier and followed the carrier standards approach.  With messaging, this means integrating with the RCS standard, which has gained little traction so far.

If Google has intentions to leverage this into business messaging application which is the direction being taken by many major OTT chat apps today, it is little room to move.   The RCS specification lacks any framework for business or application-to-person messaging.   The RCS spec only enables traditional person-to-person messaging.   Additionally, RCS lacks enhaced GUI-type graphical interface.  Anybody who has looked at WeChat or FB Messenger lately know that they have very rich graphical interfaces.

Finally, it is worth mentioning that Google has powerful and proven resources for advertising and analytics.  Integrating Jibe messaging capabilities with the Google advertiting prowess could present carriers with a new means of monetizating the messaging business.

Dean Bubley

Link: Disruptive Analysis

70% chance that it disappears without trace, as they realise they don’t have enough lipstick to make the pig look attractive

20% chance that it turns into Google iMessage clone with limited RCSin/out as per my blog post http://disruptivewireless.blogspot.co.uk/2015/10/google-buying-jibe-mobile-is-aimed-at.html

9% chance that it’s repurposed for interactive advertising thing

0.9% chance it’s the basis of Google entering the NFV market

0.09% chance it’s something to do with Fi

0.001% chance it’s about the GSMA vision of RCS as a mainstream paid messaging service

Chad Hart

Link: WebRTC Hacks

I gave up on RCS and IMS long ago and I’m not sure if I should start caring again now. Perhaps the more interesting question is how much a company worth $456 Billion really cares about RCS?

Google has had 184 acquisitions, so how important in Jibe compared to the others, particularly the communications related ones:

  • Android – estimated at least $50M in 2005
  • Marratech – videoconferencing for $15M in 2007
  • GrandCentral – forming the core of Google Voice for $45M in 2007
  • Gizmo5 – SIP & XMPP client for $30M in 2009
  • GIPS which is the main engine in WebRTC for $68M in 2010
  • SayNow voice recognition used in Google Voice in 2011
  • Motorola for $12.5B in 2011

The acquisition price was not announced, but I would be surprised if Jibe ranked close to the average (excluding Motorola) here given their number of employees and the size of the RCS market.

Another question is if the acquisition of Jibe is somehow an indication that Google are doing something different with their real time communications strategy. WebRTC is clearly a huge part of Google’s strategy with numerous groups involved – Hangouts, Chromium, Chrome, Android, Chromecast, U-Proxy, Chrome Remote Desktop, Play Game Services, and likely many more coming. As it pertains to non-messaging capabilities, I suspect any expansion into RCS will cause an equal or greater increase in WebRTC traffic growth.

Schumann Sebastian

Link: Personal page

I think with the Jibe acquisition Google bought three things (from least to most important):

  1. The Jibe piece: Google bought an RCS backend instead of developing it themselves. It has apps as part of the deal and the native piece is implemented not only in their but also other OEMs devices (thanks to carriers’ push). Jibe has iOS/Android support and has also some general platform approach that fits Google (cloud). With all of this, they can act as “RCS provider” for users that lack native carrier support right away. This could be Google’s entrance door, since initially this group of users is the biggest of all.
  2. The RCS piece: They benefited from the connection of operators to help push other OEMs to implement native Joyn and is just taking advantage of that. It can work beyond apps – natively – and carriers will support this. If Google can manage to be the default backend for non-RCS carrier it could essentially have a service like iMessage not only on their own devices.
  3. The Hub piece: It owns now the component for interconnecting operators amongst each other and with their own backend. One can’t “just do RCS” and communicate with anyone who does as well all of a sudden. Carriers are interconnected 1:1 most of the time – with both technical but more importantly contractual agreements. The Jibe hub became (one of) the de-facto RCS interconnect (think GRX/IPX for RCS) solutions. Interconnecting carriers amongst themselves and perhaps eventually with Google’s platform may be an entrance door towards “free interconnect” (Google won’t pay for anything that isn’t SMS or telephony by the message or minute), so RCS is THE chance for a company like Google to get the foot in the door for that: carriers want to see RCS take off and might make compromises that may have a bigger impact than they think in the long term (not because of RCS itself, but applying it to the yet-so-lucrative legacy business perhaps).

I believe essentially Jibe’s mix of technology (cloud, clients, public cloud, hub) and also “political position” (interconnect provider, public cloud operator) what made the deal attractive I believe.

 

Rules of engagement for Topic of the Month: No product/company promotion. Contributors should have a wide market perspective.

If you would like to join this initiative and have your opinion published here in future posts please drop me a note.

Read more

What to hope for from the Alliance for Open Media

Topic of the month covered by WebRTC “activists”

For this month the topic is: With the announcement of the Alliance for Open Media what do you hope to see as the outcome of this and what do you view as a practical one.

Open Media

Starting with my opinion on this topic.

Amir Zmora

Link: TheNewDialTone

In April Dan Burnett & I talked about the NETVC initiative at the IETF. Now the Alliance for Open Media was announced and given the participating company it is fair to have hopes for good things to come out of it. Real-time communications and WebRTC specifically are just a narrow view of this much bigger thing, how will video run on the Web.

The challenge with video codes is twofold:

Business – avoiding the royalties and patent licensing costs. This is mandatory in today’s Web world as the cost may just kill new innovation that involve masses of users

Technical – having multiple codecs and support for only some of them based on camps (usually big companies) means there is a need for heavy lifting video transcoding

This is a good initiative but change will not come overnight.

Alan Quayle

Link: Alan Quayle

Fingers crossed for AOMedia, it may short-circuit the ‘Civil War’ WebRTC was facing in the coming years. In my work with telcos I make this point often, “the web has won, now get with the program.” Video transmission has a long history, hence there are lots of legacy business models. AOMedia has the potential to “get the video business with the web program.” And regardless, the video services I use are in AOMedia, so it really doesn’t matter what the legacy guys try to do, they have go where their customers go. The web has won.

Tsahi Levent-Levi

Link: BlogGeek.me

The Alliance for Open Media is a surprising and positive development. Who would have thought these rivals could come to terms about about something like video coding, doing it with a free royalties model attached to it. In order to make a dent, this alliance must attract the chipset manufacturers – they are the ones with the real work here as they need to include hardware acceleration for this new video codec in the process – something that Google’s VP8 was always criticized of lacking. I wrote a longer analysis of this topic here: https://bloggeek.me/webrtc-codec-wars-rebooted/

 Sorell Slaymaker

Link: Gartner

An opensource, royalty free, video codec that is robust and efficient is what the industry is looking for and the objective of this alliance.  While there is a high probability that this alliance will be successful, it will take 5-7 years to significantly displace the existing video codecs.  This is a long time in web years, so the industry will continue to have video interoperability challenges, which some businesses profit from.  The alliance should expand into areas outside of technology companies and include industries such as adult entertainment to help drive quicker adoption.

Read more

Peer-to-Peer Web and WebRTC, What’s So Special About It?

Topic of the month covered by WebRTC “activists”

For this month the topic is: Peer-to-Peer – WebRTC is one of the few peer-to-peer protocols in the web.  What can a peer-to-peer protocol offer over a client server one?

Peer-to-Peer Web

Starting with my opinion on this topic.

Amir Zmora

Link: TheNewDialTone

Wikipedia lists 3 major components of WebRTC, 2 of which relate to the peer-to-peer nature of it. The beauty of WebRTC stems from the combination of:

  • Peer-to-peer
  • Embedded in the browser
  • Standard APIs

With these 3, low latency applications can be developed and run on any supporting browser. Content distribution, real-time communication between people and multi-participant games are good examples. Being a technology, innovation depends on the implementers of the application. The technology is not more than a tool to implement the innovative service.

It is also important to note that WebRTC is not “more” peer-to-peer that VoIP protocols such as SIP, both sometimes need to rely on relay of the streams given symmetric NATs clients are behind.

Alan Quayle

Link: Alan Quayle

The peer to peer capabilities of WebRTC are cool, low latency communication of really anything. Check out this winning hack at TADHack Madrid from Carlos Verdes, Jaime Casero, and Carlos Torrenti called, PlayMyBand, https://medium.com/@carlosverdes/playmyband-webrtc-real-time-game-e65d8b66aed8. The actions of the players are immediate on the other screen. The great thing about peer to peer communication with WebRTC is its mandated to use DTLS-SRTP (Datagram Transport Layer Security Secure Real-time Transport Protocol). But as Alan Johnson, Dan Burnett and Mahak Patil (Digital Codex team) have highlight at TADHack, man-in-the-middle attacks are possible. As shown in their excellent demonstration https://www.youtube.com/watch?v=MOR2AYuRZ48, and how ZRTP (Zimmermann (its inventor) Real-time Transport Protocol) over WebRTC data channel can solve this, which is now an IETF drafthttps://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-02. This demonstrates the power of the web community to quickly plug holes as the community discovers them, and could make WebRTC a target for governments in their encryption ban crusade (https://en.wikipedia.org/wiki/Encryption_ban_proposal_in_the_United_Kingdom).

Tsahi Levent-Levi

Link: BlogGeek.me

WebRTC is about several orthogonal things:

  1. Access to the camera and microphone
  2. Ability to send voice and video in real time
  3. Ability to send arbitrary data as well as voice and video directly between browsers

Most use cases and value today is derived from the ability to send voice and video in real time – this is where obvious use cases reside. Most of them will work without the peer to peer nature of WebRTC. In some cases, though, the ability to do things directly between browsers, peer to peer is invaluable. Two important characteristics that come to mind:

  1. We’re reducing load from the servers, which allows us to scale our services better and at a lower cost. It opens up the road for more use cases and different business models
  2. It adds privacy to play, since the server isn’t privy to the interactions

What developers end up doing with it is what is really interesting.

Sorell Slaymaker

Link: Gartner

WebRTC’s peer-to-peer capability enables real-time voice and video to take the shortest path and keep the media bandwidth from having to go through a server.  As the number of devices that we utilize to communicate with scales, forcing all media to go through servers is not cost effective, especially HD video.  Plus peer-to-peer communication can be more secure, since there is not a centralized place for it to be monitored and recorded.

Video will be everywhere, so we can be effectively anywhere.  Real-time video is more exciting than stored video, just like watching a football game.  The Internet of Things (IoT) and social media will continue to drive real-time video.

One killer application that is at the cusp of taking off is remote monitoring.  Users remotely monitoring the things they care about – pets, property, family members, …

A WebRTC solution enables a low cost, secure way of providing video everywhere we would like to be.  ​

Dean Bubley

Link: Disruptive Analysis

P2P gives security, privacy, and unpredictability. Given the rise of unlawful surveillance from authoritarian and supposedly-democratic nations alike, this is increasingly important.

Rules of engagement for Topic of the Month: No product/company promotion. Contributors should have a wide market perspective.

If you would like to join this initiative and have your opinion published here in future posts please drop me a note.

Read more

In-context vs. out-of-context WebRTC communication. What fits where?

Topic of the month covered by WebRTC “activists”

For this month the topic is: In-context vs. out-of-context WebRTC communication. What fits where?

Contextual communication

Starting with my opinion on this topic.

Amir Zmora

Link: TheNewDialTone

You see an artwork in a store placed nicely with other items; you start imagining how great it will look at your home and you buy it. But, when placed at your home, in context different from the one in which you saw it in the store it looks different, usually not to the good side. The value of this item when it was part of a larger design among other items was higher. Once out of context its value dropped.

Same goes for communication, when being placed in context of a service it has higher value. In communication as a feature people don’t pay for the communication, they pay for the service in which it is embedded.

If all you are doing it offering the basic communication/collaboration capabilities you are competing with free services and that is not a good place to be in. So bad of a place many of those will not be around for long. If you are providing an API platform, it will have more value to specific segments if it will support requirements specific for that segment.

Dean Bubley

Link: Disruptive Analysis

There are at least three separate definitions of context that are emerging:

  • Communications IN a particular context: embedded into an app, a website, a thing and so on
  • Communications USING contextual data, about the users’ state and purpose, in order to be more effect. The data may come from their current web/app activities, sensors or other indicators of the external world, or analytics/big-data/mashups
  • Communications WITH context relates to metadata about the session/conversation itself, and can be used to hand off a call between people or channels, or link multiple instances into a single activity stream

The first of these is clear being driven by WebRTC as a principle enabler.

The second doesn’t generally rely on WebRTC, except if the data-channel is used as realtime transport for sensor or similar inputs. However, many of the communications use-cases involving contextual data will also be cloud/web/app-embedded, so the will often go hand-in-hand

The third is similar, in that it uses continuity servers or other cloud-based tools – and at least some of the channels or agents/users involved are likely to be using browsers & WebRTC as a components

All that said, a fair amount of WebRTC usage will be non-contextual – most obviously, where it is being used to extend an existing non-contextual service or function, eg “plain old phone calls” or standalone videoconferencing.

Alan Quayle

Link: Alan Quayle

Context is Not New

Contextual communications is not new. Back in 2000 there were start-ups using ancient technologies like WAP and J2ME to enhance incoming calls with information about the person or business calling scavenged from the web and databases, as well as the callers intention with the call. The callee was then given call treatment options, like reply by SMS with “go away and leave me alone,” or send to voicemail. The experience was crap, the ancient technologies were too slow, and the application versions ran into the tens of thousands.

Today many of us use contextual communications: we check IM to see if someone is available; we message them to ask if its OK to chat now about the price of eggs; we have conversations over IM where we share websites, videos and pictures without ever breaking into real-time voice communications. The OS enables us to use multiple platforms to communicate with people on their preferred application. For example, with Dean’s work persona (not the other ones) don’t use Google.

Within many business processes your identity opens up a history of interactions, even your recent browsing history is used to direct communications to most probably the appropriate agent. Context has become pervasive, and will continue to grow, mainly behind the scenes, in making communications fast, appropriate, and easy. And WebRTC’s role in contextual communication is one of the many enabling web technologies, just like HTTP.

Tsahi Levent-Levi

Link: BlogGeek.me

Context is the only way of making a living out of communications these days.

Messages, voice calls and even video calls – all of them are now expected by customers to be free. People are willing to pay for the context of specific calls – be it a business setting or a scenario where a doctor consultation is required.

That said, in many use cases, you can’t charge a customer for the context of his communications – it just doesn’t seem to be worth it. In such cases context gets coupled with analytics, and asymmetric business models, where advertising and other means of monetization are used.

Sorell Slaymaker

Link: Gartner

WebRTC will accelerate “Continuous” UCC.  Today, most communication is session by session, and does not provide continuity between sessions by carrying all the previous communication and associated information into the next session.  Continuity provides context, keeping participants from having to repeat previously communicated and shared information.  Cloud based solutions will also offer recording, transcribing, and meta-data tagging of communication sessions, providing advanced search and reporting capabilities.

Magnus Wester

Link: www.ericsson.com

As the area providing new values compared to previous solutions, in-context communication has been the driving force for WebRTC adoption. We have seen evidence of how this ability to integrate communication with information in various business processes delivers great value in our current enterprise engagements. The simplicity of deployment is of course another driving point. For end-users, not having to go through an installation process, but instead just clicking to communicate, is a very big value for most services. For out-of-context communication, the uniqueness of webRTC becomes less clear. Most of those deployments have been about “A calling B” cheaper than with traditional telephony. But, as operators are gradually shifting to a data-centric pricing model, that business incentive is rapidly disappearing. One can argue that the ease of innovation on top of WebRTC could also be a driving force for out-of-context communication. But in innovating separate “communication island use-cases”, are you not in fact creating an in-context solution in the end?

 

Rules of engagement for Topic of the Month: No product/company promotion. Contributors should have a wide market perspective.

Read more

WebRTC as a Web App, Native App or Anything In-Between

Topic of the month covered by WebRTC “activists”

For this month the topic is: Web App, Native App or anything in-between. Which is best for WebRTC and in what cases?

WebRTC-Mobile

Amir Zmora

Link: TheNewDialTone & WebRTCStandards.info (NEW)

WebRTC is being used on desktop and mobile mostly in a similar way to which users typically use services on these platforms. This means, web on desktop and native app on mobile. A few things to point out:

Desktop

  • Due to current lack of support for WebRTC in IE and Safari some use a plug-in for these browsers which means it is not a pure 100% web app but this should be viewed as a gap filler
  • The more interesting case for desktop I ran into is a company that built a mission critical financial service with WebRTC. Due to the frequent version upgrades of browsers and since they can’t really control browser upgrades on PCs of their customers they decided to include WebRTC in a desktop native app so they can test and guaranty its stability

Mobile

  • End goal of most companies is a native app
  • Due to priority and resource allocation many companies start with native app on iOS, browser on Android and only later build the app for Android
  • On Android some opt for a hybrid app using WebView that already has WebRTC built into it in latest version

Alan Quayle

Link: Alan Quayle

I’ve been using the Wire web app since February, app.wire.com. Its fast, slick, and elegant; I highly recommend you give it a go. The user experience is refreshing, the audio quality is amazing, and content loads fast.  WebRTC works well in this use case, its reliable and delivers nearly as good as experience as the the OS X app.  The gap has nothing to do with Wire, and everything to how web apps are presented. I loose the page, I mistakenly close the page, I mistakenly close the browser. Once web apps are presented in OS X like native applications, why would I ever want to go back to having to close applications and upgrade software? But how long until that gap is closed?

Tsahi Levent-Levi

Link: BlogGeek.me

As with anything else, it all depends on the use case.

That said, in most occurrences that I’ve noticed, the following rules of thumb apply:

  • Desktop is dominated by the web app in a “traditional” web browser
  • Mostly, that means an SPA (Single Page Application)
  • At times, a browser extension or a packaged app in the form ofChromium Embedded Framework is used. This means that the HTML5 SPA is just packaged as an executable – there is little benefit from “going fully native” with WebRTC on the desktop
  • Mobile is dominated by the app paradigm – with or without WebRTC
  • Today, most of it is native in nature, but more and more I see vendors who are trying to build cross platform HTML5 web apps and wrap them as mobile apps
  • More on approaches to mobile development in WebRTC can be found in myrecent report

Dean Bubley

Link: Disruptive Analysis

In general, WebRTC is better-surfaced as a web-app on PCs and via native app on smartphones. Tablets fall in-between, and other devices/IoT will vary case by case depending on how browsers are used anyway.

That is the key here – what is the *existing* role of the browser, and the associated user behaviour (& developer preferences). A taxi firm wanting to add a “speak to the driver” button isn’t going to re-write its entire existing native app as a webapp, just to enable feature #37. Or a user looking at a travel-booking website on a PC and big screen, or their company’s intranet, is going to be using a browser – so any real-time interaction is likely to be via the web.

Chad Hart

Link: WebRTC Hacks

All the above for most use cases. The great thing about WebRTC is that it has great development community across web and mobile, so you don’t have to worry about making the wrong choice. There are plenty of mainstream examples like Wire, Facebook Messenger, Google Hangouts that use WebRTC to support both web and native mobile.

Would mobile WebRTC be easier if it was built into native web views? Of course. At least Android 5 has it today. iOS still requires someone who really knows how to code for iOS, but if you are building a serious iOS app you probably have that anyway. I am looking forward to broader support coming for cross-platform tools like Cordova/Phone-Gap and Xamarian.

Schumann Sebastian

Link: Personal page

WebRTC as technology fits both; I’d make a distinction based on the angle we’re looking at. In both browser and native app real-time communication could be built prior to WebRTC, but with more efforts (time, money, development, licenses). WebRTC equally lowered that barrier and offers now a cheaper entry with high-quality media stacks. For “professional” developers WebRTC is just another tool for a certain problem.

What I found the most interesting so far is that for web development, the barrier is so low that for the first time, non-developers are able to build communications applications. This is fascinating hence I’d draw the line here to emphasize the benefits I’ve perceived myself. If you’re not a professional app developer WebRTC won’t be an immediate savior for building a native comm’s app, but for a non-pro web dev it is an easy enabler to start building cool apps with inbuilt high-quality audio and video communications in a few hours.

 

Rules of engagement for Topic of the Month: No product/company promotion. Contributors should have a wide market perspective.

If you would like to join this initiative and have your opinion published here in future posts please drop me a note.

Read more

The Impact of WebRTC on UC

Topic of the month covered by WebRTC “activists”

For this month the topic is: The impact of WebRTC on UC

Unified Communication and WebRTC

Starting with my opinion on this topic.

Amir Zmora

Link: TheNewDialTone

The word Unified in Unified Communications has nothing to do with unification of platforms. UC is all about bringing all your communication channels to one screen. The systems themselves don’t really talk one with the other natively, Lync, Avaya, Cisco, Broadsoft… all use standards based protocols with modifications that don’t let them interoperate out of the box.

WebRTC takes this one step further; it creates more islands of communication as it makes it easy to add UC capabilities as a feature in other applications – business applications, customer care, team collaboration and verticals.

And yes, UC vendors are adding WebRTC as an interface to their systems. Problem is that the applications and service providers mentioned above that are adding these features to their solutions have asymmetric business models that will allow them not to charge for the UC feature but for the service UC is embedded into.

Alan Quayle

Link: Alan Quayle

Does anyone remember the hype around ICA (Innovative Communications Alliance) between Microsoft and Nortel back in 2006? Unified communications was its focus, and here we are in 2015 using an ever expanding array of dis-unified communications. Presence remains the main gap in traditional PSTN, telcos and their vendors are to blame for that yawning gap, which drives us to lots of applications: Skype, WhatsApp etc. The application diversity being driven by the person we’re trying to communicate with and their preferences. So what impact will WebRTC have on UC? None. Because the problem is in federation of presence, not in the standardization of media codecs, and the lack of federation is driven more by commercial issues than lack of standardization.

Tsahi Levent-Levi

Link: BlogGeek.me

Unified Communication will struggle to compete with new vendors that will come into their space armed with WebRTC.

WebRTC reduces the cost and effort needed to develop UC systems drastically – to the point of commoditization. This race to zero means UC gets downgraded from a service into a feature that is plugged into some other service. Enterprise Messaging vendors are primed to take the leadership position from UC vendors, as they offer much more than mere real time communication capabilities.

Here’s a recent post I’ve written about the competition between enterprise messaging and unified communications.

Sorell Slaymaker

Link: Gartner

A couple potential use cases for WebRTC in UC:

–          Clientless Access to UC Suite – Utilizing WebRTC to access an enterprises UCC solution.  For example, a 3rd party accessing an enterprise Lync conference, w/o a Lync client, via an Audiocodes or Sonus SBC/WebRTC GW.

–          Least Common Denominator Video – Utilizing WebRTC to bridge different video platforms together in a cost effective way such as Starleaf integrating Lync and Jabber together via WebRTC.

Dean Bubley

Link: Disruptive Analysis

WebRTC will improve the usability and reach of UC platforms – but ironically, it will also have a much larger effect catalysing the trend of “disunification” of enterprise voice/video.

The world has 700m “knowledge workers” who use IT applications, plus 750m more that just use a phone for work. Yet today only a third use a traditional corporate “phone” or UC system. The rest use mobile telephony, cloud/app-based communications and a variety of consumer-grade VoIP and conferencing tools. WebRTC will reach both groups – and app/web developers embedding communications.

Disruptive Analysis forecasts 120m UC “seats” enhanced with WebRTC by 2019 – but 340m regular Disunified (DUC) users, exploiting fragmented cloud-based apps or services, “the best tools for each job”. Another 450m or so will use WebRTC occasionally – perhaps for one-off conferences or “guest access”.

nterprise user-base adoption of WebRTC

Chad Hart

Link: WebRTC Hacks

One of the more interesting aspects related to WebRTC in UC is the rise of Application IT. The larger trend of “build it yourself” that is prevalent in Silicon Valley startups could seriously eat into the traditional UC vendor market.  We are seeing more and more internal development groups look to take on communications capabilities leveraging WebRTC – both for customer facing applications but also to enable their own internal IT. For example, a Fortune 100 company we have worked with created their own video conferencing and collaboration platform that is tied into many of the other systems they have already created on their own. No traditional UC vendor involved.

Many of these groups have the skills to make apps for 10’s of thousands of your own employees and get millions of website hits a day. With WebRTC, how long will it take until they no longer need their UC vendor?

Schumann Sebastian

Link: Personal page

WebRTC in UC fits B2C more than B2B for now. Business/Customers communications will be simplified, since customers do not need any prerequisites to access the corporate UC. If a company decides to “open up” its UC, they make the necessary changes within their environment and it should be accessible from most “open Internet” accesses (consumers, smaller businesses). What will most likely not be affected is the communication with other larger enterprises. Federation today is mostly with predefined partners – with the need for changes on both sides. It is very likely that the other business has restrictions in place, too (e.g. browser installation, firewall restrictions, no plug-in permission for screen sharing). It is easy to ask IT for permission to install WebEx once, but several exceptions for several websites’ “proprietary” exceptions – not that likely.

Victor Pascual-Avila

Link: WebRTC Hacks

From what I see in my customers, main drivers for doing UC over WebRTC are:

  • Complement existing UC offerings (e.g. to provide mobility or user
    access when they are using their own devices/laptops from the
    internet)
  • Replace existing UC offerings (e.g. reduce cost of licenses)
  • Created tailored solutions (use web developers to implement the very
    right set of features they want to provide — some go beyond existing
    UC offering, some other included in UC offering are dropped)
  • Integrate with existing assets (support systems, user databased,
    process databases, in-house developed APIs, etc)

 

Rules of engagement for Topic of the Month: No product/company promotion, a short 700-800 character statement.

If you would like to join this initiative and have your opinion published here in future posts please drop me a note.

Read more

Which use cases for WebRTC will dominate in 2015?

Topic of the month covered by WebRTC “activists”

WebRTC is a dynamic segment with new services, announcements and rapid advancements of the technology.

There are several websites you can follow to stay current with these activities. WebRTC technology is covered in depth by WebRTC Hacks while standard updates are provided by Dan Burnett and myself at TheNewDialTone. Weekly updates about the WebRTC news and activities can be found at WebRTC Weekly by Tsahi Levent-Levi and Chris Koehncke and other updates and opinions can be found on several blogs, some of which are mentioned below in this post.

In this post and those to follow, I want to tackle one topic each month and bring to you the opinion of a few of the WebRTC “activists”.

For this month the topic is: Which uses cases for WebRTC will dominate in 2015?

WebRTC dominant use case for 2015

Most of the opinions presented below relate to B2C contact center type of use cases but there are different angles to this. Read below for details

Starting with my opinion on this topic.

Amir Zmora

Link: TheNewDialTone

Quantifying WebRTC usage by numbers is hard. Today, WebRTC is massively used in consumer OTT such as Hangouts and SnapChat. The most significant usage of WebRTC for consumer OTT in 2015 will come from WhatsApp assuming they start providing voice calling services.

On the B2B and B2C side, Amazon Mayday Button is a great example of a paradigm change in the Contact Center where conflict is between self service (don’t call us) approach, to enhanced engagement. We will see more of this in the financial and healthcare segments as well as team collaboration services such as Slack. What I’m really looking forward to see is what rabbit will Microsoft pull out of their hat with Skype for business as this has the potential to be the #1 use case for 2015.

Alan Quayle

Link: Alan Quayle

The flippant answer is Google, through Hangouts, Chromecast and all the other projects they have using or planning to use WebRTC in 2015.  But the more interesting answer is within businesses. I point to this case study of a “WebRTC Powered Travel Agency” presented by Yvan Wibaux Co-Founder & CTO Evaneos and Luis Quina Borges Co-founder & CEO Apidaze at TADSummit. A nice quote from Yvan is, “the power of communications to revolutionize the travel business.” The dominant use case in 2015 from a business impact perspective will be businesses transforming their operations with WebRTC to reduce human latency and improve communications associated with specific business processes. http://youtu.be/ADHBwQEGHSY

Tsahi Levent-Levi

Link: BlogGeek.me

The main use case we will see is the contact center. It is going through a technology transformation already, with concepts such as self service, omnichannel, big data and analytics changing what a contact center really is. WebRTC enables improving the contact center either on the agent side by virtualizing his system or on the customer side, by adding more flexibility and touch points.

Dean Bubley

Link: Disruptive Analysis

The key 2015 use-cases for WebRTC will be for enterprise B2C customer support, small workgroup collaboration/conferencing and consumer in-app video chat. B2C will involve WebRTC on the agent side (primarily on desktops specified by the IT function with suitable browsers), and to some degree among customers – although mostly via dedicated mobile apps, rather than “click-to-call” in a browser. Collaboration software will come in various sub-types, including screen-sharing and voice/video connectivity, targeting both general small teams, and specific verticals like software developers. Consumer embedded video-chat is evolving rapidly too, starting from social/messaging apps – both on desktop (eg Facebook) and mobile (eg SnapChat) – and likely extending to other areas such as gaming progressively.

Chad Hart

Link: WebRTC Hacks

Making the Most of the Server-side Media Conundrum

WebRTC is a great peer-to-peer technology that allows WebRTC apps and services to be deployed cheaply and reliably. Unfortunately peer-to-peer does not always work. TURN servers are nearly always needed to help with NAT traversal for a meaningful number of users. Media servers are needed for multi-party conferencing, broadcasting, and many other use cases.  These services use a lot of media – i.e. bandwidth – and bandwidth can quickly drive up your networking costs. So if you need to terminate media on your servers – at least some of the time – why not make the most of it to get some value back for your extra expense?  Recording, meta data analysis, and optimized routing are all good examples of this.

Sebastian Schumann

Link: Sebastian’s Personal page

I believe we will start seeing more “contextual use cases” from outside the Telecom’s industry. Here WebRTC will be used as a tool to deliver new RTC experiences where the value is not in the connectivity any more. It will be chosen because it will be considered as the best technology for this. From within the Telecom’s industry we will see more conservative use cases motivated by the knowledge about WebRTC and an urge to do “something” with it. Telecom’s will focus more on video, however, the use cases here will be rather generic and could have easily been done before. The industry will also continue to focus on classic “call” use cases (voice only, bound to E.164 telephone number, minute rating, etc.) as they start to open up their new IP core communications infrastructures.

Victor Pascual-Avila

Link: WebRTC Hacks

While service provider/operator folks have been trying to figure out what to do next with WebRTC following proof of concepts they conducted, during the second half of 2014 we have seen s lot of momentum on the enterprise/vertical markets. This is basically about eBanking, eLearning, eHealth and the popular kid in town is contact center access via WebRTC (in many cases also providing webrtc access to center agents). In 2015 we will see greater momentum in these verticals and service provider investments to serve their enterprise customers by deploying multitenant solutions for these segments.

 

Rules of engagement for Topic of the Month: No product/company promotion, a short 700-800 character statement.

If you would like to join this initiative and have your opinion published here in future posts please drop me a note.

Read more