NAT

All posts tagged NAT

Last year we interviewed Oleg Moskalenko and presented the rfc5766-turn-server project, which is a free open source and extremely popular implementation of TURN and STURN server. A few months later we even discovered Amazon is using this project to power its Mayday service. Since then, a number of features beyond the original RFC 5766 have been defined at the IETF and a new open-source project was born: the coTURN project.

Today we are catching up  with Oleg again to see what’s new and to learn what coTURN is about.

...

Continue Reading

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

For the last year and a half I’ve been working with a number of customers helping them to understand what WebRTC is about, supporting them in the definition of new products, services, and in some cases even developing WebRTC prototypes/labs for them. I’ve spent time with Service Providers, Enterprise and OTT customers and the very first time I demoed WebRTC to them, after the initial ‘wow moment’ almost all of them complained about the ‘call setup delay’, as in some cases represented tens of seconds.

...

Continue Reading

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

As Reid previously introduced in his An Intro to WebRTC’s NAT/Firewall Problem post, NAT traversal is often one the more mysterious areas of WebRTC for those without a VoIP background. When two endpoints/applications behind NAT wish to exchange media or data with each other, they use “hole punching” techniques in order to discover a direct communication path that goes from one peer to another through intervening NATs and routers but not traversing any relays. “Hole punching” techniques will fail if both hosts are behind certain types of NATs (e.g. symmetric NATs) or firewalls. In those cases, a direct communication path cannot be found and it’s necessary to use the services of an intermediate host that acts as a relay for the media or data packets, which typically sits on the public Internet. The TURN (Traversal Using Relays around Nat) protocol allows an endpoint (the TURN client) to request that a host (the TURN server) act as a relay. So far TURN, along with ICE and STUN, has seen little deployment. Now that it is a fundamental piece of WebRTC, it is gaining some momentum. In fact, at the IETF we’re now starting a new effort that will focus on enhancements to TURN/STUN that will be applicable to WebRTC deployments. This new effort is called TRAM (Turn Revised And Modernized), and we’re currently discussing its charter.

...

Continue Reading

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone
The WebRTC NAT/Firewall traversal trifecta

Most folks that set out to write an application, or build an architecture, begin with nothing but features and functionality in mind.  Many might start out assuming they will be traversing flat, reliable, and secure networks.  Inevitably, reality sets in as one starts to demo or prototype much beyond the friendly confines of the lab, and suddenly you begin finding scenarios not working properly, quality issues cropping up, or your stuff gets hacked.  “Phase 2” of the design emerges, backing in all the necessary tools to cover the gaps.

...

Continue Reading

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone