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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 1 Oct 2020 14:42:41 +0000

Hello Robert

I believe many agree as I do. If all respond like I also do that will be a lot of traffic for you.
Could you use an online poll, or say that you expect people who do not agree to reply?

Keep safe,

Pascal

> -----Original Message-----
> From: IETF-Announce <[email-masked]> On Behalf Of Robert
> Sparks
> Sent: jeudi 1 octobre 2020 16:32
> To: [email-masked]
> Subject: Proposal to discontinue live mp3 audio streams at IETF meetings
> 
> We propose to discontinue producing live mp3 audio streams for IETF
> meetings, starting with IETF 109 and we want to hear from the community
> before we do.
> 
> At many past meetings we have produced live mp3 streams for each session.
> These steams have been associated with physical meeting rooms, and
> appeared before and during the session as a link on the agenda page to a URL
> like
> 'http://mp3.conf.meetecho.com/ietf/ietf<some_number_associated_with_the
> _room>.m3u'.
> 
> 
> For the last several meetings, these have only been available as a live
> stream.
> Recordings of that stream have not been made available after the
> meeting. The
> full video recording provided by Meetecho has served as the way to listen to
> (or watch) any given session after the fact.
> 
> Further, for the last several meetings, the live streams have seen very
> light
> use, on the order of 10 uses for IETF 108.
> 
> Now that we are holding more meetings online, we have a requirement to
> allow
> meetings to run outside their scheduled times. Allowing the live streams
> to run
> outside their scheduled times will require changing how they are
> represented,
> to no longer be associated with "rooms" or "tracks". The code refactor
> at both
> the datatracker and at meetecho to support would not be a huge effort,
> but it
> also would not be tiny. Instead, we feel that removing this complexity,
> recognizing that the regular meetecho connection and recordings satisfy the
> need, is the better use of our resources. That holds true even for future
> in-person meetings.
> 
> There are several points that have been considered while arriving at this
> proposal:
> 
> * Chairs use the recordings to fill in minutes.
> 
>      For the last several meetings, the chairs have been using the Meetecho
>      recordings for this purpose. Recordings of the live mp3 streams haven't
>      been available.
> 
> * Some participants (especially ADs) want to listen to more than one
> meeting at
>    a time.
> 
>      Meetecho allows joining multiple sessions.
> 
> * Some participants may not have the bandwidth or a new enough computer
> to run
>    meetecho.
> 
>      The use of the mp3 streams has been very low at the last several
> meetings.
>      This population isn't using the mp3 streams to address the posited
>      limitations.  If this is a     concern that some people think they
> will
>      experience then we can look at asking Meetecho to allow sending only
>      audio (muting all video).
> 
> * This removes a mechanism that allowed people to listen to a session in
>    real-time without paying a registration fee.
> 
>     There will be ongoing discussion and tuning of the meeting registration
>     structure. In the meantime, the fee waiver program is available and
> being
>     improved.
> 
> Please send comments by 16 Oct 2020 either to [email-masked] or
> directly to [email-masked].
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 1 Oct 2020 15:55:20 +0000

Hello,
I think it is not a very good idea.
This would be closing the last non-paying option to get real-time audio from IETF meetings. I understand that may be the point, but it will cut off a stream of participation that has proved useful for some of us in the past.
You noted that there was very light use during the recent meetings, but there may be an easy explanation : I tried myself to get at the audio feeds during IETF108 and failed. I didn't dig very deep into it (there was meeting going on), but to make things simple what I got was not an mp3 feed but something else  (maybe a live streaming manifest) that no application I had would recognize (not even VLC which is not very picky).
So the explanation for the light usage might just be that it was nonobvious to use, a bit like it is nonobvious to use Jabber. There were recent efforts at improving setup for Jabber (such as providing information on clients, accounts and servers), something similar for audio would have been helpful. 
A better path would have been to make it easier to use (RTFM) rather than killing it altogether.
Regards,
Julien.

-----Original Message-----
From: IETF-Announce <[email-masked]> On Behalf Of Robert Sparks
Sent: Thursday, October 1, 2020 4:32 PM
To: [email-masked]
Subject: Proposal to discontinue live mp3 audio streams at IETF meetings

