Implementation of a Fully Functional VoIP Server Inside of a Campus Network

Transcription

1 Implementation of a Fully Functional VoIP Server Inside of a Campus Network Prepared for Ronny L. Bull Lecturer, Computer Science Department SUNY Institute of Technology By Matthew Lapinski Student, NCS416 SUNY Institute of Technology and Konrad Armitage Student, NCS416 SUNY Institute of Technology 1

2 Abstract The increased adoption of voice over IP as a replacement for the traditional public switched telephone network has created a mechanism for businesses and consumers alike to implement their own custom built communication network. For an expanding collegiate academic club, VoIP can be harnessed to create private extensions, conference bridges, and SIP trunks out to the PSTN. By using existing hardware and network connections, the aforementioned academic club can create an enterprise level communication network that not only increases efficiency, but also projects a professional appearance to potential employers. Introduction Data communications networks have become a cornerstone of life in the 21st century, and as is only natural, voice communication networks have started to make the jump from the traditional public switched telephone network (PSTN) to voice over IP (VoIP). With VoIP, telephone calls are not routed over the typical copper telephone wires running alongside streets, but instead over the same lines as internet traffic through packet switched networks. This implementation allows for cost savings since most homes and businesses already purchase internet connectivity from their internet service provider (ISP). Instead of paying separately for data and voice connectivity, only a data connection is necessary. Under the old copper wire, PSTN system, the process of switching phone calls between internal business lines and external lines was done through the private branch exchange (PBX), which was typically a confusing nest of wires inside a locked closet. Also, connections between satellite offices required the renting of a dedicated line to ensure reliability and confidentiality. The enterprise use of voice over IP has removed the need for physical PBXs and dedicated lines through the use of internal PBX servers and virtual private networks (VPN). The PBX servers, such as the popular open sourced Asterisk, handle all of the internal switching of calls between intra and inter network users, while a VPN creates an encrypted data tunnel between two endpoints to ensure confidentiality of calls from authorized remote locations. 2

3 While the advent of VoIP has translated into cost savings for corporations and small businesses alike, it has also become a versatile tool for consumers as well. With a little knowledge about networking and the general voice over IP system, a consumer can remove the need for the outdated landline phone and create their own phone system. While connections to the PSTN still require a SIP/IAX2 trunk from a provider, a home user can still create a complex network complete with conference calling and multiple extensions without having to pay for numerous incoming lines. Using this same consumer type deployment of a VoIP system, another application would be for a collegiate academic club to allow for remote conferencing into meetings, as well as extensions for various club rooms and officers. In this paper, we will discuss the creation of a fully functional VoIP system for the Network and Computer Security (NCS) Club at the State University of New York Institute of Technology (SUNYIT). Methods and Materials For this deployment, we attempted to implement the voice over IP system with a minimal amount of cost by using available equipment and open source software. For our PBX server, we used a Dell Poweredge 860 server with a CentOS 6.4 x86_64 minimal install for our host operating system, and Asterisk compiled from source for our private branch exchange software. Peripheral devices also included Ekiga softphones (version 3.2.7) and a Sipdroid application on a Samsung Galaxy Player for testing. The server initially resided on the NCS Club private network during the provisioning process, but was later migrated to the larger Computer Science Department network once the configuration of the host operating system was complete. A publicly routable IP address was assigned to the Asterisk server by the system administrator of the Computer Science Department network, as well as a destination network address translation (DNAT) rule to route all traffic inbound to to the Asterisk server at A diagram of the general network map is displayed below in Figure 1: 3

4 Figure 1: General Network Diagram As is evident from Figure 1, the Asterisk server does not reside on the edge of the Computer Science network, yet it is publically routable from the address. Since our SIP VoIP system operates on a number of ports, some of which as dynamically allocated, a port forwarding system would not be feasible for routing inbound traffic to the Asterisk server. Instead, a pre processing translation was necessary to strip the destination address ( ) from inbound traffic, and replace the address with without changing the source address information. Essentially, this process allows all traffic to pass through the GW router without any changes to port or source address information. From a security standpoint, this process undermines the firewall rules put in place at all levels above the Asterisk server, and all internet traffic is able to infiltrate the Computer Science network down to the Asterisk server. For this reason, specific firewall rules needed to be implemented on the server to prevent the opening or access of unnecessary ports from the outside world. A sample 4

