Failed by ICE timeout

Artem

New Member
Добрый день!

На сервере идет несколько стримов. На одном из них часть пользователей начинает отваливаться с ошибкой Failed by ICE timeout и не могут переподключиться. На другом стриме в это время все нормально.

В логах много такого:
0;WebRTC;1813_598952_1589523710306;65a65430-9679-11ea-a627-1bd6a59b8c7d;0;FAILED;Failed by ICE timeout;;SUBSCRIBE;0;/116.203.205.186:49557/10.129.0.5:8443-11220569-c50f-4af5-9bcd-d7ab39a5c50c;
2020-05-15 06:22:12;WebRTC;1813_598952_1589523710306;696a5350-9674-11ea-a616-5993cc011636;00:35:55;PLAYING;;;SUBSCRIBE;0;/89.23.213.157:50035/10.129.0.5:8443-8b351516-6848-4495-a434-bd16c786e07c;
0;WebRTC;1813_598952_1589523710306;682adc30-9679-11ea-9dc9-c7bd4b52beca;0;FAILED;Failed by ICE timeout;;SUBSCRIBE;0;/86.62.69.116:58063/10.129.0.5:8443-2a6c4080-438c-43b9-9d55-112483e9abcc;
0;WebRTC;1813_598952_1589523710306;6a10b330-9679-11ea-8855-d7a12dd17af4;0;FAILED;Failed by ICE timeout;;SUBSCRIBE;0;/94.29.88.41:50016/10.129.0.5:8443-8e11a4d6-4b85-4813-a4fd-28a2a123e751;
0;WebRTC;1813_598952_1589523710306;6adbcb60-9679-11ea-99f0-c1857273d84b;0;FAILED;Failed by ICE timeout;;SUBSCRIBE;0;/95.161.223.72:58431/10.129.0.5:8443-a5114f21-57ce-4b51-990b-cec2417b4cd1;
0;WebRTC;1813_598952_1589523710306;6c56d2a0-9679-11ea-99bc-b737f97d1fe3;0;FAILED;Failed by ICE timeout;;SUBSCRIBE;0;/5.130.49.70:63730/10.129.0.5:8443-bba6dfc7-91be-4137-9dfd-3e182b47c85a;
0;WebRTC;1813_598952_1589523710306;6c98bda0-9679-11ea-8112-21f727380abe;0;FAILED;Failed by ICE timeout;;SUBSCRIBE;0;/37.113.63.148:63007/10.129.0.5:8443-cfb8d443-ba93-45b2-8fc6-3fc199a3b814;
2020-05-15 06:21:50;WebRTC;1813_598952_1589523710306;5ca74420-9674-11ea-8f8c-e3dcaa920c24;00:36:45;FAILED;Stopped by session disconnect;;PUBLISH;159;/91.192.21.3:49622/10.129.0.5:8443-907158f7-2566-4f31-8f53-a059ec51c91a;

В чем может заключаться ошибка?
ЗЫ: отправил доступы к серверу на суппорт почту если требуется посмотреть логи/настройки
 

Max

Administrator
Staff member
Добрый день.
Попробуйте выставить настройку
Code:
dtls_close_socket_after_tries=30
 

Max

Administrator
Staff member
Failed by ICE timeout

Эта ошибка создания WebRTC сессии. Браузер отправляет UDP пакеты (ICE binding) на сервер. Сервер отвечает на эти запросы.
Если браузер долго не присылает пакеты, сессия завершается по ICE timeout.

Одна из причин, по которой это может происходить, у подключившихся зрителей проблема с UDP пакетами. Например UDP трафик закрыт полностью или настроен корпоративный NAT, который мешает передаче пакетов. В этом случае, можно попробовать использовать TCP транспорт. Если IP-адреса зрителей заранее известны, можно поставить их на отладку и собрать логи их сессий по IP.

CLI v2
Code:
connection debug-add -a 192.168.1.100
В этом случае, если у конкретного зрителя не проходит подключение, мы сможем по логам понять точную причину.
 

Artem

New Member
Добрый день!

