Summary

When WebSocket reconnection occurs for all users connected to the Room due to network-related lag on the server, the MediaStreamSettings of these clients may appear to be broken. Consequently, after the reconnection, device_video becomes disabled, and display_video becomes enabled, leading to screen sharing being activated for all users. This behavior seems to indicate a potential bug in our reactive state synchronization mechanism triggered during WebSocket reconnection through a full state update. However, certain aspects do not look related to this mechanism, so a more in-depth investigation needed.

Platform information

Not platform specific.

Steps to reproduce

1. Start group call
2. Members are connecting
3. Network lag happens

What is the current bug behavior?

1. Camera and microphone is disabled on every member now
2. Screen-sharing is enabled on every member now (without user intention)

What is the expected correct behavior?

1. All MediaStreamSettings should be the same as user selected before

Possible fixes

It looks like a problem in our state synchronization after WebSocket reconnection mechanism. So most likely bug is somewhere here, but firstly we need constant reproduce of this bug. We can trigger state synchronization on different stages of the call and try to catch this bug locally.

Problem to solve

Хотельсь-бы знать, когда новый монитор подключается или отключается.

Proposal

Предлагаю добавить вызов onDeviceChange при подключении/отключении дисплея.

Background

During an active call, connection loss may happen due to bad Internet connection, or manually disconnecting from the network.

Problem to solve

If such connection loss occurs, the connection seems to be alive for too long. I've noticed that even after 5-10 minutes of connection loss, restoring the connection works, video/audio recovers, etc. Well, reconnection does work, yet I think the lost connection should be kicked after 30-60 seconds.

BTW, it may be nice to introduce 0 level signal, so that packages using medea_jason may display disconnected label over videos? Something to indicate, that user is really-really dead, not just bad signal, yet tries to reconnect? Just something to discuss, perhaps?

Note, that all of the above was tested in Android to Web direction. Disconnection was happening manually by disabling the WiFi on the Android device.

В процессе реализации #33 мы начали прокручивать Flutter тесты на Винде и Линуксе. На линуксе тесты уверенно падали, предварительное изучение показало что Dart_Handle'ы внутри platform::Error успевают протухнуть, надо персистить.

После фикса проблемы надо будет вернуть задисейбленные тесты из flutter/example/integration_test/jason.dart.

Нужна возможность получать полную инфмацию о состоянии трека. Например, если выключить remote video, то мы хотим знать а включена ли отправка видео у нашего корреспондента.

RemoteTrack.onTransceiverDirectionChange(direction: TransceiverDirection)

TransceiverDirection {
    sendonly
    recvonly
    sendrecv
    inactive  
}

Revealed from from team113/messenger#346

Background

To connect to a room one must follow the steps:

1. Obtain the RoomHandle by invoking the Jason.initRoom().
2. Call the RoomHandle.join.
3. When disposing, call the Jason.closeRoom(RoomHandle).

Problem to solve

When using the same Jason instance, repeating the stated above steps fail on the second iteration - RoomHandle.join never completes. E.g. create a room, join it and close the handle. Then create a new room and try to join it - this RoomHandle.join call freezes.

Also sometimes after closing the room MediaManagerHandle becomes detached: Bad state: MediaManagerHandle is in detached state. However there are no MediaManagerHandle.free calls and the pointer is always kept in a static variable.

This behaviour is reproducible on Web, macOS and Android - probably Windows, Linux and iOS as well.

Description

E2E tests failing with the following message in web driver logs:

2023-03-16 11:47:45 [0316/164745.369243:INFO:CONSOLE(38)] "Uncaught (in promise) TypeError: e.name is not a function", source:  (38)

Error occurs in this function because RpcClientException::name probably? replaced with RpcClientException::kind.

Full trace of error conversion on rust-side: SessionError -> RoomJoinError -> SessionError -> RpcClientException (the latest struct before converting to js-side obj) -> JsValue -> Error

Possible fixes

Replace this callback function calling with:

callback({
    err: {
        kind: e.kind ? e.kind() : undefined, // check function exist, because errors like `StateError` doesn't contains such functions.
        message: e.message(),
        trace: e.trace(),
        cause: e.cause ? e.cause() : undefined
    }
});

CI does not respond to errors in tests.

This problem in
flutter_gherkin 3.0.0-rc.11 and above

there is also a problem of MacOS freezing on versions flutter_gherkin 3.0.0-rc.9 - 3.0.0-rc.14

From #144

BTW, it may be nice to introduce 0 level signal, so that packages using medea_jason may display disconnected label over videos? Something to indicate, that user is really-really dead, not just bad signal, yet tries to reconnect? Just something to discuss, perhaps?

This can be implemented by looking whether PeerConnnection's ConnectionState is in [disconnected, failed]

Summary

When user on MacOS many times enables/disables AirPods (or most likely other bluetooth headphones) while in call, then audio stops playing on any device. Even manual output device switching through media settings not fixing it. It was reported that sometimes after AirPods reconnection audio can start to play on it and everything backs to normal (even switching to speakers), but in my tests it never happened.

Also it was reported, that adding Mutex for output audio switching on frontend side decreases chance of this bug to happen, but maybe it's just seems that way.

Platform information

