Peter Hicks' Blog

For several years, Electromagnetic Field has operated its own internal telephone system. Attendees can set up one or more extensions which can terminate on a copper telephone line, a DECT phone, a SIP endpoint or a GSM phone.

Two years ago, I set up BatFax on a Raspberry Pi. Call the number, it calls you back and sends you a fax with a fact about bats. This time around, I wanted to do something more whimsical and considerably less difficult.

My initial idea was to register extension 2820 (twit-twoo) which simply plays back an MP3 of an owl. Everyone got the joke apart from one person who shall remain nameless, and there were a couple of hundred calls during the event after I put up an advert on the on-site Infobeamer.

I have a varied tech history, and did a lot of VoIP and SIP work in the mid-2000s using Asterisk. Since somebody asked about automated phone lines on Discord, I decided the best way to explain how to do it is by example. It’ll also serve as a reminder for me in two years time when I inevitably forget.

Please bear in mind that this is a really quick write-up and doesn’t cover everything. I can’t teach you all about VoIP, security, Asterisk and SIP, but I’ve tried to make the configuration as clear as I can.

First, you need to install Asterisk. I’ll leave that up to you.

Next, you need to set up several configuration blocks in /etc/asterisk/pjsip.conf.

The first is the transport configuration. UDP is used for SIP rather than TCP because latency is more important than guaranteed delivery:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0

Next up, we need some authentication credentials to register with the remote Asterisk server:

[emf2820]
type=auth
auth_type=userpass
username=2820
password=geeksinafield

We need an Address of Record (AOR):

[emf2820]
type=aor
contact=sip:2820

To differentiate incoming calls, we need to tell Asterisk how to identify an incoming call to 2820. We do this by matching the To header in the SIP message, and check if it contains sip:2820@sip.emf.camp.

[emf2820]
type=identify
endpoint=emf2820
match_header=To:/sip:2820@sip.emf.camp/

Next, we need to configure an endpoint. This combines the transport, authentication, AOR and identification, and defines the context for which calls are made/received. I won’t go in to it too much, but for security we’re just using a single context named emf which has nothing else in it. No other endpoints, no outbound trunks, no inbound trunks. VoIP is quite easy to get wrong, and you don’t want somebody being able to dial in, then somehow dial out again at your expense!

[emf2820]
type=endpoint
transport=transport-udp
outbound_auth=emf2820
aors=emf2820
disallow=all
allow=all
identify_by=header
from_domain=sip:sip.emf.camp
context=emf

Finally, Asterisk needs to register, so we set this up.

[emf2820]
type=registration
server_uri=sip:sip.emf.camp
outbound_auth=emf2820
client_uri=sip:2820@sip.emf.camp

To make this live, run pjsip reload at the Asterisk console. pjsip list registrations will then, hopefully, show that the server has registered.

Finally, we need to configure extensions.conf to handle incoming calls. The following minimal configuration will answer calls coming in to context emf, wait for one second, then play a custom sound from /usr/local/share/asterisk/sounds:

[general]
static=yes
writeprotect=yes
clearglobalvars=no

[emf]
exten => s,1,Wait(1)
same => 2,Playback(custom/long-eared-owl)
same => 3,Wait(2)
same => 4,Hangup()

Incoming calls may use a variety of codecs, so if you want to cater both for high quality audio connections and low-bandwidth u-law connections, you can use sox to convert files from MP3 to other formats. It’s quite simple – replace $FILE with the name of the MP3 containing owl sounds, and run these commands to generate the file formats:

/usr/bin/sox $FILE.mp3 -r 8000 -c 1 -t ul $FILE.ulaw vol 0.9
/usr/bin/sox $FILE.mp3 -r 8000 -c 1 -t al $FILE.alaw vol 0.9
/usr/bin/sox $FILE.mp3 -r 8000 -c 1 $FILE.gsm vol 0.9
/usr/bin/sox $FILE.mp3 -r 8000 -c 1 -b 16 $FILE.wav vol 0.9
/usr/bin/ffmpeg -loglevel quiet -i $FILE.mp3 -ar 16000 -ac 1 -acodec g722 $FILE.g722

That’s really it. Reload the Asterisk configuration and have some fun!

