switched from OBi110 to 200 - autoattendant not working for trusted callers
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 pm
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!
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page