Currently offline – 2017-08-12 – resolved

It looks as though the asterisk is currently offline, as of 2017-08-12 14:25:01 (BST)

I’m not sure yet the cause of this problem. It could be anything from a power failure, to the dynamic dns failing to update, the router being offline, or the router having been reset losing the port forwarding configuration.

More information when I’ve got it.

Update 2017-08-12 22:11 – I don’t think it’s the Dynamic DNS this time. The asterisk regularly phones home to my monitoring server (a process that isn’t reliant on the Dynamic DNS) and it hasn’t reported in since 14:25.

Update 2017-08-13 12:00 Sam very helpfully went in, and found everything switched off. He powered up the UPS and we’re back in business… for now!

New feature! Faultsmans Ringback on VoIP Phones


A “faultsmans ringback” facility is useful for testing that you’re able to receive incoming calls. The idea is that you dial a special number, hang up, and the exchange calls you back.

On our UAX13 strowger exchange, we use this relay set: http://dfrtelecoms.org.uk/ex002.htm and a similar relay set on our PABX4 based exchange: http://dfrtelecoms.org.uk/ex027.htm – but on the asterisk phones we didn’t have a solution.

Until now!

If you dial ‘9#’ from any of our asterisk phones, you should hear a 3 tone “doo… dah… Dit!” sequence, which will repeat until you hang up. There should then be a short pause before your phone rings to indicate an incoming call. If you pick the handset up you should hear dialtone (although you won’t be able to dial any numbers)

The facility is still new, and we’re still ironing out a few wrinkles, but try it and let Paul know how you get on.

For anyone interested in asterisk, it’s based on the following dialplan contexts:

...
exten => 9,1,Goto(SIP-ringback,s,1) ; Faultsmans ringback
...

;======================================================================
[SIP-ringback] ; This context (and SIP-ringback-complete) do faultsmans ringback
;======================================================================
exten => s,1,Answer()
exten => s,n,Set(RINGBACK=${CALLERID(num)})
exten => s,n,Log(NOTICE, Ringback requested for ${RINGBACK})
exten => s,n,Wait(1) ; Wait 1s for the audio to connect
exten => s,n,Playtones(950/330,0/15,1400/330,0/15,1800/330,0/1500) ; "Dooh Dah Dit!"
exten => s,n,Wait(10) ; Play 10S of the above tone before hanging up
exten => s,n,Hangup()

exten => h,1,Log(NOTICE,Executing ringback for ${RINGBACK})
exten => h,n,Wait(3)
exten => h,n,Originate(SIP/${RINGBACK},exten,SIP-ringback-complete)

[SIP-ringback-complete] ; Used in conjunction with [SIP-ringback]
exten => s,1,Answer()
exten => s,n,Playtones(350+440) ; Dialtone
exten => s,n,Wait(10)
exten => s,n,Hangup()

There are a few knotty issues in the above, which mean that it’s not quite as predictable as it might seem at first – but I’ve got plan for ironing those out…

Downtime – fixed

It looks like at about 6pm on 12th July 2016, our external IP address changed at Norchard (so much for “BT Business – Static IP”) but for some reason our dynamic DNS didn’t catch up.

So the asterisk has been effectively offline since then. Service was restored at around 4pm on 14th July when I noticed it was down!

My phones are still offline (including his C*Net and SipGate numbers) due to some technical glitches at home, but that’s unrelated!

Asterisk back online – 2016-03-19

I managed to get to site yesterday with Peter, and the asterisk is now back on line and working again.

The fault turned out to be with the BT router at Norchard (again!)

This time it was a new failure mode I haven’t seen before. It had the port forwarding rules configured, but for some reason had decided it didn’t want to actually use them any more.

I took the port forwarding off and put it back again and everything sprung back to life.

And we’re offline again (mostly)

The Asterisk is currently offline (mostly)

Some classes of call can be completed in some circumstances (eg calling the speaking clock on 400 works)
Some calls complete but with no audio (I believe calls between our home phones do this)
All calls out to the strowger network fail.

Calls in from the sipgate dial in number get as far as the voice prompt on the asterisk box itself, but can’t dial out into the strowger and seem to have the same audio problems (ie if I call my voip number I get no audio)

My remote access has stopped working, so I can’t troubleshoot it in detail from here, detailed troubleshooting will have to wait until I’m able to get on-site. Unfortunately that’s not until Saturday 9th April.

Updates will follow on here as and when I know anything.

Asterisk to UAX Junctions – Update

Over the Christmas period, I spent quite a lot of time giving out Asterisk config a good going over, trying to identify the root cause of it not always releasing junctions at the end of a SIP->UAX call.

In the process, I found and fixed several issues.

  • We now pause slightly before dialling, to play a little nicer with slow line finders.
  • Whenever we use Dial to send a call out to the UAX, we explicitly jump to the (h)angup extension, so that we can trap the end of the call
  • We’re now a bit more thorough about logging what we’re doing as a call progresses. This isn’t a “fix” as such, but it does help debugging intermittent errors
  • Our DAHDI config was using Loop Start (ls) rather than the preferred KewlStart (ks) signalling. ks is supposedly a bit better at disconnect supervision
  • We upgraded from Debian Wheezy to Debian Jessie. This gives us an upgrade to a more recent version of asterisk
  • In sip.conf we now set an rtp timeout so that we end the call if we don’t receive any RTP (audio) traffic for 60 seconds. This should help to end calls which haven’t been torn down properly
  • We turned off “SIP ALG” on the BT Business Hub router as this seems to be causing SIP packets to occasionally go astray
  • We were rotating the logs a little aggressively and were only keeping a couple of weeks. This has been expanded so we now keep several months – which should make retrospectively investigating issues easier.

With all that done, we decided last week to reinstate one of the junctions from Asterisk to UAX. By only enabling a single junction, we can easily detect when it gets stuck (as any subsequent calls will get NU from the asterisk)

It’s been back up for a week, and so far it’s working well. I’m still keeping an eye on it, and will continue to do so for a while before we re-enable the second junction.

Calls from Asterisk->UAX offline

To quote todays diary entry from http://dfrtelecoms.org.uk/diary15.htm

December 19: Peter came in today to find an alarm from Lydney Signal Box. Rick and I met him at the box. It was a low volt alarm caused by a junction held permanently. This had the ringer running continuously. The volts were down to 29 when we arrived. Disconnecting the junction cleared the fault and stopped the ringer. The battery voltage started to rise slowly. Hopefully it will all be OK. Back at Norchard we found the Asterisk holding the connection. We don’t know why, the circuits from the Asterisk have been pegged out and the problem referred to Paul.

As a result, calls from the Asterisk to the internal phones at the railway are offline. (This includes calls connected from the sipgate number)

This problem seems to have started since we moved the FXO ports on the Asterisk from being directly connected to an incoming selector on the UAX, to being connected to a pair of line circuits.

I can’t get to site to do any direct investigation (and I can’t get to my copy of Atkinson to do any diagram based theorising because it’s all packed up for some decorating work) but I suspect something is behaving differently from an electrical point of view.

I have a hunch it might be related to line reversals on called-sub-answer, but I need to check that before I can make any changes or recommend that we reconnect the circuits.

Watch this space…

Back online…

Well that was an effort.

We’re back online, it seems my port forwarding documentation is accurate – but our dynamic dns provider is being “less than perfect” at the moment.

To cut a long story short, they were claiming we hadn’t changed our IP when we had (even when I tried to force an update) so weren’t propagating the changes.

All sorted for now, but I’m going to have to find another way around this DDNS issue.