25361 2014-04-16 04:24:53 +0000 Media Capture and Streams spec should explicitly specify that recvonly streams / tracks should be considered as muted. 2014-05-08 08:05:16 +0000 1 1 1 Unclassified WebRTC Working Group Media Capture and Streams unspecified All All RESOLVED FIXED P2 normal --- 1 kiran.guduru public-media-capture adam.bergkvist public-media-capture stefan.lk.hakansson oldest_to_newest 103934 0 kiran.guduru 2014-04-16 04:24:53 +0000 The remote MediaStreamTracks may be temporarily stopped receiving data from the remote peer, if the streams / tracks are specified to be recvonly in the sdp. In Section 4.3.1 "Life-cycle and media flow" of [1], it is specified that "a track that is a member of a MediaStream, received via a RTCPeerConnection [WEBRTC10], is muted if the application on the other side disables the corresponding track in the MediaStream being sent." This statement should be extended as below. "a track that is a member of a MediaStream, received via a RTCPeerConnection [WEBRTC10], is muted if the application on the other side disables the corresponding track in the MediaStream being sent or it is specified as a recvonly stream in the SDP." [1] http://www.w3.org/TR/mediacapture-streams/#life-cycle-and-media-flow 104160 1 stefan.lk.hakansson 2014-04-22 11:11:44 +0000 I think we should not extend the statement, but rather remove it. This kind of info belongs in the WebRTC document IMO. 104249 2 adam.bergkvist 2014-04-23 07:24:28 +0000 Perhaps it's ok to mention RTCPeerConnection as an example of a future "MediaStream source" that's outside the scope of this spec. But we shouldn't be too specific about it's behavior. 104317 3 kiran.guduru 2014-04-24 06:16:10 +0000 I agree with Adam to give the example of a future "MediaStream source". Re-reading the spec, it seems "disabled" should be replaced with "recvonly", instead of extending, as explained below. A disabled track outputs blackness / silence. Since in this case, remote track is disabled, it will any how send blackness / silence to remote end (to its consumer). So receiving end will receive blackness / silence from its (remote) source. But from [1], A MediaStreamTrack is muted when the source is temporarily unable to provide the track with data. If the track is "recvonly", then remote peer will not send any data (even blackness / silence), will be more apt for that example? [1] http://www.w3.org/TR/mediacapture-streams/#life-cycle-and-media-flow 104431 4 adam.bergkvist 2014-04-25 11:23:42 +0000 Back from list discussion. So is the conclusion that we should, for now at least, remove the example all together and simply cut after the first sentence below? A track can also be muted by the user agent. For example, a track that is a member of a MediaStream, received via a RTCPeerConnection [WEBRTC10], is muted if the application on the other side disables the corresponding track in the MediaStream being sent. 104435 5 kiran.guduru 2014-04-25 11:34:17 +0000 Yes, To remove the example, for now, and keep the first sentence. "A track can also be muted by the user agent." 104972 6 adam.bergkvist 2014-05-02 14:08:11 +0000 Proposed fix: https://github.com/fluffy/webrtc-w3c/commit/099c935185e695aab5f78c234c93625099c756a0 105405 7 stefan.lk.hakansson 2014-05-08 08:05:16 +0000 Fixed in http://dev.w3.org/2011/webrtc/editor/archives/20140507/getusermedia.html.