How to: make use of a locked VoIP ATA with asterisk

So you've got a VoIP ATA but it's locked to one provider and you want to make better use of it?

You've searched all over the net on how to crack or hack the firmware to unlock it but given up all hope?

Well, I've worked out an interesting way to get around this problem. This works with my Netgear TA612V that is locked to MyNetFone here in Australia. Essentially, what you can do is set up an asterisk server to pretend to be your provider. Here is roughly how I did it:

You'll need:

- a DNS server such as bind (and know how to set it up)

- to be able to redirect DNS requests to your bind server (some ATA's don't use your network's DNS server provided by DHCP) - i.e. you'll need to be able to add a port redirect on your router

- asterisk and the desire to learn how it works and to set it up

A note, my server has the IP address 10.0.0.250

1) Set up bind to redirect the domain name of your provider's sip server to your own. I did this by setting up a hosts file in bind for sip01.mynetfone.com.au and adding the following host:

sip01.mynetfone.com.au. IN A 10.0.0.250

2) Redirect all UDP port 53 requests from your local network (but not your server!) to your server. I use shorewall firewall and did that with the following line:

REDIRECT loc 53 udp 53 - !10.0.0.250 # Transparent DNS

3) Add accounts in your asterisk sip.conf for your ATA to log into. The following is what worked with my TA612V:

[09*****4] ; ATA line 1

canreinvite=yes

type=friend

secret=********

host=dynamic

dtmfmode=rfc2833

context=ta612v

[09*****5] ; ATA line 2

canreinvite=yes

type=friend

secret=********

host=dynamic

dtmfmode=rfc2833

context=ta612v

Naturally, I've *'d out my username and password. A note, I originally found that this didn't work if I had both lines set up in Asterisk (there was a bug with the TA612V and old versions of asterisk) however, with 1.6.2 this seems to be fine now.

You'll then need to edit extensions.conf in asterisk to create dialling plans. Unfortunately, as the ATA will be programmed with you'r providers dialing plans, you won't be able to set up extensions (dial 1 to 9 for each extension or dial 0 for an outside line). What I mean by this is that (for example) my ATA is set up to accept either a 10 digit number if the first digit is 0 (eg 02xxxxxxxx or 04xxxxxxxx) a 10 digit number for numbers starting with 1300 or 1800, a 6 digit number for other 13xxxx numbers and also to send 121 to voicemail. This is all needed because the ATA needs to know how many number presses to wait for before it sends the dialled number and create the call.

This is how I set up my extensions.conf

[ta612v]

exten => _X.,1,Dial(SIP/${EXTEN}@othersipprovider)

exten => _121,1,Dial(SIP/111@othersipprovider)

exten => _09X.,1,Dial(SIP/${EXTEN}@mynetfone)

You can see I've set up outgoing calls to go via an alternative sip provider, I've configured dialling 121 to go to my other sip provider's voicemail (which is 111) and I've configured all 09 numbers to go via mynetfone (as 09XXXXXX is the format of mynetfone's direct numbers). In theory, you could set up an extension (like 121) to connect you to an asterisk IVR extension where you could select which extension to dial or which provider to dial out on. I'm thinking of doing this but haven't had the time to look into this. Asterisk is an immensely powerful voice service and the possibilities are endless once you've got your ATA working with it.

Legalities: Whilst hacking or cracking the firmware of a locked ATA is definitely a grey area legally, (whilst I'm no lawyer) I feel that the above approach is generally OK. In doing the above at no stage have you had to reverse engineer any form of encryption or even modify the firmware of your ATA.

What surprised me is that there is no challenge/handshake authentication that occurs between these ATA's and the provider. In theory it would be incredibly easy to intercept these authentication details on a network and hack into someone's SIP account (just use some packet sniffing software and you can see for yourself the SIP authentication process with your username and password there in plain text) - however this would be illegal, I'm just pointing out how insecure I found the whole system to be!

Finally, I know I haven't been very detailed with this how-to but the reasons are:

1) I'm short on time at the moment

2) There are a huge number of combinations of the tools and devices and providers - I've provided you with the idea on how to do it, it's up to you to work out how to do this with your setup