Subject: [vmeet] just a suggestion

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 7 Mar 2014 13:59:41 +0100

I copied my message that I sent to All attendees here 
-------------------------------
Just a far suggestion
It would be good that there was possibility like a classroom that the remote
participant could really talk (raise their hands and the jabber scripter
gives him/her permission for microphone) and talk. Then I guess the remote
participant wasn't something different than the real participant 

Of course it is just a wild idea.. and needs infrastructure and works.

Thanks for all jabber scripter, all organizers, all people who helped the
remote participant to feel like they are there.

Hosnieh

---

From: SM <[email-masked]>
Date: Fri, 07 Mar 2014 06:14:38 -0800

Hi Hosnieh,
>Of course it is just a wild idea.. and needs infrastructure and works.

See http://ietf83.conf.meetecho.com/index.php/UMPIRE_Project

I have not tested that.

Regards,
-sm

---

From: Simon Pietro Romano <[email-masked]>
Date: Sat, 8 Mar 2014 20:41:17 +0100

Hi all,

as indicated by SM, we at Meetecho have worked quite a lot on this kind of scenarios. At the upcoming IETF in Toronto we plan to conduct a couple of tests based on the mentioned UMPIRE technology. Suggestions and proposals are more than welcome!

Cheers,

Simon

On 07/mar/2014, at 15:14, SM wrote:

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

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

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

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 10 Mar 2014 22:49:36 +0100

Hi Simon,

I sent the other suggestion via other message. Here I’d like to consider the
realization of that suggestion. I guess it would be really useful and fair
for remote participant as well as people at IETF.

Since the main problem of remote participant is that the jabber scribes do
not always have a chance to replay the comments of these participants. I
have a possible, might be easy, suggestion.

I guess it shouldn’t be so difficult to have a program for assigning numbers
to people at IETF. Consider a case where there is a laptop close to
microphone (or computer). This laptop only runs a web application that the
participant in IETF can click on a button and receive a number from this
laptop. They will then wait at the microphone until the application calls
out their number from the speaker. 

The remote participant also use their application that you called it
“UMPIRE” to raise their hands and ask for microphone permission. The
application assign numbers to people in order. (for the application it
doesn’t matter whether the person is onsite or in remote. For example, if
remote participant raise its hand earlier than someone clicked on button
onsite, then the remote participant receives number 1 and the onsite person
receives number 2. ) Then for remote participant the application needs to
replay their voice from the laptop speaker or other speaker and for onsite
participant, they can use the microphone after their numbers is called out
from the speaker. This gives the same chance for both remote and onsite
participant to participate and give their comments.

I attached a picture.

Problem statement:

-          Comments of remote participant will not always replay 

-          It is not easy to receive the attention of jabber scribes during
comments sections

-          The jabber scribe is only one person and not easy to replay the
comments of 1 to several people who attended remotely

Remote participant Use cases:

-          They should be able to raise their hands (show an icon)

-          They should be able to talk themselves (their voice can be heard
from the numbering laptop, etc.)

Application admin (jabber scribes or chairs, etc.)

-          Free up the microphone so that the application can let the people
who raise their hands to talk or put them in a queue of people who are
waiting for talk

People who presents at IETF

-          They should be able to choose a number for talking (this is only
for fairness)

-          They should be able to receive a number from a laptop (close to
microphone or else that is connected to the main app which remote
participant using)

-          They should hear their number loudly from the laptop speaker (so
that they know it is their time to talk at the mic)

I hope I could be of any help and my explanation is clear.

Thanks,

Best,

Hosnieh

From: Simon Pietro Romano [mailto:[email-masked]] 
Sent: Saturday, March 08, 2014 8:41 PM
To: SM
Cc: Hosnieh Rafiee; [email-masked]
Subject: Re: [vmeet] just a suggestion

Hi all,

as indicated by SM, we at Meetecho have worked quite a lot on this kind of
scenarios. At the upcoming IETF in Toronto we plan to conduct a couple of
tests based on the mentioned UMPIRE technology. Suggestions and proposals
are more than welcome!

Cheers,

Simon

Hi Hosnieh,

I have not tested that.

Regards,
-sm 

_\\|//_

                                                              ( O-O )

                                                        Simon Pietro Romano

                                                Universita' di Napoli
Federico II

                      <<Molti mi dicono che lo scoraggiamento è l'alibi
degli 

                      idioti. Ci rifletto un istante; e mi scoraggio>>.
Magritte.

                                                          oooO

                                                                \ (
(   )

                                                             \_)          )
/

                                                                       (_/

---

From: Alessandro Amirante <[email-masked]>
Date: Tue, 11 Mar 2014 13:10:44 +0100

Hosnieh,

I'm afraid simple number assignment is not suitable for the IETF 
process. The solution you propose would not work for several reasons:

1. bigger room have more than one mic;
2. you have to take into account different roles (e.g, an AD coming to 
the mic usually skips the queue);
3. replaying remote voice through the laptop speakers would generate 
acoustic echo for the remote speaker itself;
4. remote voice would be barely audible in bigger rooms, as well as for 
other remote participants.

The UMPIRE project is something similar in the approach, as mixes all 
participants in a single queue, regardless them being locals or remotes. 
Locals ask to speak by swiping an RFID tag (which may be embedded in 
their badges), remotes ask to speak by clicking on a button on the 
Meetecho interface. Remote audio is injected into the room and is 
available for other remote participants as well. Besides, UMPIRE:

a) works side-by-side with Meetecho, which is connected to the room 
audio board to suppress echo;
b) handles different roles;
c) gives chairs the possibility to moderate requests (i.e., 
grant/deny/revoke floors).

Furthermore, it would require no hardware other than cheap RFID readers 
and tags.

Cheers,
Alessandro

Il 10/03/2014 22:49, Hosnieh Rafiee ha scritto:
> Hi Simon,
>
> I sent the other suggestion via other message. Here I’d like to consider
> the realization of that suggestion. I guess it would be really useful
> and fair for remote participant as well as people at IETF.
>
> Since the main problem of remote participant is that the jabber scribes
> do not always have a chance to replay the comments of these
> participants. I have a possible, might be easy, suggestion.
>
> I guess it shouldn’t be so difficult to have a program for assigning
> numbers to people at IETF. Consider a case where there is a laptop close
> to microphone (or computer). This laptop only runs a web application
> that the participant in IETF can click on a button and receive a number
> from this laptop. They will then wait at the microphone until the
> application calls out their number from the speaker.
>
> doesn’t matter whether the person is onsite or in remote. For example,
> if remote participant raise its hand earlier than someone clicked on
> button onsite, then the remote participant receives number 1 and the
> onsite person receives number 2. ) Then for remote participant the
> application needs to replay their voice from the laptop speaker or other
> speaker and for onsite participant, they can use the microphone after
> their numbers is called out from the speaker. This gives the same chance
> for both remote and onsite participant to participate and give their
> comments.
>
> I attached a picture.
>
> Problem statement:
>
> -Comments of remote participant will not always replay
>
> -It is not easy to receive the attention of jabber scribes during
> comments sections
>
> -The jabber scribe is only one person and not easy to replay the
> -They should be able to raise their hands (show an icon)
>
> -They should be able to talk themselves (their voice can be heard from
> the numbering laptop, etc.)
>
> -Free up the microphone so that the application can let the people who
> raise their hands to talk or put them in a queue of people who are
> waiting for talk
>
> -They should be able to choose a number for talking (this is only for
> fairness)
>
> -They should be able to receive a number from a laptop (close to
> -They should hear their number loudly from the laptop speaker (so that
> they know it is their time to talk at the mic)
>
> //
> *From:*Simon Pietro Romano [mailto:[email-masked]]
> *Sent:* Saturday, March 08, 2014 8:41 PM
> *To:* SM
> *Cc:* Hosnieh Rafiee; [email-masked]
> *Subject:* Re: [vmeet] just a suggestion
>
> Hi all,
>
> as indicated by SM, we at Meetecho have worked quite a lot on this kind
> of scenarios. At the upcoming IETF in Toronto we plan to conduct a
> couple of tests based on the mentioned UMPIRE technology. Suggestions
> and proposals are more than welcome!
>
> Cheers,
>
> Simon
>
> <mailto:[email-masked]>
>

-- 
Ing. Alessandro Amirante, Ph.D.

Meetecho S.r.l.
www.meetecho.com

Via C. Poerio, 89/a
80121 Napoli, Italy

Mobile: +39 329 6178743
E-mail: [email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 Mar 2014 09:00:02 -0400

I’ve been thinking about this, and wonder if we actually could make this even better.

So, maybe the way we deal with mic is to…get rid of in-room microphones.
Have an app that runs on phones, laptops and tablets that puts you in the queue, and you use your device mic to speak, when you are recognized.

We might need some kind of way handle an in-room participant that doesn’t have a suitable device, but that is a very small minority of in-room participants.

It may be that the app has to do echo cancel, or maybe we could do it centralized (as long as we can have accurate timing from the source).

Brian

On Mar 11, 2014, at 8:10 AM, Alessandro Amirante <[email-masked]> wrote:

> Hosnieh,
> 
> I'm afraid simple number assignment is not suitable for the IETF process. The solution you propose would not work for several reasons:
> 
> 2. you have to take into account different roles (e.g, an AD coming to the mic usually skips the queue);
> 3. replaying remote voice through the laptop speakers would generate acoustic echo for the remote speaker itself;
> 4. remote voice would be barely audible in bigger rooms, as well as for other remote participants.
> 
> The UMPIRE project is something similar in the approach, as mixes all participants in a single queue, regardless them being locals or remotes. Locals ask to speak by swiping an RFID tag (which may be embedded in their badges), remotes ask to speak by clicking on a button on the Meetecho interface. Remote audio is injected into the room and is available for other remote participants as well. Besides, UMPIRE:
> 
> a) works side-by-side with Meetecho, which is connected to the room audio board to suppress echo;
> c) gives chairs the possibility to moderate requests (i.e., grant/deny/revoke floors).
> 
> Furthermore, it would require no hardware other than cheap RFID readers and tags.
> 
> Cheers,
> Alessandro
>

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 11 Mar 2014 09:52:54 -0500

