1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. Check out the 6 new Certified Incredible PBX Builds for Asterisk 11 and 13 featuring CentOS 6, Ubuntu 14, Raspberry Pi 2, and Asterisk-NOW.
    Dismiss Notice

GVoice In Flames No More

Discussion in 'Help' started by ghurty, Mar 21, 2011.

  1. fizadmin

    fizadmin Guru

    Fair enough - and I see your point. Then again, the issues with Digium and their generally lackluster support of Asterisk goes back a while, as I recall Ward's articles about Digium not really eating their own dog food (i.e. not running Asterisk company wide, for example).

    Though, to be perfectly honest, dissing Asterisk just because Digium sucks, is kinda throwing out the baby with the bathwater - if Digium is asleep at the wheel, couldn't others pick up that slack? I'm not familiar with FreeSwitch, though.

    Is that just another fork of Asterisk, or something completely separate? Asterisk is just the flavor/associated associated with Digium, right? Other forks exist?
  2. Folks, we need to keep in mind that Asterisk is Digium's child, and they can raise it as they see fit. We may not agree with what they do, but we need to keep in mind that Asterisk is first and foremost a way for Digium to make money. I don't think they've ever made any claim to the contrary. Digium is paying for the code their developers write and they have every right to set direction and priorities for their developers.

    I understand how frustrating it is for some feature of Asterisk (or FreePBX) to not work, and how it feels like blackmail for the developers to say "pony up some cash, and we'll raise the priority". But remember that for professional coders, fixing bugs and adding features is about paying bills - pride and craftsmanship must unfortunately take a back seat.

    Digium has graciously released Asterisk under the GPL. This means that if and when sufficient portion of the Asterisk community decides Digium is no longer taking Asterisk in the direction they want, they can fork a new version and take the new version in whatever direction they like. Or, they can look to something else to fill the void. This is the true beauty of open source.
  3. It's been a while since I've posted on this topic, in part because I've had little to say that wouldn't consist of more ranting about Digium pretty much abandoning their Google Voice support, and I know some of you disagree with my views on that, and in the end such rants accomplish nothing. But still, the problems have not gone away; if anything they have gotten worse. I know some of you have found that increasing the delay before answer, or playing a little bit of noise or maybe Allison saying "Hello" before sending the touch tone "1" helps sometimes, but I have not found any of those methods to work reliably, and anyway I hate the idea of making callers wait an extra 8-10 seconds before their call is connected through (and keep in mind, that gives you less time to answer before many will get frustrated and hang up. Gone are the days when people will wait a full six to ten rings for the called party to answer — nowadays if you don't answer in the first 20 seconds or so, a lot of people will give up, which is really frustrating to older guys like me, but that's a whole other rant!).

    So I decided to actually try and do something about it, and I found a solution that actually fixes the problem, but some of you will not like it, and a few (those on systems with limited resources) may simply be unable to implement it. It's actually been around since even before Asterisk introduced their Google Voice support, but you may not have wanted to try it back then. Today, with all the issues with the Google Voice channel driver in Asterisk (particularly for incoming calls), you may want to take another look. The procedure is detailed here:

    FreeSWITCH to add Google Voice to Asterisk

    The funny part is that even though I had suggested that such a thing might be possible (and Bill from the PSU VoIP blog then created the instructions shown), it was right about then that Asterisk's Google Voice support came along, and it worked well enough for the first six months or so, so I kind of put this idea on the back burner. But when it finally got to the point that I was terribly frustrated with the issues in Asterisk's GV drivers, I dusted off Bill's post and actually tried it. It works great as shown if you have a single Google Voice account, and if you have multiple Google Voice accounts you can read the comments under the article (which I suggest you do anyway) to see how we got those to work. The multiple account support still isn't perfect since it is Caller-ID based and therefore will fail on call-forwarded calls unless you take an extra precaution or two (NOT mentioned in the comments; I felt like I'd already been far too verbose by then) but for outgoing calls from extensions and incoming calls it works great.

    Now some observations:

    1) Calls seem at least as clear, if not clearer than when using Asterisk's channel drivers. YMMV, of course.

    2) Both outgoing and incoming calls complete MUCH faster - there is virtually no delay.

    3) After finishing this, I removed all the Asterisk configurations related to Google Voice (commented out everything in gtalk/jabber/jingle conf files) and strangely enough some weird issues I've been having with spontaneous restarts of Asterisk seem to have stopped. Can't say for sure it's related but it sure makes me go hmmmm....

    4) You PiaF guys (and probably everyone else) will want to block all outside traffic (coming from the Internet) on port 5050 (both UDP and TCP). I used Webmin to do this but the rules it generated (in /etc/sysconfig/iptables) are:

    -A INPUT -p tcp -m tcp ! -i lo --dport 5050 -j DROP
    -A INPUT -p udp -m udp ! -i lo --dport 5050 -j DROP

    5) As a byproduct this could conceivably simply configuration in PiaF because if you are not concerned with allowing call-forwarded calls (and other types of calls that originate from somewhere other than one of your extensions) to use your Google Voice trunks then you may be able to get by with only ONE outbound route and ONE FreeSWITCH trunk for all your users — the proper Google Voice account to use will be selected based on their outgoing Caller ID.

    6) Alternately, if you have multiple Google Voice accounts and need call-forwarded calls to work, the easiest way is to make sure that no outgoing calls go directly to your main FreeSWITCH trunk, but instead go to a CUSTOM trunk first. The CUSTOM trunks should be set up as follows:

    Trunk Name: I use "GV_User_Name" but you can use whatever you like.

    Outbound Caller ID: Put the same number here that's in the corresponding extension's Caller ID (the one used for calls outside the system), or use something else if you like but then be sure to change the FreeSWITCH configuration file to look for that Caller ID number. You only need a number here, not a name. Remember that Google Voice ignores what you put here (it ALWAYS sends the number associated with the account), so this is solely for account selection purposes in FreeSWITCH.

    CID Options: Use "Force Trunk CID" — this is the whole point of doing this — by setting this we force it to send the Caller ID entered in the previous field, thus FreeSWITCH won't see an "offsite" Caller ID in a forwarded call (note: I understand this might be broken in FreePBX 2.10; if so, there's not much you or I can do about it. If you haven't upgraded to 2.10 yet and want to try this, I suggest staying at 2.9 or below).

    Custom Dial String: SIP/FreeSWITCH/$OUTNUM$

    This assumes that your (non-custom) FreeSWITCH trunk is named FreeSWITCH - if you used some other name, use that here also.

    Don't change any other field from the defaults and don't use any Dialed Number Manipulation Rules. Make one such CUSTOM trunk for each of your Google Voice accounts, then create Outbound routes that select only the CUSTOM trunks, never the main FreeSWITCH trunk directly. That way, all calls hitting FreeSWITCH will come in with a Caller ID number that FreeSWITCH recognizes.

    (Note that I am simplifying things here a bit; if those who are technically minded want to expound on what is really taking place under the covers that's great, but I'm trying to keep things relatively simple here. And there may be a better/easier way to do this; I just haven't thought of any other way that wouldn't be more difficult).

    7) In the settings for the (real) trunk that connects to FreeSWITCH, you may want to add a statement like context=from-pstn-e164-us to use the built in context that strips +1 from the start of incoming US numbers.

    8) When you use the instructions on Bill's page, during the initial installation of FreeSWITCH there will be a few times when it looks like it's taking forever and is stuck in an endless loop. This is normal. Just go away and do something else. Since I installed this on a remote system, I actually set up screen ("yum install screen") so I could disconnect from the running process and reconnect later, without having a bunch of useless (to me) output sent over my ssh connection (use your favorite search engine to get info on how to use screen or go here, or you could always look at the man page if those actually make sense to you).

    9) If you have ever previously installed FreeSWITCH, be aware that this won't work right (especially with the mods suggested in the comments under Bill's article) if you don't go into the FreeSWITCH source directory and do "make current" (again, if you're doing this on a remote system and you have screen installed, you may want to invoke it before doing this).

    10) (EDIT) Turns out that even FreeSWITCH can have issues receiving incoming calls reliably. I believe that adding a short delay (one second or so) before answering the call may fix the issue (see my February 1 comment under the article), but I am not 100% certain of that.

    A big shout out and thank you to Bill for publishing this information many moons ago. I'm just sorry now that I didn't try this back when we started having all these issues. At this point, I honestly do not recommend that anyone use Asterisk's Google Voice channel drivers, but that is, of course, just my personal opinion.

    Ward, perhaps you should consider a "PiaF Chameleon" version that install all this automagically — I know that some people would not be able to use it due to CPU, memory, or storage constraints, but it sure seems to solve a lot of issues, at least in limited testing. And as a bonus, once you have this installed, you could also try installing Bill's Skype for Asterisk using FreeSWITCH, for hackers, if something like that floats your boat.

    Just a suggestion for those brave enough to attempt it! :D
  4. wardmundy

    wardmundy Nerd Uno

    See this post for the latest experiments with solving the failed inbound calls issue that some folks have.

    I personally never saw this problem with Proxmox, but it showed up immediately using our RentPBX PIAF2 test server. No idea why. :crazy:
  5. jeffmac

    jeffmac Guru

    I have been quietly following the Google Voice saga in these forums as they have continued for over a year. I have dabbled with the various implementations via Sipgate, etc. but never was trying to get serious use from my GV numbers until recently. By then I was using the Asterisk support in a PIAF This implementation has worked only "somewhat".

    My major problem has been that inbound calls are frequently only allowed to "ring" on my end for 12 seconds - often too short for someone to answer and never long enough for my answering machine (WAF - I don't use Google Voice voicemail, nor Asterisk's). After 12 seconds Google pulls the call back to their voicemail, EVEN THOUGH I CAN SEE IN THE LOG THAT ASTERISK "ANSWER'd" THE CALL! And what I've seen claims it will ring for 25 seconds - but that's not what I get...

    I have added an OBI110 and have shifted my active GV line over to it. Its too soon to pass judgement on that implementation. If its not the best I'm not worried because I wanted to replace a SPA3102 anyway, and the OBI is a much more capable device.

    But I have also followed Michigan Telephone with an implementation of Freeswitch in the "GV only" adjunct role on my new PIAF server. I intend to compare the results from OBI and Freeswitch with the previous Asterisk (gtalk) solution.

    As the use of GV continues to be a small portion of my usage it will take some time to compile meaningful results. If and when I have some results to share I will, of course, do so right here in the PIAF forums.

  6. wardmundy

    wardmundy Nerd Uno

    FWIW... I've never, ever seen this problem with an OBi device. If you need perfect, then $50 is a bargain.
  7. frederic

    frederic Guru

    While I'm a fairly new user here, I have to say Michigan Telephone's writeup about the obi100/110 "appliances" are outstanding.

    Following his guide (er, blog as he calls it) I got my two GV numbers up and running in about 15 minutes each.
  8. atsak

    atsak Guru

    Ward's right. I'm getting rid of all the system based GV install stuff and just using OBi's. Def. not worth the hassle for $50; they always work and if they don't the firmware update appears in a few hours.

Share This Page