Re: Reminder: Remote Participation Support for Admin Plenary Tonight

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear all,

as a representative of the Meetecho team, let me jump into this discussion.

First, about the quality of the audio stream. Our system provides two different real-time (and when I say "real-time" I mean "real-time") streams: the former is a standard VoIP (Asterisk-based) GSM stream; the latter is an RTSP G.711 alaw stream. Both of them are not meant for high-quality transmission (which, as far as I know, is the objective of the classical IETF mp3 streaming based on icecast); they are rather meant to provide the participants with a good-enough audio experience. With respect to this, I defy anyone who tested Meetecho to demonstrate the contrary. The same holds for video, which is a standard H.263 encoded (and mixed, if needed) stream with either a QCIF or a CIF resolution. We do not aim to do HD video or telepresence, or the like. The point is that Meetecho has been conceived at the outset as a real-time collaboration framework; if you ever participated in a virtual meeting here at the IETF, you'll have noticed that we provide seamless, integrated access to the standard IETF jabber room, to live slide presentations (with automated trigger of slide changes on the chat), as well as (if needed) to both live video and audio. For this last part (access to the audio and video streams) we require people to execute a very simple and lightweight applet based on Java Media Framework which enables multimedia support. Those who don't want to use the applet can just open they're favourite RTSP player and listen to the available audio stream; not to say that those who want to rely on the PSTN, can just dial-in through the PSTN bridge. As to the login credentials, the only thing we require is that participants insert they're preferred username, together with an e-mail address. We create on-the-fly a temporary account on our system, which is valid just for the duration of the conference and is immediately thereafter destroyed. We do not store any information about the users who logged into the system and we are not interested at all in using the information they provided for any other purpose.

We do believe that the experience we provide (especially to remote participants) is an advanced one and does not conflict at all with the services that the IETF normally offers to its participants. To have an idea of what I'm saying, please have a look at the recordings of the sessions we supported, with special regard to today's plenary, available at the following site: http://www.meetecho.com/ietf81/recordings. If you play it out, you'll also easily acknowledge the fact that the service we provide is useful both "during" the sessions and "after" the sessions (e.g. for the minutes, or as a reference for those who could not make it when the event was scheduled). You'll also recognize that the quality of the audio is definitely good. Correct me if I'm wrong.

We are anyhow open to criticisms, especially when they are made with a constructive aim.

Best regards,

Simon




From: Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>
To: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
Reply-to: Gonzalo.Camarillo@xxxxxxxxxxxx
Subject: Re: Reminder: Remote Participation Support for Admin Plenary Tonight
X-RSN: 1/0/933/10396/57949

Hi,

> I don't know about the codecs, but there is a wireless hop. I'm getting
> frequent very short drops as well as slightly buzzy sound and less fidelity > than the parallel session streaming. The voices of people I know well are
> harder to recognise.

one aspect to consider is that long play-out buffers increase the audio
quality but also increase the delay. Many people have complained about
not being able to effectively participate in the meetings remotely using
the traditional audio streams because of the long delay. On the other
hand, short play-out buffers reduce the delay but can also reduce the
quality under bad network conditions.

As you said, different situations require different services and having
both services available makes sense.

Cheers,

Gonzalo

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

--
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@xxxxxxxx
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]