Re: [rtcweb] Issue with new Trickle ICE text

Justin Uberti <> Thu, 06 March 2014 13:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 69D4B1A02CE for <>; Thu, 6 Mar 2014 05:31:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lho0u0Id-Hpv for <>; Thu, 6 Mar 2014 05:31:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c03::22c]) by (Postfix) with ESMTP id 48E921A02F9 for <>; Thu, 6 Mar 2014 05:31:35 -0800 (PST)
Received: by with SMTP id lf12so2560738vcb.17 for <>; Thu, 06 Mar 2014 05:31:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BEJfFjjHGg3oGv/0Evi55GnSYxavX2g+D9VcvqfBQZ4=; b=er7k60ttUlisW/RK6qTQmagj8uqk+13/hdiGyvzEA05FRCUnIJSDf0ZuCfEG0QHNqg tXyzXsNpi/UJ93wYlnNgR6anom1fghzSuTapenrHx94/4rlhvsQbgG7FCye6MHKvnJnW n+kLQYh+xnb7mEPVinfIp4jvkkv/8K2OO4zebyVTQwd3ketit82Lx2+Jq6o+X/kI/k0H /W0VdHRNqA+qZAQCigln8ib+PX4eWp0czeKFsvKz7e6S5/M4NYqkZLGeid4OXSAv93w2 JgMRsVQwhuAzreYXLLJy4MpKPRg0wp8b8YKqaiQzg1vKWL2roaUnnUgzonnfcLZ4Tb3I CWNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BEJfFjjHGg3oGv/0Evi55GnSYxavX2g+D9VcvqfBQZ4=; b=kqwwApoW3yA53ssKAnZWU8kaEAsJXphMZSW0ow68WDRzct51lLxmcQDAJNPL0fpC44 HcUyXNpPS/ck4UudUKWzvNqOvRmuBzdr+khnkjMoI65lKuS+QCEIExPxPUdRZrdmvd84 arT6u35bNmDiiG3kd0X1jrMe+GwxUcbvoeWQ16S0joH9ckVMChcmbKJTh4lF9ghZnvwF PHnYw8XpUDwe+voSHi6Am8gBBfmGzYVy1WXUBr9UCqV3G+tClsMMp9HDuolW06QB1Yor 8SsBizDH6vIjCr5HZqbuk37R9dqCKu05l8/YmtrRcBj80N/fJZQ5q9zbr8uAvT6g3whI 9+Ug==
X-Gm-Message-State: ALoCoQldMUPkHJ9srRE9uORvDVC3RsVoMCBkPxcnWKWFAYBBJJxDa2eLd35kDmu3HvVFpukPCgwrK0poKrvZeZUkMgzGCE6I/o7QRUOu3q1m5KaKV/5St36Sy9QO4d7OdAdJsIQQpfSv66XOiBgPoi0mahP1KJXYCip94MMW6DyYE7ymzlgdud5z9UkdxiW1y33VmWGKAEMz
X-Received: by with SMTP id q15mr82651vcn.38.1394112691252; Thu, 06 Mar 2014 05:31:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 6 Mar 2014 05:31:11 -0800 (PST)
In-Reply-To: <>
References: <>
From: Justin Uberti <>
Date: Thu, 06 Mar 2014 13:31:11 +0000
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary="001a11c1da06bd45a204f3f027ec"
Cc: "" <>
Subject: Re: [rtcweb] Issue with new Trickle ICE text
X-Mailman-Version: 2.1.15
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, 06 Mar 2014 13:31:52 -0000

As discussed in the meeting, this doesn't mandate Trickle ICE for the
application (which can just wait until gathering is complete, as indicated
in S 3.4.1). Trickle ICE is mandated for the implementation, but I thought
we had agreed that long ago so that applications can get consistent

While the text in S 3.4.2 is new, it is consistent with the text in 4.1.2
and 4.1.5, which defines the behavior for createOffer and


   Calling this method may do things such as generate new ICE
   credentials, but does not result in candidate gathering, or cause
   media to start or stop flowing.


   This API indirectly controls the candidate gathering process.  When a
   local description is supplied, and the number of transports currently
   in use does not match the number of transports needed by the local
   description, the PeerConnection will create transports as needed and
   begin gathering candidates for them.

On Wed, Mar 5, 2014 at 9:27 AM, Eric Rescorla <> wrote:

> S 3.4.2 of JSEP now reads:
>     JSEP applications typically inform the browser to begin ICE gathering
>     via the information supplied to setLocalDescription, as this is where
>     the app specifies the number of media streams to gather candidates
>     for.  However, to accelerate cases where the browser knows the number
>     of media streams to use ahead of time, the application MAY ask the
>     browser to gather a pool of potential ICE candidates to help ensure
>     rapid media setup.  When setLocalDescription is eventually called,
>     and the browser goes to gather the needed ICE candidates, it can
>     start by checking if any candidates are available in the pool.
> The issue here is that this basically mandates trickle ICE. If the
> pool is smaller than the number of independent ICE streams needed,
> then there is no way for you to "start gathering" (since this text
> says it happens with sLD) and therefore you cannot supply all of the
> candidates in the offer.
> If that's not the intention to require (and I don't believe we agreed
> to this semantic), then this needs to be rewritten.
> -Ekr
> _______________________________________________
> rtcweb mailing list