Subject: [rtcweb] Another approach to forking...

From: Harald Alvestrand <[email-masked]>
Date: Fri, 23 Sep 2011 14:58:31 +0200

Just to confuse the forking issue still further:

If the APIs remain as they are today, a JS application that wants to 
support forking can do the following:

- Create a PeerConnection
- Cause it to generate an SDP blob ("SDP OFFER")
- Send that SDP blob out to be forked
- Throw away the PeerConnection
- As the answers come back, for each answer:
   - Create a new PeerConnection
   - Take out the SDP blob, put "SDP OFFER" at the top, and give it to 
the PeerConnection
   - Throw away the generated "SDP ANSWER"

Then connect all the media to output devices as appropriate, and shut 
them down one by one as the application decides that these were not the 
connections that would last.

For extra safety, cause the PeerConnection to do a renegotiation at an 
appropriate time, so that both sides have seen an SDP OFFER/ANSWER 
exchange that actually came from the other side.

It requires a little bit of insight into the SDP offer/answer model, and 
it's a pity to have to resort to string manipulation at any level, but 
.... it doesn't seem anywhere near impossible. Not even particularly 
architecture-breaking.

            Harald

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Sep 2011 13:25:46 +0000

On Sep 23, 2011, at 8:58 AM, Harald Alvestrand wrote:

> If the APIs remain as they are today, a JS application that wants to support forking can do the following:
> 
>  - Take out the SDP blob, put "SDP OFFER" at the top, and give it to the PeerConnection

By this you mean take the answer and make it appear as an offer to PeerConn, right?

>  - Throw away the generated "SDP ANSWER"

But wouldn't the new PeerConn's be creating new ICE ufrag/passwords that won't match the one it created in the original PeerConn's offer, and thus not be able to successfully negotiate ICE with the peer(s)?

And doesn't PeerConn create/allocate the IP:ports used for MediaStreams?  If so, each new PeerConn would also presumably be using a new UDP listen port and break this.

-hadriel

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 23 Sep 2011 15:30:53 +0200

> And doesn't PeerConn create/allocate the IP:ports used for MediaStreams?  If so, each new PeerConn would also presumably be using a new UDP listen port and break this.
Oops. There was something I'd forgotten.

You're right - it won't work unless we create PeerConnections from the 
initial PeerConnection so that they can clone the ICE data and share the 
port.

Back to the drawing board. Thanks!

(in a previous API discussion I suggested a PeerConnectionFactory 
class.... nobody liked it at the time...)

---

From: Randell Jesup <[email-masked]>
Date: Fri, 23 Sep 2011 11:29:33 -0400

On 9/23/2011 8:58 AM, Harald Alvestrand wrote:
> them down one by one as the application decides that these were not 
> the connections that would last.
>
> It requires a little bit of insight into the SDP offer/answer model, 
> and it's a pity to have to resort to string manipulation at any level, 
> but .... it doesn't seem anywhere near impossible. Not even 
> particularly architecture-breaking.

Evil (kinda), but effective in practice.  I'd prefer the ability to effectively 'clone'
a PeerConnection object on receipt of (another) speculative answer (see my earlier
proposal), removing the need to play games like above.  This requires keeping in the
PeerConnection any necessary state to reproduce the necessary object state on a new
speculative (or final) answer.  Seems fairly straightforward.  Alternatively you
could use a model where an offer was done via a PeerConnectionOffer object, and on a
(speculative or final) answer a connected PeerConnection object is produced by it.
When the app is done and has decided "no more forks accepted" (for example on an ACCEPT
per my proposal), it would kill the PeerConnectionOffer and any PeerConnections it didn't
want to keep.  This is a bit 'cleaner' an API in my mind than just PeerConnections with
some sort of fork/clone method, but that's minor and a personal preference.

-- 
Randell Jesup
[email-masked]