Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00

Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 11 May 2013 16:24 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF9D21F9305 for <mmusic@ietfa.amsl.com>; Sat, 11 May 2013 09:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.026
X-Spam-Level:
X-Spam-Status: No, score=-0.026 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WflZJ4aVBuin for <mmusic@ietfa.amsl.com>; Sat, 11 May 2013 09:24:20 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id D2A5F21F92EC for <mmusic@ietf.org>; Sat, 11 May 2013 09:24:11 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id agB01l0010EZKEL5CgQBnP; Sat, 11 May 2013 16:24:11 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id agQA1l00k3ZTu2S3MgQAyq; Sat, 11 May 2013 16:24:11 +0000
Message-ID: <518E70A9.7070007@alum.mit.edu>
Date: Sat, 11 May 2013 12:24:09 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
References: <CA+9kkMDWy_Koq0Aun5A330O7OOMt9vimWPNe_uznAQdr0TSfow@mail.gmail.com> <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se>
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368289451; bh=8UTa6ZJNZGmpimfK6oznzEHlDAk382YzHGooMGsU7bQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VD+4JxlepMZqzi9p57UZbgwphdKePSqMHTOL5+uZUvSjfrjESeJkk3lQV2FNx1+2D P3qX+lE1LcQHzTi1wccWQtuA2WMpy/srkr+AfEmoQo1xYpwnrfyWbT5aR56ATrZUA5 HWCZePkQqOM++G58/bQKls03BJzJ5mGwMYnp7giXoB7Nb2apwbhdOgQ6V5w578NV+C psj7MpRFZBhMMFD3TVRIY4zddoEmsFQT/fCzLFuZAbO4I5uBlsoeZHqSriPjNDC7n1 k94gQzEt9KyX+/vhkhS5fPvNKRHApqnGme8MCeJkdQeoeAexAzZ7DOYoU/xvmNEa5/ fobd8evHAITXg==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 May 2013 16:24:26 -0000

On 5/11/13 7:50 AM, Stefan Håkansson LK wrote:
> On 5/10/13 11:20 PM, Paul Kyzivat wrote:

>> What is the probability that the other side, for independent reasons,
>> decides to make a change within that interval? (And it isn't really the
>> whole interval - it is only the first part of it.)
>
> Given that in multiparty services the "main" video changes quite often,
> I'd not say this is extremely low. It will happen.

Are you thinking that there will be an SDP change every time the speaker 
changes???

Or do you mean changes when participants join and leave a conference?

I would hope there will normally not be SDP changes for either of those 
events.

> But, given that there is a way to roll-back in a predictable way I think
> glare resolution could be quick - nothing stops the web application from
> including a random number in every offer, and resolve glare based on
> that (one of the offers "win").
>
> So I think glare will happen in practice (that is what I wanted to point
> out), but it is not a show-stopper provided there is a way to roll back.

I'm sure it will happen. The question is whether it happens often enough 
to do more than count on the normal glare recovery procedures.

	Thanks,
	Paul