bloggeek

Subscribe to bloggeek feed bloggeek
The leading authority on WebRTC
Updated: 6 min 28 sec ago

Is Twilio Redefining CPaaS?

Mon, 05/29/2017 - 12:00

Twilio’s Jeff Lawson had a really interesting keynote at their Signal event. I think Twilio is trying to redefine what CPaaS is. If this works for them, it will make it doubly hard for their competitors.

This is going to be long, as the keynote was long and packed full with information and details that pave the road to what CPaaS is going to be in 2020.

I suggest you watch this keynote yourself –

What I loved the most? The beginning, where Jeff refers to code as making art. I have to agree. In my developer days, that was the feeling. Coding was like building with lego bricks without the instructions or sitting down to paint on T-shirts (yes – I did that in my youth). When a CEO of a company talks about coding as art and you see he truly believes it – you know that what that company is doing must be… art.

Before we Begin

One term you didn’t hear at the keynote:

CPaaS

One term that was there every other slide:

This was about developers, who is the buyer and how software APIs are everywhere.

It was also about how CPaaS is changing and Twilio is now much bigger than that – in the traditional sense of what CPaaS means.

It wasn’t said out loud, but the low level APIs that everyone are haggling about – SMS and voice – are nice, but not where the future lies.

Twilio by the Numbers

The numbers game was reserved for the first 13 minutes of the keynote, where Jeff asserted Twilio’s distinct leadership in this market:

  • 28 billion interactions (a year)
  • 70 countries (numbers in) today; plan to grow to numbers in a 100 countries “by this summer”
  • Over 900 employees; Over 400 in R&D
  • 30,000 annual deployments (the number of times a year Twilio is introducing new releases… in a continuous delivery mechanism to an operational cloud service) – this enables shipping faster with less mistakes. The result? 3.5 days between new product or feature launch
  • 1.6 million developer accounts on Twilio; 600,000 new accounts in the past year; doubling YoY
  • 99.999% API availability – and 99.999% success rate
  • 0 APIs killed

More about the two last bullets later.

Here’s what Twilio deployed in the past year:

To me, this is becoming hard to follow and grasp, especially when I need to look at other vendors as well.

If you look at it, you’ll see that Twilio has been working hard in multiple vectors. The main ones are Enterprise, IP communications and “legacy” telephony.

The main messages?

  1. Twilio is the largest player in the communication API space
  2. Twilio is stable and solid for the enterprise
  3. Twilio is globally available and rapidly expanding to new countries
  4. Twilio is fast to introduce new features

All this boils down to stating that a competitive advantage can be best achieved on top of Twilio.

Twilio’s New Layering Model

If you’ve been watching this space, you might have noticed that I tend to use this model to explain CPaaS feature sets:

And this is how Jeff explained it on stage in Twilio’s Signal event 2016:

Building blocks. Unrelated. Could have been placed horizontally one next to the other to get the same concept. But piling them on top of each other is great – it shows there’s lots and lots of services and features to use.

2017 brings with it a change in the paradigm and a new layers model that Jeff explained, and was later expanded with more details:

The funny thing is that this reminded me of how we explained the portfolio and API layers in our VoIP products at RADVISION more than 10 years ago. It is great to see how this translates well when shifting from on premise APIs to cloud APIs. But I digress.

Back to the layering model.

The Super Network wasn’t given much thought in this time around. There were announcements and improvements in this area, but these are a given by now. For those who wish to outmaneuver Twilio by offering a better network – that’s going to be tough without the layers above it.

Then there’s the Programmable Communications Cloud, which is where most of the CPaaS vendors are. This is what I drawn as my own perspective of CPaaS services. The names have changed a bit for the Twilio’s services – we’ve got Programmable Chat now instead of IP Messaging. SMS has 3 separate building blocks here instead of one, and the baseline one is called Programmable SMS – keeping the lower level Communications APIs with a nice naming convention of Programmable X.

The interesting part of this story comes in the Engagement Cloud. Jeff made a point of explaining the three aspects of it: Systems, Departments and Individuals. And the thing about the Engagement Cloud is that services there are actually best practices – they aren’t “functional” in their nature. So Twilio are referring to the APIs in this layer as Declarative APIs.

The Engagement Cloud

The main difference between what’s in the Engagement Cloud and the Programmable Communications Cloud? In the Programmable Communications Cloud you know as a developer what will happen – you ask to send an SMS and the SMS is sent. With the Engagement Cloud, you ask for a message to reach someone – and you don’t really care how it is done – just that it will be done in any channel that fits best.

No Channel To Rule Them All

What is that “any channel that fits best”?

That’s based on what Twilio decides in the modules they offer in the Engagement Cloud, and it is where the words “best practices” were used during the event.

Best practices are powerful. As a supplier, they show you know the business of your customer to a point where you can assist him more than just by giving him the thing that he think he needs. It places you often as a trusted advisor, or one to go to in order to decide what it is you are going to do. After all – you own the best practices, so why not follow them?

It is also where the most value is to be made moving forward.

SMS is probably still kind when it comes to revenue in CPaaS. Not only for Twilio, but for all players in the market. And while this is nice and true, it is also a real threat to them all:

Yes. SMS is growing in use.

Yes. The stupid term A2P (Application 2 Person) is growing rapidly and it is done using SMS.

Yes. People prefer that over installing apps, receiving emails and getting push notifications.

Yes. People do read SMS messages. But I am not sure if they trust them.

Here’s a quick story for you.

Airbnb.

I use them once in awhile. I was just planning a trip with the family for July. Found the dates. Booked the flights. Found an Airbnb to stay at. Reserved a place – and was asked if I am cool with push notifications. I clicked yes. And here’s what I got the next moment on my phone:

Businesses might be recommended to use SMS to reach their customers, but the prices of SMS urges businesses to seek other, cheaper channels of communications at the same time.

There is no money to be had in Communications APIs in the long term.
Click To Tweet

There is already a price war at this level. Vendors trying to be “cheaper than X”. Developers complaining about the high prices of CPaaS, not understanding the real costs of developing and maintaining such systems.

What’s in Twilio’s Engagement Cloud

Which is where the Engagement Cloud comes – or more accurately – the best practices and smarts on top of just calling communications APIs.

Twilio are now offering 4 APIs in that domain:

  1. Authy – handling authentication type scenarios, including but not limited to the classic 2FA
  2. Notify – a notification service from applications and services to users. It started as SMS, continued with the addition of push notifications, but now supports multiple channels
  3. TaskRouter – a way to connect incoming tasks with workers who can handle them. Can be used to build queuing systems in contact centers
  4. Proxy – a mechanism to send connect between people in two separate groups – riders and drivers for example. Suitable for the sharing economy or when the “agents” aren’t “employees” or are loosely “controlled” by the organization
Omnichannel

The interesting bit here is that these all started as functional building blocks. But now the stories behind them are all about multi-channel.

SMS is great, but it isn’t the answer.

IP messaging is great, but it isn’t the answer.

Facebook messenger with its billion+ users is great, but it isn’t the answer.

XKCD says it best:

With such a model in which we live in, programmable communications need to be able to keep track of the best means to reach a person. And so Twilio’s Engagement Cloud is about becoming Omnichannel (=everywhere) with the smarts needed to pick and choose the best channel per interaction.

Are we there yet with the current Twilio offering? I don’t know. But the positioning, intent, roadmap and vision is crystal clear. And with Twilio’s current speed of execution, it is going to happen sooner rather than later.

Vendor Lock-in

The great thing about this layer of Engagement Cloud for Twilio is that it is going to be hard to replace once you start using it.

How hard is it to replace an API that sends out an SMS to a phone number with another API that does the same? Not much.

But how hard is it to replace best practices wrapped inside an API that decides what to do on its own based on context? Harder. And getting even more so as time goes by and that piece of module gets smarter.

Twilio gets a better handle on its customers with the Engagement Cloud. It makes it a lot harder for developers to go for a multi-vendors strategy where they use SMS from the CPaaS vendor whose price is the lowest.

Developer’s Benefits

Why would developers use these Engagement Cloud modules from Twilio?

Because they save them a ton of time and even a lot more in headaches.

Today, there are 3 huge benefits for developers:

  1. Logic – the logic in these modules is one you get for “free” here. No need to write it on your own and make the decisions on your own
  2. Best practices – I know that your contact center is unique, but it probably adheres to similar queuing mechanisms as all the rest. You end up using similar/same best practices as others in your domain, and having these already pre-built is great. Maybe you can even improve your own business simply by using best practices and not do it alone
  3. Multiple vendors – adding channels means figuring out the APIs and craziness of multiple providers. No fun. You get a single API to rule them all. What’s not to like?

These areas are usually those that developers usually don’t like to deal with. That third one especially is a real pain – after you did it for 2 vendors/channels – connected it to SMS and maybe Facebook Messenger, it feels boring to add the next channel. But now you don’t have to anymore. And don’t you get me started with how the APIs there deprecated and changed through time.

Machine Learning and its CPaaS Role

Twilio talked about Machine Learning in two new APIs that it is introducing: Speech Recognition and Understand

The Speech Recognition one is a bit less interesting. It is done in partnership with Google, using Google’s engine for it. The smarts on Twilio’s side here is the integration and how they are stitching these capabilities of text to speech throughout their line of products.

Here what Twilio is doing is acting in the most Twilio-like approach – instead of developing its own speech recognition tech, or using a 3rd party that gets installed on premise, it decided to partner with Google and user their cloud based speech recognition technology. And then making it easier for developers to consume as part of the bigger Twilio offering.

The real story lies elsewhere though – in Twilio Understand.

While Speech Recognition is a functional piece where you feed the machine with voice and get text, Understand is about modeling your use case and then having the machine parse text based on that model.

It is also where Twilio seems to have gone it alone (or embedded a third party internally), building its real first customer-facing Machine Learning based product.

In the past few years we’ve seen huge growth in this space. It started with Big Data, turned Analytics, turned Real Time Analytics, turned Decision Engines, turned Machine Learning.

Companies use this type of capabilities in many ways. Mostly internally, where Twilio probably had been doing that already. But embedding machine learning and big data, making products smarter is where we’re headed. And for me, this is the first instance I’ve seen by a CPaaS vendor taking this route.

It is still a small step, as Understand is another piece of API – a module – that you can use. And just like many of Twilio’s other APIs, you can use it as a building block integrated with its other building blocks. It is a move in the right direction to evolving into something much bigger.

LinkedIn shows that Twilio has several data scientists (the man power you need for such tasks), though none of them was “kind enough” to offer details of his role or doings at Twilio

Moving forward, I’d expect Twilio to hire several more people in that domain, beefing up its chops and starting to offer these capabilities elsewhere.

The only competitor at the moment who is seeing that is Cisco Spark – with their recent acquisition of MindMeld.

The great thing about machine learning? People feel and assume that it is super hard. Which means it is worth paying for.

The Enterprise

Here’s where enterprises find a home at Twilio’s Signal 2017 keynote. Best to just show it in slides:

Twilio’s API calls success rate. This goes on top of its 99.999% API availability and this is where Jeff wants you to focus – not on getting an API returning an error (would would still fall under availability) but rather on how many successful results you get from the APIs.

Since Twilio launched, none of its APIs was ever deprecated or killed (haven’t checked it myself but this is what Jeff wants you to remember).

Twilio has been working hard on reaching out to enterprises. It introduced an Enterprise plan last year. Implemented ISO 2700. Added Public Key Validation. Introduced support for Enterprise SSO.

All these are great, but what I think resonates here the most are the above two items.

99.999% Success Rate

Enterprises LOVE this.

SLAs. Guarantees. All the rage.

Twilio is operating at 99.999% uptime and is happy to offer a 99.99% guarantee in its enterprise SLA:

For an enterprise to go for Twilio requires two leaps of faith:

  1. Leaping from on premise to the cloud. Yes. I am told everyone’s migrating to the cloud, but this is still painful
  2. Picking Twilio as its vendor of choice and not its natural enterprise vendors (known as ISVs)

When you pick Twilio, who’s giving you any guarantees?

Well… Twilio does. At 99.99% while maintaining 99.999% across all of its services to all of its customers.

That’s a powerful message. Especially if you couple it with 30,000 deployments a year.

0 APIs Killed

This one is REALLY interesting.

In the world of APIs where everything is in the cloud with a single copy running (it isn’t, but bear with me a second), having someone say that they offer backward compatibility to all of their APIs is huge.

The number of changes you usually need to follow with APIs on the internet is huge. If you have a product using third party APIs, then every year or two, you need to make some changes to have it continue to work properly – because the APIs you use change.

0 APIs kills means that if an enterprise writes their code today for a project they have, it won’t need to worry about changes to it due to Twilio. Now, in many cases, enterprises develop a project, launch it and then are happy to continue with it as is without further investment (or budget). Which means that this kind of a soft guarantee is important.

How does Twilio do it?

They launch products in beta and run the beta for long periods of time. During that time, they get developers to use and tinker with the APIs, collect feedback and when they feel ready, they officially launch it – at which point the API is deemed stable.

