Tivia and WebRTC magic

 Posted by on March 27, 2015 at 22:14  applications, ORTC, WebRTC  No Responses »
Mar 272015

Tivia is a new WebRTC app for group communications. Yet Tivia doesn’t use WebRTC…

Let’s start with what Tivia currently does:

  • Tivia is Slack. Except for community groups and events. Tivia is purpose built for private group communication
  • Tivia group communication includes: instant group messaging; schedule events on shared group calendar; Dropbox integration; private media sharing; bulletin boards.
  • Tivia is strictly private. No public groups. Even within your group, your personal contact info is not shared.
  • Tivia prioritizes speed and reliability: mobile notifications; delivery reports; indicator of who is typing as they type (integration with the awesome PubNub services).
  • Tivia has a full app for iPhone and Android, yet is all inclusive. Group members with other phones automatically receive group messages via text message.

Ok, so Tivia is a nice app for private group communication. Well, almost. There is no voice. Or video. Or even WebRTC data channel features. Yet. So what gives?

Well, Tivia can use WebRTC to add video chat or group conference calls as features. One touch in a private group and you start your conference. PINs? DTMF? Email invites? Dial plans? Directories? No thanks. No legacy conferencing baggage because Tivia started with the group and messaging, and WebRTC then enables Tivia to add RTC as a feature. That’s WebRTC magic.

And WebRTC magic goes well beyond conferencing. How about when Tivia groups want feeds from the Internet of Things (IoT)? Alerts, video clips, photos, sensor data?  WebRTC. I actually think we will soon have more asynchronous voice, video and data streams from IoT than we will have full duplex human conversations.

And of course WebRTC extends to collaboration via data channel (ok, once there is a bit more work to tighten the security or give the user more knobs). Here too though it is best to start with messaging and start with groups. WebRTC magic makes this easy.

This is the under appreciated magic of WebRTC. You can build your experience, while knowing you can easily integrate RTC as a feature via WebRTC, whenever and however makes sense. Of course, you could start from the other side, meaning start your communications app with voice and video. But I think the world is going the other way (read Tsahi’s nice post here for example).

Groups and identity.  Messaging.  Asynchronous communication.  IoT streams.  RTC as an integrated, contextual feature in many apps. This is where the world is going, and this is why WebRTC is much more magical than if we view WebRTC as just another option for communications apps. As a developer, you can start with the experience, and should, and usually that means starting with messaging and groups (or whatever social graph your application is going to leverage). 

WebRTC is not just an option to build communications apps.  WebRTC is the best way to integrate RTC into your experiences. And the magic of WebRTC is it enables you to build your experience in the order that makes sense, and seamlessly include RTC within the context of that experience.

Mar 162015

Day one of Enterprise Connect 2015 is in the books. A few highlights (personal opinions):

  • Best use of WebRTC: customer contact center IF includes mobile channel engagement
  • Top theme: RTC everywhere
  • Hot: WebRTC SDKs
  • Key question: If/when Skype for Business goes to BFCP content share?

And some Enterprise Connect 2015 day one notes as a combination of themes, thoughts on the future of communications, our Tata WebRTC products (of course!), and other interesting show floor sightings:

WebRTC SDKs are the new SIP phones.
Lots of them. Click2RTC from Tata (more on Click2RTC below), Sonus, Genband, Vidyo, CafeX, Dialogic, Aspect, Twilio and many more. I am a bit biased in this area ; ), but I recommend you evaluate in aspects such as support across all mobile and OS platforms and browsers, security, QoE (including network), interoperability and support models.

RTC everywhere.
Real-time communication will be everywhere. Embedded. Integrated. Standalone. There when we don’t know it.

Fit for purpose.
Specialized use cases. Apps to enable very specific experiences. As such, most apps will do something unique (even if technically “standards-based”) with media, signaling, collaboration and/or session control. This has important interop ramifications…

I think we will end up with more one-way video communication streams then full duplex video conversations. Streams from IoT cameras and sensors. Video mail. Conversations composed of video clips exchanged asynchronously and with other bits (content, images, collaboration).

Where are we going?
Communications is a software feature. But it is still a fairly monolithic feature. Decomposition is next – the separation of communications into software layers such as identity, authentication and session control. And this will spur innovation – in the same way that innovation was ignited when Internet separated the communications transport layer from the communications application layers.

