Что означает ошибка "Publish session closed"?

alexanderY

Member
Случайным образом пользователи в комнате вдруг перестают вещать. В логах есть FAILED с описанием "Publish session closed".
Рестарт Фонера не помогает.
Билд 2175.
 

Max

Administrator
Staff member
Это скорее статус. Означает что воспроизведение потока было остановлено из-за того что была закрыта публикующая сессия.
Т.е. говорит, что пользователь перестал вещать и отключился.
Это может произойти по двум причинам:
1) Дисконнект Websocket.
2) Дисконнект WebRTC ICE.
Пришлите:
1. ID сессий, которые отвалились
2. Логи flashphoner_manager.log, server_logs/flashphoner.log
3. Конфиги из /conf
на logs@flashphoner.com
Проверим из-за чего мог быть дисконнект.
Статистика стримов также пишестя в файл:
/usr/local/FlashphonerWebCallServer/logs/cdr/sdr.log
4. Его тоже пришлите пожалуйста.
 

alexanderY

Member
Добрый день.
Есть новости? Логи вчера выслал, забыл отписаться здесь.
 

Max

Administrator
Staff member
По логам удалось понять, что коннекты websocket отключаются по keep alive.
Рекомендации:
1. Обновиться до последней версии сервера
Включить лог в конфиге log4j.properties
Code:
log4j.logger.WSClients=DEBUG
2. Если используется HA proxy, включить лог ha proxy http://kvz.io/blog/2010/08/11/haproxy-logging/
Если подробно опишете ваш deployment, попробуем развернуть у себя на стенде и прогнать нагрузочный тест на предмет сбросов соединений.
 

alexanderY

Member
1. Сделаем.
2. Не используется.

Мы же уменьшали настройки keep_alive в server.properties. Возможно стоит вернуть обратно? Тем более, что мы все-таки реализовали уникальные логины для каждого подключения.

Описываю deployment.
  • Сервер в scaleway (4 Dedicated x86 64bit Cores / 8GB Memory 300Mbit/s / Unmetered bandwidth) на Ubuntu 16.04
  • Флэшфонер находится за nginx'ом (конфиг ниже в спойлере)
  • ssl от letsencrypt, сертификаты импортировали по вашей инструкции
  • вроде всё? спрашивайте, если что-то еще нужно.
map $http_upgrade $connection_upgrade{
default Upgrade;
'' close;
}


server {
listen 80 default_server;
listen [::]:80 default_server;
server_name subdomain.domain.tld;
return 301 https://$server_name$request_uri;
}

server {

# SSL configuration
#
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
include snippets/subdomain.domain.tld.conf;
include snippets/ssl-params.conf;

root /var/www/html;

# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;

server_name subdomain.domain.tld;

location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
#try_files $uri $uri/ =404;
add_header X-Frame-Options SAMEORIGIN;
proxy_pass http://127.0.0.1:9091;
proxy_hide_header X-Frame-Options;
}

location /socket {
proxy_pass https://127.0.0.1:8443;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}


}
 

Max

Administrator
Staff member
Да, если логины уникальные, то ничего не мешает увеличить интервалы для keep alive.
Попробуем у себя поднять nginx с похожим проксированием websockets и провести похожий тест.
По конфигу все выглядит корректно.
Здесь похоже на избыточное шифрование:
Code:
proxy_pass https://127.0.0.1:8443;
Возможно есть смысл настроить так:
Code:
proxy_pass https://127.0.0.1:8080;
Насколько я понимаю, nginx уже принимает https на порту 443, поэтому нет смысла шифровать локально и можно использовать 8080(ws) вместо 8443(wss).
 

alexanderY

Member
Откатил настройки keepalive к дефолтным, в течение нескольких дней соберем "проблемных" юзеров в одной комнате, потестируем.
Вы же имеете в виду прописать http://127.0.0.1:8080, не https? Прописал, работает, спасибо за совет, действительно нет смысла второй раз шифровать.
 

Max

Administrator
Staff member
Вы же имеете в виду прописать http://127.0.0.1:8080, не https?
Да, HTTP. Ощутимого прироста производительности это не даст, но уберет лишнюю сложность с повторным шифрованием / дешифрованием.
 

pride

