Subject: Re: MBONE access

From: Keith Moore <[email-masked]>
Date: Thu, 4 Mar 2004 10:24:17 -0500

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 :)