Signaling WebSocket ping timeouts from Russian networks; stable with VPN

Client SDKs
, , ,
1

Hello,

We are developing an Android React Native voice-chat application using LiveKit Cloud.

Environment:

  • Expo SDK 54

  • React Native 0.81.5

  • @livekit/react-native 2.12.0

  • livekit-client 2.22.3

  • Tested on Realme C67 and a Samsung Galaxy device

  • Location: north-west Russia

We reproduced the issue through two different direct internet connections:

  1. Home Wi-Fi

  2. iPhone mobile hotspot

With VPN disabled:

  • The participant initially connects successfully.

  • The connection is routed to Germany 2, node OFRANKFURT1B.

  • Approximately every 15–20 seconds, the signaling WebSocket closes with ping timeout.

  • The SDK reports RR_SIGNAL_DISCONNECTED and repeatedly enters signalReconnecting.

  • The microphone becomes unavailable and the application displays “Reconnecting”.

  • The selected WebRTC route is srflx/udp -> host, so ICE/media connectivity is established.

With VPN enabled:

  • The same application build, devices, room and user accounts work correctly.

  • The client still connects to the Germany 2 region.

  • Two-way microphone audio works.

  • The connection remains stable with no signaling ping timeouts.

Participant permissions are valid:

  • canPublish: true

  • canPublishSources: MICROPHONE

  • canSubscribe: true

Affected direct-connection test:
September 24, 2026, approximately 08:38–08:42 UTC.

Successful VPN test:
September 24, 2026, approximately 09:11 UTC.

This appears to affect the secure signaling WebSocket rather than microphone permissions or the WebRTC media route.

Could you please advise:

  1. Are there known routing or WebSocket connectivity issues between Russian networks and the Germany 2 edge?

  2. Is it possible to test this project through another LiveKit Cloud edge?

  3. Is there a supported workaround for stabilizing the signaling WebSocket in this network environment?

  4. Can we provide the project/session identifiers and Android logcat files privately for investigation?

Thank you.

2

@Maksim, The ping timeout is the signaling keepalive, not media or permissions: the client pings the signaling WebSocket on a server-set interval and drops into reconnect if the pong does not return in time (handleOnClose('ping timeout'), SignalClient.ts#L1143-L1155; timings from the JoinResponse at #L654-L655). Your handshake and UDP media pass, but the long-lived WS ping/pong does not. Reproduced on two Russian ISPs and cured by VPN with the same region and media path, that is the network path interfering with the persistent WSS, not LiveKit or your config.

  1. Known Russia-to-Frankfurt issue: Cloud-internal, so support with your session IDs is the way to confirm it. The team has read VPN connectivity failures as “something blocking websockets in the path” before (#900).
  2. Another edge: region pinning is the lever, but it is Scale-plan and adds latency (region pinning), and will not help if every EU path is filtered the same. On a similar VPN routing thread the team proposed EU region pinning (#665), so raise it with support rather than assume it fixes this.
  3. Workaround: none in the SDK. The ping interval and timeout are server-set, so you cannot widen them client-side; a tunneling transport like your VPN is the only thing that stabilizes the path.
  4. IDs/logcat: yes, send them to support.