bloggeek

I was meaning to write something about Skype, Linux and WebRTC. But never got around to it. Until now.

The reason why I decided to write about it eventually? This tweet by Alex:

IMTC (Microsoft, Cisco, polycom, unify, sonus, …) to provide free (no cost) and free (do what you want) webrtc plugin for I.E. And Safari.

— Dr. Alex. Gouaillard (@agouaillard) August 3, 2016

Hmm. The IMTC is planning to offer a FREE plugin for IE and Safari.

Sounds like Temasys, and from the person who worked at Temasys at the time of releasing their plugin – now a commercial one rather than a free offering.

While some like this plugin, others don’t. They tried it and decided that the warning messages it pops up when being installed aren’t worth the effort.

The Electron WebRTC app approach

What did catch my eye was the Skype for Linux announcement. This is an alpha release of the Skype app for Linux – something that Microsoft have been neglecting for quite some time now.

The interesting bit isn’t that Microsoft is actively investing in a Linux version for Skype and acknowledging this part of the user base, but rather how they did that and the stance they have.

Here are a few lines from the announcement on the Skype community site:

The new version of Skype for Linux is a brand new client using WebRTC, the launch of which ensures we can continue to support our Linux users in the years to come.

[…] you’ll be using the latest, fastest and most responsive Skype UI, so you can share files, photos, videos and a whole new range of new emoticons with your friends.

The highlighted text is my own addition.

Here are my thoughts:

• This is implemented on top of WebRTC and not ORTC. In a way, we’ve gone full circle with Microsoft – from ORTC, to adding WebRTC support in Edge to using WebRTC to develop their own products where needed
• Microsoft gives the best reasoning behind using WebRTC in its own development: to ensure continued support for Linux
  • For the most part, using WebRTC equates better support for more devices and platforms than any other technology out there today
  • Yes. You still need to put some effort into getting it working on some platforms – but with a lot less of a hassle than any other technology and at a lower cost
• Responsive Skype UI = HTML5. So there’s some browser engine / rendering engine for HTML in there somewhere
• Latest and fastest…

It turns out Microsoft decided to use Electron.

What is Electron? It is a framework around Chromium that can be used to created desktop apps from web apps. And it is the most popular platform for doing it these days.

The irony.

Microsoft. Who owns, develops and promotes IE and Edge. Who was against WebRTC and for ORTC. That Microsoft used Chromium (effectively Chrome) to bring its Linux Skype app to market.

A few years ago, that would have been unheard of. Today? It makes too much sense – it actually increased the value of Microsoft in my eyes. Making the most practical decision of all and putting the ego aside.

Back to a WebRTC Plugin

So.

The IMTC is now investing its time and effort in a WebRTC plugin. Call me skeptic, but I can’t see this heading in the right direction.

Here’s why:

• The IMTC is an interoperability group. Its strength lies in getting multiple vendors into the same room and having them test their products against each other. “their products” being products that follow the same specification and end up being deployed in the same network and service
• Companies put their money into the IMTC to enable them that testing services
• The problem with WebRTC and the IMTC is that WebRTC doesn’t really require interoperability per se – besides that between browser vendors. And browser vendors aren’t exactly the type of audience the IMTC caters for. To be exact, Microsoft is the only browser vendor who is part of the IMTC – and that’s probably for their Skype for Business product and not Edge or IE
• Writing and maintaining a WebRTC plugin is hard work. It gets updated too frequently to be considered a one-time effort, so maintaining it comes at a cost – a type of cost that is new to the IMTC and its member companies

I believe it will be hard for the IMTC to maintain such a plugin on their own, and if the idea is to open source it to the larger community so the external community can take it up and continue to work and maintain it for the IMTC then that’s just wishful thinking. Open source projects are not synonymous with community development – they don’t all get picked up, adopted, used and maintained by the masses. The webrtc-everywhere project on github shows that – 2 contributors, a few forks, but not much of a collaboration or community around it.

Since the IMTC is a group of vendors who all seek reaching interoperability of the spec while maintaining a technical advantage on the rest of the vendors (I was there once), I can’t see them cooperating for a long term development of such a thing and putting the resources into it while contributing back to the community.

Furthermore, do we really need a WebRTC plugin?

Yes. I know. Safari. Important. IE. All those poor enterprise guys forced to use it. You can’t live without it and such.

But guess what? That same target market? How receptive do you think it will be for a plugin? What will be the install rate and usage rate for a plugin in such environments?

–

I have a warm place in my heart for the IMTC, but I think it is losing its way when it comes to WebRTC. I can’t see how a free plugin for WebRTC today will make a change. There are better things to focus on.

What to do in 2016 with WebRTC on IE/Safari?

There are two use cases here:

1. I need to use the service daily
2. I just want to get on a URL and do whatever needs to be done (call a doctor for example)

The first one can be solved with an installed PC app. A quaint choice maybe, but one which seems to be popular by comms vendors who started from the web. Think Slack or even Whatsapp – they both have a PC app. If you are using a service daily, the idea goes, you might as well just have it somewhere handy in the background of your PC instead of having to have it opened in a browser tab all the time.

The second one is where things get nasty. Asking for a plugin installation for it is just like asking for an app installation for it. Maybe worse if the installer of the plugin comes with a large set of browser warnings (because browsers now hate plugins). So you might just rethink the app option – or just ask the user to come back with a better browser.

My suggestion?

Explore the option of using Electron instead of a plugin.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post WebRTC Plugin? An Electron WebRTC app is the only viable fallback appeared first on BlogGeek.me.

Guess what? Mozilla is removing Hello from Firefox.

It will still be available as an add-on, but it seems to have degraded in its importance to Mozilla, which is understandable.

Goodbye HelloWhat is/was Hello?

Hello was Mozilla’s attempt to build a video calling service. Something that is baked right into the browser, but can be used by any browser supporting WebRTC. Think FaceTime or Hangouts but without the app or even a website.

Mozilla partnered for Hello with TokBox (a Telefonica company), which provided the backend to the service – mainly NAT traversal as far as I can tell.

When Hello was announced, I had my doubts and questions about it.

What went wrong?

A few things were wrong from the onset in Firefox Hello:

1. While it debuted on a desktop browser, its main purpose was mobile. The problem is that Firefox OS got scrapped/pivoted, leaving Hello with no real use
2. It came at a low point in Mozilla’s history. Mozilla partnered during 2014 with 3 vendors, trying to reduce Google’s hold on it: Yahoo, Cisco and Telefonica
   • Yahoo is all but dead – it just got acquired by Verizon
   • Telefonica needed Firefox OS on mobile, and now that that hasn’t matured, my guess is that its interests lie elsewhere these days, so having Telefonica/TokBox as part of Hello probably isn’t helping too much today
   • Cisco only wanted to protect its H.264 investments, which it succeeded
   • This cost Mozilla in focus and diluted its brand from being a pure open alternative
3. Firefox has no real network effect or user base to rely on. It doesn’t connect users to one another but rather it connects viewers to web pages. Having hundreds of millions of viewers doesn’t equate monthly active users for a personal communication tool that is baked into the same product
4. Hello was simple, but offered nothing interesting/innovative/new/needed. People who used apps continued to use apps. Those that wanted to meet over URLs used URLs. Having the button in the browser wasn’t enough to make people leap for the opportunity to use it
5. While available in all WebRTC supporting browsers (=Chrome & Firefox), it was really a Firefox thing. This limited the user base, and especially the ability to start or to really receive a call over a mobile device

The main issue though is that a free video calling service isn’t that much of a deal these days (if this surprises you – just ask Google).

So Mozilla started by embedding Hello right into the browser. Then making it into a system add-on. And now it is making it into just another add-on. I assume it has a lot to do with the usage they’ve seen over the past year for Hello (and its non-adoption). It makes no sense to continue investing the time and effort in it if no one is using it – and having it officially released with the browser once every few months is a waste. Better throw it out of the browser and simplify the browser releases.

The next step might be to sunset the add-on/service altogether and say goodbye to Hello.

Is this predictive to Google’s Duo app?

Google announced Duo and is about to release it. Simplifying things a bit (and dumbing it down), Duo is a FaceTime clone. I covered Allo/Duo a few months back.

On face value, there’s no reason why Google Duo won’t meet a similar fate as Mozilla Hello.

That said, there are a few notable differences:

• Duo is a mobile only app, whereas Hello focused on desktop browsers
• Duo will probably be released on Android and iOS, covering 100% of the mobile market from day one
• Google has a large users base on Android and the ability to get Duo in front of users. It also has the social graph of these people – via the phone’s address book
• While Google kept Duo simple, it did bake two features into it:
  • Speed of connectivity, taking it to the extreme by adding QUIC into the mix
  • Caller’s video sent even before you accept the call

Will this be enough for Google Duo to get the adoption? I don’t know.

Where do we go from here?

In 2016 there should be no doubt anymore:

If you plan to monetize a video calling service, you need a serious business plan.

Most services I see launched have no business plan. They attempt to grow to millions of users. There’s a lot of dumb luck involved in it.

I’ve had my doubts about the viability of Wire as a company due to the same reasons. The only progress made by Wire is open sourcing their app – this doesn’t strike me like a business plan or a signal of strength and healthy growth.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post Surprise: Free Video Calling is no Guarantee for Success (or Adoption) appeared first on BlogGeek.me.

Hardware acceleration for video codecs is almost mandatory.

VP9 is getting a performance boost

There are three things that keep VP8 in the game when compared to H.264:

1. It was the only video codec in Chrome for WebRTC in the last 5 years, giving it a headstart in deployments
2. H.264 while available in mobile chipsets isn’t always accessible for the developer (or works as it should when it is accessible)
3. VP8 and H.264 are rather old now, so software implementations of them are quite decent

 

With VP9, the main worry was that it will be left behind and not get the love and attention from chipset vendors – leading it to the same fate as VP8 – abysmal, if any, hardware acceleration support. It is probably why Google went to great lengths to make it running on YouTube so soon and is publicizing its stats all the time.

This worry is now rather behind us. Recent signs show some serious adoption from the companies that we should really care about:

#1 – ARM

Mobile=ARM

Without checking stats, I’d say that 99% or more of all smartphones sold in the past 5 years are based on ARM.

If and when ARM decides to support a feature directly, that brings said feature very close towards world domination in future smartpones.

Which is somewhat what happened last week – ARM announced its Mali Egil Video Processor with VP9 acceleration.

Here’s a deck they shared:

ARM Mali "Egil" technical preview from Phil Hughes

Being farther away from chipsets than I were 5 years ago, it is hard for me to say if this is an integral part of an ARM processor, but I believe that it isn’t. It is an add-on component that takes care of video processing that chipset vendors add next to their ARM core. They can source the design from ARM or other suppliers – or they can develop their own.

Not sure how popular the ARM alternative is for video processing, but they have the advantage of being the first alternative for any chipset vendor (hell – they already source the ARM core itself, so why not bundle?). Which also means every other vendor needs to match up to their feature set – and improve on it.

Now that VP9 encode/decode capabilities are front and center in the ARM Mali Egil, it has become a mandatory checkmark for everyone else as well.

#2 – Intel

If ARM is the king of mobile, then Intel rules the desktop.

As with ARM, I haven’t been following up on Intel CPU acceleration lately. And as with ARM, it was Fippo who got my attention with this link here: the new Intel Media SDK.

For those who don’t know, Intel is providing several interesting software packages that make direct use of its chipset capabilities. Especially when it comes to optimizing different types of workloads. The Intel IPP and Media SDKs handle media related processing, and are quite popular by low level developers who need access to such facilities.