It works well because Twilio has lots and lots of customers, some willing to jump on new offerings and take the risk of having things break a bit during those beta periods.

The end result? 0 APIs killed.

Will it Blend?

I believe it will.

Twilio has introduced a new paradigm for they way it is layering its product offerings.

In the process, it repositioned all of its higher level APIs as the Engagement Cloud. It stitched these APIs to use its lower Programmable Communications APIs, adding business logic and best practices. And it is now looking into machine learning as well.

It is a powerful package with nothing comparable on the market.

Twilio are the best of suite approach of CPaaS – offering the largest breadth of support across this space. And it is making sure to offer powerful building blocks to make developers think twice before going for an alternative.

Twilio isn’t for everyone. And other CPaaS vendors do have their place. But increasingly, these places become niches.

Is there more?

Yes.

This analysis is long, but by no means full.

There were a lot of other aspects of the announcements and Twilio’s moves that require more thought and details. The pricing model on group Programmable Video is one of them. Third Party Add Ons in certain domains (especially for analytics) is another. Or Twilio heading into the UI layer. And then there’s serverless via Twilio Functions. This isn’t even an exhaustive list…

I won’t be going into these here, but these are things that I am actively looking at.

Contact me if you are interested in understanding more about this space.

Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.

The post Is Twilio Redefining CPaaS? appeared first on BlogGeek.me.

WebRTC for Business People – The 2017 Edition

Mon, 05/22/2017 - 12:00

WebRTC for Business People – The 2017 Edition

The revamped WebRTC for Business People report is now published.

I’ve been reviewing the stats of the content here lately, and noticed that people still find their way and download my WebRTC for Business People report.

My only problem with it is that it was already old – and showing it: There’s no serious mention of the advances made by Microsoft Edge towards WebRTC support, nothing about the difficulty of finding experienced WebRTC developers.

But most of all – the use cases it mentioned. Some of them were companies that got acquired. Others were shutdown. Some stagnated in place, or are now on life support.

That’s not a good way to introduce someone to the topic of WebRTC.

So a rewrite was in order here, which brought me to work with a few sponsors:

They were kind enough to make the investment needed for me to put the time and effort into it.

WebRTC for Business People – what’s in the 2017 edition?

Well…

First off – the report is still free. You can download it, print it, read it online – practically do whatever you want with it.

I’ve refreshed the visuals and updated the analysis part with data from 2015 until 2017 (the time that have passed since the last update to the report). Did you know that WebRTC is still growing linearly in all relevant parameters that you can check?

No hype here. Just solid, steady growth. The minor change in github projects trajectory? That started when Google moved their WebRTC samples and demos from Google code to github.

I wonder if this will change when Apple adds WebRTC to Safari and iOS.

I removed all the nonsense in the report about SIP and H.323. These protocols still exist, but more often than not, people don’t look at them and compare them with WebRTC – because WebRTC has gone way beyond these signaling protocols.

Oh – yes – and I completely rewritten all the vendor use cases and the segments I look at in this report. Here’s the new set of vendors in the report:

If you are interested in WebRTC, the ecosystem around it and understand how companies are using it today – in the real life – making real commercial use of it – then check out this report.

Download the report

The post WebRTC for Business People – The 2017 Edition appeared first on BlogGeek.me.

Announcing my Virtual Coffee sessions

Wed, 05/17/2017 - 09:00

Time to start another ongoing project. This time – my Monthly Virtual Coffee sessions about WebRTC, CPaaS, APIs and comms in general.

Some time in 2015-2016, I decided to host Virtual Coffee sessions. Once a month, I’d pick a subject, create a presentation and host a meeting with my customers. All of them. It was open for questions and it was fun. It stopped because… I don’t know. It just did.

Ever since then, I wanted to do something similar. I found I like talking and interacting with people, and I want to do it more.

Which is why I am now announcing the new Virtual Coffee with Tsahi.

Here’s how it will go down:
  • The live sessions are free to join. For anyone
  • Recording of the session will be available to my customers only
  • Topic will be selected and announced a week or more in advance
  • This will happen once a month. Hopefully
How will this be announced?

I won’t be using this blog to publish future sessions – sorry.

The sessions will be announced through Crowdcast (the service I started using for such events lately), so follow me there. And through my newsletter, so if you’re not subscribed – do it now.

What topics will I cover?

I really don’t know…

If you want something specific – drop me a line.

Our 1st Virtual Coffee together

The first topic I want to tackle?

CPaaS, WebRTC, Differentiation and M&A

When? May 23 @ 15:30 EDT

There are over 20 different CPaaS vendors out there, and that number is growing and shrinking at the same time:

  • AT&T closing their Enhanced WebRTC APIs
  • Cisco acquiring Tropo
  • Vonage acquiring Nexmo
  • CLX Communication acquiring Sinch
  • RingCentral adding APIs to its UCaaS
  • TeleSign announcing self service CPaaS, only to get acquired

I want to take the time to review some of this M&A activities, as well as show how different vendors are trying to differentiate themselves from the rest of the crowd.

Join me for this Virtual Coffee with Tsahi

Oh – if you you have questions for this already – just ask them on Crowdcast once you register.

See you there!

The post Announcing my Virtual Coffee sessions appeared first on BlogGeek.me.

What is WebRTC and What is it Good For?

Mon, 05/15/2017 - 12:00

What is WebRTC and What is it Good For? This 7-minute video provides a quick introduction to WebRTC and demonstrates why it is growing in importance and popularity.

Covered in this video:

  • What is WebRTC?
  • Current state of adoption of WebRTC
  • Why is it so much more than just a video chat enabler
  • The power of “Open Source” in WebRTC
  • How WebRTC works
  • Five reasons to choose WebRTC
What is WebRTC?

WebRTC is an HTML5 specification that you can use to add real time media communications directly between browser and devices.

Simply put:

WebRTC enables for voices and video communication to work inside web pages.

And you can do that without the need of any prerequisite of plugins to be installed in the browser.

WebRTC was announced in 2011 and since then it has steadily grown in popularity and adoption.

By 2016 there has been an estimate from 2 billion browsers installed that are enabled to work with WebRTC. From traffic perspective, WebRTC has seen an estimate of over a billion minutes and 500 terabytes of data transmitted every week from browser communications alone. Today, WebRTC is widely popular for video calling but it is capable of so much more.

A few things worth mentioning:

  • WebRTC is also completely free
  • It comes as open source project that has been embedded in browsers but you can take and adopt it for your own needs
  • This in turn has created a vibrant and dynamic ecosystem around WebRTC of a variety of open source projects and frameworks as well as commercial offerings from companies that help you to build your products
  • WebRTC constantly evolving and improving, so you need to keep an eye on it
So, how does WebRTC work?Code and API

It is important to understand from where we are coming from: If you wanted to build anything that allowed for voice or video calling a few years ago, you were most probably used C/C++ for that. This means long development cycles and higher development costs.

WebRTC changes all that: it takes the need for C/C++ and replace it with a Javascript API.

WebRTC comes with a Javascript API layer on the top that you can use inside the browser. This makes it far easier to develop and integrate real time communications anywhere. Internally, WebRTC is still mostly implemented using C/C++, but most developers that use WebRTC won’t need to dig deep into these layers in order to develop their applications.

Availability

WebRTC today is available in most modern browsers. Chrome, Firefox and Microsoft Edge support it already, while Apple is rumored to be in the process of adding WebRTC to Safari.

You can also take WebRTC and embed it into an application without the need of browser at all.

Media and access

What WebRTC does is allow the access to devices. You can access the microphone of your device, the camera that you have on your phone or laptop – or it can be a screen itself. You can capture the screen of the user and then have that screen shared or recorded remotely.

Whatever WebRTC does that does in the real time, enabling live interactions.

WebRTC isn’t limited to voice and video. It allows sending any type of data any arbitrary data

There are several reasons WebRTC is a great choice for real time communications
  1. First of all, WebRTC is an open source project
    1. It is completely free for commercial or private use, so why not use it?
    2. Since it is constantly evolving and improving, you are banking on a technology that would service you for years to come
    3. WebRTC is a pretty solid choice – It already created a vibrant ecosystem around it of different vendors and companies that can assist you with your application
  2. WebRTC today is available in browsers and most modern browsers today support it
    1. This has enabled and empowered the creation of new cases and business models
    2. From taking a Guitar or a Yoga lesson – to medical clowns or group therapy – to hosting large scale professional Webinars. WebRTC is capable of serving all of them and more
    3. WebRTC not limited to only browsers because it is also available for mobile applications
      1. The source code is portable and has been used already in a lot of mobile apps
      2. SDKS are available for both mobile and embedded environments so you can use WebRTC to run anywhere
    4. WebRTC is not only about for voice or video calling
      1. It ss quite powerful and versatile
      2. You can use it to build group calling service, add recording to it or use it only for data delivery
      3. It is up to you to decide what to do with WebRTC
    5. WebRTC takes the notion of communication service and downgrades it into a feature inside a different type of service. So now you can take WebRTC and simply add communication in business processes you need within your application or business

So what other choice do you really have besides using WebRTC?

The idea around WebRTC and what you can use it for are limitless. So go on start building whatever you need and use WebRTC for that.

Embed this video on your own site for free! Just copy and paste the code below…

<iframe src="https://player.vimeo.com/video/217448338" width="640" height="360" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>

 

The post What is WebRTC and What is it Good For? appeared first on BlogGeek.me.

What to Expect when Deploying WebRTC in Contact Centers?

Mon, 05/08/2017 - 12:00

Contact centers are the main adopters of WebRTC still. This is clearly reflected by my infographic of the WebRTC state of the market 2017.

Motto:“This ‘telephone’ has too many shortcomings to be seriously considered as a means of communication. The device is inherently of no value to us.”

Western Union telegraph company memo, 1877.

Think you know how WebRTC fits in a contact center? Check out with The Complete WebRTC Contact Center Uses Swipefile

Get the swipefile

Recently, Jaroslav from iCORD, told me the stats they now see from the contact center deployment they have in O2 Czech Republic, who also happen to be their parent company.

How is O2 CZ making use of WebRTC in their Contact Center?

What they did isn’t the classic approach you will see to WebRTC in contact centers, but rather something slightly different. If you are a customer of O2 CZ and you are thinking of making a purchase on their website, you have the option to leave a number for them to immediately get back to you:

And yes – there is also an “exit intent”  on that sales page, so if try to leave this page, it will appear as a popup.

How is a phone call related to WebRTC you ask? Well… it isn’t. Unless you factor in the fact that we now know what web page the user is on.

What happens next, is that a contact center agent will call back to the user, and the user will see something new on his browser – a shared space between him and the agent that just called him.

This shared space will enable the agent to browse the same page the customer was on, and move on from there elsewhere. It also includes annotations – the agent can draw or mark things on the screen. One last thing – the user will see the video of the agent, but will not share his video.

See? They even haggle and write down discount prices right on the webpage.

Now, if the interaction started with a phone call, the agent in the contact center can instruct the customer to go to the O2 CZ website and enter a PIN code there – and magically get to the same experience.

Here’s a diagram to show the communication channels we now have between the customer and the contact center agent:

Why this approach?

  1. Customers continue using the phone. Same way they did in the past
  2. There’s no reliance on the customer’s camera, microphone or muted speaker volume
  3. It got stitched right into the existing contact center O2 CZ already had in place
The results

But was this effective? Was it worth the effort?

O2 CZ have been running this contact center service throughout 2016, and took the time to analyze the results. They did so only for sales related calls – the money makers.

Here’s what they found out:

Using this approach is much more efficient than a simple phone call.

Let’s stop right here for a second and soak that statement.

We’re talking about a contact center.

Of a mid-sized European carrier (4 million subscribers).

The type of those where I am told over and over would NOT adopt WebRTC because it does not support Internet Explorer 4. Oh. And this specific service falls back to Flash if the customer’s browser doesn’t support WebRTC and even decreases further in feature set to static screenshot and PDF file sharing for those who don’t even support Flash.

And they are already doing it for a full year.

Successfully.

In production.

In front of live customers.

Who would have thought a non-startup company that isn’t located in Silicon Valley and operated by 16-year olds would be able of doing such a ridiculous thing like deploy WebRTC in production directly to where money gets negotiated with customers.

— end of rant —

Back to the results.

Call length on average dropped

It takes 30% less time to negotiate and close a deal than a regular phone call and considerably shorter than text chat. This may seem a bit backwards – the fact that chat takes the longest and a video session the shortest, but that’s the experience of this contact center.

How about succeeding to close a deal and make a sale? WebRTC gets closed deals 25% more than regular phone calls. Chat is slightly less successful than WebRTC but more successful as phone. These values were measured on session landing at sales agents’ desk once those irrelevant and redirected were filtered out.

And the customer satisfaction? Over 20% rate the service 5 stars at the end of the interaction and 7% left positive textual evaluation of the service. Compared to the traditional IVR system that’s really high.