Member
Заметил, что при публикации потока, после дисконнекта в http://server:9091/rest-api/connection/find_all соединения пропадают, а вот вижу висяки такого вида:
[
{
"custom":{},
"nodeId":null,
"appKey":"flashStreamingApp",
"sessionId":"8c12eaa7-8648-48c6-bd25-cf862e5dae01",
"mediaSessionId":"1352128c12eaa7-8648-48c6-bd25-cf862e5dae01",
"remoteMediaElementId":null,
"name":"135212",
"published":false,
"hasVideo":true,
"hasAudio":true,
"status":"FAILED",
"sdp":null,
"info":"Publish session closed",
"record":false,
"recordName":null,
"width":0,
"height":0,
"bitrate":0,
"quality":0,
"rtmpUrl":null,
"streamInfo":{
"custom":{},
"nodeId":null,
"appKey":null,
"sessionId":null,
"mediaSessionId":"1352128c12eaa7-8648-48c6-bd25-cf862e5dae01",
"name":"135212",
"samplingTime":null,
"recordTimestamp":null,
"recordStarted":false
},
"mediaProvider":"Flash"
},
{
"custom":{
"custom":{
"user":"135231",
"token":"tadi9nenpp45q2u9fpu9jlcqo4",
"broadcast":"121212"
}
},
"nodeId":null,
"appKey":"stream",
"sessionId":"/127.0.0.1:57568/127.0.0.1:8443",
"mediaSessionId":"76cd0a50-3a16-11e7-a948-551d900fc400",
"remoteMediaElementId":null,
"name":"135212",
"published":false,
"hasVideo":true,
"hasAudio":true,
"status":"FAILED",
"sdp":null,
"info":"Publish session closed",
"record":false,
"recordName":null,
"width":0,
"height":0,
"bitrate":0,
"quality":0,
"rtmpUrl":null,
"streamInfo":{
"custom":{},
"nodeId":null,
"appKey":null,
"sessionId":null,
"mediaSessionId":"76cd0a50-3a16-11e7-a948-551d900fc400",
"name":"135212",
"samplingTime":null,
"recordTimestamp":null,
"recordStarted":false
},
"mediaProvider":"WebRTC"
},
{
"custom":{
"custom":{
"user":"135231",
"token":"tadi9nenpp45q2u9fpu9jlcqo4",
"broadcast":"121212"
}
},
"nodeId":null,
"appKey":"stream",
"sessionId":"/127.0.0.1:57568/127.0.0.1:8443",
"mediaSessionId":"ff8ade10-3a13-11e7-a948-551d900fc400",
"remoteMediaElementId":null,
"name":"135214",
"published":false,
"hasVideo":true,
"hasAudio":true,
"status":"FAILED",
"sdp":null,
"info":"Publish session closed",
"record":false,
"recordName":null,
"width":0,
"height":0,
"bitrate":0,
"quality":0,
"rtmpUrl":null,
"streamInfo":{
"custom":{},
"nodeId":null,
"appKey":null,
"sessionId":null,
"mediaSessionId":"ff8ade10-3a13-11e7-a948-551d900fc400",
"name":"135214",
"samplingTime":null,
"recordTimestamp":null,
"recordStarted":false
},
"mediaProvider":"WebRTC"
}
]
И таких 10 записей. Которые пропадут только после перезагрузки WCS
 

Max

Administrator
Staff member
У нас со сборкой 2224 такая проблема не воспроизводится.
Тестируем так:
1. Отправляем поток с WebRTC - Two Way Streaming.
https://wcs5-eu.flashphoner.com/demo2/two-way-streaming
2. Играем этот поток в Flash - Flash Streaming.
https://wcs5-eu.flashphoner.com/demo2/flash-streaming
3. Закрываем вкладку с WebRTC.
4. Выводим список стримов REST-командой find_all
Code:
http://192.168.88.59:9091/rest-api/stream/find_all
В результате все чисто. REST возвращает 404 Not Found. Т.е. потоки не найдены.
Если у вас воспроизводится, дайте пошаговое воспроизведение. Проверим.
 

pride

Member
У нас со сборкой 2224 такая проблема не воспроизводится.
Тестируем так:
1. Отправляем поток с WebRTC - Two Way Streaming.
https://wcs5-eu.flashphoner.com/demo2/two-way-streaming
2. Играем этот поток в Flash - Flash Streaming.
https://wcs5-eu.flashphoner.com/demo2/flash-streaming
3. Закрываем вкладку с WebRTC.
4. Выводим список стримов REST-командой find_all
Code:
http://192.168.88.59:9091/rest-api/stream/find_all
В результате все чисто. REST возвращает 404 Not Found. Т.е. потоки не найдены.
Если у вас воспроизводится, дайте пошаговое воспроизведение. Проверим.
Мы вещаем поток из Флеш.
Смотрим WEBRTC.
Закрываем Флеш.
Висяк WEBRTC.
Code:
"nodeId": null,
"appKey": "stream",
"sessionId": "/10.10.10.159:34464/10.10.10.191:8443",
"mediaSessionId": "32666f00-3af2-11e7-a22b-05dc1db271ba",
"remoteMediaElementId": null,
"name": "135212",
"published": false,
"hasVideo": true,
"hasAudio": true,
"status": "FAILED",
"sdp": null,
"info": "Publish session closed",
"record": false,
"recordName": null,
"width": 0,
"height": 0,
"bitrate": 0,
"quality": 0,
"rtmpUrl": null,
"streamInfo": {},
"nodeId": null,
"appKey": null,
"sessionId": null,
"mediaSessionId": "32666f00-3af2-11e7-a22b-05dc1db271ba",
"name": "135212",
"samplingTime": null,
"recordTimestamp": null,
"recordStarted": false,
"mediaProvider": "WebRTC",
 

Max

Administrator
Staff member
Мы вещаем поток из Флеш.
Смотрим WEBRTC.
Закрываем Флеш.
Висяк WEBRTC.
Да, так воспроизводится в последней сборке 2226. Попробуем исправить.
 
Top