Making SIP NAT Friendly

1
Making SIP NAT Friendly

• Jonathan Rosenberg
• dynamicsoft

2
Problem Statement

• Long time until we have ubiquitously deployed
• IPv6
• Midcom enabled NAT
• ALGs
• No commercial SIP ALGs today
• Many deployment scenarios, you cant just
  upgrade the NAT, when we need SIP
• Especially when the NAT is in the consumers home
  and the provider wants SIP
• Solution is to make protocols NAT friendly

3
NAT Friendly Guidelines

• Draft-ietf-nat-app-guide-04.txt
• Some basic ideas in there
• Dont put IP addresses in protocols
• Client origination of connections
• Unfortunately, SIP predates these guidelines
• So, lets see how to apply them to SIP via small
  extensions

4
Basic concepts

• Find ways to ignore IP addresses in SIP/SDP
  wherever possible
• Get the information from the transport
  connections themselves
• Find ways to make a peer to peer application look
  like client server
• One side initiates
• Can send data back and forth
• Dont rely on DNS, since many clients wont have
  domain names

5
Our assumptions

• NATs let packets out, both UDP and TCP
• If packet comes from A,B to C,D, A,B is
  bound to X,Y
• Packet forwarded with source X,Y
• Packets from C,D, to X,Y, are natted to A,B
  ONLY packets from C,D
• Most restrictive case for UDP
• UDP binding maintained as long as there is
  activity in either direction for many seconds to
  a minute

6
Reference Model
proxy
proxy
NAT
NAT
UAC A
UAS B
7
First problem SIP UAC to proxy

• SIP over UDP is not NAT friendly
• Uses port number from Via header
• SIP over TCP is NAT friendly
• Send response to existing connection
• Recommendation
• UAC should use TCP to proxy for sending messages
• Keep persistent connection to minimize setup
  delay

8
Second problem proxy to UAS

• Proxy to UAS routing is through registrations
• Registration has Contact header containing
  address to send to
• Not NAT friendly
• Address is wrong
• No NAT binding for it
• Solution
• Registration sent over TCP connection to proxy
• That connection used for incoming INVITEs
• UAS listens on connection
• But contact header will not point to this
  connection!

9
Contact Cookie

• Special contact value which tells registrar
  register my contact using the IP address and
  port where the register came from
• Register comes from persistent TCP connection to
  server
• Causes calls to be routed to UAS through NAT!
• Want to be explicit
• Call forward service
• Contact cookie
• Special URL
• Sipltusergt_at_jibufobutbmpu

10
Solves many other problems

• Multi-homed hosts
• VPN interface to private network
• Registrar on public network and private
• Need to pick the right interface for each
  registration
• Client cant easily tell which interface to pick!
• Let server figure it out

• Cant tell my address
• Many hosts cant determine their IP address
• Java Applets
• Cant write SIP UA as Java applet today
• Why? Cant communicate anywhere but server
• If registrar server, can connect to server, and
  now receive incoming invites on that connection!

11
Hard part RTP

• Current RTP is unidirectional
• A indicates IP/port to receive from B
• B indicates IP/port to receive from A
• If either is behind NAT, media wont flow to them

• Solution make RTP look like client-server
  protocol
• A indicates IP/port to receive from B
• B sends to A, A sends back to B using source
  IP/port of RTP
• Basically, only need IP address from ONE of the
  participants the server

12
Symmetric RTP

• Conceptually, this is symmetric RTP
• Connection oriented
• Problem who initiates connection to whom?
• Same problem for media over TCP
• Need to define active and passive participants

• Work already in mmusic to do just that
• Draft-ietf-mmusic-sdp-comedia-00.txt
• All we need is to define new keyword for this

13
Handles two of three cases

• A behind NAT, B not
• A initiates RTP connection to B
• B tries to connect to A, but since A provided
  private address, fails
• B receives RTP packet from A
• B sends RTP packets to source address of packet
  from A
• A-gtB connection used

• B behind NAT, A not
• B initiates RTPconnection to A
• A tries to connect to B, but since B provided
  private address, fails
• A receives RTP packet from B
• A sends RTP packets to source address of packet
  from B
• B-gtA connection used

14
What about third case?

• Both behind NAT is hard
• Many solutions possible
• Baseline solution RTP translator outside of NAT
• Both users connect to translator

RTP trans
NAT
NAT
A
B
15
How does translator get there?

• Proxies on both sides know whether their users
  are behind NAT
• Via header doesnt match source IP/port
• Requires client to place listen interface into
  Via header
• Socket connect must happen before via added

• As proxy modifies SDP to indicate active if A is
  behind NAT
• If Bs proxy gets INVITE with active SDP, and B
  is behind NAT, problem!

16
How does translator get there?

• When theres a problem
• Bs proxy allocates translator
• Modifies SDP address in INVITE to point to
  translator
• Modifies SDP address in 200 to point to
  translator
• A and B connect to translator
• Translator sends media back to A and B over those
  connections

• Other solutions are possible
• No solutions are possible without this ability to
  send packets back to source address through
  binding!

17
Symmetric RTP Solves other problems too

• Java applets
• Same problem as before
• SOCKS
• SIP/RTP/SDP applications can now be socksified!!
• Reduces number of bindings needed in NATs
• 1 per call instead of 2

• Works with firewalls that allow outbound
  connection oriented UDP
• Generally, anything that assumes client-server
  connection oriented traffic
• Many things

18
So, what needs to be done?

• Framework document that describes concepts in
  light of existing NAT and midcom work
• SIP extension
• Contact cookie
• Anything else possibly needed

• SDP Usage
• Add token to comedia draft
• Describe symmetric RTP conventions