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

Francois Audet <> Tue, 28 August 2012 04:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74F9311E80AE for <>; Mon, 27 Aug 2012 21:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5+G+dnnc+q9r for <>; Mon, 27 Aug 2012 21:40:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5D74C11E808E for <>; Mon, 27 Aug 2012 21:40:53 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Tue, 28 Aug 2012 04:40:51 +0000
Received: from mail220-va3 (localhost []) by (Postfix) with ESMTP id AACDE20314; Tue, 28 Aug 2012 04:40:51 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: 1
X-BigFish: VS1(zz98dIc85fh1432Izz1202hzz8275bhz2fh2a8h668h839hd25he5bhf0ah107ahbe3k)
Received-SPF: pass (mail220-va3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail220-va3 (localhost.localdomain []) by mail220-va3 (MessageSwitch) id 1346128850462057_12110; Tue, 28 Aug 2012 04:40:50 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 6AA04C00045; Tue, 28 Aug 2012 04:40:50 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 28 Aug 2012 04:40:50 +0000
Received: from ([]) by ([]) with mapi id 14.02.0318.003; Tue, 28 Aug 2012 04:40:48 +0000
From: Francois Audet <>
To: Bernard Aboba <>
Thread-Topic: [rtcweb] Filling in details on "trickle ICE"
Thread-Index: AQH4Z3X5I7zcrx421Sos9AL76IZ9BAJvCnahAdiFK1ACgKa3jAGz5sLXAsrOx68ChET32QJMFXN+AitKuM4CAxiVZgJ/+26+AdDCUrACfNC2awJzCOrgAdiruaeWHX4mcIAAIIbwgAAxCgCAABiOOA==
Date: Tue, 28 Aug 2012 04:40:47 +0000
Message-ID: <>
References: <><><><><><><><>, , <>, , <>, , <>, , <>, , <> <BLU002-W2286956624CC6600038246993A20@phx.gbl>, <> <BLU169-DS457B54FA311A048E5E68B093A20@phx.gbl>, <>, <BLU002-W161FE7AE76153E3E8A6A81293A10@phx.gbl>
In-Reply-To: <BLU002-W161FE7AE76153E3E8A6A81293A10@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_DDFF5412966F47C8B7773C57E96AD689skypenet_"
MIME-Version: 1.0
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: Tue, 28 Aug 2012 04:40:54 -0000

Yes, this is exactly the section of 5245 I was referring to. Seems to be effectively trickling.

On Aug 27, 2012, at 20:12, "Bernard Aboba" <<>> wrote:

Francois said:

> Wouldn't the same mechanism as XEP-0176 work with SIP too, by sending new offer/answers with new candidates?
> In either cases, it is true that the "trapezoid" model makes this process more difficult than with the "triangle" model.
> But you don't *have* to do trickle ICE don't you, in the trapezoid scenario (especially when involving protocol mapping).

[BA]  Looking at XEP-0176 Section 5.8, it does seem possible to use new offer/answers with new candidates to similar effect.  Here is what Section 5.8 says:

Section 5.8 Negotiating a new candidate

Even after media has begun to flow, either party MAY continue to send additional candidates to the other party (e.g., because the user agent has become aware of a new media proxy or network interface card). Such candidates are shared by sending a transport-info message....  The receiving party MUST acknowledge receipt of the candidate. The parties would check the newly-offered candidate for connectivity, as described previously. If the parties determine that media can flow over the candidate, they MAY then use the new candidate in subsequent communications.

[BA]  If ICE completed and media was already flowing, the controlling agent can generate a RE-INVITE with a candidate from the in-use pair as the default as well as additional candidates.  There is no need to do an ICE restart.  As described in RFC 5245 Section 8.1.2, if the additional candidate ends up in a highest-priority nominated candidate-pair, then an updated offer is sent:

      *  If an agent is controlling, it examines the highest-priority
         nominated candidate pair for each component of each media
         stream.  If any of those candidate pairs differ from the
         default candidate pairs in the most recent offer/answer
         exchange, the controlling agent MUST generate an updated offer
         as described in Section 9.  If the controlling agent is using
         an aggressive nomination algorithm, this may result in several
         updated offers as the pairs selected for media change.  An
         agent MAY delay sending the offer for a brief interval (one
         second is RECOMMENDED) in order to allow the selected pairs to

Details of the updated offer are described in RFC 5245 Section

   If an agent generates an updated offer including a media stream that
   was previously established, and for which ICE checks are in the
   Completed state, the agent follows the procedures defined here.

   The default destination for media (i.e., the values of the IP
   addresses and ports in the m and c lines used for that media stream)
   MUST be the local candidate from the highest-priority nominated pair
   in the valid list for each component.  This "fixes" the default
   destination for media to equal the destination ICE has selected for

   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.

   In addition, if the agent is controlling, it MUST include the
   a=remote-candidates attribute for each media stream whose check list
   is in the Completed state.  The attribute contains the remote
   candidates from the highest-priority nominated pair in the valid list
   for each component of that media stream.  It is needed to avoid a
   race condition whereby the controlling agent chooses its pairs, but
   the updated offer beats the connectivity checks to the controlled
   agent, which doesn't even know these pairs are valid, let alone
   selected.  See Appendix B.6 for elaboration on this race condition.