Юзер не может публиковать в одной webRTC комнате, но может в других

[alexanderY]

Есть у нас один юзер, с которым уже пару раз наблюдался странный баг.
Юзер заходит в WebRTC комнату, пытается стримить, но у него не получается. В логах "Session not ready". Он тут же переходит на страницу с эхо-тестом - всё работает. Создаем новую комнату, он спокойно стримит там без ошибок.
Перезагружаем сервер и только тогда он может стримить в первой комнате.

Есть пара деталей, не знаю насколько это важно:

1. Это тот же юзер, о котором я писал здесь http://forum.flashphoner.com/threads/web-call-server-play-not-working.10809/#post-12192
2. Не помню, в каком треде я это писал.. Но с этим юзером однажды была проблема, он закрыл браузер, но Флэшфонер считал, будто он еще в комнате, помогла тогда только перезагрузка
3. Как вообще создаются наши мероприятия: у нас в приложении юзер создает мероприятие и назначает дату (допустим, начало через две недели). Юзер может зайти в комнату и проверить, работает ли видео в любой момент, даже за две недели до даты старта. Настраивает некоторые параметры мероприятия и со спокойной душой забывает об этом на две недели. Ну а за 5 минут до начала мероприятия он снова заходит в эту комнату и не может стримить.

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

 

[Max]

Попробуйте узнать IP пользователя или его логин, найти в логах время, когда он коннектился и репортил о проблеме.
Пришлите нам логи за этот час.
Интересны три лога:
1. WCS_HOME/logs/server_logs/flashphoner.log
2. WCS_HOME/logs/flashphoner_manager.log
3. WCS_HOME/logs/client_logs/{date}/{login}
Здесь {date} - дата коннекта к серверу
{login} - имя пользователя, которое использовалось при коннекте.
Для включения третьего лога, нужно убедиться, что эта настройка не выставлена в false в конфиге flashphoner.properties

enable_extended_logging

Если при инициализации API выставить push:true, то сервер будет хранить браузерные логи, которые генерируются на клиенте. Это даст понять, что конкретно происходило у клиента в момент работы с браузером. Лог будет храниться в WCS_HOME/logs/client_logs/{date}/{login} и будет доступен после дисконнекта клиента.

Flashphoner.init({logger:{push:true}});

 

[alexanderY]

Первые два лога отправил. Юзер webinar186-176.
Третий лог включим сегодня, пусть собираются на всякий случай. На данный момент этот лог отключен.

 

[alexanderY]

Для включения логов пришлось немного покопаться в исходнике:

logger: {
            push: true,
            severity: "DEBUG" // без этого параметра Flashphoner не инициализируется, кидает эксепшн
          }

Вдруг кто-то тоже решит включить

 

[Max]

15:52:37,376 ERROR MediaHandler - WS-pool-7-thread-7 playStream actualSession not ready, session name

Из логов видно, что попытка воспроизвести видеопоток происходит в тот момент, когда публикующий юзер еще не установил WebRTC соединение по ICE.
Т.е. по какой-то причине ICE, скорее всего, завис и не прошел.
В третьем логе должно быть лучше видно, что произошло.
Пока третьего лога нет, попробуем воспроизвести у себя на комнатах.

 

[Max]

Предполагаем, что проблема связана с неуникальными именами потоков, которые не успевают освободиться после предыдущей публикации.
Сделали промежуточную сборку Web SDK, в которой имена потоков внутри room уникализированы:
https://github.com/flashphoner/flashphoner_client/commit/cc23f08a14eefb3d2a8e0d6401db8c0faec899af
https://flashphoner.com/downloads/b...23f08a14eefb3d2a8e0d6401db8c0faec899af.tar.gz
Сборка на тестировании.

 

[alexanderY]

Функцию createUUID нужно включить в саму библиотеку, видимо.
Потому что с новой версией сборки "ReferenceError: createUUID is not defined".
Сейчас, на время теста, я её скопирую из examples\demo\dependencies\js\utils.js, но к релизу нужно поправить

 

[alexanderY]