We propose to discontinue producing live mp3 audio streams for IETF meetings, starting with IETF 109 and we want to hear from the community before we do.

At many past meetings we have produced live mp3 streams for each session. These steams have been associated with physical meeting rooms, and appeared before and during the session as a link on the agenda page to a URL like 'http://mp3.conf.meetecho.com/ietf/ietf<some_number_associated_with_the_room>.m3u'. 

Now that we are holding more meetings online, we have a requirement to allow

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Oct 2020 12:33:18 -0400

> meetings, starting with IETF 109 and we want to hear from the community

uhm, okay.

    > allow meetings to run outside their scheduled times. Allowing the live
    > streams to run outside their scheduled times will require changing how
    > they are represented, to no longer be associated with "rooms" or
    > "tracks". The code refactor at both the datatracker and at meetecho to
    > support would not be a huge effort, but it also would not be
    > tiny. Instead, we feel that removing this complexity, recognizing that
    > the regular meetecho connection and recordings satisfy the need, is the
    > better use of our resources. That holds true even for future in-person
    > meetings.

I understand.
I would request that the mp4's that are produced and uploaded to youtube be
made available via some other site as well.

I'm okay if the site has no "player", and if it's just raw files, and I'm
okay if the bandwidth per connection is intentionally set such that I can't
stream it "live".
(That is, I'd have to start a transfer for the 1hr recording, and it may take
more than 1hr to download.  I'm not insisting that this be done, I'm
just saying that I'm okay if for reasons of cost-of-CPU-diskio-and-bandwidth
it works out that way.)

There is still a contingent that dislikes having to deal with Big Tech.
The audio recordings were publically available records that did not involve that.

I am interested in who those 10 uses in IETF108 are.
Is that one person for 10 sessions? Or 10 different users?
I can imagine that there are some people for whom a live video stream is too
bandwidth intensive.
Still, meetecho has some options to suppress video receiving I thought..

    > meeting at   a time.

My record is three meetecho windows, and a lot of use the mute button my
audio mixer :-)

    > to run   meetecho.

    > meetings.      This population isn't using the mp3 streams to address
    > the posited     limitations.  If this is a     concern that some people
    > think they will     experience then we can look at asking Meetecho to
    > allow sending only     audio (muting all video).

I thought that we already had this.

    > * This removes a mechanism that allowed people to listen to a session
    > in   real-time without paying a registration fee.

I think that this will be the biggest hurdle.
Given how the waivers have been repositioned, perhaps this is much less of a hurdle.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 2 Oct 2020 08:42:04 +1300

>     structure. In the meantime, the fee waiver program is available and 

I don't think that's a tools-discuss decision alone. It's been a significant
point of principle discussed (e.g.) in SHMOO, hence the extra CC.

It seems to me that the principle of the fee waiver and when it's
ethical to use it is still not clear, and we don't know whether it is
financially viable in the medium to long term. Until that's settled,
I'm a bit uneasy about dropping the mp3 streams, precisely because they
do not need pre-registration.

(If meetecho had a "read only" or observer mode without pre-registration,
this problem would go away instantly.)

Regards
   Brian

Regards
   Brian Carpenter

On 02-Oct-20 03:31, Robert Sparks wrote:
> meetings,
> starting with IETF 109 and we want to hear from the community before we do.
> 
> At many past meetings we have produced live mp3 streams for each 
> session. These
> steams have been associated with physical meeting rooms, and appeared before
> and during the session as a link on the agenda page to a URL like
> 'http://mp3.conf.meetecho.com/ietf/ietf<some_number_associated_with_the_room>.m3u'. 
> 
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 1 Oct 2020 15:01:11 -0500

> made available via some other site as well.

I'd make the same request. A little bit ago, I went to try to find the 
audio stream for a recent meeting, and was perplexed that the recordings 
no longer existed. I'm sympathetic to the concerns that Michael 
expressed; I also note that, even if you're willing to deal with big 
tech platforms, the inability to download a local copy of material from 
YouTube is a very unfortunate drawback.

