- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 16 Apr 2014 05:48:53 +0000
- To: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 16/04/14 06:25, bugzilla@jessica.w3.org wrote: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25361 > > Bug ID: 25361 > Summary: Media Capture and Streams spec should explicitly > specify that recvonly streams / tracks should be > considered as muted. > Product: WebRTC Working Group > Version: unspecified > Hardware: All > OS: All > Status: NEW > Severity: normal > Priority: P2 > Component: Media Capture and Streams > Assignee: public-media-capture@w3.org > Reporter: kiran.guduru@samsung.com > CC: public-media-capture@w3.org > > 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." I have a different view: I think we should remove this part completely from the spec, everything that has to do with PeerConnection and SDP and so on should be documented in the WebRTC draft. That makes it more modular, and in addition makes the addition of a future, SDP free, API for sending streams/tracks over the net cleaner. > > [1] http://www.w3.org/TR/mediacapture-streams/#life-cycle-and-media-flow >
Received on Wednesday, 16 April 2014 05:49:19 UTC