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

alexanderY · Apr 25, 2017

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

Max · Apr 25, 2017

Это скорее статус. Означает что воспроизведение потока было остановлено из-за того что была закрыта публикующая сессия.
Т.е. говорит, что пользователь перестал вещать и отключился.
Это может произойти по двум причинам:
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 · Apr 27, 2017

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

Max · Apr 27, 2017

По логам удалось понять, что коннекты 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 · Apr 28, 2017

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 · Apr 28, 2017

Да, если логины уникальные, то ничего не мешает увеличить интервалы для 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 · Apr 28, 2017

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

Max · May 2, 2017

Вы же имеете в виду прописать http://127.0.0.1:8080, не https?

Да, HTTP. Ощутимого прироста производительности это не даст, но уберет лишнюю сложность с повторным шифрованием / дешифрованием.

pride · May 16, 2017

Заметил, что при публикации потока, после дисконнекта в 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 · May 16, 2017

У нас со сборкой 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 · May 17, 2017

Max said:
У нас со сборкой 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 · May 17, 2017

Мы вещаем поток из Флеш.
Смотрим WEBRTC.
Закрываем Флеш.
Висяк WEBRTC.

Да, так воспроизводится в последней сборке 2226. Попробуем исправить.

Max · May 18, 2017

Исправлено в сборке 2232.

pride · May 21, 2017

Max said:
Исправлено в сборке 2232.

Благодарю, проблема исчезла.

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

alexanderY

Member

Max

Administrator

alexanderY

Member

Max

Administrator

alexanderY

Member

Max

Administrator

alexanderY

Member

Max

Administrator

pride

Member

Max

Administrator

pride

Member

Max

Administrator

Max

Administrator

pride

Member