Distributed Hash Table (DHT) In Structured Peer-to-Peer SIP Overlay


peersDistributed Hash Table (DHT) is used in structured Peer-to-Peer overlay for resource location and discovery. In SIP world, the resource can be the contact list (physical addresses) associated with an AOR (SIP/SIPS URI that points to a user on domain -virtual address of the user). The mappings between the AORs and the contact lists will be distributed amongst the peers in the SIP overlay. In this way we get a distributed registrar functionality for SIP.

There should be an interface for the DHT so it can be used without caring about the implementation and it can easily integrate with the SIP server so the server can work in P2P mode. Basically the functions that need to be implemented are: Join (join the overlay), Leave (leave the overlay), Lookup (search for a resource using the AOR as a key), and Store (store the resource). For example the lookup function works as following:

  • Using the AOR as a key to find the appropriate node/peer. The hash value of the key is used to find the node/peer ID.
  • Then the selected node/peer will do normal hash table (HT) lookup to get the value/resource/contact-list

The mappings {AOR, Contact List} can be stored persistently on disks in a key-value databases like Berkeley DB.

The IETF standards body is working on P2P-SIP. There is a working group called p2psip where you can find the internet drafts (working documents) related to P2P-SIP. For example the RELOAD (RFC [6940]) is a signaling protocol for resource location and discovery. It specifies “chord-reload” as a mandatory DHT algorithm to be implemented. The purpose of this work is distributed SIP registrar. The RELOAD works with SIP to enable the distributed SIP solution. The RELOAD can be used by other protocols and not only SIP (e.g. A Constrained Application Protocol (CoAP) usage for RELOAD: Internet Draft: draft-jimenez-p2psip-coap-reload-10).

But why P2P SIP mode. This is because in P2P:

  • There is no one point of failure.
  • Less cost: avoid having service provider (Paying) + delete nodes/peers on low demand.
  • Capacity: Adding new nodes/peers on high demand.

The peer to peer SIP overlay is very suitable to be built over Openstack cloud where the automated creation and deletion of nodes/peers is based on predefined policies. The peers are defined in an autoscaling group where they are scaled up and down based on the autoscaling policies. When a node is determined to leave the overlay based on the cloud policies, the node starts the leave process where the configuration is delivered to it from the cloud (DELETE lifecycle hook). The trigger to add (<=> join the overlay) or delete server (<=> leave the overlay) are controlled by the cloud orchestration service (the scaling policies). The policies itself are based on CPU utilization, Load,…etc.

Creative Commons License
The content of this blog is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.