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
>