A Self-Managing SIP-based IP Telephony System based on a P2P approach using Kademlia

Transcription

1 A Self-Managing SIP-based IP Telephony System based on a P2P approach using Kademlia Felipe de Castro Louback Rocha 1, Linnyer Beatriz 1 Programa de Pós Graduação em Engenharia Elétrica, Universidade Federal de Minas Gerais, Belo Horizonte, Brazil louback@gmail.com, linnyer@gmail.com, Abstract. Most of Voice over IP(VoIP) systems are deployed using SIP protocol and based in a client-server architecture. A lot of people and companies could be benefited if the system did not require the configuration and maintenance of central servers. Some proposals are found in the literature. In order to improve the efficiency of such approaches and to provide a complete self-configuring service of IP telephony, we suggest a new solution based on the P2P algorithm Kademlia. According with the results of our experiments, our approach has a better performance when network experiences different kind of delays due to the fact that Kademlia supports concurrent searches, improving the latency in user location, and providing a faster call establishment. 1 Introduction Voice over IP(VoIP) systems are becoming very popular nowadays, with many services being offered in the market. Deployment of services based on IP telephony have good advantages, such as low cost calls and mobility to the users. The configuration and maintenance of such systems requires the configurations of server and specialized employees to do so. Knowledge of the signalling protocols are need, for example. However, a lot of small-size to middle-size companies can t make use of an IP telephony system due to lack of specialized employees or lack of enough money to hire a third-party company to install and keep its telephony IP system. Day by day, distributed applications based on a Peer-to-Peer architecture are becoming popular and with this DHTs (Distributed Hash Tables) are being more utilized. DHTs are known by its decentralization, fault tolerance and scalability characteristics. In many scenarios, deployment of DHTs instead of centralized servers is a good deal. Telephony IP systems can make use of such benefits. Using these DHTs characteristics, we propose in this article another approach to replace VoIP centralized servers by an approach using DHTs, envisioning a complete self-organizing and self-configuring IP telephony system using Kademlia P2P algorithm.

2 2 1.1 P2P Networks There are a great number of definitions to P2P(Peer-to-Peer) system. In the most basic level, a P2P system is a system where multiple software applications interact with each other to realize a task. The node group, as a whole, is some times referred to as an Overlay Network. This contrasts with the traditional client-server model, where a piece of centralized software(the server) process tasks from different clients. The P2P or the client-server model choice is a matter of architecture decision of where the data-processing of the information will happen. A P2P architecture does not necessarily implies that each node must offer all kind of services or store all available data. All nodes on the overlay network must provide all services collectively, but any node can provide just a fraction of the services. For example, a group of nodes may provide a database service and each one may store a small fraction of the database itself. If a big number of nodes share the task, the chances that some entry will be stored in one chosen node is small, but at least one node on the overlay network will store the entry, making sure that, as a group, the nodes offer a complete database system. In a structured P2P architecture, nodes are connected to each other in a logical and well defined structure, such as a ring, a tree or a grid. Many arrangements are possible, but in general an unique identifier is given to a node when it is inserted into the overlay network. This identifier may be specified in a randomly way or determined by the hash of some property of the node, such as his IP address. The ID determines with which other nodes the node must establish contact. For example, a new node must connect to other nodes near him, to some notion of proximity. A very special type of structured P2P system is widely deployed, called DHT (Distributed Hash Table). Some of the most discussed DHTs algorithms are Chord[1], Kademlia[2] and Bamboo[3]. In a DHT, not only the connectivity structure among the nodes is controlled in a mathematical way, but also the way the resources are shared. An ID is given to each resource in the same ID space that the ID given to the nodes. In other words, the range that the values that a resource ID can have is the same as the node ID. The resource identifier is the hash of some property of the resource, such as the filename or another keyword that identifies the resource. The hash of this keywork is done, yielding to the resource ID, and the node with ID closer stores the resource. The definition of proximity and redundancy are very dependent of the algorithm deployed. 1.2 SIP - Session Initiation Protocol SIP [4] is a protocol based and derived from HTTP(Hiper Text Transfer Protocol), so its types of messages and traffic are very similar to the http traffic. SIP is a general protocol to establish and control multimedia sessions, but is has been mostly used in the VoIP field. Devices implementing SIP may be configured to communicate directly with each other, but usually in systems with more than two UAs(User Agents) a