As an aside: prior to the youtubization of sessions, it was possible to 
grab the individual media components from the meetecho recordings, which 
was *even nicer*. For example, the HRPCRG had a very interesting spot in 
their session where EFF's Eva Galperin gave a slide-free talk that I 
shared with some colleagues. In the old format, I could have pointed to 
the speaker video stream, which would have been nice. On YouTube, the 
lack of slides meant that the speaker view was rendered as 1/16th of the 
frame in the upper-right-hand corner, while the remaining 15/16ths of 
the screen was blank. I'm not necessarily asking for that format to be 
restored, but it would make for a replacement of the MP3 streams that 
isn't merely adequate, but actually quite superior.

/a

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Oct 2020 22:31:09 +0200

> made available via some other site as well.

Syncing the channel to LBRY could be an easy, low-effort first start.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Oct 2020 16:36:21 -0400

Adam Roach <[email-masked]> wrote:
    >> I understand.  I would request that the mp4's that are produced and
    >> uploaded to youtube be made available via some other site as well.

    > audio stream for a recent meeting, and was perplexed that the
    > recordings no longer existed. I'm sympathetic to the concerns that
    > Michael expressed; I also note that, even if you're willing to deal
    > with big tech platforms, the inability to download a local copy of
    > material from YouTube is a very unfortunate drawback.

Well, there tools that will do this, but youtube tries to break them, I
think. :-)

    > grab the individual media components from the meetecho recordings,
    > which was *even nicer*. For example, the HRPCRG had a very interesting
    > spot in their session where EFF's Eva Galperin gave a slide-free talk
    > that I shared with some colleagues. In the old format, I could have
    > pointed to the speaker video stream, which would have been nice. On
    > YouTube, the lack of slides meant that the speaker view was rendered as
    > 1/16th of the frame in the upper-right-hand corner, while the remaining
    > 15/16ths of the screen was blank. I'm not necessarily asking for that
    > format to be restored, but it would make for a replacement of the MP3
    > streams that isn't merely adequate, but actually quite superior.

I agree it would be nice to have the media components.
It might also allow for interesting remixes later on.

Also the meetecho recording does not include the jabber/chat view, the
participant queue (to see who is speaking), or the vote/hum results.
So even though you have jabber logs, it's difficult to easily see exactly
what it relates to.

The best part about watching the recordings though, is 2x playback speed :-)

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 1 Oct 2020 17:41:34 -0400

> On Oct 1, 2020, at 4:36 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:

I have argued in the past that all of the media from IETF should be available in non-proprietary formats as stream components for tools and user interface people to combine them and use the components in more user friendly ways than simply archiving everything in Youtube.

I was told no to this. I think this is a mistake.

The IETFers app used to be a significant user of the audio streams. I provided live streaming as well as recorded playback of a session. This was difficult because the stream info for a sessions was not algorithmic. I had to release a new version of the app each meeting to map stream numbers to rooms. I received tons of compliments on this and people loved this feature.

When this was the only reason left to release a new version of the app for each meeting, I dropped the recordings but I always wanted to come up with a way to re-instate this functionality because the low bandwidth audio stream was so much more useful on a mobile device than the youtube. It was possible to stream a session over cellular in your car while the youtube would take significant bandwidth.

Not only do I not want this to go away, I want all of the material to be available in open formats. This includes:

1. audio (presenter in one channel, audience mics in another channel would be even better)
2. slide video
3. speaker video
4. slide files

It makes perfect sense that the number of people using this recently is low. It’s difficult to use in its current form. It shouldn’t be this way.

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 1 Oct 2020 18:02:12 -0400

> On Oct 1, 2020, at 5:41 PM, Tom Pusateri <pusateri=[email-masked]> wrote:
> 
> 

Actually, even better would be an audio channel per microphone. I’ve been doing machine learning on these audio files and when people speak over each other, it’s hard to do silence detection and word recognition correctly. Having a channel per mic would be so helpful.

Tom

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 Oct 2020 21:03:37 -0400

Out of a desire to stay out of this discussion, I sent a private
note to Robert earlier today that I will not try to reprise
here.  However...

--On Friday, October 2, 2020 08:42 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> * This removes a mechanism that allowed people to listen to a
>> session in real-time without paying a registration fee.
>> 
>>     There will be ongoing discussion and tuning of the
>>     meeting registration structure. In the meantime, the fee
>>     waiver program is available and  being
>>     improved.
> 
> I don't think that's a tools-discuss decision alone. It's been
> a significant point of principle discussed (e.g.) in SHMOO,
> hence the extra CC.

