Re: [MMUSIC] Trickle ICE and frozen candidates

Emil Ivov <> Sat, 13 July 2013 00:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1DC811E8146 for <>; Fri, 12 Jul 2013 17:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.288
X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 07hhB37ZwlHP for <>; Fri, 12 Jul 2013 17:15:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6AD8C11E8144 for <>; Fri, 12 Jul 2013 17:15:36 -0700 (PDT)
Received: by with SMTP id k10so1221517wiv.7 for <>; Fri, 12 Jul 2013 17:15:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=H/8NK5s+x241j2TOd6Cr1Tn+6JKnRPOHCPAqVb2qbNY=; b=NBJ5ZiGBWYDpv6vH5oMrPgn4rep/blz2ng9dKpRpZfjlYY3S/QrvpSCu9TvH6RNNq/ th9WA3TcptD9cNk1ceXmlXXXl6aXN3Ls4hAB7Z8UxM2cJpHjUlsm1uqa9qMleZScX03/ rLGo4+6yMXDM3PmBvRdYy6+zubOb+OB40TzflXUyXR6vU72sFSdO48AoE8VV1+lqNBfG 9KBjkoDIbhXDUCVhcJeUn8zVA3U0Sp7MjM2/UD9to27VWOaH69aV7reYALDHL+K8zz1d R7ksup6q1m3OVAMeDJjqf6K97sZ6+2aHGQvIl4idSR9FZqOQaJ3DVuCOW8bRoptcQoNB PjMQ==
X-Received: by with SMTP id xk16mr2930866wib.62.1373674534240; Fri, 12 Jul 2013 17:15:34 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:38e6:8f85:a1df:fc5b]) by with ESMTPSA id f8sm5863886wiv.0.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 17:15:32 -0700 (PDT)
Message-ID: <>
Date: Sat, 13 Jul 2013 02:15:26 +0200
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Martin Thomson <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnt9i1TH/qXlWIGf2BLtGotZorKz3/6Kyu9ajB1CbiewuZ5mSfT8DhGJB3P2n0ZW0JWqQLb
Subject: Re: [MMUSIC] Trickle ICE and frozen candidates
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Jul 2013 00:15:41 -0000

Hey Martin, all,

On 10.07.13, 18:50, Martin Thomson wrote:
> On 9 July 2013 18:58, Emil Ivov <> wrote:
>> OK. Do you mean something like 2. or do you have another mechanism in mind?
> I don't have any particular mechanism in mind, though 2 might be
> workable (I initially read "priority" there, which isn't quite right,
> I think that you mean something like "preference order", since it's
> the component ordering that would matter).

Yes and the idea was that component ordering is generally the only thing 
that would influence "priority" within a single foundation. That said, I 
agree there's no reason not to say this directly.

So to summarize. The algorithm would look like this:

We start by unfreezing the first available pair for a foundation. Any 
new pairs would be:

a) automatically unfrozen if they belong to a component that precedes 
that of an unfrozen pair.

b) automatically unfrozen if other checks in that foundation already 

c) kept frozen and then handled by regular 5245 unfreezing if they 
belong to components that come after the last currently unfrozen but not 
yet completed check

d) kept frozen if checks for unfrozen pairs in this same foundation have 
already failed.

Obviously "d" is kind of murky. We need it in order for the freezing 
algorithm to have any sense but it could still lead to race conditions 
and premature failures.

So, at least now this doesn't seem like a great way to go forward.

Therefore, it seems to me that the only way to keep "freezing" is to 
mandate that candidates be trickled by component order. This way we 
would be able to pretty much reuse the vanilla ICE algorithm.