Asterisk 1.8.x and FreePBX users: How to NOT answer Google Voice calls UNTIL the called extension answers

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

EDIT (May, 2018): FreePBX and Asterisk users that wish to continue using Google Voice after Google drops XMPP support should go here: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware.

This article was originally published in December, 2010 and may contain out-of-date information.

Many folks are experimenting with Asterisk 1.8.x and Google Voice.  In most cases the way it’s set up is that when a Google Voice call arrives, Asterisk answers the call, then sends a touch-tone digit “1” to Google Voice to answer the call, then proceeds to ring the destination extension.  This is necessary because when you configure Google Voice to use a Gtalk destination, they require you to press “1” to accept the call, even if you’ve configured Google Voice not to require that.  I don’t know if this is a bug in Google Voice or if they did it that way deliberately for some reason, but answering the call and accepting it upon arrival at the PBX has a few unintended side effects:

  • If your callers pay for long distance by the minute, they get charged from the moment the called extension begins ringing – even if you never answer the call.
  • You can’t use Google Voice’s Voicemail, nor their transcription service, because you’ve already answered the call.
  • Callers may hear a confusing double ringing tone at the start of ringing — one ring from Google Voice and the rest from Asterisk.

On the other hand, there are some advantages to doing it that way:

  • Because you’ve answered the call, you can let the extension ring as long as you like before sending it to voicemail, and Google Voice won’t snatch it away in 25 seconds and send it to their voicemail.
  • You can use Asterisk’s voicemail, if that’s what you prefer.

For those who’d prefer to let Google Voice handle their voicemail, or who object to making callers pay to listen to up to 25 seconds of ringing, there is a way to not answer the call and send the touch tone “1” until  after the destination extension has actually picked up the call.  If you are using plain vanilla Asterisk, all you have to do is make sure your Dial() command contains two additional options.  Consider this example line of Asterisk dialplan:

exten => gvoicein,n,Dial(SIP/1004,35,rTWtwaD(:1))

The important part here is the aD(:1) — the other options can be whatever you’d normally use, if any, but it’s the aD(:1) that does the magic. Now at this point, if you’re a FreePBX user you may be wondering how on earth you can modify the Dial() string, since the code that generates it is buried deep within the bowels of FreePBX. Fortunately, there is a way. Consider the following piece of code that might be used in extensions_custom.conf to bring in Google Voice calls:

[googlein]
exten => _[0-9a-z].,1,Noop(Incoming Google Voice call for ${EXTEN})
exten => _[0-9a-z].,n,Set(CALLERID(name)=${CUT(CALLERID(name),@,1)})
exten => _[0-9a-z].,n,GotoIf($["${CALLERID(name):0:2}" != "+1"]?notrim)
exten => _[0-9a-z].,n,Set(CALLERID(name)=${CALLERID(name):2})
exten => _[0-9a-z].,n(notrim),Set(CALLERID(number)=${CALLERID(name)})
exten => _[0-9a-z].,n,Wait(1)
exten => _[0-9a-z].,n,Answer
exten => _[0-9a-z].,n,Wait(1)
exten => _[0-9a-z].,n,SendDTMF(1)
exten => _[0-9a-z].,n,Goto(from-trunk,gv-incoming-${CUT(EXTEN,@,1)},1)
exten => h,1,Macro(hangupcall,)

With this context you’d use gv-incoming-username (where username is the part of the associated gmail address before the @) as the DID in your inbound route — a DID doesn’t have to be numeric even if FreePBX whines about it, and the advantage is you only need one context to handle incoming calls for all your Google Voice accounts.  This particular context is slightly modified from one found in the PBX in a Flash forum, but note that it contains these four lines that wait ONE second, answer the call, wait ONE second (you do NOT have to wait two seconds, despite what any other article may say, and in fact the one second wait might be unnecessary), and then send the touch tone digit 1:

exten => _[0-9a-z].,n,Wait(1)
exten => _[0-9a-z].,n,Answer
exten => _[0-9a-z].,n,Wait(1)
exten => _[0-9a-z].,n,SendDTMF(1)

You will find those four lines, or some variation on them (sometimes just the last three), in just about every published method for using Google Voice with Asterisk and FreePBX.  But, in FreePBX at least, you can replace them with this:

exten => _[0-9a-z].,n,Set(DIAL_OPTIONS=${DIAL_OPTIONS}aD(:1))

This slides the aD(:1) into the options that will be used with the Dial command, so when the extension answers, the call will be answered and then the touch tone “1” will be immediately sent to Google Voice, and then the audio between Google Voice and the called extension will be bridged as usual.

Unfortunately, or maybe fortunately depending on your point of view, it appears that if the call should go to Asterisk’s voicemail, the call will not be answered and the DTMF 1 will never be sent.  This means that if, for whatever reason, you don’t answer the incoming call, after 25 seconds it will go to Google’s voicemail.  There are doubtless ways around that (and if anyone’s truly interested, leave a comment and I’ll suggest a way that may work, that involves routing the incoming call to a ring group first) but I suspect that the majority of people who want to do this will be doing it because they want to use Gmail’s voicemail.

I’ve tested this and it works for me, though I would not use it on a regular basis because I prefer Asterisk’s voicemail.  If it doesn’t work for you for some reason, the only suggestion I can offer is adding a w before the :1, so the added options look like aD(w:1) – that will add a one-half second delay before the “1” is sent, and more than likely it won’t help one bit, but may cause callers to not hear your “hello” or other greeting.  But, you can try it and see — at least one user has reported it to be necessary.  If that doesn’t work, I probably won’t be able to help you but if you leave a comment, maybe someone else can.

And, should anyone from Google Voice read this, it would be really helpful if you’d do two things:

  1. Give us a way to disable Google Voice’s voicemail so we don’t have to resort to hacks like this to discourage callers from leaving a message there.
  2. Fix the bug (or “feature”) so that when we turn off call screening, it’s off for ALL destinations, including Gtalk!

Link: Interesting security technique for Asterisk and FreePBX users (may work with other SIP-based PBX’s also)

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This article was originally posted in November, 2010.

NOTE: For some reason WordPress absolutely hates it when I try to edit this post, and turns links and other things into piles of steaming poo.  If things don’t look right here please e-mail me or leave a comment and I’ll check it out.  WordPress, I KNOW how I want my articles to look, why can’t you just leave them alone?

One problem faced by some SIP-based VoIP PBX administrators is the issue of security when you have external extensions (that is, extensions located anywhere in the world that’s not a part of your local network). You want to allow those extensions (the ones you’ve authorized) to connect to your system, but you prefer to keep everyone else out, and preferably not even tip them off that there’s a PBX there. The idea is, if the bad guys that would like to break into PBX’s don’t even realize that there is a PBX at your IP address, they won’t waste any time trying to crack into your system.

There have been other suggestions for how to handle this but many of them require your users to take some additional action(s) that they would not normally have to take, and users hate having to lift a finger to do anything to enhance their security. Which brings us to a rather clever technique that doesn’t require user to do anything other than use their phones as they normally would. It might be a tiny bit of a pain to set up initially, but the results may be worth it. I would call this medium level security because if someone is sniffing your packets, this alone may not keep them out, but most of the lowlifes that try to break into PBX’s don’t actually have sufficient access to sniff your packet stream (and also, they’d have to know the exact technique you’re using to be able to crack this). So without further ado…

Secure your VoIP server with the SunshineNetworks knock

(As of October 24, 2012, the above link appears to be DEAD — see the edit at the end of this article)

Note that while the article recommends changing the SIP port to something other than 5060, their basic technique (the “knock”) should still work even if you feel you need to stay on 5060. My only fear about changing the SIP port would be the possibility of losing communications with VoIP providers and with other systems I legitimately send/receive voice traffic to/from. They’re probably going to keep using 5060 even if I don’t. EDIT: My concern here may be unfounded — note the comment below from Alex of Sunshine Networks, who said that “changing the SIP port is quite safe. Your SIP server will send this SIP port along in it’s first SIP invite registration to the VoIP provider. So unless your VoIP provider is actively blocking out anything else than port 5060, it should work fine. We use this technique with 3 different major SIP providers in Australia and never had problems. So far we haven’t seen any unintended consequences.”

