Right now we’re testing a suite of WebRTC updates to hopefully introduce even stronger stability to user’s video/voice calls. These updates are currently on the Developer's Server, so you will need to be a Pro user to create a game on there, but any subscription tier user can play on a Dev Server game. For future replies to this thread, please let us know if you've been seeing your issues on Production or on the Developer's Server. Here’s what’s been updated to WebRTC on the Dev Server: Update 1 - Resolving the Chain of Calls When WebRTC activates it begins connecting individual users sequentially from the first user to log into the game to the very last. The expected result was that each user would go down the chain of users until everyone was connected to the call. Call 1: User A is hailed, User A receives the request and connects to the call, Move on to Call 2 Call 2: User B is hailed, User B receives the request and connects to the call, Move on to Call 3 Call 3: User C is hailed, User C receives the request and connects to the call, Move on to Call 4 Call 4: User D is hailed, User D receives the request and connects to the call, Move on to Call 5 (repeat this process until all Users currently logged into the game are connected) The unexpected problem we discovered is that when a user in the order fails to connect, the entire chain of connections stops cold. So we have the following occur: Call 1: User A is hailed, User A receives the request and connects to the call, Move on to Call 2 Call 2: User B is hailed, User B does not receive the request, doesn’t connect to the call, Process Hangs There are no Calls 3, 4, 5, … made out to the remainder of the users in the group. The Chain dies at User B. Worse, we also didn’t have an error being thrown out when this occurred so we wouldn’t know when the connection breaks. For those in a game, it would feel like the entire call failed rather than being able to identify which user in particular was having difficulties with WebRTC. Now with this update, there is a purposely made delay as it connects to the users down the chain. If a user is unable to connect, the chain of connections will continue onto the next user until all users have been given a chance to connect to the call. This way the gaming group will be able to identify the user who needs Video/Voice troubleshooting. Update 2 - No More Doubled-Up Calls Previously, if two users logged in to a game at close to the exact same time, WebRTC would have the two users call each other and the result would be two separate connections between the two users rather than one. This lead to a great deal of call instability where one of the video feeds would be overwritten by the other and it would be impossible to tell which one. This made it impossible for our system to know which feed to attach the Volume and Whispering controls to. With this update we’ve locked down the connection system and made the process “atomic”. In programming terms, the calls between users are locked down to a specific order even if the two users log in within a fraction of second apart. Multiple users doing the exact same thing, at the exact same time, with the same data doesn’t have an impact on the order in which the calls are being sent out and connecting. Update 3 - No More Volume Meter Stacking We have added more polish to the Volume Meter. Previously, when users reconnected, it was possible for multiple instances of the same volume meter to stack on top of each other. This would cause the volume meter to flash at best or be entirely unstable at worst. Now everyone should only have a single Volume Meter that clears itself properly in the case of a browser refresh or reconnect. Remaining Issue Sometimes a call connection with a user may go through without issue, but all anyone else sees is a Black Box for their video feed and no audio transmitted. This issue is due to a browser hiccup (likely caused with all the other background processes Roll20 is doing at that very moment) when the call connection was made. From Roll20's side, it looks like the connection is made, but the user's browser isn’t actually sending any video or voice data. In most cases, all the User should have to do is click on the Reconnect Button from the Settings Tab to kickstart the browser to establish a new connection.