After running Proxmox 8.x in a lab environment for two years, this weekend was an appropriate time to upgrade.

Backing up each machine was far more straightforward than I thought – shut it down, back it up to a Synology NAS defined in Proxmox, and delete it from the host. Even with 2.5Gbps Ethernet, this took quite a long time.

I spent far too long trying to work out how to get my motherboard (an ASUS Prime X299A-II) to boot from a USB stick with the Proxmox 9 ISO written to it. As it turns out, disabling Secure Boot is a matter of clearing out the keys in the setup utility.

Given a reinstall was imminent, I decided to update the firmware on each of the M.2 SSDs – all Samsung devices. There isn’t an easy way to this, and I settled on writing ISO images with the updater for each model from Samsung’s website. I’m sure it wouldn’t have been too difficult for them to provide an ISO image with all the latest firmware, but I am writing this from a position of not knowing the finer points of why they did what they did.

The actual Proxmox setup was slick, and after fiddling with /etc/network/interfaces to try to get a management interface on the built-in 1Gbps NIC, and a VM interface on the additional 2.5Gbps NIC, I’d wrecked the machine’s configuration. Running the install again and keeping everything on the 2.5Gbps NIC was a lot easier, especially as I disabled renaming the Ethernet interfaces so they had useful names such as eno1 and enp6s0 rather than nic0 and nic1.

Re-applying the Proxmox licence was as simple as copying my licence key on to the machine. No faffing around with anything.

Finally, restoring virtual machines was far simpler than I imagined. After defining the NAS backup store to Proxmox, it’s possible to selectively restore particular images and choose which disks to put them on. I took the opportunity to move all my Retrocomputing VMs to a 4TB SATA drive, leaving the 1TB and 2TGB M.2 SSDs for performance-critical workloads.

The only way the restore process could have been slicker was if I could queue up restores of each of the backed-up images. Having a database image bordering on 750GB and not being entirely sure when it’d finish, and having half a dozen sub-4GB images which I had to restore one by one – that wasn’t the most exciting of afternoons. It seemed much quicker restoring one by one than restoring everything in parallel.

Would I do this again? Absolutely. Would I back up to a locally-attached hard drive as well as the NAS for speed? 100%.

Some years ago, I bought some APC Back-UPS Pro units to keep a few important but non-critical home items working. I’m particularly invested in this because living in a large city, there are frequent short outages and I’d rather not have all my network kit reboot each time the electricity supply sneezes.

Recently, I had to replace the batteries on two of the three UPSes as they’d served their eight-year life well. There’s nothing worse than having a UPS that doesn’t protect your equipment.

To swap the batteries is a breeze and with my units, I can do it without powering anything down. A more complex task is to set the battery replacement date within the UPS – two of mine were showing a 2-3 minute runtime even on a full battery.

There is Windows software to do this, but what if you don’t run Windows? On the Linux systems here, it turns out to be ridiculously easy using NUT:

upsrw -s battery.mfr.date=2026/03/01 ups

No, that’s really it. Both UPSes now show in excess of 30 minutes runtime, protecting against a power outage for 20 minutes or so before attached equipment will start to shut down.

I am a long-time user of Apache ActiveMQ. It’s served me well, and the tight integration with Apache Camel means I can interface with so many systems with relative ease.

In the past, I used to struggle with the concept of queues versus topics, persistent versus non-persistent messages, messages and expiry times. In some ways, it feels like magic, but it’s deterministic, and we like deterministic, and we also like documentation.

Here’s a bit of a walk-through of each of those concepts in a way that sense to me.

Test Setup

There’s a freshly unpacked ActiveMQ archive already on my machine, and I’m in the ActiveMQ directory itself.

I’ve placed the following in conf/local-configuration.xml. It sets up a Camel context, defines a single bean to connect to the local ActiveMQ service, and three routes.

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:util="http://www.springframework.org/schema/util" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd">

  <bean id="activemq" class="org.apache.camel.component.activemq6.ActiveMQComponent" >
    <property name="brokerURL" value="vm://localhost"/>
  </bean>

  <camelContext xmlns="http://camel.apache.org/schema/spring" id="camel">

    <!-- Send a message every 1s, expire after 10s, persistent -->

    <route>
      <from uri="timer://foo?fixedRate=true&amp;period=1000"/>
      <to uri="activemq:queue:EXPIRE.10S.PERSIST?timeToLive=10000"/>
    </route>

    <!-- Send a message every 1s, expire after 30s, non-persistent -->

    <route>
      <from uri="timer://foo?fixedRate=true&amp;period=1000"/>
      <to uri="activemq:queue:EXPIRE.10S.NONPERSIST?timeToLive=10000&amp;deliveryMode=1"/>
    </route>

    <!-- Send a message every 1s, expire after 15s, priority 1 -->

    <route>
      <from uri="timer://foo?fixedRate=true&amp;period=1000"/>
      <to uri="activemq:queue:EXPIRE.10S.NONPERSIST.PRI1?timeToLive=10000&amp;deliveryMode=1&amp;priority=1"/>
    </route>

  </camelContext>

</beans>

This uses the ‘timer’ component to produce a message every second (1000ms) and route it to a queue with a customisable time-to-live, delivery mode and priority.

I’ve also added the following line in conf/activemq.xml, just after importing jetty.xml:

<import resource="local-configuration.xml"/>

Overview

Looking at the web interface to ActiveMQ at http://localhost:8161/admin/queues.jsp, you’ll see three queues: EXPIRE.10S.NONPERSIST, EXPIRE.10S.NONPERSIST.PRI1 and EXPIRE.10S.PERSIST.

The messages in EXPIRE.10S.PERSIST are marked as persistent, and the messages in the other queues are marked as non-persistent. The messages in EXPIRE.10S.NONPERSIST.PRI1 are priority 1 whereas the others are the default priority of 4.

Persistence

Messages are either persistent or non-persistent. Persistent messages are written to disk and survive a restart, but non-persistent messages aren’t. As a result, if you restart your ActiveMQ server, non-persistent messages will disappear, and persistent messages will persist.

To see this in action, look at the user interface. You’ll see the same number of pending messages in all three queues. Now, restart the server by running ‘bin/activemq restart’.

Take a look again, and you’ll see that there are now more messages in EXPIRE.10S.PERSIST than the non-persistent queues. Why is this? Well, the messages marked as persistent are written to disk and survive a restart, whereas the messages in the queues queues don’t.

You might use persistent messages where you have an event that needs logging, e.g. a door being opened, and you need all the events. You might use non-persistent messages if you have a stream of messages from an electricity meter – it doesn’t matter if you miss a few on restart, because they’ll be generated again in a second.

Expiry

When you have nothing consuming from a queue, persistent and non-persistent messages will build up in the queue. Unless they’re consumed, they’ll sit there forever, consuming disk space and memory.

In each of our three queues, we’ve set an expiry, or time-to-live (that’s ‘live’ as in the opposite of death, rather than ‘live’ as the opposite of recorded) of 10 seconds.

Go back to the ActiveMQ web interface and look at the number of pending messages. This figure will be at least 10, and at most 40 – but why? Let me explain.

It’s computationally expensive to keep scanning queues to see if messages have expired, so ActiveMQ runs a task every 30 seconds to expire messages from queues. When we first start the server, the message count will grow from 0 to 10 every second. At the 11th second, the first message will have expired, and we’ll have placed another message on the queue. This will happen at the 12th through 39th second, at which any expired message will be removed, and we’ll be left with the last 10s of messages.

Dead Letter Queue

If you have ActiveMQ set up to use a dead letter queue (DLQ), then every message that expires will be sent to the DLQ. If you have a process which logs or reprocesses these messages, great. But if you don’t, then they’ll fill up the DLQ and give you the same problems as filling up a queue.

It’s possible to use a plugin in activemq.xml to discard messages sent to the DLQ if you don’t care about them:

<plugins>
  <discardingDLQBrokerPlugin dropAll="true" dropTemporaryQueues="true" dropTemporaryTopics="true"/>
</plugins>

Often, it’s important to check you have nothing on your DLQ because it indicates your clients aren’t consuming messages fast enough, so don’t make this plugin your default!

Background

