News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Obi/GV to call Toll-Free (888)?

Started by jclark5093, June 11, 2011, 06:16:08 PM

Previous topic - Next topic

jclark5093

I am having trouble dialing out toll-free numbers.

The most recent was 888-298-9274 (ADT Home Security). Is this something I should be able to do (call 800/888 numbers)?

Thanks in advance!

SteveInWA

Specifically, what do you mean by "having trouble"?

If you mean that you dial the number, and it rings and rings with no answer, I have been experiencing intermittent problems calling various toll and toll-free long distance numbers via GV for the past few days.

I just now tried your ADT number on my OBi.  I have GV provisioned on SP1 and Callcentric on SP2.  The call rang and rang with no answer when dialed with GV, but was promptly answered when dialing with Callcentric.

It's a Google problem, not an OBi problem: 


  • it should work, and it used to work for me, as recently as with the current OBi firmware level
  • I just now tried calling the ADT number using the GMail "call phone" web interface, and the call just rings, too.


MichiganTelephone

#2
Here's how you can bypass Google Voice on toll free calls, providing that you have a sip account set up for Service Provider 2 or at least can configure it as a "fake" sip account (these calls will NOT go out via SP2):

Under Voice Services, Gateways and Trunk Groups, pick an unused Voice Gateway - I used Voice Gateway 1 (remember to use the OBiTALK portal's expert configuration mode to make these changes if you allow the portal to configure your device).

Change only the Name (optional - whatever you want it to say) and then change the AccessNumber to:

sp2(tf.callwithus.com)

(You can use any toll free provider that accepts anonymous incoming calls; there are several and I don't have any specific recommendations).

EDIT: Optional: put your 10 digit Caller ID number (just digits, no punctuation or spaces) in the AuthUserID field if you want to try sending accurate caller ID on outgoing calls.  Many toll-free providers will just ignore it but occasionally you may find one that actually passes it.  See my next post below for more information.

Assuming you use sp2() as shown above then as I said, Service Provider 2 must be set up as a sip account, though I don't think it actually has to be an active connection - if you want you can just point it to any free service where you can get a SIP account if you don't already have one, or maybe even just put in some dummy credentials and point it to an unused address on your own local network (example, 192.168.0.250)?

Next, under Physical Interfaces, Phone Port change the OutboundCallRoute and ADD the following string to the existing rules, probably right after the existing {(<#:>|911):Mpli}, string:

{(1800xxxxxxx|1888xxxxxxx|1877xxxxxxx|1866xxxxxxx|1855xxxxxxx|1844xxxxxxx):vg1},

Make sure that once the string is pasted in there is a single comma separator at the start and end of the above rule. The vg1 near the end points to Voice Gateway 1; change it if you used a different Voice Gateway.

This will route all your toll free calls out via whatever provider you have specified in VG1.

Besides tf.callwithus.com here are a few others I know of - again, no recommendations, just a list:

proxy.ideasip.com
sip.tollfreegateway.com
tollfreetollfree.com

(there's also tollfree.future-nine.com but they require that you prepend ** to the 1-8NN number, which means the Voice Gateway DigitMap would have to be changed just for them.  Plenty of other services for now).

In theory you could configure multiple Voice Gateways with different toll-free providers and then assign them to a Trunk Group, so that if one is failing it would roll over to another, but I have not attempted to do that thus far.

Bypassing Google Voice for Toll Free may result in a faster connection (GV typically sends you about 6-10 seconds of fake ring tone before the called number even starts to ring, whereas when using one of these services you'll probably hear actual ring tone (or busy signal or whatever) from the number called).
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

RonR

There's something strange about 888-298-9274 (ADT Home Security).  It fails to connect through Google Voice here also, regardless of how Google Voice is accesed (OBi, Sip Sorcery, GV web site).

What's strange is:

1. Calling it through tf.callwithus.com via Sip Sorcery works.

2. Calling it through tf.callwithus.com via OBi PHONE Port works.

3. Calling it through tf.callwithus.com via OBi InboundCallRoute fails.

4. Calling it through sip.ideasip.com via OBi InboundCallRoute works.

MichiganTelephone

#4
Well, this may or may not be part of the problem...

There are some companies (usually cheap-@## companies) that buy "restricted" toll-free service.  The idea is that if you only have customers in certain states, then you only accept calls if the caller ID (or, in some cases, the ANI, which can be different from the Caller ID) matches a number in "your area." If it comes from an area code that's not considered to be in your area, the carrier drops the call before it ever reaches the company.  The idea is that by doing that, the company saves a few bucks a month on wrong numbers, sales calls, and other traffic they don't want to pay for.

This was a great idea back in the 1980's.

Today, of course, there are two issues.  First, a customer may have a phone number that bears no relation to their actual geographic location.  But second, if you are using anything other than a traditional landline phone company, there is a very good chance that your true Caller ID or ANI will not be sent.  That's particularly true when you are not providing it to the carrier in the first place.

One way you can tell what number is being sent is to call MCI at 1-800-444-4444.  In the first few seconds they will read back the number they think you are calling from.  When I call from a Google Voice number in Michigan, using Google Voice, it accurately reads back my Google Voice number.  But that may not be the case for calls from all areas of the country. If I am using tf.callwithus.com it reads back 567-255-9999, a Mansfield Ohio number.  So if some company accepted calls from Michigan area codes but not from Ohio area codes, the call would go through (for me) when using Google Voice, but not when using callwithus.

(Another test: Call TellMe at 1-800-555-8355, say "Weather", and after the short ad plays see if it offers to read the weather for your city, or some other city in another part of the country, after it prompts for your city and state or zip code.  If it actually says the city and state associated with your phone number, then it's probably getting an accurate number.)

To make things even more confusing, if you actually supply a number during call setup, some toll-free providers will use it while others (most of them) will not. I think the number of toll-free carriers that will pass caller ID is dwindling because of new anti-spoofing laws (apparently passing a totally bogus Caller ID is not considered spoofing, but they don't want people pretending to be calling from the White House or something).  If using a Voice Gateway on an OBi device you can try putting your desired 10 digit Caller ID number in the AuthUserID field and see if it will pass through, but unless you are actually authenticating with a provider in some way I doubt they will pass it (tf.callwithus.com appears to be an exception in that, at least as I write this, they will pass a 10 digit caller ID placed in the AuthUserID field - if you try that make sure to use numbers only, with no punctuation or spaces).

So, to make a long story short, sometimes the trick is to use a toll-free provider that sends a number that the company you are trying to call will accept calls from.  Of course you could call up the company and try reminding them that we are not in the 1980's anymore, and suggest it might be time to stop limiting incoming calls based on area code (assuming you know for a fact that they do that, and chances are they're not going to admit it). Or for home alarm service you could switch to a company that actually knows that some of their customers have broadband Internet and VoIP (I've heard some good reports about NextAlarm, but have never used them personally).

By the way, a simple explanation of the difference between Caller ID and ANI is that Caller ID is supposed to be the CALLING number, while ANI is the BILLING number.  They are not always the same.  For example, many companies send the Caller ID of the main switchboard, or some other number they want people to use when returning the call, but will send an ANI reflecting the actual extension the call came from, so when they get the phone bill they can break down the calls by individual extensions.  For residential landline users, Caller ID and ANI are nearly always the same.  BOTH are transmitted during the setup of a toll-free call, but as noted above there are many cases where one or both may not accurately reflect the actual caller.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

AndyJ

#5
Quote from: MichiganTelephone on June 11, 2011, 08:49:38 PM
Next, under Physical Interfaces, Phone Port change the OutboundCallRoute and ADD the following string to the existing rules, probably right after the existing {(<#:>|911):Mpli}, string:

{(1800xxxxxxx|1888xxxxxxx|1877xxxxxxx|1866xxxxxxx|1855xxxxxxx|1844xxxxxxx):vg1},

Make sure that once the string is pasted in there is a single comma separator at the start and end of the above rule. The vg1 near the end points to Voice Gateway 1; change it if you used a different Voice Gateway.
You can define the digit map in the DigitMap field of the voice gateway itself, which seems a little "cleaner" to me. It can also be shortened to:

(18(00|88|77|66|55|44)xxxxxxx)

The leading 1 could be made optional if desided:

(18(00|88|77|66|55|44)xxxxxxx|<1>8(00|88|77|66|55|44)xxxxxxx)

Then, in the OutboundCallRoute, reference the digit map:

{(Mvg1):vg1}

I routinely use tollfreetollfree.com for my toll free calls, and it's been pretty reliable.

jclark5093

@SteveInWA thanks, so *hopefully* it clears up soon...

As far as setting up the rest of this, I'm trying to set up my PBXes account which has multiple lines on it, not sure if that will use up SP2 or not (hopefully not, because I would like for my kids to be able to dial 911 from these phones via callcentric or something like that)

Thanks for all the tips

@MichiganTelephone Thank you for the information - you have helped me along this learning process quite a bit! (Your blog has been quite useful - I love learning about new things :-) )

MichiganTelephone

AndyJ,

Thanks for that suggestion - it makes a lot more sense.  So to recap, here's how you'd fill in the Voice Gateway fields:

Name: Optional - whatever you want it to say
AccessNumber: sp2(tf.callwithus.com)    — assumes sp2 set up with a SIP account.  You can substitute a different provider.
DigitMap: (18(00|88|77|66|55|44)xxxxxxx|<1>8(00|88|77|66|55|44)xxxxxxx)
AuthUserID: Optional - a 10 digit number (no spaces or punctuation) that you'd like to send as Caller ID.  Won't work with all providers.
(Leave AuthPassword set to the Default setting)

Then, as AndyJ suggested, in the OutboundCallRoute, reference the digit map (insert it early enough in the map that some other rule doesn't pick off your toll-free calls, and make sure there's a comma separator on both sides of the rule):

{(Mvg1):vg1}

Note that if your dial plan allows seven digit dialing of local calls then you won't be able to do ten digit dialing of toll-free calls unless you are a VERY quick dialer, because the first seven digits will be treated as a local number after a delay of a second or so.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

SteveInWA

Since GV does appear to be sending the correct calling party number (I tested this with both the MCI test number and with another read-back service), perhaps its service provider or call-routing software is doing something else to mess up the call to certain numbers (ADT being only one example I've encountered).

Many businesses using TFNs make use of ANI for various legitimate functions (e.g., geographic/regional call center routing or load balancing, or to do a data base lookup and display account info about you to the person answering the call, or as one piece of authentication in some multi-factor authentication scheme).

Trying to use one of the 1-8nn toll free calling gateway providers might work with some numbers and not others, for some of the ANI-handling reasons discussed above.  IMO, it just introduces more complexity and confusion when troubleshooting, and is probably not worth the hassle, given the variety of new issues it may introduce.  The issue of whether the ANI is sent or not sent, and if sent, is it your number, some invalid characters, null, or some number belonging to the 8nn middleman, can make things worse, unless you are willing to spend a lot of time experimenting.

As for ADT, actually, I use their 1-888-238-7374 number, which works fine with GV.  IF no luck with a TFN, given free or next-to-free long distance calling, It's probably easier to find out the non toll-free number for the party you are calling, and use that instead. 

Extra-credit reading:  one example of valid ANI being put to good use is by my local electric/gas utility.  When there is an outage, they get swamped with calls asking the same questions (did you know my power is out, when will it be restored, etc).  So, their interactive phone system uses the 1-800 ANI to look up the caller's phone number and thus, their address in their records, (and asks if this is, indeed, you), then looks up any known outages, and only if no outages have been reported (yet), routes the caller to an agent.  Otherwise, if the outage is known, the automated system tells the caller what's known about it, including estimated time to restore, and offers to call back the caller with updates.

kevin889

Can you tell us what kind of problems you are facing while dialling these numbers?
________________
Custom Toll Free

martinchris

Have you tried Skype or Google voice for calling on these numbers? If not, than you should try these services, I am sure, it will solve your problem.