Re: [vmeet] Best Practices

Doug Otis <doug.mtview@gmail.com> Tue, 28 April 2009 00:26 UTC

Return-Path: <doug.mtview@gmail.com>
X-Original-To: vmeet@core3.amsl.com
Delivered-To: vmeet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E8E3A6BC5 for <vmeet@core3.amsl.com>; Mon, 27 Apr 2009 17:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43XC+avApP-Z for <vmeet@core3.amsl.com>; Mon, 27 Apr 2009 17:26:38 -0700 (PDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id 8EAD53A68DA for <vMeet@ietf.org>; Mon, 27 Apr 2009 17:26:08 -0700 (PDT)
Received: by wa-out-1112.google.com with SMTP id l35so80444waf.5 for <vMeet@ietf.org>; Mon, 27 Apr 2009 17:27:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=PTz8kjXz/Opvr1co5V0dpXSWTIfrNTn3WgawYmt5Pjs=; b=gBHUAKs23ggAgJbAEFStNaJzNTiR+hgGUW9iXEgizncM/nqIZIaikPvVDfw/aTB7nC 2Idf1BRhI+qPhKybCRTvK5NitEyaSEEaIq/nAOb0CuyP6JtvcT12LWVUJt8/vPSnDKpb 73BPbtFuSPIb+XcnhWmOaymVLMXIFv6do4fII=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=GozMeB3YWUBjoFLeX6bw47j+6GiH4Kmc95ZnPlosAZ4ym0iDvgTAvLngbLfxjNQ7df yOtvOYSEKJ6S3sOH8wGpaBJVyirynuOYIx8D//Do1YvEJ+qthqfWFIUgkv9L/H1+0/04 FDhwwF+LfjnY4ezZWAI3+qF2aZq24NQ+uSyK0=
Received: by 10.114.106.13 with SMTP id e13mr2969206wac.128.1240878449852; Mon, 27 Apr 2009 17:27:29 -0700 (PDT)
Received: from SJC-Office-NAT-219.mail-abuse.org (SJC-Office-NAT-219.mail-abuse.org [168.61.10.219]) by mx.google.com with ESMTPS id n6sm3139671wag.4.2009.04.27.17.27.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Apr 2009 17:27:29 -0700 (PDT)
Message-Id: <F48646FD-6934-4CFC-8A97-AB2104930C6E@gmail.com>
From: Doug Otis <doug.mtview@gmail.com>
To: Fred Baker <fred@cisco.com>
In-Reply-To: <F9A276AD-3FC3-429F-A4A3-4BF3E3C83018@cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 27 Apr 2009 17:27:26 -0700
References: <49F1FD36.4010208@bbiw.net> <F9A276AD-3FC3-429F-A4A3-4BF3E3C83018@cisco.com>
X-Mailer: Apple Mail (2.930.3)
Cc: Dave CROCKER <dcrocker@bbiw.net>, vMeet@ietf.org
Subject: Re: [vmeet] Best Practices
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF remote participation meeting services discussion <vmeet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vmeet>
List-Post: <mailto:vmeet@ietf.org>
List-Help: <mailto:vmeet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Apr 2009 00:26:39 -0000

On Apr 24, 2009, at 4:40 PM, Fred Baker wrote:

>
> On Apr 24, 2009, at 10:56 AM, Dave CROCKER wrote:
>
>> Thomas Narten is lobbying for an effort to develop a document on  
>> best practices... A BCP on this sounds like it would be useful.
>
> I would agree. That said, I would want it to in fact be a BCP, in  
> the sense of being the best practices known to currently be in use  
> among people who use virtual meetings. That can be simple or  
> complex, and we are a community that knows how to make simple things  
> complex.
>
> First, I would want it to be written and reviewed by a people that  
> have used a variety of remote interaction tools and have no obvious  
> grist to chew. I would also want the important assumptions written  
> in the same memo as the "best practices". Assumptions include the  
> attendants and style of the meeting; a meeting of a dozen people who  
> know each other well and work well together is very different from a  
> meeting with 200 people who are split into factions with  
> fundamentally different models for whatever is under discussion.
>
> That showed up this morning, with some of us who had experience with  
> WebEx, Marratech, and Adobe tools talking about smallish  
> collaborations while others really wanted to discuss "how does this  
> work with 200 people in a room and one lonely denizen dangling off  
> the edge of the earth?"

Fred,

Several applications such as WebEx and Adobe Connect allow a small  
number of remote participants to approximate face-to-face meetings by  
using telephone bridges.  The low latency offered by the 64 kb/s full- 
duplex low latency telephone switching permits nearly spontaneous  
audio exchanges.  However, typical IETF meetings would be  
characterized by much larger groups listening to a Public Address  
system while observing slide presentations.  The scale and nature of  
these meetings represent a different exchange style than that found  
with smaller face-to-face meetings.  Due to the larger numbers,  
participants must speak in turn, from the meeting hosts, presenters,  
to those in the audience queuing behind microphones and waiting to be  
called upon.  Although the cost of about $100 per participant per day  
for telephone bridging can be offset by the travel time and expense  
otherwise needed, this technology goes well beyond what is needed when  
speaking is dictated by a regimen suitable for larger groups, and  
where full-duplex audio is not needed and where full-duplex audio also  
inhibits cheaper alternatives.

The IETF should make attempts at providing more effective remote  
participation tools that can accommodate more than a few lonely  
denizens, as you suggest.  Ensuring effective remote participation  
ensures progress is not thwarted by the loss of otherwise productive  
participants caused by visa restrictions or by escalating travel  
expenses.  Full-duplex telephone bridges will not cope well with the  
transmission delay complexities of VoIP since the bridge must converge  
on desired signals while canceling extraneous noise and feedback.   
Introducing Full-Duplex remote audio into the typical IETF meeting  
room will require expensive specialized equipment and expert  
configuration.  Just as with large meetings, allowing anyone to speak  
as desired will be impractical, even when individual speakers strive  
to be courteous.

WebEx can be used within an IETF meeting room environment only after  
there is a means to accommodate switching between remote or local  
audio inputs.  This approach should also be able to utilize VoIP or  
other communication methods without significant audio quality issues.   
To investigate using the WebEx service as a means to augment meeting  
room participation, experiments should be made using a dedicated Net- 
Box hard-wired to the room's projector and Public Address system's  
output and input.  Controlling the Net-Box could be accomplished using  
a wireless keyboard.  These experiments should also investigate  
whether the WebEx VoIP options might be suitable when switching  
between remote and local audio inputs is being employed.

Leaving a Net-Box permanently configured to operate as a training  
system that connects audio over VoIP might also represent an  
affordable solution for training.

-Doug