News:

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

Main Menu

Auto Attendant Stopped Answering Trusted Callers - Suspect Firmware Update

Started by AnnaYaro, May 19, 2018, 09:53:57 AM

Previous topic - Next topic

AnnaYaro

Auto Attendant was working fine on my Obi200 until I tried to use it on 5/18/18. Now I cannot get the Auto Attendant to pick up the line when called by a Trusted Caller. I tried adjusting a few parameters, deleting/adding device, factory reset.

Any suggestions?

Obi System Status is showing "SoftwareVersion 3.2.2 (Build: 5859EX)". Is this related to a recent firmware update?

azrobert

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}

AnnaYaro

azrobert,

Thanks for your help. Your suggestion fixed my problem.

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.)

Pestman

Does this look right?

{(+290045450|+552114026)>(xx.):SP1},{(+290045450|+552114026):aa},{ph}

It didn't seem to work for me.

AnnaYaro

It doesn't look right to me. I'm not an expert, but I believe all the characters, except the phone numbers should be exactly the same as my example. But I have a simple setup. I am only using the SP1 voice service with Google Voice (GV). Additional voice services might complicate matters. Try a single phone number with this syntax {(+12223334000):aa},{ph}

These are the steps I followed to get two different OBi200's (version 3.2.2 (Build: 5859EX)) working:

1. Set the Trusted Callers using the OBiTALK Dashboard at https://www.obitalk.com/obinet
2. Enter the OBi Expert Configuration and confirm the OBiTALK Dashboard X_InboundCallRoute value includes the phone number(s) entered in step 1
3. Uncheck the OBiTalk and Default checkbox for X_InboundCallRoute
4. Change "x." to "+" in the X_InboundCallRoute value
5. Save the changes and exit the OBi Expert Configuration
6. Reboot the OBi200. (I did this by navigating to the OBi200 IP address and entering username "admin" and password "admin" and then clicking "Reboot".)

drgeoff

Quote from: Pestman on May 20, 2018, 03:34:33 PM
Does this look right?

{(+290045450|+552114026)>(xx.):SP1},{(+290045450|+552114026):aa},{ph}

It didn't seem to work for me.
No that does not look right.

The 290..... and 553.... numbers have only 9 digits so cannot be GV numbers.  It is only GV that is prepending +1 to the CallerID.

Ankur

I followed the instruction but AA is still not working after reboot via web portal ???
NNNNNNNNNN and MMMMMMMMMM are 2 of the trusted 10 digit numbers.

From
Voice Services -> SP? Service -> X_InboundCallRoute =  {(x.1NNNNNNNNNN|x.1MMMMMMMMMM):aa},{ph}
-- Call instead of going to AA, directly rings phone connected to OBI200

To
Voice Services -> SP? Service -> X_InboundCallRoute =  {(+1NNNNNNNNNN|+1MMMMMMMMMM):aa},{ph}
-- Now when I call, instead of going to AA, call goes to voicemail without ringing phone.

See attached call history from OBI200 portal - It detects trusted number and sends to AA but AA is not working. What should do next?

drgeoff

Quote from: Ankur on May 22, 2018, 07:18:05 PM
See attached call history from OBI200 portal - It detects trusted number and sends to AA but AA is not working. What should do next?
Next thing to do is examine the settings on the Auto Attendant page.

Ankur

Quote from: drgeoff on May 23, 2018, 12:17:40 AM
Quote from: Ankur on May 22, 2018, 07:18:05 PM
See attached call history from OBI200 portal - It detects trusted number and sends to AA but AA is not working. What should do next?
Next thing to do is examine the settings on the Auto Attendant page.

Auto Attendant setting in pic with below values. I have not changed anything on this screen.

DigitMap =  ([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|<00:$1>|0|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**70(Mli)|**8(Mbt)|**81(Mbt)|**82(Mbt2)|**9(Mpp)|(Mpli))

OutboundCallRoute
{911:sp2},{([1-9]x?*(Mpli)):pp},{0:ph},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Msp3)):sp3},{(<**4:>(Msp4)):sp4},{(<**70:>(Mli)):li},{(<**82:>(Mbt2)):bt2},{(<**81:>(Mbt)):bt},{(<**8:>(Mbt)):bt},{(<**9:>(Mpp)):pp},{(Mpli):pli}

Ankur


Ok. My AA not working mystery solved. I turned on GV call screening and that killed AA.
I have now turned off GV call screening and AA is working fine.

Thanks for all the help.

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,

drgeoff

Quote from: Jeff47 on November 09, 2018, 04:59:14 AM
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,
Rather short on details.  What do you mean by "AA still didn't work"? What ITSP are you using?  Where are you trying those x., + and @ characters?  What is the format of the string you have there now?

Hoeveer

I've attempted to perform this change of x. to + on my Obihai 200, and after reboot it seems that OBiTALK re-asserts itself and changes the string back to x. on reboot.

I discovered that I needed to read the instructions above a little closer, and figure out how to get to obiexpert instead of trying to make the changes directly on the Obihai 200 device.

It pays to read the directions a few times for comprehension!

drgeoff

Quote from: Hoeveer on December 19, 2018, 10:53:16 AM
I've attempted to perform this change of x. to + on my Obihai 200, and after reboot it seems that OBiTALK re-asserts itself and changes the string back to x. on reboot.

Seems that Polycom really doesn't want us using this functionality any more.

Without more info I'd guess that you are changing this via your OBi200's onboard web server management interface.  Unless you have disabled Obitalk provisioning, changes made that way will be almost immediately overwritten by the settings on the Obitalk portal.  Make the change using Expert mode on the portal.  At the end of the relevant line are two tick boxes.  You must clear both of those before you can edit the setting.