5 of the iptables INPUT chain rules are included below in Figure 2: Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination K DROP all * * / ACCEPT udp * * / /0 udp dpt: ACCEPT tcp * * / /0 tcp dpt: ACCEPT tcp * * / /0 tcp dpt: ACCEPT udp * * / /0 udp dpts:10000: ACCEPT all lo * / / K 154M ACCEPT all * * / /0 state RELATED,ESTABLISHED ACCEPT tcp * * / /0 tcp dpt: ACCEPT udp * * / /0 state NEW udp dpt: M LOG all * * / /0 LOG flags 0 level 4 Figure 2: Iptables Rules for the Asterisk Server As illustrated in Figure 2, the 5 major services necessary for running and maintaining an Asterisk server are SIP (tcp/udp 5060), SIP over TLS (tcp 5061), RTP (udp 10000:10200), SSH (tcp 22), and NTP (udp 123) (Madsen, Van Meggelen & Bryant, 2011). For security purposes, the default RTP port range of 10000:20000 has been cut down from to 200 ports, and SSH access is only allowed from the internal Computer Science GW network at /16. Another important fact to notice is the explicit iptables rule to drop any traffic from which was added after repeated unsuccessful attempts by the Turkish IP to authenticate to the Asterisk server. The traffic was dropped instead of rejected in order to create the illusion that the server has gone offline indefinitely, and within a minute of deploying the iptables rule, the inbound traffic ceased. With our networking and security properly configured, we then proceeded to configure the Asterisk server for multiple extensions, a conference bridge, and an outgoing SIP trunk to connect to the PSTN. Four extensions were created by editing the extensions.conf, sip.conf, logger.conf, modules.conf files on the Asterisk server according to the format in Ronny Bull s NCS416 SIP Lab writeup (Bull). In addition, the rtp.conf file was edited to reflect the iptables rule restricting the RTP port range from 10000:20000 to 10000: At this point, the Asterisk service was reloaded and two Ekiga 5

6 softphones were connected to the server from the internal Computer Science GW network to confirm internal network connectivity. After the successful registration of the devices, a test call was placed between the two extensions and the basic configuration of the Asterisk server was validated. The next goal of the project was to utilize the confbridge module to create a functional conference bridge on the server. Because of the ease of use of Asterisk, this process was as simple as loading the confbridge module in the modules.conf file and adding a dialplan extension for the conference bridge in the extensions.conf file as such: [conference] exten => 600,1,Answer() same => n,confbridge(600,,default_user,default_menu) It is also important to note that an include => conference declaration must also be added to the extensions.conf file to include the conference context. Essentially, by dialing extension 600, the user to transferred to the confbridge module and a conference is created using the default settings in confbridge.conf. While the default settings in confbridge.conf are robust enough to get a basic conference bridge online, further customizations can be made in the confbridge.conf file such as default notifications, sounds, and menu preferences. An interesting feature of the confbridge module is the ability to record the conference to an audio file (in /var/spool/asterisk/monitor) at a sampling rate of 8kHz, as well as requiring a pin to enter the conference, both of which we decided to implement in our deployment. With the Asterisk server configured for internal calling and conferencing, our next goal was to implement an outbound SIP trunk for calls to the public switched telephone network. With a plethora of SIP trunk providers, our choices were far from limited. We decided on SIP.us for their generous free trial offer of 60 minutes, since we did not want to sign up for a monthly contract during the test phase of the project. After a quick registration process that did not require a credit card, we were given a trunk number, password, and a set of instructions to connect to the SIP provider ("Sip trunk configuration," 2013). The first order of business was to set up a entry in the channel configuration file (sip.conf) for the route 6

