BUGS to solve

[LePhenix47]

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:

  1. The local peer connection isn't closed
  2. The tracks aren't stopped
  3. The state management is not reset
  4. The 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)

  • [x] When we join then create a room, joiners cannot join the room because it sends the room name to null, room creator also cannot create new room

• [x] When we switch devices

  1. If the local peer enabled their webcam, shared their screen, and switched the video or audio input, it stops the screenshare

  2. 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

[LePhenix47]

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

[LePhenix47]

Update reguarding the "unsolvable bug"

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.

[LePhenix47]

IMPORTANT NOTE:

Regarding the screen recording, we must mix the audio data together using the AudioContext API