Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis

"Pal Martinsen (palmarti)" <palmarti@cisco.com> Tue, 22 July 2014 09:57 UTC

Return-Path: <palmarti@cisco.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 EBFDF1A064A for <mmusic@ietfa.amsl.com>; Tue, 22 Jul 2014 02:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 CQA6IwJUBH2P for <mmusic@ietfa.amsl.com>; Tue, 22 Jul 2014 02:57:47 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE02C1A032A for <mmusic@ietf.org>; Tue, 22 Jul 2014 02:57:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1581; q=dns/txt; s=iport; t=1406023067; x=1407232667; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xEnDOh3wqheSHJt5EnNirqJZWn36EhJW9ZvDlSzG9ok=; b=hbSTr+E/en/3o2/5gkS/uyT8sBJlUdoxJo5ymUR4gLPst4QGanGmgh+G 6Pj+flx7sQps2smO41EWocTEjhMNLbmlmjvYL0zXEZ4CdOZB8b9yQVard IOTWIYoWdnjanBkEkZSZ4AoCMHwc2PA8maLdzAcbPXS6Z2+AJCr8v5sfB c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AksFAD41zlOtJA2N/2dsb2JhbABYgw5SVwTHBwqGclMBgREWdoQEAQEDAQEBAWsLBQsCAQgOOCcLJQIEDgUZiCEIDb8+EwSOdyEzB4MugRgFiiyQepQvg0RsgUU
X-IronPort-AV: E=Sophos;i="5.01,709,1400025600"; d="scan'208";a="62937116"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP; 22 Jul 2014 09:57:46 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6M9vj4a021439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 09:57:45 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.80]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 04:57:45 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
Thread-Index: AQHPpSTNMoyao5qjc0uyG0oVeP4rqpusMEwA
Date: Tue, 22 Jul 2014 09:57:44 +0000
Message-ID: <9F57A7FF-0029-4228-931C-0B19A49A81BB@cisco.com>
References: <53CD7C04.8070106@jitsi.org>
In-Reply-To: <53CD7C04.8070106@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.194.214]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2F235BD9604007439643A3B5E5714D14@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/LsSIFO8_Zm5fAqMOI_XUO3iwP2I
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
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: Tue, 22 Jul 2014 09:57:59 -0000

On 21 Jul 2014, at 16:45, Emil Ivov <emcho@jitsi.org> wrote:

> Hey all,
> 
> In London we mentioned the option of adding a new attribute that, during 
> aggressive nomination, the controlling agent can use to notify its peer 
> that ICE processing is over and no more changes are going to be 
> attempted. This way controlled agents will no they can now release 
> resources.
> 
+1

And it makes life somewhat easier for people looking through Wireshark traces trying to figure out why the ICE negotiation failed.

Middle boxes that understand ICE would also benefit from this. (As a side effect, not the main motivation)

> This could either be a new attribute (e.g., USE-CANDIDATE-CONFIRMED) or, 

I prefer this approach. The new attribute will not hurt backwards compatibility, and it is a nice hint to say that this behaviour is supported.

> as Justin suggested in an off-list discussion, we could have the 
> controlling agent send a second USE-CANDIDATE once aggressive nomination 
> converges.

I just want to avoid keeping more states in the ICE machinery. 

Keeping track of how many USE-CANIDATES received with the same USERNAME, but different STUN transaction Ids on the same 5-tuple is just a bit inconvenient. 

Or am I missing something?

.-.
Pål-Erik
 
> 
> Any thoughts?
> 
> Emil
> 
> 
> -- 
> https://jitsi.org
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic