| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 29, 2007.
Copyright © The IETF Trust (2007).
This document shows how the algorithm for resource registration and lookup in a SIP-based peer-to-peer system can be implemented in the presence of NATs. More precisely, this document show how this algorithm can be generalized into a method of routing arbitrary SIP requests through overlays, and how this approach can be used to set up new connections between peers to use for additional SIP signaling.
The document uses SIP to signal new dSIP connections, and uses Interactive Connectivity Establishment (ICE) to allow these connections to be established through NATs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
1.
Introduction
2.
Overview and Key Concepts
2.1.
Overview of the New Procedures
2.2.
ICE
2.3.
Connection Table
2.4.
Comparison of Iterative and Recursive Routing with NAT Traversal
2.4.1.
Iterative Routing
2.4.2.
Recursive Routing
2.4.3.
Relative Costs
3.
Establishing and Maintaining dSIP Connections
4.
Routing a SIP Request through the Overlay
4.1.
Sending using Direct Routing
4.2.
Sending using either Recursive or Iterative Routing
4.2.1.
Forming and Sending the Request
4.2.2.
Handling the Request at a Receiving Peer
5.
Examples
5.1.
Routing a REGISTER Request using Recursive Routing
5.2.
Setting up a dSIP Connection using Recursive Routing
5.3.
Routing a REGISTER Request using Iterative Routing
6.
Possible Enhancement
7.
Security Considerations
8.
IANA Considerations
9.
Acknowledgments
10.
References
10.1.
Normative References
10.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
Network Address Translators (NATs) are a fact of life on the modern Internet. Some measurements have indicated that almost 74% of web-browsing clients on the global Internet are behind NATs [Illuminati] (Cadaco, M. and M. Freedman, “Illuminati - Opportunistic Network and Web Measurement,” February 2007.).
NATs cause problems for peer-to-peer systems because they make it difficult for two peers to communicate freely. First of all, the nature of address translation means that the local IP address of a peer Y behind a NAT is often not the address that another peer X needs to use to reach peer Y. Second, NATs typically provide a security function whereby the NAT in front of peer Y will typically block a packet sent by X to Y unless Y has recently sent a packet to X.
Many peer-to-peer systems work around this problem by dividing peers into two groups: those behind NATs (often called "ordinary peers") and those not behind NATs (often called "super peers"). These systems then establish a peer-to-peer relationship between super peers, while establishing a master-slave relationship between each ordinary peer and a super peer.
This approach works well if a large percentage of peers are not behind NATs. However, in some of the use-cases [P2PSIP‑Use‑Cases] (Bryan, D., Shim, E., and B. Lowekamp, “Use Cases for Peer-to-Peer Session Initiation Protocol (P2P SIP),” November 2005.) identified for P2PSIP, the percentage of peers not behind NATs may be very small. For example, a P2PSIP system in a "Managed, Private Network Environment" may consist of a number of peers, each one of which is behind its own NAT. In these cases, the ordinary peer / super peer approach scales poorly or breaks down entirely.
Another approach is to treat all peers as equal and establish long-lived connections between peers through the intervening NATs. In this approach, there is a partial mesh of connections between peers, which is used for routing messages flowing between peers. If peer X wants to send a message to peer Y, it can either send the message directly (if it has a direct connection), or send it indirectly through one or more intermediate peers. Alternatively, X can set up a new connection directly to Y, then send its message along that new connection.
For dSIP systems [dSIP‑Base] (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.), this second approach works well because dSIP already has the notion of connections between peers. And if the set of connections forms a structured partial mesh, as it does when Chord is used as the lookup algorithm [dSIP‑Chord] (Zangrilli, M. and D. Bryan, “A Chord-based DHT for Resource Lookup in P2PSIP,” February 2007.), this approach provides a very efficient way to organize peers such that every peer contributes equally to the routing and lookup functions of the overlay.
This document describes how to add NAT Traversal to dSIP using this approach of establishing a partial mesh of long-lived connections between peers. It describes how to set up a dSIP connection between two peers, and how to route SIP requests and responses through the resulting partial mesh of connections.
For more discussion on the problems that NATs cause for peer-to-peer systems and the various approaches to NAT Traversal for P2PSIP, see [BEHAVE‑P2P‑State] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs),” .), [NATs‑and‑Overlays] (Cooper, E. and P. Matthews, “The Effect of NATs on P2PSIP Overlay Architecture,” February 2007.) and [DHT‑for‑Communications] (Bryan, D., Zangrilli, M., and B. Lowekamp, “Challenges of DHT Design for a Public Communications System,” June 2006.).
| TOC |
This section provides a non-normative description of the procedures and data structures required to perform NAT traversal between P2PSIP peers. Normative text is found in subsequent sections. This section first describes the new procedures at a high-level and then discusses certain aspects of interest.
| TOC |
This document defines two procedures:
These two procedures are mutually recursive: setting up a dSIP connection requires the ability to route an INVITE request through the overlay, and routing a request can require new connections to be set up (depending on the routing method used).
Consider the case of a peer X in the overlay. Peer X is maintaining a table of current dSIP connections to other peers. Peer X now wishes to establish a new dSIP connection with peer Y. This connection may be intended as a long-term connection in the overlay as dictated by the DHT algorithm [dSIP‑Base] (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.), or it may be a connection needed for some short-term purpose.
Peer X sets up a new dSIP connection using SIP signaling. The standard SIP and SDP mechanisms for signaling a connection are used, with two exceptions. The first exception is that the SDP offer and answer does not specify RTP as the media stream, but instead specifies dSIP. How this is done is described in detail in Section 3 (Establishing and Maintaining dSIP Connections). The second exception is that the INVITE, and indeed all SIP requests, are not routed as described in [RFC3263] (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.) but are instead routed as described in this document.
A typical message exchange to establish a dSIP connection proceeds as follows. First, peer X creates an INVITE request. The SDP body of the INVITE specifies that the new connection will be a dSIP connection. The SDP body also contains ICE candidates so the connection can be established through intervening NATs. Peer X then sends the INVITE to peer Y, using the routing procedure described below. Peer Y responds with a 200 OK, which is then ACKed by peer X. Peer X and Y then use ICE to determine the candidate pair for the connection. At this point, the connection is established.
For short-term connections, nothing more needs to be done. However, for long-term connections, one endpoint (typically peer X) will send a new INVITE with a Replaces header down the new connection to establish a new dialog for the connection that involves only the two endpoints and not any other peers. If this was not done, and if one of those peers subsequently left the overlay, then the signaling path for the connection would be broken. (This idea was borrowed from [Bootstrap] (Cooper, E., Johnston, A., and P. Matthews, “Bootstrap Mechanisms for P2PSIP,” .) - see that document for more discussion on why peers want to do this).
When peer X sends the INVITE, or indeed any SIP request, to peer Y, it has three choices for how to route the request: direct routing, recursive routing, or iterative routing.
Direct routing is simply sending the request directly to peer Y without establishing a dSIP connection to Y first. This may or may not work, depending on the address that X has for Y and the filtering permissions installed in any intervening NATs.
Recursive routing is sending the request to a peer U to which X already has a dSIP connection, and requesting that U proxy the request onward towards Y. Peer U may or may not have a direct connection to peer Y; if it does not, it will need to send the request to another peer V which in turn proxies it onward until peer Y is reached. When proxying the request onward, each peer forwards the request to the peer in its connection table that is "closest" to the destination peer Y. This "closest" function is defined by the DHT algorithm used by the overlay. For example, in a DHT based on Chord, each peer U forward the request to the peer V in its connection table whose peer-ID is closest but not greater than peer Y's peer-ID.
Iterative routing is sending the request to a peer U and requesting that peer U reply with 302 Moved Temporarily specifying a closer peer V. In the presence of NATs, this technique is rather complex because peer X usually does not have a dSIP connection to V. So peer X must first set up a temporary dSIP connection to V and then send the request to V. (Setting up the temporary dSIP connection to V is done by sending the INVITE for the connection to peer U and requesting that it proxy it onward to peer V).
We discuss the pros and cons of iterative vs. recursive routing in Section 2.4 (Comparison of Iterative and Recursive Routing with NAT Traversal).
| TOC |
A variety of NAT traversal techniques have been created for Internet communications. Some involve changes in network devices and some are strictly endpoint-based mechanisms. The recommended technique [Sipping‑NAT‑Traversal] (Boulton, C., Ed., Rosenberg, J., and G. Camarillo, “Best Current Practices for NAT Traversal for SIP,” .) for SIP systems is Internet Connectivity Establishment [ICE] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” .). ICE is a technique for performing "NAT-hole-punching" [BEHAVE‑P2P‑State] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs),” .).
ICE is an especially attractive technique because it does not require the configuration of network devices and allows end-to-end encryption to be used. ICE has the added benefit of working in complex network topologies that may include multiple NATs.
ICE-enabled peers collect a number of addresses that might be useful for communicating with other peers. These addresses, referred to as candidates, commonly include the address of the peer's network interface as well as the publicly reachable address of the NAT the peer is behind (discovered via STUN [STUN‑bis] (Rosenberg, J., Huitema, C., Mahy, R., and D. Wing, “Simple Traversal Underneath Network Address Translators (NAT) (STUN),” .)). These candidates are exchanged with remote peers via an existing communication channel. Each peer then combines its own candidates with the remote candidates to create an ordered list of candidate pairs. The pairs are then tested in order until a working network path is discovered.
Given the uncertainty surrounding NAT behavior it is difficult to predict how often "NAT-hole-punching" can be successfully used for TCP and UDP transports, but [NAT‑Character] (Guha, S. and P. Francis, “Characterization and Measurement of TCP Traversal through NATs and Firewalls,” October 2005.) estimates an 88% success rate for TCP and a 100% success rate for UDP when certain common types of NAT devices are present.
| TOC |
In addition to the routing table entries required by the DHT algorithm, the connection table described in [dSIP‑Base] (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.) contains additional connections. These additional connections arise because a peer has connections that it originates to other peers (in its routing table), connections that other peers originate to it (in their routing table), and temporarily connections made to perform resource registrations and queries. Since connections are bi-directional, we do not distinguish between these two types of connections when routing requests. For example, Chord specifies that each peer stores routing table entries to other peers in the first half of the ring starting from itself [dSIP‑Chord] (Zangrilli, M. and D. Bryan, “A Chord-based DHT for Resource Lookup in P2PSIP,” February 2007.). In practice, however, the connection table will provide connections to peers distributed across the entire ring. Keep-alive traffic must be sent on all the entries in the connection table to ensure that NATs between the peers will not discard the overlay traffic.
| TOC |
[dSIP‑Base] (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.) describes two techniques for routing SIP requests in a P2PSIP network: iterative and recursive. While that document discusses some of their costs and benefits in terms of reliability and security against various DoS attacks, the added cost of NAT traversal affects each differently. Both approaches require ICE connectivity checks to occur whenever an dSIP connection between peers is added to the overlay. But the two techniques differ in the amount of work to route a request.
| TOC |
In the iterative technique, a request from peer X may be sent to peer U. If peer U is the final destination, it will respond immediately, but normally peer U will respond with the address of another peer, V, that is closer to the destination. Having received a response that contains the address of peer V, peer X re-issues the request directly to peer V. This process of iterative redirection continues until eventually the peer that is the final destination is reached. Under the iterative routing method, peer X is responsible for transmitting each request to a sequence of new targets. The first target (peer U) is selected from peer X's connection table, so a dSIP connection will already exist and the query can be expected to traverse any intervening NATs with no difficulty. However, it is very likely that peer X will not have an existing dSIP connection to the second target, peer V. The same holds true for any subsequent targets.
As mentioned above, ICE requires an existing (usually indirect) communication channel to exchange candidate addresses and establish a new (direct) channel. In order for peer X to successfully transmit a SIP request to peer V, it must enlist the help of peer U (which has established dSIP connections to both X and V). For this to work, peer U must proxy the INVITE for the new dSIP connection on to peer V. Peer U must not respond to the INVITE with a 302 as it did for the original SIP request. Therefore, dSIP connection establishment dictates that even if the overlay is using iterative routing for requests, it must support two-hop proxying (recursive routing) for INVITEs that set up dSIP connections. Assuming that U is willing to proxy the INVITE, X and V can perform ICE connectivity checks to create a new dSIP connection. Peer X is then free to use the new dSIP connection to deliver its query to peer V. This entire process can then repeat until a dSIP connection has been established to the target of the request. Clearly the efficiency and effectiveness of the iterative routing technique are greatly affected by the presence of NATs.
| TOC |
Under the recursive routing technique, once peer X sends a request to peer U, peer U will proxy the request to peer V. Since peer V is selected by peer U from its own connection table, peer U already has a dSIP connection with peer V, and the proxied request will traverse any NATs between Y and Z with no problems. No new dSIP connections need be established. In fact, every hop along the path of the request is selected from the proxying peer's connection table, so the request will only traverse existing dSIP connections.
| TOC |
When the costs of setting up new dSIP connections are considered, the recursive routing technique remains low-cost, while the iterative technique grows in cost as the number of temporary dSIP connections that must be established increases. On the other hand, iterative routing reduces the risk of amplification attacks and allows the originating peer to identify where a message failure occurs, whereas recursive routing gives the originating peer less control and awareness of how failures occur.
Because iterative and recursive routing both have advantages in different situations, and because in a heavily-NATed network, even when using iterative routing a significant amount of two-hop recursive routing is needed for each new dSIP connection, it is possible for both techniques to be used within the same operation to balance the costs and benefits of the two techniques.
| TOC |
This section and its subsections present a normative description on how to set up a dSIP control connection in the presence of NATs. The description here modifies the procedures given in [dSIP‑Base] (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.) and the procedures specified there should be followed where they are not otherwise overridden by this document.
At the start of this procedure, peer X wishes to set up a dSIP control connection to peer Y. This procedure assumes that X has a URI for peer Y that is in the form specified in [dSIP‑Base] (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.).
- How X obtains this URI is not specified here. The REGISTER query operation in [dSIP‑Base] (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.) provides one way. The DHT chosen for the overlay may provide other ways. See also the discussion in Section 6 (Possible Enhancement)
The details of this procedure are almost identical to the details of the procedure for setting of a control connection between a joining peer and an admitting peer specified in [Bootstrap] (Cooper, E., Johnston, A., and P. Matthews, “Bootstrap Mechanisms for P2PSIP,” .). Rather than repeating that procedure, we simply describe the necessary modifications.
Peer X begins by constructing a SIP INVITE message. The To: header is set to the URI of peer Y, and the From: and Contact: headers are set to the URI of peer X. Both URIs MUST be constructed according to the rules of [dSIP‑Base] (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.) and include the "peerid" parameter.
The SDP offer and answer are constructed as specified in section 6.4 of [Bootstrap] (Cooper, E., Johnston, A., and P. Matthews, “Bootstrap Mechanisms for P2PSIP,” .), except that, in the "m" line, the "media" parameter is set to "application" and the "fmt" parameter set to "sip". This specifies that the Peer Protocol for the new connection will be SIP.
The INVITE request is then routed to peer Y using direct, iterative, or recursive routing using the procedures defined in Section 4 (Routing a SIP Request through the Overlay).
When peer Y responds with a 2xx, the two endpoints follow the procedures specified in sections 6.5 and 6.5 of [Bootstrap] (Cooper, E., Johnston, A., and P. Matthews, “Bootstrap Mechanisms for P2PSIP,” .). As a result of these procedures, a SIP connection is established between peers X and Y, with the dialog for the connection running over the connection itself.
Keep-alives must be run on the control connection to maintain it in the presence of NATs. To do this, control connections SHOULD use the STUN Binding Indication method described in ICE [ICE] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” .). These procedures require STUN [STUN‑bis] (Rosenberg, J., Huitema, C., Mahy, R., and D. Wing, “Simple Traversal Underneath Network Address Translators (NAT) (STUN),” .) and SIP [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) to be multiplexed on the same connection: at the far end, the two types of packets can be distinguished because the STUN packets contain the magic cookie 0x2112A442, and these characters cannot occur in a SIP packet at this location.
If the two peers at each end of a connection can somehow learn that there are no NATs between them, then the keep-alives MAY be run at a rate lower than that recommended in [ICE] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” .). The procedures for making that determination are not specified here.
| TOC |
This section and its subsections present a normative description on how to route a SIP request through the P2PSIP overlay. The description here modifies the procedures given in [dSIP‑Base] (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.) and the procedures specified there should be followed where they are not otherwise overridden by this document.
At the start of this procedure, peer X has a SIP request which it wishes to send to peer Y. This procedure assumes that X has a URI for peer Y that is in the form specified in [dSIP‑Base] (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.).
- How X obtains this URI is not specified here, and depends on the context in which the request is generated.
Peer X MAY elect to use direct routing, iterative routing, or recursive routing when sending the request.
| TOC |
If peer X has an IP address for peer Y, peer X MAY elect to send the request directly to peer Y, using standard SIP techniques.
- Peer X might obtain an IP address in a variety of ways. The URI for peer Y may include an IP address, or peer X may obtain information about peer Y through DHT-specific mechanisms.
If peer X knows the port and transport protocol associated with the address, it SHOULD use those values. Otherwise, it is RECOMMENDED that it use port 5060 and the UDP protocol respectively.
If peer X sends the request directly to Y using UDP, then it is RECOMMENDED that peer X assume the send attempt has failed if it does not receive a reply within a short period (one or two expirations of Timer A). If peer X uses TCP to send the request, then it is RECOMMENDED that peer X assume the send attempt has failed if it is unable to establish a TCP connection within a short period (perhaps 2*T1). If the send attempt fails, then the peer SHOULD try to send the request through the Overlay using either recursive or iterative routing.
| TOC |
| TOC |
Peer X SHOULD indicate the requested routing method by adding either "proxy" (for recursive routing) or "redirect" (for iterative routing) to a Request-Disposition header [RFC3841] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.) in the request.
Peer X then chooses the peer U in its connection table that is "closest" to peer Y. If there is no such peer U, then peer X SHOULD treat the request as having failed.
- The definition of "closest" depends on the DHT algorithm used by the overlay. For example, in a system based on Chord (for example, [dSIP‑Chord] (Zangrilli, M. and D. Bryan, “A Chord-based DHT for Resource Lookup in P2PSIP,” February 2007.)), "closest" means the peer whose peer-ID is the closest in the ring when going in the direction of ascending peer-ID.
Peer X then sends the request on its connection to U.
If peer X receives a reply of 302 Moved Temporarily specifying some other peer W, then peer X SHOULD follow the procedures specified in Section 3 (Establishing and Maintaining dSIP Connections) to set up a dSIP connection to peer W if it does not already have such a connection. Peer X MUST use recursive routing (and not iterative routing) when establishing the connection. Peer X MAY omit sending an INVITE with a Replaces header [RFC3891] (Mahy, R., Biggs, B., and R. Dean, “The Session Initiation Protocol (SIP) "Replaces" Header,” September 2004.) - this may be appropriate if peer X views this new connection as temporary and plans to tear down the connection after a short while.
Once the connection to peer W is established, peer X SHOULD try the request again, using whatever routing method it wishes.
| TOC |
When peer U receives the request, it decides whether the request is addressed to it, or whether it should proxy the request onward.
If peer U is not the final destination for the request, peer U acts as a SIP proxy for the request as specified in section 16 of [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). When forwarding the request, looks for the peer V it its connection table that is "closest" to the destination peer Y.
If a peer V is found, the handling depends on the requested handling ("proxy" or "redirect") indicated in the Request-Disposition header of the request.
If the requested handling is "proxy", the peer MUST proxy the request on to V. Peer U MUST add a Record-Route header [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) to the request and SHOULD add a "rport" parameter [RFC3581] (Rosenberg, J. and H. Schulzrinne, “An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing,” August 2003.).
- Adding the Record-Route header ensures that subsequent requests in the dialog (if any) take the same route. In particular, this ensures that the ACK in an INVITE transaction will be routed through the overlay and not sent directly.
If the requested handling is "redirect", the peer SHOULD reply with a 302 Moved Temporarily specifying peer V.
If no handling is specified, the handling of the request is undefined.
If there is no such peer V, then peer U MUST treat the proxy attempt as having failed and reply appropriately.
The handling of a request addressed to peer U follows normal SIP processing rules [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). In particular, any response is routed back along the path of the request.
| TOC |
In this section, we give three examples that illustrate the procedures defined above.
| TOC |
This first example shows the recursive routing of a SIP request message. In this particular case, the request is a REGISTER message. In dSIP, REGISTER messages are used to store and retrieve information in the overlay. In this example, peer X does a recursive lookup of information associated with a user M. The hash of M's resource-id falls within the range of ids owned by peer Y, so M's information is stored with Y. Peer X, which wishes to retrieve this information, creates a REGISTER message which is addressed to M, and sends it into the overlay via peer U with a Request-Disposition header containing "proxy". Peer U proxies this request on to peer V, which it turn proxies it on to peer Y, which replies with a 200 OK containing information about user M.
In the figure, "REGISTER(To:M,R-D:proxy)" indicates a REGISTER message with a To header containing "M" and a Request-Disposition header containing "proxy". Not shown in the figure is the adding of Record-Route headers by peers U and V as they proxy the request.
Peer X Peer U Peer V Peer Y | | | | | REGISTER(To:M,R-D:proxy) | | |--------------------->| | | | |----------------->| | | | |--------------------->| | | | 200 OK | | | |<---------------------| | |<-----------------| | |<---------------------| | | | | | |
Figure 1: Routing a REGISTER Request using Recursive Routing
| TOC |
In this example, assume peer X wishes to set up a dSIP connection to peer Y. Peer X has a URI for peer Y, but cannot send directly to peer Y due to intervening NATs. However, there is an indirect route to Y via peers U and V.
Peer X sends an INVITE request to peer Y via peer U with a Request-Disposition of "proxy". Peer U proxies this onward to peer V, adding a Record-Route header as it does so. Similarly, peer V proxies the request on to peer Y. Peer Y replies with a 200 OK. Peer X then responds with an ACK, which is proxied through peers U and V because of the Record-Route.
Peers X and Y then perform one or more ICE ([ICE] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” .) and [ICE‑TCP] (Rosenberg, J., “TCP Candidates with Interactive Connectivity Establishment (ICE),” .)) connectivity checks. These are shown as happening after the INVITE transaction, but in practice they would usually happen in parallel.
Once the connectivity checks finish, the controlling agent (assumed to be peer X in this example) sends an INVITE with a Replaces header directly to Y to replace the dialog that goes via U and V with a new dialog that runs along the direct dSIP connection. The Replaces header causes the controlled agent (assumed to be Y) to send a BYE for the old dialog.
To compress the example, we show final BYE transaction with a single arrow labeled "BYE/200".
Peer X Peer U Peer V Peer Y | | | | | INVITE(To:Y,R-D:proxy) | | |--------------------->| | | | |----------------->| | | | |--------------------->| | | | 200 OK | | | |<---------------------| | |<-----------------| | |<---------------------| | | | ACK | | | |--------------------->| | | | |----------------->| | | | |--------------------->| | | | | | ICE connectivity checks | |<-------------------------------------------------------------->| | | | | | Direct dSIP connection established | |================================================================| | | | | | INVITE (Replaces) | | | |--------------------------------------------------------------->| | | | 200 OK | |<---------------------------------------------------------------| | ACK | | | |--------------------------------------------------------------->| | | | | | | | BYE / 200 OK | |<---------------------|<-----------------|<---------------------| | | | |
Figure 1: Setting Up a dSIP Connection using Recursive Routing
| TOC |
In this example, we revisit the situation of the first example, and show how it can be done using iterative routing. As before, peer X want to retrieve information about a user M, who information is stored with peer Y.
In the figure below, peer X sends an REGISTER query request addressed to user M via peer U with a Request-Disposition of "redirect". Peer U responds back to peer X with a 302 Moved Temporarily, specifying that peer X should try peer V.
Peer X does not have a dSIP connection to peer V, and the various NATs in the network prevent peer X from just sending the REGISTER request directly to V. Thus, when doing iterative routing, the next step is for peer X to set up a temporary dSIP connection to peer V. To do this, peer X send an INVITE to peer V via peer U with a Request-Disposition of "proxy". This INVITE is proxied by U to V, which responses with a 200 OK. Peers X and Y then do ICE connectivity checks and set up a direct dSIP connection between themselves. Since this is just a temporary dSIP connection, peer X does not bother with replacing the indirect dialog with a direct dialog (as shown in the previous example).
Peer X then resends the original REGISTER (addressed to M), this time sending it via the direct dSIP connection to V. This causes peer V to respond with a 302 that specifies peer Y.
Once again, peer X needs to set up a temporary dSIP connection (assuming it does not already have one with peer Y and that intervening NATs prevent sending without a connection). Peer X does this by sending an INVITE addressed to Y along its temporary connection to V, which proxies it onto to Y. As before, X and Y run ICE connectivity checks and establish a dSIP connection.
At this point, peer X once again resends the original REGISTER request, this time along the direct connection to Y. Peer Y responds with a 200 OK containing the desired information.
Finally, peer X tears down it two temporary dSIP connections to Y and V (in the reverse order that they were set up).
Peer X Peer U Peer V Peer Y | | | | | REGISTER(To:M,R-D:redirect) | | |--------------------->| | | | 302(Contact:V) | | | |<---------------------| | | | | | | | | | | | INVITE(To:M,R-D:proxy) | | |--------------------->| INVITE(To:M,R-D:proxy) | | |----------------->| | | | 200 | | | 200 |<-----------------| | |<---------------------| | | | ACK | | | |--------------------->| ACK | | | |----------------->| | | | | | | ICE connectivity checks | | |<--------------------------------------->| | | dSIP connection to V established | | |=========================================| | | | | | | | | | | REGISTER(To:M,R-D:redirect) | | |---------------------------------------->| | | | 302(Contact:Y) | | |<----------------------------------------| | | | | | | | | | | INVITE(To:Y,R-D:proxy)/200/ACK | INVITE(To:Y)/200/ACK | |---------------------------------------->|--------------------->| | | | | | ICE connectivity checks | |<-------------------------------------------------------------->| | | | | | dSIP connection to Y established | |================================================================| | | | | | | | | | REGISTER(To:M,R-D:redirect) | | |--------------------------------------------------------------->| | | | 200 | |<---------------------------------------------------------------| | | | | | | | | | BYE/200 | | BYE/200 | |---------------------------------------->|--------------------->| | BYE/200 | | | |--------------------->|----------------->| | | | | |
Figure 3: Routing a REGISTER Request using Iterative Routing
| TOC |
As currently specified, a peer X must know the exact peer-ID of the peer it wishes to establish a dSIP connection with before starting the procedure described in Section 3 (Establishing and Maintaining dSIP Connections).
However, to build and maintain its routing table, peer X wants to set up a connection for each routing table entry. The range of peer-IDs that can be used for each routing table entry is dependent on the DHT used. (For example, if the Chord DHT is used, peer X would try to set up a connection to the first peer in the range 2^i .. 2^(i+1), for various values of "i"). To update a routing table entry as currently specified, peer X must first send a Peer Query for a peer-ID in the range of peer-IDs associated with each routing table entry. This query will fail, but the failure response will contain the peer-ID of the first peer in this range. At that point, peer X has the exact peer-ID it needs and can use the procedure described in Section 3 (Establishing and Maintaining dSIP Connections).
Future versions of this specification may extend the procedures here to allow this operation to be done with one SIP transaction rather than two.
| TOC |
Security considerations will be discussed in a future version of this document.
| TOC |
IANA considerations will be discussed in a future version of this document.
| TOC |
A team of people have worked on the various drafts related to the dSIP protocol and extensions thereof. The team consists of: David Bryan, Eric Cooper, James Deverick, Cullen Jennings, Bruce Lowekamp, Philip Matthews, and Marcia Zangrilli.
Special thanks to Alan Johnston, who suggested (originally in the context of [Bootstrap] (Cooper, E., Johnston, A., and P. Matthews, “Bootstrap Mechanisms for P2PSIP,” .)), the use of the Request-Disposition and Replaces headers.
| TOC |
| TOC |
| [Bootstrap] | Cooper, E., Johnston, A., and P. Matthews, “Bootstrap Mechanisms for P2PSIP,” Internet Draft draft-matthews-p2psip-bootstrap-mechanisms (Work in Progress). |
| [ICE] | Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” Internet Draft draft-ietf-mmusic-ice (Work in Progress). |
| [ICE-TCP] | Rosenberg, J., “TCP Candidates with Interactive Connectivity Establishment (ICE),” Internet Draft draft-ietf-mmusic-ice-tcp (Work in Progress). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002. |
| [RFC3581] | Rosenberg, J. and H. Schulzrinne, “An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing,” RFC 3581, August 2003. |
| [RFC3841] | Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” RFC 3841, August 2004. |
| [RFC3891] | Mahy, R., Biggs, B., and R. Dean, “The Session Initiation Protocol (SIP) "Replaces" Header,” RFC 3891, September 2004. |
| [dSIP-Base] | Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” Internet Draft draft-bryan-p2psip-dsip-00 (Work in Progress), February 2007. |
| TOC |
| [BEHAVE-P2P-State] | Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs),” Internet Draft draft-ietf-behave-p2p-state (Work in Progress). |
| [DHT-for-Communications] | Bryan, D., Zangrilli, M., and B. Lowekamp, “Challenges of DHT Design for a Public Communications System,” William and Mary Technical Report WM-CS-2006-03, June 2006. Copy available at http://www.cs.wm.edu/~bryan/pubs/wm-cs-2006-03.pdf |
| [Illuminati] | Cadaco, M. and M. Freedman, “Illuminati - Opportunistic Network and Web Measurement,” http://illuminati.coralcdn.org/stats/, February 2007. |
| [NAT-Character] | Guha, S. and P. Francis, “Characterization and Measurement of TCP Traversal through NATs and Firewalls,” Proceedings of Internet Measurement Conference (IMC), October 2005. Copy available at http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/ |
| [NATs-and-Overlays] | Cooper, E. and P. Matthews, “The Effect of NATs on P2PSIP Overlay Architecture,” Internet Draft draft-matthews-p2psip-nats-and-overlays (work in progress), February 2007. |
| [P2PSIP-Use-Cases] | Bryan, D., Shim, E., and B. Lowekamp, “Use Cases for Peer-to-Peer Session Initiation Protocol (P2P SIP),” Internet Draft draft-bryan-sipping-p2p-usecases (work in progress), November 2005. Copy available at www.p2psip.org/ietf.php |
| [RFC3263] | Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” RFC 3263, June 2002. |
| [STUN-bis] | Rosenberg, J., Huitema, C., Mahy, R., and D. Wing, “Simple Traversal Underneath Network Address Translators (NAT) (STUN),” Internet Draft draft-ietf-behave-rfc3489bis (Work in Progress). |
| [Sipping-NAT-Traversal] | Boulton, C., Ed., Rosenberg, J., and G. Camarillo, “Best Current Practices for NAT Traversal for SIP,” Internet Draft draft-ietf-sipping-nat-scenarios (Work in Progress). |
| [dSIP-Chord] | Zangrilli, M. and D. Bryan, “A Chord-based DHT for Resource Lookup in P2PSIP,” Internet Draft draft-zangrilli-p2psip-dsip-dhtchord (Work in Progress), February 2007. |
| TOC |
| Eric Cooper | |
| Avaya | |
| 1135 Innovation Drive | |
| Ottawa, Ontario K2K 3G7 | |
| Canada | |
| Phone: | +1 613 592 4343 x228 |
| Email: | ecooper@avaya.com |
| Philip Matthews | |
| Avaya | |
| 100 Innovation Drive | |
| Ottawa, Ontario K2K 3G7 | |
| Canada | |
| Phone: | +1 613 592 4343 x224 |
| Email: | philip_matthews@magma.ca |
| David A. Bryan | |
| SIPeerior Technologies and College of William and Mary | |
| 3000 Easter Circle | |
| Williamsburg, Virginia 23188 | |
| USA | |
| Phone: | +1 757 565 0101 |
| Email: | dbryan@sipeerior.com |
| Bruce Lowekamp | |
| SIPeerior Technologies and College of William and Mary | |
| 3000 Easter Circle | |
| Williamsburg, Virginia 23188 | |
| USA | |
| Phone: | +1 757 565 0101 |
| Email: | lowekamp@sipeerior.com |
| TOC |
Copyright © The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).