"The reason why you are getting this error message is because when a third user joins, it sends an offer to the 2 previously connected users, and therefore, it receives 2 answers. Since one RTCPeerConnection can only establish one peer-to-peer connection, it will complain when it tries to setRemoteDescription on the answer that arrived later, because it already has a stable connection with the peer whose SDP answer arrived first. To handle multiple users, you will need to instantiate a new RTCPeerConnection for every remote peer.
That said, you can manage multiple RTCPeerConnections using some sort of dictionary or list structure. Through your signalling server, whenever a user connects you can emit a unique user id (could be the socket id). When receiving this id, you just instantiate a new RTCPeerConnection and map the received id to the newly created peer connection and then when you will have to setRemoteDescription on all entries of your data structure.
This would also remove the memory leaks in your code every time a new user joins when you overwrite the peer connection variable 'pc' when it is still in use.
Notice though, that this solution is not scalable at all, since you are going to be creating new peer connections exponentially, with ~6 the quality of your call will already be terrible. If your intention is to have a conference room, you should really look into using an SFU, but be aware that usually, it is quite cumbersome to set it up".
"The reason why you are getting this error message is because when a third user joins, it sends an offer to the 2 previously connected users, and therefore, it receives 2 answers. Since one RTCPeerConnection can only establish one peer-to-peer connection, it will complain when it tries to setRemoteDescription on the answer that arrived later, because it already has a stable connection with the peer whose SDP answer arrived first. To handle multiple users, you will need to instantiate a new RTCPeerConnection for every remote peer.
That said, you can manage multiple RTCPeerConnections using some sort of dictionary or list structure. Through your signalling server, whenever a user connects you can emit a unique user id (could be the socket id). When receiving this id, you just instantiate a new RTCPeerConnection and map the received id to the newly created peer connection and then when you will have to setRemoteDescription on all entries of your data structure.
This would also remove the memory leaks in your code every time a new user joins when you overwrite the peer connection variable 'pc' when it is still in use.
Notice though, that this solution is not scalable at all, since you are going to be creating new peer connections exponentially, with ~6 the quality of your call will already be terrible. If your intention is to have a conference room, you should really look into using an SFU, but be aware that usually, it is quite cumbersome to set it up".