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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Sep 2013 08:02:03 +0200

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.

Thus it appears that this topic may require some further discussion.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Sep 2013 09:25:20 +0200

> 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".

- 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.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 20 Sep 2013 10:57:10 +0000

> 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.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Matt Fredrickson <[email-masked]>
Date: Tue, 24 Sep 2013 10:58:45 -0500

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.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Sep 2013 10:50:11 -0700

Since we have a clear path forward for a signaling-plane mechanism for
these features, I think we should proceed on this path.

If it eventually turns out that this path does not provide good enough
performance in certain situations, we can look into a media-plane mechanism
as an alternative.