3
Я разрабатываю приложение iOS, используя WebRTC для обмена данными между одноранговыми узлами с RTCDataChannel. Мне удалось заставить все работать, когда оба устройства находятся в одной сети Wi-Fi, но когда я помещаю 1 в мобильную сеть, соединение, похоже, останавливается, и я не могу сказать, что случилось. Глядя на журналы с разных прогонов, все одинаково вплоть до момента, когда он останавливается. Я не уверен, что делать в этот момент, поскольку ошибок нет. Клянусь, в какой-то момент это работало, но прошло много времени с тех пор, как я тестировал свою локальную сеть. Вот пример моего вывода журнала, любые идеи, что я могу сделать неправильно?WebRTC на состояние соединения со льдом iOS
Устройство 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
Устройство 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
Просто сделал быструю проверку на моей сети Wi-Fi, где я только отправляю srflx заявки на получение льда. Это приводит к тому, что состояние соединения льда на устройстве A изменяется на «Сбой», тогда как устройство B работает одинаково. отправка только ледяных кандидатов хост-класса создает рабочее соединение. Не уверен, что это помогает – skorulis
вы используете серверы STUN и TURN? , если одноранговые узлы не находятся в одной сети, вам понадобится оглушающий сервер для установления соединения (srflx ice-кандидаты являются кандидатами, использующими оглушающий сервер). Также, если оба пэра находятся за симметричным nat, вам понадобится сервер очереди для ретрансляции соединения (релейные ледяные кандидаты - это кандидаты, которые используют сервер очереди). –
Я просто использовал STUN-серверы, которые, как мне казалось, были бы достаточными, поскольку они работали до этого. Теперь я добавил сервер TURN, который снова заработал. Я думаю, мне нужно провести еще несколько тестов с другими службами STUN, чтобы увидеть, показывают ли они ту же проблему. – skorulis