Re: [webrtc-pc] Add reject() + make stop() safe. New stopping state affects createOffer only. (#2220)

@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