Implementation and Analysis of a Mobile Aerial Wireless Network

Steven Bosch, Pradosh Kharel, Eli Katz (A paper written under the guidance of Prof. Raj Jain)

Download

Abstract

Unmanned Aerial Vehicle (UAV) technology combined with wireless mobile networking is a growing area of research with promising preliminary results. This technology could be used to quickly deploy a wireless network over a large area during emergencies where typical networks might fail. In this paper, we implement and perform experiments to test an implementation of a mobile wireless network. We also perform experiments to test the seamless handover capability of the network as well as test the performance of common applications like Voice over IP (VoIP) while using UAVs. Using Raspberry Pis and OpenWrt to create a wireless distributed network with seamless handover, we were able to get average stall periods of 1.615 seconds for a VoIP call and 37.26 seconds for file transfers using Secure Copy Protocol (SCP). We also measured signal strength and packet loss of the wireless network when deployed on a UAV.

Keywords

seamless handover, Raspberry Pi, OpenWrt, UAV, WDS, VoIP, SCP, DD-WRT, wireless network, Zoiper, Asterisk

See Also

Experiment Design and Analysis of a Mobile Aerial Wireless Mesh Network for Emergencies, Seamless Handover among WiFi Access Points on Raspberry

Table of Contents

• 1. Introduction
• 2. Network Design
  • 2.1 Communications Server
  • 2.2 Communication Software
  • 2.3 Routers
• 3. WDS and Handover Tests
  • 3.1 Seamless Handover Verification
  • 3.2 SCP Test
  • 3.3 VoIP Call Test
• 4. UAV Experiment
  • 4.1 Setup and Design Considerations
  • 4.2 Lab Test
  • 4.3 UAV Flight Test
• 5. Future Work
• 6. Summary
• 7. References
• 8. Acronyms
• 9. Appendices
  • 9.1 Router Setup
  • 9.2 Asterisk Installation on CentOS 7
  • 9.3 Adding a New Asterisk Client
  • 9.4 Installing Zoiper on Client Device:

Aerial wireless mobile networking is a growing area of research with promising preliminary results. In the last several years, Unmanned Aerial Vehicles (UAVs) have become affordable and reliable, but their potential as infrastructure for wireless networks remains untapped. UAV-based networks would be more maneuverable and adaptable to their circumstances than existing infrastructure. One important potential application is a disaster-relief scenario where permanent communication systems have been rendered inoperable. Deploying a UAV-based network in that situation could support rescue efforts by allowing civilians, aid workers, and law enforcement to communicate.

However, one of the primary challenges associated with UAV technology is its heavy power consumption. The need for large batteries reduces the carrying capacity of the UAV and limits its flight time. In an aerial network, UAV units would have to circulate due to battery constraints. Building on the prior research of Dali [Dali14] and Yijian [Yijian16], our goal was to implement a seamless handover procedure in a mobile aerial network to allow units to be switched out without interrupting service. This can be done by implementing WDS (Wireless Distribution System). WDS is a system that enables interconnectivity of access points with the same backend network. WDS is ideal for our project since the coverage area can be quickly expanded simply by adding new UAVs with on-board routers and it provides seamless handover, as desired.

The remainder of this paper is organized in the following way: In Section 2, we describe the structure of our wireless network and design choices for the server, routers, and clients. In Section 3, we describe the implementation and verification of the seamless handover procedure. We then describe the setup, testing, and results of the wireless network and handover procedure when deployed on UAV units in Section 4. Finally, Section 5 presents ideas for future work in this area of research.

In a disaster-relief scenario, UAV units bearing routers could be deployed to cover a broad area. The routers would act as access points (APs) that rescue workers or civilians could connect to for communication and emergency procedures. The UAV routers would mediate the connection between user devices like computers or smart phones through a central base router on the ground. This ground router would relay data as a communications server that establishes connections between clients and transfers data between them. This topology is depicted in Figure 1. In this section we discuss the implementation details of our network’s server and clients, the software we use for our Voice over IP (VoIP) communication, and the routers that define our network topology.

