Re: [rtcweb] Proposal for PeerConnection cloning

"Ejzak, Richard P (Richard)" <> Tue, 08 May 2012 02:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFBF621F8631 for <>; Mon, 7 May 2012 19:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.232
X-Spam-Status: No, score=-7.232 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C0L79LxTJZXV for <>; Mon, 7 May 2012 19:10:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3AFEC21F8615 for <>; Mon, 7 May 2012 19:10:59 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id q482Aw6c012317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Mon, 7 May 2012 21:10:58 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id q482AvaO023131 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <>; Mon, 7 May 2012 21:10:58 -0500
Received: from ([]) by ([]) with mapi; Mon, 7 May 2012 21:10:58 -0500
From: "Ejzak, Richard P (Richard)" <>
To: "" <>
Date: Mon, 07 May 2012 21:10:56 -0500
Thread-Topic: [rtcweb] Proposal for PeerConnection cloning
Thread-Index: Ac0suwWDStY/ZEhsRMKulO5M+p1c7AAASEbQ
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0881USNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
Subject: Re: [rtcweb] Proposal for PeerConnection cloning
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 May 2012 02:11:00 -0000

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?


From: Roman Shpount []
Sent: Monday, May 07, 2012 8:37 PM
To: Ejzak, Richard P (Richard)
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