MacOS specific bug. Was tested on Apple Silicon processors, on different machines, but most likely it related to any Mac because it looks like bug in Jason's MediaManager.

Steps to reproduce

1. Start call in messenger
2. Connect AirPods to Mac
3. Disconnect AirPods from Mac
   3.1. Do it many times until bug happens

What is the current bug behavior?

1. Output audio is now not working

What is the expected correct behavior?

1. Output audio should play on connected device

Possible fixes

It can be related to MediaManager of Jason, because of behaviour where even manual output device selection is not doing anything, but more in-depth investigation needed.

Background

MediaManagerHandle.onDeviceChange is called every time the list of connected devices change.

Problem to solve

If there's multiple MediaManagerHandles (all point out to the same media manager under the hood, I suppose), then changing the onDeviceChange callback overwrites any previous callback being set.

This is an essential problem, since our application uses separate MediaManagerHandles in a call and in a microphone/camera/output switch modal, all having their own onDeviceChange callbacks to do different logic.

Also it's impossible to remove the callback set, which should be possible.

Possible solutions

1. Use addListener/removeListener approach. Library stores the list of callbacks to invoke, addListener adds that callback and removeListener removes it.
2. Use a StreamController.broadcast, which is more preferred to my humble opinion, as API returns a Stream and developer may use it as they wish.

Background

Жизненный цикл звонка выглядит примерно следующим образом:

1. Инициализация локальных треков (initLocalTracks) и настроек (setLocalMediaSettings) от MediaStreamSettings, который при аудио звонке содержит только audio составляющую, а при видео звонке - audio и deviceVideo.
2. Нажатие на кнопку "выключить видео" вызывает room.disableVideo(Device) и в случае успеха удаляет и освобождает трек (и рендерер) этого видео.
3. Нажатие на кнопку "включить видео" вызывает только лишь room.enableVideo(Device), а сам трек приходит через room.onLocalTrack callback, откуда трек и добавляется.
4. Пункты 2-3 описывают поведение и для аудио, и для screen sharing'а.

Question

Если при инициализации локальных треков видео было включено, то описанное выше поведение работает идеально, видео включается и выключается, индикаторы гаснут и так далее. Однако если видео было выключено (т.е. отсутствовала при initLocalTracks/setLocalMediaSettings в MediaStreamSettings составляющая deviceVideo), то в таком случае room.enableVideo(Device) просто моментально выполняется (await моментален) без каких либо ошибок, при этом никакого enable'а не происходит. Аналогично и screen share, т.е. если вместо Device прокидывать Display. Отмечу, что если при инициализации локальных треков аудио было отключено, то room.enableAudio всё равно вызывает onLocalTrack, тем самым отрабатывая идеально даже при выключенном изначально аудио.

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

И ещё вопрос, если можно: насколько некорректно дёргать заново initLocalTracks и setLocalMediaSettings для enable/disable камеры и шейринга экрана? Потому что если вызывать эти функции с включением или нет той или иной составляющей deviceVideo и displayVideo, то enable/disable отрабатывает идеально и как задумано. audio составляющая делает disable аудио, но enable аудио не отрабатывает таким образом.

У нас сейчас есть возможность вырубить remote audio/video только для всей комнаты, через соответствующие функции на RoomHandle, нужна возможность вырубать точечно, для каждого коннекшена отдельно. Тобишь:

• ConnectionHandle.enable_remote_video
• ConnectionHandle.disable_remote_video
• ConnectionHandle.enable_remote_audio
• ConnectionHandle.disable_remote_audio

При повторной инициализации Jasonа в консоль на вебе прилетает следующая ошибка:

attempted to set a logger after the logging system was already initialized

Прилетает из этой функции файла medea_jason.js, дальше лезет в WASM:

    /**
    * Instantiates a new [`Jason`] interface to interact with this library.
    */
    constructor() {
        var ret = wasm.jason_new(); // <== HERE
        return Jason.__wrap(ret);
    }

Насколько я понимаю, это не совсем ошибка, но вылетает именно через console.error, я так полагаю.

Background

На вебе пользователь может дать разрешение на доступ к микрофону, а позже отменить его.

Question

Что нам стоит делать в таком случае? Потому что RoomHandle.unmuteAudio будет и дальше использовать устраевший трек.

Summary

Если запустить демонстацию экрана например на 10 фпс, а позже запустить уже с 60 фпс, демонстрация будет и дальше работать на 10 фпс.

Подобное поведение наблюдается только если между остановкой демонстрации экрана на 10 фпс и запуском на 60 фпс проходит меньше чем пол секунды.

Steps to reproduce

1. Запустить демонстацию экрана на 10 фпс
2. Завершить предыдущую демонстрацию экрана и сразу запустить демонстрацию на 60 фпс
3. Наблюдать что вторая демонстрация экрана тоже работает на 10 фпс

What is the current bug behavior?

При перезапуске демонстрация экрана продолжает рабоать на 10 фпс.

What is the expected correct behavior?

При перезапуске демонстрация экрана работает на 60 фпс.

Background

На данный момент E2E сценарий Video endpoint added while disconnected имеет свойство рандомно падать в CI, поэтому его было решено временно закомментить (#23). Но в будущем его нужно поправить, и раскомментить.