Description
When a participant joins from Android using a token with canPublishSources permission set to "canPublishSources” :["camera"] then the expected behaviour is only video track should be published.What we have observed is no track is published in this case.
Reproduction
Reproduction is a simple step join android client with token with "canPublishSources” :["camera"] and a second participant to observe the behaviour with canSubscribe as true(web/Android either is fine).The remote user will not be getting any video track.
System Info
Android SDK version verified on 1.4.1 as well as 1.4.2 with livekit SFU version 1.4.5
Severity
blocking an upgrade
My Analysis:
This issue is specific to Android even though the canPublishSources implementation is being handled at server end because this functionality is breaking due to coroutine being suspended which never gets a response from server.That is the when a client joins a livekit call addTrack method of RTC engine is called for audio as well as video irrespective of the token permissions.What happens with camera only token is a suspendible coroutine is called first for audio Track.This coroutine expects a response from server but since microphone is missing as a source so no response is received from server and this coroutine is blocked and sendAddTrack for video is working on same coroutine which is already blocked by sendAddTrack of audio leading to Android client not publishing its video Track.
To further verify my analysis i tried two scenario Firstly i used a token with "canPublishSources" :["camera","microphone" ] in this case i got a positive response from server and first audio was published and on same coroutine video was published later(Since coroutine got unblocked by server on Publishing audio Track).Secondly to further confirm this theory ,I removed whole audio Publishing from android client so that suspend coroutine is not being called for audio sendAddTrack and the used the token with "canPublishSources” :["camera"] ,here the video was successfully published and visible at remote participant's end.
For fixing this bug i have two approach in mind: 1.Sending a negative response to add Track request from client.This response will ensure the coroutine is unblocked for further requests. 2.Diverting the request on different coroutine such that audio and video is independent of each other.
Description When a participant joins from Android using a token with canPublishSources permission set to "canPublishSources” :["camera"] then the expected behaviour is only video track should be published.What we have observed is no track is published in this case. Reproduction Reproduction is a simple step join android client with token with "canPublishSources” :["camera"] and a second participant to observe the behaviour with canSubscribe as true(web/Android either is fine).The remote user will not be getting any video track.
System Info Android SDK version verified on 1.4.1 as well as 1.4.2 with livekit SFU version 1.4.5
Severity blocking an upgrade
My Analysis:
This issue is specific to Android even though the canPublishSources implementation is being handled at server end because this functionality is breaking due to coroutine being suspended which never gets a response from server.That is the when a client joins a livekit call addTrack method of RTC engine is called for audio as well as video irrespective of the token permissions.What happens with camera only token is a suspendible coroutine is called first for audio Track.This coroutine expects a response from server but since microphone is missing as a source so no response is received from server and this coroutine is blocked and sendAddTrack for video is working on same coroutine which is already blocked by sendAddTrack of audio leading to Android client not publishing its video Track. To further verify my analysis i tried two scenario Firstly i used a token with "canPublishSources" :["camera","microphone" ] in this case i got a positive response from server and first audio was published and on same coroutine video was published later(Since coroutine got unblocked by server on Publishing audio Track).Secondly to further confirm this theory ,I removed whole audio Publishing from android client so that suspend coroutine is not being called for audio sendAddTrack and the used the token with "canPublishSources” :["camera"] ,here the video was successfully published and visible at remote participant's end. For fixing this bug i have two approach in mind: 1.Sending a negative response to add Track request from client.This response will ensure the coroutine is unblocked for further requests. 2.Diverting the request on different coroutine such that audio and video is independent of each other.