Nat traversal in WebRTC context


Published on

A presentation by Yossi Zada from AudioCodes at the 2nd WebRTC meetup in Israel talking about NAT Traversal

Published in: Technology

Nat traversal in WebRTC context

  1. 1. Yossi Zadah NAT Traversal October 2013
  2. 2. WebRTC is:  WebRTC is a free, open project that enables web browsers with Real-Time Communications (RTC) capabilities via simple Javascript APIs.  WebRTC is a media engine with JavaScript APIs.  WebRTC Allows developers to add realtime voice calls, video chats and file sharing to their web apps without the need for plug-ins.  The WebRTC initiative is a project supported by Google, Mozilla and Opera.
  3. 3. How does it work? Web Browser A Java Script code calls browser APIs to establish a call JavaScript APIs browser 1. HTML & JavaScript Web Server Call signaling 2. HTML & JavaScript Web Browser B WebRTC is a set of standardized browser APIs
  4. 4. WebRTC in Specs APIs by W3C & Protocols by IETF  Connectivity  ICE, STUN and TRUN  Signaling:  Signaling protocol not determined  WebSocket  Must support SDP form to implement ICE  Media  DTLS for key exchange for SRTP  SRTP  Bundle and Media Multiplexing  Coders  Voice Coders: Opus and G.711  Video Coder: VP8 (not final)
  5. 5. Network Address Translation  Network Address Translation (NAT) is the process of modifying network address information in datagram packet headers while in transit across a traffic routing device for the purpose of remapping a given address space into another.  This mechanism is implemented in a routing device that uses stateful translation tables to map the "hidden" addresses into a single address and then rewrites the outgoing IP packets on exit so that they appear to originate from the router.  In the reverse communications path, responses are mapped back to the originating IP address using the rules ("state") stored in the translation tables.  The translation table rules established in this fashion are flushed after a short period without new traffic refreshing their state.
  6. 6. STUN - Session Traversal Utilities for NAT  STUN is a standardized set of methods and a network protocol to allow an end host to discover its public IP address if it is located behind a NAT.  It is used to permit NAT traversal for applications of realtime voice, video, messaging, and other interactive IP communications.  STUN is intended to be a tool to be used by other protocols, such as ICE. STUN Server STUN Response Your address is STUN Query What’s my IP address
  7. 7. Different types of NAT  Network address translation is implemented in a variety of schemes of translating addresses and port numbers, each affecting application communication protocols differently.  Different NAT implementations is classified as:  Full cone NAT  Restricted cone NAT  Port restricted cone NAT  Symmetric NAT
  8. 8. Non- Symmetric NAT  Full cone, Restricted cone and Port restricted cone NATs are presenting a “static” nature of the mapping.  The NAT mapping is according the source only.  A STUN query can predict the mapping. STUN Server 1 STUN Server 2 STUN Query What’s my IP address STUN Response Your address is STUN Query What’s my IP address Static NAT STUN Response Your address is
  9. 9. Symmetric NAT  Each request from the same internal IP address and port to a specific destination IP address and port is mapped to a unique external source IP address and port.  The mapping is done by a combination of the source and destination address.  A STUN query is varies according the destination. STUN Server 1 STUN Server 2 STUN Query What’s my IP address STUN Response Your address is STUN Query What’s my IP address Symmetric NAT STUN Response Your address is Identity Crisis
  10. 10. Why symmetric NAT is challenging for SIP ?  For symmetric NAT the STUN query is irrelevant , since the STUN answer is relevant only when communicating with the STUN server, when communicating with other host the NAT will map a new IP and port.  In case that a VoIP client is located after a symmetric NAT, the client can’t share it’s own address (media) with the other side of the call.  In case that two media devices located behind symmetric NAT they can’t establish a call and must use an external media relay server – TURN server.
  11. 11. SBC as a result of a standard mistake  Probably the single biggest mistake in SIP design was ignoring the existence of NATs.  This error came from a belief in IETF leadership that IP address space would be exhausted more rapidly and would necessitate global upgrade to IPv6 and eliminate need for NATs. The SIP standard has assumed that NATs do not exist.  SIP simply didn't work for the majority of Internet users who are behind NATs.  At the same time it became apparent that the standardization life-cycle is slower than how the market ticks: SBCs were born, and began to fix what the standards failed to do: NAT traversal.
  12. 12. How SBC solves the NAT traversal issue?  An SBC is NOT located behind symmetric NAT, therefore it always knows its own signaling and media addresses.  When using an SBC to solve the NAT traversal issues the most common approach for SBC is to act as the public interface of the user agents.  This is achieved by replacing the user agent’s contact information with those of the SBC.  For remote user the SBC waits for the 1st incoming media packet and latches to its source IP. Remote User IP Phone 1 FW Symmetric NAT SIP SDP from IPP includes wrong IP:port SIP SIP SDP from SBC includes Correct IP:port SBC sends the media to the source IP address of the 1st incoming packet SBC waits for The 1st incoming packet IP Phone 2
  13. 13. ICE in a nutshell  ICE resolves the connectivity issue at the signaling stage, via SDP negotiation.  The caller gathers candidates, where each candidate is a potential address for receiving media.  Three different types of candidates  Host candidate (local address)  Server Reflexive candidates (NAT residing addresses)  Relayed candidates (TURN server address –a host acting as a relay towards the agent)  The callee gathers its own three candidates and sends them to the caller. And by using STUN it start checking connectivity toward the caller local and NAT residing addressed.  The caller checks connectivity towards the addresses provided by the callee and chooses the best pair, LAN, NAT residing and for the worst case scenario (both clients are behind symmetric NAT) TURN allocation.
  14. 14. ICE How does it work? STUN server TURN server NAT Caller WebRTC server Callee
  15. 15. ICE – Session Flow Gather Local candidates Gather Server Reflexive candidates using STUN Gather Relayed candidates from the TURN server Select the best candidates Perform Media Check on all peer candidates Receive peer candidates from the SIP message Exchange final candidates with the peer Check the connection type Activate UDP/TCP socket
  16. 16. Thank You!