Link: FreePBX: Inbound number not working help [might also be useful for other SIP-based PBX administrators]

 

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 may be of some help to those of you still using “that” software, that are having problems getting a new DID (inbound number) to work.  Note this tip might be equally useful for all Asterisk users, or even for administrators of other SIP-based PBX software.

FreePBX: Inbound number not working help (sysadminnet)

Related article

I no longer recommend using Asterisk’s Google Voice support — try these methods instead!

 

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 written in January of 2012, and has been heavily edited in an attempt to update it a bit.

Not that anyone probably cares what I think, but anyone who regularly reads this blog (or any of the other VoIP-related blog that cover Asterisk) may have noticed that prior to the release of Asterisk 11, Asterisk’s support for Google Voice had become less and less reliable over time, particularly for incoming calls. You have to do all sorts of “tricks” to make it work, and these usually involve adding delays that don’t always fix the problem, inconvenience your callers, and possibly cause more hangups as people get tired of waiting for you to answer the phone.

Therefore, I suggest that if you are using a version of Asterisk earlier than Asterisk 11, you stop using Asterisk’s Google Voice support completely. Assuming that you feel you must keep using an older version of Asterisk, I suggest trying one or more of the following:

  1. Use YATE as a gateway between Asterisk and Google Voice. See Using YATE to overcome Google Voice issues in FreeSWITCH and Asterisk, this article and this forum thread on YATE in a Flash, and this thread on YATE Tips & Tricks). YATE is what powers Bill Simon’s gateway (mentioned below). See comments by Bill and pianoquintet under this article.
  2. Use Bill Simon’s Google Voice-SIP gateway to handle your Google Voice calls. Some people may not want to rely on an external service for this, while others may very much appreciate having the option. I mention it for those in the latter group. For more information see Bill Simon’s Free SIP-to-XMPP Gateway Easily Puts Google Voice on Your VoIP Phone (Voxilla). While the linked articles talk about using the gateway with a SIP device, it can be used as an Asterisk trunk.  EDIT: As of April 7, 2015 the Google Voice Gateway has been relaunched and there is now a one-time fee to sign up.
  3. If your only issue is with incoming calls, you could use a DID to bring the calls into your system.  But keep in mind that Google Voice does not like it when calls are answered the moment they connect, so in your FreePBX Inbound Route be sure to set the “Pause Before Answer” option to at least 1.  I have found that a 1 second pause is sufficient, but I’m not saying that is the correct value for everyone, or even that everyone will need to include such a pause (some DID providers may delay the call sufficiently before connecting through to your system that the pause isn’t needed).

At this point, any of those would likely produce better results than using the Google Voice support in any version of Asterisk prior to Asterisk 11.

EVERYTHING in this article is my personal opinion.  Nothing here should be taken as a statement of fact.

EDIT:  Ward Mundy reports that he just may have found a workaround for the incoming calls issue — see this thread in the PBX in a Flash forum.

FreePBX voicemail hacks

 

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 January, 2011 and may contain outdated information.

Motel Phone
Image by Andreas_MB via Flickr

A few things you should know about FreePBX voicemail:

• If you are not receiving voicemail notifications (stutter dial tone, message waiting indication on certain phones, etc.) there are two things to check.  One is to go into /etc/asterisk/vm_general.inc and see if there is a line of the form ;pollmailboxes=yes — if it is commented out (semicolon in front), uncomment it by removing the semicolon.  The other is to go to the /var/spool/asterisk/voicemail directory and make sure that you have directories there called default and device, and that one is symlinked to the other (generally default is the “real” directory and device is the symlink). If the device directory is missing, make sure you’re in the voicemail directory and do this:  ln -s default device

• If you have users in different time zones, you can have the voicemail “envelope” information say the correct time by creating a [zonemessages] context at the end of /etc/asterisk/vm_general.inc (in later versions of FreePBX you can also enter these in the Timezone Definitions section of the Voicemail Admin module) — here’s a simple one showing the four major time zones in the continental United States (I know this is not complete, it’s just an example):

