Failed by ICE keep alive

Дмитрий

New Member
Добрый день!
У некоторых клиентов, в основном удаленных и использующих Firefox при попытке воспроизведения стрима появляется ошибка.
Chrome работает нормально.

12:04:40,927 INFO agerRemoteRmiService - RMI TCP Connection(19)-127.0.0.1 RECEIVED REST OBJECT <==
URL:http://localhost:9091/RoomApp/StreamStatusEvent
OBJECT:
{
"nodeId" : "rwsOG4CIdJqngsXqdBeSMwhKrQCS8lsi@192.168.150.15",
"appKey" : "roomApp",
"sessionId" : "/192.168.225.1:51438/192.168.150.15:8443",
"mediaSessionId" : "f803f300-57f2-11e7-9432-b947bb37fbeb",
"name" : "stand000001stream",
"published" : false,
"hasVideo" : true,
"hasAudio" : true,
"status" : "FAILED",
"info" : "Failed by ICE keep alive",
"record" : false,
"width" : 386,
"height" : 290,
"bitrate" : 0,
"quality" : 0,
"mediaProvider" : "WebRTC"
}
12:04:45,929 INFO agerRemoteRmiService - RMI TCP Connection(19)-127.0.0.1 SEND REST OBJECT ==>
URL:http://localhost:9091/RoomApp/StreamStatusEvent
OBJECT:
{
"nodeId" : "rwsOG4CIdJqngsXqdBeSMwhKrQCS8lsi@192.168.150.15",
"appKey" : "roomApp",
"sessionId" : "/192.168.225.1:51438/192.168.150.15:8443",
"mediaSessionId" : "f803f300-57f2-11e7-9432-b947bb37fbeb",
"name" : "stand000001stream",
"published" : false,
"hasVideo" : true,
"hasAudio" : true,
"status" : "FAILED",
"info" : "Failed by ICE timeout",
"record" : false,
"width" : 386,
"height" : 290,
"bitrate" : 0,
"quality" : 0,
"mediaProvider" : "WebRTC"
}
 

Max

Administrator
Staff member
Пришлите пожалуйста полные логи на logs@flashphoner.com
1. logs/server_logs/flashphoner.log
2. logs/flashphoner_manager.log
3. logs/client_logs/2017-06-23/{login}
Здесь login - логин пользователя
2017-06-23 - дата записи логов
Логин пользователя можно найти в том же файле (logs/flashphoner_manager.log), кусок которого вы опубликовали.
В вызове REST метода:
http://localhost:9091/RoomApp/connect
4. Кроме этого, пришлите папку conf с настройками сервера.
 

Max

Administrator
Staff member
Эта ошибка, как правило, возникает когда UDP пакеты от клиента не доходят до сервера и обратно.
Например, если между клиентом и сервером есть firewall, блокирующий UDP пакеты.
Из логов видно, что клиент соединяется с сервером с IP адреса 192.168.225.3.
И далее нет успешного обмена UDP пакетами.

Если есть возможность совместного тестирования с клиентом
1. Проверьте простое воспроизведение потока.
Опубликовать поток с такой страницы, а потом с этой же страницы воспроизвести клиенту.
https://wcs5-eu.flashphoner.com/cli...ming/two_way_streaming/two_way_streaming.html
2. Проверьте, проходит ли UDP трафик от клиента.
На сервере нужно вызвать
tcpdump host 192.168.225.3 -s 4096 -w log.pcap
Здесь 192.168.225.3 - IP адрес клиента.
Пришлите нам этот log.pcap файл.
3. Проверьте, будет ли работать воспроизведение в этом примере:
https://wcs5-eu.flashphoner.com/demo2/firewall-traversal-streaming
Здесь весь трафик будет идти через наш TURN сервер по порту 443.
Если здесь работает, то скорее всего проблема в блокировке UDP портов.

Единственное, что не стыкуется, вы говорите, что в Chrome работает нормально.
Т.е. тот же самый пользователь нормально работает в Chrome, но в Firefox возникают проблемы?

Мы протестирвали вашу сборку 2289 в Chrome и FF. Проблем нет. Публикуется и воспроизводится.
 

Дмитрий

New Member
Попробуем. Проблема возникает только на свежеустановленном Firefox (или если удалить профиль в Firefox) и на слабых каналах.
 

Дмитрий

New Member
В логе с адреса 192.168.200.1 сначала не работает Firefox, потом работает Chome с той же машины. Проблема возникает только на свежеустановленном Firefox и только если воспроизводить поток, опубликованный с другой машины. Если Firefox "дернуть", например опубликовав с данной машины поток, он начинает работать и работает дальше без проблем. Дополнение: только на машинах , работающих с программной VPN Cisco AnyConnect. В RoomApi все работает нормально, не работает только воспроизведение потока, опубликованного с другой машины.
 

Attachments

Last edited:

Max

Administrator
Staff member
Нам удалось воспроизвести проблему.
Если вызвать на Windows:
Code:
firefox.exe -P
и удалить профиль default, то Firefox действительно перестает играть видео.
Возможно, внутренняя проблема Firefox, связанная с кодеком H.264.
При переключении на кодек VP8, Firefox играет видео.
Попробуйте в конфиге сервера flashphoner.properties выставить приоритет vp8,h264
Code:
codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,h264,flv,mpv
 

Дмитрий

