Re: [rtcweb] Proposal for PeerConnection cloning

["Ejzak, Richard P (Richard)" <[e-mail]>]

You raise a good point since some candidates may be released before cloning occurs.  So this is another bug in the procedure.  I would suggest that the configuration also be passed to the CPC and that if any of the required candidates are released before cloning occurs that they be reallocated.

Alternately, we could recommend that candidates be kept allocated longer than usual and that if cloning is attempted after any of the candidates are released then the cloning procedure fails.

The latter approach should be sufficient for SIP forking scenarios, but others may prefer the generality of the former.  Or maybe both?  Any votes?

Richard

________________________________
From: Roman Shpount [mailto:[e-mail]]
Sent: Monday, May 07, 2012 8:37 PM
To: Ejzak, Richard P (Richard)
Cc: [e-mail]
Subject: Re: [rtcweb] Proposal for PeerConnection cloning

One question I have is when should TURN allocations be released? TURN would not be used for 99% of PeerConnections but it cannot be released until it is guaranteed that the offer that used this TURN candidate would not be used to create any more PeerConnections. We would need a separate method to release the TURN candidates, which can be complicated by the fact that you can have several offers for a given peerconnection in progress, each with its own TURN candidates that can have overlapping lifetimes.

I would actually think that the model where an offer object is created and each PeerConnection is created  using the offer object and the answer would be cleaner.

One way to implement this, is to define a factory object is used to create offers. SDP is extracted from an offer object. Once answer is received, a method in the offer object is used to create the PeerConnection. Once no more answers are expected offer object should be released.

The other option, that would be less disruptive to the curretn API,  is that instead of cloning peerconnection method, a method that returns reference to the current offer is used. A cloned peerconnection can be created using this offer. Once final answer is processed by the peerconnection, offer object is released by it. If multiple answers are expected, offer object can be retrieved using the get offer method and stored separately until the moment when answers for this particular offer a no longer expected.
_____________
Roman Shpount