Where does this lead us?
  1. There are many ways to deploy WebRTC in a contact center
  2. WebRTC is already being used by contact centers – successfully
  3. Done right, there’s huge value in adding WebRTC to your customer engagement. It adds efficiency and improves customer satisfaction, resulting with higher value to both sales and care
Want to learn more of the various ways WebRTC fits in with contact centers?

Get my free WebRTC Contact Center Uses Swipefile

And if you are looking for more information about the O2 CZ deployment details – especially the technical ones, Jaroslav will be happy to have a conversation with you.

 

The post What to Expect when Deploying WebRTC in Contact Centers? appeared first on BlogGeek.me.

6 Questions to Ask Yourself BEFORE Hiring a WebRTC Outsourcing Vendor

Mon, 05/01/2017 - 12:00

How do you find good WebRTC outsourcing talent?

At least once a week.

That’s about the current rate in which I bump into a hiring or talent question related to WebRTC.

Recently, I got a few calls with companies that went through the process of working with an outsourcing vendor who developed their app and got stuck.

Sometimes it was due to bad blood going between the two companies. But more often than not it was because the company that approached me wasn’t happy with the delivered results. The application that was developed just didn’t really work as expected. Looking at some of these apps, it was easily apparent to see that the developers were clueless about WebRTC. Things like wrong NAT traversal configurations (or none at all), or the use of mesh media delivery for large multiparty video sessions are the most obvious warning signs here.

If I had to think why this is so, my guess it boils down to three reasons:

  1. WebRTC is still rather new. 5 years. So there’s still not enough mileage on it for most developers
  2. It isn’t Web and it isn’t VoIP. But it is also Web and VoIP together. Which means many seem to misunderstand it
  3. Skilled WebRTC developers are hard to find. Less than 12,000 profiles with that term on LinkedIn’s now 500 million profiles

When you go and ask from an outsourcing vendor to build you a service, the answer you will get is “sure thing”. And then a price and a timeline. That’s their business, and most would often use that project as their jumping board towards another domain of expertise for them. Many of these outsourcing vendors won’t invest in learning new technologies without a customer paying for that investment.

This means that a lot of the market for WebRTC outsourcing is a market of lemons. Which is why it is so important you check and validate your prospective WebRTC outsourcing vendor before signing an agreement with him.

Picked a WebRTC outsourcing vendor? Here are a few quick telltale signs that will help you determine just how knowledgeable he is about WebRTC:

Get the WebRTC Outsourcing Vendor Signals swipefile

Here are 6 questions to ask yourself before you hire a WebRTC outsourcing vendor.

#1 – Do I know my own requirements?

There are two parts to knowing your requirements from the product:

  1. Knowing and understanding your business and the interactions you want for it
  2. Understanding what’s realistic for you with WebRTC to set your expectations accordingly – this also means understanding the costs of certain features versus how important they are for you

For that, I suggest you use something like my WebRTC requirements template.

#2 – Am I their first WebRTC customer?

This is a biggie.

Try. Not. To be. Their FIRST. Customer. That does. WebRTC.

Don’t be their first customer doing WebRTC.

Make sure you’re not the first one they build a WebRTC product for.

Their first WebRTC project? You shouldn’t be the one they do it for.

Got the point?

One more time if you missed it:

I knew that picture (and font) would come in handy some day.

#3 – Is the team working for me built a WebRTC product before?

This one is somewhat tricky, and I must say – a bit new in my list of top questions to a WebRTC outsourcing vendor.

If you’ve been reading this from the start instead of skimming through, you might have seen the number 12,000. This number is higher than the number of profiles in LinkedIn that have the term WebRTC in them anywhere. It means that with some of these WebRTC outsourcing vendors, the people put in place on your project might not be the ones who know WebRTC – these are already fully booked by other clients – or they might have gone elsewhere (with the demand of WebRTC developers, I wouldn’t be surprised to see them learn the trade in one vendor and move on to the next).

I’ve seen it happen once or twice before.

So make sure that not only does the vendor knows WebRTC well – he is also placing the right people on your project. And understand that there are times when not the whole team must know WebRTC to develop a successful project.

#4 – Can I validate what they build for me?

Developers who don’t know and understand WebRTC won’t be able to deliver a commercial product for you.

If they don’t understand the server side of WebRTC and its implications (check my free mini course on WebRTC server side), then the end result will run great between you and your pal sitting next to you, but when you take it to production it will fail spectacularly.

Things to look for:

  1. Not configuring NAT traversal properly (public STUN servers, no TURN servers, no TCP or TLS configurations for TURN)
  2. Using mesh instead of mixing or routing the media (see here) – in plain English, not using a media server in scenarios that beg for it to be used
  3. Not testing for scale (see here)
  4. Not checking the result in varying network conditions

While some of these can be solved just by more testing (and focused testing – one where the tester actually knows what to look for), there are times when the architecture selected for the product is just all wrong. It should have been apparent from the get go that it won’t hold water.

But anyways – make sure you’ve got a plan in place on what and how to test to validate that that thing that was given to you as the finished good is actually the finished good and not finished for good.

#5 – Should I ask for something On Premise or CPaaS based?

This goes back to #1, but slightly different. Probably should have placed it as #2.

Developing your own product from scratch will be more expensive than using a CPaaS vendor. CPaaS vendors are those vendors that take the whole hassle of real time communications, wrap it with their nice API and manage it all for you (and yes, I wrote a report about them).

Whenever I sit down with an entrepreneur that wants a product I start there when it comes to vendor and technology stack selections. Trying to understand his restrictions and requirements. Oftentimes, entrepreneurs are deterred by the seemingly high pricing of CPaaS vendors. Especially at the beginning – when they believe they will get to a million monthly active subscribers within a month. Well… it won’t happen to you. And if it does, a VC or two will probably be happy to foot that bill, understanding you probably found a real boon.

What should you do?

  1. Read this one. And then read this one from Chris Kranky
  2. Make your  decision on that build vs buy decision (in both you will be building – don’t worry)
  3. Revisit your initial requirements
  4. Revisit that vendor you plan on working with
#6 – Who is the owner of this project on my end?

Someone needs to be the owner of this project on your end.

Yes. You have a WebRTC outsourcing vendor developing this thing for you, but you need someone to have that vendor behave and deliver.

That someone needs to understand WebRTC well enough to handle the requirements, the discussions with the vendor for all the issues that will arise along the way.

I’d also recommend having that someone on the payroll and not external.

If you don’t have such a someone then you effectively selected you for that job. Congrats!

Do Your Homework

If you plan on starting a project that makes use of WebRTC, and you plan on using a WebRTC outsourcing vendor for it, start by doing your homework.

Make sure you have the answers to the questions above.

And if you need help along the way – with the requirements, the architecture, the vendor to select, the process – you know where to find me.

Picked a WebRTC outsourcing vendor? Here are a few quick telltale signs that will help you determine just how knowledgeable he is about WebRTC:

Get the WebRTC Outsourcing Vendor Signals swipefile

The post 6 Questions to Ask Yourself BEFORE Hiring a WebRTC Outsourcing Vendor appeared first on BlogGeek.me.

Should Browser Vendors be Responsible for their User’s WebRTC Actions?

Mon, 04/24/2017 - 12:00

Security is… complex. Even with WebRTC.

I’ve always been one to praise the security measures placed in  WebRTC.

While WebRTC is a secure protocol by nature, it seems that browsers take different approaches to who needs to take responsibility of any additional means of security.

The gist of it:

  • WebRTC is secure by default
  • Whenever a developer’s mistake can be thwarted by tweaking WebRTC – it gets tweaked
  • Whenever a security hole is found, it gets fixed and deployed by the browser vendors faster than most other companies in the industry can even perceive the notion of a threat

Seriously – what’s not to like?

Recently though, I started thinking about it. How do browser vendors think about security? How much do they take it upon themselves to be the guardians of their users? His trusted guide in the big bad world that is the Internet?

Which brings me to the big one –

Are browser vendors responsible to the actions of their users when it comes to WebRTC?

It seems that they have different approaches and concepts to this one.

Google Chrome

Moto: Users are stupid and should be protected

That’s how I’d put their mindset to words.

getUserMedia

Chrome has long been one to clamp down on where and when can WebRTC be used.

They started off with voice and video working on HTTP and HTTPS, while HTTP access granting to the camera and microphone were forgotten, and required a user’s approval each and every time.

They shifted towards HTTPS only. You can’t access the microphone or the camera in an HTTP page.

Persistence

The decision a user made is persistent. If you granted a domain access to your microphone or camera – Chrome remembers it – for eternity. Your only way of revoking that is by clicking the camera icon on the address bar (if you can even notice it):

Oh, and for persistency – Chrome offers you two choices:

  1. Ask when there’s a need (and Chrome will remember the answer for that domain for you)
  2. Never ever share your device

No middle-ground here.

Screen sharing

You can share your screen with Chrome.

But it will ask the user each time for his permission.

And to enable screen sharing, you will first need to create a Chrome Extension for your web app and have the user install it. Not a biggie, but a hurdle.

Now, to publish a Chrome Extension on the Chrome Web Store, you’ll need to pay a small $5 fee.

Why? Fraud – obviously:

You see, screen sharing is considered by Google (and most other browsers) as more of a security threat than camera and microphone access.

By forcing the Chrome Extension, Google raises the bar against abuse, and can theoretically remove any abusive accounts and extensions with better tracability to their source.

The only real downside of it? I have over 10 icons on my toolbar now in Chrome, and most of them are for screen sharing on different services. Once a move I remove a few of them to declutter my browser. Yuck.

Mozilla Firefox

Moto: Users are intelligent

Maybe. But not all of humanity. Or even the billion or two that use browsers.

getUserMedia

In Firefox, getUserMedia will work in HTTP.

Not sure if persistence can be configured for Firefox for HTTP websites. I guess it is akin to herd immunity in vaccination. Since Chrome is THE browser, developers make sure their WebRTC service works on Chrome (lets call it Chrome first?) so their service starts by running only on HTTPS anyway.

Persistence

Anyways, Philipp Hancke wrote a great post about getUserMedia and timing with browsers. Here’s how timing looks for appear.in from the moment getUserMedia is called and until it is completed:

Firefox tend to take longer to complete its getUserMedia calls. Philipp attributes it to this little UI design in Firefox:

In Firefox, if you want to decision (allow/disallow) to be persisted, you need to opt in for it. And for appear.in, most people don’t opt in.

This is great, especially for the Don’t Allow option (it is quite a hassle to remove that restriction from Chrome once you decided not to allow such access in a session).

Screen sharing

For screen sharing, Firefox used to have a whitelist of domains you had to register on to get screen sharing to work.

From Firefox 52, this restriction has been removed. Mozilla wrote a post about it, explaining their millions of users around the world about the dangers.

I am not sure about you, but I’ve learned early on as a developer catering to developers that other developers are stupid (if you are a developer, then I am sorry, but bear with me – and read this one while you’re at it). So when I wrote code for developers, I made sure that if they screw things up, we crash spectacularly. The reasoning was, the sooner we crash the faster our customers (who are developers) will fix their bugs – and do that during development – so they won’t get into deadlocks or weird crashes in production that are way harder to find. These were the good old days of C programming.

Now… if developers are stupid, then what would mere users do about their understanding of security and threats?

In Firefox, they need to read and understand that yellowish warning when all they want to do is share their screen now – after all – people are waiting for them to do so in the session already.

With such a warning… I am not sure I am going to be in a trusting mood no matter the site.

While I mostly prefer Firefox approach for getUserMedia permissions, I think Chrome does a better job at it with the extensions mechanism.

Microsoft Edge

Microsoft Edge has started to support WebRTC (finally).

While I a, in the process of installing my Creators update (where I am promised proper support for WebRTC), this will take more time than I have to get some nice screenshots of what Edge is doing.

So I asked Philipp Hancke (like I do about these things).

Here’s what I got:

  • Edge enable persistence for getUserMedia
  • It has a model similar to Firefox – you need to opt-in for persistency
  • It doesn’t support screen sharing yet

Download the WebRTC Device Cheat Sheet to learn more on how to get WebRTC to as many devices and environments as possible.

Are Browser Vendors Responsible for Our WebRTC Actions?

Yes they are.

In the same approach that browser vendors are taking in HTTPS everywhere, removing Flash from the web, protecting against known phishing sites, etc; they need to also protect users from the abuse of WebRTC.

The first step is by not allowing developers to do stupid (by forcing encryption and DTLS-SRTP for example). The second one and just as important is by not allowing users to do stupid.

 

The post Should Browser Vendors be Responsible for their User’s WebRTC Actions? appeared first on BlogGeek.me.

How to find (or create) WebRTC Developers?

Mon, 04/17/2017 - 12:00

And I have a couple of bonuses waiting for you in this WebRTC course launch.

I’ve been thinking lately on how to make this course available throughout the year, but still “launch” it as a live program once or twice every year. The idea here is to get as many people as possible into the course and improve our current market state (which is rather abysmal):

I always say that WebRTC sits between Web and VoIP, but I guess this says it best.

