Connecting to room on Android 12 over cellular causes entire device network interface to disconnect
Closed this issue · 18 comments
- I have verified that the issue occurs with the latest twilio-video.js release and is not marked as a known issue in the CHANGELOG.md.
- I reviewed the Common Issues and open GitHub issues and verified that this report represents a potentially new issue.
- I verified that the Quickstart application works in my environment.
- I am not sharing any Personally Identifiable Information (PII)
or sensitive account information (API keys, credentials, etc.) when reporting this issue.
Expected behavior:
User should be able to connect without cellular network drop.
Actual behavior:
When a Twilio video participant joins a room from an Android 12 device over cellular (tested multiple Verizon SIMs throughout the US) the cellular radio completely drops, resets, then drops again. This occurs in a continuous loop.
- Behavior doesn't occur on Android 11.
- Behavior doesn't occur on Google Fi.
- Behavior doesn't occur Android 12 device is connected to a VPN.
- Tested on Pixel 3, 4A, 5, and 6 running Android 12
- Doesn't occur with other known WebRTC clients such as Google Meet and Signal
As soon as the the Verizon user joins the call it's cellular interface drops.
11-19 09:17:20.955 873 882 I WPKTRT : process_address_event: 100.123.Y.Z removed from rmnet1
11-19 09:17:20.957 20506 20918 V NativeCrypto: Read error: ssl=0xb400006dd5d6a418: I/O error during system call, Software caused connection abort
"Software caused connection abort":
11-19 09:17:20.964 13960 20873 E CarrierServices: [454] eyb.run: (RCS): : Error while receiving message: Software caused connection abort: java.net.SocketException: Software caused connection abort
11-19 09:17:20.964 13960 20873 E CarrierServices: at java.net.SocketInputStream.socketRead0(Native Method)
11-19 09:17:20.964 13960 20873 E CarrierServices: at java.net.SocketInputStream.socketRead(SocketInputStream.java:119)
11-19 09:17:20.964 13960 20873 E CarrierServices: at java.net.SocketInputStream.read(SocketInputStream.java:176)
11-19 09:17:20.964 13960 20873 E CarrierServices: at java.net.SocketInputStream.read(SocketInputStream.java:144)
11-19 09:17:20.964 13960 20873 E CarrierServices: at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.readFromSocket(ConscryptEngineSocket.java:945)
11-19 09:17:20.964 13960 20873 E CarrierServices: at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.processDataFromSocket(ConscryptEngineSocket.java:909)
11-19 09:17:20.964 13960 20873 E CarrierServices: at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.readUntilDataAvailable(ConscryptEngineSocket.java:824)
11-19 09:17:20.964 13960 20873 E CarrierServices: at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.read(ConscryptEngineSocket.java:797)
11-19 09:17:20.964 13960 20873 E CarrierServices: at java.io.BufferedInputStream.fill(BufferedInputStream.java:248)
11-19 09:17:20.964 13960 20873 E CarrierServices: at java.io.BufferedInputStream.read(BufferedInputStream.java:267)
11-19 09:17:20.964 13960 20873 E CarrierServices: at dgo.a(PG:2)
11-19 09:17:20.964 13960 20873 E CarrierServices: at exb.a(PG:3)
11-19 09:17:20.964 13960 20873 E CarrierServices: at eyb.run(PG:6)
11-19 09:17:20.965 13960 20873 I CarrierServices: [454] cpg.b: Using config server URL from bcy
11-19 09:17:20.966 14002 20852 V NativeCrypto: Read error: ssl=0xb400006dd5dc2858: I/O error during system call, Software caused connection abort
11-19 09:17:20.975 20506 21563 V Twilio : [Core](465699421360): WebSocket::Implementation::on_read
11-19 09:17:20.975 20506 21563 W Twilio : [Core](465699421360): Closing the connection due a system error 103 while reading: Software caused connection abort
11-19 09:17:20.975 20506 21563 V Twilio : [Core](465699421360): WebSocket::Implementation::on_close
11-19 09:17:20.975 20506 21563 W Twilio : [Core](465699421360): The WebSocket was closed with a system error, code 103: Software caused connection abort
11-19 09:17:20.975 18014 20832 V NativeCrypto: Write error: ssl=0xb400006dd5d71918: I/O error during system call, Broken pipe
The device reconnects and attempts to connect to the room again. The process loops:
11-19 09:17:20.977 20506 21372 D Twilio : [Core](466788527280): <0xb400006e15db2f50> Reconnecting, starting session expiry timer. timeout: 30s
11-19 09:17:20.977 20506 21372 V Twilio : [Core](466788527280): <0xb400006e15db2f50> TcmpSignaling::startReconnectionTimer: session_state: kReconnecting
11-19 09:17:20.977 20506 21372 D Twilio : [Core](466788527280): The network is reachable, retrying connection in 95 ms.
11-19 09:17:20.977 20506 21372 V Twilio : [Core](466788527280): <0xb400006e15db2f50> TcmpSignaling::closeConnection: Completed for 5baa8be1-6ea5-4498-b782-5a88d6e98870. session_state: kReconnecting
Showing the cellular connection to fail:
11-19 09:17:21.007 2186 21594 D NetworkMonitor/134: PROBE_DNS connectivitycheck.gstatic.com 2ms FAIL in type ADDRCONFIG android.net.DnsResolver$DnsException: android.system.ErrnoException: resNetworkQuery failed: ENONET (Machine is not on the network)
11-19 09:17:21.008 13960 14022 I CarrierServices: [190] cde.c: (RCS): : Exit RegisteredState
11-19 09:17:21.008 2186 21593 D NetworkMonitor/134: PROBE_DNS www.google.com 3ms FAIL in type ADDRCONFIG android.net.DnsResolver$DnsException: android.system.ErrnoException: resNetworkQuery failed: ENONET (Machine is not on the network)
11-19 09:17:21.010 2186 21594 D NetworkMonitor/134: PROBE_HTTP http://connectivitycheck.gstatic.com/generate_204 Probe failed with exception java.net.UnknownHostException: Unable to resolve host "connectivitycheck.gstatic.com": No address associated with hostname
11-19 09:17:21.012 2186 21593 D NetworkMonitor/134: PROBE_HTTPS https://www.google.com/generate_204 Probe failed with exception java.net.UnknownHostException: Unable to resolve host "www.google.com": No address associated with hostname
11-19 09:17:21.015 2186 21592 D NetworkMonitor/134: PROBE_FALLBACK http://www.google.com/gen_204 Probe failed with exception java.net.UnknownHostException: Unable to resolve host "www.google.com": No address associated with hostname
...
11-19 09:17:21.024 20131 21347 V NativeCrypto: SSL shutdown failed: ssl=0xb400006dd5d75098: I/O error during system call, Success
11-19 09:17:21.024 1518 1792 I GnssNetworkConnectivityHandler: Network connection lost. Available networks count: 0
11-19 09:17:21.024 1518 1792 I GnssNetworkConnectivityHandler: updateNetworkState, state=CLOSED, connected=false, network=134, capabilities=[ Transports: CELLULAR Capabilities: SUPL&DUN&INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VPN&VALIDATED&NOT_ROAMING&NOT_CONGESTED&NOT_SUSPENDED&NOT_VCN_MANAGED LinkUpBandwidth>=15000Kbps LinkDnBandwidth>=30000Kbps Specifier: <TelephonyNetworkSpecifier [mSubId = 1]> SubscriptionIds: {1}], apn: VZWINTERNET, availableNetworkCount: 0
Possibly relates to:
- https://bugs.chromium.org/p/chromium/issues/detail?id=898210
- webrtc/samples#1302
- https://docs.freedomrobotics.ai/docs/webrtc-connection-issue-on-cellular-routers
Software versions:
- Browser(s):
- Operating System: Android 12
- twilio-video.js: 7.0.2 within native Android app
- Third-party libraries (e.g., Angular, React, etc.):
Hello, would it be possible to troubleshoot this while traversing through the Twilio network? It seems like there isn't much activity here from Android 12 developers.
@futurealecks thank you for filing the bug. We will investigate.
Any update on this? Still happening for us. Thanks!
@afriedmanGlacier we don't have an update yet, we are still investigating, we will keep you posted. BTW, do you or @futurealecks know if when this happens the device is on an IPv6 cell network?
@afalls-twilio I'm not sure but I can confirm that this still occurs on Android 12 over cellular.
@afalls-twilio , could we discuss this with someone outside of GitHub? Causing us some pain.
I am also dogged by this issue, but in my own audio-only webrtc-based app, not using twilio.
Thanks very much for your description of this problem. I would love to hear if you discover a workaround.
I suppose if signal doesn’t have this issue then I will look again at their source code and see what I can find.
@StevenLove thanks for adding your comment. Signal app does not have these issues as far as I can tell.
Back in November I said this does not occur on the Google Fi network. We now see it across most cellular networks.
@futurealecks @StevenLove Sorry for the delay, please check out 7.3.1 and see if that fixes the issue, we fixed many issues in that release.
@futurealecks may I ask if your affected devices use Android Work Profile? I am not personally able to reproduce the issue and I don't know if the key factor is just that I'm on AT&T and not Verizon.
@futurealecks I don't know if you are still affected, but I've successfully developed a workaround. I can filter out the ICE candidates that start with fc00: or fd00: as they represent private IP addresses. Perhaps this workaround would be inappropriate if the client and server are on the same private network, but apparently these candidates resulted in our client trying to send packets to the private IPv6 address which resulted in killing the device network interface.
@StevenLove that's interesting, we'll check that out! I haven't looked at this thread for a while, and I'm not sure whether it's IPv6 related or not, but that gives us a place to look. (By the way, this is also affecting iOS for us, but with iOS the Twilio code is in a Framework and I don't think I can do any sort of workaround.) Thanks!
@futurealecks we have a support channel that may be able to help? we are in the midst of a major upgrade, which includes changed in the way ICE behaved. I was not able to reproduce your issue in the past, but maybe upon this upgrade, your issue will be resolved?
@afalls-twilio hopefully. This is still an issue across certain devices and networks.
@afalls-twilio do you have an ETA on this update for us to be able to test?
@futurealecks We released 7.6.1 which included the ICE negotiation changes a few weeks ago, Were you able to test with that version?
@afalls-twilio We updated to 7.6.1 and saw the same issues described above. We decided to try swapping our Verizon physical SIMs to Verizon eSIMs and the problem went away. I then asked one of our customers who also reported the issue last year to do the same upgrade to eSIM - and that also solved the issue.
Now, can anyone on the internet tell me why switching to eSIM would fix this issue (same phone, same subscriber info).
@futurealecks Thats weird... from a software side, we have no knowledge of the type of sim used.... this could be a carrier issue, maybe?
either way, glad it was resolved, closing...