On 03/11/2014 08:00 AM, Brian Rosen wrote:
> I've been thinking about this, and wonder if we actually could make 
> this even better.
>
> So, maybe the way we deal with mic is to...get rid of in-room microphones.
> Have an app that runs on phones, laptops and tablets that puts you in 
> the queue, and you use your device mic to speak, when you are recognized.

I ended up as note-taker in AQM last week. Even being an AD doesn't get 
you out of taking notes :-)

Which leads me to my point. It's a pretty serious disincentive for a 
serious participant (and ADs are at least supposed to be paying 
attention between e-mails) to volunteer as note-taker if they have to 
stand in a mike line holding their laptop open and typing, in order to 
say anything.

During the Harald Alvestrand-as-IETF Chair era, I was usually note-taker 
for IESG plenaries, and we joked about that being a DOS attack because 
if I was sitting down typing, I wasn't standing up talking (let's ignore 
whether that was a good thing or a bad thing, OK?).

Some chairs have let me wave frantically to attract their attention, so 
they could put me "virtually in line" until it was my turn, but I was 
delaying the meeting while running to the mike and missing about half 
what was said while returning to my seat.

Brian's suggestion could help with that.

Spencer, as repeat-offender scribe-for-life

> We might need some kind of way handle an in-room participant that 
> doesn't have a suitable device, but that is a very small minority of 
> in-room participants.
>
> It may be that the app has to do echo cancel, or maybe we could do it 
> centralized (as long as we can have accurate timing from the source).
>
> Brian

---

From: Alexa Morris <[email-masked]>
Date: Tue, 11 Mar 2014 07:58:48 -0700

One of my colleagues recently showed me this free app: http://crowdmics.com/ thinking that it might work for the IETF.  It purports to do just what you are talking about and I've been mulling over how we might experiment with it (or something similar)

Alexa

On Mar 11, 2014, at 7:52 AM, Spencer Dawkins wrote:

> I ended up as note-taker in AQM last week. Even being an AD doesn't get you out of taking notes :-)
> 
> Which leads me to my point. It's a pretty serious disincentive for a serious participant (and ADs are at least supposed to be paying attention between e-mails) to volunteer as note-taker if they have to stand in a mike line holding their laptop open and typing, in order to say anything.
> 
> During the Harald Alvestrand-as-IETF Chair era, I was usually note-taker for IESG plenaries, and we joked about that being a DOS attack because if I was sitting down typing, I wasn't standing up talking (let's ignore whether that was a good thing or a bad thing, OK?).
> 
> Some chairs have let me wave frantically to attract their attention, so they could put me "virtually in line" until it was my turn, but I was delaying the meeting while running to the mike and missing about half what was said while returning to my seat.
> 