Right.  And I think there are some very broad principles about
who we are willing to disenfranchise, whether we are willing to
insist that people give up privacy to observe our meetings;
whether real-time observation is actually needed or whether
people who just want to observe can watch or listen later;
whether policies that require either registration fees that are
not tied to ability to pay or asking for fee waivers are
inherently discriminatory against, e.g., people from developing
areas; how many people have to be pushed out before it is an
issue (note the tie to Robert's "not many people are using the
mp3 feed); etc.  

To me, there is also a small elephant lurking around the corners
of the room having to do with just how serious we are about key
discussions and decisions occurring on the mailing lists.  My
recollection about what I heard when the IETF got started --long
before real-time remote participation was feasible for most
people -- was that there was not a lot of concern about these
issues, not because people were backward, but because it was
very clear that meetings were about discussion and getting a
shared understanding of the issues and how to explain them, not
about "deciding" or even "agreeing".   I suspect that a really
pure form of that approach may be somewhat mythological, but the
difference between even a watered-down version and the "decide
in meeting, ask on mailing list if there are any significant
objections" pattern we've seen frequently in recent years is
still significant.

However, I think my main point is similar to Brian's (if I
correctly understand him): it is time we have discussions about
principles and make decisions about them and then answer
questions (probably easily) about what services we need to offer
and how they should be arranged and/or delivered in terms of
those principles.   Making a decision about something like an
mp3 feed (and a variety of other things) in isolation is
unlikely to lead us to good places. 

> It seems to me that the principle of the fee waiver and when
> it's ethical to use it is still not clear, and we don't know
> whether it is financially viable in the medium to long term.
> Until that's settled, I'm a bit uneasy about dropping the mp3
> streams, precisely because they do not need pre-registration.

> (If meetecho had a "read only" or observer mode without
> pre-registration, this problem would go away instantly.)

Which, of course, Meetecho, in its IETF form, had in the
original distinction between joining as an observer and as a
participant until "we" decided to shut it off in the run-up to
IETF 108 (or IETF 107 if not using Meetecho at all for that
meeting counts).  The problem is not what mode(s) are available
but where we draw the dividing line about who gets a free ride.
Personally I have a lot of difficulty justifying free mp3 live
streaming but requiring that "read only" / observer Meetecho
users pay, but YMMD.

And I see parts of those things as both important but larger
parts as just another symptom.  We need to look at whether to
make a distinction between observers and participants and
whether the latter (at least) are pay to play... always, or only
when a meeting is all-remote.  We need to figure out if there is
any real justification for requiring that observers be able to
observe in real time and, if not, how much delay in getting
video (and audio?) posted is tolerable.  And so on.  I think
that, if we have answers to those sorts of questions of
principle, most of the questions about live audio feeds and even
fee waivers will largely fall out.

best,
   john

---

From: Michael Richardson <[email-masked]>
Date: Sat, 03 Oct 2020 21:13:44 -0400

Tom Pusateri <[email-masked]> wrote:
    > When this was the only reason left to release a new version of the app
    > for each meeting, I dropped the recordings but I always wanted to come
    > up with a way to re-instate this functionality because the low
    > bandwidth audio stream was so much more useful on a mobile device than
    > the youtube. It was possible to stream a session over cellular in your
    > car while the youtube would take significant bandwidth.

I would have liked that option back in 2018.

    > Not only do I not want this to go away, I want all of the material to
    > be available in open formats. This includes:

    > 1. audio (presenter in one channel, audience mics in another channel
    > would be even better) 2. slide video 3. speaker video 4. slide files

    > It makes perfect sense that the number of people using this recently is
    > low. It’s difficult to use in its current form. It shouldn’t be this
    > way.

Maybe Robert could detail what the challenge was in the retooling.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 3 Oct 2020 20:11:16 -0700

> objections" pattern we've seen frequently in recent years is

