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:
User A (call initiator):
{ audio: true, video: false }{ initiator: true, trickle: true, stream: MediaStream*}User B (call receiver):
{ audio: true, video: true }{ initiator: false, trickle: true, stream: MediaStream*}*MediaStream object is coming from navigator.mediaDevices.getUserMedia(MediaStreamConstraints)
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
I forgot to mention that simple-peer version is 9.1.2
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
If you're using addStream, you need to use the setConstraints method in a similar way.
If you aren't getting the connect event, there might be a different issue. Can you confirm you're getting the connect event but just missing streams?
I'm not getting the connect event in this test case only.
I'm going to check if specifying offerConstraints change this behaviour
I have just tested specifying offerConstraints, the SDP is changed properly according to offerConstraints but connection can't be established between the two peers.
I'm still getting the same log messages where the call initiator waits at "already negotiating, queueing +0ms".
I confirm that in the other tests cases I get the connect event
Sorry small typo in the above code. You should specify offerConstraints for the initiator, but answerConstraints for the initiator.
If you don't get the connect event for the 4th test case, then there is another issue here. I'll try to reproduce.
The problem persists
I noticed the signal event was emitted in User A's logs, but there is no call to signal() on User B. Are the logs incomplete, or is signal() not being called on User B?
I'm not able to reproduce with stable or current source: https://codepen.io/anon/pen/GYvYja?editors=0010
Is there anything different between this example and your application? (It turns out constraints are not necessary as long as there is at least one media track.)
I will recreate my case on codepen, unfortunately it may take some time so I'll let you know for any updates
I'm sorry to have wasted your time, the problem was in my wrong implementation.
Thank you very much for your availability, I'm closing this "issue"
I have a question, would you accept a future pull request containing a TypeScript definition file?
My project uses TypeScript and the types definitions that I've found are outdated
Good to hear you’ve figured it out.
Typescript types should probably be provided to “Definitely Typed”.
I found t-mullen's video-stream-merger approach better than renegotiation.