Closed MaZZly closed 23 hours ago
@mustafaboleken can you clarify if this is the intended behavior due to e.g. WebRTC, or if it is a bug?
As far as I know, it's not an intended behavior but let me discuss with my collegues. I will let you know.
@mustafaboleken, thanks; I'm thinking this is quite a critical bug if audio/video tracks are still being sent even when not initialized to be...
@mustafaboleken has there been any progress on this one?
Hi @MaZZly,
I hope you are doing well. I have some findings that I wanted to discuss with you in order to discuss a couple of things related to React Native and this issue. Do you have some time next week for a meeting? After the discussion, I wanted to create pull requests.
Yeah sure, still quite open for next week. Send an invite to my email I'll let you know if it works :)
Hi @mustafaboleken,
What's the current status of this issue?
Cheers Oguz
This can also be seen in the multitrack conference, where we listen to obj.stream.onremovetrack
to handle streams stopping.
if (info === 'newTrackAvailable') {
obj.stream.onremovetrack = (event: MediaStreamTrackEvent) => {
console.log(event.track.kind);
}
}
The above code will log 2 entries: video
and audio
, even though we don't have audio enabled when initializing the WebRTCAdaptor
object
Hi MaZZly,
I hope you are doing well. Let me explain how the multitrack conference works. Whenever you join a room with more than 1 participant, you will have 2 RTCPeerConnection. One is for publishing to the server, and the other is for playing the room (main track). I tested the scenario that you raised and saw that, if I make the audio false, then I don't have an audio track for publishing but I have audio tracks for the peer connection which is used by play functionality even if all the participants are video-only participants. So, it's an expected behavior.
I'm closing this issue due to the inactivity. If you need to discuss it in the future, feel free to reopen the issue.
Short description
We initialize the JS SDK like:
When inspecting
this.webRTCAdaptor.remotePeerConnection
senders and receivers we seeMediaStreamTrack
of typekind: audio
that areenabled: true
...Steps to reproduce
audio: false
Expected behavior
The
RTCPeerConnection
s should not have anyMediaTrack
wherekind: audio
when we have explicitly disabled it in the beginning.Actual behavior
The
RTCPeerConnection
s haveMediaTrack
s wherekind: audio
andenabled: true
are added..