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

@youennf I believe you're arguing for less blocking. This issue and PR result in less blocking, so I'm not hearing an argument against merging this.

We should be consistent, and this PR merely aligns with our existing pattern (removing unintended blocking). This isn't theoretical, as we're fixing our Firefox code right now, and would like to merge this spec support to avoid blocking on `stop()`. I suggest opening a separate issue to challenge the overall pattern.

> That may leave code to be hanging forever due to some timing issues.

FWIW I think it's inaccurate to characterize the absence of a callback as "hanging".

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

Received on Tuesday, 19 February 2019 18:45:00 UTC