Subject: Getting Taipei remote participants' input

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Nov 2011 18:26:37 -0800

Greetings again. This follows my last message about hearing the experiences of people who participated remotely at last week's meeting.

I would love to hear from your WG members who remotely participated in WG meetings in Taipei. My original plan was to look through the logs of a bunch of WGs and send out messages, but in doing so I realize that many people use abbreviated names so I can't identify them. My bad.

If you held a session in Taipei, it would be really nice if you could go through your Jabber logs and pick out anyone who spoke (or unsuccessfully attempted to speak) at the mic or presented from afar. If you could send me their name and email addresses, I would greatly appreciate it. I'm sure I'll get duplicates of some names, but I can batch accordingly.

FWIW, I have already gotten a *great* set of comments from many of the people you pointed towards me from the last message. Let's keep more coming. Thanks in advance!

-- Paul Hoffman

---

From: Brian Rosen <[email-masked]>
Date: Tue, 22 Nov 2011 09:25:20 -0500

I'll give you some chair experience:

We tried remote presentation in two WGs I co-chaired.  One was in DCON BoF, where we attempted to use the Meetecho tool with a remote driver.  They tried to jack Meetecho audio into room audio.  That did not work (echo).

We then successfully did it in paws.  We had a remote presenter audio only where we simply pointed the chair mic to the speaker of the chair PC running Skype.  That worked fine.  The presenter ran the Meetecho client for slides and room audio in.

I was also in the vipr session where ekr presented with occasional Skype video from the chair mac.  That worked, but was more gimmick than useful (audio was useful).

Brian

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 22 Nov 2011 15:46:54 +0100

Hi Paul,

to complete Brian's review, I can add that we had interactive remote 
participation also in RTCWEB (second session), TLS, and DRINKS. In the 
former two cases, EKR participated in the session by using gtalk as 
input to the room and the RTSP stream from Meetecho in order to listen 
to the local 'audio' feed. He also used Meetecho to present and share 
his slides. DRINKS was different, since it is a session where we managed 
to connect the Meetecho mixer laptop to both input and output of the 
mixer. In such case we had active remote participation entirely managed 
by Meetecho, and it worked like a charm (no echo at all). This is indeed 
the ideal configuration if you want to allow remote presenters to 
seamlessly interact with the local participants.

Cheers,

Simon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Nov 2011 14:50:27 +0000

The ekr video in rtcweb was hilarious. (Not you ekr, I
think any 3m tall head would have been:-)

S

---

From: Ted Hardie <[email-masked]>
Date: Tue, 22 Nov 2011 08:30:52 -0800

On Tue, Nov 22, 2011 at 6:46 AM, Simon Pietro Romano <[email-masked]>wrote:

> Hi Paul,
>  EKR participated in the session by using gtalk as input to the room and
> the RTSP stream from Meetecho in order to listen to the local 'audio' feed.

We also pointed the laptop "holding" ekr to the mic line, so he could at
least vaguely see the mic line.

He also used Meetecho to present and share his slides.

So, I'm not sure what you mean here; the slides ran from the same laptop as
gTalk, with him saying "next slide" from the audio link to advance them.  I
think Meetecho advanced the slides  from the uploaded set for the remote
folks.

Ted

