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

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
>