token error

Started by chiptape, June 09, 2021, 12:50:17 PM

Previous topic - Next topic

TheFoxRocks

Quote from: SteveInWA on June 12, 2021, 11:13:37 AM
I reported this to Google Voice engineering staff yesterday afternoon.  They have identified the problem and they are working with Poly to resolve it.

To be clear: no action on your part is necessary nor will fix it at this time.  This outage is a good reminder that nobody should depend on Google Voice as their sole source of telephone service, and you can configure your OBiTALK device to use one or more other service providers, such as Callcentric or voip.ms.

I'm sorry, but I don't have any status update to report, since my Google contacts are off for the weekend.  Nonetheless, it's safe to assume that they are working on it, and I will pass along any news I can get.

Hey Steve,

You have my thanks for reaching out on behalf of the community. Please know, that there are people who are thankful for people like yourself. I think people fail to appreciate after buying their OBi (or other) device that they are getting completely free service through Google Voice and expect that free service to always be perfect. I was only relying on Google Voice before. I am using mine as a business phone, I will probably follow your CallCentric guide later today so I have a viable backup. Thanks again!

PusBucket

This didn't achieve even a temporary fix, for me.


Quote from: GeeObi on June 13, 2021, 09:10:29 AM
The fix is as follows:
Use Obi expert and under Service Providers, ITSP, General:
STUNEnable  checked  (you must uncheck the box to the right first)
STUNserver  stun.l.google.com
X_STUNServerPort  19302

calt

Quote from: GeeObi on June 13, 2021, 09:10:29 AM
The fix is as follows:
Use Obi expert and under Service Providers, ITSP, General:
STUNEnable  checked  (you must uncheck the box to the right first)
STUNserver  stun.l.google.com
X_STUNServerPort  19302

NO fix!
I tried these changes via OBI expert and via the built in UI of the device (local IP). Also rebooted after each change.

Still exactly the same token error!

Will undo these changes.

Taoman

Quote from: jccpa on June 13, 2021, 08:08:17 AM

NSLOOKUP cannot find obihai.sip.google.com or sip.google.com using 8.8.8.8 or 8.8.4.4 or 1.1.1.1 or ns1.google.com

*** dns.google can't find sip.google.com: Non-existent domain

So either Google shut down SIP of google voice, or the A Record was removed on purpose or by attack.

In any case, until the A record for sip.google.com is restored, no obihai.sip.google.com, no GV connection.

obihai.sip.google.com has never had an A record or SRV record. It doesn't matter. Whenever there is an OutboundProxy setting it overrides any Proxy server setting.

All SIP requests go to obihai.telephony.goog, not obihai.sip.google.com. From there it gets redirected as needed.

Look at many of the error messages people are getting:"Connecting to 216.239.36.145;Token Error"
And what does 216.239.36.145 resolve to? The OutboundProxy setting which is obihai.telephony.goog.

You're wasting your time worrying about obihai.sip.google.com.

Mickey613

Quote from: ppan on June 13, 2021, 11:16:21 AM
Quote from: GeeObi on June 13, 2021, 11:01:31 AM
It should look like this:

It looks like that (but slightly different layout for me). I unchecked STUNEnable since it didn't help. See image here:
https://i.gyazo.com/ac54496c7b678553a3cbbb70beb65aa0.png


That's exactly the settings I had BEFORE making any changes. I'm still down with or without this setting change.

Taoman

Quote from: GeeObi on June 13, 2021, 09:10:29 AM
The fix is as follows:
Use Obi expert and under Service Providers, ITSP, General:
STUNEnable  checked  (you must uncheck the box to the right first)
STUNserver  stun.l.google.com
X_STUNServerPort  19302

The purpose of a STUN server is to allow the local client to traverse your local NAT successfully. The current issue some people are experiencing is not related to any STUN setting.
Your OBi device may have connected after making a STUN setting change but I guarantee it was purely coincidental.

Taoman

