Open Source Research and Education Networking Project in Malawi. VoIP

Transcription

1 Open Source Research and Education Networking Project in Malawi (OSREN-MaREN) VoIP Design and Interoperatibilty Version IK ICT and Communication Systems Design Summer 2008 Date: 10 July Teaching Team: Principal: Harry Gombachika Champion: Bjorn Pehrson Coach: Hans Bjurgren Co-Coach: Voravit Tanyingyong, Eneas Hunguana, Gustavo af Sillen de Mesquita, Thomas Andersson, Erik Eliasson, Guillem Cabrera Submitted by: Abdelraheem Tamimi (15hp)

2 Royal Institute of Technology Revision History Date Version Description Author(s) , First draft version Asim Shahzad Revised Draft Abdelraheem Tamimi Asim Shahzad Chang Tong

3 Table of Contents 1. Introduction: Purpose: Functionalities of VoIP: VoIP Participants User Agent Proxy Server Registrar server Location Server: Domain Name Server (DNS) Server: Reflector Communication architecture and Scenarios: Call in a Campus (Same campus or two different campuses) Conference call using Reflector Direct communication using IP Address Backup, Redundancy and load balancing: Interoperatibilty SIP with H Hardware Phone to MiniSIP Soft phone Usage of different user agents: NAT...9 References:... 9

4 1. Introduction: 1.1 Purpose: Purpose of this Design Document is to describe the design, architecture and interoperability of the overall VoIP service, as well as the components of the VoIP service. This document also discusses the interaction between the components and talks about the necessary dataflow between them. The design of the platform and its components is described in sufficient detail so as to enable everyone to understand the underlying basics of the VoIP service. 1.2 Functionalities of VoIP: Our VoIP service provides different functionalities that includes, Audio call Video call Multi-participants video conference Instant messaging Call logging 2. VoIP Participants The Overall design of VoIP using SIP consists of a number of participants that includes User Agent, Proxy server, Registration server, Location Server and the Reflector. All these participants have different functionalities to perform and these servers are placed with other servers in the network. 2.1 User Agent User agent is an entity that can initiate the sessions and can receive the session Requests. A user agent consists of user agent client and user agent server so basically the user agents initiate call and can also receive a call. In our case we have the MiniSIP user agent which will be used in order to communicate with each other. 2.2 Proxy Server Proxy server is a form of server that forwards request from one user agent to other proxy server or another user agent. Hops towards the destination from Proxy server could be many or less depending upon the location of the callee. Proxy server also maintains the state of the call only, they are not aware of the content of the call so it is one of the good things that SIP has privacy. Proxy servers mere not only forward the request, create and maintain logs, above all they do authentication which is the most important role that proxy servers perform. In our case we are using Open SER as a proxy server and also each university has its own Proxy server in order to make and manage calls more efficiently. 2.3 Registrar server Registrar server basically deals with the registration requests. In which a client send its identity and capability to sever and the server then checks the identity with the help of a pre saved entries

5 in database that is working at the back end. With the help of registering we got a binding between the user agent global address and its physical address for instance asim@ to asim@khh.com. 2.4 Location Server: SIP Registrar server then send the information, that the user is registered to the following IP Address that will help the Proxy server to route the call when someone wants to communicate with the user. 2.5 Domain Name Server (DNS) Server: DNS server is basically used to resolve the SIP URI to the IP address to make communication smooth. 2.6 Reflector Reflector is like a bridge which helps you to make conference calls within the universities and also between the universities. It is another server in your domain which is running on high speed link to enable you to provide conference call facility to your users whether it is voice or video. Each user connects to the reflector in order to participate in the conference. As every university has their own reflector but what if there is a university which is much far away from the other and you to use the reflector of that university. Then in that case we suggest that there should be a national reflector and it should be at a distance where everyone can connect with the reflector with less delay and cost. So that s how the universities which are much far away can communicate with each other with fewer problems. 3. Communication architecture and Scenarios: The general architecture of the VoIP communication is shown in the figure 1.we can also see that how the VoIP service will work. There are different scenarios that how the communication took place between the users, like it s different for communicating the user in the same domain and it is different if the user wants to communicate with a user who is in other domain. So all this communication is through proxy server and other servers that should be supposed to be in the network but we can also do the communication directly if we know the IP address of the other party. So in our case for discussion we will take the different domain scenario and point to point communication. We can characterized the communication as, Call in Campus (Same campus or two different campuses) Conference call using Reflector Direct communication using IP Address