3 3 central server or a proxy is used. In SIP s specification [4] the functions of a server are divided, including the proxy server and the registrar server function. This functions are often implemented together, and for the sake of clarity, in this article we will refer to the server realizing the previous cited functions as proxy server. A SIP proxy keeps information about user location and it is also responsible for all the routing and establishment of calls. 1.3 OpenDHT With the goal to serve applications that would make use of a public DHT, it was created OpenDHT[5]. OpenDHT is a public shared DHT that runs in about 200 machines of the PlanetLab 1 globally distributed. OpenDHT implements the BambooDHT[3] algorithm. Nodes that run OpenDHT code are considered infrastructure nodes. Clients may run codes that uses OpenDHT through RPCs(Remote Procedure Calls), but they do not have OpenDHT code implemented. In this way, applications do not need to worry about DHT implementation. But on the other hand, nodes can not execute specific codes at the infrastructure nodes. In most of the applications today, the DHT is executed through a local library that implements it. The adoption of a library that implements the DHT allows the use of specific code and code optimized to the application, but each application must implement its own DHT. OpenDHT offers an opposite approach, with a smaller flexibility of utilization, but the application programmer does not need to worry about DHT implementation. 1.4 Kademlia Kademlia[2] is a P2P Distributed Hash Table. Kademlia uses the same general approach as others DHTs. An 160-bit ID is associated to each node and it is given and algorithm that searches and locates successively closer nodes to some given ID, converging the search in a logarithmic way. Kademlia treat nodes as leaves in a binary tree, where the position of each node is determined by the smalled unique prefix of its ID. To some given node, the tree is divided in a series of successively smaller subtrees that do not contain the node. The biggest subtree consists of half the subtree that doens t have the node. The next smaller subtree consist of half the remaining tree not having the node and so on. Kademlia protocol assures that each node knows the location of at least one node in each of its subtree, if that subtree has a node. With this warranty, each node can locate another node through its ID by successively querying the best node the knows, trying to locate it in smaller subtrees and finally the search converges to the target node. Usually searches are made in a concurrent way, that is, more than one query is sent at the same time. The parameter α controls this behavior. 1

4 4 Each Kademlia node has an ID of 160 bits. Node IDs are usually randomly numbers of 160 bits. Key IDs are also 160 bit longer. To give a pair <key, value> to a node, Kademlia uses the notion of distance between identifiers. Given two IDs of 160 bits, x and y, Kademlia defines the distance between them as their bitwise exclusive or(xor) interpreted as an integer. Kademlia nodes keep contact information about each other to make routing of messages possible. For each 0 < i < 160, each node keeps a list of tripes <IP, UDP Port, node ID> to nodes with distance between 2 i and 2 i+1 of itself. These lists are called k-buckets. More details about the algorithm can be obtained at [2]. Kademlia is the algorithm implemented in one of the most popular file share software, Emule. 2 Related Work In [6] it is proposed the use of OpenDHT as an alternative to resource location servers of SIP architecture. SOSIMPLE [7] is a project that aims to implement a system without servers, based on a SIP P2P communications. In this project all P2P traffic is managed using SIP messages and the DHT implemented is based on the Chord algorithm. Skype [8] allows users to make free calls to other Skype users as all as paid phone calls to regular phone numbers. Skype is parcially P2P, once that it users centralized servers to authentication and authorization. Skype is based on a proprietary protocol and it is not compatible with other protocols such as SIP and H323. Kundan Singh and Henning Schulzrinne from Columbia University have a project [9] with a similar approach to SOSIMPLE, using Chord as the DHT. The main differences are related to the transport and routing of data inside the P2P overlay network. All works cited above requires Internet connectivity to work, otherwise communication will fail or not even be established. 3 Our Proposal We want our proposal to promote cost reduction, because there will be no need to buy physical servers, and management simplification, once it will not be needed any personnel to keep the system running. To achieve such goals the main point is to remove the need of a centralized resource location server in SIP based systems. The centralized server will be replaced for one adapter that will run locally at the machine and will be responsible for all the server functions. It is a requirement that it will not be necessary to adapt existent UAs and that every UA that is SIP compliant will be able to use the adapter. The adapter was written in C++ using the library Resiprocate 2 to treat SIP messages. The implementation using Kademlia used the code from Anulus project 3. Anulus project implements Kademlia algorithm in C++ and one of the authors of this article is part of the Anulus developer team