You can find a million people whose profile contain either “VoIP” or “HTML5”. If you go into specifics, you’ll have hundred of thousands of people with either “SIP” or “Node.js”. But “WebRTC”? Only 11,874 righteous people. We’re a pretty small industry. And those with enough understanding and knowledge of WebRTC? Probably less than that.

What are people challenged with?

The request that comes up almost every time someone contacts me through the blog? It is about finding an experienced WebRTC developer. Here are a few “sound bites” from these emails I am getting:

if we were to hire someone to build our own platform – what qualifications in a programmer would I need to look for?!!

 

We are needing to develop video chat and having a difficult time finding a qualified developer to create this

 

I am seeking a WebRTC engineer to do a peer review on a WebRTC app I had developed in oversees (west Russia.)

 

A couple of thoughts about this
  1. If you are a developer and you know WebRTC well, then your talents are in high demand – and if you aren’t conversant in WebRTC, this can be an opportunity for you to learn and grow
  2. If you are an employer and you need someone to build a real time comms product, you’re going to be hard pressed to find good talent. Your three best choices are:
    1. Outsource the whole project to a company who is skilled in WebRTC
    2. Hire a freelancer to help your team with the WebRTC parts
    3. Grow your in-house team to make them skilled with WebRTC
  3. If you are an outsourcing vendor and you have WebRTC talent, then you’ve got a different set of challenges:
    1. The more projects you take, the more WebRTC talent you need, which means you are back to the hiring challenge as anyone else
    2. Your best WebRTC talent is always on high demand outside, getting job proposals and needing to think how happy are they (so you have a retention issue in your hands, which gets worse due to the high demands of the skillset you are nurturing)

And since the market is so slim on resources (around 12,000 people know WebRTC out of a million who know VoIP – when all VoIP projects are adding WebRTC these days), demand and supply don’t match.

My WebRTC course and its bonuses

Tomorrow, my Advanced WebRTC Architecture course officially launches. If you haven’t enrolled already, then you should seriously consider doing so.

The previous round had almost 100 students going through it with some very positive feedback.

There are going to be a few bonus materials that I will be giving for anyone who enrolls today (or already enrolled):

#1 – 2 live lessons

There are going to be 2 special live lessons taking place. They will be recorded for those who can’t join live. But the lessons as well as the recordings will only be available as part of the course bonuses.

LIVE Lesson 1: Philipp Hancke – Video Quality in WebRTC: The audio and video quality WebRTC provides is amazing. Well, most of the time at least. Sometimes, the video gets pixelated and audio starts dropping out even. What is going on here and why is bandwidth estimation still a problem?

LIVE Lesson 2: Bradley T. Hughes – How to deploy TURN on AWS? TURN servers are boring. They do nothing but relay data. However, they are necessary in WebRTC. Here’s how appear.in’s global TURN infrastructure works – and how you should think of when deploying your own.

So…

2 live lessons.

With top industry experts.

Recorded and available only for you.

#2 – The Perfect WebRTC Developer Profile ebook

Recently I’ve been asked multiple times about CVs and profiles and stuff. It goes both ways:

  1. Recruiters want to know what experience to look for in order to find experienced WebRTC developers
  2. Developers want to know what to learn and put in their CV to be attractive

I had my own thoughts about it, but decided to take a different route on this one. I went and asked top developers and “recruiters” who work with WebRTC for quite some time now. I asked them about the ideal WebRTC developer and what they’d look for in a CV. Collected the answers and created an ebook out of it:

Who’s in there? Amir Zmora, Arin Sime, Chad Hart, Emil Ivov, Gustavo García, Iñaki Baz Castillo and Philipp Hancke.

You’ll get to see what they think about WebRTC developers and what it means to be a WebRTC professional.

#3 – WebRTC Course FAQ

There are a lot of popular questions out there about WebRTC. You can find them lurking on webrtc-discuss forum, stackoverflow, Quora and elsewhere. But what are the answers? And how should you go about finding them?

What I did in the past few weeks was collect questions and map them to the course lessons. To these questions I provided short and clear answers for you, packaging it all in a neat document.

Now, you can use these questions to tackle specific issues you bump into – or to check how much you understood of the lessons of the course. Hell – if you need to recruit someone – you might as well use it as some good questions to ask to gauge experience.

What if you are not sure?

Besides looking at the testimonials from previous students, I can suggest checking out two things:

  1. My free WebRTC server side mini-course. You can expect this kind of content in the course itself, just on a deeper level, on a lot more WebRTC related topics AND with the option of asking questions on the online course forum or during the live Office Hours
  2. Join me for the WebRTC Course AMA on Wednesday this week. I will be answering any questions related to WebRTC or the course, so you can make your decision about enrolling to the course (or just get some free advice for your current project)
What if you wait and don’t enroll today?

Bonuses will go away in 48 hours.

After that, the only price plan available for the course will be the Plus price plan and it will only include the Office Hours for the initial duration of this course.

My suggestion?

Enroll now to the Advanced WebRTC Course

The post How to find (or create) WebRTC Developers? appeared first on BlogGeek.me.

My Advanced WebRTC Architecture Course is back with an AMA

Tue, 04/11/2017 - 12:00

Have questions about my course? Here’s a WebRTC Course AMA for you.

Later this week, I will be opening my Advanced WebRTC Architecture course for enrollment again.

Last year, I decided to launch a course to teach WebRTC. Something different than just going through the WebRTC APIs or explaining the network specification. The end result? A 100 people enrolled and when through the course (!) And more than that – people seemed to be genuinely satisfied with it (!!)

It was fun, so it is time to do it again.

While I am changing and adding stuff to the course, the baseline material is going to stay the same – most of it is “timeless” anyway.

I am adding to this round a couple of things, and this one I want to mention two of them:

#1 – Corporate Plans

The course now has a corporate plan, for larger teams who need to use WebRTC. I’ve got a couple of companies already enrolled to it, which is great.

Corporate plans include a private Slack forum for Q&As alongside the course’ forum. They also include a corporate badge that you can use on your own site, along with their logo on my own site as Corporate Partners.

If you want to learn more about the corporate plans, check out the course syllabus (PDF).

#2 – Course AMA

Philipp forced my hands on this one…

Really looking forward to @tsahil's #WebRTC architecture course: https://t.co/srDBNUuN46
We have a bet running if he can teach me things!

— Philipp Hancke (@HCornflower) April 7, 2017

Only thing left to do is…

But seriously.

I am trying to make this the best place for people to get their WebRTC education.

For those who aren’t sure yet, I’ll be hosting a WebRTC Course AMA, where you can Ask Me Anything. About the course. About WebRTC. About me. About the weather (though I know nothing interesting about the weather).

The WebRTC Course AMA is free to attend. It will be part webinar, part Q&A, but mostly fun.

Philipp – you are hereby cordially invited to join as well

Register to the WebRTC Course AMA – and even write down your questions on the event’s page right now – no need to wait until the 19th for that!

#3 – A few more launch bonuses

For those who end up enrolling early, I’ll have a few additional launch bonuses, but that’s for later.

On a personal note, today is Passover here in Israel.  If I seemed somewhat “off” in the past couple of days (or will seem like that in the coming days), then it probably has to do with me eating too much food and spending some time with my family.

 

The post My Advanced WebRTC Architecture Course is back with an AMA appeared first on BlogGeek.me.

Why Doesn’t Google Provide a Free TURN Server?

Mon, 04/03/2017 - 12:00

No such thing as free lunch. Or a free TURN server.

It is now 2017 and WebRTC has been with us for over 5 years now. You’d think that by now people would know enough about WebRTC so that noob questions won’t be with us anymore. But that just isn’t the case.

Want to learn more about WebRTC server requirements and specifications? Enroll now to my 3-part video mini-course for free:
  • Email*
  • CommentsThis field is for validation purposes and should be left unchanged.
jQuery(document).bind('gform_post_render', function(event, formId, currentPage){if(formId == 18) {if(typeof Placeholders != 'undefined'){ Placeholders.enable(); }} } );jQuery(document).bind('gform_post_conditional_logic', function(event, formId, fields, isInit){} );jQuery(document).ready(function(){jQuery(document).trigger('gform_post_render', [18, 1]) } );

One question that comes up from time to time is why doesn’t Google (or anyone else for that matter) offer a free TURN server?

Besides the fact that you shouldn’t be using free STUN or TURN servers that are out there simply because you have zero way to control them when things go wrong, lets first understand what’s the difference between these two servers – or more accurately protocols, since STUN and TURN usually end up being deployed together.

How STUN works

The illustration below should give you the gist of how STUN works:

When STUN is used, the browser or any other WebRTC enabled device sends out a message to the STUN server asking him “who am I?”. The idea here that STUN is used to find out your public IP address. This is something your machine doesn’t know on its own as this “allocation” happens by the NAT you are behind (and you will almost always be behind a NAT). That information is also dynamic in nature – you can’t really rely on the same answer being received each time – or that the pinhole generated by the query itself will stay open.

This is a simple question that the STUN can provide a single answer for. Furthermore, this takes place over UDP, making it lightweight and quick – not even requiring establishing a longstanding connection or having context in place.

Once the browser has the answer, he can share it, and if all else works as expected, he will be receiving media directly.

The STUN’s role here was limited to this single question at the beginning.

How TURN works

Here’s how TURN works:

When it comes to TURN, we start with a request for binding – our browser is practically asking the TURN server if he can be used as a relay point. And if the TURN server obliges, then it can now be used to receive all media from the other device on the session and relay that to our own browser.

While the initial binding request isn’t taxing (though still more expensive on our TURN server than the query sent to the STUN server), the real issue is the media that gets relayed.

If you take a simple WebRTC video session that gets limited to 500kbps or so, then a 15 minute session will end up eating…

That ends up being over 50MB in traffic. Assuming we do only 10 sessions an hour on average on that TURN server, we end up with 360GB in traffic per month. And that for quite a small service. It isn’t really expensive, but it does if you scale it up: use more bandwidth per session, have more sessions per hour on average – and you’re going to end up with lots of data traffic.

Here’s how a recent stress run we’ve had on testRTC ended up:

For a stress test with 500 participants, split into group of 5 browsers per multiparty call, running for only 6.5 minutes, we ended up with 52Gb of media traffic in each direction. Less than 10 minutes.

Now think what happens if all that traffic need to go through a TURN server. And that TURN server is free for all.

Putting it all together

STUN and TURN are drastically different from each other. We need both in real production WebRTC services. And we usually think of them of a single server entity deployed in the backend – for STUN we simply don’t fret about the resource needs it has and focus on what we need to get TURN running in scale and in multiple geographical locations.

It is also standard practice to clamp down on your TURN server and have credentials configured for it. For WebRTC, these credentials need to be ephemeral in nature – created per session on demand and not per user (as often is the case in SIP).

So…

  • If you are wondering why there are no free TURN server out there, or good code on github that has TURN already configured for it that works – don’t. It makes no sense for anyone to give that for free
  • If you happen to bump into a TURN server with user/password credentials that work, then please don’t make use of them – someone ends up footing the bill for you – and he is probably doing it without even knowing (he wasn’t aware of the abuse potential I am assuming)
  • And if you still end up using that TURN server (nasty you) – expect that person to find that out at some point and just shut you out of his server – not something you want happening if you have users for your service
Want to learn more about WebRTC servers?

Tomorrow, I will be launching a free video mini-course. This course explains what servers you will need to deploy for your WebRTC product, what are their machine specifications and what are the tools that are out there to assist you developing them faster.

Want to learn more about WebRTC server requirements and specifications? Enroll now to my 3-part video mini-course for free:
  • Email*
  • CommentsThis field is for validation purposes and should be left unchanged.
jQuery(document).bind('gform_post_render', function(event, formId, currentPage){if(formId == 18) {if(typeof Placeholders != 'undefined'){ Placeholders.enable(); }} } );jQuery(document).bind('gform_post_conditional_logic', function(event, formId, fields, isInit){} );jQuery(document).ready(function(){jQuery(document).trigger('gform_post_render', [18, 1]) } );

The post Why Doesn’t Google Provide a Free TURN Server? appeared first on BlogGeek.me.

How to Get Started Learning WebRTC Development

Mon, 03/27/2017 - 12:00

So you’ve been using WebRTC for a while, or even not at all. You might have checked out AppRTC or took a piece of code from github and forked it, running your own server (yay!). But now you’re feeling stuck, unable to become a serious WebRTC developer.

WebRTC developers come in different shapes and sizes. They usually have one of two origin stories:

  1. They were VoIP developers 10 years ago (that can mean anything from played with the configuration of an Asterisk installation to wrote their own RTP stack)
  2. They are web developers (which can easily be implementing WordPress sites on top of premium themes, but can just as well be building backends used by the Facebooks of the world)

The challenge though is that WebRTC sits somewhere between these two very different disciplines that are VoIP and Web:

Me? I’ve got a VoIP developer origin story. I wrote my own static memory, no-recursion implementation of an ASN.1 PER encoder/decoder. Dealt with scaling linearly a UDP/TCP sockets implementation on different operating systems. Handled multi-threading in C code. Low level stuff that most developers today don’t even grok. While these are great starting points, they don’t really offer any way of making the transition to WebRTC.

