Re: [rtcweb] When are ICE candidates added to the SDP

Eric Rescorla <ekr@rtfm.com> Mon, 12 May 2014 12:40 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC561A0690 for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 05:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_2R5A4o0QRj for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 05:40:04 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 92CBB1A068C for <rtcweb@ietf.org>; Mon, 12 May 2014 05:40:04 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id r20so4389129wiv.1 for <rtcweb@ietf.org>; Mon, 12 May 2014 05:39:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=opiwEa9kHM9uCIn3nJOtENmM1MJXaF+/SgzywovylWA=; b=muXMUIYcS/dciRhUHcA70/Xzep4BkAFdwafDgoL14YlSDPj1sG/cjus0VktEPnmgLB OgveXRzz4aw7L5DVlkBwE5vAbWptEcPDZyl/2+yNBm0lCk3sWuhW8MZLaeCJkbMv67IB eMMVOfVxH0ToQDMtabYSgMcQCfwXy6tEuEnn2NDUJ52IYpjiy8O6ur4j/EUvQ4iqhYrI CkY51Gql5pa9M2II/mGolFBm6zUjqSiuSlbMRSEwKhO3mr9OkeQjczlM95MQ8yVR91uP 8loPgrRSdnlfJt67vR4OLdIene0KLoGDxLZt07VOXcD8472gfAfwP0IuewY4X5ETtQAj 4M6w==
X-Gm-Message-State: ALoCoQlS4pFcHalGMtS9qdeD/C3GvwA3KaiZbNq9tuLo/ILn5cOO/Z58e3AuATNgf5yxpSbFvtyE
X-Received: by 10.194.187.107 with SMTP id fr11mr1420001wjc.70.1399898398214; Mon, 12 May 2014 05:39:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Mon, 12 May 2014 05:39:18 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF82F69E8@DEMUMBX005.nsn-intra.net>
References: <CABcZeBNUTf42tS9FrjS9Q6Zk8LBkhpKOR1z2v8MHoeNEUf93Mw@mail.gmail.com> <56C2F665D49E0341B9DF5938005ACDF82F69E8@DEMUMBX005.nsn-intra.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 12 May 2014 05:39:18 -0700
Message-ID: <CABcZeBO1Z0SnTUixjV09ekw-mb=YyzHjOV-b-MMUZy7sx32h6Q@mail.gmail.com>
To: "Rauschenbach, Uwe (NSN - DE/Munich)" <uwe.rauschenbach@nsn.com>
Content-Type: multipart/alternative; boundary=047d7bb03f60bf64dd04f9333e49
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/STubH0wJtxWQoskNb6Eq0ExXnmY
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] When are ICE candidates added to the SDP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 May 2014 12:40:07 -0000

On Mon, May 12, 2014 at 2:03 AM, Rauschenbach, Uwe (NSN - DE/Munich) <
uwe.rauschenbach@nsn.com> wrote:

>  Hi Eric, all,
>
>
>
> Is the consequence of “always trickle” that ICE candidates have to be
> added by non-trickling applications via SDP manipulation?
>
> I consider this indeed quite inconvenient for non-trickling applications.
>

So, my understanding was that we had agreed that no candidates would
be available in the first CreateOffer() no matter how many candidates were
in the pool.

The intent of this message is to ask if that is useful.

-Ekr

 A way out would be that the SDP always contains the candidates collected
> so far (as currently defined in the JSEP snippet cited),
>
> or that a switch in the API allows an application to configure the
> behavior when adding ICE candidates.
>
>
>
> Kind regards,
> Uwe
>
>
>
>
>
> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *ext Eric
> Rescorla
> *Sent:* Monday, May 12, 2014 8:52 AM
> *To:* rtcweb@ietf.org
> *Subject:* [rtcweb] When are ICE candidates added to the SDP
>
>
>
> See: https://github.com/rtcweb-wg/jsep/issues/11
>
>
>
> Section 3.4 reads:
>
>
>
> When a new ICE candidate is available, the ICE Agent will notify the
>
> application via a callback; these candidates will automatically be
>
> added to the local session description. When all candidates have
>
> been gathered, the callback will also be invoked to signal that the
>
> gathering process is complete.
>
>
>
> However, we agreed in London that we would do "always trickle", and
>
> that even if there were candidates available at the time when CreateOffer
>
> (because of candidate pooling) was called, they would not be included
>
> in the initial offer. Consider the following sequence of events.
>
>
>
> 0. pc = new RTCPeerConnection();
>
> 1. pc.AddStream(stream);
>
> 2. pc.CreateOffer();
>
> 3. CreateOffer callback fires with offer A, and you call
> SetLocalDescription();
>
> 4. onicecandidate fires with candidate X.
>
> 5. pc.CreateOffer()
>
> 6. CreateOffer callback fires with offer B.
>
> 7. onicecandidate fires with null.
>
>
>
> So, in London, I think we agreed that offer A would have no candidates.
>
> The above text implies that if you were to examine localdescription prior
>
> to step #5 or at step #7 it would contain candidate X, and probably that
> offer B would
>
> also contain candidate X.
>
>
>
> Note that it's quite inconvenient for non-trickle applications to never
>
> have any candidates in the SDP, especially after gathering is completed
>
> at step #7. However it also seems kind of inconsistent to only update the
>
> candidates after SetLocal() has been called.
>
>
>
> -Ekr
>
>
>