I haven’t personally tested this, so if you do, please consider leaving a comment to let me know how it worked for you. The two things I wonder are, do these rules survive a reboot, and can you have more than one secret phrase that would let people in (in case you want to use a different one for each external extension)? EDIT: Those questions are also addressed in Alex’s comment below. Also, those of you running PBX in a Flash should take note of Ward Mundy’s comment about changing an entry in /etc/sysconfig/iptables in this thread. In that same thread, there appears a method to view the “knock” each extension is currently sending — just do “sip debug” from the Asterisk CLI for an hour or so (long enough for all your endpoints to register, after which you can use “sip no debug” to turn it off), then run this at the Linux command prompt (not from the CLI!):

grep "From: " /var/log/asterisk/full|cut -f1 --delimiter=; | sort -u

For each of your remote extensions, you’ll see a line that looks something like this:

From: The Knock <sip:234@nn.nn.nn.nn>

“The Knock” may or may not be enclosed in quotation marks, but it apparently doesn’t matter (you don’t include them in the iptables rules). If you haven’t used a specific “knock”, it could be the actual user’s name, if you set that up when you first set up the endpoint. Anyway, I’d suggest running this BEFORE you actually implement the iptables rules, so you know ahead of time what each endpoint is sending.

EDIT (Added January 8, 2012): I am now using a slight variation on this technique on one of the systems I administer. Without going into too many specifics, I will just note that some SIP devices and VoIP adapters actually already send a unique string that you can use as a “knock” – you do not have to configure a new one, you just need to find out what the device is already sending and use that. For example, let’s say you have an VoIP device connecting to your Asterisk server as extension 234. All you have to do is go to the Asterisk CLI (NOT the Linux command prompt) and enter this:

sip set debug peer 234

(Replace 234 with the actual extension number). Now, assuming that the device is connecting to your server, you will start to see SIP packets scroll across your screen. Within a few minutes you should see one like this (IP addresses have been xx’ed out):

<--- SIP read from UDP:xx.xx.xx.xx:5061 --->

REGISTER sip:xx.xx.xx.xx:5060 SIP/2.0
Call-ID: e10700c2@xx.xx.xx.xx
Content-Length: 0
CSeq: 56790 REGISTER
From: <sip:234@xx.xx.xx.xx>;tag=SP8f427e45f1e19cb24
Max-Forwards: 70
To: <sip:234@xx.xx.xx.xx>
Via: SIP/2.0/UDP xx.xx.xx.xx:5061;branch=z4b9hGK-4f0473a8;rport
Authorization: DIGEST algorithm=MD5,nonce=”37cd169d”,realm=”asterisk”,response=”a726bfed5db321a7bc967b997b5157c2″,uri=”sip:xx.xx.xx.xx:5060″,username=”234″
User-Agent: xxxxxx/xxxxxx-x.x.x.x
Contact: <sip:234@xx.xx.xx.xx:5061>;expires=60;+sip.instance=”<urn:uuid:nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn>”
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER
Supported: replaces

<————->

If you don’t see this you may need to increase the debug level. After you see a packet like this, you can turn off sip debugging:

sip set debug off

The string you are looking for is in the Contact: string above (the nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn is replaced by a unique string). So, where in the instructions for the “knock” they show a sample string such as:

iptables -I door 1 -p udp --dport 5060 -m string --string "mysecretpass" --algo bm -m recent --set --name portisnowopen

I would change the --dport parameter to 5060:5061 (since an VoIP adapter sometimes uses port 5061 for the second service provider — for an device that allows up to fours service providers, use 5060:5063) and the --string parameter to “<urn:uuid:nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn>”, but using the actual string sent by the device, of course. I know the Sunshine Network people recommend using something other than port 5060 but I just can’t bring myself to go quite that far, and even their examples show 5060.

Some other SIP-compliant devices also send unique strings in their REGISTER packets. One that does NOT do so, as far as I am aware, is the venerable Linksys PAP2. And I also do not believe that any of the Sipura line of devices send such a unique string.

Naturally, if an intruder KNOWS you are using that technique, they could try a brute-force attack on the unique string. So I recommend only using this with “uncommon” extension numbers (not 200 or 1000, for example) and with a VERY strong secret/password on the SIP connection. But it is another line of defense against would-be intruders!