The following was recently posted on Reddit supposedly by a Google Voice engineer:
QuoteGV eng here: There is some kind of OAuth refresh token problem with some devices. We haven't been able to track it down as of yet. It seems to be only affecting some OBiTALK devices, but it's unclear why because neither us nor Polycom have rolled anything out that would do this, not that we know of at least. We are continuing to investigate, but Google has no access to the devices so there's not a lot to go on. If you have paid support from Polycom, please open a support case with them and give them the serial number of the device that is malfunctioning so they can pull its system logs.

https://www.reddit.com/r/Googlevoice/comments/nxubgn/google_voice_token_error_message_on_poly_obitalk/h1m05vh?utm_source=share&utm_medium=web2x&context=3

railpass

Just ported my Google Voice number to a different Service Provider (Anveo). Didn't realize how dependent I'd become on the VoIP line. Hard to complain given that GV was free.

Jasmine10

You are 100% correct, obihai.sip.google.com is just SIP realm name: http://docs.intenogroup.com/v312/en/glossary/s/sip_realm#:~:text=A%20SIP%20realm%20is%20a,as%20a%20the%20SIP%20domain.

216.239.36.145 is the real SIP registration server: obihai.telephony.goog

But before SIP registration, it needs to get OAuth token from another Google server: www.googleapis.com

If changing DNS works, it may be related to the fact that different DNS servers may return different IPs for this server.
Can anyone post the dns resolution output:

In Mac computer:

# Get answer from your ISP DNS server
dig www.googelapis.com

# Get answer from specific DNS server
dig @1.1.1.1 www.googleapis.com

Please also include your city/state.


Quote from: Taoman on June 13, 2021, 11:36:39 AM
Quote from: jccpa on June 13, 2021, 08:08:17 AM

NSLOOKUP cannot find obihai.sip.google.com or sip.google.com using 8.8.8.8 or 8.8.4.4 or 1.1.1.1 or ns1.google.com

*** dns.google can't find sip.google.com: Non-existent domain

So either Google shut down SIP of google voice, or the A Record was removed on purpose or by attack.

In any case, until the A record for sip.google.com is restored, no obihai.sip.google.com, no GV connection.

obihai.sip.google.com has never had an A record or SRV record. It doesn't matter. Whenever there is an OutboundProxy setting it overrides any Proxy server setting.

All SIP requests go to obihai.telephony.goog, not obihai.sip.google.com. From there it gets redirected as needed.

Look at many of the error messages people are getting:"Connecting to 216.239.36.145;Token Error"
And what does 216.239.36.145 resolve to? The OutboundProxy setting which is obihai.telephony.goog.

You're wasting your time worrying about obihai.sip.google.com.


lrosenman

#129
I got an ONLINE note from Obitalk at 13:45 CDT 2021-06-13.  Thanks, @SteveInWa for reaching out to Google!

Taoman

#130
Quote from: Jasmine10 on June 13, 2021, 12:52:09 PM

But before SIP registration, it needs to get OAuth token from another Google server: www.googleapis.com

If changing DNS works, it may be related to the fact that different DNS servers may return different IPs for this server.


Right. Someone posted a SIP trace and it points to a cert issue. I would guess this is correct as it has happened before.
QuoteI did a packet capture and get a "Unknown CA error" so it looks like a certificate issue.

Transport Layer Security
   TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unknown CA)
       Content Type: Alert (21)
       Version: TLS 1.2 (0x0303)
       Length: 2
       Alert Message
           Level: Fatal (2)
           Description: Unknown CA (48)


Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    www.googleapis.com
Addresses:  2607:f8b0:400a:80a::200a
         2607:f8b0:400a:806::200a
         2607:f8b0:400a:805::200a
         2607:f8b0:400a:807::200a
         142.250.217.106
         142.251.33.106
         142.250.217.74
         172.217.14.234
         142.250.69.202
         172.217.14.202
         142.251.33.74

Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    www.googleapis.com
Addresses:  2607:f8b0:400a:803::200a
         2607:f8b0:400a:805::200a
         2607:f8b0:400a:807::200a
         2607:f8b0:400a:806::200a
         172.217.14.234
         142.250.69.202
         142.251.33.106
         142.251.33.74
         142.250.217.74
         142.250.217.106
         172.217.14.202

Server:  cdns01.comcast.net
Address:  75.75.75.75

Non-authoritative answer:
Name:    www.googleapis.com
Addresses:  2607:f8b0:400a:805::200a
         2607:f8b0:400a:807::200a
         2607:f8b0:400a:806::200a
         2607:f8b0:400a:803::200a
         142.250.69.202
         142.251.33.106
         142.251.33.74
         142.250.217.74
         142.250.217.106
         172.217.14.202
         172.217.14.234

Edit: Near Seattle, WA and GV has stayed connected to 2 GV accounts on multiple OBi devices.


Taoman

Quote from: Jasmine10 on June 13, 2021, 12:52:09 PM

If changing DNS works, it may be related to the fact that different DNS servers may return different IPs for this server.


So is your OBi device not connecting to GV? If so, are you able to do a TCPdump? That's what the GV engineer was asking for. I posted the SIP trace but that wasn't enough. All my OBi devices are connecting normally so a TCPdump from me would do no good.

https://www.reddit.com/r/Googlevoice/comments/nxubgn/google_voice_token_error_message_on_poly_obitalk/h1mm753?utm_source=share&utm_medium=web2x&context=3


awriter

Obi 200 still out in New England at 4:30 pm EST. Still shows either token error or registration not required.

However... I just discovered that Alexa can call out using my GV number, no problem! And there's one within the sound of my voice all around the house.

If you have an Echo, give it a try.

Jasmine10

Hi, Taoman,

Thanks for your help.
So 1.1.1.1 and 8.8.8.8 work, but 75.75.75.75 doesn't work, correct?

Quote from: Taoman on June 13, 2021, 01:06:10 PM

Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    www.googleapis.com
Addresses:  2607:f8b0:400a:80a::200a
         2607:f8b0:400a:806::200a
         2607:f8b0:400a:805::200a
         2607:f8b0:400a:807::200a
         142.250.217.106
         142.251.33.106
         142.250.217.74
         172.217.14.234
         142.250.69.202
         172.217.14.202
         142.251.33.74

Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    www.googleapis.com
Addresses:  2607:f8b0:400a:803::200a
         2607:f8b0:400a:805::200a
         2607:f8b0:400a:807::200a
         2607:f8b0:400a:806::200a
         172.217.14.234
         142.250.69.202
         142.251.33.106
         142.251.33.74
         142.250.217.74
         142.250.217.106
         172.217.14.202

Server:  cdns01.comcast.net
Address:  75.75.75.75

Non-authoritative answer:
Name:    www.googleapis.com
Addresses:  2607:f8b0:400a:805::200a
         2607:f8b0:400a:807::200a
         2607:f8b0:400a:806::200a
         2607:f8b0:400a:803::200a
         142.250.69.202
         142.251.33.106
         142.251.33.74
         142.250.217.74
         142.250.217.106
         172.217.14.202
         172.217.14.234

Edit: Near Seattle, WA and GV has stayed connected to 2 GV accounts on multiple OBi devices.



Taoman

Quote from: Jasmine10 on June 13, 2021, 01:46:02 PM
Hi, Taoman,

Thanks for your help.
So 1.1.1.1 and 8.8.8.8 work, but 75.75.75.75 doesn't work, correct?

Not using Comcast's DNS servers. Using 8.8.8.8 as primary and 8.8.4.4 as secondary.

Jasmine10

My OBi is working, so we need someone with a failed device to do a TCPdump.

Quote from: Taoman on June 13, 2021, 01:26:11 PM

So is your OBi device not connecting to GV? If so, are you able to do a TCPdump? That's what the GV engineer was asking for. I posted the SIP trace but that wasn't enough. All my OBi devices are connecting normally so a TCPdump from me would do no good.

