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.