Two minor fixes

I’ve done two minor fixes this week:

  • Status Graphs: These were being updated, but not drawn for most visitors. I’ve fixed that now, if you still have no graph try a force refresh of the page (ctrl-f5)
  • Speaking Clock: Ian noticed that it was saying “thirty four” twice, skipping “thirty five” and jumping straight to “thirty-six” – This was a fault I fixed on my asterisk server years ago, but seemingly never applied the fix to the railway version. The route cause was that the “35.wav” file contained the words “thirty four”. I’ve updated to a newer version of the samples and everything is working again.

I’m going to re-think the status graphs, as we now have static-ip so don’t need dynamic DNS any more (so don’t really need to monitor it any more).

Perhaps I’ll finally write the peer monitoring stuff as well, so we can spot when sipgate goes away.

We’re definitely back now. Hopefully.

After much head scratching, inconsistent one way audio problems, some routes through the astersisk producing audio some not…  I noticed I’d set the port forwarding on the router for the RTP stream as “TCP” not “UDP”.  Simple slip of the finger, ticked the wrong box on the router interface.

It caused some really weird problems though!

Any audio path which resulted in the asterisk setting up the RTP stream worked, but anything which relied on the VOIP phone initiating the RTP stream ended up with either no audio, or one way audio.  This wasn’t immediately obvious from the pattern of symptoms as reported!

Anyway, I have rectified the error, ticked the right box, and my testing seems to suggest that it’s working now.

I’ll try and fix the next fault a bit quicker, promise!

And we’re back. Hopefully.

The router was reset on March 15th to try and troubleshoot the persistent problems we’re having with it, unfortunately in the process all the port forwarding rules we require dropped off the router.

Due to holidays, easter and various other commitments I wasn’t able to attend until April 7th and while I thought I’d fixed it then I discovered when I got home that I hadn’t – and that one of the changes I thought I’d made hadn’t been saved.

So it’s now April 18th (over a month since James reset the router under advice from BT) and we should now be back online.

I think this is a perfect example of why the DFR VoIP system should never be considered a “production” or “business critical” service – anything which goes wrong and relies on a chap who lives a 40 minute drive away and has a full time job (so isn’t available in business hours) just isn’t going to have a quick turnaround for fixes!

Level 0 – Special Services

The new “Level 0” relay set currently only has one line connected to it, for test purposes. It was pointed out to me last night that we hadn’t added it to the dialplan, so Level 0 services weren’t available from SIP phones.

I’ve now rectified that, and we’re currently matching 0X and 0XX numbers as being destined for Norchard special services.

If we deem any of the special services “inappropriate to dial from SIP phones” (as we have with the fire alarm number) I’ll bar them individually, but for now everything on 0X and 0XX is available from the asterisk.

I’ve also updated the directory listing over in the sidebar, to include the level 0 services.

Up… and Down…

On the 29th, I initiated an upgrade[1] to my broadband connection at home, and the engineer who was sent out botched the job and moved the wrong pair in the cabinet – so my number (491) has been offline for a week.

I’ve now fixed that, but it looks like the DFR has dropped off the internet!

Hopefully, it’s just that the power to the router has tripped out, and someone will fix it tomorrow when the shop opens.

If it’s not all working again by the 10th, I’ll be on-site anyway and will work out what’s going on. More details when I get them!

[1] I’m now all swanky and 40Mbit!

Update: Service was restored 2015-01-06 11:48 – No word yet what the problem was!

Severn Bridge Disaster Museum Display

A little over a week ago, we installed a phone in the museum as part of a display about the Severn Bridge Disaster of 25th October 1960. This allows visitors to pick up the handset, and by dialling a single digit they can listen to one of 10 pieces of audio taken from a BBC Radio Gloucestershire program about the disaster.

The phone was installed on the 22nd Oct, just in time for the 54th anniversary of the disaster. So far, it’s had 11 calls, with the most popular section being the one about “The night of the disaster”

Technical details:
The phone itself is just a cheap DTMF handset (easy to replace when the public break it!) connected to a Cisco SPA112 ATA. The ATA is configured to expect a single digit and then dial immediately (I’ve set the dialplan to “x”)

The ATA registers itself with the Asterisk with a restricted SIP account, which lands in its own context. That context is pretty simple, and the dialplan for it looks like this:

; Samples should be placed in /usr/share/asterisk/sounds/bridge - eg
; ln -s /etc/asterisk/museum_display/bridge /usr/share/asterisk/sounds/bridge

; Severn Bridge Disaster - 10 audio files, bridge/bridge_[1-0].mp3

; Single Digit Extensions play back selected audio
exten => _X,1,Answer();
exten => _X,n,Playback("bridge/bridge_${EXTEN}");
exten => _X,n,Hangup();

; Everything else gets "number not recognised"
exten => _.,1,Answer();
exten => _.,n,Playback("bridge/not_recognised");
exten => _.,n,Playback("bridge/not_recognised");
exten => _.,n,Playback("bridge/not_recognised");
exten => _.,n,Playback("bridge/not_recognised");
exten => _.,n,Playback("bridge/not_recognised");
exten => _.,n,Hangup();

It’s a pretty straight forward context. Any incoming call which matches a single digit (“exten => _X”) plays back one of the 10 audio files relating to the disaster.

Any other incoming call (“exten => _.”) plays a message which says “That number is not recognised, please hangup and try again” it repeats the message 5 times, then hangs up.

The “number not recognised” block shouldn’t get hit in normal use, because the ATA is configured to only send one digit.

It’s mostly there for testing, in case we ever have to replace the ATA in a hurry with one that can’t be set to dial immediately, or in case we ever decide to allow access to this feature from elsewhere in the dialplan (eg from C*Net)

Asterisk back talking to the Strowger again

It seems that when I was fixing Shellshock the other day, I managed to get the server into a state where it didn’t know it had a card in it which can talk to the Strowger, so dialling in/out of the asterisk over the junctions to the UAX failed.

I’ve now fixed this!

Click “Continue Reading” to see lots of boring linux related technical details of the problem/fix.

Continue reading


“Shellshock” has been reported in the news a lot over the last day or so (eg and you might be forgiven for thinking the sky was falling in!

This is just a quick post to say that we weren’t particularly exposed to this security vulnerability in the first place (we were running a vulnerable version of the software concerned, but remotely exploiting that vulnerability in out setup is – at worst – extremely difficult!)

However, this evening I’ve made sure we’re all patched and up to date. Nice and tidy.

Dean Forest Railway – now on CNet!

CNet is a network of heritage telephone exchanges around the world, connected together over the internet.

We’ve recently joined, and if you’ve got a DFR VoIP phone at home, you can now make calls to CNet numbers around the world! For directory listings of numbers you can try calling, see

Incoming calls from others on CNet to DFR VoIP services are possible, although at the moment I’m planning on making this opt-in.

So if you’d like CNet members to be able to call you, drop me (Paul) an email and I’ll assign you an inbound CNet number. If you’d like it to only work at certain times of day (eg 10am-9pm) that is possible as well.

We’ll be making a small set of facilities available to external CNet callers, and we’ve started with the speaking clock – which is now available on CNet +44 (0)594 48081

It’s only been available for 12 hours or so, and has already been called 16 times by 10 people on 3 continents!

DDNS tracking reliability confirmed

I’ve just been looking at the monitoring for our dynamic dns and it looks like the new update script is tracking our IP changes reasonably well.


The top graph shows the state of our DNS entries. When the line is “high” it means everything is working fine, when the line is “low” it means that our DNS name doesn’t resolve to the right IP address because our IP has changed and the DNS hasn’t caught up yet.

The bottom graph shows how many IP addresses the monitoring has seen per-hour. On a healthy broadband connection, that line should be fairly flat. However, the broadband at Norchard is so flaky that the router drops sync several times a day – getting a new IP address in the process.

So you can see, on the left hand side of the red line – we were frequently losing sync with our DDNS provider with the old script in place. With the new script in place we were out of sync for a 1 minute period yesterday, despite experiencing 7 changes of IP address!

Why is the broadband so flaky? As it gets worse in damp or cold weather, I suspect an earth leakage on one leg of the line caused by a damp joint, or a nick in the cable somewhere between Norchard and the exchange.

However I’ve always been told the Norchard broadband isn’t our responsibility – so I’m not best placed to get that looked into.

The “powers that be” seem hell bent on moving away from BT Broadband to Chess (and if I try and get the BT broadband fixed, they’ll moot that as a “cure”) – although that’s not going to improve matters if it’s the line plant which is at fault.

Which I’m fairly certain it is.