[zonemessages] eastern=America/New_York|'vm-received' Q 'digits/at' IMp
central=America/Chicago|'vm-received' Q 'digits/at' IMp
mountain=America/Denver|'vm-received' Q 'digits/at' IMp
pacific=America/Los_Angeles|'vm-received' Q 'digits/at' IMp

Then, on each extension setup page in FreePBX, find the Voicemail & Directory section, and under that the VM Options.  In the VM Options add a tz= option for each user (for example, tz=eastern), using one of the zones you defined under [zonemessages] in /etc/asterisk/vm_general.inc.  Note that multiple options in VM Options must be separated by the | (vertical bar) character (not that you’re likely to have multiple options, but I mention it just in case).

• If your system is not used in a large office, or some other location where not all users can be trusted, you can disable the requirement to enter a PIN when using *97 to pickup voicemail for your own extension.  To do that, add the following context to /etc/asterisk/extensions_custom.conf:

NOTE: This is the original code for older versions of FreePBX:

[custom-voicemail-retrieve] exten => s,1,Answer
exten => s,n,Wait(1)
exten => s,n,Macro(user-callerid,)
exten => s,n,Macro(get-vmcontext,${CALLERID(num)})
exten => s,n,VoiceMailMain(${CALLERID(num)}@${VMCONTEXT},s)
exten => s,n,Macro(hangupcall,)
exten => h,1,Macro(hangupcall,)

In newer versions of FreePBX (probably 2.9 and later) use this instead:

[custom-voicemail-retrieve] exten => s,1,Answer
exten => s,n,Wait(1)
exten => s,n,Macro(user-callerid,)
exten => s,n,Macro(get-vmcontext,${AMPUSER})
exten => s,n(check),Set(VMBOXEXISTSSTATUS=${IF(${MAILBOX_EXISTS(${AMPUSER}@${VMCONTEXT})}?SUCCESS:FAILED)})
exten => s,n,GotoIf($["${VMBOXEXISTSSTATUS}" = "SUCCESS"]?mbexist)
exten => s,n,VoiceMailMain()
exten => s,n,GotoIf($["${IVR_RETVM}" = "RETURN" & "${IVR_CONTEXT}" != ""]?playret)
exten => s,n,Macro(hangupcall,)
exten => s,check+101(mbexist),VoiceMailMain(${AMPUSER}@${VMCONTEXT},s)
exten => s,n,GotoIf($["${IVR_RETVM}" = "RETURN" & "${IVR_CONTEXT}" != ""]?playret)
exten => s,n,Macro(hangupcall,)
exten => s,n(playret),Playback(beep&you-will-be-transfered-menu&silence/1)
exten => s,n,Goto(${IVR_CONTEXT},return,1)
exten => h,1,Macro(hangupcall,)

Then do the following in FreePBX’s GUI (do these steps in the order shown):

Go to Feature Codes and under Voicemail, disable “My Voicemail” (*97) using the dropdown, then Submit Changes.

Go to Custom Destinations (under the Tools tab) and create a new Custom Destination:  custom-voicemail-retrieve,s,1 — then Submit Changes.

Go to Misc. Applications and add a new Misc. Application. Make the feature code *97 and the destination the Custom Destination you created in the previous step, then Submit Changes.

Finally do an “orange bar reload” in FreePBX. Now when your users dial *97, it will assume they are authorized to pick up the voicemail for the extension they’re calling from. Obviously, this is probably not a good idea in any kind of office setting.

Got any other FreePBX voicemail hacks you like?

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.

Link: Using FreeSWITCH to add Google Voice to Asterisk

 

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 (2018): This article is extremely out-of-date and in no way useful today, and will probably be removed from this site at some point in the future. You might find this article more useful: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware.

