WebRTC on iOS ice connection stuck

I am developing an iOS application using WebRTC

peer-to-peer data transfer with RTCDataChannel. I managed to get everything to work when both devices are on the same Wi-Fi network, but when I put 1 on the mobile network, the connection seems to stop and I can't tell what happened. Looking at the logs from different runs, everything is the same up to the point where it stops. I'm not sure what to do at this point as there are no errors. I swear it worked at some point, but it's been a long time since I tested my LAN. Here is an example of my log output, any ideas what I might be doing wrong?

Device A

20:07:47.653  Sending SDP offer
20:07:47.653  ICE gathering changed 1
20:07:48.067  ICE gathering changed 2
20:07:48.068  Sending ice: data:0:candidate:3022624816 1 udp 2122260223 192.168.1.4 54049 typ host generation 0
20:07:48.071  Sending ice: data:0:candidate:4205470912 1 tcp 1518280447 192.168.1.4 51226 typ host tcptype passive generation 0
20:07:48.073  Sending ice: data:0:candidate:494278629 1 udp 1686052607 14.---.---.208 54049 typ srflx raddr 192.168.1.4 rport 54049 generation 0
20:08:09.448  Answer from NxblUpoB1F7q
20:08:09.452  SIGNAL STATE CHANGE 0
20:08:09.454  ICE connection changed 1
20:08:09.986  ICE candidate was added 1
20:08:10.335  ICE candidate was added 1
20:08:10.338  ICE candidate was added 1
20:08:10.340  ICE candidate was added 1
20:08:10.342  ICE candidate was added 1
20:08:10.345  ICE candidate was added 1
---- When not on the same network things stop here ----
20:08:10.638  ICE connection changed 2
20:08:10.639  ICE connection changed 3
20:08:10.642  Channel did change state 1
20:08:10.644  Connection active

      

Device B

20:08:07.753 Offer from AJcoXH6EtM3etg==
20:08:07.843 SIGNAL STATE CHANGE 3
20:08:07.848 SIGNAL STATE CHANGE 0
20:08:07.851 Sending SDP answer
20:08:07.851 ICE gathering changed 1
20:08:08.245 ICE connection changed 1
20:08:08.245 ICE candidate was added 1
20:08:08.247 ICE candidate was added 1
20:08:08.249 ICE candidate was added 1
20:08:08.378 ICE gathering changed 2
20:08:08.378 Sending ice candidate data:0:candidate:211156821 1 udp 2122260223 192.168.1.5 64361 typ host generation 0
20:08:08.380 Sending ice: data:0:candidate:3923309006 1 udp 2122194687 10.---.---.220 50007 typ host generation 0
20:08:08.381 Sending ice: data:0:candidate:1108738981 1 tcp 1518280447 192.168.1.5 58785 typ host tcptype passive generation 0
20:08:08.383 Sending ice: data:0:candidate:2807762238 1 tcp 1518214911 10.---.---.220 58786 typ host tcptype passive generation 0
20:08:08.384 Sending ice: data:0:candidate:1754331002 1 udp 1685987071 1.---.---.24 29841 typ srflx raddr 10.165.91.220 rport 50007 generation 0
20:08:08.385  Sending ice: data:0:candidate:2781507712 1 udp 1686052607 14.203.230.208 64361 typ srflx raddr 192.168.1.5 rport 64361 generation 0
---- When not on the same network things stop here ----
20:08:09.428 ICE connection changed 2
20:08:09.443 Opened data channel ordered 1 reliable 1
20:08:09.445 Channel did change state 1
20:08:09.446 RTC Connection did change state 3
20:08:09.447  Connection active

      

+3


source to share


1 answer


If you are using both of your clients behind symmetric NAT, STUN will not be able to handle this. Thus, you must use TURN to communicate behind symmetric NATs.



+2


source







All Articles