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

[Randell Jesup <[e-mail]>]

On 9/23/2011 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
>   - 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.

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
[e-mail]