Avatar

Not applicable

Hi,

We have a 2-sides meeting room in which every side can see his and the other's video and hear the other side. You can also control whether to mute the camera/audio and we have a chat between the users. The room is created from our rails backend using a server-to-server api which also creates the two users that are authorized to access the room. Meaning, each room is created to a specific combionation of two users and stays like this for it's entire lifetime.

We are having a couple of problems with it and we thought that maybe we are missing something because it looks like our use-case is pretty trivial.

1. Video&Audio gets stuck

Once in a while both participants stop receiving video&audio (the flash it self is still running and you can see yourself). We notices that it happens usually after a gradual degradation sound and video quality. Also, when we pause&start the video it returns to work fine but if we do that for the audio it doesn't - which leads us to think that it has something to do with the stream state (our video stop&start really pauses the stream and the audio's stop&start only sets the volume to 0). Another thing we suspect is that it happens only when the it is P2P (and not via your servers) because our office network does not permit P2P communcation and we can leave it for hours, but in real-world cases it gets stuck often.

Does it sound familiar? Maybe we are missing some trivial event or doing something wrong in the code? More info needed?

2. Already connected scenario

As mentioned above our meeting room is designed for 2 specific users. This made it easier for us to build it as we do not need to support a multi-side generic room. However, we are not sure what to do when a user is already connected (trying to connect twice). Letting him connect twice is problematic because then you cannot set the publishersId to [other_user_id] because the second and third instances gets the following user ids 'USER/2' and 'USER/3' consecutively (and also the user name gets a little 'dirty' - 'User Name 2' and 'User Name 3'). So to prevent our code from handling many weird cases (knowning that usually it doesn't happen) we don't allow more instances to connect after the first one (we display a nice message). The problem is the sometimes although the user disconnected (regularly or aggressively) the room still thinks that he is connected and does not allow the 'real' user to connect. It stays in this 'dirty' state for a few minutes and then it's okay. We thought of throwing out previews instances when you enter the room but it doesn't 'feel' right.

What do you suggest doing there? How should we handle this case without too many hacks?

Thanks in advance,

Ehud Yalin-Mor

vCita