DRINKS was different, since it is a session where we managed to connect the
> Meetecho mixer laptop to both input and output of the mixer. In such case
> we had active remote participation entirely managed by Meetecho, and it
> worked like a charm (no echo at all). This is indeed the ideal
> configuration if you want to allow remote presenters to seamlessly interact
> with the local participants.
>
> Cheers,
>
> Simon
>
>> We tried remote presentation in two WGs I co-chaired.  One was in DCON
>> BoF, where we attempted to use the Meetecho tool with a remote driver.
>>  They tried to jack Meetecho audio into room audio.  That did not work
>> (echo).
>>
>> We then successfully did it in paws.  We had a remote presenter audio
>> only where we simply pointed the chair mic to the speaker of the chair PC
>> running Skype.  That worked fine.  The presenter ran the Meetecho client
>> for slides and room audio in.
>>
>> I was also in the vipr session where ekr presented with occasional Skype
>> video from the chair mac.  That worked, but was more gimmick than useful
>> (audio was useful).
>>
>> Brian
>>
>>  Greetings again. This follows my last message about hearing the
>>> experiences of people who participated remotely at last week's meeting.
>>>
>>> I would love to hear from your WG members who remotely participated in
>>> WG meetings in Taipei. My original plan was to look through the logs of a
>>> bunch of WGs and send out messages, but in doing so I realize that many
>>> people use abbreviated names so I can't identify them. My bad.
>>>
>>> If you held a session in Taipei, it would be really nice if you could go
>>> through your Jabber logs and pick out anyone who spoke (or unsuccessfully
>>> attempted to speak) at the mic or presented from afar. If you could send me
>>> their name and email addresses, I would greatly appreciate it. I'm sure
>>> I'll get duplicates of some names, but I can batch accordingly.
>>>
>>> FWIW, I have already gotten a *great* set of comments from many of the
>>> people you pointed towards me from the last message. Let's keep more
>>> coming. Thanks in advance!
>>>
>>> -- Paul Hoffman
>>>
>>
>>
> --
>                            _\\|//_
>                            ( O-O )
>   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)**~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>                    Simon Pietro Romano
>          http://www.comics.unina.it/**simonpietro.romano<http://www.comics.unina.it/simonpietro.romano>
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 22 Nov 2011 17:57:22 -0500

As Brian's noted, Skype with a mic on the laptop speaker works great,
as we see it in the room.  We used that for two presenters in APPSAWG:
Mark Nottingham <[email-masked]> and Paul Bryan
<[email-masked]>.  The chairs ran the slides, as we always
do, to avoid the delays involved in switching presentation sources.
There was Q&A for both presenters, and it appeared to work well from
my side.  I'll be interested to know whether the presenters also
thought so.

I left the Skype connection up so that Mark and Paul could participate
in the rest of the meeting if they chose to, and they both stayed on
for a while.  Neither of them, though, made to say anything on the
mic.  Mark made a comment in jabber, and added that he didn't try to
say it because there was no convenient way to get in the mic queue and
know where he stood.  [I note that he could have "raised his hand" in
jabber, and I'd have told him when it was his turn.  But we had not
set up any such protocol in advance, and I guess he found it easier
just to ask someone to channel him.]

For OAuth, Thomas Hardjono <[email-masked]> set up a WebEx meeting,
which I dialled into (audio only) from my laptop, using Skype and a
microphone.  The audio quality was notably worse than using Skype
alone -- WebEx does not appear to be our friend, with respect to audio
quality.  Julian Reschke <[email-masked]> presented to
the room through the WebEx-to-Skype-to-mic link; Thomas and William
Mills <[email-masked]> were on WebEx, but didn't attempt to
talk.

We did not try Meetecho in either of those sessions.

Barry

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 23 Nov 2011 07:33:40 -0800

On 11/22/2011 2:57 PM, Barry Leiba wrote:
> as we see it in the room.

As a hack, yeah, it works tolerably.  As a production mode, probably not.  I'd 
hope that a goal for the tools we use is better intergration and better sound 
quality.

> just to ask someone to channel him.]

In terms of modeling how to have remote audience participants be in the queue to 
talk, the simplest approach is to treat the entire set of remote participants as 
one more 'microphone'.  We already have an approach for servicing local folks at 
a microphone.  This would be one more, albeit virtual.

The problem with this is deciding the rank ordering of the virtual queue.  Webex 
has hand-raising, but doesn't indicate the order.  (A different tool, whose name 
I don't remember, does rank order.)  I believe meetecho also does not rank 
order.  Using jabber for a convention to indicate hand-raising probably 
implicitly imposes an ordering.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brian Rosen <[email-masked]>
Date: Wed, 23 Nov 2011 11:06:52 -0500

I've thought about the mic queue problem.  It's definitely not easy, because we don't follow a strict FIFO - people exchange places all the time depending on the flow of conversation.

