Re: [Tools-discuss] [Manycouches] Proposal to discontinue live mp3 audio streams at IETF meetings

Alexandre Petrescu <> Wed, 07 October 2020 09:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D68DD3A16EB; Wed, 7 Oct 2020 02:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.458
X-Spam-Status: No, score=0.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.213, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZD-fLeHg2QZY; Wed, 7 Oct 2020 02:20:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6B573A0E13; Wed, 7 Oct 2020 02:20:06 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0979K4WI009117; Wed, 7 Oct 2020 11:20:04 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id 51CE42041BD; Wed, 7 Oct 2020 11:20:04 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 3D18520413D; Wed, 7 Oct 2020 11:20:04 +0200 (CEST)
Received: from [] ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0979K4xH031330; Wed, 7 Oct 2020 11:20:04 +0200
To: Robert Sparks <>, Tom Pusateri <>, Carsten Bormann <>
Cc: Tools Discussion <>,
References: <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Wed, 7 Oct 2020 11:20:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Tools-discuss] [Manycouches] Proposal to discontinue live mp3 audio streams at IETF meetings
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Oct 2020 09:20:09 -0000

Le 06/10/2020 à 21:49, Robert Sparks a écrit :
> On 10/5/20 11:39 AM, Tom Pusateri wrote:
>>> On Oct 5, 2020, at 12:28 PM, Carsten Bormann <>
>>> wrote:
>>> On 2020-10-05, at 17:57, Tom Pusateri 
>>> <> wrote:
>>>> I would support using Opus over MP3 but that is not the main 
>>>> obstacle. We need a way to map live streams to sessions in the
>>>> API to restore widespread access to the streams.
>>> Apologies for a stupid question:  Why do we need to have a
>>> limited number of sessions?  Can’t we make each WG its own
>>> session?
>>> Grüße, Carsten
>> In the past (with physical meetings), the hardware to stream was
>> set up in a meeting room and tied to that location throughout the
>> week. There were typically 8 streams that didn’t change except for
>> when rooms were reconfigured throughout the week to make
>> bigger/smaller spaces.
>> Once the stream number was tied to a room location, I was able to 
>> determine which sessions would be held in the room and know which 
>> stream to join for each session.
>> So the limited number of streams is based on physical audio
>> hardware.
> This is the crux. If we do continue to support these streams (or 
> something different, but meeting the purpose they were intended to 
> serve), the software changes would be exactly in modelling what the 
> streams are connected to. Most likely it would turn into a separate 
> named stream per Session. If foobar met three times during the
> meeting, that would be three separate streams. We would remove the
> assumption that the streams are tied to a specific room, which will
> involve changes at the datatracker, in Meetecho, and in Tom's iphone
> app.
> As I noted in the announcement, these changes aren't prohibitively 
> expensive, but they aren't trivial either, and if there wasn't an
> actual _need_ for the streams, we would be better spending our time
> elsewhere.
> Tom (and others) have made some arguments about why the usage
> statistics we have may not represent the actual desire to use the
> live streams.

I am not disagreeing.  I think  any change needs work and the work
quantity needs to be evaluated.

I would also think about the following: if the one stream per room is a
hardware problem, is that problem related to the use of old mixing
stations?  I remember having seen at room back in f2f ietf meetings some
mixing stations with these numerous linear potentiometers.  These are
outdated tools.

Nowadays people use PCs with large screens and virtual potentiometers.
These dont have limitations in terms of numbers of channels.  There is
programmatical freedom in the way channels are defined, used and sent

If a limitation is in hardware, there is advantage to be gained from
migrating to software functionality.

(I might be trying to persuade the already convinced here, but I wanted
to say that, because it is strange to hear about hardware limitations in
audio, with 110V/220V nearby and all space and coffee).


>> Tom ___________________________________________________________ 
>> Tools-discuss mailing list 
>> Please report and bugs at
>> or send email to
>> Please report bugs at 
>> or send email to