P2P-SIP
Once that signaling with SIP and resource location with the peer-to-peer paradigm have been defined, how these two technologies can be integrated will be considered.
In traditional SIP, the centralized entity is the proxy, whose functions can be decomposed into:
1. user location; 2. message routing.
When creating peer-to-peer SIP, we want to make distributed such cen-tralized functions, asking each peer share its resources and contribute in providing these two services.
5.1
Distributed Location Service
In concrete, a peer-to-peer DHT algorithm should be used to implement a distributed location service.
As described in section 3.3.2, DHTs store pairs (key, value) in a dis-tributed manner, where each peer is responsible for a part of the key space. In case of P2P-SIP the key is the AOR of the user (i.e. its “public SIP ad-dress”) and the value is its contact address (i.e. the address at which its UA can be actually contacted).
Therefore, the traditional SIP procedures for locating the next hop must be substituted with a peer-to-peer DHT protocol.
The choice of a structured overlay (such as a DHT) over an unstructured overlay is strongly supported by two main reasons:
• unstructured overlay proved to offer efficient resource searches when the considered resource is shared by many peers; in case of SIP the resource (i.e. the UA associated to an AOR) is unique;
• false negatives cannot be tolerated: when a user makes a phone call to another user, we want the overlay to find that user with chance of 100% if that user is actually on-line; this guarantee can only come from a DHT, while an unstructured overlay may not be able to find the desired resource even if it is available. On the other side, false positives are not so bad, because the attempt to open a connection to the no longer existing UA will fail and allow the detection of the new off-line status.
There are two possible design choices for the new location service (figure 5.1):
1. use a separate ad-hoc protocol for the management of the DHT (store information, retrieve information, maintain routing structures);
2. convey peer-to-peer protocol data through SIP messages.
User Agent DHT-based Loc. Serv. SIP stack DHT stack User Agent DHT-based Loc. Serv. SIP stack
5.1.1
SIP as protocol for DHT maintenance
Using SIP as the protocol for managing the P2P overlay may seem convenient for different reasons:
• the P2P-SIP overlay would be used to manage SIP resources, so the support for such URI is already present in the SIP protocol;
• it would avoid embedding an additional protocol stack into the applica-tion, particularly important if the size of the application does matter; • current SIP procedures can be adopted without too big modifications
to make P2P operations on the overlay.
In case SIP would be used as peering protocol, overlay operations could be implemented as follows:
• PUT : with a REGISTER request; the key is in the To header and the value the Contact one;
• GET : with a REGISTER with no Contact header (defined by the SIP specification in order to fetch bindings from the location database); the searched key is the To header;
• redirect : if the node is not responsible for that key and it is employing iterative routing (see section 3.3.2), it would answer with a 302 Moved Temporarily, specifying in the Contact header a node closer to the searched key.
• exchange of routing information between peers: they can be embedded in new ad-hoc SIP header or in the body of SIP messages.
Although this is a viable solution (and also implemented by SIPDHT, see section A.2), it has a few significant drawback. The main one is the excessive overhead. SIP messages must include many other header that are not strictly needed for P2P overlay operations. Moreover SIP messages are text messages, therefore are bigger than an binary equivalent and need more processing power to parse them. This is not a problem for the low rate of
signaling messages, but the overhead is not negligible for the overlay stabi-lization messages which must be small and frequent, in order to maintain high scalability and robustness. Moreover this approach distort the nature of SIP.
Anyway, although we believe that the most efficient way to implement P2P operations is with an ad-hoc stack, in the rest of this work we will not make any assumption on how this is implemented, studying NAT traversal solution independently.
5.2
Message routing
The other relevant design question is how the initial INVITE (or any other request for a user) should be routed across peers peer to reach the destination. The simplest and most efficient approach would be the following. Let k be the AOR of the user being invited, the inviting UA:
1. fetches the contact URI of the other user via a P2P query: cont uri = GET (k);
2. sends an INVITE directly to that user (cont uri ) without intermediate hops.
Clearly the Contact URI of the invited user must be publicly routable and not filter incoming connection, which is not the case for NAT devices and firewalls. This topic, in fact, will be considered in the next section.
5.3
NAT and P2P-SIP
Peers participating in a DHT have to ensure the availability of the data they are storing to any other peer, in particular when using iterative routing of queries (see section 3.3.2). For this reason they need to reachable by all the other peers. Moreover they are expected to answer queries with low latency. Therefore, it is quite clear that DHT peers do need a non-firewalled public address. An argument against this approach is that the percentage of hosts
with public IP address is low, if compared to number of hosts behind NAT1.
It possible to think about some kind of mechanism to have DHT peers residing behind NAT. Such a mechanism must allow other nodes to contact such masqueraded peer; this can be done by employing recursive routing and having the nodes that perform the DHT lookup to build a direct connection (when possible) with all the nodes in their finger table; however, it is not feasible to keep such a high (e.g. 160 in case of Chord) number of active connections to a node behind a NAT, because this is very likely to cause NAT device overloading and too much background traffic for keep-alive packets.
It it important to note that the major benefit that would derive from having a larger number of DHT peers is not the lower need for storage space per node, but the reduced load of received queries per node. In fact, storing 50 associations AOR–Contact URI instead of 5, is not much more expensive. However, processing 5 queries per second instead of 50 is great reduction of load.
As we can see, allowing DHT peers behind NAT would not help in reduc-ing the load on public peers, but would just increase the complexity of the protocol and the used network bandwidth.
5.4
Related work
5.4.1
SOSIMPLE
Exploring SIP and P2P integration has been done in [15] and [14]. The authors have been working on an implementation of an Instant Messaging and end-to-end presence client based on the SIP protocol, its SIMPLE extension [20] for Instant Messaging and the Chord P2P algorithm. SIP messages are used to carry the P2P traffic, in order to reduce the number of protocol stacks included in the application.
The problem of NAT traversal, however, is not solved. The authors are using STUN for public IP discovery, and acknowledge the need for STUN
1As we will discuss in section 7.6.1, according to [21] the number percentage of public hosts is about 26%.
Relay servers.
5.4.2
SIPpeer
Also in [76] it has been worked on an adaptor for using a traditional SIP client with a P2P location service. Such adaptor, called SIPpeer, acts as a SIP proxy, from the point of view of the SIP client, but implements a peer-to-peer protocol to store and retrieve information for the SIP location database. They used, at first, the Chord protocol, than they explored the usage of the OpenDHT [62] libraries in order to exploit an already existing and running overlay.
The authors suggest using standard IETF procedures for NAT Traversal (STUN, STUN Relay and ICE), and exploiting ReDir API, provided by OpenDHT, for discovery of STUN and STUN Relay services.
ReDir (Recursive Distributed rendez-vous, [62]) API is a client-side library that allows the creation of namespace over the key space of OpenDHT. Nodes that join that provide a particular service, should join the namespace for that particular service.
The idea form SIPpeer is that peers offering STUN service (and STUN Relay service) should register under the namespace stun (and turn). This approach, anyway, has the drawback of requiring multiple key lookups in the overlay in order to find just one node offering such service.
5.4.3
IETF
Both these prototypes (SOSIMPLE and SIPpeer) are not publicly available. Moreover latest report and articles date back to 2005.
Discussion has been started by the newly created IETF Working Group P2PSIP [55] to define and develop protocols and mechanisms for the use of SIP in absence of a centralized server and where the endpoints are partici-pating a peer-to-peer overlay.
The Internet Draft [13] has been published proposing concepts and ter-minology. It states the problem by a general point of view, making any
assumption on the peering protocol and without excluding the possibility of having DHT peers behind NAT.
In fact, draft [12] has been written proposing a SIP based Registration and Location Service (named dSIP ). This draft, however gained opposition of some IETF members not only for the above stated reasons, but also for some considerations about the relationship between dSIP and traditional SIP. Using SIP as the peering protocol would break compatibility with RFC 3261, thus giving birth to a fork of the SIP protocol. In particular it would:
• make SIP manage the location database, while RFC 3261 states that it should be independently managed by the registrar;
• change REGISTER semantic: it would be no longer used to register AORs for a precise domain, but would be used to insert peers in the DHT, reg-ister resource keys in the DHT and fetch them; this multiple semantic change is not permitted by RFC 3261;
• change the meaning of some URIs, posing additional constraints in-compatible with the RFC (e.g. that the user part of the URI must be a hash of the domain part);
• imply that all the nodes understand dSIP and reject traditional SIP requests, thus making dSIP and SIP completely separate;
• use SIP for transfer of P2P routing tables, whereas SIP is just a sig-naling protocol and is not designed to perform bulk transfers.
Another couple of drafts ([23] and [24]) analyze NAT issues and propose a solution for having DHT peers behind NAT. It is based mainly on two ideas: the first is to create and keep live direct connections with all the nodes in the routing table of the DHT; the second is to use ICE to create those direct connections, specifying SIP as a new flow in the SDP payload. As already remarked, this approach adds latency, complexity and bandwidth requirement to the process without providing significant benefit.
5.5
Pending issues
From the analysis carried out so far, three issues emerge that still do not have a proper solution.
5.5.1
Direct connectivity for signaling
In chapter 4 techniques for NAT traversal have been examined. We have seen that ICE (paragraph 4.6) procedures allow creation of direct connec-tions for media flows between SIP UAs. On the other side, NAT traversal limitations have been overcome for signaling messages by means of forcing all the messaging to pass through a proxy SIP server (see section 4.3.2). While it would not be too problematic for a SIP provider, which can invest in in-creasing its servers resources to support a greater number of users, in case of a provider-less peer-to-peer SIP network, that proxy server would become the UA of another user. In the struggle of minimizing load on other peers, a solution must be found to achieve direct end-to-end connectivity also for signaling between UAs, whenever possible.
Besides, the presence of intermediate peers between two UAs would re-duce the robustness of the communication, because a peer is an instable node by nature. This is, therefore, another reason supporting the need to build a direct end-to-end connection.
Direct connectivity would become the preferred long-lived channel for SIP message exchanges between two UAs; such messages are not limited to INVITE sessions, but include also SUBSCRIBE/NOTIFY dialogs for presence subscription, MESSAGE exchanges and so on.
In the next chapter (6), ALEX (Address List eXtension) will be described. ALEX is an extension to the SIP protocol designed to achieve SIP direct connectivity for two multi-homed UAs. So far, ALEX has been specified and tested only in dual-stack IPv4/IPv6 environments, however we will show how it can be easy extended to the case of hosts behind NAT.
5.5.2
Ensuring reachability of peers behind NAT
Even though we have a procedure for establishing direct connectivity in most network configurations, still we need a mechanism to allow nodes behind NAT to receive messages coming from other nodes. For each masqueraded node, therefore, there must be some public peers that keep a persistent connections with it.
When a UA on a private node registers in the DHT, it must not store its private address in association with its AOR. Instead, it must store the address of these public peers with which it has a persistent connection. In some sense, it is similar to a distributed Outbound (section 4.3.2) service.
5.5.3
Location of rendez-vous and relay peers
From the analysis on the NAT traversal techniques (section 4.2), it appears clear that almost any communication between two masqueraded hosts, or from a public node to a NATted one, needs at least a rendez-vous point. Such rendez-vous point is the host that allow a first message exchange between the endpoints, in order to discover each other public mapped address and activate UDP hole punching procedures. Moreover, in some unlucky network configuration, a public peer that acts as relay for the media traffic is needed. In the traditional SIP architecture, those rendez-vous and relay servers are STUN and STUN Relay servers managed by the SIP provider. In the peer-to-peer paradigm they are no longer available; therefore such task must be took over by public peers.
Clearly, we need a mechanism for efficient location of those relaying peers. By “efficient” location we mean that the relying load should be proportional to the peer’s resources. Moreover it is desirable a way for relaying nodes to notify back to the masqueraded node about their status and the moment they are going to leave the overlay, in order to suggest the node behind NAT to look for another helper node.
In chapter 7 this issue and the previous one will be discussed in detail and a solution will be proposed.
