[webrtc-pc] Pull Request: Add stopping state (transceiver.stop() queues to stable). Rename old unsafe stop to reject()

• From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
• Date: Tue, 09 Apr 2019 21:21:30 +0000
• To: public-webrtc@w3.org
• Message-ID: <pull_request.opened-268929786-1554844888-sysbot+gh@w3.org>

jan-ivar has just submitted a new pull request for https://github.com/w3c/webrtc-pc:

== Add stopping state (transceiver.stop() queues to stable). Rename old unsafe stop to reject() ==
Fixes https://github.com/w3c/webrtc-pc/issues/2150.

I had to scrap my initial thoughts of modeling a `currentlyStopped` state after `currentDirection`.

After reading JSEP, I realized we have no shot of altering its definition of ***stopped*** without major pain. So I left it alone and added a *webrtc-pc*-only ***stopping*** one instead:

![stopping](https://user-images.githubusercontent.com/3136226/55832984-bbb8bb00-5ae4-11e9-877b-b37ef46f4669.png)

The other difference I realized from `currentDirection` is that `stopped` is an *input* to negotiation, not a result from it, so it needs to happen ahead of it. I put it in the queued task that fires *negotiationneeded*. This ends up working whether people rely on the event to negotiate or not.

This PR is best explained though a mental detour:
 1. First define a new `stableStop()` method that sets this new `stopping` attribute.
 2. Then rename that `stableStop()` to `stop()`, and rename the old hazardous `stop()` to `reject()`.

Net result: A `stop()` safe to call regardless of state, designed to miss the danger window of `"have-remote-offer"`—instead landing in "stable", where a subsequent negotiation will pick it up, handling BUNDLE optimally.

Pros with safety glasses may use `reject()` to reject m-lines in `"have-remote-offer"`.


See https://github.com/w3c/webrtc-pc/pull/2168

Received on Tuesday, 9 April 2019 21:21:31 UTC