Re: [MMUSIC] Trickle ICE

Emil Ivov <emcho@jitsi.org> Fri, 12 October 2012 18:55 UTC

Return-Path: <emil@sip-communicator.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF17C21F86D6 for <mmusic@ietfa.amsl.com>; Fri, 12 Oct 2012 11:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SfGN5UjDGnz for <mmusic@ietfa.amsl.com>; Fri, 12 Oct 2012 11:55:43 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEE5E21F867A for <mmusic@ietf.org>; Fri, 12 Oct 2012 11:55:42 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so2067667wey.31 for <mmusic@ietf.org>; Fri, 12 Oct 2012 11:55:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=SkNCou0e3lk3MYBe7yVcA/+yp/8rcy/Wg9Jc1eL1b20=; b=V4s/qq68kU7mb1cX/GpoXVn9Qhak+UwRzb1+JHEc+MXgBgnps8lAZG1zsmlARteQou 9Tgn5O9qxmu4v6A62gsNutFsq3xEixjUgWdtil0ITvXXcRQQJSW8+s2+ueyaxrTyCfGd 6dzg9r9G3T7aFJnf31kC6gFk6ee9xEGCLKF7hwZaha9GjZjuUqd8ReJ9Q3a8HVkdzbuH esQE0B0PSwPSl+RzvPd/wVtxKIf2ZcZYwCnEk1HnB4jMLzecG229F2JEB+aAREkpUcFY lCwDWhXWoNAlrWNogh8OyfQGomHU2VM8L45+zeXv8eX+XGBAm13Kx0JYsYLPEX1s/bHS jbHA==
Received: by 10.216.204.130 with SMTP id h2mr3009070weo.202.1350068141992; Fri, 12 Oct 2012 11:55:41 -0700 (PDT)
Received: from camionet.local ([2a01:e35:2e2c:f600:5c2a:e2a8:a4af:298b]) by mx.google.com with ESMTPS id dm3sm5157353wib.3.2012.10.12.11.55.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 11:55:41 -0700 (PDT)
Message-ID: <507867AB.70404@jitsi.org>
Date: Fri, 12 Oct 2012 20:55:39 +0200
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se> <5077FE17.3010800@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCF1D9@ESESSCMS0356.eemea.ericsson.se>, <50782585.9070204@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA87@ESESSCMS0356.eemea.ericsson.se>, <50785E8A.7080903@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA88@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA88@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmvGM7b8ZpjAzLZpPynTJdiv9B5HgwS/OATHgLUpL41uM33s/1FUvFfRonxlSto5ryyKt/F
Cc: MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Oct 2012 18:55:44 -0000

Hey Christer,

On 12.10.12, 20:20, Christer Holmberg wrote:
> Hi,
> 
>>>>>> All in all, making assumptions on the receiving end is
>>>>>> always a risk. If the host sending the candidates knows
>>>>>> that they are its best/only candidates, then it could
>>>>>> indicated so by sending the end-of-candidates message we
>>>>>> describe in the draft.
>>>>> 
>>>>> In case Bob has a public IP address, why does Alice need to
>>>>> send an offer with the additional candidates in the first
>>>>> place? Why not simply start using them, and Bob will process
>>>>> them as peer reflexive candidates?
>>>>> 
>>>>> (I can understand that signaling is needed in case
>>>>> per-candidate ufag/pwd values are used, but let's assume a
>>>>> case where the same values are used for all candidates.)
>>>> 
>>>> My point was that Bobs IP address being public:
>>>> 
>>>> * does not mean it is the best option: VPN, tunnelling, and
>>>> multiple interfaces can all generate public host IP addresses
>>>> that are a lot less preferable to server reflexive ones. * does
>>>> not even guarantee that it's reachable. Connectivity may be 
>>>> administratively prohibited, routes can be down.
>>> 
>>> Alice CAN continue to gather candidates, in case there are
>>> better ones. My question was why she needs to signal them to Bob
>>> in a new offer, instead of simply start sending STUN checks
>>> associated with the candidates? Bob will then process them as
>>> peer reflexive candidates.
>> 
>> She can do that of course. And she should. That's what trickling
>> is about after all. But those checks may fail for the reasons above
>> (second bullet) or simply because Bob has a firewall with
>> endpoint-dependent filtering so it won't let Alice's packets come
>> in unless Bob also starts sending packets to her.
>> 
>> Does this make sense?
> 
> Note that in my use-case Bob has a public IP address, and is an ICE
> lite entity, so Bob won't send any STUN requests to Alice - only
> reply to those received from Alice.

Oh, I had missed the "Lite" part. Sorry about that.

So, yes, right now I can't think of a good reason why Alice would
continue trickling after a successful check in this case.

Emil





-- 
https://jitsi.org