Multimedia Communication in the

Internet
SIP and NAT Traversal
Sven Ehlert
Next Generation Network Infrastructures
Fraunhofer FOKUS

Recap: SIP Message

Request

Response

INVITE sip:UserB@there.com SIP/2.0

SIP/2.0 200 OK

Via: SIP/2.0/UDP here.com:5060

Via: SIP/2.0/UDP here.com:5060

From: BigGuy <sip:UserA@here.com>

From: BigGuy <sip:UserA@here.com>

To: LittleGuy <sip:UserB@there.com>

Call-ID: 12345600@here.com
CSeq: 1 INVITE

Message
Header
Fields

Subject: Happy Christmas

To: LittleGuy <sip:UserB@there.com>;tag=65a35

Call-ID: 12345601@here.com
CSeq: 1 INVITE
Subject: Happy Christmas

Contact: BigGuy <sip:UserA@here.com>

Content-Type: application/sdp

Contact: LittleGuy <sip:UserB@there.com>

Content-Type: application/sdp

Content-Length: 147

Content-Length: 134

v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Payload

v=0
o=UserB 2890844527 2890844527 IN IP4 there.com
s=Session SDP
c=IN IP4 110.111.112.113
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000

receive RTP G.711-encoded audio at 100.101.102.103:49172

NAT Introduction

NAT = Network Address Translation

Share one IP address among many hosts

NAT solution to map between private and public addresses

Mid-Term solution until IPv6

Benefits

Allows multiple hosts operating with one singe address

Conceal internal structure of intranet

Scenarios

Corporate use with insufficient available IP addresses

Corporate use to hide network structure (Security)

Private use DSL line sharing

NAT Details

192.168.1.10:80
1.2.3.4:10080
Internal IP
192.168.1.1

External IP
1.2.3.4
NAT

192.168.1.11:80

1.2.3.4:20080

NAT Classification

RFC 2663: IP NAT Terminology and Considerations

Full Cone

Restricted Cone

Port Restricted Cone

Symmetric NAT

Generally dynamic mappings for a short time

Contact
Source
User Client

Contact
Target

Full Cone NAT

Mappings well established

A:200.10.0.1
P:20100
A:192.168.1.10
P:8000

A:100.0.0.1
P:12000

Full Cone NAT

Mappings well established

Connection from public Internet possible if mapping known

A:200.20.0.1
P:20200
A:200.10.0.1
P:20100
A:192.168.1.10
P:8000

A:100.0.0.1
P:12000

Restricted NAT

Mappings established on client request

A:200.10.0.1
P:20100
A:192.168.1.10
P:8000

A:100.0.0.1
P:12000

Restricted NAT

Mappings established on client request

Connection from public Internet possible only after client request

A:200.20.0.1
P:20200
A:200.10.0.1
P:20100
A:192.168.1.10
P:8000

A:100.0.0.1
P:12000

Restricted NAT

Mappings established through client connection

Connection from public Internet only possible after client request

Port Restricted NAT

applies also to different ports on same host!

P:20100
P:20101
A:192.168.1.10
P:8000

A:100.0.0.1
P:12000

Symmetric NAT

Mappings depend on target IP

Every new target establishes a new mapping

Connection from public Internet possible only after client request

P:12000
P:12001

A:192.168.1.10
P:8000

A:100.0.0.1

A:200.20.0.1
P:20200
A:200.10.0.1
P:20100

Symmetric NAT

Mappings depend on target IP

Every new target establishes a new mapping

Connection from public Internet possible only after client request

High security setting

P:12000
P:12001

A:192.168.1.10
P:8000

A:100.0.0.1

A:200.20.0.1
P:20200
A:200.10.0.1
P:20100

NAT Summary

NAT: Multiplex multiple private addresses to one public

address
Four different types

Full Cone

Dest. Independent

Incoming traffic always possible

Restricted Cone

Dest. Independent

Incoming traffic after outgoing

Port Restricted Cone

Dest. Independent

Incoming traffic after outgoing

Symmetric

Dest. Dependent

Incoming traffic after outgoing

Mapping generally available only for a short time

Use NAT keep alive pings

SIP Traffic Flow

Signaling Protocol
Media Transport
End Users

Call Server
End Users

IP Router

Signaling and Media traffic might pass different hosts

