Re: [vmeet] Comments on today's vMeet webex session

["Brian Rosen" <[e-mail]>]

I believe your comment on the audio is incorrect.

Let's say that no one has any echo cancel, and someone in the room speaks.
As you point out, you don't hear echo in the room.  The remote participants
would get the direct audio a bit later, and what also happens is that some
of the outgoing audio from the room bounces off the hybrid in older phones
and is reflected back to the bridge.  The bridge has echo cancellation for
this and the echo won't come back to the room.

When a remote participant speaks, the sound comes out the speakers, gets
picked up by the microphone a bit later, and is sent back to the
participant, delayed.  Most conference bridges can't actually deal with
this: they aren't equipped to have local echo.  In this regard, it's not any
different from two conference phones in use with a phone connection between
them.  If you don't do anything locally, you WILL get echo.

However, there are devices available that are designed to link the room PA
to the phone line used for the audio connection, and they have the same kind
of echo cancellation that  conference phone does.  So, I think it will work
out okay, although we have to make sure we do that.

For example:
http://www.jkaudio.com/broadcast-host_dtails.htm
http://www.biamp.com/nexia_tc.php

Brian

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Doug Otis
Sent: Friday, April 24, 2009 3:01 PM
To: Dave CROCKER
Cc: [e-mail]
Subject: Re: [vmeet] Comments on today's vMeet webex session


On Apr 24, 2009, at 10:56 AM, Dave CROCKER wrote:

> These are my own comments about today's two-hour session.
>
> A vigorous round of thanks to Eliot Lear for setting this up, as  
> well as patiently demonstrating and explaining Webex features.  As  
> he noted, he's not part of the Webex product team but rather is an  
> extended user.  I think this made his comments less canned and more  
> salient and maybe more candid.

Agreed,  and you should be thanked for your efforts as well.  : )


> And a vigorous round of thanks to the 12, or so, folk who  
> participated.  I think we had enough people and enough kinds of  
> discussion, debate, confusion, resolution, etc., etc., to give a  
> reasonable taste of this using this tool real work.
>
> John Buford posted a note suggesting an additional session that is  
> primarily intended to give each participant a chance to be 'host',  
> that is to control the room.  It does afford a different perspective  
> than merely being a participant.

This seem to be a must have.

> We will also try to set up sessions similar to today's, with other,  
> similar tools.
>
> It was noted that this was a strictly virtual meeting, with no face- 
> to-face room component.  Hence, it was felt that this probably more  
> like an online-only interim meeting than a face-to-face.  My own  
> reaction about this assessment is mixed:  Eliot noted that the  
> pattern of contribution actually matched some kinds of face-to-face  
> working group meetings, and I agree.  While it's certainly true that  
> a mixed f2f/remote meeting has its own dynamics, I think that this  
> all-virtual session felt quite a bit like smaller, collaborative f2f  
> wg meetings.
>
> Any interesting tool in this space is going to have quirks.  Some  
> will be distracting.  I think one of our challenges is to  
> distinguish between core features vs. details of how they are  
> implemented.  For example, Webex lets a participant raise their  
> hand, but it doesn't indicate what order hands are raised in.  As  
> the one calling on folks who raised their hand, I certainly would  
> have preferred having them rank-ordered.  But while I think that  
> hand-raising is an essential feature, I think the rank-ordering is  
> more a matter of convenience than being essential
>
> My point is that I hope we are all careful to distinguish between  
> what is essential versus what is preferred.
>
> Also predictably -- especially during the relatively early stages of  
> an exercise like this -- is our jumping between comments about the  
> specific tool we were using, versus comments about requirements for  
> any tool.  The scenarios/goals list is meant to be generic:  what  
> kinds of meeting capabilities do we want and how do we want to use  
> them, versus whether a particular tool can satisfy a particular  
> scenario.
>
> The issue of meeting participation "role" has come up a number of  
> times, such as between passively lurking, versus occasionally asking  
> a question, versus giving a presentation, versus actively engaging  
> in a discussion/debate.  Each implies some very different functional  
> capabilities. While it's tempting to think of these as explicitly  
> different memberships, chosen at the time of joining, I hope folks  
> will think of how fluid real IETF meetings are, in terms of the  
> roles people switch between.  Any lurker can suddenly become an  
> active and important component of an intense debate.  We want to be  
> careful we don't lose that.
>
> Having a lot of mechanism mediating a meeting clearly requires that  
> process and content be delegated to different people.  So, for  
> example, at one point I was trying to conduct a discussion about  
> scenarios and take notes of people comments, and I completely missed  
> the fact that some folks were raising their hands.  We need the  
> person who is facilitating the meeting process always to be  
> different from any of the folk who are actively engaged in the  
> discussion and different from the person(s) taking notes.
>
> Thomas Narten is lobbying for an effort to develop a document on  
> best practices.  This highlights that any tool we use still requires  
> some care among the participants:  for that matter, even when there  
> is no tool.  The usual example is that the way a speaker should talk  
> (pace, language, volume) is different when non-native speakers are  
> present, and even now, we attend to this too little. Adding heavy  
> computer mediation increases the issues and the need for each  
> participant to be careful.  A BCP on this sounds like it would be  
> useful.