Клиентские логи:
https://gist.github.com/skid-rock/fb7bb3de5707c5be8d61205c794e1e4b
https://gist.github.com/skid-rock/9a6b8f217accb9164b68ade98b4dc046

Серверные:

Вообще проблема стала проявляться следующим образом: сначала все нормально работает, затем в какой-то момент под небольшой нагрузкой все стримы на сервере обрываются, новые не создаются вне зависимости от клиента (у нас два сервера, ко второму в это время можно спокойно подключиться и начать стрим). Ошибка все та же - Failed by ICE timeout. Помогает перезагрузка на сервере.
 

vasyap

New Member
Обратите внимание, в этой ситуации подключиться не может не зритель, а вещатель.
 

Max

Administrator
Staff member
По-умолчанию
Code:
ice_timeout = 15

Если 15 секунд нет UDP пакетов от браузера в сторону сервера, соединение завершается.
В логах, которые вы собрали, показано именно это.

Основных варианта два:

1. Перестал ходить UDP трафик. Например, закрыты порты или закрылся NAT и не дает
Порты 35738, 35740

Решение: снять pcap дамп и найти, почему не доходят UDP пакеты

Решение: переключиться на TCP. В этом случае непрохождение UDP будет исключено.
 

vasyap

New Member
Решение: переключиться на TCP. В этом случае непрохождение UDP будет исключено.
Боюсь, это нам не подойдет, слишком высокие нагрузки ожидаются.

Решение: снять pcap дамп и найти, почему не доходят UDP пакеты
Можно подробнее, чем и как конкретно (в случае WireShark) нужно снимать дамп? Нужно ли это делать на стороне клиента (публишера) или на стороне FlashPhoner'а?
 

vasyap

New Member
На стороне клиента (вещателя) STUN трафик выглядит проблемно: несколько подряд Binding Request user, после них - Destination Unreachable (Communication Administratively filtered).

При этом час-полтора назад этот клиент вещал нормально из этих же условий.

С чем может быть связана проблема?
 

vasyap

New Member
Вот скрин:

unknown.png

Проблема явно не на клиенте - этот же клиент к другому серверу подключается мгновенно, сессия сразу же стартует.

В чем еще может быть проблема?
 

vasyap

New Member
А вот так это выглядит на сервере:

Аннотация 2020-05-21 161445.png

Т.е. очевидно от клиента к серверу пакеты ходят, а вот обратно даже не отправляются. Похоже, дело все-таки во FlashPhoner'e.
 

Max

Administrator
Staff member
Снимете, пожалуйста, полные логи (скрипт report.sh) и дамп (tcpdump) на стороне сервера. Выслать можно на support@flashphoner.com.

сначала все нормально работает, затем в какой-то момент под небольшой нагрузкой все стримы на сервере обрываются, новые не создаются вне зависимости от клиента
Какая нагрузка на сервер?
 

Max

Administrator
Staff member
10.129.0.5 - это какое устройство? Оно говорит, что пакет зафильтрован.
Если это коммутатор или другое сетевое устройство, отличное от WCS, то дело в нем.
https://www.reddit.com/r/Cisco/comments/b30yyx
Если 10.129.0.5 - это WCS, то нет ли на нем файрволов и фильтров, которые ограничивают UDP трафик на порты, указанные в настройках flashphoner.properties

Вы можете проверить доступность конкретных портов, например 35738, 35740 утилитой nc.
 

vasyap

New Member
Похоже, конкретно эта проблема действительно заключалась в фаерволе, извините.

Однако вопрос - почему отваливаются уже подключенные клиенты (в т.ч. спикер)?
 

Max

Administrator
Staff member
Однако вопрос - почему отваливаются уже подключенные клиенты (в т.ч. спикер)?
Спикер также отпраляет трафик по UDP портам, например 35742, 35744.
Если эти порты перестают принимать трафик, то видео перестанет идти, а сессия ICE будет разорвана по таймауту, т.к. клиент и сервер должны обмениваться "keep alive" UDP пакетами на протяжении всей сессии.
 
Top