Request for Feedback: API changes to BigBlueButton 0.8

2335 views
Skip to first unread message

Fred Dixon

unread,
Jun 30, 2011, 9:06:15 AM6/30/11
to BigBlueButton-dev
This is a DRAFT document for the API changes planned for BigBlueButton
0.8. These changes are to support the upcoming record and playback
functionality in BigBlueButton 0.8 and to improve the security of
joining a session.

We've tried to keep the changes minimal while at the same time
expanding the API to support record and playback.

We welcome all your feedback on the changes below.

** Overview

In the current API, BigBlueButton supports the following calls:

create
join
end
isMeetingRunning
getMeetings
getMeetingInfo

In BigBlueButton 0.8 there will be updates to the create, join, and
getMeetings, and getMeetingInfo API calls, along with the addition of
three new API calls to support record and playback:

getRecordings
setRecordingsPublish
deleteRecordings

The current API version is 0.7 (this is the result returned from a
BigBlueButton 0.71a server). This string will change to 0.8 so you
can detect the newer version of the API on the BigBlueButton server.

All the API changes and additions are backward compatible.
Applications using API version 0.7 calls will work unchanged on a
BigBlueButton 0.8 server.


** Updates to existing API calls


1. Add the optional parameters ‘record’ and ‘duration’ to create

record
type: string
values: true|false
default: false

duration
type: integer (in minutes)
default: 0 (no automatic end)

Setting ‘record=true’ instructs the BigBlueButton server to record the
media and events in the session for later playback. BigBlueButton
starts recording when the first person joins the session, and stops
recording when either the last person leaves or upon receiving an end
API request for the associated meetingID.

When the recording stops, BigBlueButton automatically begins
processing the recorded media and events using one or more ‘ingest and
processing’ scripts installed on the BigBlueButton server. The
default scripts will playback the slides and audio in the session.

Meetings now have a duration. The default is 0, which means the
meeting continues until the last person leaves or an end API calls is
made with the associated meetingID. This is how meetings work in
BigBlueButton 0.7.

However, when recording a meeting, you should pass a value for
‘duration’. When the length of the meeting reaches the duration,
BigBlueButton automatically ends the meeting. Passing a duration for
a meeting prevents the scenario where one (or more) users linger in
the session long after the meeting has finished (i.e. leave their
browser open over night), indefinitely delaying the processing of the
recording for the meeting.


2. The ‘meetingID’ parameter for create should not contain commas

If you intend to use the new getRecordings, setRecordingsPublish, and
deleteRecordings API calls, the value for ‘meetingID’ must not contain
commas.

The above new API calls will accept a set meetingIDs, separated by a commas.

2. create will accept one (or more) additional parameters prefixed
with ‘meta_’

meta_* (optional)
type: string

These additional metadata parameters will be stored by BigBlueButton
and later retrievable via the getMeetingInfo call (while the meeting
is running) and getRecordings (after the meeting is finished and the
recording is ready for access).


Examples of meta parameters are meta_Presenter, meta_category,
meta_LABEL, etc. All parameters are converted to lower case, so
meta_Presenter would be the same as meta_PRESENTER.


3. The parameters ‘name’ and ‘meetingID’ can now differ in create.

The ‘meetingID’ parameter should be an internal key value (without
commas) created by the 3rd party application calling the API. In
contrast, the ‘name’ parameter is meant as an external, user visible
value accesible via the %%CONFNAME%% string in the welcome message.

The parameters ‘name’ and ‘meetingID’ can now differ, enabling 3rd
party applications to change the ‘name’ between sessions, such as
“First Meeting”, “Second Meeting”, while keeping a consistent
‘meetingID’ for later retrieval of recordings.

4. The XML result from create now includes ‘createTime’.

Reason: Third-party applications using the BigBlueButton API can now
pass ‘createTime’ a join URL to prevent re-use of the URLs between
sessions with the same ‘meetingID’ (see 6).

