- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Jun 2019 21:10:38 +0000
- To: public-webrtc-logs@w3.org
@henbos This is based on what we discussed. PTAL. In short, the PR creates a new `tc.stopping` sibling to `tc.stopped`. The former only affects `createOffer`, not `createAnswer`, sidestepping https://github.com/w3c/webrtc-pc/issues/2150. The `stop()` method now sets `stopping` instead of `stopped`, but otherwise works as before locally, and `setRemoteDescription(answer)` transitions it to `stopped`, basically. Renamed old dangerous stop to `reject()`; made it work only in `"have-remote-offer"`, solving https://github.com/w3c/webrtc-pc/issues/2176. I had to audit existing places the spec reads `[[Stopped]]`, to see which should be `[[Stopping]]` instead. Very few it turned out, mostly high-level modification APIs like `addTrack`. Stop reading now if you don't care about edge cases... The good news is that the [setting an RTCSessionDescription](http://w3c.github.io/webrtc-pc/#set-description) algorithm did not look at `[[Stopped]]` much. I found two places, but they seem like optimizations, and one may even be a bug. I'll file a separate issue. This means most of our negotiation event firing code already runs on stopped transceivers today, something I verified in Firefox with [this fiddle](https://jsfiddle.net/jib1/gzn9f20k/). That may sound bad, but is actually quite orthogonal and seems benign to me, since it's basically shuffling around `ended` tracks at that point. This was informative to figure out how a peer should react to incoming offers/answers in the new `stopping` state: For example: an edge-case is where a fixed-role answerer may end up staying in `stopping` state for a while, because things like `tc.stop()` and `pc.addTrack` won't automatically be negotiated (requires out-of-band-signaling to the fixed-role offerer). So it sits until negotiation comes from the other end, because it's never the offerer. In this case, events may still fire from incoming non-stopped offers, except on the `transceiver.receiver.track` itself which has been `ended` synchronously already by `stop()`, like today. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2220#issuecomment-506877986 using your GitHub account
Received on Friday, 28 June 2019 21:10:40 UTC