Re: [rtcweb] Filling in details on "trickle ICE"

Emil Ivov <> Tue, 28 August 2012 06:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E38CB11E809C for <>; Mon, 27 Aug 2012 23:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OVe69wf2csZ7 for <>; Mon, 27 Aug 2012 23:04:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CCE6111E809A for <>; Mon, 27 Aug 2012 23:04:05 -0700 (PDT)
Received: by weyu54 with SMTP id u54so3029348wey.31 for <>; Mon, 27 Aug 2012 23:04:04 -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=5gYx42ASn2S1r9kXZV7F0BUqC+Lo8CFDeP7b7b7RrHo=; b=BxC6T5Yhn4lrXbidlamcO7+nJaMfXGlC0C/XCdlpYtBW+1BJNz4gDEwjBLMLbPQpDN sDLz2qPeYT/DXDTuLuV9cdpqC8SsG1Drts2gdifaLUWUZzCXyfX9WBMdVrnW4FkXPlwW R1ggxjmwhUT2bOFXXy8Zvkg3ESTjJ5xIZ8ogNhVstEjeL3EB8WKNn45j6hKC9bGaNOzk SxoSfFQn5aVcTXTcrYxtye9gLoAPpYlFBM/R0/cF6Da0f4JaCQFF5XpojpOhDsWJrk9a K4d4ZrAjvrwbeHV6WFcl3dRfYDnhUcyqGjNDYtS7bmU3nJuAgynagf+BIHnAO1QEw/Al fNUA==
Received: by with SMTP id p2mr30557815wiw.0.1346133844852; Mon, 27 Aug 2012 23:04:04 -0700 (PDT)
Received: from camionet.local ( []) by with ESMTPS id eu4sm3202852wib.2.2012. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 23:04:02 -0700 (PDT)
Message-ID: <>
Date: Tue, 28 Aug 2012 08:04:04 +0200
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Bernard Aboba <>
References: <><><><><><><>, <>, <>, <>, <>, <> <BLU002-W2286956624CC6600038246993A20@phx.gbl> <> <BLU169-DS457B54FA311A048E5E68B093A20@phx.gbl>
In-Reply-To: <BLU169-DS457B54FA311A048E5E68B093A20@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQk9KVWBLvFCK+5DaErIFrzOqb2E17narFNqKrRlt82ucV9UHzKCE51zHf8IaaszuOi1/ly+
Subject: Re: [rtcweb] Filling in details on "trickle ICE"
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, 28 Aug 2012 06:04:07 -0000

On 28.08.12, 00:29, Bernard Aboba wrote:
> Emil Ivov said: 
>> Well an ICE stack that implements trickle as per XEP-0176 would currently
>> not interoperate with a 5245 implementation or, at best, would lead to
>> unpredictable results.
>> The description in XEP-0176 is actually quite perfunctory and can't really
>> be considered a proper specification.
>> A document that describes a proper way of implementing this would hence be
>> quite helpful.
> [BA]  You are correct that XMPP/Jingle signaling will not be understood by a
> SIP UA. 

Right. And of course, I was not referring to signalling.

> However,   I don't see anything inherent in the use of STUN/TURN 
> within XEP-0176 that violates RFC 5245. 

It's more about ICE processing rather than STUN and TURN and the fact
that, if an ICE implementation is not prepared to handle trickling it
would not work well with one that does. (more below)

>From your other mail:

> Details of the updated offer are described in RFC 5245 Section

I am not sure how would apply here given that it's about sending
updated offers once ICE has completed. It even says that:

    The agent MUST include candidate attributes for candidates matching
    the default destination for each component of the media stream, and
    MUST NOT include any other candidates.

Did you instead mean to quote section which contains the following:

   The agent
   MAY include additional candidates it did not offer previously, but
   which it has gathered since the last offer/answer exchange, including
   peer reflexive candidates. does indeed refer to updating ICE for "Existing Media Streams
with ICE Running".

While I agree that this does look like trickling I am not sure it was
intended to be used in exactly the same way that we are discussing here
and the text is not enough to cover a proper trickling implementation.

The main issue is that there's currently nothing in 5245 that would
allow an agent to determine if more candidates are to be expected. If
trickling is in use there's no way for a controlled agent to know that
(or if) more candidates are to be expected. This creates a race
condition which may result in the controlled agent moving into the "ICE
Failed" state before it has received all candidates from the controlling

Such premature failures can happen very easily if the first offer only
contains addresses that can be determined as unusable without even
running any checks. This would be the case for an IPv4-only host
receiving an offer with IPv6 candidates only (and vice versa). One can
probably come up with a few more cases like this one.

> If the issue is lack of clarity in
> XEP-0176, shouldn't that be brought up in the XSF, which owns the
> specification?

Nope, XEP-0176 would be crystal clear if the IETF comes up with a
document that explains how ICE agents should behave in situations where
addresses continue to arrive after the original offer.