From the release page itself:

With this release we are happy to announce new full hardware accelerated support for HEVC and VP9.

• HEVC Main 10 (10-bit) encoder and decoder support
• VP9 8-bit and 10-bit decoder support

So… HEVC (=H.265) has encode and decode while VP9 only has decode support.

Probably because HEVC has been in the works for a lot longer than VP9, but there’s hope still.

#3 – Alliance of Open Media

The Alliance of Open Media. I’ve published a recent update on the alliance.

Intel was there from the start. The recent additions include ARM, AMD and NVIDIA.

I am sure additional chipset vendors will be joining in the coming months – there seems to be a ramp up in memerships there, with Ateme and Adobe added to their logos just last week.

While the alliance is about what comes after VP9, it is easy to see how these vendors may sway to using VP9 in the interim.

The Future

The future is most definitely one of royalty free video codecs. We’ve got there with voice, now that we have OPUS (though Speex and SILK were there before to pave the way). We will get there with video as well.

Coding technologies need to be accessible and available to everyone – freely – if we are to achieve Benedict Evans’ latest claims: Video is the new HTML. But for that, I’ll need another post.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post VP9 Hardware Acceleration is Real appeared first on BlogGeek.me.

It’s good to have Fippo when there’s lack of ideas in your head.

While there are synergies abound, a flawless execution is necessary

Yap. Fippo again prodded me about a topic, so here comes the post for it.

If you missed it, yesterday Microsoft acquired LinkedIn. $26.2B.

In some ways, Microsoft now rules the enterprise space – communication, collaboration and creation:

• Microsoft Office suite (Excel, PowerPoint and Word as the main pillars)
• Microsoft Outlook and the Exchange server (Email)
• Yammer (Enterprise communications)
• Skype (Voice and video communications)
• LinkedIn (User identities and profiles)

Dean Bubley puts it nicely:

The @microsoft / @linkedin deal has nailed enterprise comms federation. Complete map of who knows whom. Add Skype4B & goodbye telephony

— Dean Bubley (@disruptivedean) June 13, 2016

There’s a longform here, but I am less convinced.

I am more inclined to how Radio Free Mobile sees this:

However, for all of this to work, LinkedIn’s systems and data has to become deeply integrated with those of Microsoft which with the companies remaining independent, will be orders of magnitude more difficult.

Microsoft of late has an issue with the ability to execute and follow through.

Skype, while huge, isn’t growing since Microsoft’s acquisition. It is actually letting others take its place.

Same with Yammer. Have you heard anything about it in the last few years? The news is all about Slack, and worse still – it is about how Atlassian’s HipChat is struggling because of Slack – Yammer isn’t even mentioned as a competitor/contender in this space.

Which brings us to LinkedIn, Microsoft’s intents for it and its ability and willingness to follow through.

Back to LinkedIn

I wrote about LinkedIn exactly a year ago. It was about their acquisition at the time of Lynda, a learning company, and me griping on why LinkedIn isn’t doing anything about comms (and WebRTC).

The people at LinkedIn aren’t stupid. They are $26.2B smarter than I am. And frankly, that’s also $17.7B smarter than Skype.

What does that tell us?

• LinkedIn saw no real value in real time communications
  • Not enough to invest in it and build something with WebRTC
  • Not enough to acquire someone outright
  • Not enough to partner and integrate someone like Skype (Facebook did that in the past for example)
• That decision played well for LinkedIn – they just got acquired
• Messaging isn’t that important to LinkedIn either
  • They have rudimentary messaging capability in their platform
  • But it is lacking in so many ways that it is hard to enumerate them
  • And you can’t call its messaging anything similar to… messaging. If feels more like emails

If LinkedIn can’t find value in real time communications for its platform on its own, can Microsoft do a better job at it?

I don’t know.

–

Now lets look at the Microsoft assets that canbe integrated with LinkedIn.

Skype and LinkedIn

As Dean suggested, there is some synergy in Skype connecting to LinkedIn.

LinkedIn can slap a Skype button on its profiles, making it easy to connect to the people you’re connected with on LinkedIn.

While that’s great, most communication today happens OUTSIDE of LinkedIn. You reach out to people on it, connect with them, and then shift to email and other means of communications. Especially once you know a person to some extent.

To make a point – I wouldn’t send a message to Dean over LinkedIn – I’ll make it over email. Or just ping him on Skype, because that’s where he is.

When someone asks me for an introduction, it usually goes like this: “I saw you are connected to John Doe on LinkedIn. Can you send an intro email for me?”. It happens a lot less on LinkedIn even when it is driven from LinkedIn.

Getting the communication back to LinkedIn will be hard. Getting slightly more communications from LinkedIn directly to Skype is possible, though I am not sure it will be widely accepted.

Yammer and LinkedIn

Yammer isn’t best of breed in enterprise messaging. Not even sure if doing anything with it and LinkedIn is worth the effort.

My suggestion is to open the coffers and take out a few more billions of dollars and acquire Slack. Then throw out all voice integrations and bolt Skype in there. But that has nothing to do with LinkedIn.

Outlook/Exchange and LinkedIn

Email is what drives LinkedIn in the most effective way.

Having the ability to embed and merge profiles properly into Outlook – without any ugly add-ons – that’s great.

But nothing earth shattering that we haven’t seen before with Rapportive on Gmail.

Office and LinkedIn

I guess that having a tighter integration between PowerPoint and Slideshare would be great. But that isn’t the reason LinkedIn was acquired.

Sarah Perez of TechCrunch wrote about the integration of Office and LinkedIn. It includes Outlook. Focuses on Outlook.

And mostly goes one-way: how LinkedIn can enrich Office/Outlook related information. A bit on how Office can enrich LinkedIn data by adding more users. But nothing about how LinkedIn’s functionality can grow. A shame.

If this is where things are headed – growing Office but not growing LinkedIn, then I am afraid LinkedIn is expecting a similar fate to Yammer and Skype. Its days of greatness will be behind it and its level of innovation and introduction of powerful features that can compete in the market – will come to an end.

Other Domains

Cortana and Microsoft’s CRM are areas I missed. You can read more about them in Richard’s analysis on Radio Free Mobile.

The Corporate Structure

It seems that LinkedIn will sit as an independent entity within Microsoft under Satya Nadella directly.

I wonder how that will make things easy for the tight integrations envisioned for LinkedIn and the rest of Microsoft’s assets. How easy will it get to get the Skype team to cooperate and assist the LinkedIn team to integrate Skype for Web? What will the Office team want in return for the data they will be passing to LinkedIn? Will legal even authorize it?

There will be a lot of coordination taking place here, and I do hope that along the way, they won’t lose what’s needed to be done – there’s a lot of synergies and power here, but this will require a lot of agility from a huge company.

Back to WebRTC

This affects larger players in the UC space. If (and that’s a big if) Microsoft can connect the dots of Office, Exchange, Skype and LinkedIn – this makes for a very compelling offering. One that can differentiate and top Cisco and Google.

If Microsoft can make LinkedIn into the congregation point of people across enterprises – and not only a place to find CVs – it will be in a position to expand its offering towards real time communications in ways that others will find hard to compete against. LinkedIn lacked this vision. I wonder if Microsoft can follow through – or will they as well see it as unnecessary.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post Will Microsoft’s Acquisition of LinkedIn Change the WebRTC Landscape? appeared first on BlogGeek.me.

How time flies.

About 10 months ago, the announcement of the creation of a new alliance caught me off guard.

Somehow, Google, Microsoft and a few other companies put their differences aside and decided to create the Alliance of Open Media. The intent – create royalty free video codec to rival H.265/HEVC. I’ve written about the Aliance of Open Media. It is time to revisit the topic.

A few things happened these last few months that are worth mentioning:

1. We’ve learned more about the alliance – Jan Ozer  wrote a good progress report
2. AMD, ARM and Nvidia joined the alliance
3. Ittiam joined the alliance
4. Vidyo joined the alliance

I am told work is being done on the actual codec itself. From the report Jan Ozer wrote, the following is apparent:

• Baseline for the codec is VP10 (Google)
• Most contributions of technologies on top of it come from Mozilla and Cisco; though I assume Microsoft is contributing there as well
• Hardware vendors are putting their weight to make sure the algorithms used are easy to place in a hardware design
• There’s a focus on GPU acceleration, which is important
• Intent is to have it integrated into a browser by the beginning of 2017 and have hardware acceleration a year later

All the right moves.

ARM and Nvidia

Adding ARM and Nvidia is quite a catch.

ARM is in charge of the architecture of most smartphones on the market today, along with many of the IOT devices out there. Having them on board means that considerations for mobile and low power devices are taken into consideration by the alliance – but also that the work of the alliance will find its way into future designs of ARM.

Nvidia is where you find GPU processing power. They complement the attendance of Intel, brining the important GPU players to the table. In a recent whitepaper I’ve written for Surf, I touched the GPU issue briefly. I’ve done some research in that domain, and it does seem like the GPU is the best candidate to handle our future video coding – having GPUs relevant to this next generation codec fron the start is an important catch for the alliance.

Ittiam

Ittiam is a recent addition to the alliance.

I’ve had the chance to know Ittiam a decade ago, while competing head to head with their VoIP software. They have expertise in the multimedia space and in video compression, but they still are the smallest (or least relevant) player in this alliance. Having them is required to fill in the ranks and grow in numbers.

It would be nice to see others join such as Imagination Technologies (who are larger and a lot more meaningful).

Vidyo

Vidyo just join the alliance. On one hand, it surprised me. On the other hand, it should have.

Vidyo is collaborating with Google for a long time now in VPx and WebRTC. Recently it reiterated that with the work it is doing on VP9 SVC for WebRTC (you can find out more about it on a guest post Alex Eleftheriadis shared here on scalability and VP9).

Their addition to the alliance means several things:

• Vidyo is making itself an integral part of every initiative related to future video codecs. This is a smart move, as it maintains its lead in the backend side and the smarts that is placed on top of SVC capabilities
• This future codec will have SVC support in it, hopefully from the moment it is released to market
• While a smaller company compared to the other members, the contribution of Vidyo to the alliance can be larger than many others of its members

Qualcomm

Qualcomm is missing.

So is Samsung.

And a few other smaller mobile chipset vendors.

I think it is their loss, as well as a missed opportunity.

They both should have joined the alliance at its inception.

Apple

Apple being Apple, they aren’t a part of it. Putting ads in the App Store and changing subscription revenue sharing models were more important to them, which is understandable.

The thing I don’t understand here is that Apple has removed most of its support in H.265. What does it have to lose by joining the alliance?

There are three paths available to Apple:

1. Go with H.265. The current reduction in its support of H.265 can only be explained as a negotiation tactic in such a case
2. Go with the Alliance of Open Media. Which it could do at any point in time. But if that is the case, then why wait?
3. Release its own unique iCodec. Apple knows best, and it is time to lock its customers a bit further anyways

I wonder which route they are taking here.

Content Creators and Service Providers

We’ve got YouTub, Netflix and Amazon already covered. The internet may rejoice.

But what about Game of Thrones? Or the next movie blockbuster? Are they staying on the route of H.265 or will they veer away from it towards the alliance?

Hard to tell, though for the life of me, I can’t understand a long term decision of staying with H.265.

It would be nice to see the large studios and even Bollywood join the alliance – or at the very least back it publicly.

Timeline

If we look at the VP9 timeline, we havethe following estimates:

• 1 year – Chrome decoding, along with a small percentage of YouTube videos supported
• 2 years – First chipsets and reference designs support. My bet is on Nvidia and Intel here
• 2.5 years – Chrome official support of it for WebRTC

H.264 in WebRTC

H.264 is hear to stay. More worrying – H.264 will grow in popularity in WebRTC services during 2016.

This progress and success of the alliance changes nothing in the current ecosystem and the current video technology.

The future of H.265

The future of H.265 does look grim. I do hope the alliance will kill it.

H.265 is in a collision course with VP9. It is still the more “popular” choice in legacy businesses, but that may change, as commercial deployments of it are small or non-existent.

The alliance simply means that a future codec is based on the VPx line of codecs instead of the H.26x ones. Now developers shifting from H.264 to a better codec will need to decide if they switch codec lines now or just later.

The royalty issues around H.265 along with the progress made in the alliance should tip the scales towards VP9 on this one.

What’s next?

Money time.

Where does that leave us all?

• Vendors who handle codecs directly should join the alliance. The benefits outweigh the risks.
• Consumers and users can continue not caring
• Developers, especially those of backend media servers, need to decide if they shift towards VP9 or wait for the next generation to switch to a royalty free codecs. They also need to decide if they want to use VP8 or H.264 today

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post The Alliance of Open Media – 10 Months in appeared first on BlogGeek.me.

H.264 is set to replace VP8 for WebRTC services.

You can thank Fippo for making me write this one.

Microsoft ended last week with an announcement of sorts on their Edge dev blog, indicating that H.264/AVC support for ORTC is now available in Edge.

• Yes. It is ORTC and not WebRTC
• Yes. It is only behind a runtime flag
• Yes. It is only on Edge. No IE

But then again, it is the only way today (or at least tomorrow) to get a video call running cross browser between Firefox, Chrome and Edge. VP8 or VP9 gets you as far as Chrome and Firefox.

Which got me to this one over here. Edge support for H.264 in ORTC isn’t much. It isn’t even interesting in the bigger scheme of things (Edge has literally no market share compared to the other browsers, so why bother with it?). And still it marks a turning point – one in which we can all ask ourselves what video codec should we be leaning towards if we started developing a product that uses WebRTC today?

Last year, the answer would have been “VP8”.

A few months ago, it was, “it depends”.

Today, it will lean towards “H.264, unless you must use VP8”.

Here are 4 reasons why this is happening:

#1 – Browser interop baseline

If you want your service to get the most coverage on as many browsers as possible and you need video, then H.264 is the way to go. In a few months, H.264 will get official support by all of these vendors and that will be the end of it. Furthermore, you can expect Apple to use H.264 first and contemplate VP8 – same as Microsoft is doing now with Edge.

#2 – Mobile

Mobile devices like H.264 more than they like VP8. Video codecs take up a lot of resources. To overcome this, mobile handsets use hardware acceleration for video codecs. They all have H.264 video acceleration (though you can’t always gain access to it as a developer). Many of them don’t even know how to spell VP8. This boils down to WebRTC implementations on mobile needing to implement VP8 using software.

Some developers ended up replacing VP8 with H.264 on mobile just because of this reason. Especially for mobile only products.

While I am sure support for VP8 is improving in new chipsets, there’s this pesky issue of supporting the billion and more devices that are already out there. And now that all browsers support H.264 in one way or another, what incentive do developers needing to support mobile apps have to use VP8?

#3 – Legacy video systems

All them video conferencing systems? They use H.264. Most don’t have VP8. Not even in their latest released products. The way they end up supporting WebRTC until today is via a specialized gateway, on the MCU or not at all.

Transcoding was one of the main barriers to getting WebRTC to legacy video systems. It just costs a lot. It would have been easier to just go H.264 all the way. Which is what is now available.

It is one of the reasons why Cisco first worked on Firefox with Spark. It made a decision to use H.264 for WebRTC instead of transcoding from VP8.

#4 – Streaming

Over 60% of the Internet traffic is video. Most of it isn’t real time video, but rather the YouTube or Netflix kind. Passive consumption.

Video streaming today is predominantly H.264 based, and at times VP9 (=YouTube whenever possible).

To get video content on an iPhone device, HLS is required, and that again means H.264.

So again we are left with the alternative of either transcoding our WebRTC generated content to H.264 when we want to stream it out – or to create it using H.264 to begin with.

Do you even care?

If your service is a 1:1 calling service with no server side media processing, then you shouldn’t even care. In such a case, whatever the browsers end up negotiating will be good enough for you (and most probably the best alternative for that specific situation).

Those who invested in server side media processing, be it recording, mixing, routing –  have made investments that are targeted at VP8. Modifying these to work with H.264 as well may not be trivial. For them, the decision of switching to H.264 is a harder one to make, but one that needs to be addressed.

The Future of Video Coding in WebRTC

Once we step into the future, we see VP9. And the SVC flavor of VP9.

And then there’s the Alliance of Open Media and the work they are doing towards a widely accepted next gen royalty free video codec. I’ve touched the progress they are making in my recent Virtual Coffee session

For the record, I rather hate H.264 and what it stands for. But now I must accept that it is here to stay and grow with WebRTC.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post 4 Reasons to Choose H.264 for your WebRTC Service (or why H.264 Just won over VP8) appeared first on BlogGeek.me.

[Luis Lopez is the face in front of Kurento, one of the popular open source media servers that can handle WebRTC. He wanted to share here the story of the new open source WebRTC PaaS – NUBOMEDIA]

When I first heard about WebRTC by 2011, I was fascinated by the idea of standardized APIs and protocols enabling the creation of interoperable RTC applications for the Web. However, I noticed very soon that my peer-to-peer services were too limited and that, as a developer, I was hungry for further features that could only be provided by a WebRTC infrastructure. This is why I got involved in the Kurento project for creating a media server. Kurento got nice traction but, as it was maturing, we found an increasing number of feature requests related to its scalability. The message was quite clear: a cloudification of Kurento was necessary.

With this in mind, by 2014 we got down to work and, with the financial support of the European Commission, we worked hard during a couple of years in cooperation with some of the most remarkable cloud experts around Europe. These efforts were worthy: NUBOMEDIA, the first open source WebRTC PaaS, is now a reality.

NUBOMEDIA: the first WebRTC PaaS

In the WebRTC ecosystem, scalable clouds for developers are not new. Providers such as Tokbox, Kandy, Twilio and many others offer them. These solutions are commonly called “WebRTC API PaaS”, “WebRTC Cloud APIs”, or just “Cloud APIs” as they expose a number of WebRTC capabilities through custom APIs that exhibit all the nice “-ilities” of cloud services (i.e. scalability, security, reliability, etc.)

For NUBOMEDIA we also considered this “Cloud API” concept as a solution. However, although APIs are the main building block developers use for creating applications, applications are more than just a set of API calls. After analyzing WebRTC developers’ needs, we felt more appealing the concept of platform than the concept of API. A platform is more than an API in the sense that it provides all the required facilities for executing applications. These typically include an operating system, some programming-language-specific runtime environments and some service APIs. The cloud version of a platform is commonly called a PaaS, which is (literally) a platform that is offered “as a Service”.

There are many such PaaSes in the market including Heroku, the Google App Engine or AWS Elastic Beanstalk. All of them expose to developers the ability of uploading, deploying, executing and managing applications written in different programming languages. These PaaS services are quite convenient as they let developers to concentrate on creating their applications’ logic while all the complex aspects of provisioning, scaling and securing them are assumed by the PaaS. In spite of the wide offer of PaaS services, we noticed that most common PaaS providers did not expose WebRTC capabilities as part of their APIs. Hence, WebRTC developers were not able to enjoy all the advantages of full PaaSes.

The main difference between a WebRTC cloud API and a full WebRTC PaaS is illustrated in the following figure. As it can be observed, WebRTC Cloud API providers (left) do not host developers’ applications, but just expose some WebRTC capabilities through a network API that applications consume. On the other hand, full WebRTC PaaSes host application and take the responsibility of executing, scaling and managing them.

Based on these ideas, the NUBOMEDIA idea emerged clearly: instead of evolving Kurento into a cloud API we should rather create a full PaaS out of it, so that developers could enjoy the nice features of PaaSes (i.e. application deployment, execution, scaling, etc.) while consuming the Kurento APIs in a scalable and secure way.

Why NUBOMEDIA may be interesting for you

NUBOMEDIA is now a reality and it can be enjoyed openly by developers worldwide. Like solutions such as OpenShift, Cloud Foundry or Apprenda, NUBOMEDIA is a private PaaS in the sense that it consists of an open source software stack that can be downloaded, installed and executed on top of any OpenStack IaaS cloud.

If you are a developer, you may be interested in trying NUBOMEDIA for your next application as it combines the simplicity and ease of development of WebRTC Cloud APIs with the flexibility of full PaaSes. When doing so, consider that NUBOMEDIA is a Java PaaS. Hence, you will be able to leverage all the capabilities of the Java platform for creating your WebRTC application. The only difference with other Java PaaS services it that NUBOMEDIA will provide you a specific SDK through which you will be able to access the complete feature set of Kurento in a scalable way.

From a practical perspective, the main differences between NUBOMEDIA and other WebRTC cloud solutions are illustrated in the next figure. As it can be seen, there is a trade-off between flexibility and simplicity: the simplest the development, the less flexible the application is and the more difficult it is to adapt it to custom needs and requirements.

For example, most flexible solutions (IaaS on the bottom left corner of the image) require complex developments for creating fully operational WebRTC applications. On the other hand, SaaS solutions (top right corner) do not require much development efforts, but developers’ ability for customizing and adapting it to special requirements is typically very limited. For this reason, WebRTC developers tend to prefer WebRTC Cloud APIs that provide some flexibility but, at the same time, enable simple developments.

NUBOMEDIA also positions within this balance but giving more prevalence to flexibility. This makes NUBOMEDIA more suitable for developments requiring to comply with special or rare requirements. Just for illustration, these are some of the things you can make with NUBOMEDIA that are complex to achieve using the common WebRTC Cloud APIs:

• To use the signaling protocols you prefer (e.g. SIP, XMPP, custom, etc.)
• To have special communication topologies. For example, imagine that you need a videoconferencing room with “spy participants” that can view others but should not be noticed by the rest; or imagine that you need simultaneous translators that are not viewed but need to listen to some participants while being listened by others.
• To have custom AAA (Authentication, Authorization and Accounting). For example, imagine that you wish to implement rules customizing who can access the media capabilities (e.g. recording, viewing a specific stream, etc.) so that they depend on some non-trivial logic (e.g. context information, time-of-day, time-in-call, etc.).
• To go beyond calls. We may imagine lots of use-cases where WebRTC might be used beyond plain calls. For example, person-to-machine or machine-to-machine scenarios where you need cameras to connect to users or to other systems in a flexible way without restricting to the typical room videoconferencing models commonly exposed by WebRTC Cloud APIs.

As another interesting property, as NUBOMEDIA is a private PaaS, it can execute onto any OpenStack infrastructure. This means that the operational costs of an application running in NUBOMEDIA are fully under your control as you can decide in which IaaS to deploy the PaaS. This significantly reduces the operational costs with respect to an equivalent application consuming a Cloud API, as the Cloud API provider margins disappear.

The NUBOMEDIA Open Source Community

We have created NUBOMEDIA following the same open philosophy we used with Kurento. Currently, it is supported by an active and vibrant open source software community that is structured as an association of several projects providing different technological enablers including: the cloud orchestration mechanisms, the PaaS management technologies, the media server, many media processing modules and client SDKs for Android, iOS and Web.