For those of you using Asterisk, Bill over at the PSU VoIP blog has come up with a way to interface Asterisk with Google Voice, by co-installing FreeSWITCH (which also supports Google Voice).  Turns out that Asterisk and FreeSWITCH can co-exist on the same server, though you do have to change the configuration a bit so they don’t compete for the same ports.  Anyway, Bill has come up with a how-to on adding Google Voice integration to current versions of Asterisk, so if that interests you, head on over and have a look:

Using FreeSWITCH to add Google Voice to Asterisk

The bonus is that once you get FreeSWITCH installed you can play around with it and look at some of its other features, if you are so inclined. Of course, the Asterisk folks could backport the Google Voice support to previous versions and make it unnecessary to do things like this, but I’m not holding my breath.

EDIT (January 26, 2012): The Google Voice channel drivers in Asterisk 1.8 have become unreliable enough (in my personal opinion, anyway) that I just used the technique shown in this article, and I must say that it works a LOT better than Asterisk 1.8’s Google Voice support.  I also added some comments to that article (probably too many!) that among other things show how I got it working for multiple Google Voice accounts.  So I would now recommend using this method to bridge Asterisk to Google Voice in preference to using Asterisk 1.8’s native channel drivers (unless you are very short on memory and/or storage space) — it just works, and calls connect faster.  Read the article AND the comments under it first, so you’ll know what to expect, and do be aware that it takes a relatively LONG time to compile and install FreeSWITCH (compared to Asterisk).  At points during the installation it may look like it’s stuck in an endless loop, but it really isn’t. Just go away and take a walk outside or something, and come back in a while and it should be done.

Review of Ring Voltage Booster II™ from Mike Sandman Enterprises

 

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. In order to comply with Federal Trade Commission regulations, I am disclosing that he received a free product sample of the item under review prior to writing the review.

This article was originally published in April, 2008.

Once in a while you run into a situation where someone wants to put a whole bunch of phones on one physical phone pair. This can often happen in a home with many rooms, where every room has been prewired with a phone jack. You start out with a phone in the kitchen or living room, then you want one in the master bedroom, then each of the kids wants one, then you want one in the workshop down in the basement, and so on. Okay, so granted that the above example would probably have been more appropriate 20 years ago (before all the family members started wanting their own cell phones) but you can still run into such situations, both in homes and in small businesses that only have one or two phone lines and a bunch of phones hanging off each line.

In the old days the phone company let you have enough current to ring five standard telephone ringers – 5 REN in telco-speak – and that was five of the old mechanical style ringers with real bells. But nowadays people have started replacing their old wireline lines with newer stuff, like VoIP, and VoIP adapters can be notoriously stingy with ring current. Sometimes when people convert to VoIP, they find that they either have to disconnect some phones (or at least, shut off or disconnect the ringers in those phones) or figure out a way to boost the ring current.

Yet another problem with both certain makes of VoIP adapters, and even with some low-cost telephone switches sold to businesses, is that they don’t produce enough ringing voltage or current to begin with. That might be particularly true if the adapter or switch was designed to standards other than those typically used in the U.S.A. and Canada. In those two countries, phones and phone equipment have always been designed to expect ringing current at approximately 90 volts AC at 20 Hertz (cycles per second), but in some other countries both the ringing voltage and frequency can be quite different, causing equipment designed for the North American standard to not ring properly. Even with a VoIP adapter set to the correct voltage and frequency (not all are; it’s left to the provider to set those parameters on some devices), most VoIP adapters are only rated at 3 REN or less.

Ring Voltage Booster II™

Recently I discovered that Mike Sandman Enterprises has started offering their Ring Voltage Booster II™ – this is the successor to the original Ring Voltage Booster™ that Mike has been selling for several years now, and it looked to me as though it would be just the thing to cure those ringing problems. The Ring Voltage Booster II is used in series with a telephone wire pair entering the premises (or coming out of a VoiP adapter or similar device), and it senses ringing voltage on the line and increases it (actually regenerates it) to the North American standard 90VAC RMS at 20 cycles, and increases ringing current to 7.5 REN.

