Automatically attempt to reconnect user if network connection has dropped

[GoogleCodeExporter]

We've observed on occasion that a user while connected to the voice conference 
bridge from within BigBlueButton (via the headset icon) will be dropped from 
the listeners window.

Specifically, their BigBlueButton client is still connected, but they are 
disconnected from their voice bridge.

There does not seem to be any observable pattern to why most users will always 
remain connected, whereas others will occasionally drop (after which they click 
the headset icon to reconnect).

This might be related to some of the exceptions thrown in the red5 logs

   http://code.google.com/p/bigbluebutton/issues/detail?id=765

This definitely needs more investigation to figure out the root cause.  

1.  Is it the network (unlikely as their client remains connected)?  
2.  Is it the state of their connected (muted/unmuted)?
3.  Is it related to red5phone not sending keep alive packets to the server

   http://code.google.com/p/bigbluebutton/issues/detail?id=830

4.  Is it related to their version of Flash?
5.  Other variables ...

If anyone is seeing this behavior in their setup of BigBlueButton (one user 
occasionally dropping from the listeners window), please add to this issue any 
details that might help narrow down the root cause.

Original issue reported on code.google.com by ffdixon@gmail.com on 22 Feb 2011 at 9:28

[GoogleCodeExporter]

Original comment by ffdixon@gmail.com on 22 Feb 2011 at 9:29

• Changed title: Users occasionally disconnected from the voice conference

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yes it happens to me also. Normally after about 40 min, they are disconnected 
from voice. Then I restart bbb with --clean

venkatesan

Original comment by venkates...@gmail.com on 1 Aug 2011 at 3:50

[GoogleCodeExporter]

It happens to me as well. I noticed that now it drops users from voice after 
4-5 hours after i changed a value of timeout to higher than 3 hours in 
properties (i don't know if that connected and if it really affects this 
behavior)

Original comment by compa...@gmail.com on 27 Sep 2011 at 5:05

[GoogleCodeExporter]

It happens to us frequently, we have 5-6 students on the conference, it drops 
student randomly. 

Original comment by aoomi.c...@gmail.com on 31 Oct 2011 at 1:00

[GoogleCodeExporter]

The 40 minute timeout hits me too but only when I'm the presenter and running 
on a Mac. I have had the voice stay up as long as 50 minutes but normally I'm 
resigned to being told after 40 minutes that my voice is starting to break up. 
I log out and in again and everything seems to be fine. Pity.

Original comment by cwlho...@gmail.com on 14 Dec 2011 at 2:26

[GoogleCodeExporter]

Hi Chris,

You may feel resigned, but we're not.  Our goal is to provide consistent, 
high-quality audio in BigBlueButton.  There are technical challenges to doing 
this (the Flash plug-in restricts applications to using TCP/IP and not UDP), 
but these restrictions might change in the future.

At the moment, we're working on figuring out why the user is disconnected 
(which is independent of the network protocol), and which may be related to 
your issue of the voice quality.

Original comment by ffdixon@gmail.com on 14 Dec 2011 at 2:45

[GoogleCodeExporter]

We've added an automatic reconnect in 0.8-RC1 if the BigBlueButton client 
detects the user has dropped from the voice bridge.

This does conflict with the eject users command where a moderator can eject a 
user from the voice conference.  In this case, the user rejoins.  However, it 
does have a benefit in that if the user's echo cancellation is not working 
correctly (they sound like they are in a long tunnel), ejecting them from the 
voice conferencing causes an automatic reconnect and restores their audio to 
the initial state.

Original comment by ffdixon@gmail.com on 8 May 2012 at 11:09

• Changed state: Started

[GoogleCodeExporter]

Any news about this problem ?

Original comment by adambouh...@gmail.com on 1 Jun 2012 at 2:54

[GoogleCodeExporter]

I have also experienced this issue recently and have not been able to identify 
the root cause. Users report that during the conference the audio drops, they 
are able to reconnect and it drops again unless they completely log out and 
rejoin the conference. 

The users reporting this issue are using the following systems:
 Google Chrome 19.0.1084.56 m, the other user was on IE 9.08.
Java Versions were version 7, update 5, and the other is version 7, update 7.

I still have not identified the users role and or status of audio (muted or 
unmuted)

Hope this helps to identify the root cause.....

Original comment by daveband...@gmail.com on 2 Oct 2012 at 5:35

[GoogleCodeExporter]

update: The Users were both unmuted and one was presenter and the other a 
viewer...

Original comment by daveband...@gmail.com on 2 Oct 2012 at 7:01

[GoogleCodeExporter]

We're going to change the focus of this issue to look at adding automatic 
reconnect logic in the BigBlueButton to

  1) Catch when a network connection has dropped
  2) Automatically reconnect the client

This will help us solve the random RTMPT disconnect issue (from the user's 
perspective), see: http://code.google.com/p/bigbluebutton/issues/detail?id=1246

We're looking at adding automatic reconnect because no matter how much we 
harden the BigBlueButton server (i.e. red5), there will still be cases where 
the network may occasionally drop, such as moving from one wireless base 
station to another.

The internet does not guarantee you a reliable connection.   Skype has 
automatic reconnect in it and anyone who has used Skype has seen the 
"Attempting to reconnect..." dialog. 

We're going to look at doing the same for BigBlueButton in 0.81.

Original comment by ffdixon@gmail.com on 8 Nov 2012 at 2:39

• Changed title: Automatically attempt to reconnect user if network connection has dropped
• Added labels: Milestone-Release0.81

[GoogleCodeExporter]

Issue 515 has been merged into this issue.

Original comment by ffdixon@gmail.com on 11 Nov 2012 at 5:08

[GoogleCodeExporter]

Original comment by ffdixon@gmail.com on 3 Feb 2013 at 3:54

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by ritza...@gmail.com on 15 Mar 2013 at 2:45

• Removed labels: Milestone-Release0.81

[GoogleCodeExporter]

Original comment by ffdixon@gmail.com on 11 Oct 2013 at 3:12

• Changed state: Accepted