Re: [MMUSIC] immortal candidates in ICE nombis

Bernard Aboba <bernard_aboba@hotmail.com> Sun, 29 March 2015 23:10 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6821A870B for <mmusic@ietfa.amsl.com>; Sun, 29 Mar 2015 16:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level:
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 L5hLclu6F9LF for <mmusic@ietfa.amsl.com>; Sun, 29 Mar 2015 16:10:25 -0700 (PDT)
Received: from BLU004-OMC3S20.hotmail.com (blu004-omc3s20.hotmail.com [65.55.116.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123511A8706 for <mmusic@ietf.org>; Sun, 29 Mar 2015 16:10:25 -0700 (PDT)
Received: from BLU406-EAS408 ([65.55.116.73]) by BLU004-OMC3S20.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 29 Mar 2015 16:10:24 -0700
X-TMN: [d6y12Id5D2gZ4VuJI1yzOdcR7qb/JPnpaYnSdvNOK2c=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU406-EAS408220E92101854D3559AD993F60@phx.gbl>
Content-Type: multipart/alternative; boundary="Apple-Mail-5E109476-5CD1-46CE-A5E1-68EF1E818823"
Content-Transfer-Encoding: 7bit
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
Date: Sun, 29 Mar 2015 16:10:23 -0700
References: <551583F4.6090200@jitsi.org> <BLU181-W7379CD8B6BF40C842E78E993090@phx.gbl> <7594FB04B1934943A5C02806D1A2204B1D781FD8@ESESSMB209.ericsson.se> <BLU181-W90CB44BE885C8F1491E90F93F60@phx.gbl> <7594FB04B1934943A5C02806D1A2204B1D783C6A@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D783C6A@ESESSMB209.ericsson.se>
X-OriginalArrivalTime: 29 Mar 2015 23:10:24.0348 (UTC) FILETIME=[897309C0:01D06A75]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/r03wsxhXwigCuMlxJ3mo1xpL-BQ>
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] immortal candidates in ICE nombis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 29 Mar 2015 23:10:27 -0000

On Mar 29, 2015, at 3:45 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>  
> I for sure think it would be good to not having to send consent requests on candidates that are currently not used (for whatever reason) for sending data/media.
>  
> But, assume you would take an interface out of service, and stop sending consent requests from the associated candidate. The remote endpoint does not know what you did - it will keep sending consent requests to that interface, and revoke consent when it doesn’t get any replies.

[BA] Yes - which is why there needs to be a way to indicate that the candidate has been removed (e.g. The timeout == 0 indication Justin spoke about). 

> Of course, the remote endpoint could be smart enough and, once it starts receiving consent requests from the interface again, also start re-sending consent requests to that interface itself, and retrieve new consent. But, such behaviour is not defined in the consent freshness draft.

[BA] Prior to the consent expiration that might work. But afterward even absent the draft language the lack of NAT binding maintenance would likely become a problem preventing 
one side from restarting things by itself.  In that case the candidate would need to be trickled again, which is not possible without an ICE restart today.