SIP Through NAT

UA1

192.168.0.1

NAT

Proxy

100.0.0.2

150.0.0.3

UA2

200.0.0.4

IP Source with Port

IPSRC 192.168.0.1:5060
INVITE sip:user@200.0.0.4
Via: SIP/2.0/UDP 192.168.0.1:5060
Contact: user@192.168.0.1
Content-Type: application/sdp
c=IN IP4 192.168.0.1
m=audio 8000 RTP/AVP 4

SIP Message with SDP

SIP Through NAT

UA1

192.168.0.1

NAT

Proxy

100.0.0.2

150.0.0.3

UA2

200.0.0.4

IPSRC 192.168.0.1:5060

IPSRC 100.0.0.2:1234

INVITE sip:user@200.0.0.4
Via: SIP/2.0/UDP 192.168.0.1:5060
Contact: user@192.168.0.1
Content-Type: application/sdp
c=IN IP4 192.168.0.1
m=audio 8000 RTP/AVP 4

INVITE sip:user@200.0.0.4
Via: SIP/2.0/UDP 192.168.0.1:5060
Contact: user@192.168.0.1
Content-Type: application/sdp
c=IN IP4 192.168.0.1
m=audio 8000 RTP/AVP 4

SIP Through NAT

UA1

192.168.0.1

NAT

Proxy

100.0.0.2

150.0.0.3

UA2

200.0.0.4

IPSRC 192.168.0.1:5060

IPSRC 100.0.0.2:1234

INVITE sip:user@200.0.0.4
Via: SIP/2.0/UDP 192.168.0.1:5060
Contact: user@192.168.0.1
Content-Type: application/sdp
c=IN IP4 192.168.0.1
m=audio 8000 RTP/AVP 4

INVITE sip:user@200.0.0.4
Via: SIP/2.0/UDP 192.168.0.1:5060; \
received:100.0.0.2;rport:1234
Contact: user@192.168.0.1
Content-Type: application/sdp
c=IN IP4 192.168.0.1
m=audio 8000 RTP/AVP 4

SIP Through NAT

UA1

192.168.0.1

NAT

Proxy

100.0.0.2

150.0.0.3

UA2

200.0.0.4

IPSRC 100.0.0.2:1234

IPSRC 150.0.0.3:5060

INVITE sip:user@200.0.0.4
Via: SIP/2.0/UDP 192.168.0.1:5060
Contact: user@192.168.0.1
Content-Type: application/sdp
c=IN IP4 192.168.0.1
m=audio 8000 RTP/AVP 4

INVITE sip:user@200.0.0.4
Via: SIP/2.0/UDP 150.0.0.3:5060
Via: SIP/2.0/UDP 192.168.0.1:5060
Contact: user@192.168.0.1
Content-Type: application/sdp
c=IN IP4 192.168.0.1
m=audio 8000 RTP/AVP 4

SIP / NAT Problems

Signaling traffic

Routing back to the NATed UA

Future requests to a NATed contact

Media Traffic

Payload SDP address does not match contact address

And more!

What about incoming requests?

SIP NAT Solutions

Messages have to be altered to reflect present address

Responsibility of NAT or UA?

NAT: Application Layer Gateway

Needs access to the NAT / firewall

Needs special configuration

No possibility to alter encrypted traffic, e.g. TLS

Cascading NATs?

UA

Needs enhanced UAs

Needs means to detect real IP

Query NAT, e.g. UPnP

Protocol security flaws
Query external Server, e.g. STUN
Can recognize cascading NAT

NAT + ALG
UA1

192.168.0.1

NAT+ALG

Proxy

100.0.0.2

150.0.0.3

INVITE sip:user@200.0.0.4
Via: SIP/2.0/UDP 192.168.0.1:5060
Contact: user@192.168.0.1
Content-Type: application/sdp
c=IN IP4 192.168.0.1
m=audio 8000 RTP/AVP 4

INVITE sip:user@200.0.0.4
Via: SIP/2.0/UDP 100.0.0.2:1234
Contact: user@100.0.0.2
Content-Type: application/sdp
c=IN IP4 100.0.0.2
m=audio 3456 RTP/AVP 4

UA2

200.0.0.4

STUN

Simple Traversal of UDP Through NATs

RFC 3489

Simple client-server protocol

