Re: [rtcweb] Proposal for PeerConnection cloning

Martin Thomson <> Tue, 08 May 2012 15:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08ACE21F8655 for <>; Tue, 8 May 2012 08:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.745
X-Spam-Status: No, score=-3.745 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lo1qFVbaSqsW for <>; Tue, 8 May 2012 08:49:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4A35E21F8652 for <>; Tue, 8 May 2012 08:49:04 -0700 (PDT)
Received: by bkty8 with SMTP id y8so5737980bkt.31 for <>; Tue, 08 May 2012 08:49:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yiLg4eG35cUWM/IDzHwLzxBkB6ZkYvz9Yg3lno6kM5w=; b=pybtEl117piN+VtsV1GoKSgmfH1zZqUDIHRF7gmUcqIf/aZ1FpwcaWxa92F41G4T7k RpyswZWuIDxYNQJW/dSdS+rh6gmNLj/VGaUurv2hgx59egoOCgMBh0WgYfx3OqJxzFcQ AMEuvKl3tSdah4cxdo62TFaEE6VOHzj/lX3N5YNNEZIAUKegu0K1PxJyWstBqZ+0069Q fTUkX7I+G4Hw9o11MC/P8lsIHD22eJhEhJ+0Pb+yNjLaM9NjMarmR02dGDqgcG9WNjIH Ko6h31vi4XjH9EqCsbznAL0dFbI98W4ZRvmRDwi5ZmFWq3234ea14yud0uFE9tq8E4O6 DZrw==
MIME-Version: 1.0
Received: by with SMTP id f9mr7343180bkw.3.1336492143345; Tue, 08 May 2012 08:49:03 -0700 (PDT)
Received: by with HTTP; Tue, 8 May 2012 08:49:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Tue, 08 May 2012 08:49:03 -0700
Message-ID: <>
From: Martin Thomson <>
To: "Ejzak, Richard P (Richard)" <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
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 15:49:05 -0000

On 7 May 2012 19:10, Ejzak, Richard P (Richard)
<> wrote:
> 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.

Releasing a TURN candidate is a real possibility.  The same could
apply to local candidates (and server reflexive), though that will
depend on implementation.  Getting the same one back is unlikely for
TURN, though it might be possible for local.

In all these cases, answers that arrive late will fail.

> 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.

I'd be against making any such recommendation for browser
implementations.  The signaling application is more likely to know
best in this scenario.  In that case, it can make the call to hold
candidates open.  PR_ANSWER seems to have the right semantics.