Mobile apps are a perfect starting point. Apps such as Kik already have your identity. What if other communications apps could interrogate via API (securely, with your permission)? Personal, API-enabled, self-administered DNS.

How about group communications? The pain of trying to setup a conference call, manage PINs, authenticate people. Mobile apps such as Tivia already have your groups defined. If Tivia groups were WebRTC or ORTC enabled, you could start a conference with one press. The DNS model works here too – Tivia groups as DNS objects, controlled by you and accessible by your communications app of choice.

Identity is another example. Identity is very hard but check out the services that Twitter (Fabric), Twilio (Authy acquisition) and others have recently rolled out. The era of (n) identities for (n) applications is in the sunset phase.

End-to-end session control is the most difficult layer to decompose, but SDN will help build on the Internet/DNS foundation that is already in place. We need some other developments there too, but we are getting closer.

What about the telcos?
Ok, stepping back from the future, and into the present. So we agree that loosely coupled, best-in-class layers is innovation fuel. We have seen it in the software world for years, and now we will see it in the communications world. However, we mainly just have building blocks now such as Internet, DNS, WebRTC, ORTC, APIs, SDN. Telcos have an opportunity to help stitch the ecosystem together, but need to evolve, instantly, from monolithic telephony providers to service enablers that work inside of an ecosystem to deliver communications experiences. Not minutes. Not sessions. Experiences that include communications.

Messaging as the core
Tsahi is the first one that I have heard really emphasize this point. And I couldn’t agree more. UC starts with messaging. I think of messaging as the product analogy of an OS or platform. UC products that are missing mobile messaging face an uphill battle.

We (Tata Communications) announced Click2RTC today. Quite simply, I challenge any of you to list another WebRTC SDK that does these five things:

1. SDK that enables developers to package RTC inside their customers’ experiences
2. SDKs/solutions for Android, iOS, IE, Safari, FF and Chrome
3. QoE across tier one backbones (Tata Communications and our partners)
4. Tier one support model for developers and operators
5. Interoperability with everything. 3-screen telepresence, Skype For Business, SIP VC, H.323 VC, voice.

Now, to be fair, we haven’t put all of the above into the product yet, however, we are showing all of it on the show floor at Enterprise Connect, and I don’t think anyone else can do the same. And I am not claiming you need those five attributes for every RTC product. However, if you do have one of those products, and you want to add RTC to it on your terms, with your brand, inside of your experience…then come visit our booth this week and see it in action.

What if WebRTC didn’t do telecom?

 Posted by on January 15, 2015 at 16:43  ORTC, WebRTC  No Responses »
Jan 152015

WebRTC and ORTC are not terribly exciting for improving telecom use cases. They are however game changing for enabling new contextual communications services.

ORTC and WebRTC help us add communications to an overall experience (rather than self-hijacking your activities in order to make a zero-context phone call…and asking the other end to self-hijack whatever they are doing to take the phone call).

In that sense, we are at the K-T boundary, communications mammals will take over, telco dinosaurs will depart.
k-t boundary

However, after giving a WebRTC & ORTC webinar for BrightTALK today (slides are here and the recorded webcast will be posted by BrightTALK), and reading the direction that was implied today in the new proposed W3C WebRTC working group charter, I asked myself:

What if WebRTC didn’t do telecom?

  • What if you couldn’t use WebRTC (or ORTC) to make a telecom call?
  • What if you had to start with a data session, and only then could add audio or video streams?
  • What if you had to find other ways to learn the capabilities of the far-end, and couldn’t do it as part of the WebRTC SDP offer answer negotiation?
  • What if media codecs weren’t in the standard at all – you are forced to use whatever codecs your browser or mobile OS provide, or bring your own to the table if they enable you to do so (as ORTC seems to be doing with H.264)?
  • What if it was really hard to interoperate with SIP endpoints?

It is an academic, Monday morning QB thought experiment, no doubt. And easier to do now, than to have done at the start of the WebRTC WG, especially for me personally after I have also gained heavy real world WebRTC experience from adding WebRTC to our Jamvee services. However, I think we would have been better off, and I say that even though I have done telco since the early days of VoIP. How would we be better off?

  • We would have more innovative, contextual communications apps, and less lipstick on pig demoes
  • I think we would be closer to a ratified spec. Much of the delay has been due to the SDP offer-answer model, integrated capabilities negotiation and media codec.
  • The first sets of WebRTC and ORTC apps wouldn’t have looked, felt and smelled like telecom apps.

