CODEWITHSUNDEEP
ioswebrtc
skorulis
skorulis

Reputation: 4381

WebRTC on iOS ice connection state stuck

I am developing an iOS app using WebRTC for peer to peer data communications with RTCDataChannel. I've managed to get everything working when both devices are on the same wifi network but when I put 1 on a mobile network the connection seems to stall and I can't tell what's wrong. Looking at the logs from different runs, everything is identical up until the point where it stops. I'm not sure what to do at this point since there's no errors. I swear at one point this was working but it's been a long time since I've tested outside my local network. Here's an example of my log output, any ideas what I could 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

Upvotes: 4

Views: 3586

Answers (1)

Nuri
Nuri

Reputation: 46

If you use your both clients behind symetric NAT, STUN will not able to handle this. So, you should use TURN for communicate behind symetric NATs.

Upvotes: 3

Related Questions