Raspberry Pi + Darkice + Icecast + FreePBX MOH streaming

A recent client requirement was to be able to use their own audio source for music on hold. This source was a box that played a monthly CD they received from corporate with seasonal ads/music and pushed out via analog component cables to the amp for the overhead speakers. Since there is no analog input on the PBXact, I had to figure out a way to take the analog audio and convert it to IP. After a bit of research, I found extensive mention of Darkice to capture, encode and then push to another program called Icecast that would then publish a network stream.

First off, you'll need some form of computer. I decided on an SBC since this is the only job it will be doing and for the small form factor+price+low power. The Raspberry Pi is the obvious choice since it's so ubiquitous and well supported with the kernel and applications. Second, a USB audio input. I used this one from Amazon: https://amzn.com/B00IRVQ0F8

More specific for my client was the fact that they used this audio system for overhead music as well, which required me to get a left/right component cable splitter, that then necked down with another adapter to the 3.5mm for the input into the Pi. This enabled both the amp/overhead speakers and the phone system to pull the same stream of audio.

The rest was done in software.

To start install Icecast:
sudo apt install icecast2

Go through the install prompts. Make sure whatever password you use for the "source" is what you put in the darkice.cfg file below. Default is "hackme"

Next install Darkice:
sudo apt install darkice

Create/etc/darkice.cfg in your home dir and add:
[general]
duration        = 0           # encoding duration, 0 = forever
bufferSecs      = 5           
reconnect       = yes       

[input]
device          = plughw:1,0  # USB audio adapter
sampleRate      = 44100       
bitsPerSample   = 16        
channel         = 2           # 1 = mono, 2 = stereo

[icecast2-0]
bitrateMode     = abr         # average bit rate
format          = mp3       
bitrate         = 128
server          = localhost  
port            = 8000      
password        = hackme    
mountPoint      = mic       
public          = yes       

To start Darkice on boot:

• crontab -e
• @reboot sleep 30 && sudo darkice -c darkice.cfg

Couple things to mention:

• The USB sound adapter I used worked the first time with no issues. YMMV. You can find articles troubleshooting this if you have issues. As a hint to see if it's a Darkice issue or the USB adapter issue, try: 
• arecord -D plughw:1,0 temp.wav  ----> for 5 seconds, then:
• aplay temp.wav 
• If the file plays back your sound/music, you know the USB adapter is working fine.
• To find out which USB adapter you need to specify in the darkice.cfg, enter the command 
• lsusb
• You might need to play with the microphone gain depending on the source signal strength/volume. Use:
• alsamixer

