News:

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

Main Menu

switched from OBi110 to 200 - autoattendant not working for trusted callers

Started by MikeGJ, June 02, 2018, 08:52:38 AM

Previous topic - Next topic

MikeGJ

Problem: OBi200 set up out of box doesnt direct trusted callers to autoattendant.

Bought a 200 a while back but was still using 110 with simonics until I started getting "service not configured" errors on outbound calls recently. Decided to set up the 200 - seemed to set up OK, status green and GV on SP1 connected - dashboard has kept both my trusted callers and my speeddial settings from my 110 setup. Set up 200 with my GV account not Simonics (disabled my GV under Simonics account to set up 200).
BUT when I dial in to my GV number from my cell (trusted caller #1) it goes straight through to ringing my house line.

Deleted both trusted callers and put them back - then checked settings under voice services (didnt think to check these untial after I deleted and reentered so I dont know what my settings were defaulted to when I set up the 200).
Thought adding trusted callers AUTOMATICALLY directed those number to autoattendant?

Expert settings for 200 setup shows SP1 X_InboundCallRoute  directing trusted callers to aa, entry is {(x.7201234567|x.secondnumber):aa},{ph} - this looks OK to me, but under physical interface Line Port inboundcallroute just shows ph - my 110 settings here show same rule as SP1 X_inboundcallroute.

Anyone have any ideas why this is happening? suggestions welcome.

thanks in advance

azrobert

Try:
{(@.7201234567|@.secondnumber):aa},{ph}

Edit:

See:
http://www.obitalk.com/forum/index.php?topic=13885.0

If you have a need for a 2nd line, you can use the OBi200 as a GV gateway for the OBi110.

MikeGJ

thanks for your response - I'd seen another post in day-to-day use regarding the autoattendant not picking up http://www.obitalk.com/forum/index.php?topic=13969.0
and they mentioned something about GV changing its callerID format - they suggested changing x.1 to +1 in the X_InboundCallRoute.
I tried your suggestion of changing x. to @. but all that did was stop my cell ringing the house line instead eventually going to VM.

BUT when I then reverted back to my OBiTalk settings with x.7201234567 and saving, miraculously the next time I tried the AA picked up! Absolutely no idea why - I had tried the other suggestions and reverted back before without success!

UPDATE - ugh. I did nothing else to my settings, just waited while I was typing this, then just tried calling in again  from my cell, trusted caller #1 (so SP1 X_InboundCallRoute value is back to x.number) and it rang the phone, AA not picking up!


azrobert

Use OBi Expert to configure the OBi200. If you use the local interface, OBiTalk will overlay your changes. You need to disable OBiTalk Auto Provisioning to use the local interface, but then you won't be able to make any changes from OBiTalk.

MikeGJ

thanks again - I am using the expert to make changes - I only use the local to see my call history. It seems I can repeat the AA picking up after reverting but only the first time. Second time I call in AA does not pick up but rings the phone!
So having value set as x.10digitnumber AA does not pick up but rings house line. I've tried setting value to x.1tendigitnumber with no success; oddly using @.tendigitnumber cause the house line not to ring but I hear it ringing on my cell, which then goes to VM.

As I understand it x means any digit 0-9, and @ means any alphanumeric character except #,
so @.7201234567 should match string ending in these ten digits? WHich should work, but then I dont see why 1) it doesnt, and 2) it causes the phone not to ring and instead go to VM.

I've tried twice now, and reverting to the obitalk settings (x.tendigitnumber) after making changes that didnt work has resulted in the next call being picked up by AA, but subsequent calls form the trusted number going straight through and ringing the house line.

If I could figure out how to embed an image I'd show you my call history (clicking on the insert image just puts this  code in the text - I dont know what to insert to load an image!) showing the times AA picks up.

azrobert

Try deleting all the Trusted Caller entries then add the rule using OBi Expert.

I create a file using Windows Snipping Tool then use the file as an attachment to a post.

MikeGJ

tried that - deleted trusted callers, SP1 X_inboundcallroute says ph (as expected); replaced that with {(@.7201234567|@.7207654321):aa},{ph}
and saved, then dialed from first number - call did not ring house line, was ringing on cell then went to VM.

Edited value changing @ back to x, saved and dialed again - went to AA!! But then same thing happened -try a second time from that number and it also didnt ring house line, ringing on cell then went to VM as well. 3rd and 4th tries also go to VM!! Tried x.1720etc and also goes to VM - will now not ring the house line. revert back to Obitalk settings - value goes to back to ph (since no trusted callers) and now calls from my cell go through and ring.

