This document discusses advanced peer-to-peer SIP concepts and NAT traversal techniques. It describes how P2P services like call forwarding, voicemail, and music on hold can be implemented within a P2P overlay network or with help from peer nodes. It also covers challenges of NAT traversal and evaluates solutions like STUN, TURN, ICE, and HIP that aim to establish media connections through NATs and firewalls. Testing methods are important to prove the effectiveness of NAT traversal approaches.

1. P2P SIP Tutorial Part 3: Advanced P2P SIP and NAT Traversal Henry Sinnreich Alan Johnston March 17, 2008

2. Advanced CS SIP SIP Call Control 3pcc Replaces Join SIP Events SUBSCRIBE/NOTIFY Event packages: MWI, refer, registration, etc. SIP Conferencing Media mixing Isfocus Conference package NAT and FW Traversal STUN, TURN, and ICE SIP media helpers Tunnels HIP NAT traversal SIP Services SIP Telephony Services Location Services Emergency Services Presence Services Mobility Services

3. P2P services easily implemented in an endpoint Hold – re-INVITE with held media Call Waiting – UA provides incoming call indication for user Caller ID – use From and Identity header field Transfers – using REFER Intercom, Auto Answer, Hotline – use Answer-Mode header field Three Way Calling, Conference Call – UA does local media mixing – limitation is bandwidth Distinctive Ring – use Alert-Info header field Call Screening, Do Not Disturb – UA accepts or rejects INVITEs using Identity and From Click to Dial – use REFER

4. P2P services with help of peers Call Forwarding – Neighbor nodes to UA provide forwarding URI or Peer node. Call Park – UA REFERs other party to another Peer UA who holds the call. Call Pickup – UA uses INVITE Replaces to pickup call at another Peer UA. Voicemail – If UA is not available, nearest Peer in Overlay plays greeting, records voicemail and stores for UA. Message Waiting Indication – Peer UA sends NOTIFY to UA when it rejoins Overlay Music on Hold – UA REFERs other party to another Peer UA who streams the music. Single Line Extension – Use dialog package for UAs in the group to discover status, and Join to conference.

5. Overlay Example Peer A Peer B 3. Admitting Peer acts as Rendezvous to establish Connection between Joining Peer and B 4. B acts as Rendezvous to establish connection between Joining Peer and A. Peer A 4. B acts as Rendezvous to establish connection between Joining Peer and A. Bootstrap Server Joining Peer 1. Joining Peer connects to Bootstrap Server to join the overlay Admitting Peer 2. Bootstrap Server acts as Rendezvous to establish connection between Joining Peer and Admitting Peer Peer B 3. Admitting Peer acts as Rendezvous to establish Connection between Joining Peer and B Peer A 4. B acts as Rendezvous to establish connection between Joining Peer and A.

6. Call forwarding in an overlay example Peer A is not present and has calls forwarded to a TN Caller Outside Overlay Peer C 2. Peer C routes the INVITE towards Peer A Peer B 3. INVITE request lands at Peer B which is the “closest” to the missing Peer A. 4. Peer B provides call forwarding information back to Peer C. Forwarded TN Outside Overlay 5. Peer C proxies the INVITE to Forwarded TN or redirects Caller to Forwarded TN. SIP RTP 1. Outside Caller calls Peer A and sends INVITE which is routed into the Overlay. SIP

7. Voicemail in an overlay example Peer A is not present and has voicemail provided by another peer. Caller Outside Overlay 2. Peer C routes the INVITE towards Peer A Peer B 3. INVITE request lands at Peer B which is the “closest” to the missing Peer A. 4. Peer B answers call, plays prompt and records voicemail message. INVITE/200 OK/ACK RTP or SRTP Peer C 1. Outside Caller calls Peer A and sends INVITE which is routed into the Overlay. SIP