The best idea I came up with is to have a small tablet like device at the mic with a reader for your badge (bar code or RFID).  This puts you in the normal queue, which is displayed on the screen.  A corresponding function is on the remote participant's tool, and the chair gets a FIFO ordered queue presentation.  I note that if implemented at all mics, would give chairs the actual "who was first" answer.

Brian

On Nov 23, 2011, at 10:33 AM, Dave CROCKER wrote:

> As a hack, yeah, it works tolerably.  As a production mode, probably not.  I'd hope that a goal for the tools we use is better intergration and better sound quality.
> 
> 
> In terms of modeling how to have remote audience participants be in the queue to talk, the simplest approach is to treat the entire set of remote participants as one more 'microphone'.  We already have an approach for servicing local folks at a microphone.  This would be one more, albeit virtual.
> 
> The problem with this is deciding the rank ordering of the virtual queue.  Webex has hand-raising, but doesn't indicate the order.  (A different tool, whose name I don't remember, does rank order.)  I believe meetecho also does not rank order.  Using jabber for a convention to indicate hand-raising probably implicitly imposes an ordering.
> 
> d/
> -- 
> 
>  Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 23 Nov 2011 08:38:57 -0800

> I've thought about the mic queue problem.  It's definitely not easy, because we don't follow a strict FIFO - people exchange places all the time depending on the flow of conversation.

I've modeled this as two different modes.  Ones is the clean FIFO per mic and 
round-robin of the mics.  (Anytime we try to get a better model it seems to fall 
apart, in spite of some inherent unfairness in this model.)

The other is a self-regulating, small-group with all mics open.

In the real room, the transition between these modes is informal and automatic. 
When adding remote participation, it probably needs to become explicit.  I 
believe no existing tools support this.

> The best idea I came up with is to have a small tablet like device at the mic with a reader for your badge (bar code or RFID).  This puts you in the normal queue, which is displayed on the screen.…

Yeah, trying to design this is fun.  No idea whether any of the existing tools 
will move in that direction; it's a significant addition.

d/
-- 

   Dave Crocker

---

From: Brian Rosen <[email-masked]>
Date: Wed, 23 Nov 2011 11:52:03 -0500

Why is strict FIFO at all mics not better than FIFO per pic round robin between mics?
Let's separate the stuff we do at plenaries from regular large room WG sessions.

Most chairs treat all commenters as FIFO as much as possible regardless of which mic they come to, and have trouble remembering who actually came first between mic queues.

Brian

On Nov 23, 2011, at 11:38 AM, Dave CROCKER wrote:

> I've modeled this as two different modes.  Ones is the clean FIFO per mic and round-robin of the mics.  (Anytime we try to get a better model it seems to fall apart, in spite of some inherent unfairness in this model.)
> 
> In the real room, the transition between these modes is informal and automatic. When adding remote participation, it probably needs to become explicit.  I believe no existing tools support this.
> 
> 
> Yeah, trying to design this is fun.  No idea whether any of the existing tools will move in that direction; it's a significant addition.
> 
> d/
> -- 
> 
>  Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 23 Nov 2011 09:20:01 -0800

> Why is strict FIFO at all mics not better than FIFO per pic round robin between mics?

I don't know what "FIFO at all mics" means, precisely.

If you mean aggregating the set of folk at all the mics and taking them in the 
strict order of their coming to the (single) queue, that doesn't work on 
average, unless the queue is tiny.  The chair can't keep track of who arrived to 
the queue and when.

If you mean something else, what?

> Most chairs treat all commenters as FIFO as much as possible regardless of which mic they come to, and have trouble remembering who actually came first between mic queues.

It works for smaller wg sessions that aren't too active.  But it doesn't scale.

d/

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 23 Nov 2011 20:16:29 +0100

Hi Dave,

> If you mean aggregating the set of folk at all the mics and taking 
> them in the strict order of their coming to the (single) queue, that 
> doesn't work on average, unless the queue is tiny.  The chair can't 
> keep track of who arrived to the queue and when.