I think it's extremely difficult to get any deep understanding of a
significant issue at a meeting session. The number of words that can
be exchanged on any topic in a minute or two at the mike is miniscule,
while emails have far more length and can be digested at leisure, and
clarifications requested after digestion.  Buttonholing attendees for
informal conversation is far more important use of the meeting.
Particularly for TLS 1.3 standardization a considerable amount of the
action in late stages was in academic conferences that weren't
officially part of the IETF because of the technicalities.

> unlikely to lead us to good places.

+1

> Manycouches mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manycouches

Sincerely,
Watson

--
Astra mortemque praestare gradatim

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 4 Oct 2020 04:26:52 +0100

> officially part of the IETF because of the technicalities.

Not quite that: those workshops were encouraged as an
addition to the IETF process. And were well worthwhile
for TLS1.3 though probably would be OTT for other RFCs.

S.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 5 Oct 2020 08:34:46 +0200

Le 01/10/2020 à 21:42, Brian E Carpenter a écrit :
>> There will be ongoing discussion and tuning of the meeting
>> registration structure. In the meantime, the fee waiver program is
>> available and being improved.
> 
> I don't think that's a tools-discuss decision alone. It's been a
> significant point of principle discussed (e.g.) in SHMOO, hence the
> extra CC.
> 
> ethical to use it is still not clear, and we don't know whether it
> is financially viable in the medium to long term. Until that's
> settled, I'm a bit uneasy about dropping the mp3 streams, precisely
> because they do not need pre-registration.
> 

It would be advantageous to continue the streaming of audio, for a
registration-less observer read-only kind of participation.

Maybe a thing to improve is the format of the data.  A better performing
format than mp3, why not an IETF recent technology (ogg?), with a better
support from free software tools that are widely available, could be good.

Alex

> Regards Brian
> Regards Brian Carpenter
>> We propose to discontinue producing live mp3 audio streams for
>> IETF meetings, starting with IETF 109 and we want to hear from the
>> community before we do.
>> 
>> session. These steams have been associated with physical meeting
>> rooms, and appeared before and during the session as a link on the
>> agenda page to a URL like 
>> stream. Recordings of that stream have not been made available
>> after the meeting. The full video recording provided by Meetecho
>> has served as the way to listen to (or watch) any given session
>> after the fact.
>> 
>> Further, for the last several meetings, the live streams have seen
>> very light use, on the order of 10 uses for IETF 108.
>> 
>> Now that we are holding more meetings online, we have a requirement
>> to allow meetings to run outside their scheduled times. Allowing
>> the live streams to run outside their scheduled times will require
>> changing how they are represented, to no longer be associated with
>> "rooms" or "tracks". The code refactor at both the datatracker and
>> at meetecho to support would not be a huge effort, but it also
>> would not be tiny. Instead, we feel that removing this complexity, 
>> recognizing that the regular meetecho connection and recordings
>> satisfy the need, is the better use of our resources. That holds
>> true even for future in-person meetings.
>> 
>> There are several points that have been considered while arriving
>> at this proposal:
>> 
>> For the last several meetings, the chairs have been using the
>> Meetecho recordings for this purpose. Recordings of the live mp3
>> streams haven't been available.
>> 
>> * Some participants (especially ADs) want to listen to more than
>> one meeting at a time.
>> 
>> * Some participants may not have the bandwidth or a new enough
>> computer to run meetecho.
>> 
>> There will be ongoing discussion and tuning of the meeting
>> registration structure. In the meantime, the fee waiver program is
>> available and being improved.
>> 
>> Please send comments by 16 Oct 2020 either to
>> [email-masked] or directly to [email-masked].
>> 
>> _______________________________________________ IETF-Announce
>> mailing list [email-masked] 
> _______________________________________________ Manycouches mailing
> list [email-masked]

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 5 Oct 2020 11:57:27 -0400

> On Oct 5, 2020, at 2:35 AM, Alexandre Petrescu <[email-masked]> wrote:

Do you maybe mean Opus (RFC 6716)?

I like it when the IETF uses open technologies like this and it seems most operating systems support it now.

Opus also supports multi-channel audio which would be great for multiple microphones.

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.

Thanks,
Tom

---

From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Mon, 5 Oct 2020 16:19:16 +0000