8. Voicemail retrieval in an overlay example Peer B has left overlay 3. Peer A establishes media session with Peer D and retrieves voicemail message. SIP RTP or SRTP 2. Peer A contacts Peer D and receives MWI indication Peer D 1. Peer A rejoins Overlay

9. NAT Traversal

10. Generic Requirements Success ratio: Some % or always Delay for signaling and media Sever bandwidth consumption for media Test tools & analytics to prove the above Test tools for help desk

11. Overview of NAT Traversal Solutions Work in progress ID: hip-nat-traversal – is a HIP WG item Works for all apps Yes 2 Some Yes HIP Open Source No 100% Yes openVPN Commercial, deployed Forbidden 100% Yes Tunnels Different for each app Yes 1 Some No ICE/TURN Commercial, deployed No No No SIP RTP Relay Valuable tools Yes 1 No No STUN Comments IETF Bandwidth Works 100% Solution

12. Refresher: Using SIP signaling and RTP media Discover the remote (called) party Negotiate session params (codecs, etc.) Establish session Modify session End session Services Telephony (PBX-like, for agents, etc.) Presence IM Conferences Chat rooms SIP can provide the applications (services) “ in the network ” using servers, or P2P XMPP and H.323 services are only “ in the network ” 1 REGISTER 2 INVITE SIP Srv SIP Srv SIP UA SIP UA sip:alice@atlanta.com sip:bob@biloxi.com DNS biloxi.com? IP Bob? Loc DB IP of Bob 3 INVITE 4 INVITE 5 RTP voice, video, text

13. The ugly, later parts in SIP NAT impedes Internet transparency Session border controllers breaks transparency VoIP and IM networks are closed vertical stacks (pay for roaming, hide from competitor, emulate telephone net) The broken SIP architecture* *I-D:draft -ietf-sipping-sbc-funcs Legend: NAT: Network address translation SBC: Session border controller SIP Srv SIP Srv SIP UA SIP UA sip:alice@atlanta.com sip:bob@biloxi.com DNS biloxi.com? IP Bob? Loc DB IP of Bob RTP media NAT NAT SBC SBC Internet SBC SBC SIP

14. NAT traversal drives VoIP design (no SBC assumed) ISP network Residential NAT SIP UAs must connect to each other through all NATs ISP network Residential NAT NAT NAT Internet Public IP Address Realm Enterprise network NAT Residential NAT Home network Home network ISP NAT Residential NAT Home network Home network hairpin interdomain NAT Multi homed

15. Failure scenarios with NAT Ref: <draft-ietf-sipping-nat-scenarios> Client Proxy NAPT 5650 (open) (5060) SIP Request SIP Response The SIP/UDP request contains in Via or ‘received’ (added by a proxy) the IP or port of the client inside the NAT. 5060 Client Proxy NAT (5060) REGISTER/response INVITE The SIP/TCP REGISTER will work correctly, but an incoming INVITE later will attempt to use a new TCP connection to the registered entity and fail. The failure can be avoided by re-using the initial TCP connection. 8023 Client Client NAT SDP offer/exchange (RFC 3264) is attempted, but since SIP is providing the internal addresses of the client, the RTP flow fails. NAT SIP signaling RTP RTP

16. NAT has to “BEHAVE” (UDP) Here are the requirements: RFC 4787: NAT Behavioral Requirements Here is what has been found: http://ietf.org/internet-drafts/draft-jennings-behave-test-results-04.txt NAT behaviors 1. Endpoint Independent (good) X1’:x1’ = X2’:x2’ for all Y:y 2. Address Dependent (bad) X1’:x1’ = X2’:x2’ only if Y2=Y1 3. Address & Port Depending (worst) X1’:x1’ = X2’:x2’ only if Y2:y2=Y1:y2 Requirements to ‘BEHAVE’ Endpoint independent IP address pooling Port assignment behavior No port overloading Port parity preservation Port contiguity (multiple apps) Outbound mapping refresh Device NAT Host Host X:x X:x X1’:x1’ X2’:x2’ Y1:y1 Y2:y2 X NAT Y1 Y2 Internal External Legend X;x = IP:port

