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

> I suggest opening a separate issue to challenge the overall pattern.

Sure, I understand that RTCPeerConnection has this behavior.

Other APIs I know of usually resolve or reject promises whenever possible, except in some specific cases, like the page is navigating for instance or the task is still pending.
In this particular case, there is no pending task, so the expectation is to either resolve or reject the promise.

Although this particular RTCPeerConnection is surprising, this issue is a separate issue.

> I believe we're consistent: Outstanding Pomises are left pending on `pc.close()`. [#150 (comment)](

RTCRtpSender is not consistently doing that.
RTCRtpSender.setParameters and RTCRtpSender.getStats are not checking for stopped/closed before resolving/rejecting the promise.

Note also that the PR further ties RTCRtpSender with RTCPeerConnection, which is not great.
It does not align with the idea of being able to create objects like transceivers or data channels directly from an ice connection.

What is the benefit of the PR vs. removing step, or replacing step by rejecting the promise with InvalidStateError?

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

Received on Monday, 25 February 2019 17:58:11 UTC