Re: [103attendees] A/V in Bangkok (was: Re: [Thanks, Bangkok !)

Carsten Bormann <cabo@tzi.org> Fri, 09 November 2018 22:45 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: 103attendees@ietfa.amsl.com
Delivered-To: 103attendees@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADBC12D4E7 for <103attendees@ietfa.amsl.com>; Fri, 9 Nov 2018 14:45:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKFZGNCi0gVu for <103attendees@ietfa.amsl.com>; Fri, 9 Nov 2018 14:45:02 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31D05129619 for <103attendees@ietf.org>; Fri, 9 Nov 2018 14:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA9Miqtu006836; Fri, 9 Nov 2018 23:44:57 +0100 (CET)
Received: from [IPv6:2001:67c:1232:144:4ca7:1ca5:121e:cc52] (unknown [IPv6:2001:67c:1232:144:4ca7:1ca5:121e:cc52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42sFb60mmTz1Bqf; Fri, 9 Nov 2018 23:44:49 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <E1443D6EC0DFCDCC464FD64C@PSB>
Date: Sat, 10 Nov 2018 05:44:42 +0700
Cc: 103attendees@ietf.org
X-Mao-Original-Outgoing-Id: 563496281.198341-861b4454ac6bde68ebbd965ec61c720f
Content-Transfer-Encoding: quoted-printable
Message-Id: <E71EDD82-D189-4ADE-A90F-98E6D6B02BD1@tzi.org>
References: <3F80FD28-C7D9-4C72-96FA-1ACD60A3A4B3@ackl.io> <7C9CE065-947B-435F-A8DA-FDDA0C3B1DBB@tzi.org> <E1443D6EC0DFCDCC464FD64C@PSB>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/103attendees/eyzYMpvhvP3rYgG7PipJQ9fYqXI>
Subject: Re: [103attendees] A/V in Bangkok (was: Re: [Thanks, Bangkok !)
X-BeenThere: 103attendees@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mailing list of IETF 103 attendees that have opted in on this list <103attendees.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/103attendees>, <mailto:103attendees-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/103attendees/>
List-Post: <mailto:103attendees@ietf.org>
List-Help: <mailto:103attendees-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/103attendees>, <mailto:103attendees-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 22:45:05 -0000

The good thing was that there often were AV people in the room that could handle problems right away.

Not so good was that this was actually needed in all the meetings I chaired, where microphone batteries were running out while people were speaking into the microphones and otherwise randomly malfunctioned.

The fun instant was where this happened and the A/V guys (at least two) were in the room but had headphones on and were playing with their phones, so we had to throw hard objects at them to get them to fix things (slightly exaggerating).

(I also wasn’t so fond about the guy who was collecting A/V stuff from the floor while we were running a Friday meeting.)

The impact of all this was minimal, this never slowed us down a lot.  But it was a distraction.
When we had real problems (such as a projector suddenly going into HDCP mode), the A/V guys always were quick to get a workaround going.

Wrt meetecho presenter problems:

I would chalk most mute microphone problems up to the fact that many people are using their laptops for this, and laptops are used every day in varying audio configurations.  So whether the configuration is right when you actually want to speak is somewhat random, even if it worked OK the week before.  (Experienced teleconference users aren’t immune to that, and doing microphone tests is just part of the hourly routine.)  In meetecho, there probably should be a quick test that you are reminded to use immediately at the start of the meeting, where you get your own audio echoed back.

This would also help with the inevitable sound level problems.  There are not many meeting apps that get AGC right.  I heard several people who were indeed clipping, and the codec used by meetecho wasn’t helping to conceal this, but instead exaggerated it.   Still much better than the WebEx experiences with completely random micropohone levels…  (Jitsi has this great feature where, as a listener, you get to adjust the level of each speaker for yourself, but this doesn’t help with clipping of course.)

There is also the case where the firewall the presenter is behind detects the sudden flow of data as an unauthorized data exfiltration and shuts you down.  We need to remind people to get on the Internet for the conferencing.  But all mute microphone cases I have seen this week looked to be more of the local audio config variety.

Grüße, Carsten


> On Nov 9, 2018, at 22:29, John C Klensin <john-ietf@jck.com> wrote:
> 
> Carsten (and others),
> 
> For the benefit of those of us who are remote and for anyone
> concerned about remote participation, could you be more precise
> about the AV issues you saw.   I have never found the Meetecho
> people and network/NOC staff and volunteers to be anything but
> responsive, often astonishingly so -- the exact opposite of
> "sloppy" -- and we don't thank them often enough.  On the other
> hand, we have had problems in the past when hotel staff run the
> AV equipment and don't take it quite as seriously as we do.  I'm
> aware of at least one incident of that during this meeting when
> a probably-important comment was made into a floor microphone
> that was not transmitting.
> 
> This is important, IMO.   Many years ago, we concluded that
> audio feeds, IM, and, later archiving of meetings was important
> enough to us that we couldn't rely on hotel networks.  As I
> understand it, if a venue told us that their facilities and
> staff were required to be used and that our people did not have
> direct control over them, the people in the meeting site
> selection process decided to find another venue.  As our
> dependency on remote participation has risen and our presumed
> commitment to it has as well, are we at the point at which we
> need the same policy for A/V operations: The facility is asked
> during the site selection process whether we will be able to
> operate it ourselves. If the answer is "no", we move on and, if
> it is "yes", that goes into the contract?
> 
> I know this list is not the best place to ask the question, but
> it is the one on which the people with the most direct
> experience of the meeting are presumably hanging out.
> 
>    john
> 
> 
> --On Friday, November 9, 2018 15:44 +0700 Carsten Bormann
> <cabo@tzi.org> wrote:
> 
>> ...
>> The biggest problem (relatively speaking, because it never was
>> a big problem) was the slightly sloppy attitude of the AV
>> people.  
>> ...
> 
> 
> 
> -- 
> 103attendees mailing list
> 103attendees@ietf.org
> https://www.ietf.org/mailman/listinfo/103attendees
>