W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2012

Sorting possible technical issues into categories

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Mon, 17 Sep 2012 12:35:56 +0200
Message-ID: <5056FD0C.60907@ericsson.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi all!

As part of the preliminary plan for moving forward (was part of the mail 
on poll result [7]), it was said that the WG will continue to work on 
the items that have been raised as possible technical issues (in [1]).

The chairs have made an initial attempt on sorting those items into 
categories ("Will not do", "Not a question for this WG", "Being 
addressed", "Needs to be addressed", "Needs further discussion", "Needs 
to be more clearly described"), see below, to facilitate moving forward.

Let us know if you think this break down makes sense or not, and any 
other feedback you have!

Stefan for the chairs.

*Will not do*
-------------
- *Remove SDP*: the poll was clear

*Not a question for this WG*
----------------------------
- *H.264 SVC support*: IETF matter

- *Testing of continued connection liveness*: IETF matter

- *Interoperability with varying ICE and ICE-like agents*: IETF matter

*Being addressed*
-----------------
- *Learn what ICE candidates are in use*: this is part of the proposed 
stats report

- *Pausing and muting of streams*: there is already enable/disable on 
tracks available [3], and there has recently been a proposal to move 
this functionality to the consumer (e.g. PeerConnection) [2].

- *Expose additional ICE state:*, *Remove offer/answer*, *Description of 
state/behavior is currently incomplete*, *Document how the different 
state machines interact*: The discussion of states for PeerConnection, 
including SDP exchanges, is ongoing

- *Are MediaStreams mutable objects?*: According to [3] they are (but 
there is a recent proposal that a MediaStream being received from a peer 
shall not be mutable [4])

*Needs to be addressed*
----------------------
- *Rollback of offers*

- *Provide congestion feedback API for flows*, *Bandwidth allocation*, 
*Bandwidth estimation feedback* (there is a bug filed related to this 
[5]; [4] proposed an API surface that might suitable; BW allocation is 
perhaps mostly and IETF matter)

*Needs further discussion*
--------------------------
- *DTMF onTone event*: unclear if there is consensus for supporting this 
feature, is currently not covered by use-case document [6])

- *Set Security Description*: need the discussion in IETF to finalize first

- *Learning of network change events*: need to discuss the role of app 
and the role of the UA
- *Priority allocation*: need further discussion

- *API for discovering capabilities* (this has to some extent been 
discussed in the Media Capture TF)

*Needs to be more clearly described*
------------------------------------
- *Control connection establishment based on certificate*

- *Split SDP between PeerConnection and MediaStream*

- *Serialization of duplicated tracks*

- *Programmatic description of described streams*

[1] http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0194.html
[2] 
http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0029.html

[3] http://dev.w3.org/2011/webrtc/editor/getusermedia.html

[4] http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0025.html

[5] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861
[6] 
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/
[7] http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html
Received on Monday, 17 September 2012 10:36:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 September 2012 10:36:21 GMT