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

Martin Thomson <martin.thomson@gmail.com> Mon, 12 May 2014 18:59 UTC

Return-Path: <martin.thomson@gmail.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 E06041A076A for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 11:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 Jqw4aUycRfa9 for <rtcweb@ietfa.amsl.com>; Mon, 12 May 2014 11:59:35 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 60F241A0728 for <rtcweb@ietf.org>; Mon, 12 May 2014 11:59:35 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id u56so7414876wes.28 for <rtcweb@ietf.org>; Mon, 12 May 2014 11:59:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UIuTu7eN2pRf4AuZrBGfZxum0xpmzKj96NtVgW2cneI=; b=zyGvBTKjFclDa9HpC1o5xAjTcGyNo5IOwK5esl4wgjQz3A7brA5Zmh/7uM2G5BH6TY HEhaJcR+pYtTk3Htl1r9c44mNwhD3IJGf5CXVsfQIzV2rjbfiZwwuTTIQD+qCU+5LJ6v 0AXOeqxc4lG3YbTJ8RkruDrv6XgrvbLYnYb9NW6hJ5wuERtCJ4GHWxXaN/T70YhDbArx BAReb+esdDfZ+h+Q6+ULkzp6IqR/LDCpVocIIrgiJ/KgaUTHDbsX849TuNQdhtHPWasW gSr3NWAIpo6meD3vEYAfGlMrMkjJKa7tE0pqu2LFr0KjQlYbICyhS4cTtuAonKEwQr0i Nhsg==
MIME-Version: 1.0
X-Received: by 10.194.202.229 with SMTP id kl5mr1534wjc.86.1399921168907; Mon, 12 May 2014 11:59:28 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Mon, 12 May 2014 11:59:28 -0700 (PDT)
In-Reply-To: <5370F349.7050006@alvestrand.no>
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>
Date: Mon, 12 May 2014 11:59:28 -0700
Message-ID: <CABkgnnWfAYTUBrrbu=m_j0=S3uBw4Cf7PBDi3ZmAGHsUMBX1kQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/juRiNyv_l_knbpasU6tz1wMTB9Q
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 18:59:38 -0000

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.

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
>