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

Christer Holmberg <> Thu, 18 October 2012 12:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE7BA21F86EB for <>; Thu, 18 Oct 2012 05:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.122
X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IYXf8xuM+Clb for <>; Thu, 18 Oct 2012 05:26:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C59C421F866E for <>; Thu, 18 Oct 2012 05:26:57 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-31-507ff5904a6f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 25.9A.04547.095FF705; Thu, 18 Oct 2012 14:26:56 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 18 Oct 2012 14:26:56 +0200
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 14:26:55 +0200
From: Christer Holmberg <>
To: Emil Ivov <>
Thread-Topic: [rtcweb] Filling in details on "trickle ICE"
Thread-Index: Ac2XjRRR2xT3N2ETRimioq1qbE99zgVCc2oAABiJLGAAAy+oAAAG/KWg///xHAD//94bEA==
Date: Thu, 18 Oct 2012 12:26:54 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3VnfC1/oAg44lWhZrdk5gsdg6Vchi xq2zLBZr/7WzO7B4LNhU6rFkyU8mj/9vAj1uPZjEFsASxWWTkpqTWZZapG+XwJVx8tFctoJj MhVzOrrYGxhfSHcxcnJICJhIbJx0kh3CFpO4cG89WxcjF4eQwClGiclzJzJDODsZJVYt/cMI 4SxhlOjfsBYow8HBJmAh0f1PG6RbREBeorttEROIzSxQJTH52hxGEFtYwFJi3ccr7BA1VhI/ Fz2HssMkWn5NAathEVCVeLjlCVgvr4C3xOTFIBeB7HrPLPF+zhawBKeApsSd01/BbEagU7+f WgO1TFzi1pP5TBAvCEgs2XOeGcIWlXj5+B8rhK0osfNsO9jNzEBz1u/Sh2hVlJjS/ZAdYq+g xMmZT1hAbCEBbYmWxRPYJzBKzEKyYRZC9ywk3bOQdC9gZFnFKJybmJmTXm6kl1qUmVxcnJ+n V5y6iREYjQe3/FbdwXjnnMghRmkOFiVxXuute/yFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MCoFHXS5E7H5nD+vdkXoqwOCu3csVLM57y3SNMuxSGP7qsUbjzPJf9h+WnDKI4VDE4riDsyf 18zafu7jnU/r5x2Ld1wvwRCw7USAc4vhlurGmiuC5Vr3rvz5c2CH19JFslIzZ55tuXeFUULp ZETq3J9apfatO589mna3q3PHh6PS1mu3NguXftJWYinOSDTUYi4qTgQA9PrZrZQCAAA=
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:26:59 -0000


>>>>> 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.


(Remember our previous discussion, though, about PR candidates being enough if the remote peer is ICE lite ;)

>>>> 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 else).

It is sure that SIP may add its own limitations, but the general O/A is generic.