Cant figure out why AA picks up only sometimes and only after making changes, and why @. in the inbound rule should then send the call from  the number that matches the rule to VM instead!

drgeoff

Quote from: MikeGJ on June 02, 2018, 11:25:36 AM
If I could figure out how to embed an image I'd show you my call history (clicking on the insert image just puts this  code in the text - I dont know what to insert to load an image!) showing the times AA picks up.
Click the "Additional Options" immediately below the text entry box.  Click the "Choose file" button and navigate to the folder on your computer that contains the image file. Select the file and click OK or Open or whatever is appropriate for the OS your are using.

In Windows, you grab a screen image by pressing CTRL and Print Screen keys.  Paste that from the buffer into an image editing program.  Crop as required and then save into a folder for the steps in the above paragraph.

MikeGJ

thanks for pointing out the additional options - I'd only seen buttons above!
Here's a screen capture of my call history for today showing that the obi always recognizes my cell phone number as 1720xxxxxxx5 but doesnt always use AA1 to deal with calls from it. This has been while I've been playing around with the expert to try and get autoattendant consistently working.
Summary - calls are not routing to the AA with default trusted caller number stored as ten digit i.e. 720-xxx-xxxx; SP1 X_inboundcallroute shows {(x.720------5|x.720------4):aa},{ph}
calling in with cell (first trusted caller ending in 5) results in GV ringing house line
editing value replacing x. with @. stops ohone ringing and sends call to GV VM
resetting value to OBitalk settings (check box; values is as shown above) and saving SOMETIMES results in the NEXT call from cell going to AA; BUT subsequent calls either go straight through and ring or dont ring and go to VM.
Call history showing incoming calls going to AA are ONLY after trying something that didnt work and then resetting to OBitalk values.
I am completely flummoxed.

SteveInWA

Quote from: MikeGJ on June 02, 2018, 10:16:04 AM
thanks for your response - I'd seen another post in day-to-day use regarding the autoattendant not picking up http://www.obitalk.com/forum/index.php?topic=13969.0
and they mentioned something about GV changing its callerID format - they suggested changing x.1 to +1 in the X_InboundCallRoute.
I tried your suggestion of changing x. to @. but all that did was stop my cell ringing the house line instead eventually going to VM.


The referenced thread demonstrated that the solution is to enter +1yourgooglevoicenumber.  You instead are trying to use x or @.  Why?  Just follow the instructions.  Take out the x. and replace it with +1 and try again.

This begs the bigger question, why do you want to use the auto-attendant with Google Voice?  What is your goal?  If you want to call another number from a phone that is linked to your Google Voice account, using Google Voice as the service, you do not need to use trusted callers, or even an OBiTALK device, for that matter.  The feature is built into Google Voice, via its own IVR.

MikeGJ

I don't mean to be rude, but irrespective of why I want to do it, I'd like the autoattendant on my 200 to actually work (like it did on the OBi110) and it currently does not, on an OBI200 straight out of the box (current firmware). These issues may be confounded by the switch in GV format - which appears to have been unannounced. All I'm trying to do is get some insight into why.

Simply put, I've tried editing my inboundcallroute to use+1tendigitGVnumber and it fails. - when the rule has the specific case of +1GVnumber, calls from that number are silenced - OBi-attached phones do not ring - resulting in the call being sent to GV VM.

Currently the automatic input of the OBitalk default for my trusted numbers inserts
{(x.720nnnnnn5|x.720nnnnnn4):aa},{ph} for the SP1 X_inboundcallroute value (where n are single digits) which fails - calls from these two cells ring the GV number directly.

If this is the result of GV changing its format, then an updated firmware would be expected. Or at least some formal announcement that the current firmware will not work properly.

I've tried specifically editing to {(+1720nnnnnn5|+1720nnnnnn4):aa},{ph} and this also fails - but this time the call does not ring the phones attached to the Obi200  - although the cell phone hears the call ringing  - which then directs the call to VM.

This also happens using @.tendigitGVnumber - which as I understand the @ and . wildcards should match ANY number ending with AT LEAST 10 digits that match the GVnumber - which should cover all the bases.

Except that in both the specific (+1GVnumber) and generic (@.GVnumber) cases, these matches then PREVENT the OBi200 from ringing the OBi-attached phones, so calls never get picked up and finally then route to GV-VM.