The value for ‘createTime’ is the unix epoch time (see
http://en.wikipedia.org/wiki/Unix_time).

Here’s a sample return from the create

<response>
<returncode>SUCCESS</returncode>
<meeting>
<meetingID>87sdf89210gt</meetingID>
<createTime>1308591802</createTime>
<attendeePW>testa</attendeePW>
<moderatorPW>testm</moderatorPW>
<hasBeenForciblyEnded>false</hasBeenForciblyEnded>
<messageKey>createSuccess</messageKey>
<message>Meeting has been create</message>
</meeting>
</response>

5. getMeetings and getMeetingInfo also return ‘createTime’, along
with the value for ‘record’, and ‘duration’

For example, here is a sample XML response from getMeetingInfo

<response>
<returncode>SUCCESS</returncode>
<meetingID>123456</meetingID>
<createTime>1308591802</createTime>
<attendeePW>abc</attendeePW>
<moderatorPW>qwe</moderatorPW>
<running>true</running>
<startTime>Thu Mar 04 14:05:56 UTC 2010</startTime>
<endTime>null</endTime>
<participantCount>2</participantCount>
<moderatorCount>1</moderatorCount>
<attendees>
<attendee>
<userID>40</userID>
<fullName>JT Attendee</fullName>
<role>VIEWER</role>
</attendee>
<attendee>
<userID>37</userID>
<fullName>JT Moderator</fullName>
<role>MODERATOR</role>
</attendee>
</attendees>
<messageKey/>
<message/>
</response>


Note: ‘createTime’ is the time the meeting was create by
BigBlueButton, ‘startTime’ is when the first person joins, and
‘endTime’ is the time when last person has left the meeting or when
BigBlueButton received an end API call for the meeting.


6. join can now pass ‘createTime’ parameter

createTime (optional)
type: integer


When passing ‘createTime’ with a join URL, BigBlueButton will ensure
it matches the ‘createTime’ for the session. If they differ,
BigBlueButton will not proceed with the join request.

This prevents a user from reusing their join URL for a subsequent
session with the same ‘meetingID’.

While the ‘createTime’ parameter is optional, we recommend that 3rd
party applications using the BigBlueButton API add this parameter to
their join calls.

** New API Calls


7. Add ‘getRecordings’ API call

meetingID[,meetingID]* (optional)
type: string

checksum
type: string

Retrieves the recordings that are available for playback for a given
‘meetingID’ (or set of meeting IDs).

Each ‘meetingID’ can have multiple recordings. Each recording
(returned in the XML described below) has a ‘recordID’, which is
computed as ‘meetingID’-’createTime’.

Each ‘recordID’ can have multiple playback formats. For BigBlueButton
0.8, the built-in playback format, called simple, will playback slides
+ audio. By adding your own ingest and processing scripts you can add
additional playback formats to BigBlueButton 0.8.

There will be a time lag between the end of a meeting and the
availability of one (or more) playback formats. This time lag depends
on how long a given ingest and processing script takes to process the
raw media and XML events recorded by BigBlueButton into a format for
playback.

For each type of playback format, BigBlueButton returns a url and
length. An example is

<format>
<type>simple</type>
<url>http://server.com/simple/playback?recordID=183f0bf3a0982a127bdb8161-1308597520</url>
<length>62</length>
</format>


There are three different usages for getRecordings

getRecordings?checksum=2134132421342134
The getRecordings API call will return a list of all recordings on the
BigBlueButton server that are available for playback.

getRecordings?meetingID=CS101&checksum=457897ew56654
If the optional parameter meetingID is passed then BigBlueButton will
return all the recordings for the given meetingID that are available
for playback.

getRecordings?meetingID=CS101%2CCS102&checksum=457897ew56654
BigBlueButton will return all the recordings that are available for
playback for a set of meetingIDs. Note, the string must URL encoded
(UTF-8).

The information returned from getRecordings includes any meta_*
parameters initially passed using the create call.

Examples of response:


No Recordings
<response>
<returncode>SUCCESS</returncode>
<messageKey>noRecordings</messageKey>
<message>No recordings available</message>
</response>

Get Recordings
<response>
<returncode>SUCCESS</returncode>
<recordings>
<recording>
<recordID>183f0bf3a0982a127bdb8161-1308597520</recordID>
<meetingID>CS101</meetingID>
<name><![CDATA[On-line session for CS 101]]></name>
<published>false</published>
<startTime>Thu Mar 04 14:05:56 UTC 2010</startTime>
<endTime>Thu Mar 04 15:01:01 UTC 2010</endTime>
<metadata>
<title><![CDATA[Test Recording]]></title>
<subject><![CDATA[English 232 session]]></subject>
<description><![CDATA[First Class]]></description>
<creator><![CDATA[Fred Dixon]]></creator>
<contributor><![CDATA[Richard Alam]]></contributor>
<language><![CDATA[en_US]]></language>
</metadata>
<playback>
<format>
<type>simple</type>
<url>http://server.com/simple/playback?recordID=183f0bf3a0982a127bdb8161-1308597520</url>
<length>62</length>
</format>
</playback>
</recording>
<recording>
<recordID>183f0bf3a0982a127bdb8161-13085974450</recordID>
<meetingID>CS102</meetingID>
...
</recording>
</recordings>
<messageKey/>
<message/>
</response>

8. Add ‘setRecordingsPublish’ API call


Set the <publish>..</publish> value to true or false in the
getRecordings result for one (or more) recordings.

You can also pass a set of recordIDs by separating them by commas.

recordID[,recordID]*
type: string

checksum
type: string


IC – Incorrect Checksum
<response>
<returncode>FAILED</returncode>
<message_key>checksumError</messageKey>
<message>You did not pass the checksum security check</message>
</response>

DNE – Does Not Exist
<response>
<returncode>FAILED</returncode>
<message_key>notFound</messageKey>
<message>We could not find a recording with that recordID</message>
</response>

Publish
<response>
<returncode>SUCCESS</returncode>
<published>true</published>
</response>

9. deleteRecording


Delete one (or more) recordings from the BigBlueButton server. You
can also pass a set of recordIDs by separating them by commas.


recordID[,recordID]*
type: string

checksum
type: string

DNE – Does Not Exist
<response>
<returncode>FAILED</returncode>
<message_key>notFound</messageKey>
<message>We could not find a recording with that recordID</message>
</response>

Success
<response>
<returncode>SUCCESS</returncode>
<deleted>true</deleted>
</response>


** Summary

Lots of details above. Again, we tried to keep the additions to the
API as minimal as possible while enabling flexibility for creating,
accessing, and managing the recordings in BigBlueButton 0.8.

We welcome your feedback.

Regards,... Fred

Temuujin Khenmedekh

unread,
Jun 30, 2011, 9:23:14 AM6/30/11
to bigblueb...@googlegroups.com

Hi thanks for all your hard work guys. So when is the release date for this ?

> --
> You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
> To post to this group, send email to bigblueb...@googlegroups.com.
> To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/bigbluebutton-dev?hl=en.
>

Fred Dixon

unread,
Jun 30, 2011, 9:29:17 AM6/30/11
to bigblueb...@googlegroups.com
Hi Temuujin,

We release on quality, not dates.

However, you can tell when an iteration is getting close to a release
when it enters beta. We still a few weeks (not months!) away from a
beta. Our beta cycles are historically four to six weeks long, but
they will be as long (or as short) as needed to ensure we have a
quality release.

Our last release was BigblueButton 0.71, released on January 13, 2011.

This has been a long development cycle for us, and we're looking
forward to getting to beta.

Regards,... Fred

cforce

unread,
Jul 1, 2011, 4:16:21 AM7/1/11
to bigblueb...@googlegroups.com
Item 6.  "join can now pass ‘createTime’ parameter" is very interesting.

Juts to be sure. Can i prevent users to join with a invite url several times, or can i prevent to only join the meeting once?

Please provide more information, i don't really understand what this time param does.

Fred Dixon

unread,
Jul 1, 2011, 7:02:52 AM7/1/11
to bigblueb...@googlegroups.com
Hi cforce,

With a bit more thought ... BigBlueButton could reject the join URL if
a user with the same userID is already in the meeting. If you have
two accounts on your server with the name 'cforce', but they both have
different IDs in your system, both could still join.

Since the userID parameter is optional, a 3rd party application could
omit the userID and essentially disable such a check.

Regards,... Fred

> --
> You received this message because you are subscribed to the Google Groups
> "BigBlueButton-dev" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/bigbluebutton-dev/-/SqShKHeL4T4J.

Fabi

unread,
Jul 1, 2011, 8:16:54 AM7/1/11
to bigblueb...@googlegroups.com
How can i bind a userid with a username and and attende passwort.
Till now there is one url for all attendes with the same passwort and the same base url.
How can i use the new feature to send out join urls, which can't be copied (means reuse the same url in paralell) and make it impossible or at least difficlut tu guess join urls?


2011/7/1 Fred Dixon <ffd...@gmail.com>

Fred Dixon

unread,
Jul 1, 2011, 8:47:18 AM7/1/11
to bigblueb...@googlegroups.com
Hi Fabi,

> How can i bind a userid with a username and and attende passwort.
> Till now there is one url for all attendes with the same passwort and the
> same base url.

Just to be clear, BigBlueButton does not have a user/password
database. Validation of the user is the responsibility of the 3rd
party application. Once validated, the 3rd party application creates
for the user a join URL and returns it to the user's browser. The
user is then logged into BigBlueButton.

Assuming for the moment you are a developer and are integrating
BigBlueButton into your application, then the invite URLs you send out
could point to your application, not directly to BigBlueButton. When
a user clicks on the invite URL, they are redirected to your
application first, at which point you can validate them first before
returning back the final join URL for BigBlueButton.

For example, the API example for creating a meeting at

http://demo.bigbluebutton.org/bigbluebutton/demo/create.jsp

create an invite URL that, when clicked, asks the user for their name.
The logic of create.jsp could be extended (or integrated into another
application) to also ask them for a password as well.

If BigBlueButton 0.8 enforces a unique userIDs in a session, then if
two people use the same joinURL, once one of them joins the session,
BigBlueButton would prevent the other from joining.

Regards,... Fred

Leonardo Daronco

unread,
Jul 27, 2011, 9:33:39 PM7/27/11
to bigblueb...@googlegroups.com
Hi Fred,

Very nice and detailed email.
I got some comments and questions about the API.

1)
The recordings will be retrieved using the "meetingID". Currently, our web app generates a random "meetingID" whenever a meeting is created. We do that to prevent the re-use of the join URL and to avoid problems when "end" is called (see below).
With the new "createTime" param I think the re-use of join URLs is solved. And we can also use the "userID" for this purpose.