I wanted to obtain a unit and try it out. I did just that and I thought I’d share the results of my test with you folks, because I was very favorably impressed with the unit. If all you want to know is whether it works as advertised, I would say that based on my experience the answer is an unqualified yes (with one very minor caveat, which I will mention in a moment).

The way I tested it was this. I had a Sipura SPA-2000 VoIP adapter which was connected to the existing phone wiring in a home where the wireline service has recently been disconnected. There was already quite a collection of phone equipment on the line, and I hung a couple of extra items on to load it down. When we got through adding phones we had the following on the line: two modern phones with warble-type ringers, three old 2500-series touch-tone wall phones with real mechanical ringers, one old 2500-series desk set with a real mechanical ringer, and just for fun, one old Western Electric 302 desk set with original ringer and ringing capacitor.

I want everyone reading to pause for a moment and consider that, apart from the fact that this 1940’s-era phone has a rotary dial rather than a touch tone pad, it works great today with the original ringer and capacitor. I’ve had several computer power supplies fail on me in recent years, usually within a year or two of purchase, due to bad capacitors (in a couple cases, exploding capacitors!). For all the bad things about the old Bell System, they sure knew how to build a telephone that would survive just about anything, except the elimination of switching equipment that accepts rotary dial pulses.

Anyway, I had the aforementioned relatively huge load (well above 3 REN, no matter how you count it) hooked up to the Sipura SPA-2000, and I placed a call to it.

And darned if the phones didn’t ring!

I stood there open-mouthed for a moment. Granted the ringing was a bit weak, but all the phones were ringing. I really hadn’t expected that. I could tell I was putting a significant load on the SPA-2000, but not enough to make a very noticeable difference in the quality of ringing. Then it dawned on me – I remember reading somewhere that early Sipura adapters were conservatively rated, but such was not necessarily the case with their successor, the PAP-2 from Linksys. Well, I have one of those, too.

So I disconnected the SPA-2000 and hooked up the newer PAP-2, and placed a call to the PAP-2, and did that make a difference! With the same load as described above, the phones were still ringing, but they were really struggling. The W.E. 302 and one of the new warblers were having the most trouble, both giving only partial rings. The others were ringing very anemically.

I then inserted the Ring Voltage Booster II™ and placed several test calls. The ringing was clear and strong, in fact, each phone rang as if it were the only phone on the line, and the ringing seemed loud and crisp on all phones. Granted this is a bit of a subjective observation since I was, after all, listening to mechanical telephone bells ring, but I grew up with those and I know what they sound like when they are ringing as they should, and these were.

There were two other things I wanted to observe. One was whether the unit interfered in any way with Caller ID. Only one of the phones in this test had a Caller ID display, but it got the correct Caller ID information every time. The other thing was whether it would have any problem with a distinctive ringing signal, and again, I can report that it did not. I happen to have that adapter programmed so that when a particular friend calls it rings with a distinctive ring, since this particular friend seems to have a peculiar form of psychic ability – he always seems to call when I am indisposed (usually in the bathroom or some such thing). So if it rings with his ring, I know I can wait until I’m through with whatever I’m doing, then call him back and share a laugh over yet another occurrence of his weird form of E.S.P. So, in order to test distinctive ringing, I called him and asked him to call me back and let it ring, and once the ringing commenced I checked several phones and all were ringing with the correct distinctive ring cadence (two approximately one-half second rings followed by a one second ring, or at least that’s what it sounds like). Also, I could hear a relay inside the Ring Voltage Booster II™ clicking on and off in time with the distinctive ring patterns.

