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

> > I believe we're consistent: Outstanding Pomises are left pending on `pc.close()`.
> RTCRtpSender is not consistently doing that.

Sorry, I should have said consistent with the other methods using the [peer connection queue](

> RTCRtpSender.setParameters and RTCRtpSender.getStats are not checking for stopped/closed before resolving/rejecting the promise.

*getStats* is specifically allowed on closed peer connections.

*setParameters* is not enqueued, and is not allowed to fail with `InvalidStateError`, so I'd assume it succeeds, which seems benign enough.

> Note also that the PR further ties RTCRtpSender with RTCPeerConnection, which is not great.

That ship has sailed I think: *replaceTrack* is enqueued on the peer connection queue, for reasons.

> It does not align with the idea of being able to create objects like transceivers or data channels directly from an ice connection.

You can't do that today. We would need to spec that, but I think we're getting ahead of ourselves.

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

Consistency with the other enqueued methods. Having `transceiver.stop()` cause outstanding *replaceTrack* promises to reject with `InvalidStateError` would be novel. I'm not hearing support for that.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at using your GitHub account

Received on Monday, 25 February 2019 22:41:41 UTC