Re: [vmeet] Meetecho sessions start/stop time
Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 10 April 2016 20:10 UTC
Return-Path: <pkyzivat@alum.mit.edu>
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 CCA5B12D12A
for <vmeet@ietfa.amsl.com>; Sun, 10 Apr 2016 13:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665]
autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=comcast.net
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 3D89elunqcnQ for <vmeet@ietfa.amsl.com>;
Sun, 10 Apr 2016 13:10:41 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net
(resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43])
(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 E79D512D0B6
for <vmeet@ietf.org>; Sun, 10 Apr 2016 13:10:40 -0700 (PDT)
Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104])
by comcast with SMTP
id pLgqa9VndjuYRpLgtajaGT; Sun, 10 Apr 2016 20:10:40 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
s=q20140121; t=1460319040;
bh=dwDxET4TwybV//lMco6PwuEY8H8oannVTB3M0k0IKwI=;
h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version:
Content-Type;
b=r76+EUypV8ugCKV9gcAD/bHYEnrJJX3go/0EMno+rzlkABJ5kUz0dl1LYWm5Z13nq
tcdLJRxM4zrA1PNUudtAhI3ALoif//BAqjnIxWVYw0xb7oxs+VLCmjAos5ONDMYvlR
eVlIWRQnnVgri/RNHpPxAMUdxxYIejeLYYzihxEjaJpNUGqsvCg6LPLXq55NPhZgqy
2Rw58NSA9Pu4PWgStCci7+KiQdr3pLlR0TPwLKmvd2JnFFPE810BYh7X72dYjdYDLB
yaI6farKAv0RoUOAI5fj3NNy5BlNCCkN0GwM1zpHB04tH7IZecwe36dJO2h9Hvlw7G
fZcpyiA9J1m2Q==
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154])
by resomta-ch2-08v.sys.comcast.net with comcast
id gkAf1s0073KdFy101kAflt; Sun, 10 Apr 2016 20:10:39 +0000
To: vmeet@ietf.org
References: <570A8E5C.8040301@meetecho.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <570AB33E.7060704@alum.mit.edu>
Date: Sun, 10 Apr 2016 16:10:38 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <570A8E5C.8040301@meetecho.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/vmeet/6nIvGUz0d9iFJyYCTHSqcDuyyvc>
Subject: Re: [vmeet] Meetecho sessions start/stop time
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: Sun, 10 Apr 2016 20:10:42 -0000
On 4/10/16 1:33 PM, Meetecho IETF support wrote: > Folks, > > just to clarify that Meetecho sessions do start 5 minutes before the WG > meeting scheduled start time, and never stops before the meeting has > actually finished. > > Only when the previous meeting runs *very* long, we have to shift the > start time of the following Meetecho session. This is needed in order to > avoid overlaps in the recordings. This was the case of the 6LO session > on Thursday, which started at 17.30 sharp because the MTGVENUE session > ended at 17.30. I realize the audio/video feeds from the room are a resource that perhaps can only be attached to one meeting session at a time. But couldn't that be separated from everything else. So the prior session and the following session could still be open concurrently, with their own participants, with the audio/video feeds being removed from one and attached to the other at a time determined on the fly? Thanks, Paul
- [vmeet] Meetecho sessions start/stop time Meetecho IETF support
- Re: [vmeet] Meetecho sessions start/stop time John C Klensin
- Re: [vmeet] Meetecho sessions start/stop time Dave Crocker
- Re: [vmeet] Meetecho sessions start/stop time Paul Kyzivat
- Re: [vmeet] Meetecho sessions start/stop time Meetecho IETF support
- Re: [vmeet] Meetecho sessions start/stop time Dan York
- Re: [vmeet] Meetecho sessions start/stop time Dave Crocker