simple-peer: Peer stuck at renegotiation

I’m testing different configurations of the MediaStreamConstraints object to represent most common types of calls and I have encountered a problem, these are my tests cases:

Initiator (User A) initiates an audio/video call to the other peer (User B) which answers with both audio and video (Connection established properly)
Initiator (User A) initiates an audio/video call to the other peer (User B) which answers with audio only (Connection established properly)
Initiator (User A) initiates an audio call to the other peer (User B) which answers with audio only (Connection established properly)
Initiator (User A) initiates an audio call to the other peer (User B) which answers with both audio and video (Connection NOT established)

In depth configs

User A (call initiator):

MediaStreamConstraints object: { audio: true, video: false }
SimplePeer options: { initiator: true, trickle: true, stream: MediaStream* }

User B (call receiver):

MediaStreamConstraints object: { audio: true, video: true }
SimplePeer options: { initiator: false, trickle: true, stream: MediaStream* }

*MediaStream object is coming from navigator.mediaDevices.getUserMedia(MediaStreamConstraints)

simple-peer logs

User A (call initiator):

simple-peer 2018-11-01T11:53:03.657Z [0023854] new peer {initiator: true, trickle: true, stream: MediaStream} +0ms
simple-peer 2018-11-01T11:53:03.661Z [0023854] addStream() +4ms
simple-peer 2018-11-01T11:53:03.662Z [0023854] addTrack() +1ms
simple-peer 2018-11-01T11:53:03.662Z [0023854] _needsNegotiation +0ms
simple-peer 2018-11-01T11:53:03.662Z [0023854] _needsNegotiation +0ms
simple-peer 2018-11-01T11:53:03.665Z [0023854] starting batched negotiation +3ms
simple-peer 2018-11-01T11:53:03.666Z [0023854] start negotiation +1ms
simple-peer 2018-11-01T11:53:03.671Z [0023854] signalingStateChange have-local-offer +5ms
simple-peer 2018-11-01T11:53:03.671Z [0023854] createOffer success +0ms
simple-peer 2018-11-01T11:53:03.672Z [0023854] signal +1ms
simple-peer 2018-11-01T11:53:03.672Z [0023854] iceStateChange (connection: new) (gathering: gathering) +0ms
simple-peer 2018-11-01T11:53:03.775Z [0023854] iceStateChange (connection: new) (gathering: complete) +103ms
simple-peer 2018-11-01T11:53:04.080Z [0023854] signal() +305ms
simple-peer 2018-11-01T11:53:04.080Z [0023854] got request to renegotiate +0ms
simple-peer 2018-11-01T11:53:04.080Z [0023854] _needsNegotiation +0ms
simple-peer 2018-11-01T11:53:04.083Z [0023854] starting batched negotiation +3ms
simple-peer 2018-11-01T11:53:04.083Z [0023854] already negotiating, queueing +0ms

User B (call receiver):

simple-peer 2018-11-01T11:53:04.000Z [2e33650] new peer {initiator: false, trickle: true, stream: MediaStream} +0ms
simple-peer 2018-11-01T11:53:04.003Z [2e33650] addStream() +3ms
simple-peer 2018-11-01T11:53:04.004Z [2e33650] addTrack() +1ms
simple-peer 2018-11-01T11:53:04.005Z [2e33650] _needsNegotiation +1ms
simple-peer 2018-11-01T11:53:04.005Z [2e33650] addTrack() +0ms
simple-peer 2018-11-01T11:53:04.007Z [2e33650] _needsNegotiation +2ms
simple-peer 2018-11-01T11:53:04.009Z [2e33650] starting batched negotiation +2ms
simple-peer 2018-11-01T11:53:04.010Z [2e33650] requesting negotiation from initiator +1ms

Is it possible that the problem lies in negotiation queueing? P.S. I waited for 10 minutes after the last log message and nothing happened

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 15

Most upvoted comments

Good to hear you’ve figured it out.

Typescript types should probably be provided to “Definitely Typed”.

t-mullen on Nov 2, 2018

If an non-initiator provides a type of media track that the initiator does not (eg initiator provides audio, non-initiator provides audio+video), then you need to explicitly specify SDP constraints.

var peer = new Peer({
  initiator: true,
  stream: audioOnlyStream,
  offerConstraints: {
    offerToReceiveAudio: true,
    offerToReceiveVideo: true
  }
})

var peer = new Peer({
  initiator: false,
  stream: audioAndVideoStream,
  answerConstraints: {
    offerToReceiveAudio: true,
    offerToReceiveVideo: false // <--
  }
})

This is due to a browser bug we aren’t able to fix in simple-peer. See #95

t-mullen on Nov 1, 2018