In this article we try to show how P2P SIP networks (a SIP network on P2P nodes) can be deployed and coexist with Client/Server SIP networks (C/S-SIP). We make no assumptions about the architecture of an already existing C/S-SIP network which could be as simple as that specified by IETF or as complex as a 3GPP IMS network. The discussion in this article is based on proposals laid down in the IETF P2PSIP working group. The article does not attempt to specify or assume what P2P Protocol (P2PP) is used and what P2P Algorithm  (P2PA) is deployed by the nodes of the P2P Network. Knowledge of SIP and other related  protocols is assumed throughout the article. The following IETF drafts provide good background:

P2P and SIP:
http://www.p2psip.org/drafts/draft-matthews-p2psip-bootstrap-mechanisms-00.txt
http://www.p2psip.org/drafts/draft-marocco-p2psip-interwork-01.html
http://www.p2psip.org/drafts/draft-willis-p2psip-concepts-04.html

SIP and NAT Traversal:
http://www.ietf.org/internet-drafts/draft-jennings-behave-test-results-03.txt
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-mmusic-ice-15.txt
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-behave-p2p-state-02.txt

The P2PSIP.org website also acts as an excellent source of information.

Figure 1: Architecture of a VoIP network using traditional SIP and P2P

We start with few definitions first (some borrowed from the Willis draft).