The communications (VoIP) server controls the transmission of data packets to enable VoIP communication between devices on the network. Our implementation of this server consists of the Asterisk framework running on a consumer Dell laptop with the CentOS 7 operating system. CentOS 7 is the latest version of the CentOS Linux distribution, a free and widely-used operating system. Asterisk is a free, open-source communications framework that allows a computer to operate as a VoIP gateway. To manage the Asterisk system, we used the FreePBX web-based GUI. Installation and configuration instructions for Asterisk can be found in Appendices 9.2 and 9.3. In the next subsection we describe our choice of software for the clients of our network.

The communication system we used in this project is VoIP. VoIP is a group of technologies for making phone calls using an internet connection rather than using the traditional public switched telephone network. VoIP has many associated benefits, such as cheap or free calls that utilize existing Internet access and voice communication in areas without cellular network coverage. These technologies and associated protocols can be used by smartphones, computers, and other internet-connected devices [Fcc01]. In a disaster-relief scenario, the portability that VoIP offers allows clients on any platform to communicate over the network without having to rely on cellular communications infrastructure, which may not be intact or reliable given the circumstances. We used the Session Initiation Protocol (SIP) to coordinate the establishment and termination of the voice call. SIP can operate on many transport-layer protocols, such as User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or Stream Control Transmission Protocol (SCTP) [Ietf01]. Our network may not be entirely reliable due to its mobile nature, and voice communication can be intelligible with missing packets, so the protocol needs to be tolerant of missing packets. Therefore, UDP was a desirable protocol for our experiment’s transmissions because it is connectionless -- clients do not maintain a persistent connection to transmit data.

For the VoIP client, we used Zoiper: a free, secure, cross-platform internet telephony application. Zoiper allows users to have a dedicated extension within the Asterisk communication network. Extensions set up on the Asterisk server can be linked to client devices running Zoiper. We were able to successfully configure and use Zoiper on the iOS and OSX client devices we used for this project. Instructions for Zoiper client installation and configuration can be found in Appendix 9.4. These client devices connect to our network through Raspberry Pis that act as routers, which we discuss in the next subsection.

A key component of the overall project is the implementation of a wireless network that provides connectivity to devices in a large area. Since the UAVs have limited battery, we can expect certain access points to become unavailable abruptly. In such a scenario, we would want disconnected clients to transfer connections over to available access points. To achieve this, we use the Wireless Distribution System (WDS) to broadcast a single network using multiple access points. When an access point goes down, clients do not have to go over the initial handshaking procedure when connecting to active access points, and the network interruption is limited [Openwrt01].

For our ground station, we used a Linksys WRT54GL router running DD-WRT, an open-source Linux based firmware. For the UAV routers, we used Raspberry Pis with OpenWrt as wireless, mobile access points. Raspberry Pis are light, low cost devices that make them ideal for our project. OpenWrt is an open source Linux based firmware that can be installed on the Raspberry Pi to convert it to a network router. To enable wireless on the Raspberry Pi, we used Alfa AWUS036NHR v2 USB WiFi adapters. This implementation of WDS using Raspberry Pis and OpenWrt is based on previous research [yijian16] [Yijian16].

Our network is simple and uses many components that are either open-source and free or inexpensive. Low price is a big factor not only because it allowed us to conduct this experiment and allows others to recreate it, but also because if this network were to be deployed over a disaster area, rescue efforts would require many UAVs to provide service to a broad area. Furthermore, the implementation of these devices and protocols are straightforward and easy to use. With the network now implemented, we will now discuss the goals of our research and the tests conducted.

As discussed in Section 1, the major component of WDS of interest is seamless handover. In this section, we describe our implementation of a WDS network to test the effects of handover on large file transfers and VoIP calls. We begin this section by giving an overview of seamless handover and test the network’s capability by interrupting our client’s connection. We then look at a test of handover while performing a file transfer and another test while performing a VoIP call. The steps required to configure the Raspberry Pis and the base router are given in Appendix 9.1.