17. Tunneling for NAT and Firewall Traversal 1. http://www.iana.org/assignments/port-numbers 2. http://www.microsoft.com/technet/prodtechnol/exchange/2003/security.mspx 3. draft-lear-iana-no-more-well-known-ports-01.txt Examples of well known 1 (reserved) ports: 0 to1,024, or use DNS SRV 3 . Tunneling various protocols “under false name” (such as port 80) Tunneling violations are a security risk that may invite deep packet inspection But deep packet inspection by service providers may be a privacy violation Right approach: Cooperation with the IT department and ISPs to use HTTP tunneling Port numbers range from 0 to 65536 Port 80 is most often used for tunneling and should be blocked for IPSec w. Firewall 2. along with other unused ports SIP/TLS 5061 HTTP 80 DNS 53 SMTP 25 Telnet 23 File Transfer 19-21 Protocol Port Number

18. The hole punching approach B. Ford et al: “Peer-to-Peer Communication Across Network Address Translators” http://www.brynosaurus.com/pub/net/p2pnat/

19. NAT check test method Test method for UDP Ping to servers 1 and 2 OK if both report the same public IP address Srv2 reports IP to Srv3 which pings the client. OK if ping is seen by client. 2 nd UDP port to check the hairpin translation of the NAT Test method for TCP Similar, but using SYN and TCP timeouts B. Ford et al: “Peer-to-Peer Communication Across Network Address Translators” http://www.brynosaurus.com/pub/net/p2pnat/ Srv1 Srv2 Srv3 1st UDP port 2nd UDP port Client Internet NAT Private Network X

20. NAT support for UDP and TCP hole punching http://www.brynosaurus.com/pub/net/p2pnat/ 380 data points w. NAT from 68 vendors (13%) 37/286 (64%) 184/286 (24%) 80/335 (82%) 310/380 All Vendors (100%) 1/1 (67%) 2/3 (50%) 3/6 (78%) 7/9 FreeBSD (8%) 2/24 (67%) 16/24 (12%) 3/25 (81%) 26/32 Linux (90%) 28/31 (52%) 16/31 (34%) 11/32 (94%) 31/33 Windows OS-based NAT (0%) 0/6 (83%) 5/6 (14%) 1/7 (100%) 7/7 3Com (0%) 0/7 (0%) 0/7 (13%) 1/8 (78%) 7/9 ZyXEL (22%) 2/9 (89%) 8/9 (30%) 3/10 (100%) 12/12 SMC (29%) 2/7 (86%) 6/7 (33%) 3/9 (100%) 12/12 Cisco (0%) 0/11 (100%) 11/11 (7%) 1/14 (100%) 14/14 Belkin (0%) 0/7 (29%) 2/7 (25%) 3/12 (12%) 2/17 Draytek (11%) 2/19 (47%) 9/19 (52%) 11/21 (76%) 16/21 D-Link (0%) 0/30 (63%) 19/30 (9%) 3/35 (84%) 31/37 Netgear (8%) 3/38 (87%) 33/38 (12%) 5/42 (98%) 45/46 Linksys NAT Hardware Hairpin Punching Hairpin Punching Hole Hole TCP UDP

21. Testing for NAT traversal Believing in a NAT traversal approach without testing resembles religion RFC 4787: “NAT Behavioral Requirements for UDP” shows that several Internet IP addresses are required for testing single layer NAT Multilayer NAT require test servers in every layer. This may be hard to implement Several NAT test tools are available Nat Check for P2P http://midcom-p2p.sourceforge.net/ Microsoft Internet Connectivity Evaluation Tool for basic full cone NAT test http://www.microsoft.com/windows/using/tools/igd/default.mspx Required for proof: Large scale testing over the Internet using a web site Required for customer support: NAT diagnostic tool UDP testing: http://www.brynosaurus.com/pub/net/p2pnat TCP testing: http://www.guha.cc/saikat/pub/imc05-tcpnat.pdf / New from the IETF and important: Using STUN: http://ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-01.txt

