Create renegotiation method

[cusspvz]

This should allow us to:

• expose method to add streams .addStream expose addStream on prototype #50
• allow mutes and video interruption on the source side

@feross has any work been initiated regarding renegotiation?

[feross]

How do you propose this would work? Can you provide a complete code example and explain a bit more?

[cusspvz]

@feross sorry for my late response, had to switch priorities. I've written a renegotiation capable software two years ago, but I cannot recall how it worked, have to dig in.
I've already read your codebase, and I have two ideas for an implementation but I have to test the first one, because I don't know if it would work:

• The first one is trying to re-use the same PeerConnection, by handling streams on it and creating offers and answers as soon as we spot a renegotiation is needed, which I think is impossible but is worth to try, and if we have success, it would be the easiest implementation.
• The second one is to abstract PeerConnection interface from your current API, this way we could refactor some code and fix some bugs you had (related with stream destroying) without causing Breaking Changes on your current API design. This way there would be two main classes:
  • SimplePeer
    • Streamable Passthrough from the currentPeerConnection;
    • PeerConnections Manager (handling renegotiations against streaming changes and long-reconnecting delays);
    • Signalling transporter gate from all PeerConnections (so we can initiate new ones before having data flowing through)
  • PeerConnection
    • Streamable implementation of PeerConnection with friendly bindings;

[cusspvz]

On the second approach, I think it could be a good Idea to have separated PeerConnections for different streams, it would make renegotiation easier.

[feross]

@cusspvz Thanks for explaining your thoughts.

My concern is that this all sounds really complicated. If there's no way to do this simply using the same RTCPeerConnection, then I don't think this belongs in simple-peer. We can try to expose the right events so that this can be built as a layer on top of simple-peer.

[cusspvz]

Yeah, I admit the second one seems a little tricky to implement, besides, its complexity doesn't go well along with this repo's purpose...

I think I can write out some tests and start playing along with the first approach until the end of this week.

[feross]

@cusspvz Sounds good. Happy to check out what you come up with!

[cusspvz]

Already PR'ed some changes! :)
Seems the first approach worked, the only issue I'm having is related with firefox and I think it is because of testing with fake MediaStreams, but I have to dig a little bit more to have sure.

Unfortunately I'm running out of time to work on it today, I can only finish this up on Monday.

[matthieusieben]

FireFox does not support more than one stream in their P2P connection (inbound or outbound). The problem with this is that it is simple to limit the number of streams on an instance in ff (if(isFF && streams.length > 0) throw new Error()), but it is much more complicated to handle the case when a chrome browser sends two or more streams. In that case, the renegotiation will fail (due to the differences in the way ff and chrome express multi stream connections). This will typically require to 1) detect that the remote peer is FF 2) potentially create a new peerconnection

[ben-pr-p]

So what's the recommended way to mute / add video after the fact? Should I be creating a new Peer object on both clients?

[gnazarkin]

@ben-pr-p I'm closing and recreating the connections. It works but having problem with one use case where the initiator isn't broadcasting a stream, but only aims to receive it. Since the stream isn't set to anything it seems that even if the other party sends over the stream, the "on" stream event never gets called. I also enable/disable the local tracks using something like

localStream.getAudioTracks()[0].enabled = false;
localStream.getVideoTracks()[0].enabled = false;

[ben-pr-p]

I've been using audioOrVideoTrack.enabled = false as well – the only downside is that it means I'm asking for audio and video initially even if they're only going to use audio.

[gnazarkin]

@ben-pr-p What I'm doing as a workaround is closing the connections and re-creating them. So I don't have to ask for all of them upfront. Only problem with this solution is that it seems the initiator has to have a stream, if not then the "on" stream event doesn't fire so you don't end up receiving any of the streams from the other peers

[t-mullen]

@gnazarkin See #95 for a workaround to that issue.

[cusspvz]

Being solved at #250

[t-mullen]

Implemented in #250.