Re: [vmeet] timeframe

"Brian Rosen" <> Fri, 15 May 2009 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97B8728C221 for <>; Fri, 15 May 2009 09:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.504
X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0DknT-w2F6Oa for <>; Fri, 15 May 2009 09:18:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7443128C159 for <>; Fri, 15 May 2009 09:18:00 -0700 (PDT)
Received: from ([] helo=BROS3VMxp) by with esmtpa (Exim 4.69) (envelope-from <>) id 1M507y-0006cf-Ur; Fri, 15 May 2009 11:19:19 -0500
From: Brian Rosen <>
To: 'Dave Cridland' <>, 'Doug Otis' <>, 'Dave CROCKER' <>, 'IETF remote participation meeting services discussion' <>, 'John Leslie' <>
References: <20090507175356.GG32848@verdi> <> <> <20090513025653.GD14375@verdi> <> <20090514221220.GA70521@verdi> <> <20090515000426.GC70521@verdi> <> <11966.1242403570.072307@puncture>
In-Reply-To: <11966.1242403570.072307@puncture>
Date: Fri, 15 May 2009 12:19:22 -0400
Message-ID: <053301c9d578$ea0863e0$be192ba0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcnVdxLMvwQVZOPLTJuM295lE1eRRgAAT0pA
Content-language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [vmeet] timeframe
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF remote participation meeting services discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 May 2009 16:18:01 -0000

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?


> -----Original Message-----
> From: [] 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 - -
>   - acap://
>   -
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
> _______________________________________________
> NOTE WELL: This list operates according to