Re: [webrtc-pc] transceiver.stop() shouldn't block in-progress replaceTrack from succeeding (#2106)

Agree that the promise should be rejected or resolved. However, we don't seem to have been consistent with respect to this throughout the specification. 

For example, several of the "If connection's [[IsClosed]] slot is true, then abort these steps." instances would appear to result in a promise never being rejected or resolved.  An example is `addIceCandidate`.  Was this what we really intended? 

Note that Step 6 sub-step 1 already tests if `transceiver` has been stopped, and rejects the promise if it has. Would it make more sense for `replaceTrack` to reject the promise if it discovers a closed `RTCPeerConnection` or `transceiver` later? 

GitHub Notification of comment by aboba
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 19 February 2019 19:53:45 UTC