Looking for a WebRTC PaaS with video? Twilio now has it.
It has been 5 months since Twilio last had an announcement related to WebRTC. Then, it was about unbundling NAT traversal. Well, this one is pretty big as well – Twilio decided to jump the video bandwagon. You now can build a video calling service using Twilio APIs.
While Twilio is almost never associated with WebRTC, it has been in their product offering for the last two years at the very least. They are probably doing more WebRTC minutes than most other players combined. The reason they are unknown in WebRTC is probably due to their lack of video support.
From reading the press release and browsing their website, here are my thoughts:
- In the WebRTC PaaS world, video is becoming a mandatory feature
- Customers may not be using it at the end of the day, but you must have it in your list of features for them to choose you
- Twilio had to have it in their feature list as well
- This announcement closes that gap
- I believe this is more about serving the existing customer base than catering and attracting new customers
- Twilio will need to see how customers end up using it to decide in their future roadmap
- They will also need to try and become synonymous with WebRTC video to dethrone TokBox’ immediate association with WebRTC (most companies I talk to have tried TokBox or are actively using it)
- Adding H.264 support with iOS hardware codec optimization is a unique selling point for Twilio today
- Other WebRTC PaaS vendors will have to follow suit and support H.264 as well
- It will be interesting to see how this plays once Google officially adds VP9 and H.264 into their Chrome mix – and Twilio goes to implement video mixing for multipoint calling. Time will tell
- Supporting Java Script Promises shows forward thinking
- WebRTC plans on adding Promises in future API (see here), to make it easier for developers to use it
- Twilio acting on it now and adding such support also simplifies work for developers
- Missing in the announcement are the next set of capabilities you see in other WebRTC PaaS solutions – solid multiparty calling that can scale to 10 or more participants, recording capabilities, etc.
- The other components in this press release are pretty standard – all vendors say they have global reach with many data centers, all vendors say they optimize their mobile SDKs for network issues. If and how has Twilio have outdone others is an open question
- Consider this Twilio’s first step into video, with more developments to come down the road – there is still place for improvement
How will this affect other players?
- Twilio adding video, even with 1:1 calling only is a big deal. They are the incumbent when it comes to voice and have the resources and clout to build video. Everyone in this space should be slightly more worried than they were yesterday
- H.264 support will become the norm. Expect other WebRTC PaaS players to change roadmaps or increase speed to introduce such capabilities
- Promises based APIs will show up in other platforms as well. Simplicity being the name of the game, I don’t see how this can be neglected moving forward
- Smaller vendors will have a harder time to differentiate. Video was an obvious choice, as the main player in this domain was TokBox up until today. Not anymore
Why is this important?
- Twilio is the incumbent in this market
- Up until recently, you could have even referred to them as the legacy player
- They are now catching up, with each announcement placing significant new capabilities into play
- It opens up another option for developers who need video in their use case
Planning on selecting a CPaaS vendor? Check out this shortlist of CPaaS vendor selection metrics:
Tsahi,
Twilio has the developers. Devs trust them. That’s their strength.
Andy
Andy,
That’s true. Goes without saying, which is probably why I forgot about it…
Well stated, Tsahi, as usual.
Do agree with Andy that we can’t overstate the importance of the Twilio developer ecosystem. This means immediate impact for WebRTC, regardless of how the Twilio platform compares to Tokbox and others.
I am most curious on how Twilio handles large scale conference use cases. Those use cases represent a serious investment in media and session management competencies that Twilio doesn’t have much of in house today. Is that use case worth building internal support for? Or perhaps Twilio is better off partnering, offering northbound APIs to providers that can specialize in those competencies?
If their service doesn’t delivers, then it isn’t interesting. It probably does though…
As for large scale conferences – they don’t deal with it. They indicate the service scales – not that a single session scales. For now, as far as I understand, multiparty video calls are mesh based.
Couldn’t you run it through Jitsi?
Steven – you could, but there are other ways. Jitsi also takes care of part of the challenges and not all of them, so there’s additional work to be done on top of it.
Also remember that Twilio needs to work at scales that others can ignore at their initial launch.
Tokbox’s pricing is minutes per stream based which makes it extremely expensive for multi-party usage. If they moved to a bandwidth model then it would be more interesting.
Different WebRTC PaaS vendors use different approaches to pricing models. My report covers these aspects: https://bloggeek.me/webrtc-paas-report/
Maybe you want to review your H.264 statement Tsahi :):
Gustavo, thanks.
At the time of writing, they were the first ones.
It was bound to be a temporary differentiator.