There are many excellent guides for setting up a Unifi Controller on CentOS 7, three that helped me:

https://community.spiceworks.com/how_to/128121-installing-unifi-controller-on-centos

https://nivethan.dev/devlog/setting-up-unifi-controller-on-centos-7.html

https://binhminhitc.com/networks-solutions/how-to-installing-unifi-controller-on-centos/

However since these were penned there are a few changes in the setup that need to be worked around:

Workarounds

UniFi.unix.zip Download Link

Unifi have stopped advertising the Unix files on the downloads, instead opting to show only the .deb Debian package. To get a file suitable for CentOS…

Navigate to https://www.ui.com/download/unifi/ and choose the download for Unifi Network Application for Debian:

Clicking download icon gives the following link…

Make note of the version number (here 7.1.66) and edit into the the following link:

https://www.ubnt.com/downloads/unifi/7.1.66/UniFi.unix.zip

MongoDB

MongoDB is no longer included in the default CentOS or EPEL repositories, so its own repository needs to be added to your system for prerequisites

Source: https://www.mongodb.com/docs/manual/tutorial/install-mongodb-on-red-hat/#install-mongodb-community-edition

Create a new file at /etc/yum.repos.d/mongodb-org-5.0.repo

Insert the following into the file:

[mongodb-org-5.0]name=MongoDB Repositorybaseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/5.0/x86_64/gpgcheck=1enabled=1gpgkey=https://www.mongodb.org/static/pgp/server-5.0.asc

Installation is now via:

yum install -y mongodb-org

Installation Guide

Disable SELinux, reboot for changes to take effect

sed -i /etc/selinux/config -r -e 's/^SELINUX=.*/SELINUX=disabled/g'
reboot

Create file to include MongoDB repositories

nano /etc/yum.repos.d/mongodb-org-5.0.repo

Add the following to the new file

 [mongodb-org-5.0]name=MongoDB Repositorybaseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/5.0/x86_64/gpgcheck=1enabled=1gpgkey=https://www.mongodb.org/static/pgp/server-5.0.asc 

Install prerequisites

yum install -y mongodb-org java-1.8.0-openjdk unzip wget

Download Unifi Controller

wget https://www.ubnt.com/downloads/unifi/7.1.66/UniFi.unix.zip

Unzip files to /opt directory

unzip -q UniFi.unix.zip -d /opt

Create data folder within Unifi directory

mkdir /opt/UniFi/data

Add new user to run service

useradd -r ubnt

Assign ubnt ownership of Unifi directory

chown -R ubnt:ubnt /opt/UniFi

Create firewall rules to allow access to Controller

nano /etc/firewalld/zones/public.xml

Add the following to the file…

  <port protocol="tcp" port="8081"/>
  <port protocol="tcp" port="8080"/>
  <port protocol="tcp" port="8443"/>
  <port protocol="tcp" port="8880"/>
  <port protocol="tcp" port="8843"/>
  <port protocol="tcp" port="27117"/>
  <port protocol="udp" port="3478"/>

Reload firewall for changes to take

firewall-cmd --reload

Enable MongoDB to start with the system, start it for first time and check its running

systemctl enable mongod
systemctl start mongod
systemctl status mongod

Create the service for Unfi Controller

nano /etc/systemd/system/unifi.service

Enter the following in the new file

[Unit]
Description=UniFi AP Web Controller
After=syslog.target network.target

[Service]
Type=simple
User=ubnt
WorkingDirectory=/opt/UniFi
ExecStart=/usr/bin/java -jar /opt/UniFi/lib/ace.jar start 
ExecStop=/usr/bin/java -jar /opt/UniFi/lib/ace.jar stop
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

Enable Controller to start with system

systemctl enable unifi

Start the Unifi Controller

systemctl start unifi

Controller should now be available for setup by browsing to
https://{IP ADDRESS}:8443/

Unifi Testing

I need the Unifi Controller in order to test the Nano HD AP, why? This is the only Unifi AP in stock in the UK at the moment, all other more preferred AP’s like the Pro, LR and HD are unobtainium along with the Cloud Key. Therefore in desperation its time to test if these will make a worthy substitute.

Its early days at present, but should testing go well and I choose to adopt Unifi as my home Wifi solution, I’d be deploying a slim VM running Rocky 8 to manage the infrastructure.

So far for testing; the AP is positioned a foot away from a Draytek 2927ac, at moderate distances the Unifi Nano is showing a 10db advantage over the Draytek on 2.4Ghz range, but curiously a 10db disadvantage on the 5Ghz range. And while devices report a better signal strength on the Unifi, bandwidth speed tests yield poor results.

I would hope that the Pro’s performance would be an improvement on the Nano, but for now that is entirely speculation since getting hands on one is impossible without paying scalper prices.

Installing and poking around the GUI is all well and good but to really find out how a PBX behaves it needs some traffic, to find outs its performance in regards to resources but also to find out what a vendor’s interpretation of an advertised feature actually is.

To generate sample calls, instead of registering handsets/softphones and dialling manually it would be better to automate this, and SIPp is the perfect tool for this.