22. Managing client initiated SIP connections (SIP outbound) Outbound scenario UA registers via SIP proxy 1 UA has the instance-id (AOR) Flow via proxy has the reg-id STUN keepalives monitor the flow Flow has failed (UA, NAT reboots, etc.) UA replaces old flow Old instance-id and new reg-id Incoming requests go to any proxy Last registration is used first Meets complex list of requirements Q: How does this work in P2PSIP? http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-12.txt UA Proxy 2 Proxy 1 Registrar instance-id (sip.instance) reg-id Incoming request to any proxy NAT/FW STUN bindings for keepalives

23. Symmetric response routing Ref: RFC 3581: “Symmetric Response Routing” 10.1.1.1:4540 192.0.2.1:9988 INVITE INVITE 200 OK 200 OK INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff UA NAT Proxy UA NAT Proxy UA NAT Proxy

24. STUN: Session Traversal Utilities for NAT (is still work in progress*) * http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489 bis-11 .txt Binding request scenario Client makes binding request Server returns the external (mapped address) The mapped address is used in SIP requests (INVITE, OK). XOR-mapped (with 16 bits of magic cookie) is used to avoid IP address changes in various intermediaries Shared secret request scenario Short term credentials during a session Long term credentials; provisioned Mechanisms: For DNS aided STUN server discovery, redirection to alternate server, fingerprints, 2 credential modes (short/long term) STUN Client NAT1 NAT2 STUN Server Internal IP address/port Reflexive IP address/port XOR-mapped address/port Server address is provisioned or discovered w. DNS SRV STUN can be collocated w. other servers

25. STUN usages I-D.nat-control-stun-usage Discovering, Querying, and Controlling Firewalls and NATs 4 I-D.ietf-behave-nat-behavior-discovery NAT Behavior Discovery 3 I-D.ietf-sip-outbound Client-initiated connections for SIP 2 I-D.ietf-mmusic-ice Interactive Connectivity Establishment (ICE) 1

26. NAT behavior discovery using STUN http://ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-01.txt See if the MAPPED-ADDRESS and XOR-MAPPED-ADDRESS do not match Detecting generic ALGs … that hunt and rewrite IP addresses PADDING only applies to UDP datagrams and can not be used with XOR-RESPONSE-ADDRESS (problem) Fragment handling No hairpin for fragments or discard The client then sends a STUN Binding Request to this mapped address from a different port. If the client receives its own request, the NAT hairpins OK NAT hairpinning Whether it is behind a NAT that supports hairpinning of connections Timed tests using a 2 nd STUN address to check if an existing binding that hasn't had traffic sent on it is still open after time T Binding lifetime Keepalive messages must be sent across the connection to preserve it Tests request responses from the alternate address and port of the STUN server; a precondition to these tests is that no binding be established to the alternate address and port NAT filtering Independent filtering, address dependent filtering, or address and port dependent filtering Binding requests to alternate STUN transport addresses. UDP, TCP, TCP/TLS NAT mapping type Independent, address dependent, or port dependent mapping

27. Discovery, query and control of NAT and FW http://ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-usage-05.txt Multilevel NAT discovery, if NAT has embedded STUN server STUN client NAT A NAT B STUN server 1 st binding request-response Learn NAT B 2nd binding request-response Learn NAT A and it is the last 3rd binding request-response Hairpining reduces the keepalive traffic outside (does not work for UDP fragments). Improves ICE.

28. RTP Media Relay and SIP Media Proxy Similar from iptel.org and ag-projects.com SIP server has same info as STUN provides Like a “server side” STUN action No STUN message exchange No ICE in SIP UA High success ratio inside the same SIP domain Widely implemented by small ISPs SIP signaling SIP UA SIP Server NAT NAT Internet RTP Relay RTP Media Control Link SIP UA