----------
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: [email-masked]

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com <http://www.amsl.com/>

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 11 Mar 2014 10:07:08 -0500

> doesn't have a suitable device, but that is a very small minority of 

I was excited enough by Brian's suggestion that I skipped over this in 
my first response.

We are starting to get IETF participants that are on a LOT lower budget 
than what we expect (one of the first-time attendees asking for info 
about hotels in London was thinking in terms of hostels). I don't know 
what the right mailing list would be to ask the question on, but it 
might be helpful to ask on an appropriate mailing list whether there are 
attendees who don't have a mike-capable device with them when they 
attend IETF meetings in person.

It might be good to know whether "very small minority" is more like 5, 
or more like 50.

Spencer

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 11 Mar 2014 11:07:08 -0400

I was listening to one of the sessions through the live audio streaming feature of the iPhone IETFers app this week while I was in the session to just verify the streaming was working from the app. There was about a 10 second delay between the live audio and the streaming audio. Joel noted that in addition to audio processing and conversion, the audio was sent from London to Washington State where it was replicated back to London.

The delays are important to any form of remote participation. If you want remote participants to interact with live participants, you must keep the delay as low as possible or the live participants will give up on the remote participants. This actually quite difficult to do well while also scaling to reach lots of remote participants.

It will require extra audio engineering work for each location as well as delay sensitive network testing.

Tom

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 Mar 2014 11:15:07 -0400

The stream is behind, but if you are on Meetecho, it’s pretty good.

Brian

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Mar 2014 15:18:36 +0000

Hi Alexa,

nice Crowd App. I like it.

Though I see an issue. The regular microphone in meeting rooms acts as the good old semaphore and helps to queue people who want to speak.

With the crowd app, how can we avoid people speaking all at once (or when they like) into their smartphones?

Cheers,
Mehmet

From: vmeet [mailto:[email-masked]] On Behalf Of ext Alexa Morris
Sent: Tuesday, March 11, 2014 3:59 PM
To: Spencer Dawkins
Cc: [email-masked]; Alessandro Amirante
Subject: Re: [vmeet] just a suggestion

Alexa

On 03/11/2014 08:00 AM, Brian Rosen wrote:
I've been thinking about this, and wonder if we actually could make this even better.

We might need some kind of way handle an in-room participant that doesn't have a suitable device, but that is a very small minority of in-room participants.

Brian

----------
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: [email-masked]<mailto:[email-masked]>

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com<http://www.amsl.com/> <http://www.amsl.com/>

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Mar 2014 11:19:04 -0400

Crowdmics seems very interesting.  Maybe we can try an experiment in a small meeting before we try it in plenary.

Russ

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 Mar 2014 11:26:55 -0400

It’s close, but it’s not at all ideal.

First of all, it’s iOS/Android only.  No Windows, no mac.
You need one device (iOS/Android) connected to the room audio.  We might be able to find a cheap wifi only android device with audio that would serve the purpose.
You need accounts for every person in their system, and you know how we love that kind of thing.

It seems to be a bit clunky to deal with all of our “events”.

But mostly, the way the presenter controls access doesn’t match what we want.

I’m not sure how well it would work for a remote questioner.  It’s not clear how it decides who can get into the event.

But, it’s the basic idea of what we want.  It may be possible to work with them to get it to work for us.

Brian

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 11 Mar 2014 16:28:33 +0100

Alex,

When the people need to use one application to get numbers, one mic is
enough since not all people can talk at the same time in the room. Actually,
several mic doesn't help with the process of talking since again it is like
a queue.

And for the ADs they can have priority when they take numbers . there can be
two buttons, one for ADs and one for others. For them the app can react like
a stack and put them in the beginning of the queue. 

As Brian mentioned, for voice, it is also possible to use echo cancellation
approaches.

Hosnieh 

 

From: vmeet [mailto:[email-masked]] On Behalf Of Ersue, Mehmet (NSN
- DE/Munich)
Sent: Tuesday, March 11, 2014 4:19 PM
To: ext Alexa Morris; Spencer Dawkins
Cc: Alessandro Amirante; [email-masked]
Subject: Re: [vmeet] just a suggestion

Hi Alexa,

