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

From: Dave CROCKER <[email-masked]>
Date: Fri, 24 Apr 2009 10:56:06 -0700

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.

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.

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.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Doug Otis <[email-masked]>
Date: Fri, 24 Apr 2009 12:01:15 -0700

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

> 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.

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

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 24 Apr 2009 17:06:52 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Doug Otis
Sent: Friday, April 24, 2009 3:01 PM
To: Dave CROCKER
Cc: [email-masked]
Subject: Re: [vmeet] Comments on today's vMeet webex session

Video Projector Issues:

Shared Desktop Issues:

Use Scenarios:

-Doug

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

---

From: Doug Otis <[email-masked]>
Date: Fri, 24 Apr 2009 14:51:58 -0700

On Apr 24, 2009, at 2:06 PM, Brian Rosen wrote:

> 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.

Local echo canceling equipment of this sort will cost much more than  
the suggested Net-Box used to project slide presentations.  Echo  
cancelation also seems unlikely able to deal with audio delays that  
that might exceed more than a second.  The IETF will be dealing with  
long distant participants and audio streaming systems handling many  
participants.   It would be much safer not to expect there will be an  
ability to offer a system able to provide rapid exchanges of remote  
and local speakers without some form of intervention.  No system is  
able to support everyone talking without also everyone following some  
type of cue.  Even a phone bridge suffers from this problem to some  
extent.  It really seems that the local room will need to decide when  
they wish to listen to a remote speaker/presenter.  This will be much  
as they do for someone at the microphone within the room, or for a  
presenter.  At that time, when the person is remote, there will be a  
need to mute the room's PA feed into the RMC (perhaps the audio input  
of the Net-Box), and then enable the RMC output into the PA, (perhaps  
the audio output of the Net-Box).  A Net-Box used in this manner could  
then offer high quality sound where there is no opportunity for any  
echo to be heard.

-Doug

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 24 Apr 2009 17:58:03 -0400

[changing subject lines to reflect the topic]

To amplify: Line echo and acoustic echo cancellation are very  
different problems; see

http://www.polycom.com/global/documents/support/technical/products/voice/vortex_choose_acoustic_echo_canceller.pdf

for a summary. (Short version: The so-called tail time is much longer  
for the acoustic echo canceller.)

Digital hybrids, such as the JK Audio one, are not meant for such  
applications - they only cancel line echo, although the basic  
operational model is not bad - essentially, we are running a call-in  
show.

ClearOne is a well-known company in that space; however, most of these  
boxes seem designed for professional installation in conference rooms,  
not just plopping them down on a table next to the screen in rooms  
holding hundreds of people. (All the microphones and speakers have to  
be wired through them to work.) They are also not exactly cheap. Thus,  
the audio installation for each IETF would have to be done by somebody  
trained on that equipment, not the usual hotel audio crew that sticks  
black tape over XLR cables.

However, you only need these fancy boxes if you run full-duplex. If  
you mute the floor microphones when the remote caller speaks (and vice  
versa), i.e., in half-duplex mode, there can be no acoustic echo. This  
is, I think, what Doug is proposing. This is more human effort, but a  
whole lot simpler to install.

Henning

On Apr 24, 2009, at 5:06 PM, Brian Rosen wrote:

> speaks.
> gets
> room PA

---

From: Fred Baker <[email-masked]>
Date: Fri, 24 Apr 2009 16:40:14 -0700

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

> 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?"

Another thing that would probably help is to have someone, probably  
several someones, who attends IETF activities remotely and whose first  
language is not English, talking about what makes meetings more useful  
for him or her.

At this point, I don't know that we as a community know how best to  
use tools like these in our meetings. We have some idea, because we  
have used them in our day jobs, but we can't say we have tried them in  
situ and know what works and what doesn't.

Thinking about this, I started to suggest that folks send Thomas and I  
lists of their best suggestions toward such a note. But I suspect that  
the old adage that "tragic cases make bad law" applies here. What we  
really want is suggestions on how to make meetings work well, not "all  
the bad things to avoid". In general, that boils down to planning (get  
the dates sorted early), preparation (agenda out a week before, write  
and read documents in advance, if presentations are involved make/ 
distribute slides well in advance), and considerate behavior during  
meetings (assume the presence of folks for whom English is not a first  
language, etc). Oh, good tools too.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 24 Apr 2009 20:21:39 -0700

> whole lot simpler to install.

Agreed. Even assuming the PA and the RMC were somehow closely
integrated, depending upon the location of the remote speaker, the
data-center offering the RMC services, and the location of the meeting,
transmission line effects still introduce complex and unstable delays.  

In addition, acoustic echo canceling is never perfect even when all
audio sources are fed through a common system.  These system are
expensive and difficult to configure when the goal is to allow both near
and far sides an ability to talk freely. Dealing with acoustic residuals
when both sides are talking represents a rather daunting problem. 

A manual half duplex mode ensures that those in the meeting room will be
able to ensure good audio quality and its use at a very low cost.  Also
note that the suggested low cost BTC wireless keyboard has both volume
and mute buttons to make the effort of controlling the Net-Box audio
fairly minimal.  Use of RDP protocols would eliminate passing around a
keyboard, but this would be dependent upon the network.

A wireless keyboard might be handy during network disruptions as it
would enable a meeting to continue when the hotel router gets depressed.
Slides for the meeting should also be stored in the Net-Box prior to the
start of the meeting.  While these devices also accept nearly any type
of memory stick and contain system recovery images, it may be unwise
from a security standpoint to rely on memory sticks being freely passed
around.

-Doug

---

From: SM <[email-masked]>
Date: Sat, 25 Apr 2009 03:29:46 -0700

>salient and maybe more candid.

Thanks to Eliot for the Webex demonstration.  As background 
information, I'll mention that I have used Webex to follow the 
plenary and small meetings.  I have also used Marratech for small meetings.

>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 

I agree with Eliot's assessment about the pattern of 
contribution.  In this meeting, most of the participants knew each 
other.  That influences the dynamics of the meeting.  There was 
little back room chatter during this meeting.

When we listen to audio, we cannot always tell who is speaking.  We 
had a visual cue during the meeting as all the participants were 
remote.  I did not have any problem following Dave and Eliot.  The 
audio was somewhat low for some of the participants but I could still 
understand what they were saying.  My phone call dropped around the 
90 minute mark.  It may be due to a time limit on the call 
duration.  During IETF meetings, I can usually refer to the Jabber as 
I get back and catch up with important points I missed.

I'll qualify the experiment as a success.  That's not always the case 
as I have experienced breaks in the audio feed or the Jabber going 
down when I follow meetings remotely.  Bandwidth on the local side 
was not an issue for this meeting but it can be when the audio feed 
is high bandwidth.

The loss of control over the workspace can be confusing at first.  If 
a participant is not familiar with the tool being used, he/she may 
feel like exploring it to find his/her way around.

I'll list some points:

  - the audio worked

  - I could tell who was speaking (map a voice to a name through the tool)

  - I could see the slides clearly and I did not have to identify 
which slide was being discussed.

I think that those are the basics for a virtual meeting.  For first 
time users, I suggest connecting earlier as setting up the (Java) 
software can take some time or you can encounter problems.

Regards,
-sm

---

From: Doug Otis <[email-masked]>
Date: Mon, 27 Apr 2009 17:27:26 -0700

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

> 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.
>
> grist to chew. I would also want the important assumptions written  
> in the same memo as the "best practices". Assumptions include the  
> 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