5 5 SIP has been the definitive standard adopted by many companies and most of the VoIP providers today have their system based on this protocol. This is why SIP was chosen as the signaling choice. 3.1 Adapter Behavior Call establishment flow in a centralized approach can be made in one of two ways: either using a redirect server or a proxy server. When a server behaves like a redirection server, the caller sends a SIP INVITE to the server, showing the intention of initialize a session with a callee. The redirect server then locates the IP address of the callee. After the IP is located, the server sends back a 302 Moved Temporarily message to the caller. The caller then sends out a new SIP INVITE to the callee using the IP address returned by the redirection message. All the later message flow is done directly between the caller and callee. When the server behaves like a proxy, basically it handles all the signalling between the two parties. It was adopted the redirection server behavior in our adapter. The redirection server does not need to keep track of the sessions established, making its implementation simpler. 3.2 The adapter The adapter is responsible for all the resource location(user location) process as well as user maintenance in the DHT. Basically the adapter can be divided into two main modules: the SIP module, who implements the redirection server functions and SIP message treatment, and the P2P module, responsible for locating and keeping the users in the P2P overlay as well as have the algorithm Kademlia running. Communication between these modules are done through an API(Application Programming Interface) exported by the P2P module, allowing registering and searching of users to be done. 3.3 Initialization Process To enter the P2P overlay network, a node needs to find another node that is already part of the overlay. OpenDHT was used to store a reference to a node in the overlay, so that another node can find a participant node. The idea to store a reference in OpenDHT is based on the idea of Dynamic DNS, but using a public shared DHT to do such. In Dynamic DNS the entries are updated in real time. The reference is store using as key bootstrap.node.br and as value related to the key IP:Port of a node that is already in the P2P network. In this way, when a node searches for that key, it will be returned the information need to contact a node in the P2P overlay. When the adapter is initialized, it searches for the key bootstrap.node.br at OpenDHT. In case of a successful search, the adapter uses that information and starts the bootstrap process.

6 6 In case of an unsuccessful search, initially the node tries to register at OpenDHT the key bootstrap.node.br with its own IP, so that he can become a reference for future nodes that try to join the overlay. After the register attempt at OpenDHT, the node try to locate any other node at the P2P overlay sending a broadcast. Broadcast is used because the unsuccessful search for the key at OpenDHT may indicate, for example, that connectivity with the Internet was lost, or that this is an attempt to establish a telephony IP system in an environment that does not have connectivity to the Internet or even that this is the first node at the overlay. If any node at the overlay notice the search broadcast, it answers it with its IP. The node who generated the request then starts the bootstrap process with that node. Only the first reply to the broadcast is considered. 3.4 User Registration During the register process, the UA send a SIP REGISTER to the adapter. The SIP module notices that the packet is a register message. DHTs store pairs <key, value>. After a user is located in a telephony IP system, the UA need the information regarding the port and IP address of where the UA of the callee is running, so the call can be established. So, when using a DHT to store information regarding users location, pairs are stored using the following format: <User, IP:Port>. In this way, when a search is performed, it will be returned the IP and port where the callee is located. 3.5 User Maintenance The main use of Kademlia today is file sharing. When a search is made for some key, nodes that participate in the search, that is, that are on the search path, cache a copy of the search. In this way, future searches to this key may be faster due to the probability that a node on the search path may have a copy in cache. In the case of telephony IP, the register of users can not be persistent because users may enter and leave the network at any time, and they may have a different IP address each time they come back. The behavior of Kademlia algorithm had to be changed in order to support the needs of telephony IP systems. An expiration time of 3600 seconds was added to the key, and after that the entry is deleted. Softphones must update its registry with the servers at regular intervals. This is done by sending SIP REGISTER messages at regular intervals to the server. We took advantage of this feature to update the user registry expiration time at the DHT. When the adapter receives a SIP REGISTER, a new key is inserted in the DHT and the expiration time is initialized to 3600 seconds seconds is the default time for most of the softphones available today. When it receiver another SIP REGISTER message, the node responsible for that user updates the registry expiration to 3600 seconds again, unless other value is specified at the message. Cached copies of user registries are not updated. But the expiration of cached copies is not a problem because, as a characteristic of Kademlia algorithm, all the searches converge to the node responsible for the key. So, in our case, even