In fact, the unit worked perfectly, save for one very minor nit: Sometimes, if I picked up a phone during a ring, it would continue to apply ringing voltage for the duration of that ring – in other words, it didn’t seem to always sense that the phone had been picked up and stop the ringing until that ring had ended. In all fairness, I’ve seen this happen before with other types of equipment, including real phone switches (particularly on long loops in rural areas, etc.). What this means is that if you pick up the phone at the very start of a ring and press it to your ear immediately, you could get a pretty loud buzz in the ear for a second or so. I don’t think this will be a major issue for most users, particularly since the unit solves a much greater problem (phones not ringing at all, or ringing very weakly). But for a few people, it might be an annoyance (Edit: One way to reduce this would be to always use a ring pattern that has rings that are one second long or less.  Some VoIP providers will let you set a “distinctive ringing” pattern for each line or each incoming number – if you pick one that has a two or more short rings instead of a single long one, you greatly reduce your chance of hearing the loud buzz when you pick up the phone.  Now that I think of that, I’ll bet that explains why many independent telephone companies used one-second long rings, instead of the two-second rings common in the Bell System).  I don’t know if this was an issue with just the unit I was using, or with all of the units of this model, but it was the only thing I noticed about the unit that wasn’t “perfect” – in every other way, it delivered all you’d expect from such a device.

There are a couple of other pleasant surprises about this unit. Neither the unit itself nor its power supply seem to generate excessive heat in normal standby mode (I did not test an extended ringing cycle lasting several minutes or more, because that would have required shutting off voicemail) – in fact the small “wall wart” was very cool to the touch a couple hours after being plugged in. That’s more than I can say about many of the “wall wart” power supplies i normally use, and as you know, heat is wasted energy, so I’m very happy that Mike is including what appears to be a quality power supply. But what really shocked me was the small size of the unit. Perhaps it’s because I’m an “olde pharte” that equates a ringing generator with, at the very least, a large steel box hanging on the wall in a basement or phone closet, but this thing blew me away because it’s even smaller than any of my VoIP adapters! The longest dimension on it is only about three and a half inches. You’re almost certainly not going to have any problem finding a place to put it.

Hookup couldn’t be simpler, but you must observe that you get the connections right to avoid damaging the unit – in other words, don’t connect the side that’s supposed to be connected to the phones to the incoming phone line, or you will damage the unit. There are only three connections, one for power, one for the incoming line (labeled “line in” – this is the side you’d connect to a VoIP adapter), and one to go to the phones. If you are connecting it to a VoIP adapter you can probably do it in under a minute, once you have it out of the packaging.

In summary, if for any reason you don’t have enough ringing voltage or current on your phone line (or coming out of a VoIP adapter) and you need to boost it, this is the unit that will do it, at least up to 7.5 REN. And if you have a ridiculous number of phones on one line, remember that you can connect some of them before the Ring Voltage Booster II™ (using the original ringing voltage and current from the line or adapter) and the rest after (using the regenerated ringing current from the Ring Voltage Booster II™).

One caveat, this unit does not increase the gain (circuit loss), talk battery, or loop current of a line – if you need to boost loop current then Mike sells a separate Loop Current Booster™ that will do that. But the Ring Voltage Booster II™ basically gets out of the way when the phone isn’t ringing, and should not have any effect whatsoever on transmit or receive volume levels.

Mike Sandman has been selling quality phone equipment for many years now, so I expected this to be a quality unit. Even so, I was very favorably impressed with it. If you have problems related to low ringing voltage or current, get this device. If you have problems related to wrong-frequency ringing current (something that’s putting out ringing current at a frequency other than 20 Hertz), I’m pretty sure this will solve that problem as well, though I did not test that personally. Here is one more link to the page that describes this unit (and some others) and please note this is a plain-vanilla link – I’m not making any commission or anything if you buy one. I hope this review helps someone that’s having a problem getting their phones to ring!

Disclosure:  I have not been and will not be paid anything for writing this article, and I do not receive any commission or other compensation from sales of this item, and the links in this article are not affiliate links.  I did, however, request and receive a complementary Ring Voltage Booster II™ for review purposes (which I was allowed to keep after writing the review, and for that I am most grateful).