ORTC is a huge and exciting step in the right direction, and I think ORTC will bleed into WebRTC (or the two will merge completely, and then spawn vendor/provider specific branches, e.g. like Android is branching).

And I still believe that WebRTC and ORTC enable a communications transformation. I said in the webinar today that WebRTC and ORTC enable this analogy:

Telecom (will be) to communications as trains are to transportation

Meaning, WebRTC and ORTC (combined with Internet, mobile and the API economy) enable us to develop new communications services – to make it such that telecom is just one form of communications.

I believe that is true. And exciting. But I still wonder what WebRTC would look like today if it didn’t initially enable telecom use cases, and I wonder if we would have been closer to the future of WebRTC and ORTC enabled contextual communications experiences?

Jan 122015
We’ve gone from:
What’s next?

2015 is the 100 year anniversary of the first transcontinental telephone call, enabling Alexander Graham Bell and Thomas A. Watson to talk between New York and San Francisco.

I also think 2015 will mark the inflection point at which ORTC, WebRTC, Internet, mobile and the API economy combine to move us into the communications paradigm of the next 100 years.

Please join me on Thursday to discuss WebRTC and ORTC in this BrightTALK webinar.

The webinar will include:

  • The future of communications, brought to you by Internet, mobile, API, WebRTC and ORTC
  • Similarities and differences between ORTC and WebRTC
  • Business models enabled by ORTC and WebRTC
  • Notes on SDP, simulcast, SVC and getCapabilities
  • Risks and challenges with ORTC and WebRTC
  • How service providers win and lose with ORTC and WebRTC

There is no cost, BrightTALK gives you a nice webinar interface, and there are other great sessions in this summit. Hope to see you there.

context is king

 Posted by on January 8, 2015 at 14:50  ORTC, WebRTC  No Responses »
Jan 082015

Last weekend, I prepared to make pancakes for a group of us that was up early and hungry.

So I went to grab my wife’s favorite pancake recipe:

Her recipe box looks simple and organized? Well, looking under “p” for pancakes, and other similar guesses, yielded no results. So, I pulled a recipe off the web and used it.

Later, I asked my wife about it and she pointed me to this index card:

Ah. The context – the key to unlock the secrets of her recipe box. “B” had apparently been claimed by “breads”, meaning “breakfast” recipes, including pancakes, had to settle for “E”. Not how I would have organized it, but, given the context, I will know what to do next time. Yes, context is king, even for an innocent looking recipe box.

Context is also king for real-time communications. Really, context has always been king. But technology used to make communications context hard. I had to stop what I was doing and pick up a phone to call you. No longer. WebRTC and ORTC help enable in-context communications. I launch the call (or video call or screen sharing session) from my mobile app or browser, all the context from the app or browser session is automagically there, and I am still inside the context and experience of my app.

Context is why WebRTC and ORTC are revolutionary. Yes, it is cool to make a call from a browser without a plugin or download. But it is still a call. Potentially a bit cheaper, maybe better audio quality, possibly more convenient. But still a call.

Add context though and you kill the a call.
(image credit)

You replace the call with an experience. Lots of customized experiences. And you create some new ones. That is great for you and me. And it is good for the communications providers because they can now deliver experiences instead of selling minutes – at least for the providers that evolve quickly enough out of the old, context-less telecom paradigm. Note: don’t underestimate the ability of old world telcos to use new technology (WebRTC, ORTC) to deliver yesterday’s solution (e.g. calls). Check AT&T’s “WebRTC” APIs for example. And I say that even though I work for one of the largest telcos; we’re all guilty of this awful mistake.

Internet and mobile have already put most of the building blocks in place. WebRTC and ORTC are maturing and will help push us to the inflection point. ORTC’s first mature draft came out this summer (and has tremendous potential). The draft RFC for WebRTC data channel (critical to the overall contextual experience for many use cases) was just moved to a proposed standard today.

Yes, context will kill the call. Or, maybe more accurately but less dramatic sounding, context will put calls back in their place – inside of the experience, not outside of it.