WebRTC Mobile - Audio not working unless on same wifi

user_7129932 0
Viewed 520

I am using react-native-webrtc to handle the WebRTC portion of this. I am using Websockets to signal and using ICE trickling to keep track of the ICE candidates.

I queue my ICE candidates until setLocalDescription has been called on the callee side. Then I addIceCandidate for each candidate in the queue.

On the caller side I am doing the same thing and not processing my ICE candidates until setRemoteDescription has been called.

I am only doing audio so no video being used.

When I test this with two mobile devices on the same network I have no issues.

But if I disconnect one device from the WiFi the calls still connect just fine except the audio cannot be heard on either device.

The onConnectionStateChange handler will still return "connected" and the onIceGatheringStateChanged will still return "complete".

I thought maybe I needed to use a TURN server to get this working so I started using Twilio's paid TURN/STUN server but the issue is still persisting.

Any ideas what to look into?

turn webrtc react-native node.js websocket
1 Answers

BACKGROUND

Ok, so you have to take some background on P2P connection on RTC platforms. And so, it begins (in very short version):

  • In order to establish connection you have to establish direct connection between two clients (how obviously, I know). In order to find this routes you need help on network servers.

  • And that's why you setup local SDP with setting, to which server we can access. ICE, TURN, STUN (you can find any information, for ex. this one). Now ICE candidates most obvious one, because this server endpoints within your local network and that's why your version is not working with different network.

  • Right, you have to use TURN/STUN to find NAT and correct routes between peers. Most TURN server are private and paid, but for less loaded application you might use public STUN servers, that would be more then enough.

You can find many available over there. One ex. is here.

stun.l.google.com:19302
stun1.l.google.com:19302
stun2.l.google.com:19302

SOLUTION

Now coming to your problem. If you think you have connected your devices with your signaling it doesn't mean you connected devices. (It's just to clarify, if you don't have media on your devices your RTC connection failed to establish, and it's not just audio).

The problem in using it's TURN/STUN servers on your devices, and you have to trace SDP which established during setRemoteDescription and check the servers were included. Furthermore there is always a Google demo which is working perfectly.

UPDATE

In order to trace how remote SDP will be set and connection establish oyu have to print candidates which will be used to setup. To do that, you have to print information which candidates gathered during setLocalDescription and setRemoteDescription.

In place where you are gathering candidates add logging to print information. You have to see, that STUN, TURN candidates will be there. Below ex in Java. Word ICE shouldn't bother you, because it's just means that candidates AFTER ICE traversing will be found.

// Listen for local ICE candidates on the local RTCPeerConnection
peerConnection.addEventListener('icecandidate', event => {
    if (event.candidate) {
        // Here should be your part where you are sending this candidate to your signaling channel

        // Add logging to print entire candidate information. You should see some data related to ICE, TURN. 
    }
});
user_41333010
Related