NAT traversal in SIP

1
NAT traversal in SIP

• Midterm presentation
• By Hazanovich Evgeny
• Hazanovich Alex
• Supervisor Eddie Bortnikov

2
Background

• NAT Network Address Translation (RFC 1631)
• Used by service providers and private individuals
  to provide solution to problem of not having
  enough public IP addresses
• NAT simply connects a range of private IP
  addresses
• to one or more public IP addresses
• There are two parts of NAT
• Source NAT Source address of all outgoing
  packets will be replaced by public address of
  NAT (mapping)
• Destination NAT Destination address of all
  incoming packets will be replaced by
  internal address

3
Background

• NAT Network Address Translation (RFC 1631)
• There are 4 types of NAT
• Full-cone In this case the mapping is well
  established and anyone who wants to
  reach clients behind the NAT, need only to
  know the mapping

4
Background

• NAT Network Address Translation (RFC 1631)
• There are 4 types of NAT
• Restricted cone In this case the mapping will
  occur only when internal computer sends
  out data to a specific destination IP and
  incoming packets only from this specific
  IP will be accepted by NAT

5
Background

• NAT Network Address Translation (RFC 1631)
• There are 4 types of NAT
• Port restricted cone This NAT is almost
  identical to previous, but in this case the
  NAT will block packets from specific IP AND
  port, unless the internal client had
  previously sent packet to the specific IP AND
  port

6
Background

• NAT Network Address Translation (RFC 1631)
• There are 4 types of NAT
• Symmetric This NAT is different from the first
  three in that a specific mapping of
  internal IPport to the NATs public IPport is
  dependant on destination IP address
  that the packet is sent to.

7
Background

• SIP - Session Initiation Protocol (RFC 3261)
• Signaling protocol used to initiate and control
  A/V sessions
• Widely used because of simplicity and
  extensibility
• Text based request/response protocol (like HTTP
  but P2P)
• All requests and responses are sent through SIP
  proxy
• All requests and responses consist of header
  fields and an optional message body
• Basic SIP headers
• Via header contains address to receive
  responses
• Contact header contains address to receive
  further requests
• To header, From header, CSeq etc.
• New headers can be easily added
• SIP uses SDP (Session Description Protocol) for
  describing
• multimedia session (IPport for media, codec,
  frame rate, etc.)

8
Problem

• The traversal of SIP through NAT can be split
  into two categories
• The core SIP signaling traversal
• Associated media traversal
• SIP signaling problem
• IPport in Via header is internal
• IPport in Contact header is internal
• So responses and future request will be routed
  incorrectly
• Media problem
• IPport in SDP message is internal
• So no media will be received
• The problem of symmetric NAT here is different
  from other 3 types

9
Existing solutionsfor Media traversal

• UPnP Universal Plug-n-Play protocol (pushed by
  Microsoft)
• Application can ask NAT (through the protocol)
  about mapping for specific internal IPport
• The solution wont work in case of cascading NATs
  
• STUN (Simple Traversal of UDP trough NAT)
• Simple request/response protocol
• Helps to discover public IPport by sending some
  requests to STUN server
• Helps to determine which kind of NAT you are
  behind
• Many SIP Clients are already STUN aware and can
  set their SDP messages accordingly
• The solution cant help in case of two clients
  behind symmetric NATs
• TURN
• Similar to STUN but provides solution for
  symmetric NAT using UDP relay

10
Existing solutionsfor SIP signaling traversal

• First solution is to use STUN to discover public
  IPport and set Via and Contact headers
  accordingly
• Second solution is same to first but using UPnPto
  discover public IPport
• Third solution is to use SIP capabilities for NAT
  traversal
• There are two parameters in SIP Via header
• received parameter The source IP of incoming
  request
• rport parameter The source port of incoming
  request
• If these parameters are different from IPport in
  Via and Contact headers, then SIP proxy will
  replace wrong addresses

11
Our solution

• Our goals in this project
• To take one of existing SIP Proxies and upgrade
  it for NAT traversal according to third solution
  in previous slide
• To implement STUN aware SIP Client
• To use one of public STUN servers
• To create external SIP UA that will record all
  SIP clients that have public IP (They will be
  used as relays)
• To implement VoIP system based on the client
• To use JMF for multimedia session managing
• To implement all kinds of NAT using IP tables on
  Linux

12
System schematic
13
Dates

• 1/01/07 Finish design of Client application and
  External UA
• 15/01/07 Finish upgrading SIP proxy and
  implementing NAT on Linux
• 30/01/07 Finish implementing of Client
  application and External UA and start Debug stage
• 10/02/07 Finish the project