Detects type of NAT used and public visible addresses

Does not work with Symmetric NATs!

...
Client

NAT's

STUN server
Public Address Space

SIP with STUN

STUN
UA1

NAT

Proxy
150.0.1.3

192.168.0.1

100.0.0.2

150.0.0.3

UA2

200.0.0.4

use STUN to find out public RTP address:

c=IN IP4 192.168.0.1

m=audio 8000 RTP/AVP 4

c=IN IP4 100.0.0.2

m=audio 3456 RTP/AVP 4

STUN NAT Detection

Client can detect the type of NAT it is placed behind

4 simple STUN tests

Primary STUN
Port x
Port y

Client

Unknown NAT

Secondary STUN
Port x
Port y

STUN Test 1

Client can detect the type of NAT it is placed behind

Primary STUN
Port x
Port y
Client

Unknown NAT

No return: UDP blocked. Stop

Return: Check returned IP address / port

Secondary STUN
Port x
Port y

Returned address / port match local address / port: no NAT

deployed

STUN Test 2

Client can detect the type of NAT it is placed behind

Primary STUN
Port x
Port y
Client

Unknown NAT

Secondary STUN
Port x
Port y

Address / port matched from test 1 (no NAT)

No return: symmetric UDP firewall

Return: unrestricted access

Address / port did not match from test 1 (NAT deployed)

Return: Full Cone NAT, otherwise new test

STUN Test 3

Client can detect the type of NAT it is placed behind

Primary STUN
Port x
Port y
Client

Returned Address / port differ from test 1

Unknown NAT

Symmetric NAT. Stop

Returned Address / port same as test 1

(Port) Restricted NAT

Secondary STUN
Port x
Port y

STUN Test 4

Client can detect the type of NAT it is placed behind

Primary STUN
Port x
Port y
Client

Unknown NAT

No return: Port Restricted NAT

Return: Restricted NAT

Secondary STUN
Port x
Port y

NAT and RTP

Different types of NAT need to send traffic before they can

receive traffic

(Port) Restricted NAT, symmetric NAT

NATed client has to initiate RTP stream

Symmetric NAT client cannot detect its public address with a

NAT probe
Connection Oriented Media for Symmetric NAT

Target has to wait until initiator starts RTP stream

Return RTP to the same address / port

Needs client support (modified SDP fields)

RTP Proxy / Relay for double symmetric NAT

Intermediate RTP connection between two UAs

Located in public Internet

RTP Relay

DeltaThree

1) UA sends INVITE to proxy

2) Proxy contacts Relay to setup RTP session
3) Relay assigns Port and forwards it to proxy
4) Proxy modifies SDP and forwards this to destination

RTP Relay

DeltaThree

5) OK from destination with its own SDP

6) Proxy delivers SDP information to relay (or instructs to setup
a new session if destination is also behind symmetric NAT)
7) Relay informs proxy of new port
8) Proxy forwards OK to UA with modified SDP

RTP Relay

DeltaThree

9) RTP traffic to RTP relay

10)Relay notes first incoming packet for further use
11)Destination sends RTP
12)RTP traffic is sent to address captured in 10)

NAT Summary

SIP and NAT are not meant for each other!

NAT won't disappear in the short term

IPv6 still not deployed yet

Even then NAT for security

No standardized NAT established

RTP relay being standardized: Traversal Using Relay NAT (TURN)

STUN + TURN -> Interactive Connectivity Establishment (ICE)

Workaround for SIP exist, but it's no perfect solution

Signaling information has to be patched

Media information has to be patched

Media traffic needs to be relayed

References

P. Mchler: SIP Architecture with NAT, Siemens MySip.ch

Technical Report, 2004
J. Rosenberg, C. Huitema, R. Mahy, STUN Simple
Traversal of UDP through NATs, RFC 3489, 2003
J. Rosenberg, C. Huitema, R. Mahy. Traversal Using Relay
NAT (TURN), draft-rosenberg-midcom-turn-07, IETF Work
in Progress, 2005
J. Rosenberg, Interactive Connectivity Establishment
(ICE), draft-ietf-mmusic-ice-07, IETF Work in Progress,
2006
P. Srisuresh, M. Holdrege: IP Network Address Translator
(NAT) Terminology and Considerations, RFC 2663, 1999