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