Back when dial-up was 33.6k and HTML email was frowned upon, I ran my own mail server. This was a luxury that not many people had, but it gave me huge amounts of experience running a live service on the Internet.

There are several problems to hosting your own email. The most significant is that you’re responsible for everything. Whilst that means you have ultimate control, there are more exciting things to do in life than continually review DNS blocklists and anti-malware technology.

Around 2013, I decided that it was time to migrate to GMail, and let Google handle my e-mail. Google are huge, and huge is frequently (but not always) a good choice when it comes to service providers.

In 2021, I decided to split my company email away from my personal email, so set up a Microsoft 365 tenant and got used to the fact that I’d have two mail clients. That fact alone makes it so much easier to think of the bigger picture, what you’ll do in five years time when your business grows and you have more employees.

Keeping decisions under periodic review is good, as something that was right for you a decade ago may not be right for you any more – and that’s fine.

Given the direction the world could be going in, I decided it was right to migrate my personal email away from Google and on to Proton, an organisation with a different, more positive and more private outlook.

The process was entirely seamless, and I am happy with the Proton Mail client, the free VPN software (even though I use my existing VPN) and the cloud storage feature with Proton Drive.

Advice

For those of you who’ve never migrated email between providers, it can be a scary experience. Here’s my list of things to think about when you’re migrating:

1. Do you have control of DNS records for your domain? You need to be able to change these by yourself, commonly achieved by logging in to a provider’s web interface and submitting changes there.
2. Have you reduced the TTL (time-to-live) on the MX records in your domain to a much smaller value, e.g. 15 minutes? Doing this means that if you mess up some of your changes, you can roll back without the Internet caching invalid records for a long time.
3. Have you verified that your new provider can receive email for your domain name? It’s difficult to do without changing your MX records, but possible if you get friendly with telnet and submit a test email by hand.
4. Will your new provider deliver all email to one mailbox, or do you need to set up aliases? For example, you might have everything to @example.com sent to your mailbox, or you might have separate mailboxes for postmaster@ and hostmaster@.
5. Do you need to migrate your previous email to your new provider, or are you going to start from scratch? It might be that you just back up or download your mailbox and keep it locally if you don’t often refer back to old email. Or, you might want to migrate your sent and personal items, but ignore other folders such as bulk emails.

I can’t emphasise enough that lowering the TTL on your MX records is really important. Having caused a day-long outage years ago with a typo in an MX record, the simple act of saying “Don’t cache this for more than 15 minutes” can be an absolute lifesaver.

Appraising Proton

A month or so in, I’m very happy with Proton. The migration was seamless, and the tools very good. I can’t vouch for the level of support, nor for any outages, but those vary wildly between providers.

One weak point is that it wasn’t simple to migrate certain folders from Google to Proton. There’s Proton Bridge which you can run locally and use to copy over the email you want, but it seems very, very slow. That could be Thunderbird’s fault, or it could be the transactional nature of “download an email”, “upload an email”. Copying email overnight was the easiest workaround.

Another point is that I’ve not found out how to share my calendar with the Apple Calendar app on either my laptop or iPhone. Whether you consider this a negative or not will depend on your personal comfort levels, but it isn’t too much of a hassle here.

Proton VPN, which isn’t something I think I’ll use very often, is ridiculously straightforward and is a Wireguard configuration that takes seconds to configure. I’ve tried it out and it might prove useful when I’m on an insecure, untrusted WiFi network and want another layer of security. However, I have an existing VPN to my own equipment which will probably get used more often.

Conclusions

I’m happy with my decision. It was in no way as painful as migrations have been in the past, which I put down to the fact that this isn’t my first rodeo. If Proton doesn’t live up to my expectations, it’s my domain name so I can move it elsewhere.

After leaving the networking industry in 2013, I decided to replace the Cisco network equipment at home with Mikrotik for reasons of cost and power. Twelve years later, I’ve ditched Mikrotik and moved to Ubiquiti for some solid reasons.

What attracted me to Mikrotik was the price/performance ratio. I was using a Cisco 1801 with dual VRFs, terminating a PPPoE connection in one VRF, routing through a Cisco ASA5505 and dropping back in to a second VRF. When I upgraded from a 24Mbps ADSL2+ line to an 80Mbps VDSL line, I quickly found my setup wasn’t anywhere near powerful enough to handle 160Mbps of traffic.

