Re: Missing Features: Stream Control

Should this not be synchronized with the Streams API? Please see recent 
evolutions [1] and thread [2] (where WebRTC streams are mentioned)

Ccing Webapps and Takeshi/Feras.

Regarding your proposal I was about to propose to add about the same 
thing in Streams: at least a stop method (which would send an EOF) and 
maybe a resume method, or something like your pause/unpause.

For flow control I think I am changing my mind, it looks impossible to 
do a precise flow control with js, so probably the API itself should 
handle it.

Regards,

Aymeric

[1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0152.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0049.html

Le 18/10/2013 18:24, Adam Roach a écrit :
> We've recently had some implementors reach out to ask about how to do 
> certain things with the WebRTC interfaces, and I've been pretty well 
> unable to turn up anything that makes a lot of sense for most of the 
> interesting stream-control interfaces.
>
> Some of this is talked about here, with an implication that the author 
> of this wiki page, at least, would be willing to leave some of them 
> unspecified for the first version of WebRTC:
>
> http://www.w3.org/2011/04/webrtc/wiki/Transport_Control#Needs_further_discussion.2C_maybe_for_later_versions
>
> Unfortunately, I don't think we can leave stream pause/unpause or 
> stream rejection/removal out of the first version of the document. The 
> good news is that I think we have all the interfaces necessary to do 
> these things; we just need to spell out clear semantics for them.
>
> As a high-level thumbnail sketch, here's what I think makes sense:
>
>  1. To pause a track that you are sending, set enabled=false on a
>     MediaStreamTrack that you have added to a PeerConnection. This
>     information will cause the PeerConnection to stop sending the
>     associated RTP. Maybe this triggers an onnegotiationneeded to set
>     the corresponding m-line to recvonly or inactive and maybe it just
>     stops sending the stream; I'm not sure which makes more sense.
>       * To unpause, set enabled back to true, and the steps are reversed
>       * To pause all the MSTs associated with a MediaStream, use
>         enabled on the MediaStream itself.
>
>  2. To pause a track that you are receiving, set enabled=false on the
>     MediaStreamTrack that you received from the PeerConnection via
>     onaddstream. This will cause the MST to stop providing media to
>     whatever sink it has been wired to, and trigger an
>     onnegotiationneeded event. The subsequent CreateOffer sets the
>     corresponding m-line to sendonly or inactive, as appropriate.
>       * As above, this operation can also be performed on a
>         MediaStream to impact all of its tracks.
>
>  3. To reject a track that has been offered, call stop() on the
>     corresponding MediaStreamTrack after it has been received via
>     onaddstream, but before calling CreateAnswer. This will cause it
>     to be rejected with a port number of zero.
>
>  4. To remove a track from an ongoing session, call stop() on the
>     corresponding MediaStreamTrack object. This will (a) immediately
>     stop transmitting associated RTP, and (b) trigger an
>     onnegotiationneeded event.
>       * If both the sending and receiving MST associated with that
>         m-line have been stop()ed, then the subsequent CreateOffer
>         sets the port on the corresponding m-line to zero.
>       * If only one of the two MSTs associated with that m-line has
>         been stop()ed, then the subsequent CreateOffer sets the
>         corresponding m-line to sendonly, receiveonly, or inactive, as
>         appropriate.
>
> Does this make sense to everyone? It seems pretty clean, easy to 
> specify, and reasonable to implement. Best of all, we're not changing 
> any currently defined interfaces, just providing clear semantics for 
> certain operations.
>
> /a
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms