Re: [rtcweb] When are ICE candidates added to the SDP

Cullen Jennings <fluffy@iii.ca> Sat, 17 May 2014 21:06 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA9B1A0208 for <rtcweb@ietfa.amsl.com>; Sat, 17 May 2014 14:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpZxe5XgK6yE for <rtcweb@ietfa.amsl.com>; Sat, 17 May 2014 14:06:07 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A847C1A017C for <rtcweb@ietf.org>; Sat, 17 May 2014 14:06:06 -0700 (PDT)
Received: from sjc-vpn7-167.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D031C22E253; Sat, 17 May 2014 17:06:04 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CABcZeBNUTf42tS9FrjS9Q6Zk8LBkhpKOR1z2v8MHoeNEUf93Mw@mail.gmail.com>
Date: Sat, 17 May 2014 13:19:04 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <804DCB7A-9D65-4438-82C7-1A553905984B@iii.ca>
References: <CABcZeBNUTf42tS9FrjS9Q6Zk8LBkhpKOR1z2v8MHoeNEUf93Mw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/K9WzHVyd0RXbM8Kv1qo0NyIuVm8
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] When are ICE candidates added to the SDP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 May 2014 21:06:09 -0000

On May 11, 2014, at 6:51 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> However, we agreed in London that we would do "always trickle", and
> that even if there were candidates available at the time when CreateOffer
> (because of candidate pooling) was called, they would not be included
> in the initial offer.

Hmm - did we agree they would not be there or they might not be there? 

Either way, I think that things will work better if we can provide whatever information we have available at the time the  call returns. So my preference would be that if they are in the pool, they are returned as early as possible. I can not really see any good reasons for delaying the return of the candidates that are available.  Even when you are doing trickily ICE, this is going to result in less round trips of “trickle” and result in closer synchronization of the connectivity checks from both sides for the candidates that are returned in the first offer. That will help up the success rate of trickle ICE.