Re: [MMUSIC] Trickle ICE and frozen candidates

Emil Ivov <> Wed, 10 July 2013 01:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0121611E80F4 for <>; Tue, 9 Jul 2013 18:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UeWeocTd+Fxt for <>; Tue, 9 Jul 2013 18:58:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 063E011E80EF for <>; Tue, 9 Jul 2013 18:58:30 -0700 (PDT)
Received: by with SMTP id p60so5434624wes.27 for <>; Tue, 09 Jul 2013 18:58:30 -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=Q9TRfyvpn8pRtOziPfGPumCbLZgW6Y3nXi5kySZzAHI=; b=Iy4HM7LN99WxxA/tRmnwa3M3z14qQcenho1ZRsPSosdmuKbhTt47cHwPH8NnSzM1YU ddznykguogU67zStKVXW2xOPbNyEj5DUXXtMCbWbOfma5m8/yy3i2SCP2MljTDE0iKKu h5IoHFWz/G5vj4sHXLd4bi7+YuzOWyQIi3t+zGL30fG+QkY2lMZJtIIfB4nqKOPRlzvU 1iv0P3IAkH7YWfmO7i90IhErLxwbzQPbUCf/gdg3oa5PlFBU8WnykfbZyn0yAXyupv75 7LHw19tpQ7hAwYt7Q2z06qiuE85FG2H7Y5Tsl+ufSuAfWeHyyCPXbYnVfuGqA1YooWGl WKNQ==
X-Received: by with SMTP id bu9mr15804983wib.32.1373421510024; Tue, 09 Jul 2013 18:58:30 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:2403:2255:f094:fc64]) by with ESMTPSA id x2sm20450563wif.3.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 18:58:29 -0700 (PDT)
Message-ID: <>
Date: Wed, 10 Jul 2013 03:58: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: ALoCoQnJkwgR4VSWzs/GrUzPZX65JEUXDh0N1aIeV9eg4a6487PxOMKZxt1aH1bMgpZH066S0sbX
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: Wed, 10 Jul 2013 01:58:36 -0000

Hey Martin,

On 09.07.13, 21:45, Martin Thomson wrote:
> On 9 July 2013 05:44, Emil Ivov <> wrote:
>> While 1 and especially 2 may be preferable in terms of efficiency,
>> personally, I am worried that getting it right in terms of spec and
>> implementation is non-trivial and this may become a common reason for
>> interoperability problems. Therefore, 3 does seem like the simplest way to
>> go.
> You are going to want to ensure that both peers check in the same
> order.

What exactly do you mean by "in the same order"? Do you mean that:

a) they should try and make sure that they are checking the candidate 
pair that is symmetric to the one their peer is testing and
b) all other components for the involved foundations should be frozen?

Do you have a better wording?

> 3 seems a little too loose for me.

It is indeed loose but I can't think of a reason why it wouldn't work 
even with several seconds of RTT. So, unless you are going to manually 
paste every new candidate into a mail and then do the the same on the 
remote side, you should probably be fine.

Ekr, I believe you mentioned you were doing this in Firefox? How is it 

> I think that some sort of
> mechanism is going to be needed to avoid problems with races, since
> both peers will have different sets of candidate pairs at every point
> in the process.

OK. Do you mean something like 2. or do you have another mechanism in mind?