I've created a simple p2p video app but one thing that I cannot think of is how to set up the initiator to be a dynamic value? Here is what I would like to build - one client opens a link, another opens another link, they are both in the same room, because I'm exchanging their offers/answers with socket.io. I would like both parties to be able to call each other and be able to accept/reject the call (like in any other p2p app). Could you please suggest an idea how can it be achieved?
Have you tried making the person who clicks "Make call" be the initiator?
I have tried, but wouldn't be there a race condition if both parties try to call each other? Then I suppose I should track the timestamps and use sockets to exchange in between who was the first initiator, then destroy the other peer and recreate with initiator: false. Or maybe destroy both peers and recreate them both? Not sure, if the signaling would work OK if I destroy only one of them, since the other has signaled already.
Regarding accepting the call, I can only think of two possible scenarios:
In your opinion which is a better approach?
Thanks!
There's a ton of ways to resolve this conflict.
simple-signal assigns unique IDs to every peer, tracks outgoing connections, and ignores conflicting connections from peers with lower IDs. It also attaches unique session IDs to each outgoing message to prevent signalling messages from being mixed between the conflicting connections.
You could also just create two connections and only keep the first one to fire the connect event.
Or have your signalling server filter out conflicting messages.
I don't recommend using timestamps. Clocks between peers will not be synchronized.
@t-mullen Thank you for suggesting simple-signal! I didn't know about it and now life would get easier :) I am closing the issue since this provides answer to my question. Once again thank you!
P.S. It would be great if in the simple-peer readme you add a reference to simple-signal, so that people find a signaling solution easier.
Most helpful comment
There's a ton of ways to resolve this conflict.
simple-signal assigns unique IDs to every peer, tracks outgoing connections, and ignores conflicting connections from peers with lower IDs. It also attaches unique session IDs to each outgoing message to prevent signalling messages from being mixed between the conflicting connections.
You could also just create two connections and only keep the first one to fire the
connectevent.Or have your signalling server filter out conflicting messages.
I don't recommend using timestamps. Clocks between peers will not be synchronized.