To test our WDS network for handover, we first setup the network shown in Figure 2 using two Raspberry Pis. The Client machines were notebooks. All of the network connections are wireless except the link between the VoIP server and the router.

To test handover of clients, we first setup the network shown in Figure 2 using two Raspberry Pis. The client machines were MacBook Pros. All of the network connections are wireless except the link between the VoIP server and the router.

We also tested the effects of handover on a large file transfer using Secure Copy Protocol (SCP). SCP requires a TCP connection, so the client will take some time to confirm that its connection is no longer working before attempting to establish a connection through a new router. Therefore, we can expect some delay time when disrupting the connection before it is re-established. Using the same network shown in Figure 2, we initiated a file transfer between Clients 1 and 2 and turned off the Raspberry Pi 1 AP radio during the middle of the transfer. We then used Wireshark, a packet sniffing software, to capture and analyze the handover based on TCP sequence IDs. An example of this is shown in Figure 4.

Figure 4 shows the sequence number of TCP packets over time. For this particular experiment, the AP was disabled at around the 10-second mark. This disruption resulted in a delay between the transfer of successive TCP packets (stall time). Continued transfer was finally re-established around the 26 second mark. We repeated this procedure for 10 file transfers, the results of which are shown below in Table 1.

As we can see from Table 1, the stall times are very large, going as high as 68 seconds. The average stall time was 37.26 seconds. Such a long delay can result in failed transfers. And while we were able to perform our file transfers, this protocol is not well-suited to our needs. In the next section, however, we shall discuss our main goal of performing handover during a VoIP call, which sends its data via UDP.

A realistic use of an aerial WDS network could be VoIP calls, especially if deployed during emergencies where traditional networks might have failed. We tested the seamless handover using the softphone software Zoiper and the same network as shown in Figure 2. We established calls between the two clients, turning off the AP radio on the Raspberry Pi in the middle of the call. The handover was then analyzed using captured Zoiper packets. Figure 5 shows an example of the packet trace of the handover in Wireshark.

In Figure 5, we can see Address Resolution Protocol (ARP) packets (Packet 4375) as soon as the radio is disabled. These packets are signify the client looking for a new connection. Regular transmission of VoIP data resumes later on in the trace (Packet 4410). The difference in time between these two packets give us an estimate of the sound delay in Zoiper. We repeated this procedure 10 times, the results of which are shown below in Table 2. In these 10 trials, the average transmission delay is 1.615 seconds. While such a delay is noticeable during the call, it will not interfere greatly with any communication, and the call is not dropped.

Our tests show that the handover process has an average stall time of 37.26 seconds for file transfers, which is indeed a very long interruption. We also noticed that some transfers failed entirely which leads us to conclude that our network is not suitable for large file transfers. On the other hand, the stall time for VoIP calls is quite low at 1.615 seconds. Most importantly, however, the calls are not dropped. With tests performed on our network in a lab setting, we are now able to explore the mobility aspect of our wireless mobile network, which we discuss in the next section.

The primary goals of this research were to ensure that VoIP calls could be successfully established and maintained over UAV-based access points and that the calls would not be dropped during a handover procedure. To that end, we conducted experiments whereby we repeated tests performed in Section 3 with the Raspberry Pis and AP radios that were powered by battery packs, all of which were secured to the underside of the UAVs. In this section we describe the setup of our experiment as well as design considerations; tests conducted in a controlled, indoor environment to verify procedure and to provide a baseline for the results of outdoor tests; and the tests when the network was airborne and their results.

When designing this experiment, several different factors contributed to the choice of equipment, such as weight and battery life. We used the DJI Phantom 2, a UAV with many desirable properties. The Phantom 2 is lightweight (weighing 1000 g) and capable of flying while carrying an additional 300 g. It also has a flat surface on the bottom, which stands 4 inches off the ground, allowing third-party devices to be easily mounted. Furthermore, the Phantom 2 has a built-in GPS that enables the unit to hover in place, automatically correcting for wind when receiving adequate signal from GPS satellites. The Phantom 2’s primary shortcoming is its short battery life, which is intrinsic to all modern UAV technology. With a fully charged battery, the quadcopter can remain airborne for only about 25 minutes [Dji01]. This limitation was a primary factor in our design for the payload to consist only of the router, antennas, and their power supply.