This isn’t about WebRTC. It is about understanding the different mindsets and approaches of developing VoIP products and developing Internet web applications. And it requires being able to learn new techniques and new ways of thinking.

While I won’t take you through that journey here, I can help you formulate a plan. In this article, we’ll explore together three things you can start doing today to make the jump from VoIP or Web to an experienced WebRTC developer.

What Don’t You Know?

The first thing you need to get a handle on is what you need to learn. Some might think that all you need to know to be a WebRTC developer is HTML, CSS, and a bit of JavaScript. Taking a github project that makes use of WebRTC, install and run it on your own. And you’re ready!

While that is certainly a good start, developing with WebRTC isn’t as easy as just learning a bit of JavaScript. Or Node.js for that matter.

To really call yourself a WebRTC developer, you’ll need to get a handle on a wide range of topics:

  • WebRTC APIs: That’s quite an understandable requirement from a WebRTC developer
  • Front-end development: HTML, CSS and JavaScript
  • Backend development: Node.js or some other modern asynchronous development platform
  • Networking: TCP, UDP, HTTP, WebSocket and anything in-between these concepts
  • Codecs and media processing: How codecs are designed and implemented, what are the algorithms and techniques used to send them over a network – using SRTP. Extra credit for understanding Simulcast and SVC
  • Server side media processing: Knowing the different techniques that can be used to support group calling, live broadcasts, recording, etc.
  • Troubleshooting and monitoring tools: to include, at a minimum, how to read webrtc-internals dump files and understand ICE failures
  • Common frameworks: know the popular frameworks that are out there and what they are good for. It doesn’t hurt to have some understanding of Jitsi, Kurento and Janus for example

With these skills and knowledge base in hand, you’ll be able to create virtually any real time communications product. That might seem like a lot to learn, but I want to share some resources below that you can use to learn about each of these topics relatively quickly. In addition, you don’t have to be an expert in every one of these topics, but as a WebRTC developer, you do need to have some basic familiarity with each and every one of these topics. I know I am not an expert in any of these…

Now that you know what you need to know, let’s look at the top three ways you can learn what you need to learn.

#1- Learn WebRTC Development by Reading Subscribing to WebRTC related blogs is one of the ways you can keep your development skills up-to-date

One of the best things you can do to grow in your knowledge about any topic is to read and follow along with posts and tutorials written by other experts in the industry. WebRTC is no different in this regard.

There aren’t many WebRTC blogs out there, but you’ll still want to focus to get maximum value here. Pick up just a few-quality blogs to follow. I try subscribing to ALL of them, mainly because it is my job to know as much as I can about the WebRTC market AND because I need to curate the WebRTC Weekly. What I do follow closely and make sure I read and understand when it comes to hard core WebRTC development amounts to just three main blogs:

  • webrtcHacks: High quality content about WebRTC for developers. That sums it up…
  • Mozilla’s Advancing WebRTC: Mozilla recently started a new blog dedicated to WebRTC. Quality there is top notch and the information is really useful. It covers small issues related to WebRTC and offers code snippets that are very useful
  • Philipp Hancke: If there’s anyone who knows… everything (?) about WebRTC it is Philipp. He is methodical with his approach to WebRTC and analyzing browsers behavior. Every time he writes and publishes something, I end up learning at least one new thing
  • WebRTC Weekly: Yap. I curate this one with Kranky. This one gives you the pulse of what’s happening with WebRTC, so following it can get you faster to the content that others are writing – especially those who don’t publish as much as I’d like them to

Pick a few blogs that you want to follow and subscribe to them. You don’t have to read everything they publish, but make sure that on a regular basis you read technical articles that stretch and challenge your developer muscles. That’s my approach here and I don’t consider myself a developer anymore. You probably take the next step as well and open a code editor and try the code snippets that the articles you read publish.

#2 – Learn WebRTC Development by Studying The Advanced WebRTC Architecture course offers a holistic view of WebRTC development

Reading about WenRTC is ongoing maintenance that you must do to keep up-to-date – especially because WebRTC changes all the time and there’s no solid specification out there just yet. To really develop new skills quickly some formal education is in order.

There are a couple of online courses about WebRTC out there that you can find. Those that I’ve seen focus on the WebRTC APIs piece which is great to start with WebRTC. The challenge though is that WebRTC is still not standardized, so things change to quickly for such content to be kept up to date.

Out of these courses, I guess there are two places where you can learn extensively about WebRTC:

  • Google’s WebRTC Codelab: This was put by Google as an introductory course on using WebRTC. It will get you through the basic concepts of WebRTC with a fast time-to-results when it comes to getting a first simple proof of concept out there
  • WebRTC School: The focus of the WebRTC classes of the WebRTC school is the WebRTC API and how to use it. For those who need to develop tomorrow with WebRTC directly, this is a great resource to begin with
  • Advanced WebRTC Architecture: This is the course that I offer here on this site. I decided NOT to focus on the WebRTC APIs and just skim through them. I tried covering more of the backend part in my course and just getting students to a point where they can build their own product architectures with all of its backend glory
  • Kranky Geek: for the visual types, I’d sugget checking out the topics curated by Kranky Geek (I am a part of that team). You’ll get high quality content there on specific topics in WebRTC development

Other than WebRTC, make sure to look at other courses as well – things around fullstack web development or Node.js development courses at the likes of Udemy, Codecademy or Pluralsight.

How about books?

I have a nagging feeling that goes with me for a few months now.

There hasn’t been any new book published about WebRTC in over a year.

I believe June 2015 was the last time a new WebRTC book got published.

Now, if reading and learning from books is still a thing for you, then check out this roundup of WebRTC books – it is still valid today as it were then.

Oh – and make sure you read High Performance Browser Networking if you are doing anything with web browsers (and especially if you are planning on using WebRTC and cobble up your own signaling).

#3 – Learn WebRTC Development by Doing Working and writing about your projects can further help cement what you read and learn about

Reading about WebRTC development will keep you sharp. Studying WebRTC development will help you develop new skills and give you solid understanding of the technology. But to really grow as a developer you’ve got to find opportunities to put all of that education to good use.

I can think of four different ways you can put your education to good use:

  1. Build out personal projects – a blog, a personal portfolio, a hobby site. Create personal projects that really stretch you and that you’ll have to figure out as you go. I guess Muaz Khan does this best. I really liked how Brian Ho shared his experience recently on using WebRTC in a client-server web game
  2. Build products for paying clients – You wouldn’t believe how many vendors are out there looking for capable hands when it comes to WebRTC development
  3. Write about the new skills you’re learning and publish them on your own blog or better yet – submit it to webrtcHacks. There’s nothing that will ensure you really understand a topic like writing a tutorial about it
  4. Become a WebRTC professional –  Once you have the requisite knowledge and a bit of experience, you might want to join a WebRTC outsourcing company that is actively building products with WebRTC. Here’s how Germán Goldenstein puts it – you really can’t ask for more than this as a developer. It reminded my what I love so much about developing and working with developers
What will you do tomorrow?

There’s a paradox in our industry.

For one, WebRTC is stupidly simple (if you compare it to doing the same things before WebRTC). But at the same time, there aren’t a lot of experienced developers out there that know how to use it. Talk to employers who are looking for WebRTC skills and you’ll see how hard it is to come by – most end up with using internal resources they grow into WebRTC developers – sometimes after a really bad experience with an external outsourcing vendor that knows how to build websites or mobile apps, but know nothing about WebRTC.

If you’re ready to move past copy+paste implementations from github of Hello World WebRTC concepts and become a real WebRTC developer. However, if you’re ready to mobe past implementation or hobby and become a real WebRTC developer all you need is a plan and the self-discipline to stick to it.

Your plan should include three core learning activities: reading, studying, and doing. Work on those three activities on a consistent basis and it won’t be long before you’ve left the hobby behind and grown into a WebRTC professional developer.

Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.

The post How to Get Started Learning WebRTC Development appeared first on BlogGeek.me.

Does WebRTC has a Role in Chrome’s Market Dominance?

Mon, 03/20/2017 - 12:00

WebRTC, Chrome, Market share. These are all intertwined, but WebRTC isn’t the only reason Chrome is dominant today.

The nagging question about support of WebRTC in Internet Explorer and Safari refuse to go away. I hear them almost on a daily basis in meetings I have, emails I receive and posts I read. In recent months. Things being what they are for the past 5 years or so, I have decided to ask a slightly different question –

If a browser doesn’t support WebRTC – will it hurt the browser’s adoption?

My inclination until recently was that WebRTC doesn’t matter that much. It is a great technology, but it won’t really hurt the market share of browser vendors that decide not to adopt it wholeheartedly.

Want to run WebRTC on anything? Check out my free WebRTC Device Cheat Sheet.

And then I read this story: Safari browser sheds users, mimicking IE

According to California-based analytics vendor Net Applications, in March 2015, an estimated 69% of all Mac owners used Safari to go online. But by last month, that number had dropped to 56%, a drop of 13 percentage points — representing a decline of nearly a fifth of the share of two years prior.

I took the liberty of using StatCounter for my own check, focusing on the desktop browser and operating system (mobile is different opera).

Here’s what you’ll find when you look from the beginning of 2012 and up until today – roughly the time frame of WebRTC’s existence:

What can we see here?

  1. Edge starting to see “some” traction, but a lot less than what you’d expect. I’ve covered that one before
  2. Internet Explorer is on the decline, with the bitter end already known
  3. Firefox shedding users
  4. Safari keeping in the 5% market share – we will get back to this one in a second
  5. Chrome is the only browser that is increasing its market share, apparently grabbing it from all other browsers
  6. If you think at WebRTC Chrome market share, I am sure numbers will look a lot more in favor of Chrome – and not only because Safari and IE don’t support WebRTC

Is Safari really keeping its market share or losing market share? To answer that question, we need to look at the desktop operating systems market share for that same period:

I’ll make it simple for you. In the past 5 years, OS X grew from around 7% to over 11%. That’s a growth of over 50% in its market share.

While at the same time, Safari, available only on OS X AND the default browser on OS X – didn’t grew in its market share.

Which means that people using Mac OS X are now more inclined towards using Chrome than they were 5 years ago.

Today, people CHOOSE their browser on the desktop and don’t use the default one provided to them by the operating system.

And when they choose, they more often than not pick Chrome.

I know:

  • Statistics are just that, and it all depends on what you count – but there’s a trend here that is being counted through a long period of time that is hard to ignore
  • It depends on regions, as there are areas who are still predominantly IE and countries with people who love Firefox
Why is Chrome our default browser these days?

This is a tough question to answer. For me, it is the one I am most comfortable with. Since I switched to it from Firefox years ago, I never looked back – and when I do – I just return back to Chrome.

If I had to estimate, it has to do with developers. It isn’t quite related to APIs, apps or the creation of developer ecosystems where innovation and value creation happens.

No. It is about developers as early adopters.

The people who spread the word and get their friends and family to switch browsers when things don’t work for them.

The people who end up building websites and working on them daily on… Chrome… which brings it all into a virtuous cycle, as now sites work better on Chrome, so you end up having more users use it, which means developers will target it first, increasing its popularity.

Google has done a lot to get it there. It started by making a lean and mean browser that had tabs crash independently of each other, and from there it grew with the set of rich developer tools it has and the technologies packed into it.

Other browsers have been trying recently to innovate as well, but it seems this haven’t caught on with the mainstream crowds just yet.

Is this a good thing?

Today, Chrome is the de facto standard for browser behavior.

There are other browsers as well, but their market share is declining – not growing or even stagnating. If this continues, Chrome will become the only play in town on the desktop.

This isn’t a good thing. It gives too much power in the hands of Google.

That said, Chrome is mostly open source (Chromium), it adheres to standards as much as can be expected from a product used by so many people daily.

But  they can change their minds at some point in the future.

On the other hand, we’re now all mobile, and there, the browser is a lot less important.

What does that mean for WebRTC?

as stated, Chrome is the de facto standard for browser behavior.

So much so that Edge is doing its best to look like a Chrome browser to developers, making it easier to interoperate with.

Should you develop based on the WebRTC specification? No.

You should develop based on what’s available in Chrome and what is planned for it in the mid term, as well as make use of adapter.js.

There’s the W3C flavor of WebRTC and then there’s the Chrome implementation of WebRTC.

Developers should stick to the Chrome implementation of WebRTC.

If you need WebRTC to work for you, you’ll need to understand how to get it running on any device and browser. My WebRTC Device Cheat Sheet is still as relevant as ever. It’s free, so go ahead and download it.

Get the cheet sheet

The post Does WebRTC has a Role in Chrome’s Market Dominance? appeared first on BlogGeek.me.

What’s up with WebRTC Video as a Service in 2017

Mon, 03/13/2017 - 12:00

Is it finally the year of video? Who knows.

Up until recently, there wasn’t much out there for anyone who wanted to really use video in his use case. In the past few months we’ve seen so many announcements and moves that makes video as a service seem almost commonplace.

