Here's something interesting.
Test was done by forcing dns on the pc to 8.8.8.8 and the comodo dns 8.26.56.26. Each nslookup was repeated at least 30 times, noting the resolved ip for
talk.google.com. Here's the values received. Ipconfig /flushdns was run after changing dns server setting.
-=}nslookup
talk.google.comUsing 8.8.8.8 for dns server
results:
173.194.192.125
209.85.234.125
74.125.69.125
Using 8.26.56.26 for dns server
results:
74.125.133.125
66.102.1.125
64.233.184.125
74.125.71.125During the test, the values would often repeat, but the above were the
unique values resolved. Note that there is *NO* overlap in results between the two dns servers.
Next, to put this theory to a test, I forced
talk.google.com to point to each of the 4 ip's in my firewall - albeit a bit limited because the firewall does not support a host dns pool (multiple ip's for a single FQDN) so each ip had to be added manually then tested.
I then pointed the obi to my firewall's dns service. Rebooted (several times after each ip change for
talk.google.com).
Results: After each and every reboot the obi connected just fine to GV. No backing off message.
Conclusion: First, it's unclear why comodo dns is the only one resolving to these ip's. I tried opendns, 8.8.8.8 and 4.2.2.2. 4.2.2.2 did come up with a few other values but it's unclear if those would work or not.
I believe there may be some misconfiguration on google's part. However, it doesn't doesn't address why gv works just fine through the pbx and hangouts.
I looked at the source code for the freepbx gv module -
https://github.com/FreePBX/motif/archive/release/12.0.4.2.zip . Looks like it just references
talk.google.com -
functions.inc.php file, line 160.
Could be the _way_ obi is authenticating with gv is different from that of the pbx module.
Second, it's unclear exactly how
talk.google.com is referenced by the obibox. Is it using strictly
talk.google.com, or something else. Is there a pool of
talk.google.com hostnames (talk.1.google.com?). Based on the results, I'd say it's simply referencing
talk.google.com.
It will be interesting to see whether the fix involves a firmware update..