For the router we used a WDS-enabled Raspberry Pi with two Alfa high-gain 2000 mw 802.11 b/g/n wireless network adaptors with 5 dBi antennas for communication with client devices and the ground router. The DJI Smart Battery cannot be used to power the Raspberry Pi or antennas, so an additional power supply was necessary. Our choice of batteries was significant, as we needed to supply adequate power to the long-range network adapters while still keeping the aircraft light enough to achieve flight. The Raspberry Pi is powered by a 5 V micro USB supply, so we used Docooler Portable USB Emergency AA Battery Powered Chargers to convert the 3 V output from 2 standard 1.5 V AA batteries to 5V output [Raspberrypi01]. To minimize weight, we conducted preliminary flights with only one USB charger; however, we noticed that the signal strength with the UAV was very low and our devices lost connectivity shortly after takeoff. The batteries quickly became overheated, since they could not sustainably provide the necessary current draw. By attaching two of the chargers in series, we were able to use 4 batteries to supply the devices with adequate power, and our connections subsequently remained stable. The power pack was then able to outlast the UAV’s power supply and consequently was no longer the limiting factor of the flight time.

Before testing our implementation in the air, we performed an experiment on the ground to verify that our network was correctly configured. Our network was set up the same way as in Figure 2, except with the Raspberry Pis connected to the UAVs. This test would also provide an idea of appropriate distances for our aerial experiment, as the unimpeded horizontal distance between UAVs and clients should translate perfectly to vertical distance outdoors. We placed our UAV with the Raspberry Pi, antennas, and battery packs at one end of a long corridor inside a campus building. We then positioned our base station router, server, and Zoiper-enabled OSX clients down the hall from the UAV. We used InSSIDer (WiFi scanning software) to measure the signal strength of the UAV-mounted router at intervals of 50 feet. Our results are shown in Table 3.

Signal strength is a useful metric for connectivity because sufficient strength is necessary for effective transmission. Signal strength decreases with distance and different devices have different sensitivities. For instance, Apple iOS devices have a “trigger threshold” of -70 dBi, under which the client automatically drops the connection. In our tests, we saw that the signal from the UAV was strong enough for iOS devices to maintain a connection, up to 200 feet away. However, there is a large drop in strength of 12 dBi after 100 feet, which shows the increasing difficulty of establishing connections with increasing distance. With one client connected to the base station and the other connected to the UAV router, we also attempted to place a Zoiper call at each distance. In all cases, the signal strength was sufficient to establish and to maintain a VoIP call. Having shown that our network was capable of handling connections at distances up to 200 feet in a controlled environment, we then moved on to conducting the experiments while airborne.

After confirming that calls could be made in an indoor setting, we conducted a series of flight experiments with the UAVs. Since we needed a large open space to safely fly the UAVs, we performed our experiments at nighttime on the parking lot of the Washington University in St. Louis campus. We used the same network topology that we used in the lab tests, connecting one Zoiper client to the ground router and the other client to a UAV’s router.

Our first experiment was to measure signal strength and packet loss with the airborne routers. For this experiment, we required only one UAV through which to send our packets. In order to measure the altitude of the UAV, we attached a kite string to its underside and taped distance markers along the length of the string. After securing the Raspberry Pi, antennas, and battery packs to the UAV, we flew the craft to a position directly above the base station. Throughout the experiment, we flew the UAV to different heights in increments of 50 feet. At each position, we measured the signal strength of the sky router using InSSIDer and attempted to make a Zoiper call between the connected clients.

We also performed a series of data throughput measurements using iPerf 3, a network testing tool. We used iPerf’s standard configuration of sending bursts of 16 UDP datagrams every second for 10 seconds to make our measurements. Repeating this procedure 5 times, we determined an average successful datagram transmission rate at varying altitudes. The results are shown in Table 4.

