- From: Andreas Pehrson via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Nov 2016 12:14:52 +0000
- To: public-webrtc@w3.org
Pehrsons has just created a new issue for https://github.com/w3c/webrtc-pc: == Does RTCRtpReceiver.track.stop() reject the track? == In [**5.1.1 Processing Remote MediaStreamTracks**](https://w3c.github.io/webrtc-pc/archives/20160913/webrtc.html#processing-remote-mediastreamtracks) it says _Rejection of incoming MediaStreamTrack objects can be done by the application, after receiving the track, by stopping it._ It doesn't define _Rejection_, but I'll just assume for now it involves talking to the RTCPeerConnection. However, [pull request 662](https://github.com/w3c/webrtc-pc/pull/662) added the text _Since `track.stop()` does not implicitly call `RTCRtpReceiver.stop()`, Receiver Reports continue to be sent._ which indicates that no rejection takes place on track.stop(), but rather on receiver.stop(). Though there is no `RTCRtpReceiver.stop()`, so I'll assume for now that it refers to `RTCRtpTransceiver.stop()`, but that again makes it even less clear. I need clarification on what stopping a received MediaStreamTrack does, and how one rejects a received track. These questions came up while implementing `MediaStreamTrack.stop()` for received tracks in Firefox. See [bug 1301675](https://bugzilla.mozilla.org/show_bug.cgi?id=1301675). Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/898 using your GitHub account
Received on Tuesday, 1 November 2016 12:14:59 UTC