Over the course of a decade, I went from a single RB750GL to a pair of RB4011iGS+RM routers, a pair of CSS326-24G-2S+RM switches and an assortment of CAPsMAN-managed access points. It worked well, but there were always some awkward parts – VLAN support was confusing, CAPsMAN seemed like magic that either worked or didn’t, and there was no firewall state synchronisation in RouterOS. But it was inexpensive, and I stuck with it.

The final straw came when one of my routers – handling WiFi and acting as a backup for the other handling PPPoE termination and routing – crashed without warning at 3am. It was stuck in a reboot loop, loading its kernel but then rebooting without any helpful error message.

I went through the manual process of moving CAPsMAN to the other router, but couldn’t get it working after four hours of trying. In the end, I reset one of my access points and set up a single SSID to get my IoT devices back online. It wasn’t optimal, but bought me time – but after a further eight hours of troubleshooting and little joy, I gave up.

Enter Ubiquiti. I’d heard of them but never looked at their kit. I started off with a U7 Lite access point. Management of all Unifi kit is via a centralised web interface, and setup was blissful despite my historical dislike of web interfaces for network mangaement.

Within a week, I’d bought the strangely named Dream Machine Special Edition which runs as a controller, switch and router. It took under an hour to get it up and running with two PPPoE connections, and I was happy. Unfortunately, it doesn’t have VRF support nor can it handle more than two Internet connections, so with two primary PPPoE and one backup domestic-grade fibre connection, I was a little stuck.

A quick explanation for those of you who are wondering why I use a pair of copper connections as a primary Internet connection, and fibre as backup. I don’t live in an area where OpenReach have FTTH available, and the only choice is VDSL or fibre from another ISP. The VDSL connections have a public routable address range – which is perfect for remote access – plus a very strong support team at the ISP. The fibre connection is a heck of a lot faster, a lot cheaper, but has a single static IPv4 address and is liable to multi-hour outages and latency spikes, so it’s relegated to backup connectivity only.

I decided to run one of the PPPoE connections alongside the fibre connection for a day or two, to see if I could route my home devices via faster fibre, and work devices via the other connection. To my complete amazement, this sort of policy routing was available without any complication, and is simply two routes to route traffic from the office network via one ISP, and everything else via another. Heck, I can even route specific traffic over a specific connection – low-latency ssh via VDSL and Facebook over fibre.

Within a few more days, I’d decided to replace the Mikrotik gear completely. A second U7 Lite handles the upper levels of my flat, and three scarily inexpensive Flex Mini 2.5G switches replace the desktop and lab switches. A Pro Max 24 switch, of which eight ports at 2.5GbE capable, has replaced the Mikrotik switches, and it’s game on.

The real test came when I needed to set up a VPN for access to some internal servers whilst I was travelling. Having struggled with RouterOS to set up a Wireguard VPN, on the Ubiquiti kit, it was a thirty-second job. Download a configuration, connect my laptop to a hotspot on my phone, set up the VPN and I’m in. Zero hassle.

I used the VPN consistently over the next week or so without any problem. I couldn’t even tell all my traffic was going through a tunnel and back out again, apart from when using on-train WiFi, but we’ll discount that as it’s universally dodgy at the best of times.

So now, less than a month after a decision to ditch a platform that had served me well for over a decade, I’ve migrated everything over to Ubiquiti and I couldn’t be happier.

After being inspired by Piotr Przybyl‘s talk about integration testing, I started off a new project with some thorough testing of a Spring Boot JAR.

Software development is full of obscure problems, and when uploading an object to an emulated Amazon S3 service using LocalStack, I kept getting the error:

java.lang.NullPointerException: host must not be null.

Not the most helpful error message, especially since I was setting endpointOverride on my S3Client builder in this way:

this.s3Client = S3Client.builder().endpointOverride(localstack.getEndpoint()).credentialsProvider(StaticCredentialsProvider.create(credentials)).build();

Some hours of painful searching suggested that the error message was pointing me in the wrong direction.

The solution? Add this to the Builder:

.forcePathStyle(Boolean.TRUE)