We shouldn't focus too hard on the implementation of the audio feeds, it's a technical problem that can be solved.
The hard part is how this is exposed to users, and what tools are available along with the necessary configuration (hopefully small or nonexistent).
Ideally clicking on a link in the meeting webpages should enable listening to the audio feed with no prerequisite at all, regardless of your device's platform. If this is not possible there should be an easy walkthrough of what needs to be done depending on the platform.
Adding Opus to the conversation could be nice, but may contradict the "ideal" scenario above (e.g. do ALL browsers support Opus ?).
Best regards,
Julien.

-----Original Message-----
From: Manycouches <[email-masked]> On Behalf Of Tom Pusateri
Sent: Monday, October 5, 2020 5:57 PM
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Manycouches] [Tools-discuss] Proposal to discontinue live mp3 audio streams at IETF meetings

> Maybe a thing to improve is the format of the data.  A better 
> performing format than mp3, why not an IETF recent technology (ogg?), 
> with a better support from free software tools that are widely available, could be good.
> 
> Alex

Thanks,
Tom

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Oct 2020 18:28:04 +0200

> 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

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 5 Oct 2020 12:39:35 -0400

> On Oct 5, 2020, at 12:28 PM, Carsten Bormann <[email-masked]> wrote:
> 

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.

Tom

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Oct 2020 18:45:19 +0200

> So the limited number of streams is based on physical audio hardware.

I understand the history; I just don’t understand how that still limits us.

Grüße, Carsten

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Oct 2020 12:05:53 +0200

Le 05/10/2020 à 18:19, Maisonneuve, Julien (Nokia - FR/Paris-Saclay) a 
> Adding Opus to the conversation could be nice, but may contradict the "ideal" scenario above (e.g. do ALL browsers support Opus ?).

The question of browser support, and its details, is relevant.  For 
example, meetecho is best supported by Chrome and less by Firefox (lacks 
device switching).  That might prevent some people from using meetecho 
instead of installing Chrome.  Which translates directly into preventing 
them from participating to IETF.

For opus - firefox does support opus, it seems.

Mp3 might be a format that, despite its longevity, might not be 
supported by some browsers because of the licensing scheme.

Other than browsers, there also the players: there are many players of 
live streams out there, which are not web browsers.  Many of these 
players dont support mp3.

Alex

---

From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 6 Oct 2020 10:21:59 +0000

Alex,
MP3 patents have not been an issue for a while : https://www.theregister.com/2017/05/16/mp3_dies_nobody_noticed/
Julien.

-----Original Message-----
From: Alexandre Petrescu <[email-masked]> 
Sent: Tuesday, October 6, 2020 12:06 PM
To: Maisonneuve, Julien (Nokia - FR/Paris-Saclay) <[email-masked]>; Tom Pusateri <pusateri=[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Manycouches] [Tools-discuss] Proposal to discontinue live mp3 audio streams at IETF meetings

> Adding Opus to the conversation could be nice, but may contradict the "ideal" scenario above (e.g. do ALL browsers support Opus ?).

The question of browser support, and its details, is relevant.  For example, meetecho is best supported by Chrome and less by Firefox (lacks device switching).  That might prevent some people from using meetecho instead of installing Chrome.  Which translates directly into preventing them from participating to IETF.

Mp3 might be a format that, despite its longevity, might not be supported by some browsers because of the licensing scheme.

Other than browsers, there also the players: there are many players of live streams out there, which are not web browsers.  Many of these players dont support mp3.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Oct 2020 13:21:06 +0200

Julien,
Thanks for the info!
I did not know that MP3 patents expired.  It's been so many years indeed.

Now I saw that lame mp3 is part of Audacity, while earlier one had to 
install it separately, almost crossing a red light.  I dont know whether 
lame mp3 is part of audacity because patents expired or because audacity 
takes more responsibility on their shoulders.

Now I notice some explanations at Fraunhofer saying that "mp3 can be 
made available as an optional part of the xHE-AAC software package." or 
that "However, the end of the mp3 licensing program does not 
automatically mean that all mp3 technology is available license-free 
now. Apart from the core mp3 patents included in the licensing program, 
there might still be some implementation–specific patents (or patents 
for other functional enhancements) that have not expired. Thus, 
manufacturers will have to check the situation regarding their intended 
products first before including mp3."

