Posted on June 10, 2014 by Paul

Dynamic DNS woes - resolved

Our Dynamic DNS provider http://dnsdynamic.org seems to be having problems at the moment, and our wonderful BT Broadband has decided it wants to change its IP address right at this moment. The practical upshot is that we've been offline since about 2pm yesterday. I'm working on a fix.
Update: Yesterday I changed our dynamic dns provider to http://noip.com, and it looks like my changes propagated by around 10:30pm last night - so we're back in business.

Posted on July 5, 2014 by Paul

Saturday work, on-site

Once again, the BT Business Broadband router "forgot" its port-forwarding config on Thursday, which has led to a patchy telephony experience and a lack of remote access. Unfortunately this needs me to be on-site to fix it, as without the port-forwarding config I have no remote access - so I can't easily put it back remotely! With that done I turned my attention to the ATA in the Norchard exchange. I traced the fault to a patch lead in the shop office which had been disturbed. A quick wiggle of the cables and we're back in business.
We're off the net again. This time it's because Microsoft have seized control of the domain names used by our Dynamic DNS provider. More details are here:
https://www.noip.com/blog/2014/06/30/ips-formal-statement-microsoft-takedown/
I'm doing the switch-dynamic-dns-providers dance again...
Update 21:00: It looks like the changes have propagated at least as far as everyone who has an ATA so we should all be back on and chatting again. Apart from me - as I've had to switch my asterisk and PAX off and cover them in a dust sheet as I'm having my fireplace enlarged tomorrow and don't want to fill the selectors with dust!

Posted on July 9, 2014 by Paul

Router issues, BT Broadband and DMZPlus

I spent 3 episodes of Star Trek TNG last night going round in circles with the Norchard router. It's doing something very odd. What's supposed to happen
1. Call setup traffic (SIP) comes in from the internet, hits the port forwarding rules and is passed on to the asterisk
2. Voice traffic (RTP) comes in from the internet, hits the port forwarding rules and is passed on to the asterisk
3. Voice traffic from the asterisk is passed back out to the internet
What's happening
1. Call setup traffic (SIP) comes in from the internet, hits the port forwarding rules and is passed on to the asterisk
2. Voice traffic (RTP) comes in from the internet, misses the port forwarding rules completely and is passed on to "DMZPlus" which is a feature of the router that forwards all traffic to a pre-defined computer without filtering it.
So the RTP stream is being forwarded to the wrong place, never hits the Asterisk, which is why I can see calls being set up but no one gets any audio. However, what I can't determine is where "DMZPlus" is sending the voice traffic. None of the "connected devices" appear to be configured for DMZPlus, and there's nothing in the special DHCP pool the router uses for that function. I can attempt to set up the asterisk box as the DMZPlus target, which should bypass the flaky port forwarding on the router, however doing that remotely is risky as if anything happens in the wrong order I'll be locked out from remote management so won't be able to fix it. It'll have to wait until I'm on site.

Posted on July 24, 2014 by Paul

New Feature: Members only section

We now have a members-only section of the website, which is only available if you're a registered user of the DFR Asterisk system. Currently it only contains a full DFR telephone directory (All the Strowger, and all the VoIP numbers, including details of all the test numbers) but it gives me somewhere I can put clever stuff, like the automatically updating "whose ATAs are online at the moment?" widgetry I've got planned, or the detailed technical documentation for the Asterisk - pretty much anything we want to publish which shouldn't be public! If you'd like an account, email signup@dfrvoip.org.uk and I'll set you up with a username and a temporary password which you can change once you're logged in.

Posted on July 25, 2014 by Paul

Dial-in from the PSTN - fixed!

I've managed to fix the settings for the VoIP provider we're using, to allow inward system access from the PSTN. So now, if you phone the (secret) magic phone number, it will now actually recognise the PIN when you enter it and let you in.

Posted on August 12, 2014 by Paul

UPS Batteries

The power at Norchard is a little unreliable at times so the Asterisk server is protected by a UPS. The picture (not available on this site) shows the UPS (on the left), the BT Voyager 220 router which we've re-purposed as an ATA for test purposes (on top of the UPS) and the asterisk box itself (on the right). The UPS is an APC SmartUPS 1500 which was donated to us a few years back.
It's been complaining recently that its batteries are deader than a doornail, nailed through the foot of a dodo. Which isn't surprising, as they're 10 years old at this point. A couple of weeks ago I sourced some reasonably priced replacements from Amazon, and I spent 45 minutes this morning wrestling the UPS down from its shelf and swapping out its batteries. It's now cheerfully reporting that its batteries are in good health, and that with the current load (just the Asterisk) it should be able to run for a little over 1.5 hours if we have a mains failure.
Today was also John Bathgate's 80th Birthday party. Happy birthday John!

Posted on August 22, 2014 by Paul

Our first power failure on the new UPS batteries

We had a 30 second power failure today (times are in UTC)
Fri, 22 Aug 2014 11:56:03 +0100 Power Failed!!!
Fri, 22 Aug 2014 11:56:32 +0100 Power Restored
The UPS did its thing, and the asterisk box stayed up. It looks like the Norchard broadband didn't, so that'll take a little while to sort itself out (as usual). I'm glad I replaced those batteries now!

Posted on September 1, 2014 by Paul

For a while now, we've been using a lightweight dynamic dns update client which I found on the web somewhere. It was reasonable, but it doesn't always play nicely with the BT Broadband router. If it attempted to make an update while the router is rebooting, the BT Broadband router returns an error page, which made the script think it had saved it's IP correctly. The practical upshot is that sometimes our IP address would be out of sync until the router had rebooted 2 or 3 times. Luckily for us (?) the Norchard Broadband is so flaky that it frequently reboots 3 or 4 times within an hour.
Anyway. I've ripped the script apart and rewritten it from the ground up to be more flexible. I've beefed up the logging, and now if it encounters a temporary error it does nothing until the next time it runs (a minute later) - when it should sort itself out. If you're interested, you can grab it from here https://github.com/paulseward/yaddc

Posted on September 7, 2014 by Paul

Directory Updated

The (members only) directory page has been updated to include the number for the new cafe building.
Talking of the members only pages, due to a performance issue with the previous way of handling members-only pages, I've switched plugins (from "User Access Manager" to "Restrict Content" if you're interested) and the new one performs much better, so pages shouldn't be painfully slow to load any more. However, if you're not logged in the new plugin doesn't display a friendly message asking you to log in - it just gives you a page title and no content. When I get a moment I'll see if I can prod at the code until it does something more friendly, and then submit a patch back to the plugin maintainer.

Posted on September 9, 2014 by Paul

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 (not available on this site) 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.

Posted on September 21, 2014 by Paul

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 https://www.ckts.info/directory. 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!

Posted on September 25, 2014 by Paul

Shellshock

"Shellshock" has been reported in the news a lot over the last day or so (eg http://www.bbc.co.uk/news/technology-29361794 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 our setup is - at worst - extremely difficult!). However, this evening I've made sure we're all patched and up to date. Nice and tidy.

Posted on<b> September 28, 2014 </b>by Paul

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!

Posted on November 2, 2014 by Paul

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
[MuseumDisplay-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 five 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)

Page provided by John Bathgate This page was last updated on 8th July 2019