But the issue with "end" will still exist. Whenever you call "end" the target "meetingID" will be invalid until this meeting is removed from memory. So the user will not be able to join his meeting again unless we change the "meetingID". 

So, if we change the "meetingID" as we're doing today it will be harder to retrieve all recordings for a specific meeting (or for a "room", where several meetings can happen). But if we don't change it we have that issue with the "end" calls.

Why is it not possible to call "create" using the same "meetingID" of a meeting that "hasBeenForciblyEnded"?
The docs point to issue 394 (http://code.google.com/p/bigbluebutton/issues/detail?id=394) and state that "Now, after calling "end" to forcibly end a meeting, you are not allowed to join that meeting again". Isn't this the same join URL re-use issue that "createTime" and "userID" can solve now?

2)
This is related to the previous question. Let's say I do the following:
* Create a meeting at "createTime" = 1000
* I join this meeting
* I leave the meeting (I didn't call "end", I just left)
* I wait some time and then create this meeting again (same "meetingID") at "createTime" = 5000

Now if I call "getMeetingInfo" for this meeting the "createTime" will be 1000, right?
Wouldn't be better if it was updated to 5000?

I mean that whenever I call "create" I want to start the meeting again. If it's already running, that's ok, I will get an error. But if it is *not* running, maybe it could be created again (or just updated using the parameters passed to "create").

3)
Some parameters passed to "create" are not returned by "getMeetingInfo". They are:
* welcome
* dialNumber
* voiceBridge
* logoutURL
* name

