Twilio just launched a NAT Traversal Service. A great way to attract first time developers to its platform.
One of the areas where we are lacking solutions today is NAT Traversal services. In order to develop the most basic WebRTC service, there’s a need for NAT, which would mean a headache in installation, deployment, management and maintenance of backend servers that deal with media – not the cup of tea for most web developers.
For that exact reason I was so hooked to what XirSys had to offer. The sad thing was that they were virtually alone in this market, barring one or two additional palyers of sorts who offer a similar service. It should be straight forward – you need to pick and choose STUN and TURN servers, so why not use a 3rd party and just pay for it? There’s very little in the way of vendor lock-in involved.
Last week this has distinctly changed. Twilio has introduced their NTS:
We originally developed STUN and TURN as a component of Twilio Client, as part of our drive to make our Twilio Client product the best global WebRTC platform out there. Once we built it, we felt that developers building their own real-time communications service would benefit from this service so we wanted to ‘unbundle’ it and make it available as a standalone service.
That’s brilliant. Here are my thoughts on this move:
- WebRTC API Platforms focus on offering a whole service. You can either take it or leave it. There’s little in the way of pick-and-choose. There are two exceptions out there today:
- Temasys, with their plugin. Started out as an interesting idea, but I think it is now defocusing their platform itself. Once you go down the customization path, product and service boundaries starts to blur
- And now Twilio, offering NAT traversal only. You can consume it and not use any of the other Twilio services
- For Twilio this is a great way to get developers to start using their platform, and maybe in the future converting them into customers of their other offering (which is quite extensive)
- There’s little extra effort on Twilio’s end. They already run and maintain these NAT traversal service, so putting extra load on them is just cranking up the benefits of economies of scale
- It gets Twilio to be used by those who develop video related use cases. Twilio today is voice only, but their NAT traversal service most probably support video use cases as well. It is a good starting point with no risk involved
- It fits well with Twilio’s domination of the long tail of developers for voice and messaging; adding them more leverage in the web and WebRTC domains
- With Twilio’s size, scale and reach – this new service should be very attractive to many developers out there (I didn’t compare prices though)
- Other WebRTC API platform vendors should take note and see what they can/should offer differently than what they do today
- XirSys should think hard of what its next move should be. The gorilla just got into the room and announced itself
I looked at this domain for a long time, always debating internally (and with Chris) if this is a good business to be in or not. There seems to be little money involved. Twilio headed there is probably more about increasing usage of their services than increasing the bottom line in the short term.
All in all, a great move by Twilio. I wish I thought of it first.
Want to learn more of the dynamics of the WebRTC API Platforms? There’s a report on that…
What would a NAT Traversal Service have to do extra/differently to support video? Isn’t it just a function of the transfer rate? If it is based on cloud architecture that is already built-in? TIA
Aswath,
That’s exactly the point I was trying to make – Twilio offers voice only services today. This is their first foray into the realm of video.
http://www.medianetworkservices.com/ has been offering such a service for quite a while so what is the news? Ok, they don’t mention WebRTC anywhere…
Philipp,
You can run such a service in your garage, but that would be different than Twilio doing the same thing. It is a matter of scale and attention.
Twilio solving it sends a different message to the industry than MNS doing the same.
We have been providing a similar service – http://www.seamconnect.com for long now. But as you said, Twilio will hopefully attract more WebRTC developers and we get to see some adoption.
Hi, We have a webRTC application using some ordinary free STUN/TRUN. Now we have to go live with hundreds of thousands of users by embeding our webRTC chating app into our another application which is being used heavily. We expect much load. So should we hire Twilio’s STUN/TURN or should we go for some Paas services directly? Please suggest if Xirus is better option.
just adding. We have to go for video chat only.
I am not sure about the differences between Twilio’s NAT Traversal service and the XirSys one. You should ask the vendors directly why you should use one and not the other.
For me, both should be fine and frankly – I never heard any complaints about either of them (doesn’t say that everyone’s happy, just the people who talked to me).
Sorry I could not explain well. I needed to ask if we have to face million users concurrently in future then should we choose to hire TURN/STUN from any vendor or choose to buy PaaS
That’s up to you to some extent.
CPaaS means a lot less hassle when it comes to developing and maintaining a service. It comes at a price that is usually usage based.
If you are contemplating the alternative, then CPaaS is probably the better approach for you.