Re: [vmeet] Slides freezing

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 05 April 2016 15:32 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 A007A12D566 for <vmeet@ietfa.amsl.com>; Tue, 5 Apr 2016 08:32:44 -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 tAcj1NCcmn6B for <vmeet@ietfa.amsl.com>; Tue, 5 Apr 2016 08:32:43 -0700 (PDT)
Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 4254612D1C1 for <vmeet@ietf.org>; Tue, 5 Apr 2016 08:32:43 -0700 (PDT)
Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by comcast with SMTP id nSxRaSfBvO4QFnSyAanh6R; Tue, 05 Apr 2016 15:32:42 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459870362; bh=8O63itFgfJE4Y/YSvfjnnszS/r4X5sMqJoANhWutslk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=O5Iket4DelghYJY4ZGYZeSzZkC8qDIR3GxTklxpqtV+TuGeLXdXINvWD5zvdedX3H yjCGpYl6PunXVTj7BDGbv6Y2NpYCtmsAjmKsghZClZEoF5G814alSvNLXYvLpKUKiw ElU25phISoyqqY89tJiZQVhwoFjN5Kzb2fypbeRrFtV6IS3fmuzEaza2c5Amq3Tsvh uyK7rs5zxyPy8nWTKsyCyBxNwazIuV+O7Nr6kNCXLupxo56qo7/LNV2qh0Vv+pW/dB /oVxz2w5EmK45prN5HczZEkAgWsKvCvY96WKck17SP8hq0g8HgUmf8onA9Qcv8W7WK tCfDbPBW0h6yw==
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-12v.sys.comcast.net with comcast id efYh1s00M3KdFy101fYiBW; Tue, 05 Apr 2016 15:32:42 +0000
To: vmeet@ietf.org
References: <20160405150120.GA8117@verdi> <5703D642.1010104@meetecho.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <5703DA98.4060007@alum.mit.edu>
Date: Tue, 5 Apr 2016 11:32:40 -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: <5703D642.1010104@meetecho.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/vmeet/KGwWUXecn6FO6oZa31Kh9G4J_ow>
Subject: Re: [vmeet] Slides freezing
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: Tue, 05 Apr 2016 15:32:44 -0000

On 4/5/16 11:14 AM, Meetecho IETF support wrote:
> Hi John,
>
> Il 05/04/2016 17:01, John Leslie ha scritto:
>>     I've noticed multiple occurances of slides freezing in Meetecho.
>>
>>     The suggestions I get are "leave and rejoin."
>>
>>     This _really_ is less than user-friendly.
>>
>
> Agreed. In the next version we will add the possibility to restore only
> a single feed without forcing anybody to re-join.
>
>>     I'll venture a guess that this may by Comcast timing out port
>> allocations, since the slides
>> have often seen no changes for ten minutes -- long enough for Comcast
>> to time-out.
>>
>>     Meetecho probably should include some keep-alives for ports; and
>> IMHO really_should notice
>> that a port has gone away, and recover without requiring the user to
>> lose half-a-minute of
>> audio.
>
> This is not the case. The technology we use (WebRTC) already accounts
> for that, and besides even when the video is not changing there always
> is a constant stream flowing anyway (of course at a much lower bitrate).
>
> BTW, is this happening only for the slides feed, or for the speaker's
> video, too? This may be of help to us to debug things.

I had my audio and speaker video freeze at the same time. But chat was 
working, and (I think) slides were still working. I could explicitly 
leave the conference.

	Thanks,
	Paul