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

Eric Rescorla <ekr@rtfm.com> Tue, 13 May 2014 04:25 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 CBB801A083C for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 21:25:05 -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 jhR7HFMXCTkk for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 21:25:03 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 793151A083B for <rtcweb@ietf.org>; Mon, 12 May 2014 21:25:02 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id bs8so6481882wib.1 for <rtcweb@ietf.org>; Mon, 12 May 2014 21:24:55 -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=IQ0T3jND4BibQm4HuCYyfU3Azd0XUR3vch3GdGLYbTQ=; b=UixlUCFvSKPCLn5FRWoF3MBAArpRo2Z6lyWJdVaKHIKhgSWChRF1r7TWOKImqStDA+ zAQhRNQtxyfji97bXboD5/Cf0q4L+5SLmOkdMYzh7xQBtM6JO6+BGXW1kjFzbuK/p25L sIJWyyJzEGq4Fe2m/Zldz8rKSVyAhWOHHFVq2j0/w4DGEd828FKjxuAyUYebvgtgghcI gqIcqaCBJOSqyDkyuuIxrY+C2OkMhtHGVt5WUv8WUhu4QXZQL4l53l0dTKTFxhnvFBQ2 /3Hh2sb/50PHhiUOyf5xwcvUS1Tl8kjnvUEwo7AG0EKtYIyN19AgPlMxxMNJnSU1jocO FCPQ==
X-Gm-Message-State: ALoCoQkAn8InAFAkW/xbYjWxZz026z1G8jHoiKf5fTBPreXJr3l8TxYnUZgDQhEAtxf5lPQ1gP69
X-Received: by 10.180.97.68 with SMTP id dy4mr18832498wib.49.1399955095839; Mon, 12 May 2014 21:24:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Mon, 12 May 2014 21:24:15 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <CABkgnnWfAYTUBrrbu=m_j0=S3uBw4Cf7PBDi3ZmAGHsUMBX1kQ@mail.gmail.com>
References: <CABcZeBNUTf42tS9FrjS9Q6Zk8LBkhpKOR1z2v8MHoeNEUf93Mw@mail.gmail.com> <56C2F665D49E0341B9DF5938005ACDF82F69E8@DEMUMBX005.nsn-intra.net> <CABcZeBO1Z0SnTUixjV09ekw-mb=YyzHjOV-b-MMUZy7sx32h6Q@mail.gmail.com> <5370D1E3.7040809@alvestrand.no> <CABcZeBNgJ_DP6XQ2L0fdrFEE-YWwuKCjq4f-X5cD6+pK3un8Hw@mail.gmail.com> <5370F349.7050006@alvestrand.no> <CABkgnnWfAYTUBrrbu=m_j0=S3uBw4Cf7PBDi3ZmAGHsUMBX1kQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 12 May 2014 21:24:15 -0700
Message-ID: <CABcZeBMVmg=fDpKgGzo-T5xQo1gLh5wAL_2L5PY2rJ7-mHDYTQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=f46d044306ac307ea104f94072ed
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DN7MzOlKv_6A1XQEvP_czK9Pcgg
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: Tue, 13 May 2014 04:25:06 -0000

On Mon, May 12, 2014 at 11:59 AM, Martin Thomson
<martin.thomson@gmail.com>wrote;wrote:

> Why not:
>
> 1. pc.createOffer(...)
> 2. success callback fires (0 candidates)
> 3. pc.setLocalDescription(offer)
> 4. onicecandidate fires some number of times
> 5. onicecandidate fires with a null candidate
> 6. send pc.localDescription (as opposed to the original offer)
>
> No need to run multiple rounds of createOffer or anything nasty like that.
>

This doesn't seem like a complete answer. The spec explicitly allows
multiple CreateOffers, so what is the impact of that?

-Ekr


> Note that we don't have an onicegatheringstatechange event that would
> let us monitor that state more directly, but the actual code cost is
> identical either way.
>
>
> On 12 May 2014 09:14, Harald Alvestrand <harald@alvestrand.no> wrote:
> > On 05/12/2014 05:17 PM, Eric Rescorla wrote:
> >
> >
> >
> >
> > On Mon, May 12, 2014 at 6:51 AM, Harald Alvestrand <harald@alvestrand.no
> >
> > wrote:
> >>
> >> On 05/12/2014 02:39 PM, Eric Rescorla wrote:
> >>
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >> If an application is written as
> >>
> >> 1) CreateOffer()
> >> 2) wait for the end of candidates callback
> >> 3) negotiate
> >>
> >> then I would think it might have trouble if all the candidates are
> present
> >> in the SDP, and therefore no callbacks were called.
> >> Solution: Always fire the end of candidates callback after calling the
> >> success callback, even if all candidates are in the SDP already.
> >
> >
> > So you mean:
> >
> > 1. CreateOffer()
> > 2. success callback fires.
> > 3. SetLocal()
> > 4. onicecandidate(...)
> > 5. onicecandidate(null)
> >
> > Then later (w/ no changes to the MSTs)
> >
> > 6. CreateOffer()
> > 7. success callback fires
> > 8. SetLocal (????)
> > 9. onicecandidate(null)
> >
> > I believe this would be a change to the W3C API (not that this is
> > necessarily bad)
> >
> >
> > Something like that, yes. Or in more detail, for a call requiring 2
> > candidates:
> >
> > 1. CreateOffer()
> > 2. success callback fires (1 candidate present)
> > 3. SetLocal()
> > 4. onicecandidate(...)
> > 5. onicecandidate(null)
> >
> > Then later (w/ no changes to the MSTs)
> >
> > 6. CreateOffer()
> > 7. success callback fires (2 candidates present)
> > 8. SetLocal ()
> > 9. onicecandidate(null)
> >
> > Then still later (after having done something that requires a 3rd
> > candidate):
> >
> > 10. CreateOffer()
> > 11. successCallback fires (2 candidates present)
> > 12. SetLocal()
> > 13. onicecandidate(...)
> > 14. onicecandidate(null)
> >
> > If we don't have the null onicecandidate in case 2 (step 9), it gets
> hard to
> > support case 3 (step 12-14).
> >
> >
> > -Ekr
> >
> >>
> >>
> >>
> >> -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
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >>
> >>
> >> --
> >> Surveillance is pervasive. Go Dark.
> >>
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>