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

John C Klensin <> Fri, 09 November 2018 20:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE24612D4F1 for <>; Fri, 9 Nov 2018 12:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oCNDoniSjVCk for <>; Fri, 9 Nov 2018 12:30:00 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC4FD1293FB for <>; Fri, 9 Nov 2018 12:29:59 -0800 (PST)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1gLDPg-000BpI-RD; Fri, 09 Nov 2018 15:29:56 -0500
Date: Fri, 09 Nov 2018 15:29:51 -0500
From: John C Klensin <>
To: Ted Lemon <>
cc: Carsten Bormann <>,
Message-ID: <F07FBEC3D5CD39652FE90A78@PSB>
In-Reply-To: <>
References: <> <> <E1443D6EC0DFCDCC464FD64C@PSB> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [103attendees] A/V in Bangkok (was: Re: [Thanks, Bangkok !)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mailing list of IETF 103 attendees that have opted in on this list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Nov 2018 20:30:02 -0000

--On Friday, November 9, 2018 15:06 -0500 Ted Lemon
<> wrote:

> There were a lot of cases, particularly early on, when remote
> presenters' audio clipped badly, making it painful to sit in
> the room.   That seemed to improve over the course of the
> week, but the gain on remote presenters in every single remote
> presentation I heard was still too high, again making it
> painful to sit in the room.
> Quite a few times when someone wanted to comment remotely they
> couldn't, because their microphone wasn't working.   This
> wasn't necessarily meetecho's fault in a direct way, but we
> have to figure out how to get this right if we're serious
> about remote participation.


Very helpful.  Thanks.  Wrt the remote presenters and borrowing
from some earlier comments from one of the Meetech team, is
there any way to differentiate how many of those problems with
remote presenters of whom Meetecho was notified well in advance
and with whom they have an opportunity to test and debug (as
they have been requesting for several years) and those who
simply used the remote queue facilities as if they were just
making a comment?