Subject: Fwd: Re: IETF 82 Audio Streaming

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 01 Nov 2011 11:37:14 +0100

...forgot to include the list in my response. Sorry about that.

Simon

Simon Pietro Romano <[email-masked]> ha scritto:

Hi Randy,

you can skip such a fat frelling chance, if you want; just choose to either attach to the RTSP stream, or to the landline phone bridge.

Cheers,

Simon

Randy Bush <[email-masked]> ha scritto:

> For general remote participation including meetecho support see:

meetecho seems to require me to let a java applet have its way with my
machine. fat frelling chance. does the ietf really want to recommend
such a practice?

randy
_____________________________________________

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

---

From: "Meetecho IETF support" <[email-masked]>
Date: Tue, 1 Nov 2011 12:36:30 +0100

> you can skip such a fat frelling chance, if you want; just choose to either attach to the RTSP stream, or to the landline phone bridge.

... or you can call the SIP URI associated with the Meetecho room!

Cheers,
the Meetecho team

---

From: Randy Bush <[email-masked]>
Date: Tue, 01 Nov 2011 13:12:08 +0100

> you can skip such a fat frelling chance, if you want; just choose to
> either attach to the RTSP stream, or to the landline phone bridge.
>> meetecho seems to require me to let a java applet have its way with
>> my machine. fat frelling chance. does the ietf really want to
>> recommend such a practice?

that is not my point.  i can easily avoid it myself.  my issue is that
we as the ietf seem to be promoting and encouraging a very bad and
anti-secure practice.  would we tell people to use telnet?  http
non-crypto to the bank? ...

randy

---

From: "Meetecho IETF support" <[email-masked]>
Date: Tue, 1 Nov 2011 14:10:11 +0100

Da: [email-masked]
A: "Simon Pietro Romano" [email-masked]
Cc: [email-masked]
Data: Tue, 01 Nov 2011 13:12:08 +0100
Oggetto: Re: Fwd: Re: IETF 82 Audio Streaming

> non-crypto to the bank? ...

Randy,

and our point was that luckily you're not forced to take that dangerous
and creepy road, since there are several (standard) alternatives you
ca exploit for the purpose. As a matter of fact, the server natively
makes use of those standard protocols, and the web interface we make
available for your convenience is just a frontend to it.

The best way to access the audio stream are of course the RTSP and SIP
URIs, which are both listed when you join one of the rooms we handle.
And, unless I'm mistaken, last time we checked they are both standard
protocols that come from the IETF itself. If (and only if) you don't
want to/can't be bothered to install a native client for those standard
protocols, or just want everything to happen in your browser, we
made available an applet whose only purpose is to take care of what
the browser cannot take care as of yet, that is media encoding and RTP
communication. Unfortunately, there still is no standard for web-based
communication: RTCWEB is on its way (and we all hope it will be out and
kicking ASAP) but is still not there to be used, and we had to make a
choice.

With that in mind, how is a Java applet any different than a Flash based
object that does the same thing or, even worse, than some full-fledged
active-x or application that a website download and opens in order to
make you think it's just another page in your browser? (yeah, someone
does that too). We chose to keep things "lite": a simple HTTP/Javascript
interface to everything we could wrap, and, for those who want everything
in the browser because that's what the web is, an applet for media/RTP,
that we couldn't wrap as of yet. Apparently we're not "lite" enough yet.

Regards,
Lorenzo

> randy
> _______________________________________________
> Ietf mailing list
> [email-masked]

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 01 Nov 2011 17:30:26 +0100

Hi Scott,

all the accounts we use for IETF Meetecho sessions are created on the fly and destroyed immediately after each such session. The URIs for IETF rooms are also dynamically created right before the session starts, and get announced on the official IETF jabber room as soon as people start to log in. They simply disappear when the session is over. The only 'spying' feature we have is session recording, with all recordings which are made available to the community after the meeting. I hope this helps clarify your concern, unless I misinterpreted it.

Regards,

Simon

"Scott O. Bradner" <[email-masked]> ha scritto:

how about - when the URLs get added to http://www.ietf.org/meeting/82/remote-participation.html#audio

they are URLs that bypass the spy features of meetecho?

Scott

On Nov 1, 2011, at 6:37 AM, Simon Pietro Romano wrote:

Simon

Hi Randy,

Cheers,

Simon

randy