1. P2P Network: This is a network of nodes connected to each other using P2P Control Connections and maintained using the P2P Protocol. The P2P Protocol runs a single P2P Algorithm to manage state.
2. P2P SIP Overlay: A P2PSIP Overlay is a P2P Network which functions as a single distributed location database of SIP resources and can transport SIP messages between the P2P nodes.
3. P2PP: Peer to Peer (Network) Protocol: This is the protocol used to establish and maintain the P2P Network and provide routing within it.
4. P2PC: Peer to Peer Control Protocol: A P2P Network assumes that the nodes which form the overlay have full duplex connectivity between them (though they may or may not be communicating with each other). This is not true in the internet because of the presence of NATs which provide only asymmetric connectivity. A Peer to Peer protocol essentially rides on control connections which provide the necessary abstraction for the P2P network. ICE over SIP provides by far the best choice for P2PC. Note that the control connections will usually be based on UDP and are kept alive by using STUN in a P2P fashion.
5. P2PA: Peer to Peer Network Algorithm: This is a P2P state management (or DHT) algorithm. In the case of SIP, this could be Chord, Bamboo, Kademlia etc.
6. Peer (P): A node that speaks the P2P Protocol and can participate in the P2P Overlay and perform the various functions
7. Joining Peer (J/P): A node that is attempting to become a Peer in a particular Overlay.
8. Bootstrap Peer (B/P): A Peer in the Overlay that is the first point of contact for a Joining Peer. It selects the peer that will serve as the Admitting Peer and helps the joining peer contact the admitting peer.
9. Admitting Peer (A/P): A Peer in the Overlay which helps the Joining Peer join the Overlay. The choice of the admitting peer may depend on the joining peer (e.g., the joining peer's Peer-ID). For example, the admitting peer might be chosen as the peer that is "closest" in the logical structure of the overlay to the future position of the joining peer. The selection of the admitting peer is typically done by the bootstrap peer. It is allowable for the bootstrap peer to select itself as the admitting peer.
10. Bootstrap Server (B/S): A network node used by Joining Peers to locate a Bootstrap Peer. Typically, a Bootstrap Server acts as a proxy for messages between the Joining Peer and the Bootstrap Peer. The Bootstrap Server itself is typically a stable host with a DNS name that is somehow communicated (for example, through configuration) to peers that want to join the overlay. A Bootstrap Server is NOT a peer and functions like a SIP Proxy or Redirect Server
11. Interworking Node (I/W): A network node which provides connectivity from traditional VoIP infrastructure equipment or VoIP endpoints to a P2P overlay.

Next we look at few scenarios to help us understand how this works:

How do P2P Nodes locate and join a P2P Network

The first step a Joining Peer (J/P) executes to join a P2P network is to ensure it has connectivity to it. This is because most of the P2P network nodes may be behind NATs which provide asymmetric connectivity and only some of the nodes in the P2P network may provide the bootstrapping service for new joining nodes. The Bootstrap Server (B/S) provides knowledge of these nodes to the J/P and acts as a rendezvous point as well.

The J/P acquires the address of the B/S using one or more of the following typical methods: (a) Hardcoded value (b) DNS SRV (c) Multicast or broadcast on local network or DHCP (d) Downloaded using HTTP etc.

After the B/S address is selected, the J/P attempts to establish connectivity to the P2P Bootstrap Peer (B/P) through the B/S. The protocol used to do this is P2PC: SIP/ICE.
The node sends an INVITE with ICE SDP to the B/S which then forwards it to the B/P. The B/P uses the P2PA to compute the peer ID of a node in the P2P Network which will be responsible for admitting and maintaining state for the J/P. This node is the Admitting Peer (and may be the same as B/P). The INVITE is then forwarded to the A/P to set up a SIP/ICE P2PC session between the J/P and the A/P.

A given B/S may support multiple P2PSIP Overlays and may use information in the INVITE (SIP URI) from the J/P to determine the overlay. The B/S may also perform SIP Authentication before allowing the P2P Control connection to be established.

The B/P nodes in the P2P network register with the B/S using SIP. It is also important to note that the B/S is just a simple SIP Registrar and Proxy which does record routing of SIP packets.

When the SIP INVITE enters the P2P network, it is forwarded on existing control connections and does not require the setting up of new control connections between nodes already part of the P2P network.

The benefit of using SIP/ICE to establish the control connection is clear: ICE provides a standardized method to establish a connection in an environment which is inherently asymmetric because of the presence of NATs. Any other technique which uses hairpin approach is quite arbitrary and may need tweaking based on circumstances.

Once the P2P control connection is established the J/P can start using the P2P protocol with the A/P. The J/P may also establish more connections with other P2P nodes for redundancy and optimum routing.

Using SIP in the P2P network

Once the peer has joined the P2P Network it next registers SIP resources (URIs) in the network using the P2P Protocol. A node which wants to send a SIP packet to a target URI first looks up the URI in the P2P network to find the P2P node where it is located. It then attempts to send the SIP packet over existing P2P connections to the target peer node. This is the main difference between the C/S-SIP network and the P2PSIP network. For example in order to monitor presence of a destination URI or to set up a session to it, a node first locates which P2P node the resource is located at and then forwards the SIP message over existing paths in the P2P Network.

Choosing the P2P Algorithm

It seems that the P2P research community is converging towards the use of Chord as the default P2P Routing algorithm. While Chord is not the most optimal algorithm in all situations it seems to perform better in most areas when it comes to failure handling, churn, latency, cost, recovery handling etc. The P2PP is designed to run almost any known P2P algorithm like Chord, Pastry, Kademlia, Bamboo etc. This allows the same infrastructure to be usable in specialized circumstances (like low churn) and use a more suitable P2P Algorithm.

Security

Security issues in a P2P SIP Overlay are somewhat different from those in C/S-SIP network. The following points are worth noting:

1. There is no central server to attack to bring down the whole service. A P2P network is also self healing if disconnected from other nodes in the network. An attack on a P2P network to bring down a service needs to be distributed.
2. Authentication of users and messages in a C/S-SIP Network is done by a Central Server which is usually the first hop. Other nodes which receive a SIP message process it based on an implicit trust relationship with the main server or something transitively related to it. This mechanism can be applied in the P2P network as well where the first authentication is performed by the bootstrap server or the bootstrap peer.
3. An encryption technique like DTLS may be more suitable in a P2P environment than TLS where TCP connections may be harder to establish and prove undue overhead.
4. For encrypting media, DTLS, SRTP or any other technique which works for normal SIP sessions may be employed.
5. The routing algorithm in a P2P Network runs in a distributed fashion and if the nodes themselves malfunction or are infected with a virus, they could affect routing of traffic in the P2P Network. This can lead to a large set of open ended security issues. This set of problems is easily avoided in a C/S-SIP Network by monitoring certain parameters of the centrally administered server. In a P2P Network, the same strategy must be applied in a distributed fashion. This allows us to use open protocols while keeping viruses at bay.

Interworking with third party devices or legacy network

Interworking between a P2PSIP Network and a C/S-SIP Network is by far the most important issue on hand for providers. Large sums of money have been spent on equipment like SIP Proxies, Gateways, SBCs, IVR/Voice Mail Servers, Application Servers, ATAs etc.

The following points are worth noting when it comes to analyzing interworking issues for P2PSIP:

1. P2PSIP and C/S-SIP utilize exactly the same SIP protocols for session establishment. This means that session establishment itself doesn’t have any new interworking issues than what already exist in SIP. Both SIP signaling and media can be sent end-to-end between a P2P SIP Node and a C/S-SIP Node.
2. The process of locating a SIP user in a P2P Network is different from that in a C/S-SIP Network and this requires interworking. For example an INVITE forwarded by a SIP Server in the C/S-SIP network will need to terminate first at the I/W node which sends a P2PP message inside the P2P Network to locate the destination URI. The INVITE is then forwarded onto a control path between the I/W node and the destination peer node. Media will flow direct between the P2P Node and the C/S-Node after the SIP session is established. Locating a C/S-SIP user on the other hand is much simpler. The key is to realize that the I/W node is not required for this task since (a) there are no connectivity issues (b) the SIP message can be directly sent from the P2P Node to the destination SIP Gateway or Proxy.
3. The I/W node can also act as a SIP Proxy for the C/S-SIP ATAs. The Registrar database can be the P2P Network since the I/W node is participates in it. This allows less amount of state to be stored in the I/W node making the service more robust and scaleable.

The only requirement for the I/W node is that it participate in the P2P Network, be globally reachable and stay in the call path (for e.g. by using SIP Record Routing).

The role of SBCs and B2B UAs

No discussion of P2PSIP can be complete without discussing SBCs and B2BUAs. The following points are worthwhile to note:

1. The security functions of an access SBC are not applicable in a P2P network. Security in a P2P network is implemented on the end hosts themselves. There is no core SIP Servers to protect against attack.
2. SBCs may still be used for managing the PSTN interconnects. SBCs may also provide STUN media relay functions for NAT traversal. Other non-compliant forms of media relays may result in media getting relayed twice for each call. ICE is optional, but not required on SBCs. Since SIP used in the P2P network and the C/S-SIP network is basically the same, no new SIP interworking issues arise because of P2P.
3. SBCs could also embed the P2P I/W function. This requires the SBCs to be part of the P2P Network as well.

E911, CALEA and other regulations

It is commonly understood that VoIP does not lend itself well to regulatory requirements like wiretapping, recording etc. In most countries a provider is required by law to provide as much data as it can about calls made to or by specific users through its network without alerting the caller or the callee that the call is being tapped. In U.S a public company could be required under Sarbanes Oxley to record all calls on its network. A call center may use call recording for performance management and training.

Based on location automatically determined by the system or manually entered by the user, emergency calling is a relatively easier to handle in VoIP.

It is important to note that in a C/S-SIP architecture, the server plays an important part when it comes to implementing or enforcing E911/CALEA. The server not only functions as the central point of call routing where these events can be triggered but also a trusted administrative point in the network which lies within the provider boundary of control.

In a P2P network several things are different. First there is no central point of routing. Depending on the architecture of the network, the routing information may reside in the user nodes themselves (which generally are beyond the administrative bounds). It could be impossible to know call events which serve as trigger points. The only place where this information is reliably available all the time is the user node itself.

It is important to design and deploy the network in such a way that flow information can be reliably detected for P2P calls in real-time. A provider must also ensure that even though the network is using open protocols (like SIP), all software connecting to the provider P2P network is signed and authenticated. This allows the provider to virtually extend his network of trust and control up to the users without installing servers in the network. Security policies will also need to be more host based than network based. Fortunately, technologies already exist to solve these problems. For example, P2P flows can be detected in real-time and these techniques are also used in some of the C/S-SIP based solutions today. Deployment cost of such a solution can be much lower since there is less specializes software to deploy for monitoring and management.

References
TMCnet - The Authority on VoIP, IP Communications, Call Centers, CRM, and Telecom (Retrieved on 29 MAY 2007)
http://www.tmcnet.com/usubmit/2007/05/03/2581919.htm