New Member
Попробовал. Не полегчало. А не может это быть связано с VPN Cisco AnyConnect ? И еще: В RoomApi все работает нормально. И поток потом воспроизводиться хорошо. И после публикации потока с этой машины все потом воспроизводится. Т.е. единожды заработав, долее работает хорошо
 
Last edited:

Max

Administrator
Staff member
Пришлите пожалуйста SSH доступ к серверу WCS
logs@flashphoner.com

Мы проведем несколько тестов и посмотрим, воспроизводится ли с Firefox с нашей стороны.
Code:
А не может это быть связано с VPN Cisco AnyConnect ?
Если WCS сервер находится под VPN, то должен работать нормально, но опять же зависит от настроек VPN.
Например, если пакеты больше чем MTU, соединение через VPN может не проходить.
 

Дмитрий

New Member
На всякий случай посылаю 2 капчи с машины, на которой работает Chrome и не работает Firefox. Фильтр лучше по адресу 192.168.150.15 (это WSC). На рабочей станции 2 интерфейса: один реальный 172.16.220.13, другой - виртуальный интерфейс Cisco AnyConnect 192.168.200.5, через который и должно работать. При согласовании STUN Chrome "понимает" интерфейс Cisco AnyConnect, а Firefox похоже нет.
 

Attachments

Max

Administrator
Staff member
По дампам видно следующее.
Chrome использует для отправки адрес 192.168.200.5 и поэтому работает.
FF использует для отправки адрес VPN 172.16.220.13 и поэтому не работает.
Если у вас все пользователи находятся в VPN, попробуйте на стороне WCS сервера выставить VPN IP адрес в конфиге flashphoner.properties
ip=172.16.220.12
ip_local=0.0.0.0
Здесь 172.16.220.12 - адрес WCS сервера внутри VPN сети.
Эта настройка требует перезагрузки WCS.
Code:
service webcallserver restart
 

Дмитрий

New Member
Это я понял. Непонятно, почему:
"Проблема возникает только на свежеустановленном Firefox и только если воспроизводить поток, опубликованный с другой машины. Если Firefox "дернуть", например опубликовав с данной машины поток, он начинает работать и работает дальше без проблем. Дополнение: только на машинах , работающих с программной VPN Cisco AnyConnect.
Проблема Firefox?
З.Ы. К сожалению, не все пользователи под VPN......
 

Max

Administrator
Staff member
Проблема Firefox?
Проблема в следующем.
WCS показывает браузеру двух кандидатов
1) Из настройки ip
2) Из настройки ip_local

Выглядят они так:
Code:
a=candidate:1 1 udp 2130706431 192.168.150.15 31228 typ host
a=candidate:1 2 udp 2130706431 192.168.150.15 31228 typ host
А вот полный SDP:
Code:
o=Flashphoner 0 1498226795546 IN IP4 192.168.150.15
s=Flashphoner/1.0
c=IN IP4 192.168.150.15
t=0 0
m=audio 31226 RTP/SAVPF 0 8
c=IN IP4 192.168.150.15
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
a=ice-pwd:2sjj8k8e42hl9fv9f8epdqumlb
a=ice-ufrag:26eb2510-581d-11e7-b173-032de2e56989566lf1bjakd90b
a=fingerprint:SHA-256 EC:7C:68:EA:F7:E3:98:7F:22:08:0D:70:52:91:27:47:B2:ED:FA:C9:19:A3:E3:CA:8C:0A:C3:EC:52:13:9D:9C
a=candidate:1 1 udp 2130706431 192.168.150.15 31226 typ host
a=candidate:1 2 udp 2130706431 192.168.150.15 31226 typ host
a=rtcp-mux
a=rtcp:31226 IN IP4 192.168.150.15
a=sendonly
a=ssrc:617356316 cname:rtp/audio/26eb2510-581d-11e7-b173-032de2e56989
m=video 31228 RTP/SAVPF 100 96
c=IN IP4 192.168.150.15
a=rtpmap:100 H264/90000
a=fmtp:100 level-asymmetry-allowed=1; packetization-mode=1; profile-level-id=42e01f
a=rtpmap:96 VP8/90000
a=rtcp-fb:* ccm fir
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* goog-remb
a=ice-pwd:2sjj8k8e42hl9fv9f8epdqumlb
a=ice-ufrag:26eb2510-581d-11e7-b173-032de2e56989566lf1bjakd90b
a=fingerprint:SHA-256 EC:7C:68:EA:F7:E3:98:7F:22:08:0D:70:52:91:27:47:B2:ED:FA:C9:19:A3:E3:CA:8C:0A:C3:EC:52:13:9D:9C
a=candidate:1 1 udp 2130706431 192.168.150.15 31228 typ host
a=candidate:1 2 udp 2130706431 192.168.150.15 31228 typ host
a=rtcp-mux
a=rtcp:31228 IN IP4 192.168.150.15
a=sendonly
a=ssrc:1563111069 cname:rtp/video/26eb2510-581d-11e7-b173-032de2e56989
Если бы WCS показал так (c VPN адресом), то скорее всего все бы заработало:
Code:
a=candidate:1 1 udp 2130706431 192.168.150.15 31228 typ host
a=candidate:1 2 udp 2130706431 172.16.220.12 31228 typ host
Но есть сомнения, что удастся забиндиться на VPN адрес 172.16.220.12, если проставить его в настройке ip_local.

Попробуйте
так
Code:
ip=172.16.220.12
ip_local=192.168.150.15
и так
Code:
ip=192.168.150.15
ip_local=172.16.220.12
 
Top