This is not a major problem, but I think it would be nice to be able to fetch from BigBlueButton all the parameters used to create a room. 

If my app created the meeting I will have access to these parameters. But if some other app created a meeting in the server I use (I guess this is not recommended, but it's possible :-) ), I will not have access to all of it's parameters. The "voiceBridge" might be the most important one in this case, to prevent duplicated values.

4)

With a bit more thought ... BigBlueButton could reject the join URL if
a user with the same userID is already in the meeting.  If you have
two accounts on your server with the name 'cforce', but they both have
different IDs in your system, both could still join.

You said that "BigBlueButton *could* reject the join URL". Is this implemented already or will it be in 0.8? Or you're just considering it but it is not implemented yet? 

5)
Will the "maxParticipants" parameter for "create" work in 0.8? Or maybe will it be removed?


That's all for now. Thanks in advance!

Regards,
Leonardo Crauss Daronco

Cameron Banta

unread,
Jul 27, 2011, 10:02:17 PM7/27/11
to bigblueb...@googlegroups.com
For what it's worth, here's my thoughts on the reusing of urls.

To improve security, I think that all of the API calls should take an optional current date and time parameter (a unix timestamp or iso8601 date and time, or whatever). If the current time is present, the server will check to see that it is within some amount (probably a minute or two) of the current time - and reject the api call if not. If the current time parameter is not present, the call will just succeed (for backward compatibility so as not to break things).