This indicates that the problem is not solely due to the hypothesized GV format change.

We still have no explanation as to why the calls are not being directed to the AA1 when they should match, or why when they appear to be matched the result is to NOT ring the phone instead of being sent to AA1.
Again, this is with a 200 straight out of the box added to my obitalk account and no other edits by the end user to any values other than the SP1 X_inboundcallroute values. Presumably the Obitalk site initially inserted my trusted callers (in 10 digit format) into this field in my specific configuration during setup?

Still even more odd is the response after reverting to the obitalk default for the trusted number SP1
X_inboundcallroute {(x.720nnnnnn5|x.720nnnnnn4):aa},{ph}
sometimes but not always actually working and going to AA, other times, not ringing the phone and then going to VM (indicating it is matching the number but not piping the call to the AA but instead silencing the ring) with subsequent attempts actually ringing the phone - the latter of which indicates that the number sent by GV does not match the rule (which should be the case for GV sending +1 and the rule looking for x.).

Why calls from the same inbound number gets treated differently immediately after resetting to OBitalk default (or at any time) is also very odd.

drgeoff

Quote from: MikeGJ on June 03, 2018, 01:19:41 PM
If this is the result of GV changing its format, then an updated firmware would be expected. Or at least some formal announcement that the current firmware will not work properly.
No, GV changing the CallerID format does not require an updated firmware to make Trusted Callers work properly.

Have you tried entering your trusted callers' number on the portal using the GV +1 followed by 10 digits format and not attempting to override its automatic operation?  Ie do not manually change the X_InboundCallRoute.

Or manually configure the numbers (+1 followed by 10 digits or the @. way) in X_InboundCallRoute and delete them from the Trusted Callers list on the portal.

MikeGJ

solution - reset Obi200 and enter expert - trusted callers are inserted into SP1 X_inboundcallroute as before
{(x.720nnnnnn5|x.720nnnnnn4):aa},{ph}
reset all values to OBitalk settings - dont know why this worked or if it was necessary as all values except SP1 X_InboundCallRoute had check marks against obitalk settings
edit x. to +1 (note @. also works now) and voila calls go through to the attendant.

what I haven't figured out is what if anything was different that was making matched calls NOT ring the obi-phones instead of going to the aa. I'd like to know but as my wife says why? its working so go with it.

thanks to all who volunteered help. Guess this will need a firmware update for auto entry of trusted callers?

MikeGJ

drgeoff your last solution posted while i was writing mine. In response I had tried all those things  - deleting trusted callers and manually entering values; adding +1 to the trusted caller number fails because anything other than numerical characters entered including the + is stripped out while saving.
So I don't know how trusted callers are entered into the configuration by the web interface - guess that needs to be changed, if its not OBi firmware thats good!

Just happy now to have this working. FYI calling into OBI and out through gv uses (unlimited cell minutes and) home data and not cellular data if I was to do it through GV on my phone. Not sure how much difference this would make - prob not much but I've had my "system" set up like that for years and just wanted it to work the same!

drgeoff

Quote from: MikeGJ on June 03, 2018, 03:59:42 PMadding +1 to the trusted caller number fails because anything other than numerical characters entered including the + is stripped out while saving.
So I don't know how trusted callers are entered into the configuration by the web interface - guess that needs to be changed, if its not OBi firmware thats good!
I expect that stripping is done by the portal and the firmware on the device does not modify whatever it is sent to put in any of the configuration fields.

SteveInWA

I'm with your wife.  What difference does it make that it used to work and now it doesn't, aside from your curiosity.  The reason it doesn't work, is because Google changed the format of the caller ID string to add a +.

Aside from that, you said:

Quote
FYI calling into OBI and out through gv uses (unlimited cell minutes and) home data and not cellular data if I was to do it through GV on my phone.

There's no need to use the OB at all to accomplish that goal; that's why I asked you originally, why this was important.  The ability to make outbound calls that don't use mobile data is exactly what Google Voice does.

If you have an Android phone or iPhone, simply use the mobile Google Voice app to place calls.  The calls only use a tiny (kilobytes, not megabytes or gigabytes) amount of data initially, to determine call routing, and then the actual call uses your mobile voice (unlimited) minutes.

OR, if you have a non-smartphone (i.e. any US landline or mobile number), simply call your own Google Voice number from the linked phone number, access your voicemail menu (which is essentially GV's "auto-attendant"), and then press 2 to make an outbound call, using no data whatsoever.