Subject: Remote participation (re: identifying yourself at the mic)

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Mar 2007 14:39:49 -0500

It'd be nice if there was a way for remote participants who are able to
speak to do so.  We tried ad-hoc VOIP + MP3 feed at IETF67 in the KITTEN
WG, but the round-trip latency was awful -- we need a better solution.

Given such a facility we'll end up with a mutual need by participants in the
room and remote participants to identify each other, which will nicely
solve the problem :)

Nico
-- 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Tony Finch <[email-masked]>
Date: Tue, 27 Mar 2007 20:55:04 +0100

On Tue, 27 Mar 2007, Nicolas Williams wrote:

> speak to do so.

I've found that it's generally OK if someone is nominated to speak
pertinent comments made by remote participants on jabber.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: WEST VEERING NORTHWEST 3 OR 4, OCCASIONALLY 5 AT FIRST,
BECOMING VARIABLE 2 OR 3 LATER. ROUGH DECREASING MODERATE. SHOWERS. GOOD.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Mar 2007 21:56:26 +0200

> room and remote participants to identify each other, which will nicely

We did this at early IETFs with multicast applications thanks to Van 
Jacobson and Evi's bunch.

Eliot

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Mar 2007 15:07:55 -0500

> pertinent comments made by remote participants on jabber.

That's not sufficient, however, when the remote participant is making a
presentation.

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 27 Mar 2007 13:10:25 -0700

> room and remote participants to identify each other, which will nicely

echo cancellation in a room full of live microphones is problematic.
there's hardware that can help, but what you really need is floor
control in the form of person who controls who can speak via mixing.

managing it is a bit harder than speaker phones and conferencing bridges
(which is hard but has a lot effort behind it).

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Mar 2007 16:42:33 -0400

> WG, but the round-trip latency was awful -- we need a better solution.

It's worth noting that in that particular experiment, the round trip time 
was dominated by the latency of the multicast audio feed which we were 
using for one half of the link.  If we were to try this again, we'd use the 
VOIP link for both directions to the remote speaker, to avoid annoying 
latency issues.

> Given such a facility we'll end up with a mutual need by participants in
> the room and remote participants to identify each other, which will nicely
> solve the problem :)

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Mar 2007 15:46:27 -0500

> VOIP link for both directions to the remote speaker, to avoid annoying 

Which should deal with the echo cancellation issues, provided a
conference bridge, say.  That should work for remote presenters.

For other remote participants a VOIP teleconference system would be
great.  We do this all the time at Sun internally for large meetings, so
it should work.  (The IETF might have to charge remote participants a
conference call fee, if it uses a third party provider, say.)

My point, however, was that one way to solve the id-at-mic problem is to
make the problem symmetric for all participants :)

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Mar 2007 16:50:14 -0400

On Tuesday, March 27, 2007 01:10:25 PM -0700 Joel Jaeggli 
<[email-masked]> wrote:

>> the room and remote participants to identify each other, which will
>> nicely solve the problem :)
>

I've seen that to be the case even with only the local microphones. 
Several groups I participate in regularly have taken to having each speaker 
turn the mic on when they speak and off when they are done, which 
unfortunately adds a bit of latency with wireless mics that require a 
couple of seconds to warm up.  I've also had at least one occasion where I 
was using the mute buttons on the mixing board for floor control, but 
that's fairly primitive and it's nearly impossible to run a meeting and mix 
it at the same time.

Maybe we need another team of volunteers to mix the meetings(*), instead of 
assuming that static settings will be good enough.  This could have the 
added benefit of relieving the chair of the burden of telling people over 
and over to speak their names....

(*) At most half-serious, though if someone showed up to run the mixer in 
my next meeting, I wouldn't complain. :-)

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Mar 2007 16:51:05 -0400

On Tuesday, March 27, 2007 03:46:27 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> > speak to do so.  We tried ad-hoc VOIP + MP3 feed at IETF67 in the
>> > KITTEN WG, but the round-trip latency was awful -- we need a better
>> > solution.
>>
>> It's worth noting that in that particular experiment, the round trip
>> time  was dominated by the latency of the multicast audio feed which we
>> were  using for one half of the link.  If we were to try this again,
>> we'd use the  VOIP link for both directions to the remote speaker, to
>> avoid annoying  latency issues.
>

Perhaps Sun would like to volunteer its system for an experiment?

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Mar 2007 15:59:45 -0500

> Perhaps Sun would like to volunteer its system for an experiment?

It isn't ours.  As best I can tell we use some high-end conference
bridging + AT&T concall services along with traditional room PA systems.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Mar 2007 17:06:22 -0400

> bridging + AT&T concall services along with traditional room PA systems.

Oh; I thought we were talking about a VOIP-based service, rather than a 
traditional conference-bridge service.

---

From: <[email-masked]>
Date: Tue, 27 Mar 2007 23:01:42 +0100

> bridging + AT&T concall services along with traditional room 

Is there something wrong with implementing some IETF technology at an
IETF meeting? Has no-one heard of Asterisk? Considering the Skype hype
out there one wonders why the IETF doesn't take the opportunity for
showcasing standards based VoIP and SIP, such as Asterisk. And if you
need to pay someone to set it up and run it for you, there are lots of
companies that will do this with Asterisk.

--Michael Dillon

---

From: Joe Abley <[email-masked]>
Date: Tue, 27 Mar 2007 19:18:23 -0400

On 27-Mar-2007, at 16:46, Nicolas Williams wrote:

> (The IETF might have to charge remote participants a

I'm still unsure why people use third party providers for conference  
calls, if they need conference call facilities at all frequently. It  
doesn't take much of a linux box running asterisk to support quite  
large conferences, and it's not clear to me that any such conference  
used in a working group context would necessarily require anything  
other than SIP access.

How many engaged remote participants do most working groups have,  
anyway? In my limited experience it's rarely more than a handful, at  
least if the jabber chatrooms are anything to go by.

Joe