Originally reported on Google Code with ID 879
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
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
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
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.
Reported by ffdixon on 2011-02-22 21:28:25
Reported by ffdixon on 2011-02-22 21:29:10
Yes it happens to me also. Normally after about 40 min, they are disconnected from voice.
Then I restart bbb with --clean
Reported by venkatesan63 on 2011-08-01 15:50:07
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)
Reported by compareo on 2011-09-27 05:05:51
It happens to us frequently, we have 5-6 students on the conference, it drops student
Reported by aoomi.chen on 2011-10-31 13:00:13
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.
Reported by cwlhobbs on 2011-12-14 14:26:11
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
Reported by ffdixon on 2011-12-14 14:45:02
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.
Reported by ffdixon on 2012-05-08 11:09:39
Any news about this problem ?
Reported by adambouhadma on 2012-06-01 14:54:09
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.....
Reported by davebanda09 on 2012-10-02 17:35:04
update: The Users were both unmuted and one was presenter and the other a viewer...
Reported by davebanda09 on 2012-10-02 19:01:59
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),
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.
Reported by ffdixon on 2012-11-08 14:39:53
Issue 515 has been merged into this issue.
Reported by ffdixon on 2012-11-11 17:08:04
Reported by ffdixon on 2013-02-03 03:54:33
Reported by ritzalam on 2013-03-15 14:45:45
Reported by ffdixon on 2013-10-11 03:12:26
The auto-reconnect feature was implemented in 1.0-beta.