Though I see an issue. The regular microphone in meeting rooms acts as the
good old semaphore and helps to queue people who want to speak.

With the crowd app, how can we avoid people speaking all at once (or when
they like) into their smartphones?

Cheers, 
Mehmet 

One of my colleagues recently showed me this free app: http://crowdmics.com/
thinking that it might work for the IETF.  It purports to do just what you
are talking about and I've been mulling over how we might experiment with it
(or something similar)

Alexa

 

I've been thinking about this, and wonder if we actually could make this
even better. 

So, maybe the way we deal with mic is to.get rid of in-room microphones.

Have an app that runs on phones, laptops and tablets that puts you in the
queue, and you use your device mic to speak, when you are recognized.

I ended up as note-taker in AQM last week. Even being an AD doesn't get you
out of taking notes :-)

Which leads me to my point. It's a pretty serious disincentive for a serious
participant (and ADs are at least supposed to be paying attention between
e-mails) to volunteer as note-taker if they have to stand in a mike line
holding their laptop open and typing, in order to say anything.

During the Harald Alvestrand-as-IETF Chair era, I was usually note-taker for
IESG plenaries, and we joked about that being a DOS attack because if I was
sitting down typing, I wasn't standing up talking (let's ignore whether that
was a good thing or a bad thing, OK?).

Some chairs have let me wave frantically to attract their attention, so they
could put me "virtually in line" until it was my turn, but I was delaying
the meeting while running to the mike and missing about half what was said
while returning to my seat.

We might need some kind of way handle an in-room participant that doesn't
have a suitable device, but that is a very small minority of in-room
participants.

Brian

----------

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com <http://www.amsl.com/>  <http://www.amsl.com/>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 Mar 2014 11:32:01 -0400

It says you need to be on the same WiFi net to participate.

---

From: Alexa Morris <[email-masked]>
Date: Tue, 11 Mar 2014 08:42:22 -0700

It has a queuing feature built in -- you join the meeting room, you get in line, and when it's your turn there is another smart phone acting as moderator that passes mic control to you. It sounds interesting but I do have concerns (not least of them being how to fairly accommodate those who don't happen to have a smart phone) and we would clearly need to try this out in a very small session first.

Alexa

----------

---

From: Alessandro Amirante <[email-masked]>
Date: Tue, 11 Mar 2014 16:49:50 +0100

Exactly. Meetecho deploys servers on-site. The delay is usually ~1sec.

Alessandro

Il 11/03/2014 16:15, Brian Rosen ha scritto:
> On Mar 11, 2014, at 11:07 AM, Tom Pusateri <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> I was listening to one of the sessions through the live audio
>> streaming feature of the iPhone IETFers app this week while I was in
>> the session to just verify the streaming was working from the app.
>> There was about a 10 second delay between the live audio and the
>> streaming audio. Joel noted that in addition to audio processing and
>> conversion, the audio was sent from London to Washington State where
>> it was replicated back to London.
>>
>> The delays are important to any form of remote participation. If you
>> want remote participants to interact with live participants, you must
>> keep the delay as low as possible or the live participants will give
>> up on the remote participants. This actually quite difficult to do
>> well while also scaling to reach lots of remote participants.
>>
>> On Mar 11, 2014, at 10:58 AM, Alexa Morris <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> One of my colleagues recently showed me this free app:
>>> http://crowdmics.com/ thinking that it might work for the IETF.  It
>>> purports to do just what you are talking about and I've been mulling
>>> over how we might experiment with it (or something similar)
>>>
>>> Alexa
>>>
>>>>> Have an app that runs on phones, laptops and tablets that puts you
>>>>> in the queue, and you use your device mic to speak, when you are
>>>>> recognized.
>>>>
>>>> attention between e-mails) to volunteer as note-taker if they have
>>>> to stand in a mike line holding their laptop open and typing, in
>>>> order to say anything.
>>>>
>>>> During the Harald Alvestrand-as-IETF Chair era, I was usually
>>>> note-taker for IESG plenaries, and we joked about that being a DOS
>>>> attack because if I was sitting down typing, I wasn't standing up
>>>> talking (let's ignore whether that was a good thing or a bad thing,
>>>> OK?).
>>>>
>>>> Some chairs have let me wave frantically to attract their attention,
>>>> so they could put me "virtually in line" until it was my turn, but I
>>>> was delaying the meeting while running to the mike and missing about
>>>> half what was said while returning to my seat.
>>>>
>>>>> doesn’t have a suitable device, but that is a very small minority
>>>>> of in-room participants.
>>>>>
>>>>> It may be that the app has to do echo cancel, or maybe we could do
>>>>> it centralized (as long as we can have accurate timing from the
>>>>> source).
>>>>>
>>>>> Brian
>>>>
>>> Email: [email-masked] <mailto:[email-masked]>
>>>

