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

Re: Update of "Sorting issues into categories"

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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:30 UTC