W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2019

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

From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
Date: Tue, 19 Feb 2019 19:53:43 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-465285053-1550606022-sysbot+gh@w3.org>
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 https://github.com/w3c/webrtc-pc/issues/2106#issuecomment-465285053 using your GitHub account
Received on Tuesday, 19 February 2019 19:53:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:55 UTC