We’re rolling out a new public address system at work and have opted to install it ourselves because the cost of outsourcing it would have blown our budget. The upside was this enabled us to go for a full IP based system with the savings and still be well under budget. The system we selected was from 2N® because they offered the best performance for the price and I’d like to particularly mention Lloyd at K2AV for helping us to get the gear despite not getting the install contract.
One issue I have had with these units is that the documentation isn’t as complete as I’d like or, it’s too hard to find. Overall though, to get the units working at the simplest level wasn’t hard.
While 2N® does provide what looks like some great software with their gear, we’re choosing only to use standards-based software that is in everyday use so that if we need to mix in equipment from other vendors down the track, we’re not going to have a problem.
The specific software applications we’re using to tie this system together are FreePBX and BellCommander.
Setting Speaker’s IP Address
All of the speakers shipped with a default IP address of 192.168.1.100. This is pretty standard but in a large routed network like ours, a real pain. Fortunately 2N® provide the 2N® Network Scanner to help.
You proceed by right clicking on the line for the speaker and selecting ‘Config’ where you’re presented with the screen below
For my network, I selected DHCP and then put the default password of ‘2n’ into the password box. Pressing the ‘Set’ button will cause the speaker to change its IP configuration and you can see the new information by refreshing the Network Scanner’s main screen.
Riche clicking on the speaker in the Network Scanner and selecting ‘Browse’ will take you to the web configuration page for the speaker. The default username and password should be ‘Admin’ and ‘2n’ and it is case sensitive.
SIP Based PABX
The SIP-Based PABX selected for this project is FreePBX because it’s free, uses solid underlying software and is easy to use. Configuring FreePBX is not covered in this document but, suffice to say that each SIP speaker will need an account to log in with.
DHCP Options
To get the speakers to look for the configuration files, you need to set Option 66 in your DHCP server. This option specifies the address where the clilent should check. We’re using a Microsoft Windows Server for DHCP.
Please be sure to choose a method of delivery that all of your devices support on this network segment as they will all need to get their configuration files from this same system
The Web Server
While we’re using Apache2 on Ubuntu Linux, you could use any other web server for this solution. Please note however that any code or tips for security in document may only be useful of you’re using the same system as us.
The options we’re using for our virtual server for this install are:
Order deny,allow
Deny from all
Allow from 10.13.0.0/24
Options FollowSymLinks
Require all granted
We use the option for FollowSymLinks to make things easier as explained later in this document. Please exercise caution with this option and don’t link any file that could compromise your system.
Folder Layout
We have stored all of our
We have another directory, /2n/firmware/, which holds the latest firmware for the speakers. The firmware file should be named ‘ss-firmware.bin’ and we used a symbolic link to the downloaded firmware file. This makes it easier to maintain all of the previous firmware files for records and change to the new one once you’re ready by pointing the symbolic link to the new version.
Because the speakers will initially check the root folder of the web server for ss-common.xml, we have put a symbolic link to the file there so that when we edit the original file, the one in the root folder will as well. Failing to do this will mean that the speakers will not find their initial configuration.
.
├── 2n
│ ├── config
│ │ ├── clean.sh
│ │ ├── data.csv
│ │ ├── make.sh
│ │ ├── ss-7C-1E-B3-03-A5-1B.xml
│ │ ├── ss-7C-1E-B3-03-B3-B4.xml
│ │ ├── ss-7C-1E-B3-03-B4-4D.xml
│ │ ├── ss-common.xml
│ │ └── ss-template.xml
│ └── firmware
│ ├── Firmware 2.25.0.zip
│ ├── Firmware 2.25
│ │ ├── 2N Intercoms_thirdpartysoftwarelicenses.txt
│ │ ├── 2_25_0_34_8.bin
│ │ ├── Release notes 2 25 CZ 5 11 18.docx
│ │ ├── Release notes 2 25._DE_5_11_18.docx
│ │ ├── Release notes 2 25._EN_5_11_18.docx
│ │ ├── Release notes 2 25._ES_5_11_18.docx
│ │ ├── Release notes 2 25._FR_5_11_18.docx
│ │ ├── Release notes 2 25._IT_5_11_18.docx
│ │ └── Release notes 2 25._RU_5_11_18.docx
│ └── ss-firmware.bin -> Firmware 2.25/2_25_0_34_8.bin
└── ss-common.xml -> 2n/config/ss-common.xml
Configuration Files
The configuration files needed to automate the creation of the provisioning files are explained below. The end result will be a common shared configuration file and individualised files that contain specific instructions for one speaker. The common and the individualised files are loaded and merged by the speaker.
ss-common.xml and ss-template.xml
Because the XML configuration files can be too long, you can view both of these files ss-common.xml and ss-template.xml here. The first file, ss-common.xml is read by every speaker on boot up, while ss-template.xml is used by ‘make.sh’ to create a unique configuration for each speaker using data.csv as the data source.
In our installation, our web server is only contactable internally, and it is also restricted to accept connections from systems in a specific IP range. I recommend doing likewise at your site as the configuration files will contain valid usernames and passwords to your PABX.
PLEASE NOTE: I have changed some of the data in ss-common.xml to protect our privacy. You can get a copy of the file with the correct data for your site by setting up one speaker manually and then downloading the configuration file from that speaker. This is especially true for the speaker’s web server password.
data.csv
The file data.csv is a CSV file that contains the information used by make.sh to replace the variables in ss-template.xml and create a new configuration file.
The first column is the MAC address of the speaker, the second column is the username for the SIP account and the last column is the password. Please note that these are not our actual passwords. The CSV file doesn’t have a header row and you should format your data as shown below.
7C-1E-B3-03-A4-EB,1010,0vAhcXmVsEsLAc2?789@
7C-1E-B3-03-A4-EA,1012,707asnosmIakjjdhOvd
7C-1E-B3-03-A5-1A,1013,094#zCqMahsnbWser9$8
make.sh
This file reads the CSV data and combines it with the template file (ss-template.xml) to create the individualised XML files.
#!/bin/bash
clone()
{
if [ ! -e "ss-${1}.xml" ]
then
echo Creating ss-${1}.xml
cp "ss-template.xml" "ss-${1}.xml"
sed -i "s/%%ID%%/${2}/g" "ss-${1}.xml"
sed -i "s/%%PASSWORD%%/${3}/g" "ss-${1}.xml"
fi
}
while IFS=, read -r col1 col2 col3
do
clone "${col1}" "${col2}" "${col3}"
done < data.csv
clean.sh
If you make changes to the CSV data, you can use this script to delete the old XML files and be ready to recreate them.
#!/bin/bash
mkdir -p backup
cp ss-common.xml backup/
cp ss-template.xml backup/
rm *.xml
cp backup/*.xml .
Additional Information
The 2N® documentation on this topic can be found at
https://wiki.2n.cz/hip/conf/latest/en/5-konfigurace-interkomu/5-5-system/5-5-5-aktualizace.