EDIT (Added October 24, 2012): The original article, and most of the original site for that matter, seems to have gone offline. While I’m not going to repost the original article here without permission, I will give you a few more details and a couple of excerpts. First, they advised that you change the SIP port to something other than 5060 – they suggested using something in the range 20001 through 49000, though I am not sure why. They uses port 34122 in their examples, and noted that if you are running PBX software that has a “SIP Settings” module, if your find a setting for “Bind Port”, that would be the one to change. Of course if you do this, you then have to change the SIP port on ALL your SIP-based phones and VoIP adapters.

With regard to the “knock” itself, they said this:

Technical information :
… Technically, our knock consists of a secret passphrase which is sent together with the first SIP packet from the phone to the server. SIP packets are text files, very much readable like http packets are. The SIP headers in a REGISTER invite packet have a lot of information, and one of those headers is called the “Display Name”. This display name is used only internally in your Asterisk server and has no other use, so we figured we could fill in anything and the Asterisk functionality would still work fine. We decided to use it as a port knock password.

How does it work :
The Asterisk administrator sets up a simple iptables rule. The iptables rule checks for a secret phrase inside packets sent to the SIP port ( 5060 by default, 34122 after having changed it ). Unless it finds this secret phrase, it will drop the packets to this port. All the remote phone has to do is fill in the “User Name” SIP property on his SIP phone with the secret phrase, and he will be able to connect.

What you then needed to do was to go to into your Asterisk server and from a Linux command prompt, issue the following command:

iptables -N door

Then for EACH “knock” string you want to use, you would do this from the command prompt (note this is only one line, and note that 34122 is the example port and “mykn0ckstr1ng” is an example “knock”):

iptables -I door 1 -p udp –dport 34122 -m string –string “mykn0ckstr1ng” –algo bm -m recent –set –name portisnowopen

If you have anyone that needs to register with your server but cannot send the “knock”, but is at a fixed IP address, you’d add a line like this for each instance (again the port and ip address would probably need to be changed, and note that an entire subnet can be specified as in this example — just leave off the /24 if it’s a single ip address):

iptables -A INPUT -p udp –dport 34122 –source 10.10.1.0/24 -j ACCEPT

Then you would enter these three lines, but again using the correct port rather than 34122. In the first line you see the number 4000 — that is amount of time in seconds that the port will be open, and should be greater than 3600 because that’s the default registration timeout for many sip phones and VoIP adapters. The original article notes that you could use 86400, which is a full day:

iptables -A INPUT -p udp –dport 34122 -m recent –rcheck –seconds 4000 –name portisnowopen -j ACCEPT
iptables -A INPUT -p udp –dport 34122 -j door
iptables -A INPUT -p udp –dport 34122 -j DROP

And finally, to make iptables use these rules, you’d enter:

service iptables save

The original Sunshine Networks article notes that…

This code keeps port 34122 closed ( DROP ) unless someone has opened the door ( door ) in which case they are allowed to pass the door for a little more than 1 hour ( 4000 seconds ). Each time the phone re-registers , the SIP secret pass header is sent, and the door is reopened for 4000 seconds. Since the default SIP reregistration time on many phones is 3600, the 4000 seconds will make sure that as long as the phone is connected to the SIP server, or needs to be connected, the dynamic firewall rule is always active.

Once you have done this, if you configure the Display Name or User Name setting with the “knock” string, it should be able to get through your firewall. Any phone that doesn’t have this string won’t. Of course you can always make the “knock” something that a phone already sends (in a SIP register packet), as noted in the previous edit, and then you don’t have to reconfigure the phone at all. If a phone or device tries to connect without sending the “knock”, the firewall won’t allow it (assuming you haven’t previously created some other rule that allows the traffic to pass) and the connection will fail, or at least that is how it’s supposed to work (I make no guarantees because I didn’t come up with this).

If you enter the command cat /proc/net/ipt_recent/portisnowopen you will get a list of IP addresses that have successfully used the “knock” to connect. Remember that after you implement this, it can take up to an hour for a device to attempt to reconnect.

If anyone ever spots the original article back online, please let me know and I’ll remove this edit. I’d rather you get the information direct from the original source anyway, and the short excerpts I have provided here don’t give the complete overview that the original article provided.

EDIT (February 23, 2014): It appears that there is an archived copy of that original article on the Wayback Machine, although we do not know if it is the most recent edit of that article prior to the site disappearing.