Subject: [vmeet] RPS Priority Question: Audio

From: Russ Housley <[email-masked]>
Date: Wed, 13 Jun 2012 16:45:50 -0400

The current draft says:

2.3.  Audio

 Audio from face-to-face meetings travels in two directions: from the
 room to remote attendees, and (potentially) from remote attendees to
 the room.  Comments on early drafts of this document indicated that
 the latter may not really be a requirement for all attendees if IM-
 to-mic is made predictable.  Given this, reliable IM-to-mic relay for
 comments to speakers is highest priority, audio from remote attendees
 giving presentations is a second priority, and audio from remote
 attendees giving comments to the room is a third priority.

I want to make sure that this represents the community consensus.

My summary:

(1) We have good audio from the room to the remote participant.  Keep doing that.

(2) IM-to-mic is working pretty well too.  Keep doing that, but there might be some improvements that could be made.

(3) Don't do audio to the meeting room for anyone except a remote presenter for quite some time.

Russ

---

From: Melinda Shore <[email-masked]>
Date: Wed, 13 Jun 2012 12:50:33 -0800

> (3) Don't do audio to the meeting room for anyone except a remote presenter for quite some time.

I think this is largely correct; I think the main condition that needs
to be met for audio from remote-to-meeting-room is that there's some
sort of queuing and acknowledgement function available, which suggests
an additional chunk of software.  I believe some conferencing systems
refer to this as "raising your hand."

Melinda

---

From: John Leslie <[email-masked]>
Date: Wed, 13 Jun 2012 20:21:18 -0400

> I want to make sure that this represents the community consensus.

   I haven't screamed yet... but I might...

> (1) We have good audio from the room to the remote participant.

   Umm... predictable delay, please!

> (2) IM-to-mic is working pretty well too.

   Sometimes yes, sometimes no. "Sometimes" is not acceptable.

> Keep doing that, but there might be some improvements that could be made.

   There are a lot of improvements that could be made.

   But I'd recommend that we put audio-from-remote-presenter as a fairly
high priority, and allow WGCs to enable remote-audio for any remote
speaker if they can't make "channeling" dependable.

   In any case, the WGC needs to know when there is a remote participant
wanting to be channeled.

> presenter for quite some time.

   "Quite some time" is a bad target.

   Most in-person attendees dislike dissociated voices. We understand.

   Most remote participants will be happy with "channeling" if it is
timely.

   But there are cases where some back-and-forth is needed -- and we
should aim for something acceptable to in-person attendees in the
one-to-two year timeframe.

   (What we don't mean to set as an at-all-high priority is the
expectation that _anyone_ can ask _any_ question that comes to mind
by remote audio.)

   BTW, Google Hangout was working quite nicely (once we got it working
at all) for RTCWEB this week...

--
John Leslie <[email-masked]>

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 14 Jun 2012 09:44:03 +0200

Hi all,

as I already stated on this list, in my view (3) is fundamental if we 
want to provide a fully-fledged experience to remotes, and I am quite 
confident it can be reliably achieved provided that a good configuration 
of in-room hardware (i.e., the audio mixer) is available. (2) is already 
working, even though we should add (as suggested by Melinda) an 
automated "queuing and acknowledgment function". We have some ideas on 
this and we are hopefully going to experiment (in some Meetecho-enabled 
sessions) them at the upcoming meeting in Vancouver. We are indeed 
prototyping a solution which automatically announces (in the conference 
room and through the conferencing system) a request for attention 
coming, via the jabber room,  from a remote: in a few words, if a remote 
writes a sentence in the chat and lets it be preceded by the [mic] 
prefix, the conferencing system automatically plays a predefined 
'attention sound' inside the room.
Related to this point, I keep on believing that we need to go for 
automated moderation of both local and remote participants. In order to 
get feedback on this, I think I'm going to write a draft on the subject, 
starting from the material we published before IETF 83 
(http://ietf83.conf.meetecho.com/index.php/UMPIRE_Project).

My two cents,

Simon

P.S. I'm skipping (1), since I do agree it is working quite fine today.

Il 13/06/2012 22:50, Melinda Shore ha scritto:
>> (2) IM-to-mic is working pretty well too.  Keep doing that, but there 
>> might be some improvements that could be made.
> _______________________________________________
> 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 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: "Martin J. Dürst" <[email-masked]>
Date: Sun, 17 Jun 2012 18:12:58 +0900

> (1) We have good audio from the room to the remote participant.  Keep doing that.

I agree with others that this is far from being the case. The usual 
delays (20' or thereabouts) are way too large for a timely feedback 
loop, either with voice back or via jabber. These delays are very 
valuable for archiving, but that's about it. (If we are talking about 
Meetecho, then that's a different story.)

> (2) IM-to-mic is working pretty well too.  Keep doing that, but there might be some improvements that could be made.

There are some good examples, but also many others. Things are far from 
solved.

> (3) Don't do audio to the meeting room for anyone except a remote presenter for quite some time.

I'm mixed on this. My experience as a remote presenter in the past few 
meetings has been quite mixed. As long as it's that error-prone to get 
remote presenters hooked up correctly, I'm indeed not sure it makes 
sense to also voice-connect others. However, I think that if we are 
serious about this, we can do a much better job ("this is the number to 
call, or the application/Web page to start up", and it just works), and 
then it shouldn't be that much of a problem to get others than 
presenters connected, and their input would be valuable.

Regards,    Martin.

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Jun 2012 15:22:48 -0400

Thanks for the discussion.  I actually thought that this posting would generate much more traffic than it did.  I conclude that the document has this topic handled roughly correct, and no further discussion of this topic is needed.

Russ