This allows the end user (developer) using the API to decide if they want the extra security of a constantly changing parameter. This with the salt/checksum will help prevent a url from being reused. Of course it can still be reused within that small time window.

-Cameron

Fred Dixon

unread,
Jul 28, 2011, 11:16:05 PM7/28/11
to BigBlueButton-dev
Hi Cameron,

Good suggestion.

However, one problem with this approach is the synchronization of
server times. If the caller's server clock is more than two minutes
out of sync with the BigBlueButton's server clock, for example, then
the API calls that requires a timestamp within one minute of the
server's timestamp will always be rejected.

To assist in synchronization, one approach could be to return the
BigBlueButton server's timestamp with the /bigbluebutton/api call,
such as having the call

http://demo.bigbluebutton.org/bigbluebutton/api

return

<response>
<returncode>SUCCESS</returncode>
<version>0.7</version>
<timestamp>3245323344</timestamp>
</response>

This would allow the caller to get an accurate timestamp from the
BigBlueButton server for the next API call (or for calculating
subsequent API calls) so that the timestamp passed in would be within
the acceptance window.

We need to study this more ... we're not security experts, and we need
to spend some time researching how other protocols (such as OAuth)
make their APIs secure.

Regards,... Fred
--
http://code.google.com/p/bigbluebutton/wiki/FAQ#BigBlueButton_Committer
> > > On Fri, Jul 1, 2011 at 8:16 AM, Fabi <fabismai...@googlemail.com
> > <mailto:fabismai...@googlemail.com>> wrote:
> > > > How can i bind a userid with a username and and attende passwort.
> > > > Till now there is one url for all attendes with the same passwort
> > and the
> > > > same base url.
> > > > How can i use the new feature to send out join urls, which can't
> > be copied
> > > > (means reuse the same url in paralell) and make it impossible or
> > at least
> > > > difficlut tu guess join urls?
>
> > > > 2011/7/1 Fred Dixon <ffdi...@gmail.com <mailto:ffdi...@gmail.com>>
> > <mailto:bigblueb...@googlegroups.com>.
> > > >> > To unsubscribe from this group, send email to
> > > >> > bigbluebutton-...@googlegroups.com
> > <mailto:bigbluebutton-dev%2Bunsu...@googlegroups.com>.
> > > >> > For more options, visit this group at
> > > >> >http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
> > > >> --
> > > >> You received this message because you are subscribed to the
> > Google Groups
> > > >> "BigBlueButton-dev" group.
> > > >> To post to this group, send email to
> > bigblueb...@googlegroups.com
> > <mailto:bigblueb...@googlegroups.com>.
> > > >> To unsubscribe from this group, send email to
> > > >> bigbluebutton-...@googlegroups.com
> > <mailto:bigbluebutton-dev%2Bunsu...@googlegroups.com>.
> > > >> For more options, visit this group at
> > > >>http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "BigBlueButton-dev" group.
> > > > To post to this group, send email to
> > bigblueb...@googlegroups.com
> > <mailto:bigblueb...@googlegroups.com>.
> > > > To unsubscribe from this group, send email to
> > > > bigbluebutton-...@googlegroups.com
> > <mailto:bigbluebutton-dev%2Bunsu...@googlegroups.com>.
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google
> > Groups "BigBlueButton-dev" group.
> > > To post to this group, send email to
> > bigblueb...@googlegroups.com
> > <mailto:bigblueb...@googlegroups.com>.
> > > To unsubscribe from this group, send email to
> > bigbluebutton-...@googlegroups.com
> > <mailto:bigbluebutton-dev%2Bunsu...@googlegroups.com>.
> > > For more options, visit this group at
> >http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "BigBlueButton-dev" group.
> > To post to this group, send email to
>
> ...
>
> read more »

