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