Who are these new and old players and what is it that they are doing in 2017?

TokBox

TokBox has been the main player when it comes to multiparty video with WebRTC. In 2012, they got acquired by Telefonica, but left as an independent entity. This gives them stability of sorts.

Their main competitor – AddLive – got acquired in 2014 and taken off market. Other vendors tried to enter that same niche, but no one caught on in the same way.

What’s interesting is the path that TokBox selected for itself. It is resisting the path of connecting to legacy directly. Their offering doesn’t include PSTN or phone numbers. On the other hand, they have been progressing and expanding their video support into broadcast.

Their recent announcement tells a story of large scale live broadcast:

  1. 3,000 real-time interactive users. TokBox is probably achieving that by cascading their SFU infrastructure – not an easy feat by all means – especially if you consider the large variety of customers and the dynamics of sessions that they need to endure
  2. Adding RTMP support. TokBox had HLS support already. HLS makes it easy to stream video, but doesn’t work well for live broadcasts. RTMP does a better job at that – and enables connecting to YouTube Live, Facebook Live and others

It seems that any type of workload that relates to real time and video is where TokBox is.

Twilio

Twilio is getting ready to become a serious video player.

In 2015, almost two years ago, Twilio came out with video chat capabilities. Since then, it stayed mostly in beta, with 1:1 video chat support only.

Last year, Twilio acquired Kurento (or at least some important parts of it along with the its developers). This acquisition of Kurento was about “programmable video” – the ability to do multiparty, but also much more. Last month? Twilio introduced a new Rooms API – a first step in offering multiparty video.

For Twilio, this is a catch-up game, trying to fit the many requirements of video. It starts with multiparty video, moves on to recording, then hybrid support of video/voice/telephony and from there to live broadcast and whoever knows what comes next.

In 2017, Twilio probably won’t be the best of breed solution for video, buy hey – if you’re already using them for voice and/or messaging – it makes sense to source video from the same vendor.

Vidyo.io

Vidyo.io is new to CPaaS but they are not new to video.

Vidyo have been working over a decade on video conferencing. Longer than other CPaaS vendors. They did that in the enterprise, offering multiparty video using SVC technology. This gave them an edge in media quality competing with enterprise video conferencing giants Cisco and Polycom at the time.

Now they are bringing this technology and their know how to the cloud and developers via Vidyo.io. And it doesn’t hurt that they are collaborating with Google on getting SVC into VP9

They are also an enterprise player, which is where the action seems to be today for CPaaS.

One has to wonder how this is going to affect the other players in this space.

Others?

There are other players out there in CPaaS. Some offering video from the start while others adding it onto their voice offering. Notable names include Agora, TrueVoice and VoxImplant. Each with his own flavor. Each with his own story.

How big is this pond and is there room for so many players?

Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.

Is this only about CPaaS?

While we’re on this topic, what about enablers? Vendors or frameworks who offer the ability to use WebRTC video in your own installation – cloud or on prem? There we had only Jitsi in the past, but now?

  • We have Jitsi and Kurento as the leading open source frameworks
  • There’s mediasoup and medooze, building SFUs
  • There’s the Intel platform
  • There’s SwitchRTC
  • And FrozenMountain, who is working on their own multiparty offering
More choice than ever before?

Here’s the thing though… There is still no one-size-fits-all.

The post What’s up with WebRTC Video as a Service in 2017 appeared first on BlogGeek.me.

Check the Pulse of WebRTC and CPaaS in my Updated Report

Wed, 03/08/2017 - 09:00

Time for another refresh of my WebRTC CpaaS report.

Call it what you want – WebRTC PaaS, CPaaS, API Platform, Communication API – they all end up doing a couple of things for the industry:

  1. Simplify and streamline the use of programmable communications that can be embedded virtually anywhere
  2. Make use of WebRTC as one of their building blocks. Usually a significant one
  3. Run in the cloud. Though not necessarily and not always

Today, I am launching the update of my Choosing a WebRTC API Platform report. It is now in its 6th edition with almost 4 years behind it already.

Before I begin – a thanks to my sponsor on this one

This time, I have a launch sponsor for the report – one of the new vendors that are profiled in it – Vidyo.

Vidyo launched recently CPaaS that enables you to embed real time video experiences into applications (here’s my recent analysis). While they are not the first in the market to do so, they bring with them some interesting SVC capabilities.

You can read more about SVC in this guest post by Alex Eleftheriadis – Chief Scientist & Co-founder of Vidyo.

SVC is a mechanism by which you can layer a video you are encoding in a way that allows peeling off the layers along the path the video takes – without needing to decode the video. This seemingly innocuous capability brings with it two very powerful capabilities:

  1. Better multiparty conferencing routing and control – because we can now easily decide in our SFU/router which layers to send based on the dynamic conditions of the call (network, CPU, screen size, etc)
  2. Better resiliency to bad network conditions – because we can take the lower layer(s) and add things like forward error correction to them to make them more resilient to packet losses (we can’t do it to all layers because that will just eat too much bandwidth)

That second capability is often forgotten – it is what can make or break great video experiences over things like WiFi or 4G networks.

SVC is starting to make its way into WebRTC, and you see developers tinkering with it. Vidyo has been at it longer than most, and have it boiled into their product. Vidyo already has SVC as an integrated part of their backend as well as their mobile and PC SDKs. When will that get enabled in their WebRTC part of the offering is a question to them, but you can assume it will have all the bells and whistles required.

Anyway, you can learn more about Vidyo.io in this report sample.

Why should you purchase this report?

This report will guide you through the process of deciding how to tackle the task of developing your product:

  1. It explains what WebRTC is briefly, and reviews the WebRTC ecosystem actors
  2. It lists the challenges you will face when developing products that make use of WebRTC
  3. It explores the various approaches to develping WebRTC – anything from self-development up to full CPaaS
  4. It shows you the key performance indicators that can guide you through your selection decision
  5. It profiles all relevant WebRTC PaaS vendors to make the selection process simpler for you

Having this kind of information can reduce the risks of your project by enabling you to make a more informed decision.

What’s new in this report?

You still won’t find marketing BS in this one such as weird market sizing numbers going to billions of dollars or devices with estimates of 2030.

That said, there are 4 important changes I made to the report:

#1 – New Vendors

The main driver for these report updates are two: major changes in existing vendors (multiparty video support in Twilio for example) and new entrants to the market.

In this update, we have 3 new entrants to the market, and they are all interesting:

  1. Agora.io, who are now adding WebRTC support to their platform
  2. TrueVoice, started with 3D voice and are now introducing video capabilities
  3. Vidyo.io, who are also sponsoring this report launch – check out there free profile (have I already mention that?)

I will be writing some more about the new video players in CPaaS next week.

#2 – Outlier Vendors

As time goes by, vendors and their products change and shift focus. Since my first release of the report this was bound to happen. Which is why I “migrated” some vendor profiles to a new section about outliers.

In some cases, you can use an outlier vendor instead of a CPaaS one, assuming your use cases fits what they have on sale. These vendors essentially cover a specific type of behavior (such as contact centers who offer visual assistance, or a click to dial consultation service for independent professionals). They might also target a very niche set of customers that just not fit what I am looking for in this report.

While they are SaaS companies in nature, they do have APIs and do offer some deep integration capabilities – and they are viable approaches to research for your product.

Two vendors who were profiled in this report in the past now find their home in this section:

  1. Respoke by Digium, who now focus on Digium’s Asterisk customers and cater to their needs only
  2. SightCall, who now focus on Visual Assist and no longer catre the more general purpose CPaaS market
#3 – Closed Platforms

And then there are platform vendors that got acquired, shut down or stopped catering for developers altogether. They were once profiled in the report, and are no longer with us.

They now have a whole section for themselves.

The reason I am not removing it? It isn’t due to sentiment. It is because this stuff is important. I believe that understanding the past and how these dynamics work will help make a better decision. It will give some more insights into the stability and trajectory of the “living” vendors in the report.

Whose gone to my deadpool section?

  1. AddLive – they were acquired in 2014 by Snapchat (yes, that company with the successful IPO). They immediately closed their doors to new customers and are shuttering their whole API service this year
  2. AT&T WebRTC Enhanced APIs – AT&T is still alive and kicking obviously. Their API developer platform is also active. But the WebRTC parts of it were shutdown. While no reason was given, it is probably due to low traction
  3. ooVoo – they tried appealing for developers by opening up their existing platform. Just to shut this initiative down recently. I am assuming similar reasons to AT&T’s decision
  4. OpenClove – I am not really sure what happened to them. The site is live, though copyright is from 2014. Up until last year, I got replies from my contacts there, but no more. There’s no indication if this is alive or dead, which is dead enough for me
  5. Requestec – who got acquired by Blackboard and taken off the API market

Each vendor section here is frozen in time, at the last point of its update. Reasons for its death have been added.

Hopefully, future updates of this report won’t make this section grow any bigger.

#4 – Multiparty Explainer

It is 2017, and it seems that many of the WebRTC API Platform vendors are now offering multiparty support of one kind of another.

When it comes to video, there’s a variety of alternative technologies of getting there. These affect pricing, quality and flexibility of the solution. It was appropriate to add that as an additional factor in the report, which means that now, there’s a new appendix in the report giving an explanation of the differences between mesh, mixing, routing, simulcast and scalability.

The Timespan Aspect of the report

This is something I added in the previous update and just… updated again in this round.

When I got to updating the vendor profiles this time around, I found this addition really useful for myself – and I try to follow the industary and gauge its heartbeat on a daily basis.

This is a small section added at the end of each vendor’s profile, where I added an “investment” section – an indication of what did the vendor introduced to the market since the pervious report. This can really show what these vendors are focusing on for growth and are they in the process of pivoting out.

Take for example the investment section I have for SightCall:

Green indicates investment into the API platform. Yellow indicates some investment. White with no text means nothing to write home about. And red means defocus in investment – putting money in non-API activities.

In this case, it is understandable that after SightCall’s investment in its Visual Assist service (May 2016), which was probably successful for them, they pivoted out of the general API market. Which is also the reason there is no update for it in March 2017.

This this is now part of each vendor’s profile in the report, so you can now factor it in with your vendor selection process (I know I would).

How about the price of this report?

The report’s price is $1950 USD. That includes:

  1. The written report (all 200+ pages of it)
  2. Online vendor selection matrix to use for comparison purposes
  3. Yearly updates – you’ll be elidgable to receive the next update of the report when it comes out

If you make your buy decision today, you’ll get a 35% discount by using the FASTMOVER coupon.

How do you do that?

Click to purchase the Premium package of the report.

Then on the shopping cart, make sure to indicate the coupon.

 

Prices go back up tomorrow at midnight, so better purchse this report now.

The post Check the Pulse of WebRTC and CPaaS in my Updated Report appeared first on BlogGeek.me.

How Can Localized CPaaS Players Thrive?

Mon, 02/27/2017 - 12:00

Who really knows?

Local or global for CPaaS?

In the past two months I’ve been conducting briefings with a lot of the CPaaS vendors out there. Some of them are now being added to my Choosing a WebRTC API Platform report that is getting a refresh next month.

During these chats, I came to realize a relatively lesser known type of CPaaS – the localized one.

To me, it was almost always about two types of players: you were either a “telco” or a global players. Telcos were based in their geography of operation, both limited and protected in their environment due to rules and regulations. Global players were the pure XaaS cloud vendors. I even created a nice graphic for that in 2013, comparing telcos to OTTs:

What we see now are mainly UCaaS vendors who are trying to join the CPaaS world. Put simply – vendors offering phone systems as a service to enterprises adding APIs for developers.

There are two reasons why these vendors are local in nature:

  1. Their offering is still tethered to a phone number for the most part, making them a kin to the telco
  2. They prefer it that way, probably because of where most/all of their business is taking place

For UCaaS, this localization might not a real issue. Corporations are still thinking locally, even the global ones. You work with people. And use phone numbers, so you tend to use the “law of the land” in every country. From how you allocate phone numbers to what exactly BYOD means at that country.

The problem starts when you want to serve one of two markets as your customers:

  1. Large multinational coroporates, whose footprint is global
  2. Small enterpreneurial teams who are spread out globally

That first one always existed. But I believe there are more of them today – smaller sized companies are reaching out globally, making them “multinatoinal corporations”.

The second? More of them as well, but probably focused on specific industries – high-tech comes to mind immediately.

What changes when moving to CPaaS while staying local?

First thing you’ll notice with these vendors, is that while they may be using AWS for their data centers and are offering WebRTC connectivity and VoIP, their distribution across AWS data centers ends up looking something like this:

This means that WebRTC calling is going to be affected – and not for the better. If I need to get a call going in France (2 people in Paris for example), then they get connected via US East – maybe even rounting their media through US East. Which lends itself to a bad user experience.

For UCaaS we might not care, as this would be an outlier – but for CPaaS?

The difference now is that we are API driven in what we do. We build processes around our company to offer programmatic communications. And these tend to be wider spread than the local mindset of corporate communications.

Are we using CPaaS to enable our customers to interact directly with each other? Are our customers as local as our own company is?

