Re: [93attendees] meetecho questions

"Meetecho IETF support" <ietf@meetecho.com> Thu, 23 July 2015 18:19 UTC

Return-Path: <ietf@meetecho.com>
X-Original-To: 93attendees@ietfa.amsl.com
Delivered-To: 93attendees@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158941B2AD1 for <93attendees@ietfa.amsl.com>; Thu, 23 Jul 2015 11:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.68
X-Spam-Level: **
X-Spam-Status: No, score=2.68 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAO2KtA6pLfL for <93attendees@ietfa.amsl.com>; Thu, 23 Jul 2015 11:19:55 -0700 (PDT)
Received: from smtpdg5.aruba.it (smtpdg5.aruba.it [62.149.158.235]) by ietfa.amsl.com (Postfix) with ESMTP id E46B21B2AFA for <93attendees@ietf.org>; Thu, 23 Jul 2015 11:19:43 -0700 (PDT)
Received: from meetecho.com ([62.149.158.90]) by smtpcmd05.ad.aruba.it with bizsmtp id vuKe1q0071xJdJu01uKeSH; Thu, 23 Jul 2015 20:19:41 +0200
Date: Thu, 23 Jul 2015 20:19:37 +0200
Message-Id: <NRYDKP$D797138643F46835511A6F430AF54014@meetecho.com>
In-Reply-To: <31595.1437672010@sandelman.ca>
References: <31595.1437672010@sandelman.ca>
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: "Meetecho IETF support" <ietf@meetecho.com>
To: mcr+ietf@sandelman.ca
X-XaM3-API-Version: V3(R2)
X-SenderIP: 31.130.224.143
Archived-At: <http://mailarchive.ietf.org/arch/msg/93attendees/Q9jyA2nLiWMB9sfPF6J4xI0u7sY>
Cc: 93attendees@ietf.org
Subject: Re: [93attendees] meetecho questions
X-BeenThere: 93attendees@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list of IETF 93 attendees that have opted in on this list. " <93attendees.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/93attendees>, <mailto:93attendees-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/93attendees/>
List-Post: <mailto:93attendees@ietf.org>
List-Help: <mailto:93attendees-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/93attendees>, <mailto:93attendees-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2015 18:19:57 -0000

Hello Michael,

thanks for your feedback! Answering inline.

> 
> I'm remote for IETF93, and I've lived entirely on meetecho, while previously,
> I've used a mix of streamed MP3/downloading-slides/pure-xmpp, and some meetecho.
> 
> 1) the meetecho sessions seem to stop exactly at the closing time, which is
>    sometimes a problem, and not everyone's watch is identically set.
> 


If you experienced something like this it's weird, as that's actually not the way it should work. We only stop sessions when we notice it has ended, something we can do as we monitor all the video and audio streams from the control endpoint in the NOC. The only times we stop sessions before they end is when the overtime exceeds ~10 minutes, as in that case we need some time to prepare the session that starts in the following slot.

What does not work is trying to join a session after the end time, that's true, but for remote participants still in the room the streaming will proceed.


> 2) the meetecho sessions do not start until the starting time, and you can't
>    wait, so it means that one can not come a minute or two early.  I also
>    suggest that during the time before the meeting starts, that some kind of
>    "muzak" fill the meetecho room at the same levels, so that people can use
>    that to validate if their headsets, etc. work.
> 


That shouldn't be the case either: to be precise, we configure our servers to allow users to join from exactly 5 minutes before sessions start. This allows for people to join quite a bit before the actual sessions start, and gives us enough time to make the proper checks (e.g., whether video and audio are captured and restreamed correctly) and fix things if needed.


> 3) the meetecho recordings are great because they synchronize slides and chat
>    and audio... but... well.. can we have an option for 2x or 3x playback speed?
> 


Yep, there's no "increase speed" feature, but there is a seekbar below you can make use of to quickly go to a specific point in the recording. It's admittedly not very precise or effective, and is one of the areas we want to improve in that respect.


> 4) The name that you put on the "Blue Sheet" winds up being your jabber ID.
>    Okay, great, but that is no collision process.  So if I happen to be in
>    the jabber room using the same ID (through my regular jabber client), then
>    I get kicked out with a weird error... Also, "Michael Richardson" is
>    actually a pretty common name (my wife even has a cousin with the same
>    name; please enqueue ozarks jokes now)... so even non-malicious situations
>    could have conflicts.
> 


We handle conflicts in Jabber usernames as I believe other clients do (or should do, at least). If you try to join a session via Meetecho and the username is already taken, you'll be asked to choose a different one: the UI suggests some by simply appending something to make the provided one unique. If you join with a Jabber client after you joined via Meetecho, the Jabber client should notify you about the conflict and resolve it pretty much the same way.

Not sure how we could change this behaviour to improve this. If the conflict management is not working as expected, it's a bug we need to fix.


> 5) I'd like to opt out of the chat on the *browser* screen, and just have the video and
>    the slides be same size... that would be more pleasant.
> 


As of now that's not possible, you're right. We do provide a Jabber-less alternative, but it only provides a Flash-based view of the slides and the audio feed, no video.

Jabber is integrated as we actually thought it would be seen as a convenience for users, so we honestly never thought about an option to opt out. If there will be enough interest in this, we'll try and work on a further alternative to address that requirement as well. 


> 6) what is the right process to get the camera pointed in a different
>    direction? Should people in the room move it?   or?
> 


That's actually our fault :-)

As anticipated, we're monitoring all sessions at the same time from a couple of controlling laptops. All cameras are remotely controllable, which means we can follow speakers around and, when possible, follow the discussion (e.g., focus on the mic line rather than the speaker). That said, 8 sessions at the same time are a lot, and since we're often busy on other things (e..g, making sure audio works, helping a remote presentation, processing recordings and the like) we sometimes lose track of a few videos.

This is something you guys can help us on, though: we join all Jabber session using Meetecho as a username, so if you notice we're not doing something right, just mention us on the jabber room (as Meetecho, capital M), and we'll be alerted loudly. This obviously also applies if you notice any problem, either in the local room or in the Meetecho session.


Thanks again for your feedback and suggestions!
the Meetecho Team


> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
>