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

Christer Holmberg <> Thu, 18 October 2012 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E6D021F84EA for <>; Thu, 18 Oct 2012 13:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.127
X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.122, 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 EKdsyIvF-zxu for <>; Thu, 18 Oct 2012 13:10:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AD3F721F8512 for <>; Thu, 18 Oct 2012 13:10:33 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-a7-5080623846ee
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 38.9C.11467.83260805; Thu, 18 Oct 2012 22:10:32 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 18 Oct 2012 22:10:31 +0200
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 22:10:31 +0200
From: Christer Holmberg <>
To: 'Matthew Kaufman' <>, Emil Ivov <>
Thread-Topic: [rtcweb] Filling in details on "trickle ICE"
Thread-Index: Ac2XjRRR2xT3N2ETRimioq1qbE99zgVCc2oAABiJLGAAAy+oAAAG/KWg///xHAD//94bEIAAJLMA///eFjCAACgVgIAAaa2A///PAeA=
Date: Thu, 18 Oct 2012 20:10:31 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>, <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3VtciqSHA4OQONYs1OyewWGydKmQx 49ZZFou1/9rZHVg8Fmwq9Viy5CeTx/83gR63HkxiC2CJ4rJJSc3JLEst0rdL4Mr4vuYBc8F6 qYqW72fZGxj/iHQxcnJICJhILLlxgBXCFpO4cG89WxcjF4eQwClGiVkz+sESQgI7GSUWHXOC SCxhlGi+cJKli5GDg03AQqL7nzZIjYiAn8TuL/MZQWxmAW+JT4sesIPYwgKWEus+XmGHqLGS +LnoOZRdJjHt4Dkwm0VAVWLqzFYmEJsXqLfv21omiF1tbBKPlu4DK+IUSJSYfeMDM4jNCHTp 91NrmCCWiUvcejKfCeIDAYkle84zQ9iiEi8f/4P6TFHi46t9UMfpSCzY/YkNwtaWWLbwNTPE YkGJkzOfsEA8rC3RsngC+wRgGCBZMQtJ+ywk7bOQtC9gZFnFKJybmJmTXm6ol1qUmVxcnJ+n V5y6iREYjwe3/NbdwXjqnMghRmkOFiVxXq6k/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GH0Flx+T6mG+YNgS7f3nirxt6qaLm2vEMvZuXZbX9qtFOmnG+13P4hU2T56gsV6iZ+1j//m1 EhuzvXobLx0qPZ1//qSjh34e39cAFW8WzvokmwWfGHQ/OrpyGx+sMd/yIn4j+24lr/7aKbts A9X2fXxcslU4q969t3rT3w03PF44Tq9gWr2jQ4mlOCPRUIu5qDgRAKSS8L2VAgAA
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 20:10:41 -0000


>Oh, I agree wholeheartedly here... in order to support things like trickle ICE it would be enormously helpful to separate the ICE negotiation 
>from the SDP O/A state machine, so that candidates may be added without making them part of an "Offer".
>The "Microsoft API proposal" neatly handles the ICE negotiation in a way that is separated from the media negotiation... I suggest we use that 
>method instead of trying to bend SDP O/A all out of shape in order to do trickle ICE.

Sure, between the browser and the JS App we might choose to separate ICE from SDP and O/A completely.

However, the way the trickle-ICE draft is written, I assume it focuses on the interactions between two entities, and what is sent on the wire.



From: Emil Ivov []
Sent: Thursday, October 18, 2012 5:53 AM
To: Christer Holmberg
Cc: Matthew Kaufman; Justin Uberti;
Subject: Re: [rtcweb] Filling in details on "trickle ICE"

Hey Christer,

On 18.10.12, 14:34, Christer Holmberg wrote:
> Hi,
>>>>>>> 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.
>> Sure, and we agree that the general O/A need not be used for trickle ICE, right?
> Well, I think general O/A SHALL be used - not only for trickle ICE,

But why? What do we get from trickling via offers and answers other than problems?

Or did you mean that

> but also for JSEP :)
> (Vanilla ICE is also using general O/A)

Not really. At least not always. ICE is quite nicely separated from the media O/A in XMPP.

Both are indeed stuffed together for SIP by 5245 but that's just a design choice that we don't need to stick with. At least I don't see why we would.