Using the 5 dBi antennas on the ground router, we were able to conduct Zoiper calls up to 100 feet. However, upon increasing the altitude beyond this point, no connection could be established between the clients. While the client devices maintained a steady connection with the sky and ground routers, no data could be successfully transmitted between the endpoints.

We then tested the seamless handover procedure in the air. In order to do so, we recreated the network of our previous tests with 2 airborne routers. We connected one client to a UAV-mounted router and one client to the base router, positioning both UAVs at an altitude of 50 feet above the base router. With the UAVs at that height, the Zoiper call we established had sufficient packet throughput for intelligible voice communication. By checking the OpenWrt configuration, we then determined with which router the client was associated and remotely disabled its radio. The client quickly associated with the other OpenWrt access point. Voice data was momentarily lost while the client switched access points, but the delay was under 5 seconds and the call was maintained. We repeated the procedure at 100 feet, and while the quality of the call was dramatically lower, the handover procedure was still successful. Above 100 feet, the packet loss was once again too great for a successful Zoiper call.

We repeated these experiments several times in varying weather conditions with the same results. Based on our successful lab tests, the antennas received adequate power from the battery packs, and as such it is unlikely that insufficient current caused the connection loss. A more likely explanation could be the motion of the UAVs while the clients attempted to connect. High crosswinds made it difficult to keep the UAVs both centered over the ground router and positioned at a constant altitude.

While the poor conditions proved to be a consistent issue for the duration of the project, however, we overcame this obstacle by performing many flight tests and gathering data in small increments whenever the weather momentarily improved. Maintaining the security and balance of the UAV attachments also proved challenging. Whenever the Phantom 2 senses it is off balance, it automatically prevents attempts to increase its altitude until it can fly properly. Initial flights failed until we achieved a balanced configuration of the attachments, which were secured to each other and to the UAV with lightweight tape and Velcro. We found it helpful to attach the payload and test for balance before inserting the UAVaE s battery, as the internal controller automatically compensates for the batteryaE s non-uniform weight distribution.

Since the performance of the UAV-mounted routers was poor, we would like to perform similar trials with antennas of different types and strengths (e.g., higher gain, directional) to compare results. Ideally we would like our routers and UAVs higher in the air both to provide signal to a broader area and to avoid obstacles, such as tall buildings or trees. Another metric we would like to explore is transmission speed. With high rates of data transfer, other services besides voice calls (e.g., video, large file transfers) could be sent through our routers, which could be used for purposes such as providing live video of a disaster area or two-way video communication between victims and rescue services.

In this paper we presented an aerial, wireless mobile network topology that can be implemented using quadcopters, Raspberry Pis, and OpenWrt. This network is cheap to implement, uses software that is open-source and cross-platform, and has reliable signal strength. We were able to establish VoIP calls through this network while routers mounted on the UAVs were flown up to heights of 100 feet. However, this network does have high packet loss at higher altitudes. We also successfully tested seamless handover and were able to get accurate timings on the stall period for multiple applications during client handover. Most importantly, we showed that seamless handover during VoIP calls on our network caused a slight delay but was successful in maintaining the call.

[Yijian16] Yijian Li, "Seamless Handover among WiFi Access Points on Raspberry Pi" 2016. 4 Apr. 2016. http://www.cse.wustl.edu/~jain/theses/yijianms.htm

[Dali14] Dali Ismail, "Experiment Design and Analysis of a Mobile Aerial Wireless Mesh Network for Emergencies," M.S. Project Report, Washington University in Saint Louis, May 2014,http://www.cse.wustl.edu/~jain/theses/dali_ms.htm

[Openwrt01] "Client Mode Wireless [OpenWrt Wiki]." 2009. 4 Apr. 2016. https://wiki.openwrt.org/doc/howto/clientmode

[Openwrt02] "Raspberry Pi [OpenWrt Wiki]." 2015. 4 Apr. 2016 https://wiki.openwrt.org/toh/raspberry_pi_foundation/raspberry_pi

