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

Robert Sparks <> Tue, 06 October 2020 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B9C53A0E22; Tue, 6 Oct 2020 12:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.274, NICE_REPLY_A=-0.213, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rAHAqwZCS0ck; Tue, 6 Oct 2020 12:50:07 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC3BB3A0E15; Tue, 6 Oct 2020 12:50:07 -0700 (PDT)
Received: from unescapeable.local ([]) (authenticated bits=0) by (8.16.1/8.16.1) with ESMTPSA id 096JnxFJ046751 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 6 Oct 2020 14:50:00 -0500 (CDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1602013803; bh=nglrshWuXGzNSfuYftIa/VCcxHvVsUTB/MjX7WSOxvo=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=oiNe6akwSXypaqojxY9TJzGGFk1phFZPQGQ/APVuT0/EkSCjug4ytGsU5c4IQ9ZgT YZRdeEy/S/YP4zCb/V4mlYGicgwh0jZ6rZDFbVGLhNiomZ6OdfMA3sAUO8vl3bGKqJ uyaHdt+ICqrz9tyNrJBsj+FcFT6lxld+tv2hSL3Q=
X-Authentication-Warning: Host [] claimed to be unescapeable.local
To: Tom Pusateri <>, Carsten Bormann <>
Cc: Alexandre Petrescu <>, Tools Discussion <>,
References: <> <>
From: Robert Sparks <>
Message-ID: <>
Date: Tue, 6 Oct 2020 14:49:57 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; 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-Transfer-Encoding: quoted-printable
Content-Language: en-US
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: Tue, 06 Oct 2020 19:50:09 -0000

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.

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