- From: Roman Shpount <roman@telurix.com>
- Date: Wed, 3 Oct 2012 13:40:14 -0400
- To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAD5OKxs7jpH0bgbO9Y=ptfjfY02Wk3XrBfqU4H4e+pAX0CQ8ag@mail.gmail.com>
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 Shpount On Wed, Oct 3, 2012 at 8:37 AM, Stefan Hakansson LK < 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:40:45 UTC