- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Apr 2018 17:16:48 +0000
- To: public-webrtc-logs@w3.org
> Yes. The intent is that there should be no observable difference between setRemoteDescription(rejected_sendrecv_answer) and setRemoteDescription(rejected_inactive_answer). Is there high value in that? Today, a pc has discrete control over what happens on the remote end. E.g. if the app wants to remotely remove tracks on stop, it can do that easily: ```js transceiver.direction = "inactive"; transceiver.stop(); ``` Also, note that peer connections only remove tracks from streams it itself manages, so if apps do: ```js video.srcObject = new MediaStream([transceiver. receiver.track]); ``` then we don't remove tracks from video.srcObject, so there's no panacea against JS having to deal with ended tracks. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1845#issuecomment-384719900 using your GitHub account
Received on Thursday, 26 April 2018 17:16:53 UTC