I personally like Brian's idea, and think the all thing might work 
smoothly if you make use of a tool capable to automatically collect and 
moderate floor requests, to be put in a (virtual) single queue. What I'm 
thinking of is RFIDs triggering BFCP (Binary Floor Control Protocol) 
requests, in much the same way as the floor requests generated by remote 
participants. The same tool should then provide session chairs with a 
chance to give potential "business class" requests (i.e., in the case of 
cut and thrust debates, or in the presence of an AD intervention) higher 
priority (which basically means putting such requests on top of the queue).
It would be nice to test such a system at an upcoming IETF.

My 2 cents,

Simon

>> Most chairs treat all commenters as FIFO as much as possible 
>> regardless of which mic they come to, and have trouble remembering 
>> who actually came first between mic queues.
>

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 25 Nov 2011 11:19:48 -0800

On 11/22/11 06:25 , Brian Rosen wrote:
> We tried remote presentation in two WGs I co-chaired.  One was in
> DCON BoF, where we attempted to use the Meetecho tool with a remote
> driver.  They tried to jack Meetecho audio into room audio.  That did
> not work (echo).

if you have a single bus mixer plugging input and output into the same
bus generally produces a loop. even with in the  in-room mics in the a
separate mix from the computers output from the room you need some
fairly deep echo-cancellation.

> only where we simply pointed the chair mic to the speaker of the
> chair PC running Skype.  That worked fine.  The presenter ran the
> Meetecho client for slides and room audio in.
> 
> I was also in the vipr session where ekr presented with occasional
> Skype video from the chair mac.  That worked, but was more gimmick
> than useful (audio was useful).
> 
> Brian
> 
>> I would love to hear from your WG members who remotely participated
>> in WG meetings in Taipei. My original plan was to look through the
>> logs of a bunch of WGs and send out messages, but in doing so I
>> realize that many people use abbreviated names so I can't identify
>> them. My bad.
>> 
>> If you held a session in Taipei, it would be really nice if you
>> could go through your Jabber logs and pick out anyone who spoke (or
>> unsuccessfully attempted to speak) at the mic or presented from
>> afar. If you could send me their name and email addresses, I would
>> greatly appreciate it. I'm sure I'll get duplicates of some names,
>> but I can batch accordingly.
>> 
>> FWIW, I have already gotten a *great* set of comments from many of
>> the people you pointed towards me from the last message. Let's keep
>> more coming. Thanks in advance!
>> 
>> -- Paul Hoffman
> 
>

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 25 Nov 2011 12:08:42 -0800

On 11/23/2011 11:16 AM, Simon Pietro Romano wrote:
>> average, unless the queue is tiny. The chair can't keep track of who arrived
>> to the queue and when.
>
> I personally like Brian's idea, and think the all thing might work smoothly if
> you make use of a tool capable to automatically collect and moderate floor
> requests, to be put in a (virtual) single queue. What I'm thinking of is RFIDs
> triggering BFCP (Binary Floor Control Protocol) requests,

An interesting challenge, for Paul's current contract, is to find a way to 
navigate between what the community wants, versus what is practical.  The fact 
that we are a group of engineers means that we tend to try to solve the problem, 
before agreeing on what problem we want to solve...

Suggestions like the above sound appealing.  Unfortunately, they are far beyond 
current products and making them useful is considerably more difficult than the 
suggestions imply.  That doesn't mean they should be ignored, but we need to be 
careful about slipping into the assumption that merely citing a bit of 
technology means that an issue is resolved.

We had an experiment with RFIDs.  It was awkward, at best.  In addition, it was 
extremely limited.  Only the person standing right next to the microphone could 
be identified.  For example, this means that it would not have been useful for 
identifying when someone /enters/ the queue.  Too far away.

So if folks are going to attempt to define the technical solution, at least 
please try to indicate how it would work throughout the requirement.

In the case of queue management, we have at least entering the queue, position 
in the queue, and the chair's control of the queue.  No doubt, there's even more 
complexity than that.  For example, there's "noise" such as someone walking by 
the queue but not entering it...

d/
-- 

   Dave Crocker

---

From: Brian Rosen <[email-masked]>
Date: Sun, 27 Nov 2011 14:50:42 -0500