6 3.1 Call in Campus (Same campus or two different campuses) The basic communication work like, the SIP user agent connect to the Proxy server and through the Proxy Server communicate to another proxy and then to a particular user agent. All the servers work as they are discussed above in the Section 1. Figure 1: General design of the VoIP So according to our scenario we have to enable voice and video communication in a campus, between two campuses of a university and between different universities. So according to this we can divide this section in the following parts, A call between one campus A call between two campuses of the same university A call between two different universities The scenario will work like this way that if anyone wants to call within the campus then he/she can do it easily with the help of user agent, proxy server and all other hardware needed in a domain. So this is basically making calls in a same domain. In the second scenario if a university have different campuses, and if you want to call from one campus to another then you can do it easily by following the process that is discussed above. Regarding the proxy server each campus can have their own proxy server or can use the same proxy server depending upon certain condition like delay, link speed etc. In the last scenario anyone wants to have call from one university to another university then you will have to connect to your proxy server then your proxy server connect to other proxy server on your behalf and the other proxy server check the person called if it is available then the call is routed towards the person if it is not then some sorts of error message is sent to the other party regarding the unavailability of the user. The communication scenario is shown in the figure: 1.

7 3.2 Conference call using Reflector The design of our VoIP service is a bit different from the traditional VoIP service design. In our service we introduced a reflector which basically use for conference call, reflector basically act as a bridge to provide help in conference call. Anyone who wants to join the Conference call will have to connect the reflector. In our case each university has its own reflector to use for conference call between different universities and also can be used in between different campuses. With the help of reflector you can do voice and video conference calls within the university campuses and also between the universities. Figure 2: Interdomain Communication using Reflector 3.3 Direct communication using IP Address We can also have peer to peer calls between the users only if we know the IP address of the users. So in that case we only have to put the IP address of the user and connect to the user directly. Figure 3: Direct Communication

8 4. Backup, Redundancy and load balancing: In case of backup our suggestion is to use a backup proxy server to provide backup in case of failure. The backup server is all the time updated from the primary server when there is any change in the server. So this can provide the university facility that their communication cannot be affected for long even if the primary server goes down. So in case of a backup server, we can use that server as to load balance between the servers if there is an extra load on to the primary server. 5. Interoperatibilty In this section we will see the Interoperatibilty of different protocols, devices, user agents etc. SIP with H.323 Hardware Phone to MiniSIP Soft phone Usage of different user agents NAT 5.1 SIP with H.323 SIP and H.323 are two different protocols but the nature of the protocols are same both are used for signaling purposes before establishing the actual media session between the users. As these two protocols are different so they are not compatible to each other. A SIP only device can only communicate to SIP only device and also the H.323 only device can communicate with H.323 only device. There is research going on to make the both protocols compatible. In an IETF draft [1] that describes the SIP-H.323 Interworking Function (SIP-H.323 IWF) that will allow the communication between the users from different protocol. This function basically translates the SIP signals into the H.323 compatible signals and vice versa. In another paper [2] there is a description that how we can make both the protocols compatible. This paper also tells us that how the users that are from different protocols can register with each other. So this paper consists of user registration, call sequence mapping and session description. There is no perfect solution is available right now about the compatibility of SIP and H.323 but there is research going on to make the both the protocols compatible. 5.2 Hardware Phone to MiniSIP Soft phone Hardware phones are the devices which provide us the same basic functionality which the soft phone provides us. So if we want to communicate with the MiniSIP by using Hardware device then there are two possibilities that either we can communicate or we cannot communicate. We can only communicate if the hardware device is SIP supported. But if the Hardware device is not

9 SIP supported then the communication between the user s is not possible. So in order to make communication both the devices should support the same protocol. 5.3 Usage of different user agents: MiniSIP also provides facility to the users to use different SIP soft phones like Xlite and other available that that work on SIP communication. Xlite is tested with the MiniSIP and the results were successful. So we can use the Xlite as a user agent as well and also other compatible soft phones. 5.4 NAT In order to avoid the NAT, MiniSIP uses STUN support for NAT traversal using a STUN server. STUN basically assists the devices behind the firewall or router with their packet routing. It is good solution to provide traversal but it is not the complete solution which we can use for communication. References: [1] SIP-H.323 Interworking Requirements by Hemant Agrawa,Radhika R. Roy, Vipin Palawat,Alan,Johnston,Charles, Agboh,David Wang, Kundan Singh, Schulzrinne. Availabale at: Last viewed:1 July, 2008 [2] Kundan Singh and Henning Schulzrinne (Columbia Univeristy, New York) Interworking between SIP/SDP and H.323 Architecture, iptel2000 Program April 12-13, 2000