FWIW, I tried to participate in a couple of WG meetings this week. I
had to go to work to get multicast access - efforts to set up a tunnel
to my home failed (partially because there wasn't any obvious way to try
it out in advance of the actual meeting).
Even when I could get multicast access, I could get video but the audio
would cut out after a few seconds. This was with the latest QuickTime
player for the mac. I also tried VLC for the mac but that didn't work
at all.
We've been experimenting with this stuff for longer than I can remember.
I'd like for this stuff to really be useful. Here's my list of things
that I think are necessary for it to be useful:
1. We need to broadcast _every_ session, or at least most of them.
That has a number of implications. It means we need more bandwidth.
It might be that we would have to use fewer codecs - maybe just
H.261. It might also mean that we need to set up some meeting rooms
differently so that a single camera would suffice (thus removing the
need for someone to switch between cameras). Comments from the floor
might have to be made from the front of the room.
2. We need the ability to access these transmissions via unicast.
That probably means that we need willing parties on various
continents to provide tunnel endpoints and/or proxies and/or
reflectors.
3. The client software needed to participate must be available to
everybody.
That probably means using an open source tool as the baseline. If it
happens to also work with proprietary tools, so much the better.
4. It needs to be possible to test things well in advance of the
meeting.
By the time the meeting is underway, there's not enough time to debug
tunnel setup, client problems, etc. This probably means having live
video feeds set up in advance, using the same codecs and tools that
will be used at the meeting. Ideally there should be feeds sourced
from somewhere near the meeting site's point of attachment to the
network.
5. In my limited experience, Jabber is an acceptable way for remote
participants to make comments - provided there is someone willing to
read those comments to those physically present at the meeting. But
if this were to be a widespread practice, we'd need to have some
reasonably fair way to divide time between the local participants
and the remote participants.
6. We should require those who use slides to make them available for
download, in a portable format, well in advance of the meeting.
I realize this is a tall order. I'm trying to make a realistic
statement of what it takes for remote access to meetings to be useful.
(I realize it might not seem realistic to actually _do_ this, but if
it's not realistic, we may as well admit it.)
I suspect the problem boils down to _money_. Money would buy more
bandwidth. Money would help get local tunnel/redirector/proxies set up.
Money would help software development if open source tools needed to be
tweaked. Money would pay for more on-site equipment and operators.
If this stuff _worked_ I would be willing to pay something close
to the full conference fee to attend the conference remotely, for those
cases when I couldn't be there in person. Though I guess I wonder
whether there would ever be enough remote participants to cover the
expenses. (for that matter, if it _worked_, would lots of people stop
travelling to meetings?)
If it is feasible it should be possible to implement this in stages:
1. Pick an open source client. Tweak it as necessary. Set up
pointers in appropriate web pages so that IETFers could easily
find and download the code. Provide instructions for how to
configure and use it.
2. Set up tunnel endpoints / proxies / redirectors.
If it's necessary to limit access to IETFers, find a way to do this.
3. Set up live video/audio feeds.
If it's necessary to limit access to IETFers, find a way to do this.
4. Encourage IETFers to download clients, test with the live feeds,
and provide feedback.
5. Try this in one or two meeting rooms. Experiment with a single
microphone setup in one room. Once it works, expand it gradually to
include additional meeting rooms (perhaps even during the same week).
6. Once it is demonstrated to work, start charging money :)