GSoc2010 Questions

[KushalP]

I'm really interested in both the HTML5 client and the RMTP HTML5
client implementation ideas, but would like a little more info.

Specifically, the RMTP client would need to have another
implementation at the server-side to handle the websockets (node.js
maybe?) as it doesn't look like you can get down to the core network
layer with websockets that the Python/Java client implementations you
provided use. Also, any work that would be done on this is likely to
only work in Chrome as it's the only browser that safely implements
the websockets api.

What are your expectations in terms of working features for the RMTP
client? Is there any particular way that you'd like it to operate? I'd
like to read around the area as much as possible before I think about
applying so any further information you can give would be much
appreciated.

I've had a quick look around and there seems to be a lack of
information in terms of good websocket implementations out there, but
the RMTP client is a whole new world of crazy -- probably why I'm
interested in it.

[Denis Zgonjanin]

Hi Kusha,

That's great to hear you're interested in this, I think it's an awesome project!

At first I was under the impression that you could actually get down to the TCP/IP layer with websockets, but I guess you're right. In that case yes we'd need something on the server to handle the data. Not sure if it would have to be written in server-side JavaScript, perhaps there is (or if there isn't I'm sure somebody will come up with it soon) a Java server side websocket implementation.

It's perfectly fine that it would work only in Chrome. All other major browsers will eventually support HTML5 full spec. We're just trying to stay ahead of the game here and on the cutting edge

