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

Emil Ivov <> Thu, 18 October 2012 12:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 355B821F86B0 for <>; Thu, 18 Oct 2012 05:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R8+l8smuYZrT for <>; Thu, 18 Oct 2012 05:21:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2AA6821F86A8 for <>; Thu, 18 Oct 2012 05:21:09 -0700 (PDT)
Received: by with SMTP id hr7so1609915wib.13 for <>; Thu, 18 Oct 2012 05:21:09 -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=c/J5QXbz79Clg7ia86NCfw6ApUv7ttbzTExaM++oz4Y=; b=YOQX/apkGHBHDdnVkHhkiaeGtXetXE8s8SlkzDk3rpgroq4zt4FEew9SxniR6TK5ES KaIY9uXYF8QLTFXoQHiag7G+fl9anR0rP4wt1Nen2r0JV5WI++/DwgCFZmvr57ZPQPwW boB0HTry4arVxiAzCxrASZglejVNu2al2fKw/i2hS1uvbLMt5hv+FVQIqqO9IyKtRacT +mVnS8JWimipp/BfOAixtVo0KqYKNBqqZUOcN/pPFsxX5M/1C5UOMrK2Cjq/dtoitrwU 8AQnAd0FLtk0M0DyFsEzreHuYuLQ2rSuvqSPLtFRaFti2OTAbOD36mNywfVp7oa6HdNd cydg==
Received: by with SMTP id db6mr10947978wib.20.1350562869298; Thu, 18 Oct 2012 05:21:09 -0700 (PDT)
Received: from ([2001:660:4701:1001:d09b:d3d8:f1d4:17c4]) by with ESMTPS id v3sm33319513wiy.5.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 05:21:08 -0700 (PDT)
Message-ID: <>
Date: Thu, 18 Oct 2012 14:21:02 +0200
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmZRLqnu9eyQt2Lw+xLErUye1yRFgJ+tceAV9dkNrOw7jm38fUW74148Z9eW9KhlT8bjYJ3
Cc: "" <>
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: Thu, 18 Oct 2012 12:21:11 -0000

Hey Christer,

On 18.10.12, 13:17, Christer Holmberg wrote:
> Hi,
>>>> 4) How does trickle ICE work without “relaxing” RFC3264 O/A? It
>>>> seems like you really want to be able to trickle via updated
>>>> offers that may be generated prior to the corresponding answer
>>>> or reject?
>>> One of my comments on the trickle draft was about that. The draft
>>> says that a new offer can be sent "at any time", but my comment
>>> was that it should be according to 3264.
>> That's not exactly what the draft says. What it does say is:
>> At any point of ICE processing, a trickle ICE agent may receive
>> new candidates from the remote agent.
> Correct.
> And, it is of course true in one sense, because STUN requests
> creating peer reflexive candidates can of course be received at any
> time :)

True but in the "Trickle ICE" case it would be more common to learn new
candidates through signalling (rather than PR candidates during conn
checks). This is what the text refers to. I agree we should make it
clearer that we do not really mean PR candidates here.

>>> IF we are going to relax 3264 (I really hope we are NOT), it
>>> needs to be clearly described somewhere. We cannot have a number
>>> of I-Ds doing it "on the run"...
>> I don't see how trickle ICE would require any changes to the O/A
>> model. Candidate trickling semantics are completely separate from
>> those in 3264.
>> Yes, the 3264 offer may, in some cases, contain a first batch of
>> candidates and the the 3264 may have to be delayed until ICE
>> processing yields valid pairs for every component but that's about
>> it.
>> Am I missing something?
> I guess the question was whether one, after the first batch of
> candidates have been sent in an offer, should be allowed to send the
> second batch in a new offer - before an answer to the previous offer
> has been received. That would be against 3264.

It would indeed but I am not sure why we would think of additional
candidate drops as offers at all. They are just independent signalling
and are only loosely related to the 3264 semantics.

Of course with SIP we would have a problem caused by the fact that
additional in-dialog signalling is blocked by the 3264 answer. However,
that's specific to SIP and will probably be best served with a SIP
specific solution (e.g. UPDATEs or forcing early answers, or something

Does this make sense?

> Regards,
> Christer