Google Voice WiFi-calling always fails

[baraja]

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

• [x] IPv4 server address
• [ ] IPv6 server address
• [x] Client IPv4 availability
• [ ] Client IPv6 availability
• Encrypt method: aes-128-gcm
• Route
  • [x] 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):
• [x] Auto Connect
• [x] TCP Fast Open
• If you're not using VPN mode, please supply more details here:

[madeye]

Disable Wifi-calling or try Hangouts instead.

VoIP is expected to have problems through shadowsocks.

[baraja]

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

[madeye]

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]

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]

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]

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]

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

[Mygod]

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]

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

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

[Mygod]

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

[madeye]

It turns out a bug in tun2socks, fixed via https://github.com/shadowsocks/badvpn/commit/b0c4d28e7406eb35a5708bf57683578ba82b11e6

[madeye]

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]

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]

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]

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]

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]

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.

[made-by-love]

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.

[made-by-love]

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