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

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Fri, 10 May 2013 06:37 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
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 2086E21F8E8F; Thu, 9 May 2013 23:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 6Mh-tlfysoXo; Thu, 9 May 2013 23:37:24 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CB66121F8FA5; Thu, 9 May 2013 23:37:23 -0700 (PDT)
X-AuditID: c1b4fb30-b7f3a6d0000007a4-18-518c95a25c72
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EB.CE.01956.2A59C815; Fri, 10 May 2013 08:37:22 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Fri, 10 May 2013 08:37:22 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: Adam Roach <adam@nostrum.com>
Thread-Topic: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
Thread-Index: AQHOS2hQZBBwa2OZtEiOSK4AxzMZ0w==
Date: Fri, 10 May 2013 06:37:21 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se>
References: <CA+9kkMDWy_Koq0Aun5A330O7OOMt9vimWPNe_uznAQdr0TSfow@mail.gmail.com> <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre6iqT2BBmf2q1ns+buI3WLq8scs Fis2HGC1WPuvnd2BxePv+w9MHkuW/GTymLXzCUsAcxSXTUpqTmZZapG+XQJXxs3721gLevkq TnT+YWxgXMrdxcjJISFgInFm22kmCFtM4sK99WxdjFwcQgKHGSXWbF3ECOEsYZQ41viVEaSK TSBQYuu+BWwgtoiAokTb4ZvMIDazQInE25NHWEFsYQFviW0bFjJD1PhIrL95iB3C1pNo6d0C VsMioCrxZP5TsM28Ar4Sx9evgFq2gVHiysujYA2MQCd9P7WGCWKBuMStJ/OhThWQWLLnPDOE LSrx8vE/VghbSeLHhkssEPV6EjemTmGDsLUlli18zQyxTFDi5MwnLBMYRWchGTsLScssJC2z kLQsYGRZxciem5iZk15uvokRGC0Ht/w22MG46b7YIUZpDhYlcd5krsZAIYH0xJLU7NTUgtSi +KLSnNTiQ4xMHJxSDYyBDdzWXXkST/wm7+IX51LTLqt0COX1O79FZnZbjcGKmY2Mki1qPWUv c3Pqk9QevHs+cVFD3qu/k+cu3Z108ciLU4XfPpy89/BThPt3Z8WjnBIa6j8dGtYH7VELZeCI WFo0U91zu/N2heOPMgNk7mYoyjje5NWxvhLjv3dj2n5bEX8VI0GXhUosxRmJhlrMRcWJAC0x PJtkAgAA
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Fri, 10 May 2013 06:37:44 -0000

On 5/8/13 11:19 PM, Adam Roach wrote:
> On 5/8/13 15:07, Paul Kyzivat wrote:

>> I remain dubious that this glare situation is a problem that needs to
>> be fixed.
>
> So am I, but Justin seems to be obsessed with it. That's why I'm
> proposing a non-normative recipe that allows people who are
> unnecessarily preoccupied with the issue to indulge their peccadillos.
> The rest of us are free to ignore it.

I think that glare coming from simultaneous add or remove of media may 
not be that common.

But I can easily think of other situations that would lead to glare for 
Plan A.

Just as an example, think about a conference scenario with a centralized 
node. Now, one of the participants wants to mute her/his audio, and as a 
result the audio m-line would go from sendrecv to recvonly. At roughly 
the same time the server wants to disable the high res video and enable 
the low res video (because this user will be moved, based e.g. on the 
recent audio activity, from being displayed in the main video window to 
be in a thumbnail on the screen of the other participants in the 
conference), so it wants to manipulate the direction attribute of other 
m-lines.

So there would be two offers sent at roughly the same time, which means 
we would have glare.

I think the result would be similar if the server would instead ask for 
another resolution using the imageattr.

You could argue that all control should be left to one end-point, but it 
is sort of clumsy.

Plan B, with the individual control of sources, seems better fitted to 
handle this kind of situations.

>
> /a