Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Google Voice WiFi-calling always fails #2168

Closed
baraja opened this issue Mar 20, 2019 · 19 comments

Comments

Projects
None yet
4 participants
@baraja
Copy link

commented Mar 20, 2019

Describe the bug
google voice's new feature wifi-calling always failed with shadowsock-android
while works well with shadowsocks-windows + LAN proxy sharing on andorid
also works well with chrome + shadowsocks on windows using google voice's web version
also works well with wireguard/anyconnect VPN on android

To Reproduce
Steps to reproduce the behavior:

  1. open google voice APP (set the call settings to wifi-calling)
  2. dial a number in the US (for example citibank 's 800-374-9700)
  3. google voice is trying to connect
  4. seems connected, but no voice at all
  5. about 12s later, google voice hangs up

Expected behavior
google voice can dial with shadowsocks-andorid

Smartphone (please complete the following information):

  • Android O
  • Device: Google Pixel 3 XL

Configuration

  • IPv4 server address
  • IPv6 server address
  • Client IPv4 availability
  • Client IPv6 availability
  • Encrypt method: aes-128-gcm
  • Route
    • All
    • Bypass LAN
    • Bypass China
    • Bypass LAN & China
    • GFW List
    • China List
    • Custom rules
  • IPv6 route
  • Apps VPN mode
    • Bypass mode
  • Remote DNS: 8.8.8.8
  • DNS over UDP
  • Plugin configuration (if applicable):
  • Auto Connect
  • TCP Fast Open
  • If you're not using VPN mode, please supply more details here:

@baraja baraja changed the title Google Voice WiFi-calling always fail Google Voice WiFi-calling always fails Mar 20, 2019

@madeye

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

Disable Wifi-calling or try Hangouts instead.

VoIP is expected to have problems through shadowsocks.

@baraja

This comment has been minimized.

Copy link
Author

commented Mar 20, 2019

Thanks for the reply.
But why it works well with shadowsocks-windows
(On both windows and android)

@madeye

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

Just tried Hangouts, shadowsocks works well.

On windows, it's through Hangouts APIs, not VoIP. Actually, shadowsocks-windows won't proxy any UDP traffic.

@baraja

This comment has been minimized.

Copy link
Author

commented Mar 20, 2019

I see. So that means when the wifi proxy of android is set to shadowsocks-windows(via LAN sharing)
Udp packet don't go through windows at all.
They are sent directly to Google's server?
(Which surprises me but I can dial without any VPN sometimes)

@baraja

This comment has been minimized.

Copy link
Author

commented Mar 20, 2019

BTW, v2rayNG-android seems working quite well with Google voice.
Sadly the app sucks, as well as other v2ray apps
I will stick to shadowsocks android.
Regards

@Mygod

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

I dumped some logcat. It seems like Google Voice is using STUN and SIP.

23870  1537 I native  : rtc_tel_session.cc:1276 webrtc::PeerConnectionInterface::kIceConnectionFailed
23870  1537 I native  : voice_call_impl.cc:1531 STUN ping completed success=false server=stun.l.google.com:19302
23870  1537 I native  : voice_call_impl.cc:1766 RTC state DONE
23870  1537 I native  : voice_call_impl.cc:1571 Media disconnected while call cxlpBp5ThUn5SNR0rAj1QAIl_8905477511d5_ was active.
23870  1538 I native  : voice_call_impl.cc:928 VoiceCall state Active --> Ended

@madeye Perhaps implementing full-cone NAT would help?

@madeye

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

I think shadowsocks is indeed a full cone NAT, unless we broke something recently.

@Mygod

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

It's showing up as address restricted cone on my side, tested with https://play.google.com/store/apps/details?id=md.tabuci.stunclient.

@madeye

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

Okay, yes it's NAT type 2, address restricted NAT.

BTW, UDP forwarding should work correctly. Tried quic with YouTube, everything works well.

@Mygod

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

I think VoIP requires full-cone (also useful for p2p transfer in general). Let's implement this in ss-server sometime.

@madeye madeye closed this in 6849027 Mar 25, 2019

@madeye

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

It turns out a bug in tun2socks, fixed via shadowsocks/badvpn@b0c4d28

@madeye

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

In general, it's possible that the UDP client will send packet to different remote address from same source UDP port.

However, our previous UDP NAT logic assumed remote address keeps the same for one source port.

@Mygod

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

Wi-Fi calling seems to be working fine now, but STU test still shows as Address-restricted-cone. Is it due to the issue you described in the previous comment?

@madeye

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

address-restricted-cone is expected as we only open a UDP port on server after receiving a request.

Google Voice is using UDP hole punching, so it should work fine.

@Mygod

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

In full-cone, the server/router also opens a UDP port on server/router after receives a first packet, but instead it also forward packets from other remote address. I think it should be achievable.

@madeye

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

full-cone requires one-to-one port mapping, given we have multiple clients behind ss-server, it may not be possible.

You can test STUN behind any WiFi, it should only report restricted-clone unless you expose your client with a DMZ setting on the router.

@Mygod

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

Agreed but it might be possible to make this an optional feature in ss-server as an ordinary server should not have >60k concurrent UDP connections IMO.

EDIT: But I guess hole-punching should work fine as well XD.

@yzou

This comment has been minimized.

Copy link

commented Mar 26, 2019

And I think this is not a tun2socks bug, it's according to the socks5 rfc: https://www.ietf.org/rfc/rfc1928.txt

The UDP relay server MUST acquire from the SOCKS server the expected
IP address of the client that will send datagrams to the BND.PORT
given in the reply to UDP ASSOCIATE. It MUST drop any datagrams
arriving from any source IP address other than the one recorded for
the particular association.

@yzou

This comment has been minimized.

Copy link

commented Mar 26, 2019

After resetting the remote addr, will the packet sent to old remote addr match the same connection?

Kiku-git added a commit to Kiku-git/shadowsocks-android that referenced this issue Mar 30, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.