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

[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:29 +0000
To: public-webrtc-logs@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:


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:34 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:47 UTC