Bandwidth for Dokeos videoconferencing

afbeelding van Oscar2

The bandwidth required for Dokeos videoconferencing system (based on Big Blue Button) is the following


Outgoing Stream:
7KB/s
Incoming Stream:
12KB/s

1 one2four VideoConference:
4 outgoing streams from every client: 4 * 7KB/s = 28KB/s incoming traffic on server-side
12 incoming streams to every client: 12 * 12KB/s = 144KB/s outgoing traffic from server-side

1 one2many Conference (up to 50 seats)
1 outgoing streams -> 7KB/s incoming traffic
50 incoming streams -> 50 * 12KB/s = 524KB/s outgoing traffic

Thank you. Please also

Thank you.

Please also include the required server hardware specs.

afbeelding van Oscar2

I would go for lmited HD

I would go for lmited HD space nut rapid access to HD. Lots of RAM.
Something like any Dual Core. 64 Gb HD or event better Flash Card memory. Because there is no storage needed, really.

32 Gb RAM. And 100 Mbs ethernet.
 

unless I am incorrect, here

unless I am incorrect, here it is 

(found the following at http://code.google.com/p/bigbluebutton/wiki/FAQ)

 

What are the bandwidth requirements for running a BigBlueButton server?

When sharing a webcam, as a moderator BigBlueButton lets you select 320x240 or 640x480. Both use the same amount of bandwidth, roughly 30-50 kbytes/second per stream. Viewers can only share a 320x240 webcam.

For example, if you have a room with 5 users, each sharing their webcam, then the you can calculate the bandwidth usage as follows:

  • Y = 30-50 Kbytes/sec; let's assume 40 Kbytes/sec on average
  • W = amount of webcams that are streaming
  • U = amount of users that are watching

For calculations:

  • server incoming bandwidth: W*Y
  • server outgoing bandwidth: W*(U-1)*Y (minus one since a broadcaster does not have to subscrive to his own stream)

 

For example, with 5 users in a room with 5 webcams streaming, the bandwidth calculation is as follows:

  • in: 5*40 = 200 Kbytes/sec incoming bandwidth needed to the server (e.g. 1.6 Mbit)
  • out: 5*(5-1)*40 = 800 Kbytes/sec incoming bandwidth needed from the server (e.g. 6.4 Mbit)
  • Total traffic used after one our: 60 mins*60 secs*(200 + 800) = 3.6 Gbyte traffic per hour

If you'd have a typical classroom situation with the presenter broadcasting their webcam to 30 remote students, the calculation is as follows:

  • in: 1*40 = 40 Kbytes/sec incoming (e.g. 0.32 Mbit/sec)
  • out: 1*(30-1)*40 = 1160 Kbytes/sec outgoing (e.g. 9.3 Mbit/sec)
  • Total traffic used after one hour: 60 mins*60 secs*( 40 + 1160) = 4.3

Gbyte traffic per hour

If you'd have 10 of those classes then you server need to be able to output 93 Mbit/sec; that's not much in a LAN but it's pretty much if your in a hosted environment.

Large "cafe-style chatroom" : 20 viewers, 8 people broadcasting with a webcam:

  • in: 8*40 = 320 kbyte/sec ( 2.5 Mbit )
  • out: 8*(20-1)*40 = 6080 kbytes/sec ( 48.6 Mbit )
  • Total traffic used after one hour: 60 mins*60 secs*( 320 + 6080 ) = 23 Gbyte traffic per hour

Sharing slides take almost no bandwidth beyond the initial uploading/downloading of slides. When the presenter clicks to show the next slide, the viewers receive a "move next slide" command in their BigBlueButton client, and they load the next slide from the local cache. Chat also almost no bandwidth as well.

Desktop sharing takes the most bandwidth, and it's dependent on area chosen by the presenter (full screen and region) and how often their screen updates.

A VoIP connection to the BigBlueButton takes roughly 20 kB/sec per user. The bandwidth for VoIP grows linearly with number of users. For example, if there are 20 students in a classroom, then the bandwidth requirements for the server to support VoIP is 20 * 20 KBytes/sec = 400 kBytes/sec.

If the presenter has only 100 KByte/second upstream, then performing VoIP, video, and desktop sharing will fit within that upstream constraint. In reality, red5/Flash does a good job of using limited bandwidth and it actually works quite well. In the case of desktop sharing, the remote desktops will still receive updates, but the refresh will be much slower than if the presenter was on a LAN (such as within the university or college network).

question out of personal

question out of personal interest:

so you are using http://www.bigbluebutton.org/ for your video-conferencing.

This is open-source software. They already integrate with a fair share of open-source platforms (wordpress, joomla, droopal) and even several of your competitors (moodle, efront, sakai). http://www.bigbluebutton.org/open-source-integrations/

Yet you have put this as part of your pro version.

Why is that?

afbeelding van Nathan

Hi Sebastian, BBB is a free

Hi Sebastian,

BBB is a free software available for download on the internet. What we sell is a service : the guarantee that Dokeos and BBB integrate properly and that the videoconferencing service will be available, work fine, according to a strict SLA that includes fixes in case of trouble. This is far from empty, as it very hard and complex to run a videoconferencing server and guarantee a fluent service to many clients simultaneously.