VoIP + NAT
1
http://www.upnp.org/
UPnP [1/2]
Universal Plug and Play
It is being pushed by Microsoft
Windows® Messenger
A UPnP-aware client can ask the UPnP- enabled NAT how it would map a
particular IP:port through UPnP
It will not work in the case of cascading NATs
3
UPnP [2/2]
A: Private Network
UPnP-aware Internet gateway device
The UPnP-enabled NAT allows “A” to be aware of its external IP
B: Public Internet
“B” and “A” can communicate with each other
UPnP- enabled
NAT
Public Internet
B Private
Network A
External Query
A server sits listening for packets (call this a NAT probe)
When it receives a packet, it returns a message from the same port to the source containing the IP:port that it sees
IP: 10.0.0.1
Port: 8000 NAT
Public Internet NAT Probe
IP: 202.123.211.25 Port: 12345
5
STUN
Simple Traversal of UDP Through NAT
RFC 3489
In Working Group IETF MIDCOM Group
Simple Protocol
Works with existing NATs
Main features
Allow Client to Discover Presence of NAT
Works in Multi-NAT Environments
Allow Client Discover Type of NAT
Allows Client to Discover the Binding Lifetimes
Stateless Servers
STUN Server
Allow client to discover if it is behind a NAT, what type of NAT it is, and the public address & port NAT will use.
Very Simple Protocol, Easy to implement, Little load
IP: 202.123.211.25 Port: 12345
Client IP: 10.0.0.1
Port: 5060
STUN Server IP: 222.111.99.1
Port: 20202
NAT
Client wants to receive packet at port 5060
Send a query to STUN server from port 5060
STUN Server receives packet from 202.123.211.25 port
12345
STUN Server send a response packet to client. Tell him his public address is
202.123.211.25 port 12345
Binding Acquisition
STUN Server can be ANYWHERE on Public Internet
Call Flow Proceeds Normally
STUN Message [1/3]
TLV (type-length-value)
Start with a STUN header, followed by a STUN payload (which is a series of STUN attributes depending on the message type)
Format
STUN
Header STUN Payload (can have none to many blocks)
9
STUN Message [2/3]
STUN
Header STUN Payload (can have none to many blocks)
Message Type (16 bits) Message Length (16bits) Transaction ID (128 bits)
Message Types
0x0001: Binding Request 0x0101: Binding Response 0x0111: Binding Error Response
0x0002: Shared Secret Request 0x0102: Shared Secret Response 0x0112: Shared Secret Error Response
STUN Message [3/3]
STUN Payload (can have none to many blocks)
STUN Header
Attribute Type (16 bits) Attribute Length (16bits) Attribute Value (Variable length)
Attribute Types
0x0001: MAPPED-ADDRESS 0x0002: RESPONSE-ADDRESS 0x0003: CHANGE-REQUEST 0x0004: SOURCE-ADDRESS 0x0005: CHANGED-ADDRESS 0x0006: USERNAME
0x0007: PASSWORD 0x0008: MESSAGE-INTEGRITY 0x0009: ERROR-CODE 0x000a: UNKNOWN-ATTRIBUTES 0x000b: REFLECTED-FROM
11
Automatic Detection of NAT Environment [1/2]
STUN Client Environment
STUN Server
IP1 ServerSTUN
IP2 Port1
Port2
Port2 Port1
Test I Test II Test IV Test III
Automatic Detection of NAT Environment [2/2]
Test I
Test II
Test III Test IV
Resp?
Resp?
Resp?
Resp?
Yes No UDP
Blocked Same
IP?
Test II
Yes No
Open Internet
SymUDP Firewall
ConeFull NAT No
Yes Same
IP as Test I?
Symmetric NAT
Port
Restricted NAT
Yes
No Yes
Yes
No No
13
Binding Lifetime Determination
STUN
Client NAT
Bind Req.
Bind (Pa, Pp) Binding Resp.
MAPPED-ADDRESS (Pa, Pp) Start Timer T
If it receives Binding Response on socket X, the binding has not expired.
Socket X
Socket Y
Another Binding Request,
RESPONSE-ADDRESS is set to (Pa, Pp)
Binding Acquisition Procedure
STUN
Client 1 NAT Client 2
Control Media
SIP Message RTP
Shared Secret Request and Response
Binding Request and Response (Pa, Pp) Binding Request and Response (Pa’, Pp’)
RESPONSE- ADDRESS is set to (Pa, Pp)
15
STUN - Pros and Cons
Benefits
No changes required in NAT
No changes required in Proxy
Works through most residential NAT
Drawbacks
Doesn’t allow VoIP to work through Symmetric NAT
RTCP may not work
Need to keep media flowing to keep bindings alive
Is STUN suitable for Symmetric NAT
Absolutely not
IP: 202.123.211.25 Port: 12345
Client A IP: 10.0.0.1
Port: 21 NAT
Mapping Table
10.0.0.1:21 <-> 12345 (for 222.111.99.1 : 20202)
STUN Server IP: 222.111.99.1
Port: 20202 Client B IP: 222.111.88.2
Port: 10101
17
Solutions for Symmetric NATs
Connection Oriented Media
RTP-Relay
Connection Oriented Media
The endpoint outside the NAT must wait until it receives a packet from the client before it can know where to reply
Add a line to the SDP message (coming from the client behind the NAT)
a=direction:active
The initiating client will “actively” set up the IP:port to which the endpoint should return RTP
The IP:port found in the SDP message should be ignored
19
Problem?
1) If the endpoint does not support the a=direction:active tag
2) If both endpoints are behind Symmetric NATs
RTP-Relay
In either of the cases considered in the previous slide, one solution is to have an RTP Relay in the middle of the RTP flow between endpoints.
The RTP Relay acts as the second endpoint to each of the actual
endpoints that are attempting to communicate with each other.
21
Example
The following is a typical call flow that might be instantiated between a User Agent behind a symmetric NAT and a voice gateway on the open Internet:
1
2 3 6 8
9 12
7
4 5
10 11
NAT Proxy
Voice Gateway NAT
UA
RTP Relay
TURN
Traversal Using Relay NAT
draft-rosenberg-midcom-turn-04.txt
Expires: August 16, 2004