Re: [rtcweb] JSEP and video stream properties selection (a=imageattr usage)
Matt Fredrickson <creslin@digium.com> Tue, 24 September 2013 15:59 UTC
Return-Path: <creslin@digium.com>
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 7003811E8175 for <rtcweb@ietfa.amsl.com>; Tue, 24 Sep 2013 08:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.318
X-Spam-Level:
X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-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 RbCxEzH0--ss for <rtcweb@ietfa.amsl.com>; Tue, 24 Sep 2013 08:59:00 -0700 (PDT)
Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1158311E816D for <rtcweb@ietf.org>; Tue, 24 Sep 2013 08:58:47 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id ep20so3827171lab.16 for <rtcweb@ietf.org>; Tue, 24 Sep 2013 08:58:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WMi9aEPBV3bjTX8RbxjK/doRo7Bz6kvkmGVHIoJfask=; b=TWtwWTS0VOCouX30eX6so4KS1dgnBe1k4tldoDhaLLteCfa+qWsv/L9Z3watg3ZFHX ATWyadsx8ul99aHGgafs2g8DVz0erjGm1XXm593t7ERsOJoaIESqmiY4f+c15r6Wx4G9 s1OSvOSFnL/n44YVkcnEPxABSdtx3YgsvzMJMBMN76naZlXfSS+fyEk+AAncMloTKhbC uCClZ/ESI+oWMPhb3ywyPRlOuicVogSyulx4rxzQGQ4qGoX+ZVLQo6ZR41GY/5SlEAl3 VAug5nDPXehccjh6eAy8BRGe5p42qrWF1AZUNBzrq4xlO0EjrXVZkLVt/jj0gnD7cQum ArLg==
X-Gm-Message-State: ALoCoQkBP0BLEctf2f9ZjG/MF5bO1Kq6ixIah/4rvZ8iYzfqgDxTkFuCH6a2XDumyiEnAXQ9wptG
MIME-Version: 1.0
X-Received: by 10.152.30.74 with SMTP id q10mr7534987lah.27.1380038326001; Tue, 24 Sep 2013 08:58:46 -0700 (PDT)
Received: by 10.112.132.102 with HTTP; Tue, 24 Sep 2013 08:58:45 -0700 (PDT)
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C395079@ESESSMB209.ericsson.se>
References: <523BE4DB.5030800@ericsson.com> <523BF860.1090105@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B1C395079@ESESSMB209.ericsson.se>
Date: Tue, 24 Sep 2013 10:58:45 -0500
Message-ID: <CAHZ_z=wnQiBVUu_ku5kSYf_0WaFhMUEVR9W8r_zpJuc3UtdUnA@mail.gmail.com>
From: Matt Fredrickson <creslin@digium.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Content-Type: multipart/alternative; boundary="089e0158c41032b41704e7233600"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Tue, 24 Sep 2013 15:59:05 -0000
X-List-Received-Date: Tue, 24 Sep 2013 15:59:05 -0000
I tend also to agree with this. Maybe I'm completely off, but it would seem that pause and resume might be done using some semi-inband media related path, perhaps like RTCP or something like that. I'm not sure where to fit resolution in though... Matthew Fredrickson Digium, Inc. On Fri, Sep 20, 2013 at 5:57 AM, Stefan Håkansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 2013-09-20 09:25, Harald Alvestrand wrote: > > 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". > > My personal view is still that SDP is the wrong level for carrying this > kind of signaling (resolution, and perhaps further down the road > pause/resume related signaling). Each update requires an O/A, and locks > out other changes to the session. And since the SDPs must be handled by > the application (that is responsible for sending them over and applying > them) I wonder if there is any advantage compared to just having an API > on the sending side. If the receiving application wants another > resolution sent, it could just tell the sending application so, rather > than going through a createOffer/setLocal/ send-offer > /receive-answer/setRemote cycle. > > > > > - 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. > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >
- [rtcweb] JSEP and video stream properties selecti… Magnus Westerlund
- Re: [rtcweb] JSEP and video stream properties sel… Harald Alvestrand
- Re: [rtcweb] JSEP and video stream properties sel… Stefan Håkansson LK
- Re: [rtcweb] JSEP and video stream properties sel… Matt Fredrickson
- Re: [rtcweb] JSEP and video stream properties sel… Justin Uberti