7 for the outbound trunk. The additional information is listed below, with the trunk and password redacted for security reasons: [XXXXXXXXGW1] type=peer insecure=port,invite host=gw1.sip.us port=5060 dtmfmode=rfc2833 canrevinvite=no disallow=all allow=ulaw qualify=yes qualifyfreq=30 nat=yes trustrpid=yes fromdomain=gw1.sip.us username=xxxxxxxx secret=xxxxxxxx context=from trunk rfc2833compensate=yes session timers=refuse In addition, a pattern matching extension was added to the extensions.conf file to capture certain dialed extensions to be sent out on the SIP trunk: exten => _9.,1,Dial(SIP/${EXTEN:1}@XXXXXXXXGW1,30,r) According to the extension pattern, all dialed extensions that begin with the number 9 are stripped of the 9 prefix and sent over the outbound trunk to the PSTN. We decided to adhere to the industry standard of dialing 9 for outbound calls, but any pattern can be specified. Results With all aspects of the voice over IP system in place, extensive testing was done to ensure all aspects of the network, security, and server configurations were implemented correctly. External connections from private networks outside of the Computer Science Department GW network required port forwarding 7

8 rules to be put in place on private routers for proper SIP and RTP communication. After doing so, the Ekiga softphones successfully registered and placed calls through the Asterisk server, as well as created/joined conference bridges. In addition, outbound calls to the PSTN were completed successfully. Discussion While the deployment of a fully functional voice over IP system inside of a multiple NAT d campus network was successful, there was a noticeable lag in all communications outside of the SUNYIT Computer Science Department network. Unfortunately, this lag is most likely due to the amount of processing that must be done to route calls both into and out of the network, as well as through the general internet. Since RTP is a real time protocol, it is time sensitive, and a one way latency of more than 150 ms becomes easily noticeable during a call (Unuth). Testing revealed that one way latency between an Ekiga softphone on an outside private network and the Asterisk server was approximately 100 ms, and between the SIP provider and the server to be ~65 ms. While these numbers fall into the acceptable latency for a VoIP call, they are far from ideal. Efforts were made to reduce the amount of latency in the system by rearranging the priority of iptables rules to reduce processing time, but with little impact. Due to the nature of transport over a packet switched network, quality of service (QoS) is done with a best effort approach, meaning that unless each router along the path is configured specifically to allow prioritization of VoIP traffic, there is not much that can be done. In a corporate environment, further configuration of the internal and edge routers could lead to better quality calls, but that was not possible in the campus network configuration used in this project. Conclusion While the voice over IP system created in the project has provided to solid foundation, there is still much work to be done to implement better quality and security. While the quality improvements were discussed in the previous section, further security in the system can be implemented with the use of SIP over TLS on tcp port While this would encrypt the SIP transmissions, including authentication 8

9 information and extensions, this could only be done on SIP devices directly connected to the Asterisk server. Since SSL/TLS encryption works based on certificates, a self signed certificate from the Asterisk server would need to be placed on each authorized SIP device. Of course, this could not work for calls between the server and the PSTN, since regular landlines and cellphones do not have the ability to store certificate information. That being said, a self signed certificate was created on the server, and TLS enabled within the sip.conf file for future work with TLS enabled SIP phones. Since the Ekiga softphone is not TLS enabled, we could not fully implement SIP over TLS. Overall, this was a very ambitious and productive project that can not only be used immediately by the NCS Club, but can be later developed to create a more robust and versatile voice over IP communication system. References Bull, R. (n.d.). Sip lab. Retrieved from Madsen, L., Van Meggelen, J., & Bryant, R. (2011).Asterisk: The definitive guide. Sebastopol, CA: O'Reilly Media, Inc. Sip trunk configuration asterisk. (2013, March 25). Retrieved from SIP Trunk Configuration Asterisk Unuth, N. (n.d.). Latency in voip. Retrieved from 9