Re: [rtcweb] JSEP and video stream properties selection (a=imageattr usage)

Harald Alvestrand <harald@alvestrand.no> Fri, 20 September 2013 07:25 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7A621F89FF for <rtcweb@ietfa.amsl.com>; Fri, 20 Sep 2013 00:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Level:
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 hAw5Uy6U71s2 for <rtcweb@ietfa.amsl.com>; Fri, 20 Sep 2013 00:25:24 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F0BA421F8443 for <rtcweb@ietf.org>; Fri, 20 Sep 2013 00:25:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 688DA39E1A6 for <rtcweb@ietf.org>; Fri, 20 Sep 2013 09:25:21 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCrru3VGmeWx for <rtcweb@ietf.org>; Fri, 20 Sep 2013 09:25:20 +0200 (CEST)
Received: from [192.168.1.186] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BC44739E0D9 for <rtcweb@ietf.org>; Fri, 20 Sep 2013 09:25:20 +0200 (CEST)
Message-ID: <523BF860.1090105@alvestrand.no>
Date: Fri, 20 Sep 2013 09:25:20 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <523BE4DB.5030800@ericsson.com>
In-Reply-To: <523BE4DB.5030800@ericsson.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] JSEP and video stream properties selection (a=imageattr usage)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Sep 2013 07:25:28 -0000

On 09/20/2013 08:02 AM, Magnus Westerlund wrote:
> WG,
>
> In the JSEP call I commented regarding a=imageattr open issue that we
> had an original agreement from over a year ago (Vancouver) to go with
> Harald's proposal in then
> http://tools.ietf.org/id/draft-alvestrand-rtcweb-resolution-00.txt
>
> This is documented in the minutes:
> http://www.ietf.org/proceedings/84/minutes/minutes-84-rtcweb
>
>
> However, I did forget to note that there has been discussion on this
> issue after that between Harald Alvestrand and Stefan Håkansson
> primarily on the W3C list
>
> http://lists.w3.org/Archives/Public/public-webrtc/2013Aug/0051.html
>
> Where they are seriously discussing only using WebRTC API for this.
>
> It is in the context of
> https://datatracker.ietf.org/doc/draft-alvestrand-constraints-resolution/
>
> Thus I would like to point out that there appear to be some indication
> of desire move away from the consensus last year.

My thinking is that there are 3 points on the spectrum of solutions:

- Constraints at source only (the approach most thoroughly described in
draft-alvestrand-constraints-resolution).

- Constraints at destination can be sigalled in SDP, and acted on at
source (described in draft-alvestrand-rtcweb-resolution). This spec
could not be pursued as long as the "Plan X" discussions were still
unsettled, but now it should really be "a piece of cake".

- Defining a new way of signalling. This was the approach rejected in
Vancouver.

Formalistically, if the IETF decides to offer a well defined mechanism
for negotiating resolution through SDP, the W3C will certainly take up
the discussion on whether or not we should connect the API to that
functionality.

Happy to discuss more.