Auto Attendant Stopped Answering Trusted Callers - Suspect Firmware Update
MikeGJ:
I have a similar problem - AA is not working for trusted callers on my OBi200 right out of the box (used to work fine for my 110). I did have GV call screening checked earlier but I removed that before I set up the 200.
GV is on SP1 and X_InboundCallRoute shows {(x.720123456|nexttrustednumber):aa},{ph} - but my trusted caller numbers are NOT preceded by a 1 - they worked that way with my 110 trusted caller settings.
My 110 settings also had the same values in the InboundCallRoute for Physical Interface LINE Port settings - but when I tried to add that in my 200 settings, calls did not even ring the phone but went through to VM after a while - just like after your changes!
any ideas?
skyaut2:
Brand new out of the box with latest FW Obi200 did not recognize my trusted numbers that I entered in the OBitalk web interface. The AA did not answer incoming calls for trusted numbers until I applied the fix from above:
So for other Newbies, if the Auto Attendant does not answer GV calls, after adding Trusted Callers via the OBi Dashboard, change the X_InboundCallRoute value by entering the OBi Expert Configuration; unchecking the OBiTALK Settings and Device Default check boxes; and correcting the syntax for X_InboundCallRoute from something like {(x.12003004000|x.12003004001):aa},{ph} to {(+12003004000|+12003004001):aa},{ph}. Basically change "x." to "+".
Make sure the OBi device completes a reboot after changing X_InboundCallRoute. After making this change through the OBi Expert Configuration on a second OBi200 at a different location, the Auto Attendant still did not answer until I triggered a reboot by entering the OBi200 directly (e.g. 192.168.1.101) and clicking on "Reboot". (The "Config Current" check mark was shown after refreshing the browser page and before rebooting.)
I would add make sure you make the changes in the web OBitalk expert interface (red E in a gray circle next to the device or at the bottom of the device configuration page). The changes would not stick using the device interface.
egandb:
I can confirm this worked for my brand new 200. Thanks azrobert!!
Quote from: azrobert on May 19, 2018, 10:48:53 am
See:
http://www.obitalk.com/forum/index.php?topic=13885.0
Use OBi Expert and go to:
Voice Services -> SP? Service -> X_InboundCallRoute
The rule should look something like this:
{(+18005551212|+18005551313|+18005551414):aa},{ph}
aberson:
Thanks for this thread! It helped me!
My inboundcallroute suddenly stopped working a few months ago, and a few nights ago I discovered this thread which turned out to be the problem.
Unfortunately I had no default route to ph, all my routes were based on caller ID, so it seemed as if the GV integration had just stopped entirely with no explanation. Turns out the call logs don't show a call if it ends up having no destination to ring to, which is extremely frustrating.
Also frustrating - at one point I noticed the caller ID had + in it, so I tried adding that to my inboundcallroute and it didn't work. I also tried adding "x." before the area code, which as I understand is supposed to be a wildcard... and that didn't work either. I think these were both just cases of the device being in a flaky state and requiring a manual reboot before the new setting would truly kick in (even though the local web GUI showed the new setting had been pulled down from obiexpert)
In general it seems 3.2.2 has a few flaky/intermittent bugs, which makes it tough to troubleshoot.
Jeff47:
Hi,
I tried changing "x." to "+", and rebooted Obi200, but AA still didn't work for me. I emailed the support; they told me to try "@" instead of "+", but that didn't work for me either. Is there any new information on how to solve this problem? Will there be a new firmware update coming that could solve this problem?
thanks,
Navigation
[0] Message Index
[#] Next page
[*] Previous page