Real Time Communications Bits

ICE [1] is a framework to find the optimal path between two endpoints to establish a channel even in presence of network elements limiting connectivity (NAT or Firewalls). What is the problem with NATs and Firewalls? Those network boxes (routers applying NAT or firewalls applying security policies) restrict the type of flows that you can establish.  For example a NAT router typically allows any connection from the intranet to the internet but not in the other direction, or corporate firewalls typically allow only TCP traffic. What are the tools we have for NAT and Firewall traversal? We have STUN that is basically a ping-pong or echo protocol that can be used for two purposes: Find out the public address of a device as seen by a STUN server in the public internet Make connectivity checks to test if a destination IP:port is visible/reachable from a source IP:port We have TURN that is a protocol to create tunnels.   Basically the client asks the TURN server to get an IP:port

Nowadays there is some hype around the WebRTC initiative leading to some missunderstandings.   I have collected some frequently asked questions to help to understand what is and what is not WebRTC to avoid it becaming the next big buzzword in the telco industry. What is WebRTC? Is an initiative to add capabilities to send/receive audio and video in the browsers without requiring additional plugins. It is exactly the same that happened with video playing and today most modern browsers have native support for that capability. Who is behind WebRTC? Google is the initial and main supporter but Opera and Firefox have been also supporting it from the very beginning.  Lots of individual contributors from different companies (f.e. Cisco or Ericsson) are working on this in standardization forums. Efforts to achieve WebRTC goals threefold now: Google with individual contributors building a reference implementation, W3C defining the APIs to be exposed in the web browsers to devel