IETF Logo Mail Archive

Re: [vmeet] Meetecho suggestion for IETF-96 and beyond

"HANSEN, TONY L" <tony@att.com> Fri, 08 April 2016 22:44 UTC

Return-Path: <tony@att.com>
X-Original-To: vmeet@ietfa.amsl.com
Delivered-To: vmeet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8BB12D14D; Fri, 8 Apr 2016 15:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 l35V1smyvgqh; Fri, 8 Apr 2016 15:44:10 -0700 (PDT)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1D912D11F; Fri, 8 Apr 2016 15:44:10 -0700 (PDT)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u38Mi5Mr033203; Fri, 8 Apr 2016 18:44:05 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 226mny2mpr-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Apr 2016 18:44:05 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u38Mi1WI029241; Fri, 8 Apr 2016 18:44:01 -0400
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u38Mhw7c029231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Apr 2016 18:44:00 -0400
Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 8 Apr 2016 22:43:45 GMT
Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.206]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 18:43:45 -0400
From: "HANSEN, TONY L" <tony@att.com>
To: "wgchairs@ietf.org" <wgchairs@ietf.org>
Thread-Topic: Meetecho suggestion for IETF-96 and beyond
Thread-Index: AQHRkc5OuUCFDq0+yEClvYKt6dOZB5+ArJqA
Date: Fri, 8 Apr 2016 22:43:45 +0000
Message-ID: <C175C1F2-E53A-453C-820A-B3AB49CE0EA9@att.com>
References: <a06d5a6284624b0db8367ac7d3393059.squirrel@mail2.ihtfp.org>
In-Reply-To: <a06d5a6284624b0db8367ac7d3393059.squirrel@mail2.ihtfp.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.110.240.53]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5A475DACCFC6554291EED5E698DC7B9B@LOCAL>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-08_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604080337
Archived-At: <http://mailarchive.ietf.org/arch/msg/vmeet/erZx1DR8lrXlExkwTwu-kNHECsw>
Cc: "vmeet@ietf.org" <vmeet@ietf.org>, "team@meetecho.com" <team@meetecho.com>
Subject: Re: [vmeet] Meetecho suggestion for IETF-96 and beyond
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF remote participation meeting services discussion <vmeet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vmeet>, <mailto:vmeet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vmeet/>
List-Post: <mailto:vmeet@ietf.org>
List-Help: <mailto:vmeet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2016 22:44:12 -0000

I suggest that dicussion of enhancements to meetecho and other virtual meeting tools at least cc the vmeet@ietf.org mailing list.

	Tony



On 4/8/16, 3:38 PM, "WGChairs on behalf of Derek Atkins" <wgchairs-bounces@ietf.org on behalf of derek@ihtfp.com> wrote:

>After spending the week trying to attend several WGs remotely this week, I
>have a couple things to say about it.
>
>First, thank you.  When the system worked, it worked well and I felt like
>I was almost in the room.  Also, a big Thank You also to the volunteers
>who channelled from jabber to the mic.
>
>However I do have a few suggestions for next time.
>
>My biggest beef was that I couldn't sign into the meetecho room until
>exactly when the meeting started.  But there was ALWAYS a delay to getting
>in, with all the page refreshes, having to login, copy-and-paste in my
>reg#, upload images, waiting for my browser to ask me to share my camera
>and mic, etc.  So for a 0900 meeting I usually couldn't get in until about
>0903-0905, often missing the introduction and sometimes even the agenda. 
>I would recommend you allow attendees to join the room up to 5 minutes
>prior to the actual meeting start.  E.g. for a 0900 meeting, allow sign-in
>to start at 0855.
>
>Similarly, at the end of the meeting there were times when the meeting ran
>long, or there was additional conversation going on.  But meetecho ended
>precisely when the meeting was scheduled to end.  I feel this was also a
>disservice and there should be some leeway at the end of the meeting. 
>E.g. if a meeting is scheduled to end at 1130, let the stream go to say
>1135 or 1145, or several minutes after the meeting actually ends (even if
>it's before or after the official end).
>
>Also, when there is a network transmission error, it could be nice to just
>refresh one stream instead of having to refresh the whole page (which
>would often require logging in again, killing the audio stream in the
>process).
>
>I'm happy to provide any other comments offline (or online) if you have
>questions.
>
>Thanks,
>
>-derek
>
>-- 
>       Derek Atkins                 617-623-3745
>       derek@ihtfp.com             www.ihtfp.com
>       Computer and Internet Security Consultant
>

v2.8.7 | Report a Bug | By Email