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

[Hadriel Kaplan <[e-mail]>]

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

> 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

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