Ietf mailing list
[email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Tue, 01 Nov 2011 10:31:18 -0800

On 11/01/2011 05:10 AM, Meetecho IETF support wrote:
> make you think it's just another page in your browser?

The IETF isn't supporting remote participation using technology
that depends on Flash, or Active X, or browser-based access, for
starters, so your question is largely irrelevant.

Melinda

---

From: Joel jaeggli <[email-masked]>
Date: Tue, 01 Nov 2011 11:59:09 -0700

> starters, so your question is largely irrelevant.

webex and the meetecho experiment (I realize that's being recursive) and
if you're being pedantic the http audio stream.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 01 Nov 2011 11:07:30 -0800

> if you're being pedantic the http audio stream.

I don't think that the http audio stream qualifies, since we're
able to use the audio client of our own choosing.  I haven't used
either webex or meetecho because webex turns on your video camera
and doesn't have an option to turn it off (I understand that this
is fixed in the most recent release) and meetecho because I don't
know who those guys are and I'm not really interested in downloading
and running software from an unknown source, particularly when
there are more open options available.  You'll note that we don't
require people to use a particular client to use the Jabber rooms,
either.  While meetecho may or may not be using standard protocols
(they say they are), they require their own client.  That's kind
of weird for a body whose reason for existing revolves largely
around interoperability.

Melinda

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 1 Nov 2011 20:30:21 +0100

On Tue, 01 Nov 2011 11:07:30 -0800

> of weird for a body whose reason for existing revolves largely

I don't think Firefox or Chrome can be defined as "our own client".

If instead you're talking about the applet, as I've explained in the previous mail, it is not started by default and so you don't even need to know it exists if you have your own SIP or RTSP client to access the audio stream.

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 1 Nov 2011 08:29:15 -0400

Scott

---

From: Joel jaeggli <[email-masked]>
Date: Tue, 01 Nov 2011 13:31:52 -0700

> of weird for a body whose reason for existing revolves largely

I've probably been involved in or responsible for more dumb remote
participation experiments at the ietf than anyone else still regularly
attending. I'm willing to grant for the sake of experimentation a fair
amount of forbearance for things I don't like and or would never use
myself. I haven't come to any such conclusion regarding meetecho.

I think there's room under to tent to provide a more comprehensive tool
than the very basic one I concluded a couple years ago had the widest
availability, and the least production overhead.

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 01 Nov 2011 22:28:03 +0100

So I should just point you to the other responses we provided to Randy.

Regards,

Simon

you did - I was referring to Randy's issue (having the download wanting total access to the 

user's machine)

Scott

On Nov 1, 2011, at 12:30 PM, Simon Pietro Romano wrote:

Hi Scott,

Regards,

Simon

Scott

Simon

Hi Randy,

Cheers,

Simon

randy

Ietf mailing list
[email-masked]

---

From: "Meetecho IETF support" <[email-masked]>
Date: Wed, 2 Nov 2011 01:28:10 +0100

Melinda,

Meetecho does make use of standard protocols, as witnessed by the possibility of accessing each of the functionality we provide by means of any client implementing such standards (i.e., XMPP for accessing IETF jabber rooms, SIP/RTP or RTSP for audio/video and HTTP for the slides).

The Meetecho WebLite interface is just an alternative we provide IETFers with, should they want to have all the aforementioned functionality wrapped in a single web page. We do not *require* our own client to be used at all.

Cheers,
Alessandro
 
www.meetecho.com
 
Da: [email-masked]
A: "Joel jaeggli" [email-masked]
Cc: [email-masked]
Data: Tue, 01 Nov 2011 11:07:30 -0800
Oggetto: Re: Fwd: Re: IETF 82 Audio Streaming

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Nov 2011 05:15:38 +0100

> If instead you're talking about the applet, as I've explained in the
> previous mail, it is not started by default and so you don't even need
> to know it exists if you have your own SIP or RTSP client to access
> the audio stream.

my question is whether it can be disabled for the ietf streaming, not on
the client, but on the servers, archive, ...

we should not run a service which suggests, allows, requires, ... an
applet.  and yes, i have the same problem with webex.

randy

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 02 Nov 2011 08:48:10 +0100

I don't see any need to disable a feature that is optional. If you want it, you get it; if you don't, you'll just live without it. This is something people call 'freedom of choice', and I personally appreciate it.

Regards,

Simon

randy

Ietf mailing list
[email-masked]

---

From: Dave Cridland <[email-masked]>
Date: Wed, 02 Nov 2011 10:31:14 +0000

> applet.  and yes, i have the same problem with webex.

We already have this problem with many things, though.

- Our mailing lists require you to operate an SMTP server. I remember  
Randy Gellens talking about having to install one in order to  
participate, back in the day. (I think he wrote it himself, actually).
- Our XMPP chatrooms require you to have a MUC-capable XMPP client.
- I've heard filthy rumours that we have some kind of website,  
requiring one of those new-fangled browsers.
- Our very RFCs require an ASR-33 emulator.

Many of these things are commonly installed with an operating system,  
these days, or easily obtained - but not always. Windows users are  
still in a XMPP-less ghetto. The only difference with Meetecho is  
that they provide a downloadable, cross-platform, client for those  
without one.

I have to say I don't see the problem here at all. I could  
understand, and would entirely support, your position if we were  
talking in terms of a mandatory, non-standard, closed-source, client,  
but as I understand things, the Meetecho client is none of those  
things. It's optional, open-standard, and open-source.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Nov 2011 02:15:55 +0100 (MET)

Simon Pietro Romano wrote:
> 
> all the accounts we use for IETF Meetecho sessions are created
> on the fly and destroyed immediately after each such session.
> The URIs for IETF rooms are also dynamically created right before
> the session starts, and get announced on the official IETF jabber
> room as soon as people start to log in. They simply disappear when
> the session is over.

It would be preferable when the URIs were made to be known sufficiently
in advance that they *can* be listed/made part of the offical tools-style
IETF meeting agenda and the audio stream information page!

In the last IETF (Quebec), there was the prerequisite to either run the
Java plugin or run an XMPP client and join the correct plenary chat
*AND* sufficiently early as a prerequisite to find out that there exist URLs
that provide an audiostream for use without XMPP client and without
a Java applet.  That is a hen-and-egg problem that could be
avoided by some planning ahead.

I also found it quite disappointing that the "official" 7 audiostreams
continued to stream in HiFi background noise and after-session talks of folks
still standing near the microphone, while the plenary audio was only
transmitted through meetecho with only phone-quality.

-Martin

---

From: Joel jaeggli <[email-masked]>
Date: Wed, 02 Nov 2011 20:58:46 -0700

> avoided by some planning ahead.

The lack of a traditional http audio stream for the plenary was (as
noted at time) an omission on the part of the contractor programing the
streaming boxes, it wasn't intentional and it will not be repeated.