Subject: IETF 82 Audio Streaming

From: Richard Golodner <[email-masked]>
Date: Wed, 02 Nov 2011 00:05:01 -0500

I think that the IETF being the large body that it is should go out of
it's way to promote good networking/computer practices. 
	I know Joel works hard for good communications at the meetings as I
have read in his emails, but.....
	I do not want to be told I must install this or use that
to get my work done. Only the shadow knows what holes may be opened up
by the meetecho applet. Besides Java is for those long nights at
customer sites and when waking in the a.m.
	Sincerely, Richard Golodner

---

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

Nobody is gonna tell you to install any sw on your machine. If you happen to use Meetecho at an IETF meeting, just let the 'dangerous monster applet code' (whose sources are, btw, publicly available) stay at our server. It is as simple as avoiding to push a button on a web page...something that any IETFfer is supposed to be able to do.

Regards,

Simon

Richard Golodner <[email-masked]> ha scritto:

_____________________________________________

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

---

From: "Meetecho IETF support" <[email-masked]>
Date: Wed, 2 Nov 2011 09:53:12 +0100

Again, my point is that we are not saying you *must* install or use anything. We're talking about providing an alternative a user *might* want to use. I don't see any particular reason to forbid it.

As to the holes that may be opened up, please consider that the source code of the applet is publicly available. Anybody can just trust us, or go inspecting it (it is a very small piece of software which basically takes care of media encoding/decoding and RTP transmission).

Regards,
Alessandro
 
--
Meetecho s.r.l.
Web Conferencing and Collaboration Tools
www.meetecho.com
 
Da: [email-masked]
A: [email-masked]
Cc: 
Data: Wed, 02 Nov 2011 00:05:01 -0500
Oggetto: IETF 82 Audio Streaming

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Nov 2011 14:40:03 +0000

I think this whole thread is based on a misunderstanding.

The IETF provides a Jabber/XMPP server with chat rooms for each session.  You can use your own Jabber/XMPP client to access it, through an XMPP provider of your choosing such as jabber.org.  Now imagine jabber.org decided to *also* provide a web-based interface for chat, so you could use your browser instead of an XMPP client, if you the user wanted to.  Imagine if to do that, jabber.org had to use a java applet because the browser couldn't natively do what needed to be done with Javascript/HTML. 

That's basically what's going on here.  Meetecho supports multimedia access to IETF sessions using your own SIP/RTSP client.  But they also want to let users use their browser for the session, if the user doesn't have a SIP/RTSP client.  Since browsers don't support WebRTC yet (because WebRTC is still being standardized), nor do many browsers even support HTML-5 yet, Meetecho has to use an applet/plugin model.

Meanwhile, I haven't heard anyone raise complaints about WebEx, which is not only a proprietary solution, but also requires installing a plugin.  Is that ok because it's Cisco?  Meetecho, in case you didn't know, is also run by folks who are active IETF participants in the RAI Area, and are authors of several Working Group and individual drafts.  

They spend their own money providing this service to the community, and unlike Cisco the cost is not a rounding error on their coffee budget. (not that I don't appreciate Cisco providing WebEx - I do)

The more ways people can access IETF meetings the better!

-hadriel

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 2 Nov 2011 16:20:40 +0100

On 2 November 2011 15:40, Hadriel Kaplan wrote:

> I haven't heard anyone raise complaints about
> WebEx, which is not only a proprietary solution,
> but also requires installing a plugin.

Thanks for info, I had no clue what this might be.

The other thingy at least offered some info.  I'd
also like a recommendation for a jabber client on
Windows 7 with the chatroom feature (= not Gtalk),
but not PSI, I have that on a W2K box.

-Frank

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 02 Nov 2011 08:29:43 -0700

> but not PSI, I have that on a W2K box.

Pandion might be a good bet.

/psa

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Nov 2011 16:35:02 +0100

i run a mac with firefox and the usual.  when i went to access a stream,
i was asked to allow an applet to own my machine.  i.e. a default/simple
user path led the user to very unsafe behavior.  i do not give a damn
what all the options might be.  normal use paths should not encourage
insecure behavior.

> Meanwhile, I haven't heard anyone raise complaints about WebEx

then you ignored my earlier mail.

i am sure everybody means well here.  the issue is not that, whether
they are a social service, a vendor, or an evil router maker.  the issue
is simply whether the ietf should present users with opportunities for
the very kinds of practices into which we claim to put much effort to
avoid.

randy

---

From: Melinda Shore <[email-masked]>
Date: Wed, 02 Nov 2011 07:45:35 -0800

> I think this whole thread is based on a misunderstanding.

Well, maybe.  The thing is that I haven't seen any other vendors
using the IETF to market their wares in quite the same way.  I
think you could probably argue that Webex provides features that
aren't otherwise available but frankly I don't use Webex at all
unless it's absolutely the only way I can participate in a
meeting I can't miss.

Out of curiosity, if it's just another client, why is it being
promoted the way it is?

Melinda

---

From: Dave Cridland <[email-masked]>
Date: Wed, 02 Nov 2011 15:50:35 +0000

> but not PSI, I have that on a W2K box.

Swift, Pandion, and Psi are all solid as far as I've experienced, on  
Windows 7.

The XSF maintains a list at http://xmpp.org/xmpp-software/clients/  
that people may find useful.

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: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Nov 2011 16:19:52 +0000

> then you ignored my earlier mail.

Actually didn't mean to - my mail app sorts emails into threads (Mac Lion mail.app), and for some reason this one is a separate thread from the one you sent that comment in, so I didn't see your other email until after I sent this one. 

> the very kinds of practices into which we claim to put much effort to

I think it's kind of a gray area to say "the IETF presents the user with it".  Obviously the email and IETF website give the Meetecho and WebEx links, so in that sense the IETF does.  But the IETF site also has a link to a list of XMPP clients on xmpp.org, yet we don't control that list nor know what the code in those clients does; nor does the IETF support people connecting directly to the IETF XMPP servers using IETF accounts - you have to use another XMPP provider.  So the analogous model for WebEx/Meetecho would be for the IETF to have a link to a third party page that then provided a link to WebEx/Meetecho, which just seems kinda silly.  Or another analogous model would be for the IETF to provide the SIP/RTSP server and content/source-feed, which we haven't.

The good news is the IETF RTCWEB WG and W3C WBERTC WG are working feverishly to get WebRTC defined so that Meetecho (or the IETF) can do it without needing to use plugins/apps.

When that happens I think we should consider having the IETF host this stuff natively, like it does jabber/XMPP.  I.e., eat our own dogfood. 
:)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Nov 2011 16:40:29 +0000

> Out of curiosity, if it's just another client, why is it being

It's not a client.  The Meetecho sessions use our own IETF standards to let remote participants hear the audio, see the presentation slides, and see a live video in the room, all at the same time in real-time.  You can use your own client - or you can view it in a browser using an applet.

The cool thing is that you can even see all this after the meetings in the recorded sessions, including the jabber session, all synchronized with each other.  I found that quite useful to view the recordings of WG sessions I missed due to conflicting WG session times.  (and I will admit I viewed other WG sessions while sitting in a different WG at the same time, due to those conflicts)

The IETF's audio recordings are good too, but having the synchronized audio, slides and room-video was even better.  

An additional benefit is the meetecho recordings split each WG session recording into the separate agenda items/presentations as separate links, so you can go right to the one you want to view; and you don't need a decoder-ring to figure out which stream to play for which WG session.

-hadriel
p.s. I have no affiliation with Meetecho, other than knowing some of them from IETF involvement, and using their IETF meeting recordings.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 02 Nov 2011 09:57:40 -0700

> Swift, Pandion, and Psi are all solid as far as I've experienced, on

Not sure how I could have forgotten Swift, which I use all the time. :)

> The XSF maintains a list at http://xmpp.org/xmpp-software/clients/ that
> people may find useful.

tl;dr

(Although it's challenging to come up with a short but official list of
recommended clients at xmpp.org, for political and other reasons.)

/psa

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Nov 2011 10:06:44 -0700

trillian is a multi-protocol client.

d/

On 11/2/2011 8:50 AM, Dave Cridland wrote:
> Swift, Pandion, and Psi are all solid as far as I've experienced, on Windows 7.
>
> The XSF maintains a list at http://xmpp.org/xmpp-software/clients/ that people
> may find useful.
>
> Dave.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave Cridland <[email-masked]>
Date: Wed, 02 Nov 2011 17:41:58 +0000

> trillian is a multi-protocol client.

I'm hesitent to recommend Trillian, because I understood it used a  
proxy server - ie, it involved my giving my credientials to a third  
party.

It's entirely possible I misunderstood, though - I should probably  
look.

Dave.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Nov 2011 10:53:08 -0700

On 11/2/2011 10:41 AM, Dave Cridland wrote:
> I'm hesitent to recommend Trillian, because I understood it used a proxy server
> - ie, it involved my giving my credientials to a third party.
>
> It's entirely possible I misunderstood, though - I should probably look.

I use it.  It does have its own account, but I believe it does not use that 
account as a data-relaying proxy.

(However it does keep the list of my other accounts and I can understand 
objecting to that.  For me, it's been quite helpful when I have to do 
(re-)installs on different platforms.)

-- 

   Dave Crocker

---

From: Doug Barton <[email-masked]>
Date: Wed, 02 Nov 2011 12:05:48 -0700

> The XSF maintains a list at http://xmpp.org/xmpp-software/clients/ that

If all you want is a basic chat client, pidgin works well. I like it
because I can use the same client/config on my Unix'y desktops, as well
as in windows. For mac there is also adium which has a similar
interface. Another advantage of pidgin/adium is that with the OTR plugin
you can get end-to-end encryption of your conversation over any protocol.

hth,

Doug

-- 

		"We could put the whole Internet into a book."
		"Too practical."

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Doug Barton <[email-masked]>
Date: Wed, 02 Nov 2011 12:10:52 -0700

On 11/02/2011 01:53, Meetecho IETF support wrote:
> Again, my point is that we are not saying you *must* install or use
> anything. We're talking about providing an alternative a user *might*
> want to use. I don't see any particular reason to forbid it.

Is it possible to default the offering of the applet to off?

> As to the holes that may be opened up, please consider that the
> source code of the applet is publicly available. Anybody can just
> trust us, or go inspecting it (it is a very small piece of software
> which basically takes care of media encoding/decoding and RTP
> transmission).

Those of us in the ultra-security-paranoid camp will respond to this by
saying that you've offered the source code for *something*, but that (by
its very nature) we have no way of knowing that the java applet you're
serving is in fact the compiled form of the source you've presented.
Please understand, I am not in any way asserting that Meetecho would
pull this sort of bait and switch, just that there are a lot of us who
don't like running random java applets from sites that we (otherwise)
*do* know/trust. Never mind people that we don't know.

Doug (yet)

--

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 2 Nov 2011 20:40:46 +0100

On Wed, 02 Nov 2011 12:10:52 -0700

> Is it possible to default the offering of the applet to off?

The applet is never not started automatically, it is offered only on a per-request basis, that is, when you join a session, there's a tab (Integrated VoIP) within another Tab (Audio/Video) from where you have to explicitly push a button: this button shows a dialog telling you you're about to run an applet, and asking you if you're sure you want to do that and only then, if you're brave enough to press yes, the applet is started :)

So I'd say it is already as you suggest: nevertheless, to meet your and other people's concern about this, we also decided to make the RTSP tab the default choice, that is, the default alternative the Audio/Video tab presents. I hope this will make it clearer we consider the four options (RTSP, SIP, PSTN, RTP applet) just alternatives among which people can freely choose, and really have no particular interest in any of you downloading and launching the applet.

> *do* know/trust. Never mind people that we don't know.

This makes sense, and I understand your point: as I understand those who prefer not to launch the applet for this or other reasons. Luckily for you all, the RTSP and SIP URIs are there for you to access: I myself used the RTSP stream to attend all the sessions in Quebec City, as I will to attend the sessions in Taipei since I won't be there in person.

What I just want to hightlight again (even though Hadriel already wrote an excellent post to explain this) is that the applet is only there because there was no other way, for us (until RTCWEB becomes a reality), to make a real-time audio/video communication available for people who just want to use their browser and don't want to install ad-hoc clients for SIP or RTSP URIs. So we actually were thinking we were doing folks a favour, and being bashed for this came a bit as a surprise.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
http://www.meetecho.com

---

From: Doug Barton <[email-masked]>
Date: Wed, 02 Nov 2011 12:54:21 -0700

On 11/02/2011 12:40, Lorenzo Miniero wrote:

> nevertheless, to meet your
> and other people's concern about this, we also decided to make the
> RTSP tab the default choice

Personally I think that's a great resolution, and I look forward to
trying it out for the Taipei meeting.

> What I just want to hightlight again (even though Hadriel already
> wrote an excellent post to explain this) is that the applet is only
> there because there was no other way, for us (until RTCWEB becomes a
> reality), to make a real-time audio/video communication available for
> people who just want to use their browser and don't want to install
> ad-hoc clients for SIP or RTSP URIs. So we actually were thinking we
> were doing folks a favour, and being bashed for this came a bit as a
> surprise.

I can understand your surprise. Our community is a bit ... quirky in the
sense that we tend to express ourselves in ways that others would find
offensive (even when none is meant), and take offense at what others
might consider harmless. We also have a lot of minefields that
new/innocent folks can wander into, which is what I fear you may have done.

In any case I think the patience and transparency of the Meetecho folks
has been a refreshing change from most vendors, especially in this
space. Glad we haven't scared you off yet. :)

Doug

--

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Nov 2011 15:59:39 -0400

>>>>> "Hadriel" == Hadriel Kaplan <[email-masked]> writes:
    Hadriel> That's basically what's going on here.  Meetecho supports
    Hadriel> multimedia access to IETF sessions using your own SIP/RTSP
    Hadriel> client.  But they also want to let users use their browser
    Hadriel> for the session, if the user doesn't have a SIP/RTSP
    Hadriel> client.  Since browsers don't support WebRTC yet (because
    Hadriel> WebRTC is still being standardized), nor do many browsers
    Hadriel> even support HTML-5 yet, Meetecho has to use an
    Hadriel> applet/plugin model.

This email thread is the first I've heard that I can use meetecho using
clients other than theirs.  I don't recall seeing that on your site back
in July, but maybe I missed it.

    Hadriel> community, and unlike Cisco the cost is not a rounding
    Hadriel> error on their coffee budget. (not that I don't appreciate
    Hadriel> Cisco providing WebEx - I do)

I don't appreciate cisco providing webex for free, because it doesn't
work for many, and multiple meeting chairs ignore complaints about this
problem. 

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.