[Openwrt03] "Chaos Calmer Repository" 2015. 4 Apr. 2016 https://downloads.openwrt.org/chaos_calmer/15.05/brcm2708/bcm2709/packages/base/

[Ddwrt01] "Linksys WRT54GL - DD-WRT Wiki." 2009. 4 Apr. 2016 http://www.dd-wrt.com/wiki/index.php/Linksys_WRT54GL

[Dji01] "Phantom 2 - The Spirit Of Flight" 2016. 4 April 2016 http://www.dji.com/product/phantom-2

[Raspberrypi01] "Raspberry Pi FAQs - Frequently Asked Questions" 2016. 4 April 2016 https://www.raspberrypi.org/help/faqs/

[Fcc01] "Voice Over Internet Protocol | Federal Communications Committee" 2016. April 4, 2016 https://www.fcc.gov/general/voice-over-internet-protocol-voip

[Ietf01] "RFC 4168 - The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol" 2005. 4 April 206 https://tools.ietf.org/html/rfc4168

[Apple01] aEoeWireless roaming reference for enterprise customers - Apple SupportaE 2015. April 17, 2016. https://support.apple.com/en-us/HT203068

AP: Access Point

ARP: Address Resolution Protocol

dBi: Decibel (isotropic)

DHCP: Dynamic Host Configuration Protocol

LAN: Local Area Network

SCP: Secure Copy

SCTP: Stream Control Transmission Protocol

SSH: Secure Shell

SIP: Session Initiation Protocol

TCP: Transmission Control Protocol

UAV: Unmanned Aerial Vehicle

UDP: User Datagram Protocol

VoIP: Voice over IP

WDS: Wireless Distribution System

In this section, we go over the steps required to create a wireless network with WDS and seamless handover. For our project, we used a Linksys WRT54GL router as our main base station.

1. Replace the proprietary firmware of the router with DD-WRT, which allowed us to use WDS. The installation steps can be found in the DD-WRT site [ddwrt01].
2. Add the MAC addresses of the USB WiFi radios to the WDS list. This can be done by going to Wireless → WDS. Figure 7 shows this step. This was the only step needed to configure the base router.

   

3. Install OpenWrt on the Raspberry Pi. We used OpenWrt 15.05 Chaos Calmer in our project. Instructions on how to install the image on the Raspberry Pi can be found in the OpenWrt page [openwrt02].
4. For the initial OpenWrt configuration, connect a monitor and keyboard to the Raspberry Pi.
5. Set the admin password through the passwd command. Once the password was set, the Raspberry Pi can be accessed either through SSH (Secure Shell) or through a web based OpenWrt configuration page at 192.168.1.1.
6. Install drivers for the WiFi radios connected to the Raspberry Pi. In this project, we used the Alfa AWUS036NHR v2 radios. The main required package is kmod-rtl8192cu. However, this package has several dependencies which also needed to be installed. These packages can be download from the OpenWrt repository [openwrt03]. We used SCP (Secure Copy) to copy them over to the Raspberry Pi and the OPKG package manager to install them.
7. Specify a static IP address for the Raspberry Pi. This can be done by going to Network → Interfaces and clicking on the Edit button for the LAN interface. The static IP address should then be changed to something higher than 192.168.1.100 and the gateway should be set to the base router's IP address. In our case, we set the IP address of the Raspberry Pi to 192.168.1.148.
8. After specifying the IP address of the Raspberry Pi, connect one of the radios to the dd-wrt network. This can be done by going to Network → WiFi, clicking on the Scan button, and joining the dd-wrt network. During the configuration, it is important to join the network as Client (WDS) and to select the LAN interface. The configuration for the client side radio is shown in Figure 8. The radio should now be connected to the dd-wrt network.
9. Set up the other radio as an access point so that clients can connect to it. This can be done by going to Network → WiFi and clicking on the Edit button for the second radio. The AP should be configured as AP (WDS) and it should also in the ln interface. The configuration of the AP radio is shown in Figure 9.

   

   

