From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: [rtcweb] JSEP and video stream properties selection (a=imageattr
 usage)
Thread-Index: AQHOtcbevxz1HDDILk+MiGgkFV/wNw==
Date: Fri, 20 Sep 2013 10:57:10 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C395079@ESESSMB209.ericsson.se>
References: <523BE4DB.5030800@ericsson.com> <523BF860.1090105@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] JSEP and video stream properties selection (a=imageattr
 usage)
Precedence: list

On 2013-09-20 09:25, Harald Alvestrand wrote:=0A=
> On 09/20/2013 08:02 AM, Magnus Westerlund wrote:=0A=
>> WG,=0A=
>>=0A=
>> In the JSEP call I commented regarding a=3Dimageattr open issue that we=
=0A=
>> had an original agreement from over a year ago (Vancouver) to go with=0A=
>> Harald's proposal in then=0A=
>> http://tools.ietf.org/id/draft-alvestrand-rtcweb-resolution-00.txt=0A=
>>=0A=
>> This is documented in the minutes:=0A=
>> http://www.ietf.org/proceedings/84/minutes/minutes-84-rtcweb=0A=
>>=0A=
>>=0A=
>> However, I did forget to note that there has been discussion on this=0A=
>> issue after that between Harald Alvestrand and Stefan H=E5kansson=0A=
>> primarily on the W3C list=0A=
>>=0A=
>> http://lists.w3.org/Archives/Public/public-webrtc/2013Aug/0051.html=0A=
>>=0A=
>> Where they are seriously discussing only using WebRTC API for this.=0A=
>>=0A=
>> It is in the context of=0A=
>> https://datatracker.ietf.org/doc/draft-alvestrand-constraints-resolution=
/=0A=
>>=0A=
>> Thus I would like to point out that there appear to be some indication=
=0A=
>> of desire move away from the consensus last year.=0A=
>=0A=
> My thinking is that there are 3 points on the spectrum of solutions:=0A=
>=0A=
> - Constraints at source only (the approach most thoroughly described in=
=0A=
> draft-alvestrand-constraints-resolution).=0A=
>=0A=
> - Constraints at destination can be sigalled in SDP, and acted on at=0A=
> source (described in draft-alvestrand-rtcweb-resolution). This spec=0A=
> could not be pursued as long as the "Plan X" discussions were still=0A=
> unsettled, but now it should really be "a piece of cake".=0A=
=0A=
My personal view is still that SDP is the wrong level for carrying this =0A=
kind of signaling (resolution, and perhaps further down the road =0A=
pause/resume related signaling). Each update requires an O/A, and locks =0A=
out other changes to the session. And since the SDPs must be handled by =0A=
the application (that is responsible for sending them over and applying =0A=
them) I wonder if there is any advantage compared to just having an API =0A=
on the sending side. If the receiving application wants another =0A=
resolution sent, it could just tell the sending application so, rather =0A=
than going through a createOffer/setLocal/ send-offer =0A=
/receive-answer/setRemote cycle.=0A=
=0A=
>=0A=
> - Defining a new way of signalling. This was the approach rejected in=0A=
> Vancouver.=0A=
>=0A=
> Formalistically, if the IETF decides to offer a well defined mechanism=0A=
> for negotiating resolution through SDP, the W3C will certainly take up=0A=
> the discussion on whether or not we should connect the API to that=0A=
> functionality.=0A=
>=0A=
> Happy to discuss more.=0A=
>=0A=
> _______________________________________________=0A=
> rtcweb mailing list=0A=
> rtcweb@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/rtcweb=0A=
>=0A=
=0A=