Open LePhenix47 opened 3 months ago
If a room creator shares ONLY one media (audio or video) and the joiner shares ONLY the opposite, the room creator won't receive any tracks
It's an SDP issue, if the offerer shares one specific media stream, the answerer one or both, then the offerer will get either none or one in common to the one shared by the answerer
UNSOLVABLE BUG
If a room creator shares ONLY one media (audio or video) and the joiner shares ONLY the opposite, the room creator won't receive any tracks
It's an SDP issue, if the offerer shares one specific media stream, the answerer one or both, then the offerer will get either none or one in common to the one shared by the answerer
This is actually NOT an unsolvable bug. We can address this issue by implementing a more robust handling of media streams. Specifically, we can introduce transceivers in the peer connection setup to ensure that the correct media flow is established, regardless of the specific streams shared by the offerer and answerer, example:
// Create a new RTCPeerConnection
const peerConnection = new RTCPeerConnection(configuration);
const audioTransceiver: RTCRtpTransceiver = peerConnection.addTransceiver('audio', { direction: 'sendrecv' });
const videoTransceiver: RTCRtpTransceiver = peerConnection.addTransceiver('video', { direction: 'sendrecv' });
By making these adjustments, we can guarantee that the room creator will receive the appropriate tracks, even in cases where there is a mismatch in shared media types. I believe this approach will resolve the issue effectively.
Regarding the screen recording, we must mix the audio data together using the AudioContext
API
BUGS to fix
There are currently 6 major bugs in the proof of concept:
[x] A user can access the
/support
page twice using the same name[x] After a room was created, if the joiner joins with their local media on, the creator still won't be able to start the WebRTC session because no notification was sent
[x] When a room is full (2 people are in the room, the creator of the room and the joiner), the "join" button isn't disabled
[x] There's no state management for the local media permission denial
[x] There's no state management for when a user stops the screen sharing, whether we're in a WebRTC session or not
[x] If you delete a room by clicking the "delete" button as a creator or "disconnect" button as a joiner, the WebRTC session is still these steps not taken care of yet:
The local peer connection isn't closedThe tracks aren't stoppedThe state management is not resetThe local stream is stopped but not restarted[x] If you try to disconnect by refreshing the page or by going to the previous page, it won't properly close the room for the remote peer
[x] We have no visual indicator that their audio input is working (should show deciBels bar)
null
, room creator also cannot create new room[x] When we switch devices
If the local peer enabled their webcam, shared their screen, and switched the video or audio input, it stops the screenshare
If the device is not available to use, the
<select>
element doesn't select back the available one[ ] There's no loading status for the local media switch or connection feedback during our WebRTC session
[x] Ensure that if the user doesn't share their microphone, the decibels bar is hidden. If the user doesn't share their webcam, the
[ ] When a user starts a screen recording & then shares their screen, there can be a memory leak
[x] The WebRTC section of the PoC has a subpar UI
[x] The rooms handling is buggy, for instance when 2 people join a room and a 3rd user creates a new room and then deletes it, it will delete every single other room, and the creator of the full rooms won't be able to create nor delete their room