10. Disable the DHCP server for the LAN interface since we were using the DHCP server in the base router. To do this, we can go to Network → Interfaces and click on the Edit button for the LAN interface. There should be an option at the bottom of the page to disable the DHCP server. The configuration page for the LAN interface is shown in Figure 10. Also disable the firewall by going to the Firewall settings and setting the zone to unspecified.

    

The same steps can be repeated for any number of Raspberry Pis.

1. Download and install Asterisk and FreePBX. Detailed instructions can be found here: http://wiki.freepbx.org/display/FOP/Installing+FreePBX+13+on+CentOS+7
2. Open a terminal and enter asterisk start to initiate the Asterisk service.
3. Use the command ifconfig to obtain the server's IP address and enter that address in a web browser to view the FreePBX GUI.
4. Click "FreePBX" Administration and use the default username "admin" and password "admin" to access the system.
5. Click the "Admin" menu button and select "Administrators" to change the username and password.
6. Under the "Admin" menu, select "Module Admin" to update any necessary modules. Only the modules installed by default are necessary for this project.
7. Under the "Settings" menu, select "Advanced Settings".
8. In the "Device Settings" section, set "SIP can reinvite" to "yes".
9. Set "SIP NAT" based on your network configuration.
10. Under the "Settings" menu, select "Asterisk SIP Settings".
11. In the "RTP Settings" section, set RTP Port Ranges to be 10000-20000.
12. In the "Audio Codecs" section, drag the "ulaw" option to the top of the list to set it as the default codec. Make sure the box next to "ulaw" is checked.
13. Switch to the "Chan SIP Settings" at the top of the page.
14. Set "NAT" based on your network configuration.
15. Set "IP Configuration" to Public IP.
16. Set "Reinvite Behavior" to "yes".
17. Set "Bind Port" to 5060.
18. Click the orange "Apply Config" button in the upper left-hand corner. This will restart the server and run the new configuration. You must click this button for your changes to take effect. If you get an error when you Apply Config, enter fwconsole restart in a terminal to manually restart the Asterisk server. Click "Apply Config" again and the changes should be applied successfully.
19. Enter the following in a terminal to open the necessary firewall ports:
    firewall-cmd --zone=public --add-port=5060/udp --permanent
    firewall-cmd --zone=public --add-port=10000-20000/udp \ --permanent
    firewall-cmd --reload
    

1. Under the "Applications" menu, select "Extensions" to view all user extensions. Initially, there will be none.
2. Click the "Add Extension" drop-down menu, and select "Add New Chan_SIP Extension".
3. Enter the desired extension number for the client in "User Extension".
4. Enter a suitable name for the client in "Display Name" and change the default password in "Secret".
5. Click the "Advanced" tab.
6. Set "Can Reinvite" to "Yes".
7. Set "NAT Mode" based on your network configuration. Ensure this mode is the same on all extensions.
8. Set "Port" to 5060.
9. Set "Transport" to "UDP Only".
10. Click "Submit" in the lower right-hand corner and click "Apply Config".

1. Download Zoiper from the iOS app store or Google Play store for mobile devices, or at http://www.zoiper.com/en for computers. The following instructions will be for iOS devices, but should be similar for other platforms.
2. Change to the same network the Asterisk server is running on.
3. Open the app, and select "Settings".
4. Under "Accounts", click the "+" to add a new account.
5. Answer "Yes" to the "Do you already have an account?" Prompt, and select "Manual Configuration". Choose the "SIP account" option.
6. Give the client device a suitable name in "Account Name".
7. Under "Domain", enter the IP address of your Asterisk server.
8. Enter the Asterisk extension number you have configured as the "User name".
9. Enter the Asterisk extension's password in "Password".
10. Under "Additional Settings", click "Network Settings".
11. Under "Transports", select "UDP".
12. Disable "STUN".
13. Return to "Accounts" and click "Audio Codecs". Make sure "ulaw" is enabled.
14. Return to "Accounts" and click the "Register" button to connect to the Asterisk server. If the server is running and configured properly, registration should only take a second.
15. Making any changes to the Account configuration (e.g., switching the Domain field to a new server IP address) will require you first to "Unregister", then to"Register" again.