1 / 10

The NAT Traversal Problem in P2PSIP

The NAT Traversal Problem in P2PSIP. Bruce Lowekamp (SIPeerior) Philip Matthews (Avaya). NATs cause problems for P2PSIP overlays. NAT. NAT. NAT. About 90% of NATs will drop inbound packets for a peer unless there is a previously-established “connection” with the sender. NAT.

Download Presentation

The NAT Traversal Problem in P2PSIP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The NAT Traversal Problemin P2PSIP Bruce Lowekamp (SIPeerior) Philip Matthews (Avaya)

  2. NATs cause problems for P2PSIP overlays NAT NAT NAT About 90% of NATs will drop inbound packets for a peer unless there is a previously-established “connection” with the sender. NAT

  3. NAT Traversal vs. Msg Type • P2PSIP will have (at least) 3 different message types: • Peer/Client Protocol msgs • SIP msgs • RTP (or other media transport protocol) msgs • For RTP (or other media protocol), use ICE and STUN to establish direct media stream • For SIP and Peer/Client Protocol msgs, problem is more complex. Here, two solutions have been proposed: • The “superpeer” approach • The “fully-distributed” approach • These solutions provide traversal and/or routing for peer/client and SIP messages across the overlay and can provide relay for RTP if needed.

  4. The “Superpeer” solution O S O NAT S O NAT S Peers with public IP addresses and other ‘good’ properties are promoted to “superpeers” (S). These peers can freely exchange messages with each other. Each “ordinary peer” (O) establishes a Peer Protocol connection to an ordinary peer. These peers can exchange messages directly with its superpeer, and indirectly with other peers with the help of its superpeer. NAT O NAT O

  5. The “Fully-Distributed” approach NAT NAT Each peer establishes a small number of Peer Protocol connections to other peers (a partial mesh). A message may traverse multiple hops to get to its destination. NAT NAT

  6. D C B A X Example: Fully-Distributed approach w/ Chord • Chord uses exponentially spaced entries in finger table. • Each peer uses “greedy routing” to route a message to its neighbor that is closest to the final destination. • Establish connections through NATs to make connection table match DHT routing.

  7. INVITE Using ICE to Open New Connections Initially inbound connections are rejected Proxy INVITE with ICE sdp through established connection to establish new {peer protocol, SIP, RTP} connection New connection now established NAT 1 3 2 NAT

  8. Superpeer Establish connections with an Outbound-like scheme? (Pro) “Classic” scheme used by many P2P systems today (Con) Requires there be enough peers eligible for superpeer status. May limit DHT to superpeers? Need mechanism to assign ordinary peers to superpeers Fully-Distributed Establish connections using SIP signaling with ICE. (Con) No operational experience w/ approach. (Pro) No requirement that some peers have public IP addresses. (Pro) No limits on DHT participation? (Con) May require up to Log2 N hops. Comparison of approaches

  9. More on Routing (either approach) • Direct Routing. • Send msg directly to destination. May work in some cases. • Recursive Routing • Send msg to neighbor nearest to destination. Ask neighbor to forward msg for you. • Iterative Routing • Send msg to neighbor nearest to destination. Neighbor replies with a redirect to another peer U. • Use direct or recursive routing to set up a connection to peer U. • Repeat.

  10. Establishing a Peer Protocol Connection Peer Y Peer X Peer U Peer V INVITE (To:Y; R-D:Proxy) 200 OK ACK ICE Connnectivity Checks Direct PeerProtocol Connection Established INVITE (Replaces) 200 OK ACK BYE 200 OK [See draft-matthews-p2psip-bootstrap-mechanisms for how first connection might be established.]

More Related