Nat traversal in WebRTC context

Yossi Zadah

NAT Traversal

October 2013

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.

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

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)

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.

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
192.168.10.10:5000

STUN Query
What’s my IP address

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

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
STUN Response
Your address is
200.200.1.1:1000

STUN Query

Static NAT
STUN Response
Your address is
200.200.1.1:1000

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
STUN Response
Your address is
200.200.1.1:1000

STUN Query

Symmetric NAT
STUN Response
Your address is
200.200.1.1:2000

Identity Crisis

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.

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.

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

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.

ICE How does it work?
STUN server

TURN server

NAT

Caller

WebRTC server

Callee

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

Nat traversal in WebRTC context

More Related Content

What's hot (20)

Similar to Nat traversal in WebRTC context (20)

Recently uploaded (20)

Nat traversal in WebRTC context