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:
220px-Alexander_Graham_Telephone_in_Newyork
To:
mayDay
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.
pancakes

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

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:
indexNotecard

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.
phone-dead
(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.

Jan 292014
 

WebRTC – Ski Lifts for Contact Centers

Minimizing costs is the most important goal of most contact centers. Talking with a few contact center executives, their bull’s eye is on minimizing the amount of time an agent used to get prepared to help a user. If helping the user is skiing down the mountain, then, today, the agent (and the user) are slowly and painfully hiking up the other side first. WebRTC is then a high-speed chairlift, enabling the user and agent to use their time skiing down the mountain, rather than struggling to get to the top of the mountain. A ski lift that saves the contact center, and the businesses that it serves, a lot of money (agent time).

A Tale of Two Calls

WebRTC-Contact-Center

The example above shows a user initiating two sessions to a WebRTC-enabled contact center (calls 1 and 2 in blue), and another user initiating two phone calls to a call center (calls 1 and 2 in red). Note the relative time length of the red sessions (the out of band phone calls to the contact center) – this out of band model causes the user and agent to hike up the mountain before they can ski down it (address the user’s problem).

Step 1a – the user seeks help from a contact center:

  • In the two contextual sessions, 1a is a short and productive step – like getting on to a ski chairlift. The user navigates the contact center’s WebRTC-enabled application (web-based or a native mobile app) to try to solve her problem. The user is in control and can easily find the information she seeks.
  • In the out-of-band calls to the contact center, the IVR is in charge of step 1a. The user is at the mercy of IVR trees and wastes valuable time.

    And this graph assumes a very good (and expensive) IVR with excellent CTI to pass information, and therefore eventually gets the user to the same level of value as 1a of the contextual session, but with longer time and higher costs.

    Unfortunately, that is the best case scenario! In other cases, the out of band step 1a will be very long and expensive, yet still not generate any value – a long hike most of the way up the mountain, only to tumble back down before reaching the top. How many times have you wasted minutes of your life in queues and IVR trees, only to be connected to an agent that then starts you back at square one, at the bottom of the mountain? Note also that if the user first tried to do self-help on a website or app, then the information (and value) from that session is not connected to his phone call.

Step 1b – the user connects with a contact center agent:

  • In the WebRTC-enabled contextual sessions, the user chooses when to add the agent to the session. Critically, this is not a new session, it is an extension of the session started in step 1a. This extended session, contextual communications paradigm means that the WebRTC application has already taken care of identification and authentication during the self-help stage (1a). It means the WebRTC app has also already initiated a session (behind the scenes) with the contact center, including adding information from relevant systems and databases (based on your credentials) to the session. So, when you choose to hit the contact button, the sessions are linked such that the contact center agent already has all the contextual information, including all the information learned during your WebRTC app self-help stage (1a) such as the key information from your clicks, swipes and touches in the WebRTC app. This not only means that the agent is able to help you from an excellent starting point, but also that the agent himself can be selected to be the one that best matches you, your information and the actions you took on the app. A linked, continuous, contextual sessions is your high-speed ski lift to the top of the mountain.
  • In the out-of-band call, 1b starts when the agent answers the call. In most cases, the agent will then need to use more time to do further identification and authentication. After the agent has spent this precious time, he next needs to slowly query one or more systems that house your data: find out what products or services you use, check out your history, grab your financial information and view your call history (remember, that was all done behind the scenes during 1a for the contextual session). You are at the top of the mountain, yet you still can’t quite ski. If you are fortunate, that agent will solve your problem.

However, we all know from experience that it is not uncommon to be thrown back into a queue to be transferred to another agent. In the out-of-band model, you are still hiking up the mountain for much of 1b. Helped by an agent, but still hiking.

In sum, this is why you see in the graph above that the red 1a and 1b takes so much longer and costs the contact center so much more money (agent time) than in the blue 1a and 1b.

Step 1c – the contact center session is terminated:

  • In the contextual session, most of the information is retained. The information gathered is therefore also valuable to future sessions. This could include a transcription of the session, possibly enabled for quick keyword-based search that also enables the contact center to efficiently watch relevant sections of the video or listen to select part of the audio.
  • In the out of band session, when you hang up, most of the past 30-minutes of your life are wiped out. The fact that the call took place will be logged and maybe the agent will enter some notes. If there is an audio recording then it will be an independent artifact – not correlated or connected with the rest of the session. Any information that could have been derived from your self-help session is effectively gone (perhaps “retained” in some web server logs; not connected or correlated in any way with your phone call).

Steps 2a – 2c – another session from the same user, but one with a head start

The subsequent sessions shown in the graph above – steps 2a – 2c – mainly mirror the first sessions. The key difference is that the contextual session builds on the information gathered in the first contextual session – notice where the blue 2a starts, compared to where the red 2a starts.

This means the second contextual communications session can be even more effective and quick than the first session. On the other hand, for the out-of-band session, if you call again in five minutes, then you will be back at square one, back hiking up the mountain via IVR prompts and back struggling through music-on-hold ice patches, and an agent will eventually be wasting time again (costing the contact center money), also starting from square one. So, not only does the WebRTC call center save time and costs on each call, they save even more time on subsequent calls (from the same users).

Other cost savings?

The example and graph above focused on the agent costs and time that contact center executives feel is the most important and viable to minimize. There are of course many other costs that can be saved by WebRTC call centers, especially once sessions become end-to-end VoIP and video over IP. These costs include PSTN costs (including toll-free), PBX costs, CTI costs and agent endpoint costs (replace expensive desk phones with software on agent computers, tablets and mobiles). It also makes it easier and cheaper to distribute call centers (including to homes), leverage cloud-based services and easier to make changes (compare making web site changes to making IVR, ACD and PBX changes).

Can WebRTC also help the revenue side of contact centers?

WebRTC call centers can also add value (revenue), especially to relationship-driven call centers. To simplify, let’s consider two types of contact centers (and some of course are really in the middle):

  • Cost-driven contact centers. These contact centers deal with calls about transactions that are relatively low-value, low-interaction and low repeat sale oriented. The performance of these contact centers is not perceived as moving the needle on the revenue side of the house. The CFO has this contact center on the top of her list, but the sales and product VPs barely know it exists.
  • Relationship-driven contact centers. These contact centers seek to maximize customer satisfaction. They are focused on relationship management, support, sales and marketing of high-value, high-touch, repeat-business, long-term relationship focused products. Sales and product VPs work hard to get budget allocated to improving these contact centers because these centers generate revenue.

I will discuss the potential revenue-side benefits (especially to relationship-driven contact centers) in more detail in other posts, but the overall drivers are that WebRTC enables the contextual communications sessions described above (which can add value, in addition to decreasing costs), and can add revenue driving functionality such as screen sharing, persistent chat and video. Meanwhile, one quick example below.

Adding faces to contact centers

As a quick example of the revenue benefits of WebRTC, how much better would it be if you could choose your favorite contact center agent, similar to how you might walk into a store and choose your favorite clerk or salesperson? In some cases, you could schedule the session to make sure you get the contact center agent that you like to work with – similar to how you might choose a specific doctor, mechanic or hairdresser. WebRTC can help humanize and personalize relationship-driven call centers. How does that help revenue? We buy more when we are comfortable and we are less inclined to move our business if we have strong relationships.

Contact center agents don’t need to be presented as faceless, interchangeable commodity parts. This won’t make sense for all contact centers – specifically some of the cost-driven contact centers – but WebRTC can help enable our relationship-driven contact centers to show us brief profile and videos of each available agent, and let us initiate a video session with our agent of choice, and then let us choose that agent for future sessions if our experience is good, even scheduling the interaction ahead of time.

Contact center conclusions

There are many verticals and domains that WebRTC could help. I think contact centers are one of the strongest, partially because they have a cost-side business case. Business cases based on cost savings tend to move quicker than cases that are only based on the revenue side, especially in the communications industry. Meanwhile, there is tremendous revenue potential around WebRTC-enabled contextual communications sessions as well.

Of course, it is not *just* WebRTC. The combination of pervasive retail Internet access, mobile and tablet proliferation, cloud-based applications and data analysis and correlation are the building. But WebRTC is the door that will enable many contact centers to walk in. And enable many of us to take the high speed quad chairlift up the contact center mountain.

Net Neutrality in 2014

 Posted by on January 15, 2014 at 22:49  internet  No Responses »
Jan 152014
 

I am a Net Neutrality advocate, meaning I agree with the precepts and objectives of Net Neutrality. However, I don’t agree that regulation is the answer.

Let’s start with three basic questions. In the US:

  • Is the Internet a flat playing field?
  • Do we have world leading Internet services?
  • Do we have pervasive broadband service availability?

No, no and no (if you believe we have a flat playing field Internet then read up on CDNs, QoS including DSCP, CoS and MPLS schemes, ISP peering and ISP transit agreements).

Yet, we have had Net Neutrality on the books since late 2010 and in practice it has essentially always been there. So why hasn’t NN resulted in those three desired outcomes?

Because the most important root cause preventing those three outcomes is the ISP monopolies and duopolies that dominate most US areas. And Net Neutrality does nothing to address that root cause. FCC governed NN is a band-aid, at best. A band-aid on a geyser.

We need to focus our efforts on opening up free market ISP competition, rather than tacking on more regulatory band-aids. Examples of where we need to focus our efforts:

  • Solutions to make better use of white space and available spectrum such as software defined radios
  • Improvements to wireless solutions and protocols and development of new ones – especially ones that can be extended to cost effectively cover larger regions.
  • Continued development of P2P solutions and related protocols (helps indirectly)
  • Taking back spectrum from entities that are not fully using the spectrum and opening it up
  • Continued development of software based routers and switches (lowers barrier to entry for new ISPs and enables more ISP innovation)
  • Eliminating regulation designed to extend the monopolies and duopolies (for example, the regulation that ISPs are sponsoring to limit competition from municipal providers)
  • Innovation in areas like WebRTC that can help distribute, diversify and grow real-time communications – which would make it less prone to ISP interference.

An argument could be made that we should do all of the above and we should fight for FCC governed Net Neutrality. But to make that argument you need to:

  • Believe the ISPs are capable of profitably doing (bad things) if they aren’t governed by Net Neutrality regulations
  • If you believe the ISPs are capable, then you also need to believe that regulation would effectively prevent those ISPs from finding ways to do those bad things in other ways.
  • If you believe both of the above, then you also need to believe it for the long-term. That the state of the Internet will remain close to what it is today, and that FCC regulation will remain a good deterrent to bad ISP behavior.

Looking quickly at all three of those:

The ISPs are not capable
Some ISPs can execute some one-off NN offenses. Block a certain site or protocol. Maybe even slow some traffic down or prioritize their own content. But not at scale and not over an extended time period. Think about it:

  • Why can’t you buy a premium service today from your ISP that guarantees you no packet loss for real-time communications services, zero buffering gaps for streaming video and five nines of uptime for your connection? Correct, the ISPs can’t effectively build, sell, deliver and operate that service…yet we think the ISPs can do it for Netflix if the FCC doesn’t block them? I have worked in VoIP service provider environments for the past 15 years…it is quite a leap to think the ISPs can deliver this type of service; in fact many would argue that it is near impossible with today’s protocols and Internet architecture
  • Which content, app or service providers would actually pay the ISPs for preferential treatment, even if we assume the ISPs could cost effectively offer such a service? Are the ISPs going to invest heavily in the technology and operations involved and then hope they can sell it? Are the app providers going to buy the story, without seeing it actually work? We would have a serious chicken and egg problem here. And, even if ISPs go build it, there is still no guarantee that anyone buys it, even if it does somehow work
  • Finally, the classic oversimplification of “pipes” is harmful in that it creates some fears that are mainly unfounded. Throttling Netflix traffic does not necessarily improve the performance of your connection or application performance. Improving Netflix traffic performance does not necessarily degrade the performance of your connection or app. Most Internet issues are transient, a function of factors that the last mile ISP doesn’t control or due to last mile ISP variables that are not directly related to pure load.

If the ISPs are capable then would FCC enforced Net Neutrality be a successful defense?
Maybe I am wrong. Perhaps the ISPs can effectively and efficiently execute source-based or stream-based type service schemes. However, if they can do that, then would the FCC really be able to block it?

Long-term, there is very little chance of FCC regulation being the best answer.
There would be unintended negative consequences. There would be waste. Look no further than the PSTN and the Universal Service Fund if want examples. Also don’t disregard the long-term with the thought that we can change off of FCC regulation later. Once the FCC is in, it will be hard and costly to get them out, even when the world changes and they are no longer wanted. Again, look at the PSTN situation. And keep in mind all of this only applies to wired ISPs…when the more important discussion is really the mobile providers…

Summary
This has been my position for years – see previous Net Neutrality posts). That actually makes me a bit nervous – there has been enough change that I feel that view may no longer be as valid. But if I quickly think through the arguments then I always come back to the above. In fact, maybe ironically, I think the second best “solution” might be somewhat the opposite – a legal mandate for US ISPs to connect every household with top tier quality – even if that meant some FCC oversight, though of course done in a way to foster free market competition (which means this probably will never happen as it would be very difficult given the players and dollars involved). But I don’t like any of the middle ground type solutions, and I think the current FCC version of Net Neutrality is exactly that, so I prefer to focus our efforts on the root cause, the monopolies and duopolies, and the innovation that can help change that. What do you think?