As for the working features, we're not expecting you to have working two way streaming live video/audio by the end of the summer. The RTMP client should be able to communicate with the existing server implementation (red5 server), either directly or through a server side node.js proxy you propose. It should be able to do a proper handshake, call and receive method calls, and possibly support remote Shared Objects. Ideally it would run in it's own thread, using the HTML5 Web Workers implementation (http://dev.w3.org/html5/workers/).

I've pre-ordered a couple of HTML5 books but unfortunately they won't be out until June. So in the case of HTML5 Google is your best and only friend, for now. When it comes to RTMP however we've got lots of info and experience around here so you can expect a lot of help in that area whenever you need it. The RTMP spec itself is now open and has been published by Adobe - http://www.adobe.com/devnet/rtmp/. Reference implementations exist, in Java as part of red5; in Python - http://rtmpy.org/wiki/RTMP; and also in Erlang if functional languages are your thing - http://code.google.com/p/erlyvideo/.

I've only looked at websockets in passing, and since html5 is so new very few people know much about websockets which is why this project should be quite challenging. Of the two HTML5 project ideas we have up there this one is probably a bit harder. Feel free to ask for anything else you need to know. Also if you want to meet online with some of the developers, we can schedule that as well.

- Denis

--
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.

[Richard Alam]

Have you taken a look at this?
http://www.kaazing.org/confluence/display/KAAZING/Home

Haven't looked much into it but perhaps a good source of info or a
good place to start.

Richard

--
---
BigBlueButton
http://www.bigbluebutton.org
http://code.google.com/p/bigbluebutton

[KushalP]

That's another possibility. The only reason I stated node.js is the
fact that it's non-blocking and is known to be very lightweight. It
also has one of the easiest to implement websocket implementations
I've ever seen: http://github.com/ncr/node.ws.js

On Mar 19, 2:39 pm, Richard Alam <ritza...@gmail.com> wrote:
> Have you taken a look at this?http://www.kaazing.org/confluence/display/KAAZING/Home

> > as part of red5; in Python -http://rtmpy.org/wiki/RTMP;and also in Erlang

> > if functional languages are your thing -
> >http://code.google.com/p/erlyvideo/.
>
> > I've only looked at websockets in passing, and since html5 is so new very
> > few people know much about websockets which is why this project should be
> > quite challenging. Of the two HTML5 project ideas we have up there this one
> > is probably a bit harder. Feel free to ask for anything else you need to
> > know. Also if you want to meet online with some of the developers, we can
> > schedule that as well.
>
> > - Denis
>

[KushalP]

Hi Denis,

My only worry with the RTMP client is that the spec requires certain
packet structures (TCP). If it's possible to create a wrapper for the
RTMP server — to produce JSON or XML — then an RTMP client in JS would
definitely be feasible.

The only reason for the wrapper is that the websockets don't allow you
to get that close to the TCP layer. Unless of course, you guys can
pull some strings at Google? :P

Another worry of mine is that all of this abstraction is may increase
latency.

Meeting online with a few developers sounds good. I'm London-based, so
we may have to come to some kind of agreement in terms of timings. Is
there an IRC channel or does all communication occur through this
group?

Whoever does take this project on, should get in touch with someone on
the Chromium team for websocket-related questions though. As there's a
sparse amount of information involving the spec and it's being
spearheaded by Google so I'd assume they'd know a lot more about it.

- Kushal

On Mar 19, 1:01 pm, Denis Zgonjanin <me.s...@gmail.com> wrote:
> Hi Kusha,
>
> That's great to hear you're interested in this, I think it's an awesome
> project!
>
> At first I was under the impression that you could actually get down to the
> TCP/IP layer with websockets, but I guess you're right. In that case yes
> we'd need something on the server to handle the data. Not sure if it would
> have to be written in server-side JavaScript, perhaps there is (or if there
> isn't I'm sure somebody will come up with it soon) a Java server side
> websocket implementation.
>
> It's perfectly fine that it would work only in Chrome. All other major
> browsers will eventually support HTML5 full spec. We're just trying to stay
> ahead of the game here and on the cutting edge
>
> As for the working features, we're not expecting you to have working two way
> streaming live video/audio by the end of the summer. The RTMP client should
> be able to communicate with the existing server implementation (red5
> server), either directly or through a server side node.js proxy you propose.
> It should be able to do a proper handshake, call and receive method calls,
> and possibly support remote Shared Objects. Ideally it would run in it's own
> thread, using the HTML5 Web Workers implementation (http://dev.w3.org/html5/workers/).
>
> I've pre-ordered a couple of HTML5 books but unfortunately they won't be out
> until June. So in the case of HTML5 Google is your best and only friend, for
> now. When it comes to RTMP however we've got lots of info and experience
> around here so you can expect a lot of help in that area whenever you need

> it. The RTMP spec itself is now open and has been published by Adobe -http://www.adobe.com/devnet/rtmp/. Reference implementations exist, in Java
> as part of red5; in Python -http://rtmpy.org/wiki/RTMP;and also in Erlang
> if functional languages are your thing -http://code.google.com/p/erlyvideo/.

> > bigbluebutton-...@googlegroups.com<bigbluebutton-dev%2Bunsubscr i...@googlegroups.com>

[KushalP]

Forget some of my last post.

If you can produce a websocket implementation at the server-side, then
the client-side won't matter. The "wrapper" that's needed is for the
RTMP server to allow websockets. After that it's doable.

My question now is, once you've got the messages to the HTML5 client,
how are you going to show it? Doesn't an RTMP server only utilise
flash-based files? Or is this looking mainly at the audio-only side?

I promise I'll hold off on the questions for a little while now. ;)

- Kushal

> > as part of red5; in Python -http://rtmpy.org/wiki/RTMP;andalso in Erlang

[KushalP]

Dennis,

Here's a java implementation of websockets: http://jwebsocket.org/

- Kushal

On Mar 19, 1:01 pm, Denis Zgonjanin <me.s...@gmail.com> wrote:

> Hi Kusha,
>
> That's great to hear you're interested in this, I think it's an awesome
> project!
>
> At first I was under the impression that you could actually get down to the
> TCP/IP layer with websockets, but I guess you're right. In that case yes
> we'd need something on the server to handle the data. Not sure if it would
> have to be written in server-side JavaScript, perhaps there is (or if there
> isn't I'm sure somebody will come up with it soon) a Java server side
> websocket implementation.
>
> It's perfectly fine that it would work only in Chrome. All other major
> browsers will eventually support HTML5 full spec. We're just trying to stay
> ahead of the game here and on the cutting edge
>
> As for the working features, we're not expecting you to have working two way
> streaming live video/audio by the end of the summer. The RTMP client should
> be able to communicate with the existing server implementation (red5
> server), either directly or through a server side node.js proxy you propose.
> It should be able to do a proper handshake, call and receive method calls,
> and possibly support remote Shared Objects. Ideally it would run in it's own
> thread, using the HTML5 Web Workers implementation (http://dev.w3.org/html5/workers/).
>
> I've pre-ordered a couple of HTML5 books but unfortunately they won't be out
> until June. So in the case of HTML5 Google is your best and only friend, for
> now. When it comes to RTMP however we've got lots of info and experience
> around here so you can expect a lot of help in that area whenever you need

> it. The RTMP spec itself is now open and has been published by Adobe -http://www.adobe.com/devnet/rtmp/. Reference implementations exist, in Java
> as part of red5; in Python -http://rtmpy.org/wiki/RTMP;and also in Erlang
> if functional languages are your thing -http://code.google.com/p/erlyvideo/.

> > bigbluebutton-...@googlegroups.com<bigbluebutton-dev%2Bunsubscr i...@googlegroups.com>

[Denis Zgonjanin]

Hi Kushal,

That java library is an excellent find. If we can do a server side implementation that would be even better, as it keeps the client smaller. RTMP is not for flash only (or it was intended to be, but people use it for a variety of things now), so it shouldn't be a problem using it with JavaScript and HTML5. Pretty much all the communication from the client side to the server right now takes place using RTMP, so we don't want it just for audio/video, but also for remote procedure calls and SharedObjects, which is basically a Flash way of doing real time collaboration across multiple clients.

The idea is to start creating a backwards compatible HTML5 client for BigBlueButton. Since any HTML5 BBB client we create won't be ready for a while, it has to be able to work with the client we have now. We also don't want to have to rewrite the whole server-side of bbb just because we have a shinny new client. So I'm thinking, if we can create a server side application that acts as an intermediary between red5 and the HTML5 client side, that would be perfect! Any traffic coming from the flash client would go directly to red5, which would also talk to the new HTML5 Websockets app on the server, which would talk to the HTML5 client.

Anyway keep the questions going, this is really good stuff.

- Denis

To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.

[Lakshan]

Hi Denis,

I'm too interested in the HTML5 client idea and was following this
discussion. BTW, I too have several questions to clarify.

What sort of functionality you expect to have in the HTML5 client? Do
you plan to support voice and video inputs with this?
If it is the case, as I see websockets alone would not be sufficient.
Though, we could use WebSockets for streaming the voice/video data,
there must be a mechanism to capture them first.

According to current HTML5 draft specification <device> element and
Stream API seems to serve this purpose (http://www.whatwg.org/specs/
web-apps/current-work/multipage/commands.html#devices) perfectly.
Though it's in the specification, AFAIK there's no browser
implementation of this feature.

Anyway, I believe if we can implement a client using these standards,
it could be a great example on how to do web communications in a
standard compatible manner. However, until browser support arrives we
must at least develop a plugin to support these specifications.

What's your recommendations on this?

Best Regards,
Lakshan
http://laktek.com

On Mar 19, 11:07 pm, Denis Zgonjanin <me.s...@gmail.com> wrote:
> Hi Kushal,
>
> That java library is an excellent find. If we can do a server side
> implementation that would be even better, as it keeps the client smaller.
> RTMP is not for flash only (or it was intended to be, but people use it for
> a variety of things now), so it shouldn't be a problem using it
> with JavaScript and HTML5. Pretty much all the communication from the client
> side to the server right now takes place using RTMP, so we don't want it
> just for audio/video, but also for remote procedure calls and SharedObjects,
> which is basically a Flash way of doing real time collaboration across
> multiple clients.
>
> The idea is to start creating a backwards compatible HTML5 client for
> BigBlueButton. Since any HTML5 BBB client we create won't be ready for a
> while, it has to be able to work with the client we have now. We also don't
> want to have to rewrite the whole server-side of bbb just because we have a
> shinny new client. So I'm thinking, if we can create a server side
> application that acts as an intermediary between red5 and the HTML5 client
> side, that would be perfect! Any traffic coming from the flash client would
> go directly to red5, which would also talk to the new HTML5 Websockets app
> on the server, which would talk to the HTML5 client.
>
> Anyway keep the questions going, this is really good stuff.
>
> - Denis
>

> > > as part of red5; in Python -http://rtmpy.org/wiki/RTMP;andalso in

> > > > bigbluebutton-...@googlegroups.com<bigbluebutton-dev%2Bunsu...@googlegroups.com><bigbluebutton-dev%2Bunsubscr

> > i...@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.
> > To unsubscribe from this group, send email to

> > bigbluebutton-...@googlegroups.com<bigbluebutton-dev%2Bunsu...@googlegroups.com>

[Denis Zgonjanin]

Hi Lakshan,

Yes you're right, the websockets aren't enough. We do plan on supporting everything in HTML5 that we currently have with Flash, including video and voice. Video and Audio would need to be captured somehow and then the packets would be streamed using Websockets. I would say that the video capturing part more closely relates to the project idea for the HTML5 interface, but it could very well be a separate project you could develop a proposal on. That's why we put two HTML5 ideas on there, because one would just be too big and general. 

If implementations of the devices part of the protocol are not ready in time, we could do a plug in. Optionally as a proof of concept we could just try streaming content from Video tag to the server, if that's possible. Or an audio file, since audio/video packets are treated pretty much the same way. Then we can just wait for browsers to implement support for devices.

- Denis

To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.

[KushalP]

Hi Dennis,

I'd probably be interested in implementing a middleware layer to RTMP
as well, but this also has it's own questions.

Latency is going to be an issue. The network structure would look
something like: html5 client > middleware > RTMP. Having the
middleware layer on the same server as the RTMP layer would use up an
extra 2 sockets that a high-availability service can't afford.

Does the RTMP spec allow multiple connections for different data
sources through a single TCP socket? Does it assume that all comms
going to a single IP are only for use by that single machine? If so,
producing a middleware could be extremely difficult. If it's possible
to pass a header with a different ID token or the IP of the client
then it would be a little easier.

What would happen in cases of resource contention? How would you
signal priority that the middleware connection is actually handling a
number more clients than the RTMP server is actually getting?

Clearly getting HTML5 functionality working isn't just as simple as
hooking in HTML5 features. If you only allowed the HTML5
implementation to work with future versions of Red5, then it would be
possible to just create a RTMP layer in JS. But having a middleware
layer to connect both the html5 and the legacy RTMP server might cause
some architectural issues.

A lot of the above may just be me over-exaggerating things. I don't
know enough (anything) about the RTMP spec to be making such
judgements yet, or even making such assumptions. It would be great to
know your thoughts on some of the above and also to fill in some of
the blanks in terms of how RTMP works in laymans terms.

- Kushal

> > > > > > bigbluebutton-...@googlegroups.com<bigbluebutton-dev%2Bunsubscr i...@googlegroups.com>
> > <bigbluebutton-dev%2Bunsu...@googlegroups.com<bigbluebutton-dev%252Buns ubsc...@googlegroups.com>

> > ><bigbluebutton-dev%2Bunsubscr
> > > > i...@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.
> > > > To unsubscribe from this group, send email to

> > > > bigbluebutton-...@googlegroups.com<bigbluebutton-dev%2Bunsubscr i...@googlegroups.com>
> > <bigbluebutton-dev%2Bunsu...@googlegroups.com<bigbluebutton-dev%252Buns ubsc...@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.
> > To unsubscribe from this group, send email to

> > bigbluebutton-...@googlegroups.com<bigbluebutton-dev%2Bunsubscr i...@googlegroups.com>

[Denis Zgonjanin]

Hi Kushal,

It's not quite that complicated. Since red5 and the websockets app would run on the same server, we don't need to implement that extra layer from middlewate > RTMP. Or rather we do but it's not going to be through networking. The red5 server runs applications within itself, i.e. applications programmed to work with the server become part of the server once it runs, tying in directly into the code and running on the same JVM process etc... This means that our network structure would just be html5 client > red5 websockets application. The websockets application running within red5 could then just communicate with all relevant red5 classes using simple method calls. This reduces complexity and simplifies many of the issues you raise above. Moreover if we can make the websockets application not specific to bigbluebutton it can be opensourced into it's own project as a red5 extension. This would provide people with a working, mature open source html5 streaming server.

- Denis

To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.

[Andrej]

Hi,

I'm interested in this project as well. I think the best way to avoid
all the server side problems is to use RTMPT which defines the way
RTMP can be tunneled over HTTP. This could be implemented using Ajax
without using websockets at all.

The only problem I see would be how to play or process raw video/audio
stream data from JavaScript.

On Mar 20, 1:52 pm, Denis Zgonjanin <me.s...@gmail.com> wrote:
> Hi Kushal,
>

> It's not quite that complicated. Since red5 and the websockets app would run
> on the same server, we don't need to implement that extra layer from
> middlewate > RTMP. Or rather we do but it's not going to be through
> networking. The red5 server runs applications within itself, i.e.
> applications programmed to work with the server become part of the server
> once it runs, tying in directly into the code and running on the same JVM
> process etc... This means that our network structure would just be html5
> client > red5 websockets application. The websockets application running
> within red5 could then just communicate with all relevant red5 classes using
> simple method calls. This reduces complexity and simplifies many of the
> issues you raise above. Moreover if we can make the websockets application
> not specific to bigbluebutton it can be opensourced into it's own project as
> a red5 extension. This would provide people with a working, mature open
> source html5 streaming server.
>
> - Denis
>

> ...
>
> read more »

[Denis Zgonjanin]

Hi Andrej,

It's a good idea but I would disagree with this. RTMPT is far too slow to be useful. Also the whole idea here is to move away from Ajax/Comet technologies, as they're not really two-way communication but a collection of hacks to get around the inherit limitations of HTTP.

- Denis

--

[Denis Zgonjanin]

Of course the RTMPT slowness is just my personal opinion, others think it works just fine. But because it involves basically polling the server for updates, it increases traffic greatly and I don't think it can really be considered a 'real time' protocol anymore. BigBlueButton does use RTMPT but only when RTMP fails, such as due to a firewall.

To answer the other part of your post about the raw video/audio data, well, I think that's a whole other problem on it's own. Hopefully the HTML5 video tag implementations will be able to handle streaming video/audio packets if we can just serve them to it in a proper form.

Anyway thanks Andrej and everyone else for your interest. This is a great discussion, keep it going. We'll try to schedule a meeting online for some time this week for anyone interested.

- Denis

[Andrej]

But if we use this websocket application integrated into the flash
server, can it actually use its own protocol and use a raw TCP/IP
connection from the server to establish a websocket connection? I
thought the only way FMS server can communicate is RTMP?

On Mar 20, 7:38 pm, Denis Zgonjanin <me.s...@gmail.com> wrote:
> Of course the RTMPT slowness is just my personal opinion, others think it
> works just fine. But because it involves basically polling the server for
> updates, it increases traffic greatly and I don't think it can really be
> considered a 'real time' protocol anymore. BigBlueButton does use RTMPT but
> only when RTMP fails, such as due to a firewall.
>
> To answer the other part of your post about the raw video/audio data, well,
> I think that's a whole other problem on it's own. Hopefully the HTML5 video
> tag implementations will be able to handle streaming video/audio packets if
> we can just serve them to it in a proper form.
>
> Anyway thanks Andrej and everyone else for your interest. This is a great
> discussion, keep it going. We'll try to schedule a meeting online for some
> time this week for anyone interested.
>
> - Denis
>

> On Sat, Mar 20, 2010 at 2:25 PM, Denis Zgonjanin <me.s...@gmail.com> wrote:
> > Hi Andrej,
>
> > It's a good idea but I would disagree with this. RTMPT is far too slow to
> > be useful. Also the whole idea here is to move away from Ajax/Comet
> > technologies, as they're not really two-way communication but a collection
> > of hacks to get around the inherit limitations of HTTP.
>
> > - Denis
>

> ...
>
> read more »

[Denis Zgonjanin]

Yes, FMS can only communicate using RTMP, but we're using red5 which is an open source server which mimics FMS functionality but also does much more. The websockets app that would be integrated into the red5 server would communicate directly with the server using method calls. In essence red5 treats it's applications as part of the server itself. So there's no network traffic going between the websocket app and the server. If you need an example of now a non RTMP application communicates with red5 you can take a look at the Desktop Sharing code, which receives TCP/IP traffic from a Java applet and encodes it on the red5 server to RTMP packets, then sends it out.

- Denis

> ...
>
> read more »

[KushalP]

Hi Dennis,

In that case, building a websocket layer for RTMP is a lot more
feasible.

I just had a read around the HTML5 spec and it seems that any
streaming video would need to be in an MPEG4, H2.64 or Ogg Theora
format to work natively in browsers. I had a brief look to find
browsers that can handle streaming video in HTML5 and it seems that
neither of the big four (Chrome, Firefox, Opera or Safari) have
implemented support for it.

Odds are, the best bet would be to implement the websocket server and
have a basic javascript interpreter for RTMP on the client side until
this is fleshed out.

Alternatively, some development branches of *nix browsers seem to be
able to handle RTP streaming to a limited extent. Although I'm not
sure about how this would fit in with the bigblue/red5 implementations
and what the product is supposed to offer.

- Kushal

On Mar 20, 7:32 pm, Denis Zgonjanin <me.s...@gmail.com> wrote:
> Yes, FMS can only communicate using RTMP, but we're using red5 which is an
> open source server which mimics FMS functionality but also does much more.
> The websockets app that would be integrated into the red5 server would
> communicate directly with the server using method calls. In essence red5
> treats it's applications as part of the server itself. So there's no network
> traffic going between the websocket app and the server. If you need an
> example of now a non RTMP application communicates with red5 you can take a
> look at the Desktop Sharing code, which receives TCP/IP traffic from a Java
> applet and encodes it on the red5 server to RTMP packets, then sends it out.
>
> - Denis
>

> ...
>
> read more »

[Denis Zgonjanin]

Hi Kushal,

Right now bigbluebutton uses H.263 video, and we'll soon be trying to move to H.264, so codec wise there won't be any problems I hope. And I know that browsers probably won't support streaming video by this summer, but that doesn't matter too much. The first concern is to be able to remote procedure calls. Transferring video/audio packets would be another great step, but we don't need to be showing those packets as video at first. We can just confirm they're getting there safely.

I'm reluctant to do any RTP streaming, especially if it would just be for unix broswers. Sounds like a great proof of concept application but we need bigbluebutton to work the same on all major platforms/browsers.

- Denis

> ...
>
> read more »

[Girish Kumar Anem]

Hi Denis,

i am interested in the HTML5 RTMP client project,

i am a MCA(Master of Computer Application) Final year Student.

One of my favorite topic in our curriculum is "Networking", and i also prepared a special seminar on different TUNNELING techniques and protocols and their application in the VoIP, Bittorrent, and other application and also anonymous surfing using HTTP Tunneling techniques.

Coming to RTMP protocol, i am having some doubts about the mode of its implementation, basically following the adobe specification, it uses

 1.HTTP tunneling technique, or 

 2.use raw TCP network and use the port 1935, or

 3.it uses HTTPS tunneling techniques.

I wanted to know  which type of implementation are required in this project and what r the middle that r going to be used if we are using the tunneling path(as tunneling packets need to decrypted on receiving)

Do we need to implement the already existing java implementation as it is with modification, and which implementation is preferred.

Regards

Girish

--------------------------------

ANEM GIRISH KUMAR

MCA 3rd year 

Department of Computer Application

ITER,Bhubaneswar,Orissa,

India

ph:  +91 9937987717, +91 9438734197

[Denis Zgonjanin]

Hi Girish,

Thanks for your interest! For the RTMP client, we're not looking for a solution that uses HTTP tunneling. Instead ideally we'd be looking for a solution that uses HTML5 websockets. A discussion is going on right now on what the best way to implement this is. Perhaps you can add your thoughts to it:

http://groups.google.com/group/bigbluebutton-dev/browse_thread/thread/723848ab21ad8733?hl=en

- Denis

--