The main goal of the vMeet working group should be aimed at  
facilitating mixed local and remote meetings. The IETF wishes to  
continue their tradition of hosting conferences.  However, there is a  
desire to better accommodate remote participation. This group should  
adopt the general assumption that details related to Remote Only  
meetings are already being well addressed by today's technologies.   
Therefore Remote Only meetings should not be the focus of this working  
group.  Only issues related specifically to mixed local and remote  
meetings should be addressed.

Remote/Local Audio Issues:

Any audio streaming system will introduces a delay measured from a few  
hundred milliseconds to tens of seconds.  However, the Public Address  
(PA) system being used within meeting rooms introduces no noticeable  
delay.

To facilitate both local and remote speakers being heard within the  
meeting room, the audio output created by the Remote Meeting Client  
(RMC) audio output must be selectively introduced into the PA system  
ONLY when hearing the remote participant is desired.  Leaving RMC  
audio output enable while any local participant is speaking will prove  
highly disruptive, since the effect will be worse than the echo heard  
in Lou Gehrig's Luckiest Man speech.  This means there must be either  
a manual switch, or software that allows an assistant within the room  
to control the RMC audio output feed into the the rooms PA system.

Video Projector Issues:

It is often difficult for remote participants to follow along with a  
speaker as they present slides.  To facilitate remote participation,  
the RMC presentation video should be feed to the digital projector  
within the meeting room, where the presenter or some local assistant  
using the RMC can then make slide changes.  Most RMCs allow control to  
be passed to different presenters, which might be someone acting as an  
assistant that already has the slide presentation.

Shared Desktop Issues:

Those using shared desktops must not assume that other participants  
are using the same display resolution.  Many may be using a laptop  
with rather limited resolutions.  In addition, they may wish to see  
the controls needed to chat, mute/unmute, or set icons.  While the RMC  
may allow scaling the size of the shared desktop, scaling does not  
work well when the presenter places a small document in the center of  
a large work space. :^(  When the workspace is reduced in size to fit  
within the remote participants screen, a small document quickly  
becomes unreadable.  A large border of unused workspace around any  
side of the document also makes adjusting these settings difficult.

The presenter should attempt to have the document resolution and size  
match that of the shared desktop window.  In addition, where there is  
a difference in size between the document and the workspace, the  
document should be positioned in the upper left of the shared desktop  
workspace.

Presenters unfamiliar with RMC features Issues:

The IETF should provide a service to allow presenters an ability to  
rehearse their presentation, and to become familiar with the RMC  
tools.  Issues related to conducting a poll, or using shared desktops  
or white-boards should be practiced well ahead of the meetings.   
Asking members to raise their hand where each option is read one at a  
time does not really permit participants a means to understand the  
range of options before responding.  A poll that offers a complete  
list of options will allow better informed responses.

Reliable control of the projector video feed and PA audio feed:

Network disruptions happen. The IETF could reduce the potential level  
of disruption by standardizing on the way the room audio and digital  
projector are used.  An inexpensive Net-Box can run the RMC, act as  
the audio input, and as the remote participant audio output.  The Net- 
Box could be physically controlled by a wireless keyboard, or by a  
remote desktop.  Remote desktop server/clients are available for any  
OS that might be used by the Net-Box.  BTC makes a wireless keyboard  
with a joystick mouse for about $35, for example. There is also open  
source software that can be used by local assistants, as yet another  
alternative.

The primary role for the Net-Box is to offer a video feed to the  
protector, and to selectively enable the audio feed to the PA system.   
By standardizing on the configuration, local participants could spend  
less time learning how to control the system, and thereby better cope  
with network disruptions.

Use Scenarios:

Event Magnitude: (ES) 3000 participants (Plenary)
Meeting Magnitude: (MM) 125 talkers + 375 listeners
Interactive Sessions: (IS) 500 participants

Typical current (ES) scale offering:

a) Jabber and Audio streaming of the room session.
b) Presentation material often posted to a web page.
c) Mic: conventions in Jabber to ask questions.

Possible mixed local and remote meeting offering:

a) Standard phone bridge (MM)
  - limited to 125 talkers + 375 listeners

b) VoIP/Standard phone bridge combined (MM)
  - limits similar to that of the phone bridge
  - may experience impaired sound quality

c) Audio streaming (up-feed) (ES)
  - practically unlimited number of listeners
  - does not allow remote talking

Modes of remote participation:
a) Web-based (ES) Slide Presentation and Text Chat client.
b) Web-based (ES) Polling
c) Web-based (ES) video feeds
d) Web-based (ES) Audio feeds (may not be available with MM client)
e) Web-based (IS) shared Desktop interactive presentations.
f) Web-based (IS) shared whiteboard


-Doug

_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html.
https://www.ietf.org/mailman/listinfo/vmeet