webRTC - Peerconnection failure over mobile data (4G/5G) on Android

Answered

Didier Boelens

October 13, 2025 11:58 Edited

Hi,
I am developing a mobile application in Flutter that connects to remote camera via nxvms, over Wifi and mobile data, using webRTC.
Everything goes fine when the application is connected to a Wifi.
On iOS, everything also goes fine with mobile data 4G/5G.
However, on Android devices, on mobile data, the connection is random and most of time fails during the ICE Candidate phase.

In order to create a peer connection, I am using the following configuration that works fine with Wifi:
final Map<String, dynamic> configuration = {
"iceServers": [
{'urls': 'stun:stun.l.google.com:19302'},
{'urls': 'stun:stun1.l.google.com:19302'},
{'urls': 'stun:stun2.l.google.com:19302'},
],
'sdpSemantics': 'unified-plan',
};
This configuration does not mention any Turn server but according to the documentation, it is not necessary.
Regarding the web socket URL, I am using the following URL template:
'wss://$systemId.$waveRelayUrl/rest/v3/devices/$cameraId/webrtc?stream=$streamParam&_ticket=$_ticketId';

I have now been struggling with it for weeks, and I have absolutely no idea on how to solve this, therefore, any help would be more than welcome…

Thanks in advance, 

0

• 

  Ichiro

  • Network Optix team

  October 20, 2025 14:54

  Hi Didier Boelens,

  Thanks for your questions and your understanding is correct - TURN is not always required.  However, with celluar network comparing to WIFI, there are a few significant differences.

   

  1. The NAT Type.
  The NAT type for cellular network usually CGNAT, it will sometimes cause for STUN, which results in ICE candidate listed failed.

  2.TURN Server
  Although it is not necessary always, however, in webRTC, this may cause potential issue which p2p connection failed cause the webRTC failed.

  3.Firewall/blocklist.
  This is a possible reason, but I don't think this will apply in your case.

   

  So, if possible, if your environment is usually sitting in cellular network, likely a TURN server will be quite helpful. Ex: 

  final Map<String, dynamic> configuration = {
    "iceServers": [
      // Public STUN servers from Google
      {'urls': 'stun:stun.l.google.com:19302'},
      {'urls': 'stun:stun1.l.google.com:19302'},
      {'urls': 'stun:stun2.l.google.com:19302'},
  
      // TURN server (commercial or self-hosted, with auth)
      {
        'urls': 'turn:turn.example.com:3478', // sample TURN
        'username': 'yourUsername',
        'credential': 'yourPassword'
      }
    ],
    'sdpSemantics': 'unified-plan',
    // Optional: fallback to TURN only if P2P fails (good for mobile data)
    'iceTransportPolicy': 'all', // or 'relay' for TURN
  };

  and likely you may also consider candidate fallback to TURN for cellular network only,, i.e. 'iceTransportPolicy': 'relay'

   

  Sometime, IPv6 may also affect the connection, you may extend your configuration with IPv6 supported to workaround this case. 

  So far, I assume the case you have is exact as your assumption about the TURN server. Although it is not necessary, but for cellular network  in different regions, the cases might be slightly different .

   

  Hope this helps. Thanks for your understanding.

  0

Please sign in to leave a comment.