Meetecho S.r.l.
www.meetecho.com

Via C. Poerio, 89/a
80121 Napoli, Italy

Mobile: +39 329 6178743

---

From: Tony Hansen <[email-masked]>
Date: Tue, 11 Mar 2014 12:03:51 -0400

One IETF meeting that I was "attending" remotely, I measured the audio 
stream delay at about 30 seconds. I found that quite often by the time I 
typed in a question into jabber to be channeled to the microphone, the 
speakers were often a 2-3 issues/slides/topics beyond what my question 
was related to.

The sessions that used meetecho were NOT delayed as much.

I think it would be worth investing some effort into improving the delay 
on the audio stream.

     Tony Hansen

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 Mar 2014 12:04:46 -0400

--On Tuesday, March 11, 2014 08:42 -0700 Alexa Morris
<[email-masked]> wrote:

> It has a queuing feature built in -- you join the meeting
> room, you get in line, and when it's your turn there is
> another smart phone acting as moderator that passes mic
> control to you. It sounds interesting but I do have concerns
> (not least of them being how to fairly accommodate those who
> don't happen to have a smart phone) 

More of an issue than one might think given those of us who keep
a deliberately-not-smart phone around and put an inexpensive
GSM-only (no data) SIM in it for some international meetings.  

If it only works when everyone is on the same WiFI network, it
is useless for us: not only would remote participants be on a
different network (something we could presumably overcome with
some fancy tunnels), it would also prevent us from running
multiple meeting SSIDs and setups as we do today.  As others
have suggested, maybe it is the beginning of an idea but
probably not even ready to try in its current form.

   john

> and we would clearly need
> to try this out in a very small session first.

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Mar 2014 16:16:50 +0000

Queuing feature sounds good.

For the beginning I think we need the microphones for those who don't have a smartphone or as a fallback solution.
I also can imagine that there will be sufficient amount of smartphones around, which can be shared within 1 square meter.

May be we can test it indeed before and use in Toronto.

Could the very small session be a small meeting at AMS ;) ?

Cheers,
Mehmet

From: ext Alexa Morris [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 4:42 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: Spencer Dawkins; [email-masked]; Alessandro Amirante
Subject: Re: [vmeet] just a suggestion

Alexa

Hi Alexa,

Cheers,
Mehmet

From: vmeet [mailto:[email-masked]] On Behalf Of ext Alexa Morris
Sent: Tuesday, March 11, 2014 3:59 PM
To: Spencer Dawkins
Cc: [email-masked]<mailto:[email-masked]>; Alessandro Amirante
Subject: Re: [vmeet] just a suggestion

Alexa

Brian

----------

----------

---

From: Alexa Morris <[email-masked]>
Date: Tue, 11 Mar 2014 09:19:55 -0700

Inline:

> GSM-only (no data) SIM in it for some international meetings.  

And even if you have a smart phone, you have to remember to download the app and then join the right "event" so that you can get into the queue. I think right now that the barrier to entry is too significant for our population. 

> probably not even ready to try in its current form.

Understand and agree, though we can continue to research and explore in the background as at some point it (or something like it) will be ready for us to try. 

However as was mentioned before, Meetecho has a very intriguing solution for mic queueing that accommodates both in-room and remote attendees and the only thing it's dependent on is the willingness of the in-room participant to wear a temporary RFID tag. So we will be trying this out in Toronto in one or two sessions. 

----------

---

From: Alexa Morris <[email-masked]>
Date: Tue, 11 Mar 2014 09:26:47 -0700

> Could the very small session be a small meeting at AMS ;) ?

I had a similar thought but unfortunately we don't have an A/V system at AMS that we could use for such an experiment. However if / when the IETF decide to experiment with something like this, we will of course do a dry run outside of a working session. 

Alexa

----------

---