https://www.reddit.com/r/Googlevoice/comments/nxubgn/google_voice_token_error_message_on_poly_obitalk/h1mm753?utm_source=share&utm_medium=web2x&context=3



Jasmine10

Can you provide DNS resolution output for www.googelapis.com with 1.1.1.1?

Also the output of below command if you are on Mac or Linux:
curl -v --tlsv1.2 "https://www.googleapis.com/"


Quote from: SoNic67 on June 13, 2021, 08:01:44 AM
I did replace the Default DNS providers with the 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google) and the OBi202 is still not working.
Deleted the device from Google account and it won't show up anymore when setting it up from OBiTalk webpage.
obihai.sip.google.com doesn't resolve to anything

Jasmine10

Can you provide DNS resolution output for www.googelapis.com with your ISP DNS?

Also the output of below command if you are on Mac or Linux:
curl -v --tlsv1.2 "https://www.googleapis.com/"

Quote from: awriter on June 13, 2021, 01:39:01 PM
Obi 200 still out in New England at 4:30 pm EST. Still shows either token error or registration not required.

However... I just discovered that Alexa can call out using my GV number, no problem! And there's one within the sound of my voice all around the house.

If you have an Echo, give it a try.

Mickey613

on Win10


>curl -v --tlsv1.2 "https://www.googleapis.com/"
*   Trying 142.251.33.202...
* TCP_NODELAY set
* Connected to www.googleapis.com (142.251.33.202) port 443 (#0)
* schannel: SSL/TLS connection with www.googleapis.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 189 bytes...
* schannel: sent initial handshake data: sent 189 bytes
* schannel: SSL/TLS connection with www.googleapis.com port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with www.googleapis.com port 443 (step 2/3)
* schannel: encrypted data got 2937
* schannel: encrypted data buffer: offset 2937 length 4096
* schannel: sending next handshake data: sending 93 bytes...
* schannel: SSL/TLS connection with www.googleapis.com port 443 (step 2/3)
* schannel: encrypted data got 292
* schannel: encrypted data buffer: offset 292 length 4096
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with www.googleapis.com port 443 (step 3/3)
* schannel: stored credential handle in session cache
> GET / HTTP/1.1
> Host: www.googleapis.com
> User-Agent: curl/7.55.1
> Accept: */*
>
* schannel: client wants to read 102400 bytes
* schannel: encdata_buffer resized 103424
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 1974
* schannel: encrypted data buffer: offset 1974 length 103424
* schannel: decrypted data length: 1401
* schannel: decrypted data added: 1401
* schannel: decrypted data cached: offset 1401 length 102400
* schannel: encrypted data length: 544
* schannel: encrypted data cached: offset 544 length 103424
* schannel: decrypted data length: 515
* schannel: decrypted data added: 515
* schannel: decrypted data cached: offset 1916 length 102400
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: decrypted data buffer: offset 1916 length 102400
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 1916
* schannel: decrypted data buffer: offset 0 length 102400
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=UTF-8
< Referrer-Policy: no-referrer
< Content-Length: 1561
< Date: Sun, 13 Jun 2021 21:25:22 GMT
< Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
<
<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>
  <style>
    *{margin:0; ...
  </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>404.</b> <ins>That's an error.</ins>
  <p>The requested URL <code>/</code> was not found on this server.  <ins>That's all we know.</ins>
* Connection #0 to host www.googleapis.com left intact

vincentnyc

Quote from: PusBucket on June 13, 2021, 11:25:11 AM
This didn't achieve even a temporary fix, for me.


Quote from: GeeObi on June 13, 2021, 09:10:29 AM
The fix is as follows:
Use Obi expert and under Service Providers, ITSP, General:
STUNEnable  checked  (you must uncheck the box to the right first)
STUNserver  stun.l.google.com
X_STUNServerPort  19302

that dude is lying out of his buttcheek.  i ignore dude like him.