If you are interested in knowing more about NUBOMEDIA you can check the community documentation where you will be able to find detailed information showing how to install and manage the platform and how to develop and deploy applications into the PaaS. You can also check the community YouTube channel and see one of the many videos with demos and tutorials illustrating how to develop and deploy NUBOMEDIA applications. If you want to know about the latest news of the NUBOMEDIA Community, you may follow it on Twitter.

 

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.

Get your Choosing a WebRTC Platform report at a $700 discount. Valid until the beginning of May.

The post NUBOMEDIA: the first open source WebRTC PaaS appeared first on BlogGeek.me.

And not only the development.

For too many years now we’ve been enamored with Agile. Supposedly the successor of the fountain development model, agile is all about short iterations and faster feedback.

In larger places, agile is usually just the next undertaking of the program manager – or whatever equivalent you have in the company that deals with processes. I remember hearing the term “we must be agile”. With the end result being… 18 to 24 months product release cycles.

That’s nice, but it isn’t really agile – at least not more than the Geek & Poke caricature above.

I had an interesting discussion with a consultant during the London WebRTC conference two months ago. He complained that browsers are moving too fast, making it hard for enterprises to follow suit and adopt WebRTC.

Here’s a quick reminder – WebRTC doesn’t care about enterprises. It cares about innovation and forward moving. If something breaks, then you’re just out of luck.

WebRTC today forces enterprises to think and act Agile

Why is this the case?

• Browsers are updating at the speed of light – every 6 to 8 weeks
  • Each time they do, something gets deprecated
  • And other things can get broken
  • This is doubly so with WebRTC, which is essentially a perpetual work in progress
  • And will stay that way well into 2017
  • Enterprises need to be prepared for it and willing to update their own deployments to keep pace
• WebRTC’s codecs are changing – and upgrading
  • VP9 is upon us
  • H.264 is here to stay
  • R&D teams need to adopt new codecs to keep their service pristine
  • Otherwise, competitors will do it and win the market simply by offering better user experience and media quality
• New capabilities
  • Browser side recording?
  • Playing video from a canvas?
  • Pipelining media?
  • WebRTC has it all, and things are only improving
  • Do these affect your product? Do you need someone to define how this changes things for you?

What Needs to Change

Enterprises need to change their stance. They aren’t in control anymore. They should act accordingly.

This means having product managers, developers, testers, support and IT all working in concert in an agile way – thinking about launched products as living and breathing entities that must be updated continuously.

Thinking of launchng a WebRTC based product? Especially if it is an on premise one – you must make sure you understand the implications AND that your customers understand the implications as wlel.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post With WebRTC, Vendors Must Embrace True Aglie appeared first on BlogGeek.me.

Wasn’t there enough complications already?

I use Hangouts all the time. At testRTC, we use it for most of our demos and customer meetings. As good and complete as Hangouts is in terms of the feature set that I need, it can be quite confusing at times. Something that probably stems from its dual use nature: Google Hangouts is both a consumer messaging app and an enterprise unified communications app. And while the two rely on the same technology – they are not the same.

If there is one other similar service that does that it is Skype, and even with it, it is mostly by branding and not by the service itself (I am not sure how uniform the Skype and Skype for Business apps and infrastructure are, but they sure are getting worse in the last year or two).

Can a single app rule them all? By the way things look today – no.

And yet this latest move by Google leaves me somewhat baffled.

At Google I/O’s keynote yesterday, Google came out with a slew of announcements. The ones interesting for me here are those related to messaging or to WebRTC:

• Allo – a new messaging app to fend off Facebook Messenger
• Duo – a new video chat app to fend off Apple FaceTime
• Firebase – a new version which I won’t be covering here

Allo

Allo is Google’s “Smart Messaging App”.

It is yet-another-messaging-app – until you see the suggestions it gives you.

I use Switfkey as my Android keyboard, and it “learns” what you click so future clicking is shorter. The smart messaging replies in Allo are the next step for me – instead of doing it on the word level it does it on the conversation level.

The smarts in Allo seems to be split into two parts – what Allo does on his own, which is suggestions inside the conversation. On top of it, Google added something they call Google Assistant, which goes “out” of the conversation to offer suggestions for external actions. The example in the I/O keynote was restaurant reservation.

This competes directly with messaging and bots. Specifically Facebook. Maybe others.

Where can this lead us?

• If I were Google, I’d make this into a bot or a layer that can be stitched into everything
• Messaging services could use it directly, which will allow Google to sift every interaction and offer their suggestions and automation – no matter the app
• Would messaging apps adopt it? I don’t know, but why shouldn’t they try it out?

Duo

Duo IS WebRTC. Or at least what you can do with it.

A not about Duo, WebRTC and purism – Duo is mobile only (for now), closed app, running on Android and iOS.

I’ll repeat that.

Duo is mobile only (for now), closed app, running on Android and iOS.

No web browser. No complaints about unsupportive Safari or IE browsers. And from Google.

To those who decide to skip WebRTC just because it doesn’t run on IE or not supported by Safari (without really understanding what WebRTC means) – this should be the best wake up call. Coming directly from Google, the company who wants everything running in the browser.

Recognize anyone in the Duo app?

If tech media outlets taught me anything this time, is that you should be suspicious at what they write.

Ingrid Lunden on TechCrunch did a nice write up on Duo, offering the gist of it:

• 1:1 video chat app, like FaceTime
• Focus is on super fast (responsiveness) and media quality
• You see the caller’s video before you answer a call. A nice gimmick I guess
• Based on WebRTC

This is where things flal apart a bit in her coverage:

The other thing that Duo is touting is the engineering that has gone into making the video in the app work. Google says it will work the same whether your network is superfast or patchy. This in itself, if it really bears out, would be amazing for anyone who has cursed his or her way through a bad Hangout or Skype call.

Duo was built by the same team that created WebRTC and it uses WebRTC, engineering director Erik Kay said today on stage at I/O. It was built using a new programming protocol, Quic, which Google unveiled last year as a route to speeding up data-heavy applications that travel over the web.

So Duo has this magic of working better than Hangouts and Skype. Great. So why didn’t Google just build it into Hangouts? Especially considering both use WebRTC…

That reference to the QUIC protocol – to be sure – this does NOTHING to the actual media – only to the time you wait until the smartphone “dials”. You shave a few hundreds of milliseconds there, but that won’t move the needle in the industry either way.

Mashable’s Raymond Wong explains QUIC and how it is a serious advantage:

Google says people don’t place as many video calls with their friends and family because connections can sometimes be spotty and drop. Duo uses a new protocol called QUIC that’s supposed to be more robust than any other video calling infrastructure out there.

QUIC won’t make the call more robust or get calls work better. It will just make them make the initial connection faster or having the mute button appear QUICker on the other end’s device. QUIC is a nice touch of how Google can go to extremes sometimes with optimizing the technology. Sometimes it makes a lot of sense, but other times less so. QUIC is definitely a step forward from TCP, but its effect on video calling isn’t huge.

What do we have here? Apple FaceTime, done by Google, working on both Android and iOS. Nothing more and nothing less.

 

There’s also Jibe

An acquisition from last year, placing Google as a serious RCS player.

No mention of it in I/O. Probably because its focus is on “fixing”/”improving”/”popularizing” the basic Google Messenger app, which does SMS.

This being something that needs to be synchronized with carriers – it will take time to materialize.

The future of Hangouts

Is the enterprise.

With Allo and Duo, why should consumers even care about Hangouts from now on?

Can this succeed?

Can such an approach succeed for Google? Having multiple communication apps, two of them announced in the same day.

Can they reach mass adoption?

Google is taking the path of unbundling here, but doing it to what was until now the same service – communications. They split it into multiple smaller apps, tearing real time voice and video calling from current messaging apps. It feels somewhat like iMessage and FaceTime, but Allo is more capable than iMessage (sans SMS) and Duo is a bit more capable than FaceTime (the knock knock feature).

I can’t really decide if taking this unbundling approach is better or worse. Will it increase engagement of users with these services or hurt them. And where does Google Hangouts fit in here, if at all?

The post Allo, Duo, Hangouts or Jibe? Help… appeared first on BlogGeek.me.

A refresher on what I’ve written in 2014 (here and here).

Can you guess the signaling and transport here?

WebRTC as a protocol comes without signaling. This means that you as a developer will need to take care of it.

The first step will be selecting the protocol for it. Or more accurately – two protocols: transport and signaling. In many cases, we don’t see the distinction (or just don’t care), but sometimes, they are important. A recent question in the comments section of one of the two posts mentioned here in the beginning, got me to write this explanation. Probably yet again.

WebRTC Transport Protocols and Browsers

This actually fits any browser transport protocol.

A transport protocol is necessary for us to sent a message from one device to another. I don’t care what is in that message or how the message is structured at this point – just that it can be sent – and then received.

HTTP/1.1

5 years ago browsers were simple when it came to transport protocols. We essentially had HTTP/1.1 and all the hacks on top of it, known as XHR, SSE, BOSH, Comet, etc. If you are interested in the exact mechanics of it, then leave a comment and I’ll do my best to explain in a future post (though there’s a lot of existing explanation around the internet already).

I call the group of solutions on top of HTTP/1.1 workarounds. They make use of HTTP/1.1 because there was no alternative at the time, but they do it in a way that makes no technical sense.

Oh – and you can even use REST to some extent, which is again a minor “detail” above HTTP/1.1.

Since then, three more technique materialized: WebSocket, WebRTC and recently HTTP/2.

WebSocket

The WebSocket was added to do what HTTP/1.1 can’t. Provide a bidirectional mechanism where both the client and the web server can send each other messages. What these messages are, what they mean and what type of format they follow was left to the implementer of the web page to decide.

There’s also socket.io or the less popular SockJS. Both offer client side implementations that simulate WebSocket in cases it cannot be used (browser or proxy doesn’t support it). If you hear that the transport is socket.io – for the most part you can just think about it as WebSocket.

When your WebSocket work great, they are great. But sometimes it doesn’t (more on that below, under the HTTP/2 part).

WebRTC’s Data Channel

To some extent, the Data Channel in WebRTC can be used for signaling.

Yes. You’ll need to negotiate IP addresses and use ICE first – and for that you’ll need an additional layer of signaling and transport (from the list in this post here), but once connected, you can use the data channel for it.

This can be done either directly between the two peers, or through intermediaries (for multiple reasons).

Where would you want to do that?

1. To reduce latency in your signaling – this is theoretically the fastest you can go
2. To reduce load on the server – now it won’t receive all messages just to route them around – you’ll be sending it things it really needs
3. To increase privacy – not sending messages through the server means the server can’t be privy to their content – or even the fact there was communication

For the most part, this is quite rare as transport for signaling in WebRTC.

HTTP/2

I’ve written about HTTP/2 before. Since then, HTTP/2 has grown in its popularity and spread.

HTTP/2 fixes a lot of the limitations in HTTP/1.1, which can make it a good long term candidate for transport of signaling protocols.

A good read here would be Allan Denis’ writeup on how HTTP/2 may affect the need for WebSocket.

 

WebRTC Signaling Protocols

Signaling is where you express yourself. Or rather your service does. You want one user to be able to reach out to another one. Or a group of people to join a virtual room of sorts. To that end, you decide on what types of messages you need, what they mean, how they look like, etc.

That’s your signaling protocol.