Ruediger Kannengiesser

unread,
Jul 29, 2011, 2:23:29 AM7/29/11
to bigblueb...@googlegroups.com, Ahmet
Hello Fred,
 
my name is Ruediger from Germany. I am a new member in the BBB - Fan Club.
 
We are in the realization phase of a huge e-Learning and e-Conferencing environment, using
 
Drupal
Moodle
BBB
 
The Target is to build up a professional environment for students, professors and conference members with a number of participants that our system is able to handle. We decided for BBB because we´ve had the best feeling for the tool. But what we couldn´t figure out were data for the biggest BBB - installation.
 
The following parameters we couldn´t check:
biggest installation with BBB
- numbers of user
- bandwith
- server - power
- quality of video
- quality of audio
- both together
 
We are planning a really huge environment, even to build up a real alternate to the professional e-Conferencing systems.
 
It would be great to get some informations ore information sources. Greatings from Germany, Ruediger. 

p.s. I am not the technician. I am the General manager of the company, just founded. So please do not lough if I ask "stupid" questions. 


Rüdiger Kannengießer 

 
> Date: Thu, 28 Jul 2011 20:16:05 -0700
> Subject: [bigbluebutton-dev] Re: Request for Feedback: API changes to BigBlueButton 0.8
> From: ffd...@gmail.com
> To: bigblueb...@googlegroups.com
> To post to this group, send email to bigblueb...@googlegroups.com.
> To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.

Fred Dixon

unread,
Jul 29, 2011, 5:39:36 AM7/29/11
to bigblueb...@googlegroups.com
Hi Ruediger,

We didn't know we had a BigBlueButton Fan Club :-).

First off, check out our FAQ on maximum number of simultaneous users

http://code.google.com/p/bigbluebutton/wiki/FAQ#How_many_simultaneous_users_can_a_BigBlueButton_server_support?

This FAQ entry gives you some suggestions in how to stress test your server.


For bandwidth usage, see

http://code.google.com/p/bigbluebutton/wiki/FAQ#What_are_the_bandwidth_requirements_for_running_a_BigBlueButton

and recommended server

http://code.google.com/p/bigbluebutton/wiki/FAQ#What_are_the_bandwidth_requirements_for_running_a_BigBlueButton

and video quality

http://code.google.com/p/bigbluebutton/wiki/FAQ#How_do_I_change_the_video_quality_of_the_shared_webcams?


The audio quality will improve in BigBlueButton 0.8 as we move to
wideband speex. The increased audio quality will require the
BigBlueButton server (specifically FreeSWITCH) to work harder to
transcode audio. See

http://groups.google.com/group/bigbluebutton-dev/browse_thread/thread/a36d61df9b9fc45b#


Finally, there is no formula for calculating # of users given the
number of variables. Your best approach is to your server and its
bandwidth with a number of users that reflect typical usage (you can
simulate large number of users by having ten friends each start a
BigBlueButton session in a browser tab) to determine the maximum load.

There are lots of items ahead on our roadmap, see

http://code.google.com/p/bigbluebutton/wiki/RoadMap1dot0

At the moment, the core development team is focused on making sure the
experience of using BigBlueButton for 25 users or less in a session
works really, really well. There is more work to be done, and the
shift to scaling BigBlueButton to large number of users will follow
it.

Fred Dixon

unread,
Aug 10, 2011, 7:39:55 AM8/10/11
to BigBlueButton-dev
Leonardo,

Thanks for your feedback! Here's our response below.


1)

When an ‘end’ API call is received, the API controller (bbb-web)
messages red5 (bbb-apps) to eject all the users. When users leave the
session, they call the API controller (bbb-web) to get the logouURL
associated with the meeting.

