1. Running SIP behind NAT Dr. Christian Stredicke, snom technology AG Tokyo, Japan, Oct 22 th 2002

2. V1.0 2 Overview Problem Description STUN: Using Legacy Equipment TURN: Fixing Remaining Problems UPnP: Remote Control for Routers Application Layer Gateways 1 2 3 4 5 Remaining Problems & Solutions6

3. V1.0 3 Which information does a client has to set up for port forwarding in NAT equipment? Router needs information where to send packets in private network –Map port to private address and port –By default packets will be rejected or sent to DMZ Router needs hint for security checking –Accept packets from any destination –Accept packets only from associated host –Accept packets only from associated host and port 123.123.123.123 192.168.0.1 Router Client

4. V1.0 4 How did other applications solve the problem? HTTP, telnet, … –Using TCP DNS, others –“Digging holes”: Set up association when client sends out packet from unmapped port for 15-60 seconds –Security policy hardwired by vendor –Some offer a DNS proxy (application layer gateway) ftp –Does not work! –Inexperienced users use http instead –Some routers offer applications layer gateway Heterogeneous environment –Every vendor does it in a different way –“Digging holes” is common denominator

5. V1.0 5 snom STUN uses the digging hole trick to set up port associations Initialization procedure checks environment –Goal: Check if STUN is needed –Type of NAT does actually not really matter because user is not interested in failure reason SIP port kept alive by sending packets every 15-60 s RTP ports are allocated dynamically when starting a call –Otherwise keep-alive traffic would be double –RTCP port can not be allocated because next port allocation is unlikely –Long ringing and putting caller on hold is problematic (no port refresh during this time)

6. V1.0 6 In cases when NAT is symmetrical, TURN could be a solution 123.123.123.123 192.168.0.1 Router Client STUN/TURN Server 124.124.124.124 1. Allocate Request/Response 2. Activate Request/Response 3. SIP/Media

7. V1.0 7 TURN works in symmetrical NAT environment, but has too many problems Scalability –TURN server becomes “media server” –Every call generates about 50 packets per second Delay –Sending packets over media server increases transport delay significantly –E.g. local call in Tokyo when TURN server is in Frankfurt TURN specification –Needs rework (activation message not defined)

8. V1.0 8 UPnP is the right approach Generic protocol to allocate ports on router –Works with SIP, can be used with other applications as well –Can be integrated with firewalls –Not too hard to implement Microsoft Messenger uses UPnP –“De facto standard” –Virtually all DSL router vendors offer UPnP now Problem: Old Equipment –Use STUN –Maybe use TURN, even if call duration is terrible –Instruct customers to set up ports manually

9. V1.0 9 With the increasing availability of UPnP, most home customers can be addressed UPnP STUN UPnP STUN 20022003 Software Updates New Equipment

10. V1.0 10 Application layer gateways (ALG) solve the problem in the business area Business customers have different requirements than home users –Many phones –Want to run proxies, media servers, application servers behind their firewall –These applications probably will not have UPnP or STUN Therefore, firewalls will probably include SIP-aware ALG Sample SIP NAT ALG available from snom

11. V1.0 11 Calling phones in the same network requires ancillary information 1a) Phone A sends to public address of B 1b) Router will not forward packet, call will fail 2) A knows B is in the same NAT and sends packet to private address instead

12. V1.0 12 Ancillary information must be placed in contact URI and in SDP INVITE sip:info1@snomag.de SIP/2.0 Via: SIP/2.0/UDP 218.230.0.59:5060;branch=z9hG4bK-6rms4e9tmtsz Max-Forwards: 70 From: ;tag=16z5zw9lqt To: Call-ID: 0000a4f95f24-zzt41v6ulesj@218.230.0.59 CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 311 v=0 o=root 19211 19211 IN IP4 218.230.0.59 s=SIP Call c=IN IP4 218.230.0.59 t=0 0 m=audio 10004 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=private:192.168.0.4:10004 218.230.0.59:10004

13. V1.0 13 NAT2NAT3 NAT1 Multi-tier NAT requires a list of private addresses 192.168.0.1 192.168.0.2 10.0.0.310.0.0.2 10.0.0.1 123.123.123.123 A has three identities: 1. 192.168.0.2:5060 2. 10.0.0.2:1234 3. 123.123.123.123:5678 B has three identities: 1. 192.168.0.2:5060 2. 10.0.0.3:1234 3. 123.123.123.123:5679 STUN Phone APhone B When using STUN, a STUN server is required between the layers

14. V1.0 14 What is the status of snom products today? Latest snom 100 image includes UPnP and STUN –Support for single-tier NAT –TURN has been put out again snom 200 integration of UPnP and STUN snom 4S STUN/TURN server –Includes STUN and TURN (with extensions) –Security and TCP not implemented snom 4S proxy/location server adds STUN –Integrated STUN server –Gives user agents hint when they are behind NAT snom 4S media server –Smooth call termination when no media available snom 4S NAT gateway –Available for Linux

15. sip:info@snomag.de

16. © 2002 snom technology Aktiengesellschaft Written by: Dr. Christian Stredicke Version: 1.0 The author has made his best effort to prepare this document. The content is based upon latest information whenever possible. The author makes no representation or warranties of any kind with regard to the completeness or accuracy of the contents herein and accept no liability of any kind including but not limited to performance, merchantability, fitness for any particular purpose, or any losses or damages of any kind caused or alleged to be caused directly or indirectly from this document. For more information, mail info@snom.de, Pascalstr. 10E, 10587 Berlin, Germany.