As opposed to the transport protocol, you aren’t really limited by what the browser allows, but rather by what you are trying to achieve.

Here are the 3 main signaling protocols out there in common use with WebRTC:

SIP

I hate SIP.

Never really cared for it.

It has its uses, especially when it comes to telephony and connecting to legacy voice and video services.

Other than that, I find it too bloated, complex and unnecessary. At least for most of the use cases people approach me with.

SIP comes from the telephony world. Its main transport was UDP. Then TCP and TLS were added as transport protocols for it. Later on SCTP. You don’t care about any of these, as you can’t really access them directly with a browser. So what was done was to add WebSocket as a SIP transport and just call it “SIP over WebSocket”. Before WebRTC got standardized (it hasn’t yet), SIP over WebSocket got standardized and already has an RFC of its own. Why is it important? Because the only use of SIP over WebSocket is to enable it to use WebRTC.

So there’s SIP. And if you know it, like it or need it. You can use it for your WebRTC signaling protocol.

XMPP

I hate XMPP.

Not really sure why. Probably because any time I say something bad about it, a few hard core fans/followers/fanatics of XMPP come rushing in to its rescue in the comments section. It makes things fun.

XMPP has a worldview revolving around presence and instant messaging, and use cases that need it can really benefit from it – especially if the developer already knows XMPP and what he is doing.

If you like it enough – make sure to slam me in the comments – you’ll find their section at the end of this post…

Proprietary

I hate NIH. And yet a proprietary signaling protocol has a lot of benefits in my view.

In many cases, you just want to get the two darn users into the “same page”. Not much more. I know I am dumbing it down, but the alternative is to carry around you extra protocol messages you don’t need or intend using.

In many other cases, you don’t really want to add another web server to handle signaling. You want your web server to host the whole site. So you resolve into a proprietary signaling protocol. You might not even call it that, or think of it as a signaling protocol at all.

How to Choose?

Always start from the signaling protocol.

If there’s reason to use SIP due to existing infrastructure or external systems you need to connect to – then use it. If there’s no such need, then my suggestion would be to skip it.

If you like XMPP, or need its presence and instant messaging capabilities – then go use it.

If the service you are adding WebRTC to already has some logic of its own, it probably has signaling in there. So you just add the relevant messages you need to that proprietary signaling.

In any other case, my advice would be to use a proprietary signaling solution that fits your exact need. If you’re fine with it, I’d even go as far as picking a SaaS vendor for signaling.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post WebRTC Signaling Protocols and WebRTC Transport Protocols Demystified appeared first on BlogGeek.me.

Grab your copy now.

I am in the last stretch of updates for my Choosing a WebRTC API Platform report. In the past month, the report has been available at a discounted price – from $1950 down to $1250. Purchasing the report includes 1 year of updates, which means that if you get your copy now – you’ll be receiving the new update next week.

What’s new in the report?

Things are at constant change with the WebRTC ecosystem, and the best place to see it is in the API space. Since the last update, we’ve experienced the rebranding of Comverse as XURA, which affected their Forge platform as well.

Here’s what you will find in the updated report, due next week:

• Updated all vendor profiles and feature sets, so they now reflect the existing
• Added a new vendor – QuickBlox. This brings us to 24 covered platforms in the report
• I added a new KPI to the report – investment level – where I indicate for periods between updates how much investment was made in new features and capabilities in the platform. This can be an indicator to the level of commitment the vendor has to his platform and what to expect moving forward when it comes to new features being introduced
• I’ve written a new Vendor Selection Blueprint. This document can assist you in the vendor selection process by guiding you through it. It includes an Excel sheet as well as a mockup example of such a process for an imaginary use case
• Presentation deck of the visuals has been redesigned and improved, so now if you need visuals – they will be even more professional looking

What do you get when you purchase the report?

The report itself isn’t only a PDF file you print and put on your manager’s table. It includes a lot more than that:

• The report, in PDF format (obviously)
• 1 year of free updates, these will cover 1-2 more updates (I tend to publish them every 6-8 months or so)
• Site membership access to additional materials
• Online comparison matrix, to make quick comparisons easy to handle
• Presentation visuals, which you can use in your own presentations
• Vendor Selection Blueprint, to guide you through the vendor selection process
• Access to the monthly Virtual Coffee sessions as well as the archived sessions

How to purchase?

Online.

1. Go to the WebRTC PaaS report page
2. Scroll down to the end of the page
3. Select the Premium option and press the BUY NOW button
4. Use your PayPal account or a credit card to make the purchase

If you do this in the next couple of days – you are guaranteed to enjoy the discounted price.

The post Last Chance to Enjoy a $700 Discount on my WebRTC PaaS Report appeared first on BlogGeek.me.

The real benefits of Apple and WebRTC has been left out of the conversations.

Can you help Apple find WebRTC?

There’s been too much chatter recently about Apple adding WebRTC. I am definitely in the opinion of Fippo here:

Things are going wild on the twitter #webrtc tag. Not a day without someone writing about Apple and WebRTC. Usually with little actual information.

I am not one to say I have inside information – I don’t. I don’t even know personally any Apple employee.

What I can say for sure, is that the real discussion on why Apple is important in the ecosystem of WebRTC has been ignored – as does the only place that is important.

Apple can add WebRTC in 3 places:

1. Safari on Mac OS X
2. Safari on iOS
3. Webview on iOS

Just as a point of reference, when Google adopted WebRTC, it added it to Chrome on the desktop, then to Chrome on Android and somewhat later to Android webview. Not surprisingly, the priorities were decided based on the complexity and risk of the tasks (from the “easiest” to the most complex).

WebRTC in Mac OS X Safari

Safari on Mac OS X is nice, but at this point it won’t matter much. For the most part, Chrome is the leading browser these days – surpassing even IE; and from asking around, it seems that Mac users are used to switching from Safari to Chrome when needed – it isn’t unheard of.

Adding support for WebRTC to Safari on Mac OS X is nice, but for the most part, it won’t change things in any meaningful way.

WebRTC in iOS Safari

Safari on iOS is interesting. For iOS, there’s only a single alternative today, and that’s to port WebRTC on your own and integrate it into your app.

While this works well for most use cases, there are a few edge cases where this isn’t desirable.

Here are 4 such areas:

#1 – Porn

I had an interesting discussion two years ago with a porn vendor who wanted to start exploring WebRTC as a long term solution and a migration path from Flash.

Their main concern was that porn viewers were migrating from the desktop to their smartphones. I guess it has something to do with phone use in restrooms.

Surprisingly (or not), the main reason for him to want WebRTC was iOS. Applications on iOS require to be puritan apps to a large degree. If an app’s content doesn’t abide to the app store submission rules (and porn doesn’t), then the app won’t get approved. This becomes a kind of a headache if what you do is serve porn.

There are two ways to “fix” that today, both run in the browser (Safari on iOS that is):

1. Use HLS to stream the video, but the latency wasn’t good for this vendor. He needed low latency. In his words, “the viewer needs to be able to interact with the performer and tell her what to do”. Apparently, waiting 20 or 30 seconds until the performer responds to the viewer’s whims isn’t fast enough
2. Capture JPEG images and send them over HTML as if they are video. It means 3 frames per second or something just as stupid, but it seems porn viewers are happy with it. At least to some extent

Having WebRTC in Safari for iOS means no need to go through the approval process of Apple’s App Store, something impossible for such companies.

As you might have guessed, I learned a lot in the meeting with that company.

#2 – Click to dial

There are times when WebRTC is used for customers and potential customers to reach out to the vendor. They happen to search the internet, bump into your travel agency, and want to make a call to book a flight. Or they might have bumped into an issue with the toaster they purchased and want to ask for assistance. Whatever the case is, that person has no inclination to install an app on his phone just to make that one time interaction.

WebRTC on Safari’s iOS means that this is possible now to achieve for iOS users – and not only the Android ones.

#3 – Guest Access

In many cases, there’s a UC (Unified Communication) system already in use. While its focus is in employees communicating with each other, these systems also allow for guest access. Think of joining one of them GoToMeeting or WebEx sessions. First thing you do in them is install a client to be able to do them – or fumble around with a phone number and a PIN code. Both ugly practices.

WebRTC enables to leave that behind by sending the guest a URL in his email – not a URL with instructions in it, or an installation link – but a URL to the actual session. Along the way, you can also make that URL unique per participant if you wish. This is already available today – unless you use an iOS device.

#4 – Gaming (the gambling kind)

Apple takes 30% of all purchases made through apps. 30%

Gambling and booking usually work on profit margins that are usually lower than 10%.

That being the case, how, if at all, can they make money out of gamblers using apps without letting them pay through the app? The whole idea of gambling is the reduction of friction.

Now, getting gamblers to open a URL and play from there, with whatever interactivity they wish to add through the use of WebRTC – that’s a useful capability.

WebRTC in iOS Webview

This is where things get really interesting.

As stated earlier, most consumption on mobile today is done via apps. For WebRTC, most of these apps are developed as native apps. This happens for a couple of reasons:

1. Force of habit. That’s just life as we know it today
2. Native tends to work slightly better than HTML5 apps
3. WebRTC dictates porting it and wrapping it as an SDK on iOS today

While native is great, HTML5 is even better. It offers cross platform development capabilities across desktop, browser and mobile – and in them, across ALL operating systems. WebRTC isn’t there yet because Apple isn’t there yet.

Add to that the new technique behind PWA (Progressive Web Applications), and you may well find HTML5 enticing for your service. To support such a thing, WebRTC on iOS isn’t enough, but it is still needed. What got this piece of technology into my radar was this write up by Henrik Joreteg – Why I switched to Android after 7 years of iOS. It goes into detail on the user experience of PWAs.

Even if you decide to stick to native development, having WebRTC implemented, optimized and fine tuned by Google and Apple for their respective mobile operating systems and then just slapping a Webview in place to use them in your app is a worthwhile investment.

–

Will Apple add WebRTC to its products? Probably yes

Do we know when will it happen? No

Should we prepare for it? Maybe. You tell me

 

The post What will Happen when iOS Webviews Adopt WebRTC? appeared first on BlogGeek.me.

Both.

VP8 and VP9 are video codecs developed and pushed by Google. Up until recently, we had only VP8 in Chrome’s WebRTC implementation and now, we have both VP8 and VP9. This lead me to several interesting conversations with customers around if and when to adopt VP9 – or should they use H.264 instead (but that’s a story for another post).

This whole VP8 vs VP9 topic is usually misunderstood, so let me try to put some order in things.

First things first:

1. VP8 is currently the default video codec in WebRTC. Without checking, it is probably safe to say that 90% or more of all WebRTC video sessions use VP8
2. VP9 is officially and publicly available from Chrome 49 or so (give or take a version). But it isn’t the default codec in WebRTC. Yet
3. VP8 is on par with H.264
4. VP9 is better than VP8 when it comes to resultant quality of the compressed video
5. VP8 takes up less resources (=CPU) to compress video

With that in mind, the following can be deduced:

You can use the migration to VP9 for one of two things (or both):

1. Improve the quality of your video experience
2. Reduce the bitrate required

Let’s check these two alternatives then.

1. Improve the quality of your video experience

If you are happy with the amount of bandwidth required by your service, then you can use the same amount of bandwidth but now that you are using VP9 and not VP8 – the quality of the video will be better.

When is this useful?

• When the bandwidth available to your users is limited. Think 500 kbps or less – cellular and congested networks comes to mind here
• When you plan on supporting higher resolutions/better cameras etc.

2. Reduce the bitrate required