We’ve experimented with instantly purging the meeting from the API
controller (so you could immediately call ‘create’ with the same
meetingID), but there is a race condition where clients logout and the
API controller no longer has the meeting, and it throws an exception
when requested for a non-existent meetingID.

We agree that when you call 'end', the meeting is over, and you should
be able to call 'create' immediately afterwards. We'll look at
modifying it during the beta testing to match that behavior (no
promises!). We'll track the effort in this issue

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



Here's a bit more infor on how it works now.



In BigBlueButton there is a background process that runs every minute
to remove meetings that have finished (no users are present) or have
been ended. The background process determines if either of these
conditions *and* at least the number of minutes in
defaultMeetingExpireDuration has passed, which is defined in


/var/lib/tomcat6/webapps/bigbluebutton/WEB-INF/classes/
bigbluebutton.properties


and is default to 1 minute


# The number of minutes before the system removes the meeting from
memory.
defaultMeetingExpireDuration=1


This means there will be at least one minute (maximum of 2) between
the call of the ‘end’ to where the meeting is deleted from memory and
you can call ‘create’ using the same meetingID.



(2)


Once the meeting has been deleted from memory (as described above),
you have a clean slate. Calling ‘create’ will set a new createTime
for the meeting.


(3)


We don't have any specific design behind returning only a portion of
the parameters, other than it's an optimization and it 'encourages'
3rd party applications to maintain state.

Some developers initialy think that BigBlueButton has a database that
it maintains a record of all current and future meetings. It
doesn't. Meetings are only in memory and only last until they are
deleted or the software/server reboots.

The 3rd party application should assume the BigBlueButton server may
reboot at anytime (by an administrator, software error, power cycle,
etc.) and if the 3d party application has all this information on a
meeting, it can recreate the meeting anew after reboot.

At the moment, we're likely to leave it as is and just focus on fixing
bugs for the upcoming beta test.


(4)


Good suggestion, but after some thought implementation, but
restricting 'join' URLs to contain unique userIDs would need to be
done as a parameter to bigbluebutton.properties. If we added this
capability into BigBlueButton 0.8 as default, it will likely break
some existing integrations.

We've added an enhancement request for this at

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

Will look at doing this in a future iteration. Again, we're pretty
focused on finishing BigBlueButton 0.8 for beta testing/release.

(5)


We're not planning on implementating maxParticipants.

There are two constraints as play here. The
first is you create a meeting, it’s parameters are fixed. You can’t
change the moderator password half way through the meeting. The
second is we want to minimize the business logic in the BigBlueButton
server.


Here’s the example for not putting maxParticipants in BigBlueButton.
Let’s
say you create a meeting with 10 users, and half way through, you want
to have 11. If the BigBlueButton server enforced maxParticipants, you
can’t (you can't change the parameters after create).

But if the calling application enforced the maxParticipants (such as
querying the meeting before returning a join URL to ensure the meeting
didn’t exceed its max number of participants), then the calling
application
could dynamically change the maximum number whenever it wants.

Thanks again Leonardo for your feedback!
On Jul 27, 9:33 pm, Leonardo Daronco <leonardodaro...@gmail.com>
wrote:
> > On Fri, Jul 1, 2011 at 8:16 AM, Fabi <fabismai...@googlemail.com> wrote:
> > > How can i bind a userid with a username and and attende passwort.
> > > Till now there is one url for all attendes with the same passwort and
> the
> > > same base url.
> > > How can i use the new feature to send out join urls, which can't be
> copied
> > > (means reuse the same url in paralell) and make it impossible or at
> least
> > > difficlut tu guess join urls?
>
> > > 2011/7/1 Fred Dixon <ffdi...@gmail.com>
>
> > >> Hi cforce,
>
> > >> With a bit more thought ... BigBlueButton could reject the join URL if
> > >> a user with the same userID is already in the meeting.  If you have
> > >> two accounts on your server with the name 'cforce', but they both have
> > >> different IDs in your system, both could still join.
>
> > >> Since the userID parameter is optional, a 3rd party application could
> > >> omit the userID and essentially disable such a check.
>
> > >> Regards,... Fred
>
> > >> On Fri, Jul 1, 2011 at 4:16 AM, cforce <fabismai...@googlemail.com>
Reply all
Reply to author
Forward
0 new messages