From: joel jaeggli <[email-masked]>
Date: Tue, 11 Mar 2014 10:03:35 -0700

On 3/11/14, 9:03 AM, Tony Hansen wrote:
> One IETF meeting that I was "attending" remotely, I measured the
> audio stream delay at about 30 seconds.

in general the total delay accumulated in the encoder and the icecast
server a the point where the client recieves the packet for the http
audio stream is on the order of 1-3 seconds...  clients can and do
deliberately accumulate  much deeper  playout buffers to account for
things like packet-loss, tcp restransmission time etc, in some cases
that is tunable.

As a toolchain, this kit is great for internet radio and enjoys
widespread compatibility. (hence client-free playback on a mobile
phone). as a conferencing tool it's unsuitable for bidirectional
communication or low-latency playout.

> I found that quite often by the time I typed in a question into
> jabber to be channeled to the microphone, the speakers were often a
> 2-3 issues/slides/topics beyond what my question was related to.
> 
> I think it would be worth investing some effort into improving the
> delay on the audio stream.
> 
> Tony Hansen
> 
>> streaming feature of the iPhone IETFers app this week while I was
>> in the session to just verify the streaming was working from the
>> app. There was about a 10 second delay between the live audio and
>> the streaming audio. Joel noted that in addition to audio
>> processing and conversion, the audio was sent from London to
>> Washington State where it was replicated back to London.
>> 
>> The delays are important to any form of remote participation. If
>> you want remote participants to interact with live participants,
>> you must keep the delay as low as possible or the live
>> participants will give up on the remote participants. This
>> actually quite difficult to do well while also scaling to reach
>> lots of remote participants.
>> 
> _______________________________________________ NOTE WELL: This
> list operates according to

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 11 Mar 2014 14:00:05 -0400

Even 1 second is too long for interactive conversation.  200ms is about the limit.

Tom

> On Mar 11, 2014, at 11:49 AM, Alessandro Amirante <[email-masked]> wrote:
>

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 Mar 2014 11:46:09 -0700

Dear Joel, Tony, and John,

Your conclusions sound correct where typing is indeed too slow.  I made a suggestion at the beginning of the vmeet mailing list for the IETF to consider investing in a dedicated netbook computer coupled with the video projector as a means to offer digital sound input and output.  The cost of such a system is now below $100.  Such a configuration would offer remote participants a means to control presentations and to respond verbally when signaled as having singular access (perhaps with tone or icon prompts).

Sound output would multiplex between the netbook computer and the room microphones fed into the room PA and outbound sound stream.  When the group is relatively small, a phone bridge works well for spontaneous conversations, but can prove fairly expensive and will not scale well.

A remote meeting software package could control who has access to video controls and sound outputs.  While there will still be delays, delays would be managed by semaphore signaling with remote meeting software.  Perhaps a signaling ICON on the projector could indicate to local participants when room microphones have access.

A VOIP App in a smartphone permit fairly inexpensive calls, especially when carried over WiFi rather than a cell data plan. The IETF could offer their own Asterisks server to offer each participant their own extension.  These many alternative audio inputs would include a microphone for local participants.  For remote participants, a laptop microphone running a VOIP app, a normal phone, or a smartphone with a VOIP app would allow participants a means to call into meetings.  Those calling in would be muted until granted their turn.

VOIP has come a long way in reducing cost and network overhead while also increasing quality.  It would also provide the IETF greater insight into telco security issues.

Regards,
Douglas Otis

On Mar 11, 2014, at 10:03 AM, joel jaeggli <[email-masked]> wrote:

> Signed PGP part

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 12 Mar 2014 19:39:59 +0900

> what was said while returning to my seat.

What about sitting near the mike, then?

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 12 Mar 2014 19:42:05 +0900

> attend IETF meetings in person.

There's also the problem that having turned on even one mike too much, 
or the wrong mike, will have everybody put their hands over their ears.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 12 Mar 2014 19:56:03 +0900

> The sessions that used meetecho were NOT delayed as much.

Even worse, one meeting I had to present remotely and we only got the 
input (me->room) direction working via skype, and I had to relay on the 
audio stream to listen to questions. It was terrible for me, and it must 
have been terrible for those in the room.

Anyway, W3C uses a very simple system for queuing speakers. On the W3C 
IRC server, there's an IRC bot, for details, please see the "Floor 
control" section in http://www.w3.org/2001/12/zakim-irc-bot. Please have 
a look at it. I'm quite sure W3C would be glad to share the code.

