Sinnreich Henry Johnston Alan Pt 3


Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Sinnreich Henry Johnston Alan Pt 3

  1. 1. P2P SIP Tutorial Part 3: Advanced P2P SIP and NAT Traversal Henry Sinnreich Alan Johnston March 17, 2008
  2. 2. Advanced CS SIP <ul><li>SIP Call Control </li></ul><ul><ul><li>3pcc </li></ul></ul><ul><ul><li>Replaces </li></ul></ul><ul><ul><li>Join </li></ul></ul><ul><li>SIP Events </li></ul><ul><ul><li>SUBSCRIBE/NOTIFY </li></ul></ul><ul><ul><li>Event packages: MWI, refer, registration, etc. </li></ul></ul><ul><li>SIP Conferencing </li></ul><ul><ul><li>Media mixing </li></ul></ul><ul><ul><li>Isfocus </li></ul></ul><ul><ul><li>Conference package </li></ul></ul><ul><li>NAT and FW Traversal </li></ul><ul><ul><li>STUN, TURN, and ICE </li></ul></ul><ul><ul><li>SIP media helpers </li></ul></ul><ul><ul><li>Tunnels </li></ul></ul><ul><ul><li>HIP NAT traversal </li></ul></ul><ul><li>SIP Services </li></ul><ul><ul><li>SIP Telephony Services </li></ul></ul><ul><ul><li>Location Services </li></ul></ul><ul><ul><li>Emergency Services </li></ul></ul><ul><ul><li>Presence Services </li></ul></ul><ul><ul><li>Mobility Services </li></ul></ul>
  3. 3. P2P services easily implemented in an endpoint <ul><li>Hold – re-INVITE with held media </li></ul><ul><li>Call Waiting – UA provides incoming call indication for user </li></ul><ul><li>Caller ID – use From and Identity header field </li></ul><ul><li>Transfers – using REFER </li></ul><ul><li>Intercom, Auto Answer, Hotline – use Answer-Mode header field </li></ul><ul><li>Three Way Calling, Conference Call – UA does local media mixing – limitation is bandwidth </li></ul><ul><li>Distinctive Ring – use Alert-Info header field </li></ul><ul><li>Call Screening, Do Not Disturb – UA accepts or rejects INVITEs using Identity and From </li></ul><ul><li>Click to Dial – use REFER </li></ul>
  4. 4. P2P services with help of peers <ul><li>Call Forwarding – Neighbor nodes to UA provide forwarding URI or Peer node. </li></ul><ul><li>Call Park – UA REFERs other party to another Peer UA who holds the call. </li></ul><ul><li>Call Pickup – UA uses INVITE Replaces to pickup call at another Peer UA. </li></ul><ul><li>Voicemail – If UA is not available, nearest Peer in Overlay plays greeting, records voicemail and stores for UA. </li></ul><ul><li>Message Waiting Indication – Peer UA sends NOTIFY to UA when it rejoins Overlay </li></ul><ul><li>Music on Hold – UA REFERs other party to another Peer UA who streams the music. </li></ul><ul><li>Single Line Extension – Use dialog package for UAs in the group to discover status, and Join to conference. </li></ul>
  5. 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. 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. 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. 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. 9. <ul><li>NAT Traversal </li></ul>
  10. 10. Generic Requirements <ul><li>Success ratio: Some % or always </li></ul><ul><li>Delay for signaling and media </li></ul><ul><li>Sever bandwidth consumption for media </li></ul><ul><li>Test tools & analytics to prove the above </li></ul><ul><li>Test tools for help desk </li></ul>
  11. 11. Overview of NAT Traversal Solutions <ul><li>Work in progress </li></ul><ul><li>ID: hip-nat-traversal – is a HIP WG item </li></ul>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. 12. Refresher: Using SIP signaling and RTP media <ul><li>Discover the remote (called) party </li></ul><ul><li>Negotiate session params (codecs, etc.) </li></ul><ul><li>Establish session </li></ul><ul><li>Modify session </li></ul><ul><li>End session </li></ul><ul><li>Services </li></ul><ul><ul><li>Telephony (PBX-like, for agents, etc.) </li></ul></ul><ul><ul><li>Presence </li></ul></ul><ul><ul><li>IM </li></ul></ul><ul><ul><li>Conferences </li></ul></ul><ul><ul><li>Chat rooms </li></ul></ul><ul><li>SIP can provide the applications (services) “ in the network ” using servers, or P2P </li></ul><ul><li>XMPP and H.323 services are only “ in the network ” </li></ul>1 REGISTER 2 INVITE SIP Srv SIP Srv SIP UA SIP UA DNS IP Bob? Loc DB IP of Bob 3 INVITE 4 INVITE 5 RTP voice, video, text
  13. 13. The ugly, later parts in SIP <ul><li>NAT impedes Internet transparency </li></ul><ul><li>Session border controllers breaks transparency </li></ul><ul><li>VoIP and IM networks are closed vertical stacks </li></ul><ul><li>(pay for roaming, hide from competitor, emulate telephone net) </li></ul>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 DNS IP Bob? Loc DB IP of Bob RTP media NAT NAT SBC SBC Internet SBC SBC SIP
  14. 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. 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. 16. NAT has to “BEHAVE” (UDP) Here are the requirements: RFC 4787: NAT Behavioral Requirements Here is what has been found: 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 <ul><li>Requirements to ‘BEHAVE’ </li></ul><ul><li>Endpoint independent </li></ul><ul><li>IP address pooling </li></ul><ul><li>Port assignment behavior </li></ul><ul><ul><li>No port overloading </li></ul></ul><ul><ul><li>Port parity preservation </li></ul></ul><ul><ul><li>Port contiguity (multiple apps) </li></ul></ul><ul><li>Outbound mapping refresh </li></ul>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. 17. Tunneling for NAT and Firewall Traversal 1. 2. 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. 18. The hole punching approach B. Ford et al: “Peer-to-Peer Communication Across Network Address Translators”
  19. 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” Srv1 Srv2 Srv3 1st UDP port 2nd UDP port Client Internet NAT Private Network X
  20. 20. NAT support for UDP and TCP hole punching 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. 21. Testing for NAT traversal <ul><li>Believing in a NAT traversal approach without testing resembles religion </li></ul><ul><li>RFC 4787: “NAT Behavioral Requirements for UDP” shows that several Internet IP addresses are required for testing single layer NAT </li></ul><ul><ul><ul><li>Multilayer NAT require test servers in every layer. This may be hard to implement </li></ul></ul></ul><ul><li>Several NAT test tools are available </li></ul><ul><ul><li>Nat Check for P2P </li></ul></ul><ul><ul><li>Microsoft Internet Connectivity Evaluation Tool for basic full cone NAT test </li></ul></ul><ul><li>Required for proof: Large scale testing over the Internet using a web site </li></ul><ul><li>Required for customer support: NAT diagnostic tool </li></ul>UDP testing: TCP testing: / New from the IETF and important: Using STUN:
  22. 22. Managing client initiated SIP connections (SIP outbound) <ul><li>Outbound scenario </li></ul><ul><li>UA registers via SIP proxy 1 </li></ul><ul><ul><li>UA has the instance-id (AOR) </li></ul></ul><ul><ul><li>Flow via proxy has the reg-id </li></ul></ul><ul><li>STUN keepalives monitor the flow </li></ul><ul><li>Flow has failed (UA, NAT reboots, etc.) </li></ul><ul><ul><li>UA replaces old flow </li></ul></ul><ul><ul><li>Old instance-id and new reg-id </li></ul></ul><ul><li>Incoming requests go to any proxy </li></ul><ul><li>Last registration is used first </li></ul><ul><li>Meets complex list of requirements </li></ul><ul><li>Q: How does this work in P2PSIP? </li></ul> UA Proxy 2 Proxy 1 Registrar instance-id (sip.instance) reg-id Incoming request to any proxy NAT/FW STUN bindings for keepalives
  23. 23. Symmetric response routing Ref: RFC 3581: “Symmetric Response Routing” INVITE INVITE 200 OK 200 OK INVITE SIP/2.0 Via: SIP/2.0/UDP;rport;branch=z9hG4bKkjshdyff INVITE SIP/2.0 Via: SIP/2.0/UDP;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP;received=;rport=9988 ;branch=z9hG4bKkjshdyff SIP/2.0 200 OK Via: SIP/2.0/UDP;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP;received=;rport=9988 ;branch=z9hG4bKkjshdyff SIP/2.0 200 OK Via: SIP/2.0/UDP;received=;rport=9988 ;branch=z9hG4bKkjshdyff UA NAT Proxy UA NAT Proxy UA NAT Proxy
  24. 24. STUN: Session Traversal Utilities for NAT (is still work in progress*) * bis-11 .txt <ul><li>Binding request scenario </li></ul><ul><li>Client makes binding request </li></ul><ul><li>Server returns the external (mapped address) </li></ul><ul><li>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 </li></ul><ul><li>Shared secret request scenario </li></ul><ul><li>Short term credentials during a session </li></ul><ul><li>Long term credentials; provisioned </li></ul>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. 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. 26. NAT behavior discovery using STUN 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. 27. Discovery, query and control of NAT and FW 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. 28. RTP Media Relay and SIP Media Proxy <ul><li>Similar from and </li></ul><ul><li>SIP server has same info as STUN provides </li></ul><ul><li>Like a “server side” STUN action </li></ul><ul><li>No STUN message exchange </li></ul><ul><li>No ICE in SIP UA </li></ul><ul><li>High success ratio inside the same SIP domain </li></ul><ul><li>Widely implemented by small ISPs </li></ul>SIP signaling SIP UA SIP Server NAT NAT Internet RTP Relay RTP Media Control Link SIP UA
  29. 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. 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. 31. Host Identity Protocol (HIP) <ul><li>Works for all apps </li></ul><ul><li>Separates locator from identifier role </li></ul><ul><li>Host Identity (HI) based on public key pair (128 bits) </li></ul><ul><li>ESP SAs (like VPN) </li></ul><ul><li>Mobility </li></ul><ul><li>Multi-homing </li></ul><ul><li>NAT traversal </li></ul><ul><li>Rendezvous server resembles STUN </li></ul><ul><li>Compatible w. IPv6 </li></ul><ul><li>Free code </li></ul>Ref:, 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. 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. 33. B: HIP for P2P SIP (in random order) <ul><li>HIP DHT Interface by J. Ahrenholz, ID: draft-ahrenholz-hiprg-dht-01 </li></ul><ul><li>A Distributed Transport Function in P2PSIP using HIP for Multi-Hop Overlay Routing by E. Cooper et al., ID: draft-matthews-p2psip-hip-hop </li></ul><ul><li>HIP Extensions for the Traversal of Network Address Translators by M. Komu et al., ID: draft-ietf-hip-nat-traversal </li></ul><ul><li>Utilizing HIP for SIP by J. Hautakorpi et al. </li></ul><ul><li>ID: draft-hautakorpi-p2psip-with-hip </li></ul>Avaya Boeing Ericsson HIIT NEC
  34. 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. 35. Skype NAT Traversal <ul><li>NAT traversal always works and blocking is difficult </li></ul><ul><li>No media relays: TURN-like fallback using a supernode on the Internet </li></ul><ul><li>Relay supernodes have small average traffic </li></ul><ul><li>STUN-like testing determines type of NAT </li></ul><ul><li>Hole punching with STUN like approach </li></ul>
  36. 36. NAT Traversal research has the latest insight NUTSS: A SIP-based Approach to UDP and TCP Network Connectivity by. S Guha et al. NUTSS Tutorial The state of the art NAT issues
  37. 37. Questions and discussion