Author: Paul

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.

New router

We’ve got a new BT Broadband router, and the new one hasn’t been configured to work with the asterisk yet.

So at the moment, the phones we’ve got at home are all offline, and my remote access is also offline so I can’t fix it remotely.

The monitoring doesn’t make this state of play obvious, but I’ll sort that out once I’ve got access.

It’ll all come back to life when I next make it to site (hopefully Saturday 21st, weather permitting)

New monitoring

Since we went static IP for our broadband, I can no longer infer the state of the Norchard broadband from the number of times we change IP address per hour (previously every time the broadband connection went down it would come up on a different IP address)

So I’ve put some better monitoring in place, and http://dfrvoip.org.uk/blog/status/ now tracks our connection to the outside world by pinging the google DNS servers.

Due to the way they’re hosted – the graphs on that page might not be visible on every interenet connection. I’ve got a few ideas about how to change that, but they’ll have to wait for another day as life is somewhat hectic at the moment!

The technology I’m using is pretty basic network monitoring software called smokeping. It’s not my monitoring tool of choice, but it’s easy to install and get going – and for something as simple as monitoring a single internet link it’s pretty good.

The gratifying results of this are that our current broadband looks a lot more stable than the previous broadband!