The other option is to switch to VP9 and strive to stay with the same quality you had with VP8. Since VP9 is more efficient, it will be able to maintain the same quality using less bitrate.

When is this useful?

• When you want to go “down market” to areas where bandwidth is limited. Think a developed countries service going to developing countries
• When you want to serve enterprises, who need to conduct multiple parallel video conferences from the same facility (bandwidth towards the internet becomes rather scarce in such a use case)

How is bitrate/quality handled in WebRTC by default?

There is some thing that is often missed. I used to know it about a decade ago and then forgot until recently, when I did the comparison between VP8 and VP9 in WebRTC on the network.

The standard practice in enterprise video conferencing is to never use more than you need. If you are trying to send a VGA resolution video, any reputable video conferencing system will not take more than 1 Mbps of bitrate – and I am being rather generous. The reason for that stems from the target market and timing.

Enterprise video conferencing has been with us for around two decades. When it started, a 1 mbps connection was but a dream for most. Companies who purchased video conferencing equipment needed (as they do today) to support multiple video conferencing sessions happening in parallel between their facilities AND maintain reasonable internet connection service for everyone in the office at the same time. It was common practice to reduce the internet connection for everyone in the company every quarter at the quarterly analyst call for example – to make sure bandwidth is properly allocated for that one video call.

Even today, most enterprise video conferencing services with legacy in their veins will limit the bitrate that WebRTC takes up in the browser – just because.

WebRTC was developed with internet thinking. And there, you take what you are given. This is why WebRTC deals less with maximum bandwidth and more with available bandwidth. You’ll see it using VP8 with Chrome – it will take up 1.77 Mbps (!) when the camera source is VGA.

This difference means that without any interference on your part, WebRTC will lean towards improving the quality of your video experience when you switch to VP9.

One thing to note here – this all changes with backend media processing, where more often than not, you’ll be more sensitive to bandwidth and might work towards limiting its amount on a per session basis anyway.

All Magic Comes with a Price

We haven’t even discussed SVC here and it all looks like pure magic. You switch from VP8 and VP9 and life is beautiful.

Well… like all magic, VP9 also comes with a price. For start, VP9 isn’t as stable as VP8 is yet. And while this is definitely about to improve in the coming months, you should also consider the following challenges:

• If you thought VP8 is a resource hog, then expect VP9 to be a lot more voracious with its CPU requirements
• It isn’t yet available in hardware coding, so this is going to be challenging (VP8 usually isn’t either, but we’re coping with it)
• Mobile won’t be so welcoming to VP9 now I assume, but I might be mistaken
• Microsoft Edge won’t support it any time soon (assuming you care about this Edge case)

This is a price I am willing to pay at times – it all depends on the use case in question.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

 

 

The post VP8 vs VP9 – Is this about Quality or Bitrate? appeared first on BlogGeek.me.

How will we be able to live in a world without… SDP?

The one thing I love best about the WebRTC Standards website is that it looks at a place I neglect most of the time – the IETF and W3C. While I had my share of dealings with standardizaton organizations when I was young and pretty, it isn’t something I like doing much these days.

Last month, it seems a decision was made/in the process of being made – to prohibit SDP munging. As these things go, if this happens at all it will take VERY long to happen. That said, such a change will have huge impact on a lot of services that make use of this practice.

What’s WebRTC SDP munging?

SDP munging is a process of a WebRTC application taking its future in its own hands and deciding to change the SDP. With WebRTC, once the application sets the user media and connects it with a peer connection (=setting up to start a session), it receives the SDP blob that needs to be sent to the other participant in the session. This blob holds all of its capabilities and intents for the session.

If you want to learn more about the contents of the SDP, then this article on webrtcHacks will get you started.

Here’s a quick flow of what happens:

Where SDP munging takes place in WebRTC

Now that the application holds the SDP blob, the question that must be asked is what can the application should/can do with this SDP blob?

1. The application should pass it to the other participant. Probably by placing it in an HTTP request or a Websocket message
2. The application can change it (=mung it) before well… setting and sending it

The problem is in that second part.

What’s the problem with WebRTC SDP munging?

SDP embodies everything that is wrong about SIP. Or at least some of what’s wrong about SIP

There are several aspects to it:

1. Being a textual kind of a protocol that is open as hell, it is open to interpretation of humans, making it hard to use. Interoperability is a headache with it, and now we’re leaving it at the hands of web developers. It becomes doubly hard, as there are extensions to SDP – some standardized, some in process and some just proprietary ones. And you need to sift between them all to decide what to do on the SDP level
2. When you modify the SDP, it is assumed that the browser needs to interpret your modifications. Since it already created an SDP, it had its own understanding of what you want, but now he needs to interpret it yet again but instead of doing that through an API, it needs to do it via an ugly text blob. And browsers are created by humans, so they might not interpret it the same way you did when you munged it – or different browsers might interpret it differently
3. New browser versions might not be able to interpret what you munged simply because that isn’t part of their main focus. The smaller you are, the more susceptible you will be to practicing SDP munging – what you do there might not be as popular as you though (or not defined as popular by browser vendors) – and it will break in some future version
4. SDP isn’t that fun to modify with JavaScript. So it frustrates developers which ends up leading to more bugs and inconsistencies

What happens if and when it gets prohibited?

When SDP munging gets banned, existing applications that rely on it will break.

They might break completely, but mostly, they’ll break in ways that are less predictable – codecs won’t be configured in the exact way the developer intended, bitrates won’t be controlled properly, etc.

The whole idea behind SDP munging is to get more control over what the browser decides to do by default, so disabling it means losing that control you had.

When is this change expected?

Not soon, if at all.

That said, I wouldn’t recommend ignoring it.

What I’ve understood is that there’s little chatter about this on the standards mailing lists, so this just might die out.

The reason I think it is important is because at the end of the day, munging the SDP leaves you prone to whims of browser vendors as well as leaves you open to this future option of banning SDP munging.

What should you do about it?

First of all – don’t worry. This one will take time. That said, better plan ahead of time and not be surprised in the future. Here’s what I’d do:

1. Refrain from practicing SDP munging as much as possible
2. Since we’re already starting to see some of the ORTC APIs tricking into WebRTC, you should make an active investment now and in the near future to use these APIs whenever you feel the urge to make changes in the SDP (that’s assuming what you need is supported in the API level and not only via the SDP)
3. If you aren’t sure, then check the code you have to see if you are practicing SDP munging, and if you are, make some kind of a plan on how to wean yourself from it

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post What if WebRTC SDP Munging was Prohibited? appeared first on BlogGeek.me.

If the only thing you have is IP calling, then why are you investing in a Slack integration this late in the game?

Looking for gold in Slack by adding WebRTC calls to it?

Slack is a rising star. It has a small and growing set of users, some of which are happy to pay for the service. When it works, it is great. When it doesn’t, well… it then just feels like any other UC or enterprise communication service. I find myself using Slack more and more. Not necessarily because I need to, but rather because I am drawn to it by the teams I collaborate with. I like the experience.

In the last few months it seems that everyone is rushing to Slack, trying to build their own WebRTC integration with it. The latest casualty? LyteSpark.

Browsing Slack’s App Directory, I found the following WebRTC based services under the Communications category:

• Google Hangouts
• Skype
• appear.in
• GoToMeeting free
• Room
• UberConference
• Limnu
• Blue Jeans
• Screenleap
• Yodel
• Videolink2.me
• Quickchat
• KOMASO

There are others, not in the marketplace, and probably a few others in other categories or ones that I just missed.

The problem with many of them is that Slack is actively adding VoIP now – using WebRTC of course.

As I always stated, WebRTC downgrades real time communications from a service to a feature. And now, Slack is adding this feature themselves.

The problem now becomes that these WebRTC services are competing with the built-in feature of Slack – something that will be infinitely easier and simpler to use – especially on mobile, where it is just there. What would be the incentive then to use a Hangouts bot when I can just start the same functionality from Slack without any integration? This is doubly so for free accounts, which are limited to 10 integrations.

The only WebRTC services that can make sense in such a case, are those that have some distinct added value that isn’t available (or easily available through roadmap of Slack). It boils down to two capabilities:

1. Seamless integration with PSTN calling. This is what OttSpott does. I think this is defensible simply because I don’t see Slack going after that market. They will be more inclined to focus on IP based solutions. Just a gut feeling – nothing more
2. Solving a higher level problem than pure voice or video calling. Maybe a widget integration with the customer’s website for click-to-call capabilities, though it can be some other capabilities that focus on a smaller niche or vertical

This Slack-rush of WebRTC services seems a bit unchecked. Basking under the light of WebRTC doesn’t work anymore, so time to move to some other hype-rich territory, and what better place than Slack? Problem is, without a real business problem to solve (conducting a video call over the web isn’t a business problem), Slack won’t be the solution.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post The WebRTC Slack-Rush appeared first on BlogGeek.me.

GPUs is most probably where we’re headed.

A couple of months ago, I was approached by SURF. An Israeli vendor specializing in server media processing. As many of its peers, SURF has been migrating from hardware based DSP systems to software systems in their architecture. As they’ve entered the WebRTC space, they wanted to have a whitepaper on the topic, and I accepted the challenge.

The end result? WebRTC Server Side Media Processing: Simplified

Download the whitepaper

Two things that I wanted to share here:

#1 – WebRTC Server Side Media Processing is real

What made writing this whitepaper so interesting for me was the fact that there really is a transition happening – not to using WebRTC – that already happened as far as I can tell. It is something different. A transition from simple WebRTC services that require a bit of signaling to services that process the media in the backend. This processing can be anything from recording to gatewaying, streaming, interoperating or modifying media in transit. And it seems like many commercial use cases that start simple end up requiring some kind of server side media processing.

In the span of the last two months, I’ve seen quite a few services that ended up building some WebRTC server side media processing for their use case. Maybe it is just related to the research I did around this are for the whitepaper, but I think it is more than that.

#2 – The Future Lies in GPUs

As I was working on the whitepaper, this one got published by Jeff Atwood – it is about AI winning a game of Go. Or more accurately, how GPUs are a part of it:

GPUs are still doubling in performance every few years

The whole piece is really interesting and a great read. It also fits well with my own understanding and knowledge of video compression (=not that much).

Two decades ago, video compression was a game of ASIC – the ugliest piece of technology possible. Hard to design and develop. You wanted to implement a new video codec? Great. Carve a few years for the task and a couple of millions to get there. They are hard to design and hard to program for.

Later it was all DSP. Still hard and ugly, but somewhat cheaper and with some flexibility as to what can get done with them. DSPs is what powers most of our phones when it comes to recording and playing back videos. It works pretty well and made it seem as if the device in our pocket is really powerful – until you try using its CPU like a real PC.

GPUs were always there, but mostly for gaming. They do well with polygons and things related to 2D and 3G graphics, but were never really utilized for video compression. Or at least that’s what I thought. I heard of CUDA in passing. Heard it was hard to program for. That was something like 5 years ago I believe.

Then I read about GPUs being used to break hashes, which was an indication of their use elsewhere. The Jeff Atwood piece indicated that there are other workloads that can benefit from GPUs. Especially ones that can be parallelized, and to some extent, video compression is such a task. It is also where SURF is focusing with its own server media processing, which places them in the future of that field.

GPUs are no longer used only for gaming or in our PCs and laptops – they are also being deployed in the cloud. They assist companies running Audocad in the cloud (heard such a story in the recent WebRTC Global Summit event), so why not use them for video compression when possible?

–