My intuition ("le pif" :-), as opposed to documented rational 
understanding, tells me that the same kind licensing of mp3 would 
continue.  They cant change the smell of it after so many years simply 
with some expiration.  Mp3 smells it.  There would be a need of a new 
concept with a new name like 'free-mp3'.

On another hand, an IETF technology is likely to benefit from a RAND 
licensing scheme, which is more advantageous.

Alex

Le 06/10/2020 à 12:21, Maisonneuve, Julien (Nokia - FR/Paris-Saclay) a

---

From: Robert Sparks <[email-masked]>
Date: Tue, 6 Oct 2020 14:49:57 -0500

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
>
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
>
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Oct 2020 11:20:03 +0200

Le 06/10/2020 à 21:49, Robert Sparks a écrit :
>>> On 2020-10-05, at 17:57, Tom Pusateri 
>>> <pusateri=[email-masked]> 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.
>> 
> 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.
> 
> 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
around.

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).

Alex

> 
> 
>> 
>> Tom ___________________________________________________________ 
>> Tools-discuss mailing list [email-masked] 
>> Please report datatracker.ietf.org and mailarchive.ietf.org bugs at
>> http://tools.ietf.org/tools/ietfdb or send email to
>> [email-masked]
>> 
>> http://tools.ietf.org/tools/issues or send email to
>> [email-masked]
>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 7 Oct 2020 11:52:23 -0400

> On Oct 7, 2020, at 5:20 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 

The physical audio hardware is more of a limitation of the space. You have rooms with separate sound systems with microphones and speakers for a physical audience. Each stream needs to be tied into the existing room sound system.

You could use a computer in each room to pipe that sound over the network to a central stream server but now we’re just talking about where it’s being served from. My previous description was meant to describe that computer in that room connected to that sound system.

Tom

---

From: Robert Sparks <[email-masked]>
Date: Wed, 7 Oct 2020 10:58:22 -0500

On 10/7/20 10:52 AM, Tom Pusateri wrote:
>
>> On Oct 7, 2020, at 5:20 AM, Alexandre Petrescu 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote:
>>
>>
> The physical audio hardware is more of a limitation of the space. You 
> have rooms with separate sound systems with microphones and speakers 
> for a physical audience. Each stream needs to be tied into the 
> existing room sound system.
>
> You could use a computer in each room to pipe that sound over the 
> network to a central stream server but now we’re just talking about 
> where it’s being served from. My previous description was meant to 
> describe that computer in that room connected to that sound system.
I don't think we need to worry about it anymore other than understanding 
how it informed the model that we've used to date. When we have a 
physical system in the future that's room based, we'll plumb things back 
to sessions.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Oct 2020 10:23:50 -0500

(With apologies for the intentional crosspost)

If you have more to say, please do so by 16 Oct.

My read of the feedback so far is that the evidence we had for low usage 
was probably misleading, and there is still a demand for a live audio 
stream if it were presented in a more useful form. I anticipate we will 
do the retooling to provide these as one named stream per session going 
forward. If anyone thinks that is not what we should be doing, please 
say so.

RjS

> For the last several meetings, these have only been available as a 
> live stream.
> very light
> meetings to run outside their scheduled times. Allowing the live 
> streams to run
> satisfy the
> Meetecho
> computer to run
> registration

---

From: Robert Sparks <[email-masked]>
Date: Tue, 20 Oct 2020 14:07:43 -0500

I have not seen any further responses.

We will do the retooling needed to provide live audio streams as one 
named stream per session.

RjS

On 10/14/20 10:23 AM, Robert Sparks wrote:
> My read of the feedback so far is that the evidence we had for low 
> usage was probably misleading, and there is still a demand for a live 
> audio stream if it were presented in a more useful form. I anticipate 
> we will do the retooling to provide these as one named stream per 
> session going forward. If anyone thinks that is not what we should be 
> doing, please say so.
>
> RjS
>
>
>> to allow
>> to no longer be associated with "rooms" or "tracks". The code 
>> refactor at both
>> the datatracker and at meetecho to support would not be a huge 
>> effort, but it
>>     limitations.  If this is a     concern that some people think 
>> they will
>>    structure. In the meantime, the fee waiver program is available 
>> and being
>>    improved.
>>