Return-Path: 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 ; 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 ; 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 ; Tue, 24 Sep 2013 08:58:47 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ep20so3827171lab.16 for ; 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: From: Matt Fredrickson To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: multipart/alternative; boundary=089e0158c41032b41704e7233600 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 --089e0158c41032b41704e7233600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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=E5kansson 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=3Dimageattr open issue that w= e > >> 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=E5kansson > >> 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 > --089e0158c41032b41704e7233600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I tend also to agree with this. =A0Maybe I'm completel= y off, but it would seem that pause and resume might be done using some sem= i-inband media related path, perhaps like RTCP or something like that. =A0I= 'm not sure where to fit resolution in though...

Matthew Fredrickson
Digium, Inc.


On Fri, Sep 20, 201= 3 at 5:57 AM, Stefan H=E5kansson LK <stefan.lk.hakansson@er= icsson.com> wrote:
On 2= 013-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=3Dimageattr open issue th= at we
>> had an original agreement from over a year ago (Vancouver) to go w= ith
>> Harald's proposal in then
>> http://tools.ietf.org/id/draft-alvestrand-rt= cweb-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 th= is
>> issue after that between Harald Alvestrand and Stefan H=E5kansson<= br> >> 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/draf= t-alvestrand-constraints-resolution/
>>
>> Thus I would like to point out that there appear to be some indica= tion
>> 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 i= n
> 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 wer= e still
> unsettled, but now it should really be "a piece of cake".
My personal view is still that SDP is the wrong level for carry= ing 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<= br> > 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

--089e0158c41032b41704e7233600--