Кстати, не уверен, что проблема связана с неуникальными именами потоков, ну или я неправильно понял.
У нас уже давно генерируются случайные 6-символьные строки как дополнение к id юзера в комнате.
Т.е. совсем давно было: roomName-userID, например webinar123-1 (комната webinar123, юзер с id 1)
Затем мы добавили рандома, стало: roomName-userID-randomString, например webinar123-1-aBcDeF
С вашим обновлением просто длина randomString увеличилась на 4 символа, т.е. webinar123-1-aBcDeFabcd.

При том, что случайная строка генерируется каждый раз при вызове Flashphoner.roomApi.connect. Т.е. даже если один и тот же юзер будет "долбиться" к серверу, имена потоков будут разные.

 

[Max]

Имеется ввиду уникальность имен потоков внутри сессии пользователя.
Если поток называется именем пользователя, например streamName=user_1, и по какой-то причине он не освободился, то вторая публикация такого потока может не пройти.
А если
streamName=user_1_abc
и потом:
streamName=user_1_xyz
то такая ситуация будет исключена.
Мы провели предварительные автоматические тесты на наших стандартных примерах, которые подтвердили, что проблема воспроизводится, когда имена стримов неуникальны (user_1) и не воспроизводится, когда уникальны (user1_xyz).

Сейчас, на время теста, я её скопирую из examples\demo\dependencies\js\utils.js, но к релизу нужно поправить

Это мы исправили в одной из последних сборок
https://github.com/flashphoner/flashphoner_client/commit/52666c67a1b17794611a3b8e6f1660679ea70ab2
Билд на тестировании.

 

[alexanderY]

Что имеется в виду под streamName здесь?
Если взять "стандартный" пример с подключением в комнату:

Flashphoner.init({
          flashMediaProviderSwfLocation: '/flash/media-provider.swf'
        });

...

Flashphoner.roomApi.connect({
    urlServer: self.server,
    username: authUser.id + '-' + stringHelper.randomString(6)
  })

...

self.connection.join({name: self.roomName})

...

self.room.publish({
    display: document.getElementById(displayNodeId),
    constraints: {audio: useAudio, video: useVideo},
    record: true,
    receiveVideo: false,
    receiveAudio: false
  })

То я вижу лишь одну возможность задать streamName (в функции connect), и, как я сказал, вероятность появления неуникальных имен крайне низка.
Мы в любом случае обновимся, когда сборка пройдет ваши тесты, но хочется понимать наверняка, что ошибка именно в этом.

 

[Max]

Имеется в виду имя потока, которое назначается стриму при публикации:
https://github.com/flashphoner/flashphoner_client/blob/wcs_api-2.0/src/room-module.js#L386
options.name

var publish = function(options) {
            options.name = (options.name) ? (name_ + "-" + username_ + "-" + uuid.v1().substr(0,4) + "-" + options.name) : (name_ + "-" + username_ + "-" + uuid.v1().substr(0,4));
            options.cacheLocalResources = (typeof options.cacheLocalResources === "boolean") ? options.cacheLocalResources : true;
            options.custom = {name: name_};
            var stream = session.createStream(options);
            stream.publish();
            return stream;
        };

В стандартном примере выше имя потока не назначается. Оно назначается ниже, в файле room-module.js
И там оно должно быть уникальным.

 

[alexanderY]

ok, благодарю за разъяснение.

 

[Max]

По комнатам были следующие исправления:

Web SDK
Заменили генерацию UUID для стримов
https://github.com/flashphoner/flashphoner_client/commit/52666c67a1b17794611a3b8e6f1660679ea70ab2
Билд Web SDK 52666c67a1b17794611a3b8e6f1660679ea70ab2
Последняя сборка:
flashphoner-api-0.5.18.2241-cd73fa4a24c939c9532dd25fc55ec583f3991f54.tar.gz

Server
2253 - Concurrency баг с одновременным созданием комнаты. Иногда не отображаются потоки.
2251 - Нет видео для нового участника. Регрессия от 2248. Статус не переходил в PUBLISHING.
2248 - Стримы могли рассылаться в статусе не PUBLISHING при создании комнаты. В результате, подключившиеся могли иногда получать FAILED.
Последняя сборка, включающая эти исправления - 2256.

 

[alexanderY]

Ок, обновились. Когда потестируем, я отпишусь.

 

[alexanderY]

Думаю, данную проблему можно считать решенной. Не сталкивались более с ней.