For more than 6 years, we have been working on and looking forward to a simpler way to build RTC (Real Time Communications) applications on the web. In order for this technology to truly show its value, the major browser vendors needed to show up.
Mobile, mobile, mobile.Now that Apple has joined the party in earnest, does the technology have the coverage required in order for developers to make good use of WebRTC on mobile devices? Let’s find out.
Until now, in order for WebRTC to work on iOS, we were relegated to wrapping WebRTC code in Objective-C and Swift, in our native iOS apps. Basically, we had to take the Chrome code and build an app that was sent to the app store for approval and wait in line, like all the other chumps (yours truly included). Conversely, on Android we could run much of that same code from our desktop Chrome apps, on the Android device as well, within reason of course.
Now that Safari and Chrome are shipping compatible WebRTC on mobile, we get to reuse the same code, right!? Well, mostly, they are different code bases, after all.
A word about hardware acceleration.If ubiquitous mobile video is to take off, the battery life of the device has to last more than the length of the 10 minute video call (ok, I am exaggerating a bit, but I think you get the point) and the performance needs to be at least adequate enough to distinguish facial features. My bar is set a little higher, baby steps for now.
Without h/w acceleration the CPU is likely working too hard to encode the local video and decode the inbound video + service the other processes required at the same time. That really means there needs to be hardware onboard the device dedicated to video coding. That in turn means H.264, since there are very few vendors that offer VP8 or VP9 h/w acceleration.
Question: Does this mean that mobile apps written with VP8 will not be able to deliver decent mobile video conferencing?
Answer: No, not at all, but they will likely not be as performant as those taking advantage of hardware acceleration.
Suffice to say that SVC (Scalable Video Coding) usage would be another reason why we need h/w acceleration, but that’s for another day.
Who’s using what?The majority of desktop and mobile WebRTC apps written today, are using VP8 for video.
Since Apple and Microsoft both use H.264 and Google uses VP8 and H.264 (recently shipped Open H.264 – on the desktop and mobile). Also, many of the Enterprise RTC developers are already on that H.264 bandwagon.
Question: If Apple and Microsoft devices ship with H.264, what is the case with Google Chrome on desktops and android, are they preferencing VP8?
Answer: Chrome for desktop and android now have H.264 native. Many of the Android devices that ship today all have H.264 hardware acceleration onboard. In order to understand which units have H.264 and hardware acceleration, you can run use the Android APIs to pull a list of available codecs, but in the case of WebRTC, you will only get H.264 in Android WebRTC if there is a h/w encoder on the device.
Is H.264 the answer for WebRTC video?Here is a recent test:
Host 1 – (before joining):
macOS Sierra, Macbook, Safari (Technology Preview 32)
Host 2 (after joining):
Android 7, Samsung 7, Chrome 55
Host 1 (after joining):
According to the Chrome Status page, Chrome for Android should have H.264. So why is the session barfing when trying to set up video? The logs do not lie…
Safari – offer:
a=rtpmap:96 red/90000
a=rtpmap:98 ulpfec/90000
a=rtpmap:99 H264/90000
Chrome on android – answer:
a=rtpmap:96 red/90000
a=rtpmap:98 ulpfec/90000
a=rtpmap:97 rtx/90000
Err, huh? No H.264 in reply?
So, I updated to latest Chrome on android (58) and tried again…
… et voilà!!
Shipping your product with H.264 enabled, means you may potentially need to deal with the MPEG-LA royalty police for H.264 royalties, but there are some grey areas.
In the case of Apple and Microsoft, where H.264 royalties are already being paid for by the parent vendor, the WebRTC developer is riding on the coattails of papa bear, at least in theory.
Cisco’s generous OpenH.264 offer means that those using this binary module, can do so at potentially no cost:
We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms.
Q: If I use the source code in my product, and then distribute that product on my own, will Cisco cover the MPEG LA licensing fees which I’d otherwise have to pay?
A: No. Cisco is only covering the licensing fees for its own binary module, and products or projects that utilize it must download it at the time the product or project is installed on the user’s computer or device. Cisco will not be liable for any licensing fees incurred by other parties.
That seems to mean (I am no lawyer) every developer shipping WebRTC apps supporting Open H.264 binary module, get a free ride. Those using some other binary, or shipping the above source code for that module, could be on the hook for those royalties. That said, since there are royalties being paid by parent vendors where devices are shipping H.264 anyways, developers may not get hassled regardless.
Summary:So what did we learn here?
The W3C and IETF are also closing in on shipping WebRTC as a web standard, here’s a great update from Google on that as well. Latest W3C WebRTC editor’s draft, latest charter.
As a side note, it would be interesting to see something like this open sourced; VP8 / H.264 conversion without transcoding, if only to service the existing desktop apps currently running VP8 <-> mobile H.264. It would likely overwhelm the mobile device, but it would be cool if it worked!
Disclaimer: The views expressed by me are mine alone and do not necessarily represent the views or opinions of my employer.
Last week WWDC was a happy occasion for those who deal with WebRTC. For the first time, we got the official word – and code – of WebRTC on Apple devices – WebRTC iOS and WebRTC Safari support is finally here.
I spent the time since then talking to a couple of developers and managers who either tinkered with Safari 11 already or have to make plans in their products for this development.
I came out a bit undecided about this whole thing. Here are where things stand.
Apple’s CoverageThe WebKit site has its own announcement – as close as we’ll ever get to an official announcement from Apple with any detail it seems.
What I find interesting with this one (go read it – I’ll wait here):
First things first, here are some posts that were published already about Apple’s release of WebRTC Safari (in alphabetical order):
I’ve ignored a few generic posts that just indicated WebRTC is out there.
Most relevant Twitter thread on this?
Testing out Safari 11's #WebRTC support on #macOS High Sierra. pic.twitter.com/zSpTfMlRj5
— Saúl Ibarra Corretgé (@saghul) June 6, 2017
Who’s Missing?Well… the general media.
I haven’t really seen the keynote. I find the Apple keynotes irrelevant to my needs, so prefer not to waste my time on them. My understanding is that WebRTC took place there as a word in a slide. And that’s HUGE! Especially considering the fact that none of the general technology media outlets cared to mention it in any way.
Not even the general developers media.
What was mentioned instead were things like the iOS file manager. That seems a lot more transformative.
This isn’t a rant about general media and how they miss WebRTC. It is a rant about how WebRTC as a technology has not caught the attention at all, outside a little circle of people.
Is it because communications is no longer interesting?
At a large developers event here in Israel on that same week, there were 6 different tracks: Architecture, Full stack, Philosophy, Big Data, IOT, Security. No comms.
Not sure what the answer…
On one hand, WebRTC is transformative and important. On the other hand, it is mostly ignored. #iOS
Click To Tweet
WebRTC Safari Support
So what did get included in the WebRTC Safari implementation by Apple?
This is mostly expected. See below why.
WebKit, Blink and WebRTCA long time ago, in a galaxy far far away. There was a browser rendering engine called WebKit. Everyone used WebKit. Especially Google and Apple. Google used WebKit for Chrome. And Apple used WebKit for Safari.
And then one day, in the middle of the development of WebRTC, Google decided enough is enough. They forked WebKit, renamed it to Blink, removed all excess code baggage and never looked back.
Apple never did care about WebRTC. At least not enough to make this thing happen until last week. I hope this is a move forward and a change of pace in Apple’s adoption of WebRTC.
Here’s what I think Apple did:
When it comes to WebRTC, the question is one of browser interoperability. There aren’t many browser vendors (I am counting four major ones).
The basics seem to work fine. If you run a simple peer-to-peer call between any of the 4 browsers, you’ll get a call going. Voice and video. The lowest common denominator for that seems to be Opus+H.264 due to Safari. Otherwise, Opus+VP8 would also be a possibility.
The challenge starts when what you’re trying to do is multiparty. While H.264 is supported by all browsers, the ability to use simulcast with H.264 isn’t. At the moment, Chrome doesn’t support simulcast with H.264. The current market perception is that multiparty video without simulcast is meh.
Doing group calling?
Now it is going to become a matter of who blinks first: Google by adding H.264 simulcasting to Chrome; or Apple by adding VP8 to Safari.
The Next Video Codec WarWhich leads us to the next frontier in the video codec wars.
If you came in late to the game, then know that we had over 3 years of continuous bickering regarding the mandatory video codec in WebRTC. Here’s the last I wrote about the codec wars when the Alliance of Open Media formed some two years ago.
At the time, both VP8 and H.264 were defined as mandatory video codecs in WebRTC. The trajectory was also quite obvious:
After H.264 and VP8, there was going to be a shift towards VP9 and then a leap towards AV1 – the new video codec currently being defined by the Alliance of Open Media.
Who isn’t in the alliance? Apple.
And it seems that Apple decided to bank on HEVC (H.265) – the successor of H.264. This is true for both iOS and macOS. This is done through hardware acceleration for both the encoder and the decoder, with the purpose of reducing storage requirements for video files and reducing bandwidth requirements for streaming.
But it goes to show where Apple will be going with WebRTC next. They will be adding HEVC support to it, ignoring VP9 altogether.
There’s a hefty cost in taking that route:
Which is why I think Apple is taking this route in the first place.
Apple has its own patents in HEVC, and is part of the MPEG-LA patent pool.
And it knows royalties is going to be complex and expensive. Which makes this a barrier for other vendors. Especially those who aren’t as vertically integrated – who needs to pay royalties here? The chipset vendor? The OS vendor? The handset manufacturer?
By embedding HEVC in iOS 11 and macOS High Sierra, Apple is doing what it does best – differentiates itself from anyone else based on quality:
Google, and Android by extension, won’t be adding HEVC. Google has taken the VP9 route. But in VP9 most solutions are software based – especially for the encoder. Which means that using VP9 eats up CPU. Results look just as good as HEVC, but the cost is higher on CPU and memory needs. Which means an “inferior” solution.
Which is exactly what Apple wants and needs. It just doesn’t care if interoperability with other devices requires lowering quality as the perception of who’s at fault will fall flat on Android and Google and not on Apple.
So…
Don’t expect to see VP9 or AV1 anytime soon in Apple’s roadmap. Not for WebRTC and not for anything else.
Dan Rayburn covers the streaming side (non-WebRTC) of this HEVC decision quite nicely on StreamingMedia.
Oh, and while at it, Jeremy Noring wrote a well thought rant about this lack of support for VP8 and VP9. His suggestion? Go vote for bug #173141 on WebKit. It probably won’t help, but it will make you feel a bit better
The only way I see this being resolved? If Google retracts their support for H.264 and just blatantly removes it from Chrome until Apple adds VP8 to Safari. I’ll be happy to see this happening.
FaceTime , Multiparty and WebRTCApple has FaceTime.
And FaceTime probably doesn’t use WebRTC. I am not sure if it ever will.
When Google came out with WebRTC, they had the Hangouts (now Meet) team about a year behind in its adoption of WebRTC as their underlying technology – but the intent and later execution was there.
When Microsoft came out with WebRTC, Skype didn’t support WebRTC. But they did launch Skype for Linux which is built somewhat on top of WebRTC, and Skype for Web which is taking the same route. Call it ORTC instead of WebRTC – they are one and the same as they are set to merge anyway.
Apple? Will they place FaceTime on top of WebRTC? I see no incentive there whatsoever.
–
Can Cisco change this? Rowan Trollope broke the news titled “Cisco and Apple Announce New Features” that WebEx and Cisco Spark now work on Safari – no download needed. I’ll translate it for you by adding the missing keyword here – WebRTC. Cisco is using WebRTC to do that. And since their stack is built atop H.264, they got that working on Safari.
Cisco and Apple here is interesting. While Cisco mentions this in the headline as if these new features were done jointly, Apple isn’t really acknowledging it. There’s no quote from an Apple representative, and at the same time, Cisco isn’t mentioned in the WebKit announcement – TokBox and BlueJeans are.
One wonders.
–
Back to FaceTime. Which is a 1:1 video chat service.
And the fact that many look into group video chat and other multiparty video configurations.
Will Apple care enough to support it well in WebRTC? Will it move from Plan B to Unified Plan? Will it care about simulcast? Will it invest in SVC? Will it listen and work with Cisco on its multiparty needs for the benefit of us all?
Older DevicesApple will not be upgrading iPhone 5 devices to iOS 11. That’s a 5 years old device.
In many requirement documents I see a request to support iPhone 4.
Will this bump the general audience out there to focus on iPhone 6 and upwards, seeing what Apple is doing as well? Will this mean vendors will need to port WebRTC on their own to support older devices?
Time will tell, but I think that switching to iPhone 6 and above and focusing there makes sense.
Chrome/Firefox support on iOSHere’s a question for you.
If you use Chrome or Firefox on iOS. And open a URL to a site using WebRTC. Will that work?
Here’s the catch.
The reason there was no real browser for iOS that supported iOS until today? Apple mandates WebKit as the rendering engine on any browser app that comes to its AppStore.
Now that WebKit is getting official WebRTC support – will Chrome and Firefox add WebRTC support to their iOS browsers?
And if they do – you’ll be getting the Apple restrictions. I can just see the WebRTC developer teams at Google and Mozilla cringing at this thought.
This can get really interesting if and when Apple decides to add HEVC support to WebRTC in its WebKit implementation of iOS. You’ll get Chrome on iOS with H.264 and HEVC and Chrome everywhere else with H.264, VP8 and VP9.
Fun times.
What Should Developers Do?Here’s what you’ve been waiting for. The question I’ve been asked multiple times already:
Do I need to build an app? Should I wait?
The suggest at the moment is wait. Question is for what and until when exactly.
If you are looking for a closed app and planning on developing native, then go with whatever worked for you until today. This news item just isn’t for you.
If you are looking for browser support on iOS, then go with Safari and plan on enabling H.264 video codec in your service. Don’t wait up for VP8.
If you want something that will be cross platform app development using HTML5, then wait. Webview WebRTC support in iOS is still an unknown. If it gets there in the coming months then waiting a few more minutes probably won’t make a real difference for you anyway.
My Updated Cheat SheetAs it is, this change with Safari, iOS and macOS required some necessary updates in my resources.
First to update is the WebRTC Device Cheat sheet. You can find the updated one in the same download page.
One last thing –
Join my and Philipp Hancke for Virtual CoffeeI planned for a different Virtual Coffee session this month. One about developer tools. It got bumped into July.
The one in June will cover the iOS announcement and its ramifications. My guest this time will be Philipp Hancke.
The session takes place on Monday, June 19 at 15:30 EDT.
It is free to join, but will not be available later as a recording (unless you are a customer).
The post WebRTC iOS 11 Support. Are We There Yet? appeared first on BlogGeek.me.
Update:
Looks like VP8 is not there after all, bummer. More political jostling afoot, which sucks for the development community.
—
This is a big deal, to have Apple / Safari onboard is really the final major obstacle in the adoption of this awesome standard.
More info (thanks Marc Abrams !!)…
Based on the beta for macOS High Sierra – that was made available yesterday…
– https://cl.ly/3q0p1O3…
– Test samples: webrtc.github.io/samples/ (It passed most of the tests)
– Video codec support is VP8 and H.264 (I have not seen a test that shows H.265 or HEVC but I know it’s there)
– Audio codec support is Opus, ISAC16, G.722 and PCMU
– Basic datachannel support is there but none of the tests seem to work
AWESOME!!! This took a bit longer that many of us were expecting, but hey better late than never!
And while at it – don’t mix signaling with NAT traversal.
Somehow, many people are asking these question in different phrasing, taking different angles and approaches to it. The thing is, if you want to build a robust production worthy service using WebRTC, you need to split these three entities.
If you haven’t already, then I suggest you check out my free 3-part video mini course on WebRTC servers.Now, let’s dive into the details a bit –
Signaling ServersSignaling servers is something we all have in our WebRTC products.
Why?
Because without them there’s no call. At all. Not even a Hello World example.
It is that simple.
You can co-locate the signaling server with your application server.
Here are a few things that you probably surmised about these servers already:
Did I mention signaling servers are written in higher level languages? Java, Node.js, Rails, Python, PHP (god forbid), …
NAT Traversal ServersSTUN and TURN is what I mean here.
And yes, we usually cram STUN along with TURN. TURN is the resource hog out of the two, but STUN can be attached to the same server just because they both have the same general purpose in life (to get the media flowing properly).
This is why I will ignore STUN here and focus on TURN.
Sometimes, people forget to TURN. They do so because WebRTC works great between two browser tabs or two people in the same office without the need for TURN, and putting Google’s STUN server URL is just so simple to do… that this is how they “ship” the product. Until all hell breaks loose.
TURN ends up relaying media between session participants. It does that when the participants can’t reach each other directly for one reason or another. This kind of a relay mechanism dictates two things:
While you might not need many TURN servers, you probably want one at each availability zone of the cloud provider you are using.
Oh – and most NAT traversal servers I know are written in C/C++.
Media ServersMedia Servers are optional. So much so that they aren’t really a part of the specification – they’re just something you’d add in order to support certain functions. Group calls and recording are good examples of features that almost always translate into needing media servers.
The problem is that media servers are resource hogs compared to any of the other servers you’ll be needing with WebRTC.
This means that they end up scaling quite differently – a lot faster to be exact. And when they fail or crash (which happens), you still want to be able to reconnect the session nicely in front of the customer.
But the main thing is that it has different specs than the other servers here.
Which is why in most cases, media servers are placed in “isolation”.
There’s a point in placing media servers co-located with TURN servers – they scale somewhat together when TURN is needed. But I am not in favor of this approach most times, because TURN is a lot more Internet facing than the media server. And while I haven’t seen any publicity around hackers attacking media servers, it is probably only a matter of time.
And guess what? Media Servers? They are usually implemented in C/C++. They say it’s for speed.
Why Split them up?Because they are different.
They serve different purposes.
And most likely, they need to be located in different parts of your deployment.
So just don’t. Place them in separate machines. Or VMs. Or Docker. Or whatever. Just have them logically separated and be prepared to separate them physically when the need arise.
If you want to understand more about WebRTC servers, then try out my free WebRTC server side mini course. You won’t regret it.The post With WebRTC, Don’t Never Ever Mix Media and Signaling appeared first on BlogGeek.me.
tested with VCSA 6.1 and vSphere replication 6.1.1. OVF Tool 4.2.0 is installed on a Debian Jessy machine.
ovftool --acceptAllEulas -ds=datastore1 \ -n=<VMname> --ipAllocationPolicy=fixedPolicy \ --prop:password='*******' \ --prop:ntpserver=******* \ --vService:installation=com.vmware.vim.vsm:extension_vservice \ vSphere_Replication_OVF10.ovf vi://vcenter01.domain.com/DC1/host/Cluster1/
The NanoPi NEO2 board by FriendlyElec has several options for an enclosure in their webshop. The 3D-printed plastic enclosure is of too poor quality, and it doesn’t fixate the heatsink properly on the CPU.
The acrylic case does not include washers, which makes the whole construct too fragile, as the screws can easily damage the plastic. Also the M2.5 screws for fixing the heatsink are too short.
So, I added the following components to the design:
Also the following parts came with the acrylic case:
As a result, we get a sturdy case that is able to sustain some rough handling, like carrying it in a toolbox among other hardware.
(scratches on my phone camera made the pictures a bit too soft)
Twilio’s Jeff Lawson had a really interesting keynote at their Signal event. I think Twilio is trying to redefine what CPaaS is. If this works for them, it will make it doubly hard for their competitors.
This is going to be long, as the keynote was long and packed full with information and details that pave the road to what CPaaS is going to be in 2020.
I suggest you watch this keynote yourself –
What I loved the most? The beginning, where Jeff refers to code as making art. I have to agree. In my developer days, that was the feeling. Coding was like building with lego bricks without the instructions or sitting down to paint on T-shirts (yes – I did that in my youth). When a CEO of a company talks about coding as art and you see he truly believes it – you know that what that company is doing must be… art.
Before we BeginOne term you didn’t hear at the keynote:
CPaaS
One term that was there every other slide:
This was about developers, who is the buyer and how software APIs are everywhere.
It was also about how CPaaS is changing and Twilio is now much bigger than that – in the traditional sense of what CPaaS means.
It wasn’t said out loud, but the low level APIs that everyone are haggling about – SMS and voice – are nice, but not where the future lies.
Twilio by the NumbersThe numbers game was reserved for the first 13 minutes of the keynote, where Jeff asserted Twilio’s distinct leadership in this market:
More about the two last bullets later.
Here’s what Twilio deployed in the past year:
To me, this is becoming hard to follow and grasp, especially when I need to look at other vendors as well.
If you look at it, you’ll see that Twilio has been working hard in multiple vectors. The main ones are Enterprise, IP communications and “legacy” telephony.
The main messages?
All this boils down to stating that a competitive advantage can be best achieved on top of Twilio.
Twilio’s New Layering ModelIf you’ve been watching this space, you might have noticed that I tend to use this model to explain CPaaS feature sets:
And this is how Jeff explained it on stage in Twilio’s Signal event 2016:
Building blocks. Unrelated. Could have been placed horizontally one next to the other to get the same concept. But piling them on top of each other is great – it shows there’s lots and lots of services and features to use.
2017 brings with it a change in the paradigm and a new layers model that Jeff explained, and was later expanded with more details:
The funny thing is that this reminded me of how we explained the portfolio and API layers in our VoIP products at RADVISION more than 10 years ago. It is great to see how this translates well when shifting from on premise APIs to cloud APIs. But I digress.
Back to the layering model.
The Super Network wasn’t given much thought in this time around. There were announcements and improvements in this area, but these are a given by now. For those who wish to outmaneuver Twilio by offering a better network – that’s going to be tough without the layers above it.
Then there’s the Programmable Communications Cloud, which is where most of the CPaaS vendors are. This is what I drawn as my own perspective of CPaaS services. The names have changed a bit for the Twilio’s services – we’ve got Programmable Chat now instead of IP Messaging. SMS has 3 separate building blocks here instead of one, and the baseline one is called Programmable SMS – keeping the lower level Communications APIs with a nice naming convention of Programmable X.
The interesting part of this story comes in the Engagement Cloud. Jeff made a point of explaining the three aspects of it: Systems, Departments and Individuals. And the thing about the Engagement Cloud is that services there are actually best practices – they aren’t “functional” in their nature. So Twilio are referring to the APIs in this layer as Declarative APIs.
The Engagement CloudThe main difference between what’s in the Engagement Cloud and the Programmable Communications Cloud? In the Programmable Communications Cloud you know as a developer what will happen – you ask to send an SMS and the SMS is sent. With the Engagement Cloud, you ask for a message to reach someone – and you don’t really care how it is done – just that it will be done in any channel that fits best.
No Channel To Rule Them AllWhat is that “any channel that fits best”?
That’s based on what Twilio decides in the modules they offer in the Engagement Cloud, and it is where the words “best practices” were used during the event.
Best practices are powerful. As a supplier, they show you know the business of your customer to a point where you can assist him more than just by giving him the thing that he think he needs. It places you often as a trusted advisor, or one to go to in order to decide what it is you are going to do. After all – you own the best practices, so why not follow them?
It is also where the most value is to be made moving forward.
SMS is probably still kind when it comes to revenue in CPaaS. Not only for Twilio, but for all players in the market. And while this is nice and true, it is also a real threat to them all:
Yes. SMS is growing in use.
Yes. The stupid term A2P (Application 2 Person) is growing rapidly and it is done using SMS.
Yes. People prefer that over installing apps, receiving emails and getting push notifications.
Yes. People do read SMS messages. But I am not sure if they trust them.
Here’s a quick story for you.
Airbnb.
I use them once in awhile. I was just planning a trip with the family for July. Found the dates. Booked the flights. Found an Airbnb to stay at. Reserved a place – and was asked if I am cool with push notifications. I clicked yes. And here’s what I got the next moment on my phone:
Businesses might be recommended to use SMS to reach their customers, but the prices of SMS urges businesses to seek other, cheaper channels of communications at the same time.
There is no money to be had in Communications APIs in the long term.
Click To Tweet
There is already a price war at this level. Vendors trying to be “cheaper than X”. Developers complaining about the high prices of CPaaS, not understanding the real costs of developing and maintaining such systems.
What’s in Twilio’s Engagement CloudWhich is where the Engagement Cloud comes – or more accurately – the best practices and smarts on top of just calling communications APIs.
Twilio are now offering 4 APIs in that domain:
The interesting bit here is that these all started as functional building blocks. But now the stories behind them are all about multi-channel.
SMS is great, but it isn’t the answer.
IP messaging is great, but it isn’t the answer.
Facebook messenger with its billion+ users is great, but it isn’t the answer.
XKCD says it best:
With such a model in which we live in, programmable communications need to be able to keep track of the best means to reach a person. And so Twilio’s Engagement Cloud is about becoming Omnichannel (=everywhere) with the smarts needed to pick and choose the best channel per interaction.
Are we there yet with the current Twilio offering? I don’t know. But the positioning, intent, roadmap and vision is crystal clear. And with Twilio’s current speed of execution, it is going to happen sooner rather than later.
Vendor Lock-inThe great thing about this layer of Engagement Cloud for Twilio is that it is going to be hard to replace once you start using it.
How hard is it to replace an API that sends out an SMS to a phone number with another API that does the same? Not much.
But how hard is it to replace best practices wrapped inside an API that decides what to do on its own based on context? Harder. And getting even more so as time goes by and that piece of module gets smarter.
Twilio gets a better handle on its customers with the Engagement Cloud. It makes it a lot harder for developers to go for a multi-vendors strategy where they use SMS from the CPaaS vendor whose price is the lowest.
Developer’s BenefitsWhy would developers use these Engagement Cloud modules from Twilio?
Because they save them a ton of time and even a lot more in headaches.
Today, there are 3 huge benefits for developers:
These areas are usually those that developers usually don’t like to deal with. That third one especially is a real pain – after you did it for 2 vendors/channels – connected it to SMS and maybe Facebook Messenger, it feels boring to add the next channel. But now you don’t have to anymore. And don’t you get me started with how the APIs there deprecated and changed through time.
Machine Learning and its CPaaS RoleTwilio talked about Machine Learning in two new APIs that it is introducing: Speech Recognition and Understand
The Speech Recognition one is a bit less interesting. It is done in partnership with Google, using Google’s engine for it. The smarts on Twilio’s side here is the integration and how they are stitching these capabilities of text to speech throughout their line of products.
Here what Twilio is doing is acting in the most Twilio-like approach – instead of developing its own speech recognition tech, or using a 3rd party that gets installed on premise, it decided to partner with Google and user their cloud based speech recognition technology. And then making it easier for developers to consume as part of the bigger Twilio offering.
The real story lies elsewhere though – in Twilio Understand.
While Speech Recognition is a functional piece where you feed the machine with voice and get text, Understand is about modeling your use case and then having the machine parse text based on that model.
It is also where Twilio seems to have gone it alone (or embedded a third party internally), building its real first customer-facing Machine Learning based product.
In the past few years we’ve seen huge growth in this space. It started with Big Data, turned Analytics, turned Real Time Analytics, turned Decision Engines, turned Machine Learning.
Companies use this type of capabilities in many ways. Mostly internally, where Twilio probably had been doing that already. But embedding machine learning and big data, making products smarter is where we’re headed. And for me, this is the first instance I’ve seen by a CPaaS vendor taking this route.
It is still a small step, as Understand is another piece of API – a module – that you can use. And just like many of Twilio’s other APIs, you can use it as a building block integrated with its other building blocks. It is a move in the right direction to evolving into something much bigger.
LinkedIn shows that Twilio has several data scientists (the man power you need for such tasks), though none of them was “kind enough” to offer details of his role or doings at Twilio
Moving forward, I’d expect Twilio to hire several more people in that domain, beefing up its chops and starting to offer these capabilities elsewhere.
The only competitor at the moment who is seeing that is Cisco Spark – with their recent acquisition of MindMeld.
The great thing about machine learning? People feel and assume that it is super hard. Which means it is worth paying for.
The EnterpriseHere’s where enterprises find a home at Twilio’s Signal 2017 keynote. Best to just show it in slides:
Twilio’s API calls success rate. This goes on top of its 99.999% API availability and this is where Jeff wants you to focus – not on getting an API returning an error (would would still fall under availability) but rather on how many successful results you get from the APIs.
Since Twilio launched, none of its APIs was ever deprecated or killed (haven’t checked it myself but this is what Jeff wants you to remember).
Twilio has been working hard on reaching out to enterprises. It introduced an Enterprise plan last year. Implemented ISO 2700. Added Public Key Validation. Introduced support for Enterprise SSO.
All these are great, but what I think resonates here the most are the above two items.
99.999% Success RateEnterprises LOVE this.
SLAs. Guarantees. All the rage.
Twilio is operating at 99.999% uptime and is happy to offer a 99.99% guarantee in its enterprise SLA:
For an enterprise to go for Twilio requires two leaps of faith:
When you pick Twilio, who’s giving you any guarantees?
Well… Twilio does. At 99.99% while maintaining 99.999% across all of its services to all of its customers.
That’s a powerful message. Especially if you couple it with 30,000 deployments a year.
0 APIs KilledThis one is REALLY interesting.
In the world of APIs where everything is in the cloud with a single copy running (it isn’t, but bear with me a second), having someone say that they offer backward compatibility to all of their APIs is huge.
The number of changes you usually need to follow with APIs on the internet is huge. If you have a product using third party APIs, then every year or two, you need to make some changes to have it continue to work properly – because the APIs you use change.
0 APIs kills means that if an enterprise writes their code today for a project they have, it won’t need to worry about changes to it due to Twilio. Now, in many cases, enterprises develop a project, launch it and then are happy to continue with it as is without further investment (or budget). Which means that this kind of a soft guarantee is important.
How does Twilio do it?
They launch products in beta and run the beta for long periods of time. During that time, they get developers to use and tinker with the APIs, collect feedback and when they feel ready, they officially launch it – at which point the API is deemed stable.
It works well because Twilio has lots and lots of customers, some willing to jump on new offerings and take the risk of having things break a bit during those beta periods.
The end result? 0 APIs killed.
Will it Blend?I believe it will.
Twilio has introduced a new paradigm for they way it is layering its product offerings.
In the process, it repositioned all of its higher level APIs as the Engagement Cloud. It stitched these APIs to use its lower Programmable Communications APIs, adding business logic and best practices. And it is now looking into machine learning as well.
It is a powerful package with nothing comparable on the market.
Twilio are the best of suite approach of CPaaS – offering the largest breadth of support across this space. And it is making sure to offer powerful building blocks to make developers think twice before going for an alternative.
Twilio isn’t for everyone. And other CPaaS vendors do have their place. But increasingly, these places become niches.
Is there more?Yes.
This analysis is long, but by no means full.
There were a lot of other aspects of the announcements and Twilio’s moves that require more thought and details. The pricing model on group Programmable Video is one of them. Third Party Add Ons in certain domains (especially for analytics) is another. Or Twilio heading into the UI layer. And then there’s serverless via Twilio Functions. This isn’t even an exhaustive list…
I won’t be going into these here, but these are things that I am actively looking at.
Contact me if you are interested in understanding more about this space.
Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.
The post Is Twilio Redefining CPaaS? appeared first on BlogGeek.me.
WebRTC for Business People – The 2017 Edition
The revamped WebRTC for Business People report is now published.
I’ve been reviewing the stats of the content here lately, and noticed that people still find their way and download my WebRTC for Business People report.
My only problem with it is that it was already old – and showing it: There’s no serious mention of the advances made by Microsoft Edge towards WebRTC support, nothing about the difficulty of finding experienced WebRTC developers.
But most of all – the use cases it mentioned. Some of them were companies that got acquired. Others were shutdown. Some stagnated in place, or are now on life support.
That’s not a good way to introduce someone to the topic of WebRTC.
So a rewrite was in order here, which brought me to work with a few sponsors:
They were kind enough to make the investment needed for me to put the time and effort into it.
WebRTC for Business People – what’s in the 2017 edition?Well…
First off – the report is still free. You can download it, print it, read it online – practically do whatever you want with it.
I’ve refreshed the visuals and updated the analysis part with data from 2015 until 2017 (the time that have passed since the last update to the report). Did you know that WebRTC is still growing linearly in all relevant parameters that you can check?
No hype here. Just solid, steady growth. The minor change in github projects trajectory? That started when Google moved their WebRTC samples and demos from Google code to github.
I wonder if this will change when Apple adds WebRTC to Safari and iOS.
I removed all the nonsense in the report about SIP and H.323. These protocols still exist, but more often than not, people don’t look at them and compare them with WebRTC – because WebRTC has gone way beyond these signaling protocols.
Oh – yes – and I completely rewritten all the vendor use cases and the segments I look at in this report. Here’s the new set of vendors in the report:
If you are interested in WebRTC, the ecosystem around it and understand how companies are using it today – in the real life – making real commercial use of it – then check out this report.
Download the report
The post WebRTC for Business People – The 2017 Edition appeared first on BlogGeek.me.
PC Engines GmbH has recently released a new board, APU3. The difference from APU2 is that two mPCIe slots are suitable for 3G or LTE modems, whereas APU2 had only one such slot. This article explains how to utilize two HUAWEI ME909 LTE modems, and it’s applicable to other modems too.
One of the LTE modems has to occupy the slot which is otherwise usable for mSATA storage. So, the board has to use the SD card for booting, and Voyage Linux is designed for such setup. The scripts in this article are tested against Voyage Linux version: 0.11.0 (Build Date 20170122).
As with APU2, the Linux kernel assigns ttyUSB port numbers randomly, so two ME909 modems produce 10 ttyUSB devices with random numbers which change after a reboot.
The modems have identical serial numbers “0123456789ABCDEF”, and the only thing that allows distinguishing them reliably is the PCI slot number of the corresponding USB controller.
Luckily, APU3 board slots designed for LTE modems, J14 (mSATA/mPCIe 3), and J15 (mPCIE 2), are attached to different USB controllers. The third slot, J16 (mPCIE 1), shares the same USB controller with J15.
USB EHCI Controller at PCI device 00:12.0 is attached to J14, and the controller at 00:13.0 is attached to J15 and J16.
So, the udev rules require a small Shell script that translates DEVPATH variable into the PCI slot and function number, and the resulting string will persistently distinguish the devices attached to USB interfaces in J14 and J15:
cat >/etc/udev/devpath_to_pcislot <<'EOT' #!/bin/sh echo ${DEVPATH} | sed -r \ -e 's,^\/[^\/]+\/[^\/]+\/[0-9af]{4}:[0-9af]{2}:,,' \ -e 's,\/.+,,' -e 's,\.,,g' EOT cat >/etc/udev/rules.d/99-wwan.rules <<'EOT' SUBSYSTEM=="tty", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15c1", PROGRAM="/etc/udev/devpath_to_pcislot" SYMLINK+="ttyWWAN%c{1}_%E{ID_USB_INTERFACE_NUM}" SUBSYSTEM=="net", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15c1", PROGRAM="/etc/udev/devpath_to_pcislot" NAME="lte%c{1}" EOTAfter rebooting, you can see “lte120” and “lte130” network interfaces, and devices suitable for configuring modems: “/dev/ttyWWAN120_02” and “/dev/ttyWWAN130_02”. There are few other TTY interfaces for various purposes, as explained in HUAWEI documentation.
Time to start another ongoing project. This time – my Monthly Virtual Coffee sessions about WebRTC, CPaaS, APIs and comms in general.
Some time in 2015-2016, I decided to host Virtual Coffee sessions. Once a month, I’d pick a subject, create a presentation and host a meeting with my customers. All of them. It was open for questions and it was fun. It stopped because… I don’t know. It just did.
Ever since then, I wanted to do something similar. I found I like talking and interacting with people, and I want to do it more.
Which is why I am now announcing the new Virtual Coffee with Tsahi.
Here’s how it will go down:I won’t be using this blog to publish future sessions – sorry.
The sessions will be announced through Crowdcast (the service I started using for such events lately), so follow me there. And through my newsletter, so if you’re not subscribed – do it now.
What topics will I cover?I really don’t know…
If you want something specific – drop me a line.
Our 1st Virtual Coffee togetherThe first topic I want to tackle?
CPaaS, WebRTC, Differentiation and M&AWhen? May 23 @ 15:30 EDT
There are over 20 different CPaaS vendors out there, and that number is growing and shrinking at the same time:
I want to take the time to review some of this M&A activities, as well as show how different vendors are trying to differentiate themselves from the rest of the crowd.
Join me for this Virtual Coffee with Tsahi
Oh – if you you have questions for this already – just ask them on Crowdcast once you register.
See you there!
The post Announcing my Virtual Coffee sessions appeared first on BlogGeek.me.
WebRTC establishes peer-to-peer connections between web browsers. To do that, it uses a set of techniques known as Interactive Connectivity Establishment or ICE. ICE allows clients behind certain types of routers that perform Network Address Translation, or NAT,to establish direct connections. (See the WebRTC glossary entry for a good introduction.) One of the first problems is for […]
The post Am I behind a Symmetric NAT? appeared first on webrtcHacks.
What is WebRTC and What is it Good For? This 7-minute video provides a quick introduction to WebRTC and demonstrates why it is growing in importance and popularity.
Covered in this video:
WebRTC is an HTML5 specification that you can use to add real time media communications directly between browser and devices.
Simply put:
WebRTC enables for voices and video communication to work inside web pages.
And you can do that without the need of any prerequisite of plugins to be installed in the browser.
WebRTC was announced in 2011 and since then it has steadily grown in popularity and adoption.
By 2016 there has been an estimate from 2 billion browsers installed that are enabled to work with WebRTC. From traffic perspective, WebRTC has seen an estimate of over a billion minutes and 500 terabytes of data transmitted every week from browser communications alone. Today, WebRTC is widely popular for video calling but it is capable of so much more.
A few things worth mentioning:
It is important to understand from where we are coming from: If you wanted to build anything that allowed for voice or video calling a few years ago, you were most probably used C/C++ for that. This means long development cycles and higher development costs.
WebRTC changes all that: it takes the need for C/C++ and replace it with a Javascript API.
WebRTC comes with a Javascript API layer on the top that you can use inside the browser. This makes it far easier to develop and integrate real time communications anywhere. Internally, WebRTC is still mostly implemented using C/C++, but most developers that use WebRTC won’t need to dig deep into these layers in order to develop their applications.
AvailabilityWebRTC today is available in most modern browsers. Chrome, Firefox and Microsoft Edge support it already, while Apple is rumored to be in the process of adding WebRTC to Safari.
You can also take WebRTC and embed it into an application without the need of browser at all.
Media and accessWhat WebRTC does is allow the access to devices. You can access the microphone of your device, the camera that you have on your phone or laptop – or it can be a screen itself. You can capture the screen of the user and then have that screen shared or recorded remotely.
Whatever WebRTC does that does in the real time, enabling live interactions.
WebRTC isn’t limited to voice and video. It allows sending any type of data any arbitrary data
There are several reasons WebRTC is a great choice for real time communicationsSo what other choice do you really have besides using WebRTC?
The idea around WebRTC and what you can use it for are limitless. So go on start building whatever you need and use WebRTC for that.
Embed this video on your own site for free! Just copy and paste the code below…
<iframe src="https://player.vimeo.com/video/217448338" width="640" height="360" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
The post What is WebRTC and What is it Good For? appeared first on BlogGeek.me.
Contact centers are the main adopters of WebRTC still. This is clearly reflected by my infographic of the WebRTC state of the market 2017.
Motto:“This ‘telephone’ has too many shortcomings to be seriously considered as a means of communication. The device is inherently of no value to us.”
Western Union telegraph company memo, 1877.
Think you know how WebRTC fits in a contact center? Check out with The Complete WebRTC Contact Center Uses Swipefile
Get the swipefileRecently, Jaroslav from iCORD, told me the stats they now see from the contact center deployment they have in O2 Czech Republic, who also happen to be their parent company.
How is O2 CZ making use of WebRTC in their Contact Center?What they did isn’t the classic approach you will see to WebRTC in contact centers, but rather something slightly different. If you are a customer of O2 CZ and you are thinking of making a purchase on their website, you have the option to leave a number for them to immediately get back to you:
And yes – there is also an “exit intent” on that sales page, so if try to leave this page, it will appear as a popup.
How is a phone call related to WebRTC you ask? Well… it isn’t. Unless you factor in the fact that we now know what web page the user is on.
What happens next, is that a contact center agent will call back to the user, and the user will see something new on his browser – a shared space between him and the agent that just called him.
This shared space will enable the agent to browse the same page the customer was on, and move on from there elsewhere. It also includes annotations – the agent can draw or mark things on the screen. One last thing – the user will see the video of the agent, but will not share his video.
See? They even haggle and write down discount prices right on the webpage.
Now, if the interaction started with a phone call, the agent in the contact center can instruct the customer to go to the O2 CZ website and enter a PIN code there – and magically get to the same experience.
Here’s a diagram to show the communication channels we now have between the customer and the contact center agent:
Why this approach?
But was this effective? Was it worth the effort?
O2 CZ have been running this contact center service throughout 2016, and took the time to analyze the results. They did so only for sales related calls – the money makers.
Here’s what they found out:
Using this approach is much more efficient than a simple phone call.
Let’s stop right here for a second and soak that statement.
We’re talking about a contact center.
Of a mid-sized European carrier (4 million subscribers).
The type of those where I am told over and over would NOT adopt WebRTC because it does not support Internet Explorer 4. Oh. And this specific service falls back to Flash if the customer’s browser doesn’t support WebRTC and even decreases further in feature set to static screenshot and PDF file sharing for those who don’t even support Flash.
And they are already doing it for a full year.
Successfully.
In production.
In front of live customers.
Who would have thought a non-startup company that isn’t located in Silicon Valley and operated by 16-year olds would be able of doing such a ridiculous thing like deploy WebRTC in production directly to where money gets negotiated with customers.
— end of rant —
Back to the results.
Call length on average droppedIt takes 30% less time to negotiate and close a deal than a regular phone call and considerably shorter than text chat. This may seem a bit backwards – the fact that chat takes the longest and a video session the shortest, but that’s the experience of this contact center.
How about succeeding to close a deal and make a sale? WebRTC gets closed deals 25% more than regular phone calls. Chat is slightly less successful than WebRTC but more successful as phone. These values were measured on session landing at sales agents’ desk once those irrelevant and redirected were filtered out.
And the customer satisfaction? Over 20% rate the service 5 stars at the end of the interaction and 7% left positive textual evaluation of the service. Compared to the traditional IVR system that’s really high.
Where does this lead us?And if you are looking for more information about the O2 CZ deployment details – especially the technical ones, Jaroslav will be happy to have a conversation with you.
The post What to Expect when Deploying WebRTC in Contact Centers? appeared first on BlogGeek.me.
Phosfluorescently utilize future-proof scenarios whereas timely leadership skills. Seamlessly administrate maintainable quality vectors whereas proactive mindshare.
Dramatically plagiarize visionary internal or "organic" sources via process-centric. Compellingly exploit worldwide communities for high standards in growth strategies.
Wow, this most certainly is a great a theme.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.