SIPp is an open source SIP testing tool for stress testing PBX’s, but it can also be used more modestly so it can generate more real-world scenarios to simulate typical calls. This can also be beneficial when testing and reviewing complex call flows through a system before deploying.

Environment

In this example I would be using a local CentOS 7 Virtual Machine to host the SIPp application, with the PBX sitting remotely and network access via VPN for the testing period.

The PBX will also have a trunk set to allow calls in from the CentOS box and a DDI assigned.

Installation

Installation on CentOS is easiest via yum and the EPEL repositories.

From a clean install run:

yum update
yum install epel-release
yum install sipp 

Operation

Once installed its as easy to run as running the program from the command line, but getting the results you are looking for requires a lot of switches and a scenario file.

The simplest way to look at this is the switches take care of the targeting and rate of the calls, where the scenario file simulates the calling person, and can be set to imitate speech (RTP streams), dtmf inputs and even introduce packet loss to measure quality of calls. Essentially a profile of a call is contained within the scenario file.

As an example, this is a typical command I use for testing a very modest call load:

sipp -sf file.xml -trace_err -trace_msg -i 10.20.30.40 -r 1 -rp 10000 -l 100 -m 50 -s 12345678901 10.100.100.100

To break down this command and make it more understandable:

• -sf {FILENAME} – Scenario file.
• -trace_err – Print errors to file, for troubleshooting.
• -trace_msg – Print verbose log to file, for troubleshooting.
• -i {IPADDRESS} – RTP stream (Audio) source.
• -r {NUMBER} – Call Rate – Rate that calls are attempted.
• -rp {NUMBER} – Rate Period – Number defined in Call Rate are spread over the Rate Period.
• -l {NUMBER} – Max number of concurrent calls.
• -m {NUMBER} – Total number of calls to attempt.
• -s {NUMBER}- SIP number to dial and server.
• “10.100.100.100” – PBX server IP

Scenario File

As mentioned, the scenario file contains the simulation of a call from a calling party.

SIPp has a number of template scenario files in XML format available on their Sourceforge page, these can be download and modified as needed.

For example, below is my modification of the uac_pcap.xml template, this is a simple file that connects and plays an RTP stream (from a pcap file) for two minutes before hanging up:

  <scenario name="UAC with media">
 <!-- CALL SETUP         -->
   <send retrans="500">
     <![CDATA[
  
       INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
       Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
       From: 01234567890 <sip:01234567890@[local_ip]:[local_port]>;tag=[call_number]
       To: sut <sip:[service]@[remote_ip]:[remote_port]>
       Call-ID: [call_id]
       CSeq: 1 INVITE
       Contact: sip:sipp@[local_ip]:[local_port]
       Max-Forwards: 70
       Subject: Performance Test
       Content-Type: application/sdp
       Content-Length: [len]
  
       v=0
       o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
       s=-
       c=IN IP[local_ip_type] [local_ip]
       t=0 0
       m=audio [auto_media_port] RTP/AVP 8
       a=rtpmap:8 PCMA/8000
       a=rtpmap:101 telephone-event/8000
       a=fmtp:101 0-11,16
  
     ]]>
   </send>
  
   <recv response="100" optional="true">
   </recv>
  
   <recv response="180" optional="true">
   </recv>
  
   <send>
     <![CDATA[
  
       ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
       Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
       From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
       To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
       Call-ID: [call_id]
       CSeq: 1 ACK
       Contact: sip:sipp@[local_ip]:[local_port]
       Max-Forwards: 70
       Subject: Performance Test
       Content-Length: 0
  
     ]]>
   </send>
   <!-- PLAY RTP STREAM         -->
   <nop>
     <action> 
         <exec play_pcap_audio="pcap/g711a_600.pcap"/>
     </action>
   </nop>
  
   <!-- SET CALL LENGTH                                                        -->
   <pause milliseconds="120000"/>
  
   <send retrans="500">
     <![CDATA[
  
       BYE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
       Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
       From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
       To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
       Call-ID: [call_id]
       CSeq: 2 BYE
       Contact: sip:sipp@[local_ip]:[local_port]
       Max-Forwards: 70
       Subject: Performance Test
       Content-Length: 0
  
     ]]>
   </send>
  
   <recv response="200" crlf="true">
   </recv>
  
   <!-- definition of the response time repartition table (unit is ms)   -->
   <ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
  
   <!-- definition of the call length repartition table (unit is ms)     -->
   <CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
  
 </scenario> 

Personal Observations

This is a great tool for automation in the testing phase of a new platform deployment, and you can easily generate calls in numbers considered unfeasible when using traditional desk and soft phones, plus this method allows all phones in the test bed to become call recipients, increasing the user base to more accurately test a platform.

In addition to the PBX this tool also tests the network that provides connectivity to the phone system, this was highlighted to me when testing with traffic going over a VPN, and discovered that the VPN gateway could not cope with more than 10 concurrent calls despite having enough bandwidth available.

As a final note I recommend to start a test with minimal call volume ad scale from there. Whilst SIPPp can simulate calls, these aren’t as organic as the real world. I managed to knock a live system offline with as little as 100 generated calls, due in part to 100 SIP invites being sent within one second.

Oh, and don’t introduce a load of test calls to a flow where the final destination is a voicemail, I found that out the hard way!