7 7 after all the cached copies expire, during a new search, new cached copies will be formed. 3.6 User Location and Call Establishment As said before, our adapter behaves like a redirection server. When a UA wants to establish a call with another UA, a SIP INVITE message is sent to the adapter, who in turn searches for that user into the DHT. In case where the user is found, a 302 Moved Temporarily is built according to SIP specifications[4], with all the information necessary to redirect the call. This message is sent back to the caller UA and then the caller sends a new SIP INVITE to the callee. When the user is not found inside the DHT, a 404 Not Found message is returned. 3.7 Performance The system can be self-configured and self-mainteined but the effects of this decentralization must be measured. In a centralized approach, user location is made in O(1) while most of the DHTs, including Kademlia, is designed to locate a resource with O(log(n)) messages[2], where n is the number of nodes in the overlay network. This affects the call establishment time, once it will take more time to locate a specific user before the call can be established. In order to measure the efficiency of our approach regarding call establishment time, we used three machines connect to each other by a 100Mbps full duplex link, using a switch to do so. In each node we started 20 adapters, in a total of 60, and after they were started, seven different users were registered. Concurrent searches improve latency in resource location when timeouts for a request is experienced, since more than one request is sent at a time. In order to measure how the concurrency parameter(α) would affect user location time, we divided our experiments in three different scenarios. In our adapter, the request to search for a value has a timeout of 3 seconds before re-transmission. In the first scenario, all 60 nodes did not experienced delay. In the second scenario, half the nodes were programmed to hold the search response for 2 seconds before sending it to the node who made the search. In the third scenario half of the nodes were configured to hold the search responses for 4 seconds. So, in the first scenario no delay at all, in the second a delay smaller than the retransmission timout and on the third one a delay that would cause a new transmission due to timeout. 40 searches were made in each scenario and we repeated the experience for α = 1 and α = 5. The value 1 for α was chosen so we could see how DHTs that does not support concurrency would behave; the value 5 was chosen based on the studies presented at[10]. This way we could check what impact does the concurrency has when the network introduces delay(simulated by the induced delay on half of the nodes). The results can be seen in figure 1 for α = 1 and in figure 2 for α = 5. We could see on figure 1 that as delay increases on the network, the average time to locate a resource also increases. When a 2 second delay were introduced in half of the nodes, the requests that reached those node had a higher response

8 8 7 6 User Location Time 60 nodes and Alpha=1 No Delay 2 second Delay in half nodes 4 second Delay in half nodes 5 Time (Seg) Measure Fig. 1. Time to locate a user at Kademlia with α = 1. time. When a 4 second delay were introduced, the requests that reached those nodes were re-transmitted to other nodes after the 3-second timeout. When the experiment were run with α = 5(figure 2) we can see that the resource location time were not that much affected. That happens because five requests are sent concurrently, and if some requests reach nodes pre-programed to introduce a delay, some would still reach nodes with no programmed delay. With these experiments, we can conclude that when multiple concurrent requests are sent we have a better chance to get a faster response even when some nodes on the overlay network are experiencing network congestion. When α = 1, Kademlia is similar to Chord in message cost [2]. Chord does not support concurrent searches. We could see from our experiments that an approach that supports concurrency can improve the mean response time for user location. All other approaches found on literature, but Skype, use Chord as the underlying DHT. 4 Future Work 4.1 NAT Traversal Users behind NAT is still an open issue. At the present time, we assume that all users can be found on reachable IPs. One alternative would be the implementation of some solution like STUN(Simple Traversal of UDP through NAT) on the adapters with valid IP address. 4.2 Authentication At the present time we do not provide any sort of authentication and assume that all users can be trusted. But this can not be a valid assumption on various