People worry about RFID, but I like it because it's a faster read.  Bar code is less controversial (and already there).  Tablet+wifi means it's only a battery lifetime issue.  If we could have aggressive enough battery management, perhaps we could get through the day.

All  I think you want is a reader and a visible queue.  The queue just tells you that the reader read correctly and has you in the queue.

The chair gets to change the queue, but that ought to be rare and probably just pick the next person in queue.  Remote participants simply imitate the reader action.

For extra credit, monitor the jabber room.  Look for <mic> and put them in queue.

Brian

On Nov 25, 2011, at 3:08 PM, Dave CROCKER wrote:

> An interesting challenge, for Paul's current contract, is to find a way to navigate between what the community wants, versus what is practical.  The fact that we are a group of engineers means that we tend to try to solve the problem, before agreeing on what problem we want to solve...
> 
> Suggestions like the above sound appealing.  Unfortunately, they are far beyond current products and making them useful is considerably more difficult than the suggestions imply.  That doesn't mean they should be ignored, but we need to be careful about slipping into the assumption that merely citing a bit of technology means that an issue is resolved.
> 
> We had an experiment with RFIDs.  It was awkward, at best.  In addition, it was extremely limited.  Only the person standing right next to the microphone could be identified.  For example, this means that it would not have been useful for identifying when someone /enters/ the queue.  Too far away.
> 
> So if folks are going to attempt to define the technical solution, at least please try to indicate how it would work throughout the requirement.
> 
> In the case of queue management, we have at least entering the queue, position in the queue, and the chair's control of the queue.  No doubt, there's even more complexity than that.  For example, there's "noise" such as someone walking by the queue but not entering it...
> 
> d/
> -- 
> 
>  Dave Crocker

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 28 Nov 2011 13:03:56 +0100

At least as far as BFCP is concerned, I'd just note that certain things are out of scope of the RFC.

BFCP defines a participant protocol (to enter the queue and have your request granted), and a chair protocol (to monitor the status of the queue and grant specific requests).

The magic that happens in the middle on a floor control server, in terms of coordinating chair grants with any automatic algorithm of allocating grants, is up to the implementor.

I guess if we used this, WG chairs could be given a number of preconfigured profiles ranging from total chair control through to FIFO (total automatic control with chair override of the whole queue). They could then select which they preferred at the start of the meeting (dependent on criteria such as size of meeting).

This is independent of any discussion of actually gathering the queue request in the first place.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dave CROCKER
> Sent: 25 November 2011 20:09
> To: Simon Pietro Romano
> Cc: IETF WG chairs
> Subject: Re: Getting Taipei remote participants' input
> 
> 
> 
> smoothly if

---

From: Tina TSOU <[email-masked]>
Date: Wed, 23 Nov 2011 22:29:00 +0000

Simon, like your signature.
If all meeting automatically having meetcho support, that would be good.

Sent from my iPad

On Nov 23, 2011, at 11:17 AM, "Simon Pietro Romano" <[email-masked]> wrote:

> Hi Dave,
> 
>> If you mean aggregating the set of folk at all the mics and taking them in the strict order of their coming to the (single) queue, that doesn't work on average, unless the queue is tiny.  The chair can't keep track of who arrived to the queue and when.
> 
> I personally like Brian's idea, and think the all thing might work smoothly if you make use of a tool capable to automatically collect and moderate floor requests, to be put in a (virtual) single queue. What I'm thinking of is RFIDs triggering BFCP (Binary Floor Control Protocol) requests, in much the same way as the floor requests generated by remote participants. The same tool should then provide session chairs with a chance to give potential "business class" requests (i.e., in the case of cut and thrust debates, or in the presence of an AD intervention) higher priority (which basically means putting such requests on top of the queue).

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Nov 2011 07:44:21 -0800

While discussing specific protocols that can be used is interesting, it is not the topic of this thread. I'd like to bring the thread back to the original message because I have been told by some ADs of WGs that had remote participants, but I have not heard from those WG chairs.

> FWIW, I have already gotten a *great* set of comments from many of the people you pointed towards me from the last message. Let's keep more coming. Thanks in advance!

--Paul Hoffman