Re: [vmeet] timeframe

What I want is a physical light on a pole that lights up when a webex or
other "hand raise" occurs.  I'd also like, but don't expect, a sensor on the
microphones to reflect someone standing at the mic as a hand raise in WebEx.
The former allows the chair, or any other participant in the room, to see at
a glance that a remote participant is queued at the "mic".   The latter
allows a remote participant to know that there is a local participant
queued.  The latter could be integrated into the "who is at the mic"
mechanism (?RFID tag) that has been tried.

I think we could hack the light on a pole fairly easily if WebEx has an API.
Does it?

Brian

> -----Original Message-----
> From: vmeet-bounces@ietf.org [mailto:vmeet-bounces@ietf.org] On Behalf
> Of Dave Cridland
> Sent: Friday, May 15, 2009 12:06 PM
> To: Doug Otis; Dave CROCKER; IETF remote participation meeting services
> discussion; John Leslie
> Subject: Re: [vmeet] timeframe
> 
> On Fri May 15 03:27:15 2009, Doug Otis wrote:
> > For smaller groups, WebEx Meeting using a telephone bridge works
> > well,  but it does not offer a Q & A window.  Raising a hand icon
> > is only  seen by the presenter.  This will likely frustrate
> > participants who  would like to make a point, but feel ignored by a
> > likely distracted  host.  A question queue seems an important
> > requirement to assure  participants they are being given a fair
> > chance.  Otherwise, the floor  is likely to ceded to those willing
> > to ask for forgiveness rather than  permission.  The chat and
> > window control for remote participants does  not compare favorably
> > to a simpler jabber client.  On the other hand,  the polling
> > feature is very nice and allows participation in "hums."
> 
> FWIW, some existing XMPP clients use the MUC presence to signal
> voting, and they could just as easily signal a "I'd like the floor".
> However, the current usage of the MUC rooms as a "back channel", for
> side-discussions, makes actual floor control tricky - XEP-0045 does
> include "voice requests" and control, and the implementation the IETF
> uses supports these, I believe, but I'd consider removal of voice to
> be a problem, unless each working group had both a "presentation" MUC
> *and* a backchannel, which becomes unweidly quite quickly.
> 
> Incidentally, my guess would be that a voting/hand-raising
> specification or two could be written, and implemented, by Stockholm,
> in cross-platform clients. If you want this to happen, please say so,
> and I'll be happy to drive this forward.
> 
> There's scope for signalling other things through MUC, too, but
> anything that requires server mediation has a longer turn-around
> time, obviously. To get a client-client signalling mechanism going
> only needs, after all, one client developer to bite.
> 
> Dave.
> --
> Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
>   - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>   - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html.
> https://www.ietf.org/mailman/listinfo/vmeet