- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 3 Oct 2012 19:58:59 +0200
- To: Roman Shpount <roman@telurix.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 10/03/2012 07:40 PM, Roman Shpount wrote: > Once again, I have mentioned my concern for the shortcomings of the > current API in > > http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0102.htm<http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0102.html> > It looks like some additional API surface is needed to address my > concerns ( > http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0109.html ). > > I am not sure why this is being ignored... Roman, sorry, there was no intention what so ever to ignore you. The issues in the list I sent out were those brought up by Matthew and Martin in the discussion of API alternatives. Personally I agree to your input, and think we need some more API surface; and I also think the proposal you reference would be a reasonable way to add that surface. However, there has been very little discussion about that proposal so far. Hopefully we will come around to discuss this aspect soon. Br, Stefan > _____________ > Roman Shpount > > > On Wed, Oct 3, 2012 at 8:37 AM, Stefan Hakansson LK > <stefan.lk.hakansson@ericsson.com > <mailto:stefan.lk.hakansson@ericsson.com>> wrote: > > For the record. This is a minor update of the mail titled "Sorting > possible technical issues into categories" > (http://lists.w3.org/Archives/__Public/public-webrtc/2012Sep/__0142.html > <http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0142.html>). > > * The issues in categories "Being addressed" and "Needs to be > addressed" now all have ACTIONs associated with them. > > * The issues in category "Needs to be more clearly described" now > have descriptions (I link to Martin's mail). However, this in most > cases moves them into the "Needs further discussion" category (one > exception). > > To make it a bit easier to see what has been added, all new lines > start by "--" > > Stefan > ------------------------------__------------------------------__----------- > > *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 > -- ACTION-12 and ACTION-54 > > - *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]. > -- ACTION-57 > > - *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 > -- ACTION-51 > > - *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]) > -- ACTION-58 > > *Needs to be addressed* > ---------------------- > - *Rollback of offers* > -- ACTION-55 > > - *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) > -- ACTION-56 > > *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* > -- Described in [8] > -- Spawned "related identity issues" (see [8]) > -- Needs further discussion > > - *Split SDP between PeerConnection and MediaStream* > -- Described in [8] > -- Needs further discussion > > - *Serialization of duplicated tracks* > -- Described in [8] > -- Proposed to consider this issue not relevant > > - *Programmatic description of described streams* > -- Described in [8] > -- Needs further discussion > > [1] > http://lists.w3.org/Archives/__Public/public-webrtc/2012Aug/__0194.html > <http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0194.html> > [2] > http://lists.w3.org/Archives/__Public/public-media-capture/__2012Aug/0029.html > <http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0029.html> > > [3] http://dev.w3.org/2011/webrtc/__editor/getusermedia.html > <http://dev.w3.org/2011/webrtc/editor/getusermedia.html> > > [4] > http://lists.w3.org/Archives/__Public/public-webrtc/2012Sep/__0025.html > <http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0025.html> > > [5] https://www.w3.org/Bugs/__Public/show_bug.cgi?id=15861 > <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861> > [6] > http://datatracker.ietf.org/__doc/draft-ietf-rtcweb-use-__cases-and-requirements/ > <http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/> > [7] > http://lists.w3.org/Archives/__Public/public-webrtc/2012Sep/__0098.html > <http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html> > [8] > http://lists.w3.org/Archives/__Public/public-webrtc/2012Sep/__0146.html > <http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0146.html> > >
Received on Wednesday, 3 October 2012 17:59:24 UTC