To test, go to the Icecast local page and you should see your mountpoint and stream stats (if a blank page, something's not configured correctly so go back and troubleshoot):
http://<ip address of raspi>:8000

To play, you can click the link to the stream, or open VLC and add a network stream:
http://<ip address of raspi>:8000/mic

Last step is to tell FreePBX how to find the audio stream. Go the "Music on Hold" module, and put the following in the application field:
/usr/bin/mpg123 -q -s --mono -r 8000 -f 8192 -b 1024 http://<ip address of raspi>:8000/mic

That's it! A fully functional, auto starting, cost effective, and simple way to convert analog audio into a network stream for your PBX.

FreePBX basics

Now that have covered some basics of VoIP in our "Sangoma PBXact deployment tips" series, lets clarify the OS of FreePBX. First is CentOS. This is the Linux distro everything is based on, with some tweaks. Then there is the backend of the server, Asterisk. It handles all of the functions needed to operate calls and databases. Then the GUI, FreePBX, that interacts with the previous but in a way that makes configuration simple. As a note, Asterisk is open sourced, and managed by Digium. FreePBX is also open source, but managed by Sangoma. Sangoma recently purchased Digium, bringing both products under one roof. This should help the teams work more closely together to streamline the product. Quick note to OS versions, at of the time of this post, FreePBX 14 is the latest stable release. v15 is right around the corner, with some important improvements. I will touch on this a later post.

So, moving on. FreePBX has modules, which can be purchased separately, or in the PBXact series that Sangoma offers. This platform includes the base OS that includes Asterisk and the GUI FreePBX, plus a large amount of commercial modules that expand the capabilities. I prefer PBXact to a basic FreePBX box. The reason is mainly due to client needs. Even if the client doesn't initially need all of the features, being able to have those already included resources later to offer as solutions is a great experience for the them (and me as the admin). If you you want just basic call capabilities, or want to load the OS on your own hardware/VM, then FreePBX can be a great way to go. There's even a way to convert from FreePBX to PBXact afterwards, or just purchase the small handful of modules that are specific to your needs.

Now might be a good time to mention the main modules I use, with some brief descriptions of their purpose. Here is a comprehensive picture of all the modules in a PBXact system. I am not going to cover every one, but in will give you an idea of what's capable in these servers.

Here are the big ones:

• Inbound routes - Incoming calls to your DIDs need to get routed somewhere in the PBX.
• Time Groups - How you build business hours, holidays ect.
• Time Conditions - You route calls to these. They have an separate destinations depending on the whether they match the time group they're linked to.
• IVR (Interactive Voice Response) - This is the menu that you can route callers to after qualifying via Time Conditions. "press 1 for ___, press 2 for ___..." A very useful module.
• Extensions & User Management - Very obvious, but a lot of options inside both of these.
• EPM - Builds templates to mass provision phones. Very important module.
• Ring Groups - Add extensions to a group so they all ring.
• VM Blast - Similar to the above, but just for Voicemail
• Parking - Similar to the POTS idea of "lines". Basically a place to park a call till another extension can pick it up.
• SipStation - Sangoma's SIP trunking service module. This enables you to pop in a large key that is unique to your account, and it will build all the trunks and import your DIDs. This is what we use and have been happy with the price and reliability. 

I will probably add to this list as I think of use cases, but for now this will get us started. I will be pushing out posts describing more in detail the use cases of the modules, and will link them.

Thanks for reading!

Unifi controller "Startup-up failed"

Tried installing the Unifi controller on a Pelco NVR server. Just so happens Pelco uses port 8880. And so does Unifi, for the portal redirect port for HTTP. Here's how you fix it:

1. You need to kill whatever process is using the port. The reason for this is that in order to tell Unifi to use another port, you have to edit the config file that is created on the first startup of the controller. But when it can't start because of the in use port, no file is created, and thus no way to change it. Dumb. Anyways, to find the process, open cmd and run netstat -ano | find "8880" . To kill it, you could use a Powershell command (run as administrator) Stop-Process -ID 8660 -Force, but in my case this was a service running in the background that kept restarting. I had to go to service manager and stop VxToolbox.
2. Start the Unifi controller to generate the file. Once started, shut it down. 
3. Navigate to C:\Users\USERNAME\Ubiquiti UniFi\data and edit system.properties file. Uncomment the portal.http.port=8880 line, but change the number to something else. I changed it to 8881. Save the file and close it. Restart the original service that was in conflict, and then start the Unifi controller.

Sangoma PBXact deployment tips

As I have deployed Sangoma PBXact VoIP systems the past couple years, I've gained a decent amount of hands on knowledge. Unfortunately, due to time constraints, I haven't had the time to document my experiences. This post is the start of a series with tips I've learned on how and why to deploy PBXact, as well as a index of posts where I will describe in detail the complexity and things to consider when deploying these phone systems. I will update this post with links to other posts that I make, as well as any major clarifications that I think might be beneficial to the big picture of this topic.

There are a lot of features to talk about, and there are many others, as well as other things for the admin/installer for such a system to take into account. We will discuss these in this series.

As a final note, lets talk about why a client would be interested in on premise systems. Although the up front cost is a consideration for a client, in the long run they save money and gain flexibility. There are many reasons for premise based VoIP solutions, but here are five main reasons in my opinion:

1. Any of the features they would like to implement in their environment do not cost extra, they're already included in the PBXact modules licensing. (Granted these are 25 year licenses, but that should be adequate for most businesses.)
2. Any internal extension to extension calling is free because it does not traverse the SIP trunk provider, it's SIP endpoint to SIP endpoint. (This includes VPN remote workers, more on this in a later post)
3. The ability to tie multiple locations together for free via IAX trunking.
4. The monthly cost (minus the upfront PBX cost) is usually cheaper than using a SaaS solution like RingCentral. (Caveat - PaaS or IaaS sometimes can be comparable if there is a team that can deploy maintain the system, but the monthly cost of renting the hardware and paying the team could equal just purchasing the hardware outright over a span of a couple years. YMMV)
5. Flexibility for very specific configurations

Now that we have all that out of the way, let's start diving into the topics that are relevant.

1. PBXact - The basics of VoIP
2. FreePBX basics
3. _____________

More to come, thanks for reading!

PBXact - The basics of VoIP

As we start this Sangoma PBXact deployment series, I thought it might be helpful to start with some basic principles of VoIP. Here are a few terms to familiarize yourself with, defined in my own simplified way for the beginner to understand.

• Latency = time to reach a destination
• Jitter = variation in latency
• Bandwidth = size of internet pipe to push traffic
• SIP = start of negotiations between two endpoints that want to talk
• RTP = actual voice traffic after SIP completes
• SIP trunking = connects you to other SIP or PSTN networks
• ChanSIP = stable, older, limited SIP protocol
• PJSIP = newer, future, more features SIP protocol
• Codecs = conversion & compression of your voice into digital

To expound on the above:

• DSL generally has more jitter than Cable ISPs, thus worse for VoIP ( haven't had too many issues myself with the few CenturyLink DSL deployments I've had, but just something to be aware of) I use https://sourceforge.net/speedtest/ for this purpose since it gives me all this information when surveying a potential clients internet quality.
• Some SIP providers carry the RTP traffic on the same session that the SIP session opened, while others use separate voice data sessions and thus require ports 10000-20000 to be forwarded to the PBX for RTP. 
• Some some providers use the term "trunks" differently. SipStation treats a trunk like a single line. Technically, they allow one trunk a concurrent outbound and inbound call. (concurrency bursting allows a per minute "burst" past the trunk limit. Helpful for the occasionally busy time where the client receives more calls that they have purchased trunks for. Need to monitor this as it might be beneficial to bump up the trunk quantity)
• ChanSIP vs PJSIP...just read the forums to find people on both sides shouting which is better. PBXact, as of 2019, defaults to ChanSIP. I usually leave the extension like that, haven't had any issues. The one time I did change a single extension to PJSIP, was when that specific extension needed two endpoints to register simultaneously to it so that both would ring. ChanSIP, as far as I could tell didn't support this. PJSIP worked great in this application.
• Some codecs require more bandwidth but sound better. Depends on the environment. I believe the default in PBXact is G.711. To be honest, I've never had to change this.

I hope this was helpful. Please let me know if there is anything else I can answer or add to this post!

Sangoma PBXact deployment series post #2 will be coming soon! (I will link it in this post)