The end result

In most cases, the end result is simple. CPaaS is there as an API initiative for the UCaaS vendor.

As companies learn the importance and strength of integrations (see Slack and many of the new startups who offer B2B services and capabilities), they tend to offer APIs on top of their own infrastructure. One that their customers can use to integrate better. This makes CPaaS just that API layer.

In the same way that a movie rating company would offer an API that exposes its ratings, a UCaaS vendor exposes an API that enables communications – and then coins it CPaaS.

Only it may not really be CPaaS – just an API layer on top of his UCaaS offering.

The business models here are also different – they tend to be per seat and not per transaction. They tend to rely on the notion that the customer already paid for UCaaS, so no need to double dip when he uses CPaaS as long as he does that reasonably.

Does this make it any worse?

No.

It just makes it different, but still something you’d like to try out and see if it fits your needs.

Is this confusing? The whole UCaaS/CPaaS area is murky and mired with doubletalk and marketing speak. It is really hard to dig deeper and understand what you’re getting before trying it out.

 

Tomorrow I’ll be starting out a short series of emails about the decision making process of build vs buy – building a comms infrastructure versus adopting a CPaaS offering. If you aren’t subscribed to my newsletter, then you should subscribe now, as these emails will not be available here on the blog.

 

The post How Can Localized CPaaS Players Thrive? appeared first on BlogGeek.me.

When CPaaS Target Enterprises. 3 Different Approaches

Mon, 02/20/2017 - 12:00

All paths lead to the enterprise.

My report was titled Choosing a WebRTC API Platform vendor. Later, I leaned towards calling it WebRTC PaaS. Last year, a new industry term starting to get used a lot – CPaaS – Communication Platform as a Service. These in many cases will include WebRTC, which leads me to call the vendors in my report CPaaS from time to time.

I am currently working on the 6th edition of my report. It has come a long way since it was first introduced. A theme that has grown over the years and especially in the past several months is the way vendors are vying towards the enterprise. It makes sense in a way.

Here are 3 different approaches CPaaS vendors are taking when they are targeting the enterprise.

#1 – Special Pricing

The current notion that WebRTC is free. This in turn leads vendors in this space towards a race to the bottom when it comes to pricing. This leads vendors to look at other alternatives, bringing them towards the enterprise.

Why?

Because enterprises are willing to pay. Maybe.

This special pricing for enterprise means they pay more for a package that may accomodate them a bit better.

Check out for example Twilio’s Enterprise Plan. It starts at $15,000/month, offering more control over the account – user roles, single sign on, events auditing, etc.

It is a great way to grow from the penny pinching game of all the platform users to some serious numbers. Only question is – would enterprises be willing to see the extra value and pay premium for it? I sure hope they do, otherwise, we may have a big problem.

#2 – Extending UCaaS to CPaaS

The second set of players viying for a place in the enterprise CPaaS game? The UCaaS players.

If you do UCaaS, Unified Communication as a Service, then you have an infrastructure already that can be leveraged for the use of CPaaS. Or at least the story says.

Who do we have here?

  1. ooVoo, went from running a communication service towards a developer play (not an enterprise one mind you), only to shut it down later
  2. Cisco Spark, coming up with its own API
  3. Skype, looking at developers from time to time, trying to get their attention and then failing to give them the tools they need
  4. Vonage, with its acquisition of Nexmo
  5. RingCentral, adding a developer platform
  6. Vidyo, to some extent, with VidyoCloud and Vidyo.io

The challenge here is the change in the nature of the business and the expectations of the customers. Developers aren’t IT. They have different decition processes, different values they live by. Selling to them is different.

#3 – Simplifying and Customizing

There are those who try to simplify things. They build widgets, modules and reference applications on top of their CPaaS. They customize it for the customer. They try to target customers who aren’t developers – assuming that enterprises lack the capacity and willingness to develop.

They augment that with system integrators they work with. Ones who speak and talk the language of the enterprise. Ones who can fill in all the integration gaps.

This is a slow process though. It is elephant hunting at its best – a slow process compared to the CPaaS game.

Where does this all lead us?

There is no one-size-fits-all.

No silver bullet for winning the enterprise.

But there are a few approaches out there that are worth looking at.

For me? I am just looking at it from the sideline and documenting this process. It is part of what gets captured in my upcoming WebRTC PaaS report – these changing dynamics. The new entrants, those who exist and the progress and change that others are experiencing.

 

Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.

 

The post When CPaaS Target Enterprises. 3 Different Approaches appeared first on BlogGeek.me.

The 3 Schools of Thought for Creating a WebRTC App

Mon, 02/13/2017 - 12:00

Different people think differently when it comes to creating WebRTC apps (obvious? maybe).

I’ve seen it all. I talk almost daily with different stakeholders in companies that end up adopting WebRTC. A developer here. An enterpreneur there. A product manager. A marketing lady. A PR agency guy who knows shit about what he is promoting. A test engineer. An architect. The sales guy. You name it.

There’s a HUGE discount on my Choosing a WebRTC API Platform report now. And it is valid only until the end of this month. Why not grab your own copy of it?

If you go and ask the average Joe who is doing something with WebRTC how exactly does creating a WebRTC app, you’ll get one of 3 different answers. You see, at the end of the day, our small market can probably be pushed into 3 neat drawers, each representing a different school of thought. 3 different set of values and world views.

These worldviews can be found within the same industry niche, serving the same customer base, using similar business processes and user experiences, and yet each vendor will explain in detail why his way of creating that WebRTC app makes the most sense. And it does. It truely does.

I mostly agree with my buddy Chris Kranky who wrote about build vs buy of WebRTC apps last week. His approach is simple – why invest in your own infrastructure to cut down ridiculously low monthly plans of a CPaaS vendor? I see it as well with those approaching us at testRTC and then running away with cold sweat because they need to pay a 3 digits figure to stress test their product. But I digress.

Back to the schools of thought.

I think it is important to understand your own behavior and that of your team before moving fotward, as this may hinder your decision – or at the very least explain it. What you want to aim at here is to find a good match between your strategy and your team but also between your team and what you are trying to achieve. In many cases, I’ve seen failed attempts and increased risk because the choices made just didn’t make sense with the market realities.

It is similar to my article recently on a development path in WebRTC just looking at it from a slightly different angle.

Let’s see what these alternatives are:

#1 – The Tinkerers

“Look what I found in the Chromium Issue Tracker”

When it comes to WebRTC bugs, Tinkerers know the current bug status in the Chrome Issue Tracker by heart.

They want to build stuff with their own bare hands, sometimes forgoing even open source frameworks and doing things from scratch. Our industry has a few of these and their names are quite known (Fippo anyone?)

If you’ve got a real Tinkerer in your team, then you’re in great luck. There are few of them out there – and even fewer who understand what they talk about and how to make real use of WebRTC.

The main challenge here is that you need to have more than a single Tinkerer. If she leaves to work someplace else – what are you to do then?

There are teams of Tinkerers out there building great products with WebRTC. What is interesting, is that these are the teams that get acquired for the technology they end up with. These are AddLive, Screenhero, BlueJimp and to some extent even Beam.

#2 – The Owners

“How can I rely on someone else with my infrastructure? I must own it to be able to resolve issues and control my own destiny”

And still you go place your service in AWS.

Owners like to own stuff. They need control over it. They are just fine paying others to build it, but they want to own and control the finished product.

While I value ownership, I think it is something that needs to be questioned each and every time. Is that piece of technology really core to the business? Is it where innovation and barriers of entry to your market is found? If not, then you should probably rent and not own.

On the other end, ownership is sometimes necessary, and the reasons vary from case to case. Here are a few good ones I’ve heard:

  • No CPaaS vendor covers our geography
  • Regulation in our industry mandates it. Our own customers are “Owners” themselves
  • We have this critical feature no one has that forced us into building our own infrastructure
  • Our industry is crowded and competitive. We need any advantage we can get
#3 – The Dreamers

“Collectors of wood art need a place to meet”

I have a dream. And in my dream, I see an untapped market. A need that isn’t answered. I am clueless about the technology that gets me there, but I am sure that will solve itself.

Many of these around. Especially now that WebRTC is with us. The reason? WebRTC lowers the barrier of entry for new players. And the best way of getting there fast is by employing CPaaS.

The Dreamers focus on their target audience. That niche market, where a problem needs to be solved. In many cases, they come from that market.

A dancer with cancer, trying to find a place for women suffering from cancer to dance from home.

Psychologists building an online group therapy service.

Teachers building education services for a very specific target audience.

You’ll find these in the verticals – places where communications is a part of the service – a feature within another service.

To You Now

Did you find yourself in that list somewhere?

Are you a Dreamer trapped inside an Owner school of thought because of the limitations of CPaaS vendors?

Are you striving to be a Tinkerer but don’t have the workforce for it?

How are your intents and company DNA match with your school of thought?

I am seriously interested in it, so leave a commend or email me about it.

 

Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.

 

The post The 3 Schools of Thought for Creating a WebRTC App appeared first on BlogGeek.me.

Microsoft and the WebRTC Edge Case

Mon, 02/06/2017 - 12:00

Microsoft getting their act with WebRTC Edge support is far from a fashionable delay, saying more about the future of Edge than the future of WebRTC.

Want to run WebRTC on anything? Check out my free WebRTC Device Cheat Sheet.

Last week, Microsoft officially announced their intent to support WebRTC 1.0 (whatever that is exactly). I skimmed over that piece of news, but direct questions from a couple of my friends about my opinion, along with short chats with them on various messaging services made up my mind to actually write something about this.

Let’s begin from the end – nothing changed under the sun. Microsoft Edge supporting WebRTC is a non-starter for most.

Now for the details.

The Microsoft’s WebRTC Edge announcement

The title of the announcement? Introducing WebRTC 1.0 and interoperable real-time communications in Microsoft Edge. 1.0 surpasses interoperability in the title, while interoperability (with Chrome) surpasses anything else in that announcement.

  • This release is still in beta, the Windows Insider Preview, making its way to a stable release in the upcoming Windows 10 Creator Update – taking place sometime in “Spring 2017” – somewhere in Q2
  • It seems that this release won’t support the WebRTC data channel, as Microsoft is more interested in getting its Skype asset to work first – making Peer Connections and ineroperability a lot more important
  • On the video side, the version supports both H.264 and VP8, making the old codec wars moot (until Apple decides to join the fray)

Microsoft is doing their damnest not to mention Chrome in the announcement – and they have succeeded. Barely. The annoucement mentions “video communications are now interoperable between Microsoft Edge and other major WebRTC browsers and RTC services”. I wonder who are these major WebRTC browsers. I wonder even more what “RTC services” means here. Maybe the ability to do a Facebook Messenger video call from an Edge browser to the Facebook Messenger iOS app?

They failed in not mentioning Chrome by mentioning specific bandwith estimation algorithm that Google is using: “Support for Google Receiver Estimated Maximum Bitrate, goog-remb”. I have to wonder how much legal fought over this one getting into an official blog post on Microsoft’s website.

The end result? Edge will soon have video interoperability support with Chrome and Firefox when it comes to WebRTC.

This is great, but it changes nothing.

Edge and Market Share

Somehow, a friend of mine actually thought Edge is a real thing. Until we started searching for recent market share indication. The most recent stats I publicly found are from November 2016, and they place Microsoft Edge at 5.21% – “Trailing Microsoft Edge was only Apple’s Safari browser, with 3.61%, and Opera with 1.36%.”

NetMarketShare places Edge even lower at only 4.52%:

Great.

While Windows 10 has grown in adoption, Edge hasn’t.

Things are now getting desparate. In my own Windows 10 laptop, Microsoft is now pushing “ads” about how Edge is faster than Chrome and how great it is – enticing me (unsuccessfuly) to try it out.

This is happening to everyone NOT using Edge apparently, with some suggesting how to stop this Microsoft pushing you to the Edge.

The Enterprise Urban Legend

Microsoft reigns supreme in enterprises. There’s no doubting that. But here’s the thing – the browser of choice there is Internet Explorer. Not Edge.

Many of these enterprises use Windows 7 today – NOT Windows 10. So the IT guy in the enterprise sees the following choices in front of him when he needs to decide on a major upgrade:

  1. Switch to Windows 10
    • While doing that, continue using Internet Explorer 11
    • Or go for HTML5, and standardize around Chrome, Firefox, Edge – or all of them
    • There’s a hybrid option of IE11/Edge which isn’t that fun, and as far as I am aware, isn’t popular
  2. Stay with Windows 7, but shift away from Internet Explorer 11
    • Microsoft’s Edge browser isn’t available there anyway, so that option is not possible
    • So you have to go for HTML5, and standardize around Chrome and Firefox

A smart IT person, will decide on a project that makes the switch in stages. Taking him to one of these two routes:

  1. Switch to Windows 10; later switching to HTML5
  2. Switch to Chrome/Firefox; later switching to Windows 10

The common denominator? Use Chrome/Firefox and NOT Edge. Which is why most end up forgoing Edge. That and the notorious reputation of IE that is tarnishing Edge.

From a friend who works in front of such large enterprises, I am told that most are asking either for Chrome/Firefox support or Windows 10 with… Chrome/Firefox support. There’s no requests coming in for the Edge browser.

In the enterprise, it is either IE11 or Chrome/Firefox these days.

What the Future Holds?

From day 1 of WebRTC, it seemed obvious that out of the oligopoly of 4 web browsers, two are going to be adopting WebRTC (Chrome and Firefox) and two will need to be dragged towards adoption (IE and Safari).

Microsoft decided to kill IE and focus on Edge. It also decided to throw the towel on ORTC and adopt WebRTC. The reasons are rather obvious – when you lack market share, you need to follow the trends. It tried taking the higher ground with the better ORTC design, only to fail and get back in line and now introducing WebRTC.

Apple… who knows? They hire people. They commit stuff into WebKit. They have people in the standards bodies. Will this mature enough in 2017 for an official release? Maybe. Probably. I just don’t know.

As always, before you make the decision on what to support – do an investigation of your target users and what they are using. You might be that outlier whose users are that 5% using Edge…

If you need WebRTC to work for you, you’ll need to understand how to get it running on any device and browser. My WebRTC Device Cheat Sheet is still as relevant as ever. It’s free, so go ahead and download it.

Get the cheet sheet

The post Microsoft and the WebRTC Edge Case appeared first on BlogGeek.me.

How to Choose a WebRTC Development Path?

Wed, 02/01/2017 - 12:00

There’s an underlying theme to questions from those approaching me. They most often than not consider what to pick as their WebRTC development path.

Before we continue – there’s a huge discount on my WebRTC PaaS report this month – so make sure you don’t miss it.

About 10 years ago or so, a large LCD manufacturer came to the company I worked for. They wanted to build a monitor that has an embedded video conferencing endpoint in it. It was revolutionary at the time. Beautiful. Agressive. And we won the project. That was when the hard work started – we had to pick out a team to build it.

We had some of the best VoIP developers out there at the time. Our business unit licensed the technology to everyone and anyone who did anything with VoIP, so it made sense to self develop. And yet… we found ourselves hiring around 8 more developers for this project. All with skillsets different than the ones we already had. We were missing in the domain of media processing, codecs and hardware.

In almost any case, when it comes to WebRTC, the skillset you already have in place will not be exactly what is necessary to get the job done.

You will either have to hire the skillset, teach your current workforce new tricks or outright outsource the work.

Which means that when you start thinking about a product that needs real time communications, there are usually 2 routes you can pick when it comes to the WebRTC development part:

  1. Use in-house developers
  2. Use an outsourcing vendor

And in them, there are 2 additional aspects to decide upon:

  1. Develop and maintain your own infrastructure
  2. Use a 3rd party CPaaS

This all leads to the following WebRTC development matrix:

There are 4 classic development paths that I see companies take with their projects.

#1 – Hard Core

The Hard Core development model is all about control and core competencies.

At the extreme, these vendors will tend to “live off the land” and go as far as building their own SFU from scraps of code they cobble up around the web.

What they see as imperative in front of them is to be the best at communications – and to rely as little as possible on others.

For the most part, these would be companies with existing VoIP heritage who make the plunge towards a WebRTC project. At times though, they can be brand new to VoIP and for them, it starts as an adventure of sorts.

Another vendor type in this space would be the NIH type of a vendor. Where the Not Invented Here synrome is high, and trust on others to deliver what is needed is non-existent. These guys know better than everyone else how to put this type of an infrastructure in place and no explanation would deter them. Their best argument? CPaaS is too darn expensive when you start counting the minutes. And I already said – WebRTC is… free.

#2 – IT Project

The IT Project development model is about ownership.

The end game here, is to own the infrastructure and the data flow. Companies will tend to go to this approach if they have a regulatory issue they need to deal with (such as “data can’t travel out of the country”), a need to serve a specific geography (China for example) or special requirements that translates into the need of using their own infrastructure since others won’t support it (real time video analytics in the backend comes to mind).

As with the Hard Core players, they will be those who simply fancy the idea of ownership.

Why is this an IT Project then? Because an external outsourcing vendor is taken to develop it for the company. Usually because the internal workforce doesn’t have the experience, overbooked, or just more expensive.

#3 – Integrate

The Integrate develoment model is about getting things done.

You have the developers in place. They are already building your product/app/service/whatever. And you direct them to a CPaaS vendor of your choosing to work on top.

Why? Because communications isn’t your core business. Because it is cheaper. Because it gives you faster time to market. Have a pick of your reason for it – there are quite a few.

#4 – Agency

The Agency development model is about the dream.

You have a dream. You want to get it done. But you don’t really have the experience or the manpower. But you have some budget for it. What do you do?

Find and outsourcing vendor to build the product for you. Use CPaaS to work on top, so ongoing maintainance will be kept at a minimum if possible. And have that delivered to you.

Simple. If you pick the right outsourcing vendor. And the right CPaaS vendor. And the stars align just the right way to give you the luck needed in any development project.

How to choose your path?

I am in the process of updating and beefing up my WebRTC PaaS report, which is geared towards the vendor selection process of a CPaaS vendor. This time, I’ll be enhancing it to cover the IT Project, Agency and CPaaS quadrants.

Until I do, I am lowering down the price of the currently available WebRTC PaaS report from $1,950 down to $199. This should make it affordable to anyone who is planning on investing any kind of time or money in this space.

There are a few caveats:

  1. This discount is available ONLY during February. The price will rise in March when the updated report is ready
  2. The report will not include any of the extras – just the report itself
  3. Specifically, it won’t come with any 1-year updates

Those who purchase the report now will be given a discount later on if they wish to go for the 1-year update package. Which means there’s nothing for you to lose when grabbing the report now at a huge discount.

Purchase the WebRTC PaaS report

 

The post How to Choose a WebRTC Development Path? appeared first on BlogGeek.me.

Vidyo.io and Differentiating in the Brave New CPaaS World

Mon, 01/30/2017 - 12:00

Making a CPaaS platform is not easy. Making one that is differentiated? That’s even harder.

Vidyo announced their new CPaaS called vidyo.io last week. It has been around for some time now – I covered it a couple of months ago on SearchUC – Vidyo migrating from enterprise video conferencing to video APIs. Now it is officially out, and I want to take a closer look at it.

Vidyo is/was an enterprise video conferencing company. Their focus throughout the years has been around software based solutions that make use of Scalable Video Coding – SVC. Its main competitors were probably Cisco, Polycom and Avaya – all operating in the same space.

But now, things are rather different. Vidyo has decided to go after two adjacencies at the same time – UCaaS as CPaaS:

  • UCaaS – VidyoCloud offering a managed video conferencing service for the enterprise. A competitor to companies such as BlueJeans and Zoom (the latter just raised $100m at $1b valuation)
  • CPaaS – vidyo.io offering an API for developers that does… video conferencing that can be embedded virtually everywhere

CPaaS isn’t something new. I have been covering the WebRTC part of it for quite some time in my own WebRTC PaaS report. And there are lots and lots of companies in that space already. So why bother with yet-another-one in 2017?

That’s a question for the vendors who join the market, but I’d say this. You can be one of two types of companies:

  1. A direct competitor to Twilio, the jack of all trades when it comes to CPaaS. This means you’ll need to support anything and everything related to communications AND give developers a reason to use your platform instead of Twilio (good luck with that)
  2. Become differentiated in a way that leaves developers no choice but to come to you. How do you do that? Beats me if I know. I just write here

Vidyo took the latter approach with vidyo.io, going for differentiation.

What is it that can make vidyo.io so enticing to developers and differentiate them from the crowd? Here’s what I came up with.

#1 – Razor focus on video

Vidyo does video. Not much more. There aren’t many players in this specific category besides maybe TokBox. ooVoo might be considered as another such player, at least to some extent.

This resistence to fill in the legacy gaps of voice and SMS probably isn’t an easy one. There’s a need to maintain a lead in the technology and the capability of the IP based video communications and at the same time believe that that lead is warranted and perceived by customers as an advantage.

Would you source your video from a second vendor or just take what Twilio or any other CPaaS player you’ve picked up for your phone calling do the video part for you as well? Maybe. Maybe not. Depending how critical video is for you and what features are you looking for. For mission critical applications such as healthcare, financial services or even customer engagement, you might not want to take the risk when you don’t have to.

#2 – Enterprise Savviness

Everyone wants to go after the enterprise these days.

Developers are hard to work with when it comes to developer tools:

  1. They aren’t the ones controlling the budget, so hard to get them to pay
  2. They are usually cheap in how much they are willing to pay
  3. And that’s because they think they can develop what you have on their own. How hard can it be to take a FREE WebRTC thingy and turn it into a managed service?

Mitigating that gap with the longtail world of developers is hard. So once a platform goes there, it will usually try going upmarket to get enterprise customers. This is one of the reasons that Twilio launched an enterprise plan last year.

Vidyo comes from the enterprise world, boasting as its customers government agencies, financial institutes, healthcare providers and contact centers. In all cases, big names who adopted Vidyo technology in one way or the other to add video to their business needs.

#3 – SVC, in all its glory

There’s a notion that SVC is necessary for multiparty video conferences, and while the answer is that it is, SVC done right also improves video quality in mobile devices over error prone networks.

You see, SVC enables you to create different layers:

The sender sends all layers and the server then peels the layers it thinks are the best that can fit to the device they are intended for. So if we send to multiple devices – we can just fit for each device his own view at a lower cost to our server. Which is why SVC is so good for multiparty calls.

For mobile? If I can split a stream into several layers, I can decide to “protect” the lower more important layers by increasing their probability of being received. How do I do that? I add Forward Error Correction. This means you can improve video quality in really bad networks – Vidyo has that in their platform for quite some time, making it one of the few players today with WebRTC that can do that.

There’s a lot more to it than that, as Vidyo has been making use of SVC longer than anyone else out there in the industry. Vidyo is also the only CPaaS vendor in the market who offers that as far as I know. You can read more about it in their technology overview on vidyo.io.

Which brings us to the Google angle.

#4 – The Google angle

We’re now in a world of VP8 and H.264 in WebRTC. That’s the video codecs you see deployed in the market. Will this trend continue? Unlikely. Technology waits for no one. H.264 is old. Its first version was officially released in 2003. It has improved, but it is time to start the transition as an industry to a new video codec. VP8 was meant to be on par with H.264. Its successor is VP9 or H.265).

In all browser based WebRTC implementations we either already have VP9 support or will have VP9 support. And VP9 is where scalability will happen for WebRTC. A great deal of that is taking place by a cooperation between Google and Vidyo – one that I am not privy to.

The end result? Vidyo will probably have the first SVC-enabled video routing infrastructure that works with Chrome’s VP9 implementation. And this, in turn, can give Vidyo a huge headstart over other platforms.

Can Vidyo succeed with vidyo.io?

Yes. It will be a question of execution, as the path isn’t an easy one.

There are two challenges here that Vidyo is taking upon itself:

  1. Migrating to the cloud, with its own business model challenges
  2. Working with developers and selling a platform and not a product, which is a different ballgame with different rules of engagement

The first point is something that Vidyo has already committed to with VidyoCloud. It is a shift that is happening – with or without the developers angle. This means that management and shareholders are already bought into the cloud strategy and will have the patience to wait until Vidyo shifts and sees enough success in this “new” market.

The second point is where the real challenges will occur. There are different things that take place when you work with developers and on a managed service. Marketing works differently. Documentation and support are also handled differently. The sales processes are different. Vidyo will need to fill in these gaps and learn fast while maintaining its position in the enterprise. Being able to do that will mean being able to win more enterprise customers with vidyo.io

CPaaS Differentiation in 2017

As we enter 2016, differentiation in the CPaaS space will be important.

The notion of “cheaper than X” will not work. It leads to a price war where nobody wins. These managed services require scale, but the market is still new and nascent, so real scale isn’t here just yet for the most part. Reducing prices and going down to AWS levels make no sense. Especially if you consider the investment in ongoing development that is required in this market.

Vendors are finding their way in this market, each trying to differentiate and carve its own niche. Vidyo may well have found its own where their strength in multiparty quality over mobile can be a differentiator. Time will tell how successful they will be.

For developers? This is definitely a big win, as there are more alternatives on the table, with Vidyo joining in and adding their enterprise video tech into the mix.

 

Join me and Vidyo for a 2017 WebRTC State of the Market webinar - registration and attendance is free.

The post Vidyo.io and Differentiating in the Brave New CPaaS World appeared first on BlogGeek.me.

Pages

Using the greatness of Parallax

Phosfluorescently utilize future-proof scenarios whereas timely leadership skills. Seamlessly administrate maintainable quality vectors whereas proactive mindshare.

Dramatically plagiarize visionary internal or "organic" sources via process-centric. Compellingly exploit worldwide communities for high standards in growth strategies.

Get free trial

Wow, this most certainly is a great a theme.

John Smith
Company name

Startup Growth Lite is a free theme, contributed to the Drupal Community by More than Themes.