- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 May 2017 08:40:46 +0000
- To: public-webrtc-logs@w3.org
fippo has just created a new issue for https://github.com/w3c/webrtc-pc: == processing remote MediaStreamTracks -- stopping the transceiver to reject them == question about http://w3c.github.io/webrtc-pc/#processing-remote-mediastreamtracks The first sentence says > An application can reject incoming MediaStreamTrack objects by calling RTCRtpTransceiver.stop(). While this does not explain what it means to "reject an incoming track" (editorial concern; I searched all instances of reject and found only promise rejections) this seems to be a leftover of a very old design pattern. Once upon a time there was a similar pattern for onaddstream. I always thought this to require that rejection a track this way has to be done in SRD. Which necessitated that the onaddstream event fires synchronously during SRD. It works that way in Firefox but when I filed a Chrome bug it was pointed out (thanks @jan-ivar) that at least the current spec we have http://w3c.github.io/webrtc-pc/#processing-remote-mediastreamtracks which says "Queue a task to fire an event". This design pattern will still work but the track will only be stopped when creating an answer. Is this sentence the only description of this design pattern? This needs a bit more explanation. There has been quite some discussion in the past, see e.g #898 Also, calling stop on the transceiver will stop the entire transceiver, not just reject the remote track. So when doing this you probably end up not with what you expect: ``` let pc = ... pc.addTrack(localVideoTrack, stream) pc.setRemoteDescription(videosdp) call transceiver.stop() pc.createAnswer ``` which will not send video. While this would (probably, I am still trying to understand them) create a new transceiver: ``` let pc = ... pc.setRemoteDescription(videosdp) call transceiver.stop() pc.addTrack(localVideoTrack, stream) pc.createAnswer ``` note that the answer probably won't contain the local track either since that is a new transceiver and it will require an additional ONN + createOffer. Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1246 using your GitHub account
Received on Thursday, 25 May 2017 08:40:52 UTC