If you are interested in WebRTC and how media processing is finding its way to the server, and how that fits in with words like cloud and GPU, then take a look at this new whitepaper. I hope you’ll enjoy reading it as much as I’ve enjoyed writing it.

Download and read this new WebRTC whitepaper.

The post WebRTC and Server GPUs? A whitepaper appeared first on BlogGeek.me.

Progressing nicely – of course.

Checking the pulse of WebRTC

It’s been 5 years since WebRTC came to our lives. Different people count it from different times. I heard in the last month or two the years 2009, 2010 and 2011 stated as the year of birth of WebRTC. While no one should really care, for me, WebRTC started with Google’s announcement of WebRTC in May 2011. It was the first time Google publicly stated its plans for its GIPS acquisition, and it came out as an open source package that was planned to get integrated into browsers and be called WebRTC. I was a CTO at a business unit licensing VoIP products to developers. The moment I saw it, I knew everything was going to change. It was one of the main reasons I left that job, and got to where I am today, so it certainly changed everything for me.

As we head towards Mat of 2016, it is time to look a bit at the 5 years that passed – or more accurately the 5th year of WebRTC.

One one hand, it seems that nothing changed. A year ago, Chrome and Firefox supported WebRTC. That’s on Windows, Mac OS X, Linux and Android. Today, we’re pretty much in the same position.

On the other hand, adoption of WebRTC is huge and its impact on markets is profound; oh – and both Microsoft and Apple seem to be warming up to the idea of WebRTC – each in his own way.

If you are interested in a good visual, then my WebRTC infographic from December 2015 is what you’re looking for. If it is numbers and trends today, then read on.

951 Vendors and Project – and growing

I’ve been tracking the vendors and projects of WebRTC since 2013, actively looking for them and handpicking relevant projects that are more than 10 lines of code and any vendor I saw. It turned into one of the services I have on offer – access to this actively growing (and changing) dataset of WebRTC vendors.

Earlier this month, the WebRTC dataset had the following interesting numbers:

• 951 vendors and projects that I track
  • There are a few that shutdown throughout the years, but not many
  • There are a few that I know of and don’t make it into the list, because they want to remain private at this point
  • There are data points I’ve stored and haven’t processed yet – many of them additional vendors (got around 80 in my backlog at the moment)
• 2015’s average was 26 vendors added every month
• 2016 shows a slight increase to that average. 3-4 months aren’t enough to make this definitve yet
• For now, there are 41 acquisitions related to WebRTC in one way or another
  • Some of them are less relevant, such as Mitel acquiring Polycom
  • Others are all about WebRTC, such as Talko’s acquisition by Microsoft

What is interesting is that these vendors and projects are always evolving. They aren’t only limited to startups or large enterprises. They aren’t specific to a certain vertical. They cut through whole industries. Just this week a new use cases popped – movers who can give a price quote without being on site. Will it fly? Who knows.

We’ve been witnessing a surge in communication services. We are not limited today by concepts of Telephony or Unified Communications. These became use cases within a larger market.

What is different now is that the new projects and vendors don’t come with VoIP pedigree. They are no longer VoIP people who decided to do something with WebRTC. Most of them are experts in communications – not digital communications, but communications within their own market niche. Check out the interview from last week with Lori Van Deloo of BancSpace – she knows her way in banking.

API Platforms are Maturing

Communication API platforms using WebRTC are maturing. Many of them have the basics covered and are moving further – either vertically or horizontally. Vertically by deepening their support of a specific capability or horizontally by adding more communication means. You can read my WebRTC API report on it. I am in the process of updaing it.

What is interesting is how this space is being threatened from two different domains:

1. Unified Communication platforms turned Enterprise Messaging turned developer ecosystems. Cisco Spark and Unify’s Circuit are such examples. They are an enterprise UC solution that can be used (and is actively being marketed as) a long tail development platform for general communication needs
2. Specialized component vendors who are offering widgetized approach of their service, enabling its integration elsewhere. Gruveo, appear.in and Veeting do it a lot; Drum ShareAnywhere and a lot of others are also examples of it

This is affecting the decision making process of those who need to roll out their own services, making the technology more accessible, but at the same time more complex and confusing when the time comes to pick a vendor to lean on.

Verticals are Fragmenting Further

What does a communication solution in healthcare looks like?

If you ask a Unified Communications vendor, it will be able having a room system everywhere and enabling doctors/nurses/patients communicate.

I had conversations with these types of health related vendors:

• Contact centers for doctor visitations of a healthcare insurer
• IOT measurement device a user takes home, connects to the phone and from there to a doctor
• Online group treatment
• Serving rural areas from an established hospital in developing countries
• Assisting/learning/teaching/participating in remote surgery
• Medical tourism
• Counseling for enterprise employees
• Care for seniors
• Secure messaging for doctors
• Medical clowns
• Fitness related

Each of these is a world unto its own, and to think we’ve looked at them all through the prism of Unified Communications or even the “healthcare vertical”.

WebRTC brought with it the ability to hone in on specific market needs.

–

WebRTC is already ubiquitous. As with any technology, its has its rough edges and challenges.

I’ve dealt with developing VoIP products for the better part of the last two decades – I can tell you hands down that never before did we have the alternatives to do what we can today. If you have VoIP on your mind, then WebRTC should be the first thing to try out as a component in your solution.

The post Where are we with WebRTC? appeared first on BlogGeek.me.

Well… Almost.

For those who haven’t been following the path Skype is taking, here’s a quick recap of the last year or so:

• Lync got “merged” with Skype, rebranding it as Skype for Business – so now all of Microsoft’s voice and video calling services are Skype
• Skype for Web was announced at about the same time
• A Skype SDK was launched
• And now, Skype for Web is running on Microsoft Edge without any plugin installation
• Oh, and they announced bots too

Skype on Edge sans plugins was to be expected

That last bit near the end? Of Skype not needing plugins when executed on Edge? That was rather expected.

Microsoft is hard at work on adding RTC to Edge – be it ORTC or WebRTC – or both.

The main UC and consumer messaging service of Microsoft are based on Skype, so it is only reasonable to assume that Skype would be utilizing Edge capabilities in this are AND that Edge would be accommodating for Skype’s needs.

This accommodation comes by way of the first video codec that Edge supports – H.264UC – Skype’s own proprietary video codec. Edge doesn’t interoperate with any other browser when it comes to video calling due to this decision. In a way, The Edge team sacrificed interoperability for Skype support.

Browser vendors tend to care for themselves first. And then for the rest of the industry:

• Google Chrome does that by having undocumented features for Google Hangouts
• Mozilla Firefox does that by working with Cisco on H.264 & Telefonica on Hello
• Microsoft Edge does that by sacrificing video interoperability for Skype support
• Apple Safari does that… by not doing WebRTC favoring its FaceTime?

Google Hangouts route to plugin-less world

Hangouts today is in the same predicament as Skype in a lot of ways.

1. Its support for the browser of the mothership is native (Chrome-Hangouts; Microsoft-Skype)
2. Both require plugins on browsers other than their own – and will stay that way for the forseable future
3. Both are no consumer/enterprise services, trying to cater both
4. Both aren’t as big or as active as their newer competitors (Facebook, WhatsApp and WeChat to be specific)

Where do they diverge?

No Plugin+SDK=Interesting

Skype has added the SDK bit before Hangouts.

Skype now offers its large user base and infrastructure to 3rd party developers to build their own services. The documentation is quite extensive (too much to go through to get things done if you ask me – especially compared to the WebRTC API platforms) and the intent is clear.

Skype doesn’t have a glorious record with developers. Maybe this time around it will be different.

And it added bots.

They did that ahead of the rumored bot support by Google.

Where’s Hangouts?

Meanwhile, Hangouts is just the same as it were two or three years ago.

The backend probably changed. It now sometimes do P2P calling. And it has a new UI. And the old one. And you can never know which one will pop up for you. Or where to write (or read) that text message.

Something needs to change and improve with Hangouts.

Skype seems to be moving forward at a nice pace. Cisco Spark has its own forward motion.

But Hangouts has stalled – especially considering we’re talking about Google – a company that can move at breakneck speeds when needed.

I wonder what’s ahead of us from both these services.

The post Skype will go the Hangouts Route with WebRTC (or vice versa?) appeared first on BlogGeek.me.

isVisible=false; function show_hide_searchbox(w){ if(isVisible){ document.getElementById('filterBoxSelection').style.display = 'none'; w.innerText='Filter ▼'; }else{ document.getElementById('filterBoxSelection').style.display = 'block'; w.innerText='Filter ▲'; } isVisible=!isVisible; } function checkIfSelected(chk){ if(chk.checked==1) chk.parentNode.className = "selected"; else chk.parentNode.className = "notselected"; getSelectedValues(); } function getSelectedValues(){ var a=document.getElementsByClassName('selected'); var vtVal=[] , ctVal=[] , ftVal=[]; var ct=0,vt=0,ft=0; for (x = 0; x < a.length; ++x) { try{ if(a[x].getElementsByTagName('input')[0].className=='companyType'){ ctVal[ct]= a[x].getElementsByTagName('input')[0].value; ct++; } if(a[x].getElementsByTagName('input')[0].className=='vendorType'){ vtVal[vt]= a[x].getElementsByTagName('input')[0].value; vt++; } if(a[x].getElementsByTagName('input')[0].className=='focusType'){ ftVal[ft]= a[x].getElementsByTagName('input')[0].value; ft++; } }catch(err){ } } search_VType(vtVal); search_CType(ctVal); search_FType(ftVal); } function search_VType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null){ a[x].style.display='block'; } } if(val.length==0){ a[x].style.display='block'; } } } function search_CType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null && a[x].style.display=='block'){ break; } if(i==val.length-1){ a[x].style.display='none'; } } } } function search_FType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null && a[x].style.display=='block'){ break; } if(i==val.length-1){ a[x].style.display='none'; } } } }Check out all webRTC interviews >>

BancSpace: Lori Van Deloo

April 2016

Banking

Vertical

Small

Voice, Video, Data

Banking and WebRTC done right.

[If you are new around here, then you should know I’ve been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]

I had my fair share of demos where a banking or a contact center application felt boring and Spartan. Too many times, the focus is on how to get video to show and when that happens – the developers are so happy they forget about the bigger picture – the service.

When I met Lori Van Deloo, Founder & CEO of BancSpace, I thought I was in for the same kind of an experience. But boy, was I wrong. She started off in the best way possible. She just explained that she worked for many years at VISA and then decided to found BancSpace. This is always a good sign – a founder who comes from the vertical he or she wants to serve instead of a VoIP engineer who decides to fix and disrupt industries.

The rest of the demo was an eye opener on how things could be done in a way that looks so simple but is devilishly complex. I of course wanted an interview, and Lori was kind enough to oblige.

 

What is BancSpace all about?

BancSpace is a WebRTC digital banking communications and collaboration platform that facilitates live access and engagement with qualified specialists, anytime, anywhere.

Prior to founding BancSpace, I spent a number of years working in software, including mobile and most recently, payments.  These and other technologies have become increasingly important in the delivery of financial services for both consumers and businesses.  However, when it comes to critical decisions or complex tasks, many prefer to consult with an expert to get financial advice or to get assistance such as when opening an account or applying for a loan.  The idea behind BancSpace is to allow Financial Services providers to deliver innovative customer experiences that combine both – the best of digital technology and live service expertise.

