This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25361 - Media Capture and Streams spec should explicitly specify that recvonly streams / tracks should be considered as muted.
Summary: Media Capture and Streams spec should explicitly specify that recvonly stream...
Status: RESOLVED FIXED
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: Media Capture and Streams (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: public-media-capture@w3.org
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-16 04:24 UTC by Kiran
Modified: 2014-05-08 08:05 UTC (History)
3 users (show)

See Also:

Attachments

Description Kiran 2014-04-16 04:24:53 UTC 
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
Comment 1 Stefan Hakansson LK 2014-04-22 11:11:44 UTC 
I think we should not extend the statement, but rather remove it. This kind of info belongs in the WebRTC document IMO.
Comment 2 Adam Bergkvist 2014-04-23 07:24:28 UTC 
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.
Comment 3 Kiran 2014-04-24 06:16:10 UTC 
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
Comment 4 Adam Bergkvist 2014-04-25 11:23:42 UTC 
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.
Comment 5 Kiran 2014-04-25 11:34:17 UTC 
Yes,
To remove the example, for now, and keep the first sentence.

"A track can also be muted by the user agent."
Comment 7 Stefan Hakansson LK 2014-05-08 08:05:16 UTC 
Fixed in http://dev.w3.org/2011/webrtc/editor/archives/20140507/getusermedia.html.