9 User Location Time 60 nodes and Alpha=5 No Delay 2 second Delay in half nodes 4 second Delay in half nodes Time (Seg) Measure Fig. 2. Time to locate a user at Kademlia with α = 5. scenarios. The solutions listed on section Related Work do not treat authentication in a very effective way. One alternative would be the PGP web of trust model. Another one would be to store centralized certificates in a central point in the network, but this would require a centralized authority to be consulted. In the case of ad-hoc or transiente networks, no verification may be required or desirable. An authentication system is still an open issue and is under analysis. 5 Conclusion Our approach is effective in building a decentralized, self-configuring and selfmanaging telephony IP system. Self-configuring is provided by the fact that it is not necessary to install and configure a centralized server. Once the adaptor is initialized, not further configuration is required. Self-managing is provided by the fact that the system does not require any person to manage it. Users joining and leaving the system are handled by the P2P network without the need of a centralized server to store user information. Our solution works well on environments with Internet connectivity or without it. For example, if the connectivity to the Internet of a company is lost, the IP telephony system would not stop in our solution. In scenarios where there may not be an Internet connection available, our approach still works. Our solution is the first one that uses the algorithm Kademlia for such purpose. Concurrent searches can reduce significantly the mean delay time in resource location when nodes are experiencing packet loss or high traffic as we could see from our experiments. Other approaches found on the literature do not use concurrent searches because of the DHT deployed. The fact that our approach is the first one to use Kademlia also leads our work to be the first

10 10 one to analyse how the concurrency parameter on Kademlia can benefit user location time on decentralized IP telephony systems under different network circumstances. A decentralized approach offers cost reduction because there is no need to buy any special hardware(servers). Another characteristic is management simplification, once the systems manages itself and there is no need to have someone specialized to keep the system up and running. In scenarios where there is the need to rapidly establish a communication system, such as a disaster area with wireless network or a conference, for instance, installation of servers can be timeconsuming and our solution provides agility. Our solution works with softphones, but it could be used a similar approach to code the adapter and embedded it inside hardphones. Our adapter is SIP compliant, it can be used with any softphone that supports SIP. References [1] Stoica, I., Morris, R., Karger, D., Kaashoek, F., Balakrishnan, H.: Chord: A scalable Peer-To-Peer lookup service for internet applications. In: Proceedings of the 2001 ACM SIGCOMM Conference. (2001) [2] Maymounkov, P., Mazires, D.: Kademlia: A peer-to-peer information system based on the xor metric. In: IPTPS 01: Revised Papers from the First International Workshop on Peer-to-Peer Systems, London, UK, Springer-Verlag (2002) [3] Sean Rhea, Dennis Geels, T.R., Kubiatowicz, J.: Handling churn in a dht. Technical Report UCB/CSD , EECS Department, University of California, Berkeley (2003) [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., Schooler, E.: Sip: Session initiation protocol (2002) [5] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stoica, I., Yu, H.: Opendht: a public DHT service and its uses. In: Proceedings of the ACM Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, New York, NY, USA, ACM Press (2005) [6] Singh, K., Schulzrinne, H.: Using an external dht as a sip location service. Technical report, Department of Computer Science, Columbia University, CUCS , New York (February 2006) [7] Bryan, D.A., Lowekamp, B.B., Jennings, C.: SOSIMPLE: A serverless, standardsbased, P2P SIP communication system. In: Proceedings of the 2005 International Workshop on Advanced Architectures and Algorithms for Internet Delivery and Applications (AAA-IDEA 2005). (June 2005) [8] Baset, S.A., Schulzrinne, H.: An analysis of the Skype peer-to-peer Internet telephony protocol. Technical Report CUCS , Columbia University (September 2004) [9] Singh, K., Schulzrinne, H.: Peer-to-peer internet telephony using sip. In: NOSS- DAV 05: Proceedings of the international workshop on Network and operating systems support for digital audio and video, New York, NY, USA, ACM Press (2005) [10] Li, J., Stribling, J., Gil, T., Morris, R., Kaashoek, F.: Comparing the performance of distributed hash tables under churn (2004)