BancSpace provides a full suite of real-time capabilities to enable advisors/specialists to connect and collaborate with their customers just as if they were meeting face-to-face.  It’s basically video banking + deep, two-way collaboration.  Since the service is cloud-based, both advisors and customers can access the platform from any device (and thanks to WebRTC, no downloads or plugins on either side!)

Having spent more than a decade working closely with large Financial Institutions, we also knew that any service we developed must address industry needs for greater management and controls.  As such, multiple layers of authentication, security and permissions have been built into the BancSpace service platform.  These additional features help support compliance with industry standards to confirm a customer’s identity and help protect the access to and exchange of information during a BancSpace session.

  

Why WebRTC, and why in banking?

Unlike other communications technologies, WebRTC was purpose-built from inception to specifically address security considerations through the framework of the WebRTC technology architecture.  For example, encryption is a mandatory feature of all data and media streams sent over WebRTC.  Features like this are especially important when you are working in highly sensitive, highly regulated environments such as banking and other financial services.

We also chose WebRTC for its ability to deliver on the important benefits of quality and convenience.  The real-time nature results in a high quality voice-video-data exchange, and the convenience of no downloads / no plugins makes for a superior customer experience.

 

Backend. What technologies and architecture are you using there?

We have developed an intricate service platform that integrates a number of different technologies and a proprietary advisor-customer interaction model.  Our developers are strong advocates for node.js.  It is great for use with WebRTC, as well as more broadly to support our full suite of real-time collaboration capabilities.  The underlying service architecture also includes support for managing the controls and permissions that govern the access and use of the service.

 

In your service, you have an interesting co-browsing and collaboration mechanism. Can you elaborate a bit about it?

Yes.  Our two-way collaboration workspace is a core aspect of the BancSpace service.  The workspace allows advisors or specialists to engage and assist their customers to immediately complete important tasks or transactions, all in a secure 1:1 session.

A number of services provide one-way screen sharing tools or applications, but as we looked at the requirements for our customers’ use cases, we needed a solution that went well beyond that.  It called for something that enabled a more intimate, two-way interaction because our goal was to replicate the same high quality, engaging experience that typically has been associated with in-person or in-branch service and then extend it to every customer interaction, on any device.

We also needed something that was more secure in terms of managing session content.  The basic “open desktop” format offered by other services just doesn’t work for many Financial Services transactions.  Think about how many times someone running an online meeting inadvertently shared the wrong file?  Or had a personal email or IM pop up in the middle of a meeting?  BancSpace’s approach allows providers to completely prevent these issues and only allow approved content to be shared in a given session.

 

Where do you see WebRTC going in 2-5 years?

For WebRTC-based vertical applications it is still early days.  Especially for those in highly regulated industries, WebRTC needs to be viewed within the broader technology adoption landscape – many Financial Services providers are still getting comfortable with cloud and SaaS.  Focused pilots and test programs will be important for applications in Financial Services to ensure bank-grade quality before expanding to full, generally available (GA) services.  A real opportunity to accelerate efforts here is for leading Financial Services providers to partner with Fintech-focused start-ups developing WebRTC-based applications and establish a beachhead for the industry.

Getting to an agreed standard with ubiquitous access for all end-customers is also critically important for driving enterprise adoption.  Financial Institutions, and really any large enterprise, need to be able to provide solutions that serve their broader customer base (not just the majority), and do so in a way that maintains a consistent experience for customers across any channel.  It’s also more efficient from a back-office operational perspective.

 

If you had one piece of advice for those thinking of adopting WebRTC, what would it be?

If you are thinking about creating a mobile/web application or service that includes WebRTC, it’s important to understand the problems that your clients are trying to solve.  WebRTC is an enabling technology and we believe a foundational one, but consideration should be given for how to best incorporate it into the design of your service to ensure it delivers the desired functionality and provides a great experience.  Once this is determined, then there is much to be leveraged from the vast resources, libraries and community supporting WebRTC globally.

For BancSpace, we are 100% focused on the end customer experience (CX).  Any WebRTC functionality we include must address a specific need and support the scenarios for which our clients are looking to employ our service. We then spend time on the UX design so that using our service (and WebRTC) is an effortless experience for both advisors and customers.

 

Given the opportunity, what would you change in WebRTC?

Our experience with WebRTC has been very positive thus far, especially when you compare to the early days of video banking.  For years the industry has been experimenting with various instantiations of video banking applications.  WebRTC unlocks the potential to truly bring together technology + live expertise and provide a modern, cost-effective option for Financial Institutions to expand their footprint without the legacy CAPEX and OPEX of a fixed, physical branch network.

So what would I change?  Well, I guess continuing to drive toward a foundational set of standards so that WebRTC can become a ubiquitous enabling technology.

 

What’s next for BancSpace?

Driving the next wave of Digital Banking!  The ability to combine communications and collaboration technologies with live expertise is allowing us to re-imagine the delivery of Financial Services in ways that can have immediate impact on growth.

We are actively engaged with Financial Institutions and other Financial Services providers, and believe there is a real opportunity to reinvent the advisor-customer experience.  WebRTC is central to this proposition and we expect it will play an increasingly important role in the BancSpace technology strategy as we expand our use of it and create new capabilities to support a growing client base.

–

The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.

The post BancSpace and WebRTC: An Interview With Lori Van Deloo appeared first on BlogGeek.me.

We can do better.

In 2012, when I started this blog, I had only 3 WebRTC related posts in mind. One of them was about the room system of the future. While this has never materialized in the 4 years since, things have definitely changed in the video conferencing space.

Let’s see what video conferencing vendors have done about WebRTC so far (vendors are listed in alphabetical order).

Avaya

Avaya’s assets in video conferencing comes from its acquisition of RADVISION.

A quick glance at the current website specs for its video conferencing line of products (mainly SCOPIA) shows a rather sad story. SCOPIA offers the best money can get, assuming we were 4 years after 2012 and WebRTC didn’t exist.

As the website states, you can “Experience crisp, smooth video quality with resolutions up to 1080p/60fps, stellar bandwidth efficiency, and error resiliency with H.265 High Efficiency Video Coding (HEVC) and Scalable Video Coding (SVC).”

Bolded tech words are my own.

Some things to note:

• 1080p is great, and the “de facto” thing these days – if you have the juice and the bandwidth for it. 60fps is more than 30fps, but I wonder if it is worth the additional effort to get there
• H.265 is betting the farm on the wrong codec
• SVC is where we’re headed. Getting one out of 3 main bullet points correct is a good start

Cynicism aside, I have it from good sources that Avaya is working on adding WebRTC support to its gear. Where exactly does it fit in its bigger picture, and why so late is a different story altogether.

What bugs me the most here is that in the last 4 years, any advancement in the SCOPIA video conferencing product line was reliant solely on hardware capabilities. You can’t leapfrog in this way over competitors – especially when something like WebRTC comes into the scene.

It is sad, especially since Avaya does work and promote WebRTC in contact centers already. At least on the press release level.

Cisco

Cisco is a large and confusing company. If you look at its telepresence products, they resemble the ones coming from Avaya. Same highlights about speeds and feeds.

On the other hand, Cisco has thrown its weight behind a new product/service called Cisco Spark.

Cisco Spark is a Slack lookalike with a focus on voice and video communications by connecting to the massive line of products Cisco has in this domain. Cisco Spark uses WebRTC to drive its calling capabilities in browsers. What Spark enables is connectivity from web browsers using WebRTC to Cisco video conferencing products.

Cisco took the approach of using H.264, making it work only on Firefox and in future Chrome versions (unless you run the new Chrome 50 from command line with the necessary parameter to enable H.264).

Cisco has also been heavily investing in acquiring and nurturing its WebRTC chops:

• Tropo acquisition, to get an API and a developer ecosystem for Spark
• Acano acquisition, which fits perfectly well in offering native browser access to its existing infrastructure
• Spark fund, with $150M to entice developers to use its APIs

Cisco has a huge ship to steer away from hardware and it is pouring the money necessary to take it there.

Google Hangouts

WebRTC. Chrome. Hangouts. Google. All connected.

Google invested in WebRTC partly for its Hangouts service.

Today, Hangouts is using WebRTC natively in Chrome and uses a plugin elsewhere – until the specific support it needs is available on other browsers.

Google also introduced its Chromebox, its take on the room system. I am not sure how successful Chromebox is, but is refreshing to see it with all the high end systems out there that don’t know a word in WebRTC. It would have been nicer still if it could use any WebRTC service and not be tied to Hangouts.

The problem with Hangouts is its identity. Is it a consumer product or an enterprise product? This is hurting Hangouts adoption.

Lifesize

Lifesize was a Logitech division. It was focused on selling hardware room systems.

In 2014, Lifesize launched its own cloud service, starting to break from the traditional path of only selling on premise equipment and actually offering a video conferencing service.

In 2015, it introduced its WebRTC support, by enabling browsers to join its service via WebRTC – and connect to any room system while doing so.

2016 started with Lifesize leaving from the Logitech mothership and becoming an independent company.

Microsoft Skype

Skype has done nothing interesting until 2015. At least not when it comes to WebRTC. And then things changed.

Skype for Business, Skype for Web and the Skype SDK were all introduced recently.

Skype for Web started off as a plugin, which now runs natively on Microsoft Edge – the same initial steps Google took with Hangouts.

My own take here:

• Skype is investing in switching its backend and modernize it to fit something like WebRTC
• This process is taking too long, and probably isn’t coordinated properly
• It is coming, and it will give Skype a lot of flexibility in where to go and what to do next

Polycom

Or should I say Mitel?

Polycom added WebRTC support in its launch of RealPresence Web Suite. In traditional enterprise video conferencing fashion, it seems like a gateway that connects the browser to its existing set of products and tools.

At almost the same time, Polycom shed its Israel office, responsible for its MCU. This is telling as to how transformative is WebRTC in this market.

Vidyo

Vidyo had a love-hate relationship with WebRTC throughout the years but has done a lot of work in this space:

• In 2013, it announced collaborating with Google to bring SVC to WebRTC
• In 2014, it joined Google’s Chromebox release with its own VidyoH2O gateway
• In 2015 they launched a WebRTC server enabling application developers to integrate WebRTC calls into the Vidyo infrastructure
• In 2015, the company has also gone through management changes, replacing its CEO Ofer Shapiro (now a vice chairman) with Eran Westman. This brought with it new thinking
• 2016 started with Video launchng their VCaaS and PaaS cloud offerings

2016? Two things already happened this year with WebRTC:

1. VP9 is now in Chrome and Firefox for WebRTC, with plans of adding SVC to it. This is something that Google and Vidyo are working on together
2. Vidyo launched their VCaaS and PaaS cloud offerings

In a way, Vidyo is well positioned with its SVC partnership with Google to offer the best quality service the moment Chrome supports VP9/SVC. They also seem to be the only video conferencing vendor actively working on and with VP9 as well as supporting both VP8 and H.264. Others seem to be happy with H.264/VP8 or running after H.265 at the moment.

The New Entrants

There are also some new entrants into this field. Ones that started at the time WebRTC came to being or later. The ones I am interested in here are those that connect to enterprise video conferencing systems.

These include Unify, Pexip, Videxio and many others.

What defines them is their reliance on the cloud, and in many cases the use of WebRTC.

They also don’t “do” room systems. They are connecting to existing ones from other vendors, focusing on building the backend – and yes – offering software connectivity through browsers, plugins and applications.

My room system dreams

I’ll have to wait for my WebRTC room system for a few more years.

Until then, it is good to see progress.

The post How Video Conferencing Vendors Adapt to WebRTC? appeared first on BlogGeek.me.