Contextual communication

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.

3 replies
  1. Aswath Rao says:

    As Alan states, context is not new. But WebRTC affords some new twists and these twists enhances the utility of contextual communications. Traditionally, a communication session began within the communication platform and it then brought in business process related information to the communications session. This creates practical difficulties. The communication platform has been the slow moving and expensive component. So it dictated the interface to the component that was running the business process, which usually evolves rapidly. It was very limiting.

    But with WebRTC, we can use web technology to flip it around. If the business process is running on a web platform, the communication component is brought in as needed. Using iFrame embed technology (“in context”), the ability to launch an independent browser window (“context passing”) or the browser redirection using URL (“out of context”), the business process and communication session can take place as the needs suggest. Furthermore, the data passing between the two can be done in any style without any restriction or loss of functionality. This is the unique strength of WebRTC.

    I slightly differ from Dean’s claim. I think we can pass on data associated with “USING” & “WITH” scenarios through the URL; if not the full data, we can certainly pass on URLs where such information can be accessed.

    All in all not much attention has been paid thus far on the “web” nature of WebRTC. This is true even if native app is being utilized, which was the discussion last month.

    Reply
  2. Alan says:

    Hi Aswath, The Blue Cross Blue Shield Phono-based service is nearly 4 years old, time flies. I agree with your position on the web benefits, which have been delivered with browser plug-ins for over a decade. So WebRTC is copying that, just without plug-ins as long as you do not care about IE and Safari, and are smart enough to deal with the Chrome / FF differences or use for example Google’s or Temasys shims. You gave a great remote hack at the first ever TADHack on the use of URL context passing. And I agree that the web nature of WebRTC has not been really explored, we’re still trapped in old models. To date I’m not seeing new twists with WebRTC, rather a repeat of existing ones, hence what we’re doing with context is really not that new, yet….

    Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *


− 1 = 8