Having just installed and migrated a client from an old Asterisk/FreePBX system running on CentOS 5 at Rackspace to a nice new installation on Ubuntu 16.04 at Amazon Lightsail and having deleted the old system as the testing all came out clean, 24 hours running passed and then strange reports of calls that just go dead after connecting. Most calls ran through OK but some particular called numbers rang (just once) were connected but then no audio at all.

Looking through the Asterisk logs didn't show anything to write home about. The FreePBX script ran through ok, started the SIP call via a SIP Trunk Provider, all the correct responses came back, the RTP audio stream was established but the client could not hear any audio on the call. After a while the call clears down. Nothing odd showing at all in the log.

Checked all the Firewall rules to see if anything might be getting in the way of the RTP audio stream but all the rules looked fine. Then it was time to look deeper and run a packet trace. This needed to capture the SIP and RTP conversations to a capture file to download and analyse via Wireshark. "tcpdump udp portrange 1024-65535 -vvvv -s 0 -w dump.pcap" to capture the traffic.

Loaded up the capture file in Wireshark and again every thing looked ok. The SIP handshaking to INVITE the call all showed OK, the RTP handshake and stream all looks OK. The great VOIP analysis tools in Wireshark allowed me to unpick the RTP audio stream and play it ok. In this particular case an announcement to say the offices were closed.

The announcement got me thinking "was the end point another VOIP system?". It turned out that the numbers that had been reported to me as having this problem were VOIP so I started to look at the CODECs involved. The SIP Trunk was setup, as it had been in the old Asterisk/FreePBX, to use ulaw and alaw CODECs. I noticed from the packet capture that the RTP stream had decided to use alaw (G 711 A). So, initially just as a test, I changed the SIP Provider Trunk to use ulaw (G 711 U) only. Tested some calls, all working ok now.

FreePBX 14.0.3.6 Asterisk 13.1.0 with a SIP Trunk Provider making SIP/RTP connections to another VOIP system with an alaw (G 711 A) CODEC fails to decode the audio, change the Trunk to use a ulaw (G 711 U) CODEC, all is well.

A simple Grafana Dashboard created for a client using SugarCRM. This used a direct MySQL client connection to a hosted SugarCRM service with a backed MySQL database. This used the latest Grafana MySQL DataSource to access the MySQL Database.

The Raspberry PI range of IoT devices are very different from the Electric Imp IoT devices I have previously used. The Pi is a full function computer in a very small form factor, particularly the Zero W (with built-in WiFi and Bluetooth). Unlike the Electric Imp. the Pi gives you full access to the Operating System, allowing you to install additional software (although, to be fare, you don't need to add much to what already comes with it). In my case, this only involved adding a Zabbix Agent. Full access to the Operating System does, of course, place a responsibility on you to manage your own security but it does allow much greater flexibility (with the exception of any Analogue to Digital Converters ADC, that is).

Being able to install a Zabbix Agent on the Pi adds a couple more possibilities over the Electric Imp setup. Firstly, the Zabbix Agent can be configured in "Active" mode which will push collected data to the Zabbix Server rather than the Zabbix Server polling the IoT device. Secondly, it allows for the usage of a local Zabbix Proxy, this can accept the Zabbix Agent data even if the connection to the Zabbix Server is down, sending data later when the Zabbix Server connection is re-established. In the above example, the Zabbix Proxy is deployed of a pfSense Server which is also acting as a WiFi AP for the Pi.

In the above picture the hardware has been put together using a "Breadboard" with fly leads but this could easily be constructed in a case with battery power. As the Pi has no ADC, an external ADC is required, the small blue board at the top (and ADS1115 From Texas Instruments). This is directly connected to the thermal Sensor via one of it's four analogue channels. It is connected to the Pi via one of the Pi's I2C busses.

And lastly, the data is passed to a Zabbix Server and presented vi a Grafana Dashboard as below.