Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Two peers sending video/audio leads to immediate renegotiation #670

Closed
feross opened this issue Jun 2, 2020 · 4 comments · Fixed by #722
Closed

Two peers sending video/audio leads to immediate renegotiation #670

feross opened this issue Jun 2, 2020 · 4 comments · Fixed by #722
Labels

Comments

@feross
Copy link
Owner

feross commented Jun 2, 2020

Using simple-peer in a relatively simple setup. Seeing the non-initiator peer immediately request renegotiation even though everything is specified upfront in the constructor. I see two offer/answers sent from the initiator peer.

Here's my setup: Two peers, each initialized with the stream option, so addTrack() is called twice (once for video, once for audio) internally in the constructor. For the non-initiator peer, this._isNegotiating is already true because of this line in the constructor:

this._isNegotiating = this.negotiated ? false : !this.initiator // is this peer waiting for negotiation to complete?

Therefore, for the non-initiator peer, the calls to this._needsNegotiation() in response to addTrack() cause a negotiation to be immediately queued. Once the connection is stable it triggers the re-negotiation.

Is this intentional?

@feross
Copy link
Owner Author

feross commented Jun 2, 2020

I have a draft PR that fixes the problem, but in a hacky way: #671

Thoughts?

@nazar-pc
Copy link
Collaborator

nazar-pc commented Jun 2, 2020

I agree, it seems to be a bit wrong. I'd expect renegotiation to not be triggered before the first offer was received and answer for it was generated. It is just pointless in this case.

@t-mullen
Copy link
Collaborator

t-mullen commented Aug 8, 2020

I've implemented a fix for this in #722, with tests and more debugging logs.

The causes were multiple:

  • Add support for negotiated channels. #570 changed the initial value of _isNegotiating to use the channelConfig.negotiated option (whether the datachannel is negotiated isn't relevant to the negotiation of the peer).
  • _firstStable was set in the wrong place.
  • The entire approach of dropping the non-initiator's 1st queued renegotiation request on first stable is wrong - this may be a valid request if we add a track right after creating an answer. What we actually want to do is start negotiation on both peers and immediately discard the non-initiator's 1st batched negotiation (since we know the initiator will negotiate). This was an unlikely race condition, but I've fixed it anyways.

t-mullen added a commit to t-mullen/simple-peer that referenced this issue Aug 8, 2020
momakes3 added a commit to thereteam/simple-peer that referenced this issue Aug 9, 2020
@t-mullen t-mullen added bug and removed question labels Aug 9, 2020
@feross
Copy link
Owner Author

feross commented Oct 28, 2020

Released as 9.8.0

FredZeng pushed a commit to FredZeng/simple-peer that referenced this issue Oct 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants