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

Discussion in 'Web Call Server 5' started by alexanderY, Apr 25, 2017.

  1. alexanderY

    alexanderY Member

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

    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. Его тоже пришлите пожалуйста.
  3. alexanderY

    alexanderY Member

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

    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, попробуем развернуть у себя на стенде и прогнать нагрузочный тест на предмет сбросов соединений.
  5. alexanderY

    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";
    }


    }
  6. Max

    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).
  7. alexanderY

    alexanderY Member

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

    Max Administrator Staff Member

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

    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
  10. Max

    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. Т.е. потоки не найдены.
    Если у вас воспроизводится, дайте пошаговое воспроизведение. Проверим.
  11. pride

    pride Member

    Мы вещаем поток из Флеш.
    Смотрим 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",
    
  12. Max

    Max Administrator Staff Member

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

    Max Administrator Staff Member

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

    pride Member

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

Share This Page