Regards,    Martin.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 12 Mar 2014 13:27:30 +0000

> One of my colleagues recently showed me this free app: http://crowdmics.com/ thinking that it might work for the IETF.  It purports to do just what you are talking about and I've been mulling over…

Interesting. How does it implement voice?

My concern is essentially imposing a cost on a user - roaming charges, which might be nominal for voice (T-Mobile tells me that in most countries it is now $0.20/minute for me, and I would only expect to speak for a minute or two at a time), but could be quite a bit more for data (polls etc). I have a feeling that this expects you to access a web site or such.

Yes, we provide WiFi. That would perhaps mitigate costs. But I have also been charged "roaming" charges when using WiFi, as the telephone operator knows when I use it. I would need to disable data use entirely on the towers, which is readily doable if I think about it but is separate from saying "don't roam".

>>> It may be that the app has to do echo cancel, or maybe we could do it centralized (as long as we can have accurate timing from the source).

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Mar 2014 09:30:07 -0400

--On Wednesday, March 12, 2014 19:39 +0900 "\"Martin J.
Dürst\"" <[email-masked]> wrote:

>> Some chairs have let me wave frantically to attract their
>> attention, so they could put me "virtually in line" until it
>> was my turn, but I was delaying the meeting while running to
>> the mike and missing about half what was said while returning
>> to my seat.
> 

>From experience, if the chairs are using a FIFO queue with one
or more mics and there is any sort of a line, it makes
absolutely no difference.  One of the ideas behind the "Jabber
Scribe" hats was to encourage chairs to give "jump the line"
priority to anyone wearing the hats on the assumption that the
remote participants were already behind due to audio lag,
typing, and reading delays.   Perhaps it would have worked
better with more planning and coordination but Vancouver doesn't
make me optimistic.

   john

---

From: Brian Rosen <[email-masked]>
Date: Wed, 12 Mar 2014 09:36:59 -0400

After coordinating with Alexa, I contacted them.  They are interested in working with us.

It’s local - the way they currently do it, they use Bonjour to figure out if you are on the same WiFi net.  The voice traffic goes direct from the participant device what they call the “Presenter”.  The presenter is jacked into the room audio system.  I’m talking with them about giving us an API to push audio into the presenter from Meetecho.  I also am talking to them about an API to manage the queue, so we could develop a tool for chair use that met all of our needs.  They are already working on a browser based client.  I also asked about a way to preload the events (sessions), and simplify the sign on using our own credentialing system.  It’s a start up, so you know they have to put their limited resources where it makes them the most money, but I think our interests are aligned sufficiently that we might be able to use it.  What intrigues me is that it won’t take much change to the actual client to get what we need.  The APIs, if we can get them, would allow us to do what we need to do without changing the clients.

I thought devices would use WiFi if it was available, and only use the cell radio if it wasn’t.   You certainly can turn off roaming if you need to.

Brian

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 12 Mar 2014 08:41:05 -0500

On 03/12/2014 08:30 AM, John C Klensin wrote:
> absolutely no difference.

Yeah, what John said, in addition to me sitting somewhere and THEN 
getting pinged to take notes :-)

The problem I mentioned is solvable - in the bad old days when we had 
more laptops than electrical outlets and wifi was iffy on the first 
couple of days of each meeting, some chairs were OK with me sitting at 
the table, plugged into the same power the chairs were plugged into, and 
I could just whisper "please put me in the line" without disturbing much.

What I was trying to say was, the suggestion we're talking about, 
probably solved that problem, too.

Spencer

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 12 Mar 2014 10:09:20 -0400

I don't want to state the obvious but don't we have a WG that has direct experience with this problem that created Binary Floor Control Protocol (BFCP)?

It seems like we should eat our own dog food.

Tom

---

From: Brian Rosen <[email-masked]>
Date: Wed, 12 Mar 2014 10:14:00 -0400

The reason I think we should pursue this is that the hard part is getting the audio to work.  Handling the floor control isn’t the hard part.  These guys have made that work (apparently, we haven’t tested it yet).  I like the idea that EVERYONE, remote or local, uses the same system, and has the same capabilities.  If there was an alternative that used BFCP to control the floor, great, but I don’t know of one. 

Brian