29. Interactive Connectivity Establishment (ICE) scenario Send candidates to remote agent draft-ietf-mmusic-ice-17 SIP signaling Agent L SIP Srvr NAT Agent R NAT Relayed Candidate Sever Reflexive Candidate Host Candidate STUN Srvr Internet

30. Traversal Using Relays around NAT (TURN) draft-ietf-behave-turn-04.txt Only for address/port dependent “bad” NATs – relays are expensive (BW) and add delay to voice (over) simplified call flow has 24 messages STUN Client STUN/TURN Relay External Client Client requesting allocations Internal remote transport address Internal local transport address External local transport address Internal remote transport address Internal 5-tuple External 5-tuple binding binding binding NAT

31. Host Identity Protocol (HIP) Works for all apps Separates locator from identifier role Host Identity (HI) based on public key pair (128 bits) ESP SAs (like VPN) Mobility Multi-homing NAT traversal Rendezvous server resembles STUN Compatible w. IPv6 Free code Ref: http://tools.ietf.org/html/rfc4423, http://infrahip.hiit.fi/index.php?index=how Separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes App Transport IP layer Link layer IP address IP, port App Transport Host Identity IP layer Link layer IP address Host ID Host ID, port

32. HIP base exchange with a rendezvous server “ HIP Rendezvous Extension” I-D: draft-ietf-hip-rvs by J.Laganier and L. Eggert RVS I R I1 I1 R1 I2 R2

33. B: HIP for P2P SIP (in random order) HIP DHT Interface by J. Ahrenholz, ID: draft-ahrenholz-hiprg-dht-01 A Distributed Transport Function in P2PSIP using HIP for Multi-Hop Overlay Routing by E. Cooper et al., ID: draft-matthews-p2psip-hip-hop HIP Extensions for the Traversal of Network Address Translators by M. Komu et al., ID: draft-ietf-hip-nat-traversal Utilizing HIP for SIP by J. Hautakorpi et al. ID: draft-hautakorpi-p2psip-with-hip Avaya Boeing Ericsson HIIT NEC

34. Summary of IETF NAT traversal for SIP and RTP C. Boulton: “NAT Scenarios” I-D STUN keep alive messages Timers in NAT close the bindings Timers in NAT ICE Symmetric RTP doesn’t work TURN relay STUN doesn’t work with IP address/port depending mapping RFC 3489bis: STUN UA doesn’t know address outside of NAT RFC 3605: Extension to SDP for explicit RTCP port negotiation using new attribute “a=rtcp” RTCP port=RTP port+1 breaks down when NAT ports are occupied “ Symmetric RTP is Helpful” Inbound and outbound IP addresses are different RTP/RTCP Media Transport Connection Reuse “sip-outbound” SIP/TCP fails in reverse direction through NAT. Keepalives. RFC 3581: Change to Via with “rport” Symmetric Response SIP/UDP: Via shows internal address behind NAT SIP Signaling Solutions Problem Category Consumer UA profile Primary UA profile

35. Skype NAT Traversal http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-039-04.pdf http://saikat.guha.cc/pub/iptps06-skype.pdf NAT traversal always works and blocking is difficult No media relays: TURN-like fallback using a supernode on the Internet Relay supernodes have small average traffic STUN-like testing determines type of NAT Hole punching with STUN like approach

36. NAT Traversal research has the latest insight NUTSS: A SIP-based Approach to UDP and TCP Network Connectivity by. S Guha et al. http://www.sigcomm.org/sigcomm2004/workshop_papers/fdna02-guha1.pdf NUTSS Tutorial http://www.csie.ntu.edu.tw/~acpang/course/voip_2005/report/419_2.pdf The state of the art NAT issues

37. Questions and discussion