What Twilio’s NTS Service Means to WebRTC Developers and to Other WebRTC API Platform Vendors

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...