[MMUSIC] Using connectivity check to carry additional candidates [was Re: draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice]

Marc Petit-Huguenin <petithug@acm.org> Fri, 05 April 2013 00:18 UTC

Return-Path: <petithug@acm.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 48E1121F8D8F for <mmusic@ietfa.amsl.com>; Thu, 4 Apr 2013 17:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.486
X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UlqYA68bGEYk for <mmusic@ietfa.amsl.com>; Thu, 4 Apr 2013 17:18:53 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 727F521F8D03 for <mmusic@ietf.org>; Thu, 4 Apr 2013 17:18:53 -0700 (PDT)
Received: from [IPv6:2601:9:4bc0:1f:84a4:8f1c:631d:60ec] (unknown [IPv6:2601:9:4bc0:1f:84a4:8f1c:631d:60ec]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id DAEAD201BF; Fri, 5 Apr 2013 02:18:51 +0200 (CEST)
Message-ID: <515E1868.2010601@acm.org>
Date: Thu, 04 Apr 2013 17:18:48 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: Alan Johnston <alan.b.johnston@gmail.com>
References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515D853C.6020107@alum.mit.edu> <515DC02D.7050105@jitsi.org> <99971244-6523-4025-AF84-1AC72D8E0681@gmail.com>
In-Reply-To: <99971244-6523-4025-AF84-1AC72D8E0681@gmail.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: [MMUSIC] Using connectivity check to carry additional candidates [was Re: draft-ivov-dispatch-trickle-ice-sip/draft-ivov-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, 05 Apr 2013 00:18:54 -0000

Hash: SHA256

On 04/04/2013 12:07 PM, Alan Johnston wrote:
> I admit that my first thought was that UPDATE was more appropriate than
> But the more I think about it, trickling in new candidates is not
> necessarily a part of O/A, rather it can be thought of as communication
> between two ICE Agents. For tunneling another protocol using SIP as
> transport, INFO is the right choice.
> Not every ICE candidate is signaled in SDP - Peer Reflexive Candidates, for
> example.

True.  But so why not push the idea further, and use an in-band mechanism to
send the newly discovered candidates?  E.g. the Offerer still sends the full
list of candidates but the Answered uses the same path than a successful
connectivity check to send its candidates as it discovers them, using a new
STUN transaction.  The Offerer will add the candidates received in this new
transactions more or less in the same way Peer Reflexive Candidates are added,
and start connectivity checks in the other direction. The answered will send
its answer only when it has collected all the candidates on its side, making
it identical to non-trickle ICE.

Obviously there is lot of details missing here, but that solution does not
require UPDATE or INFO, or a=ice-options:trickle.  It's probably not
compatible with non-SIP trickle implementations, but perhaps a gateway can
convert candidates in the signaling path to and from candidates in the media path.

> And remember ICE has a second O/A exchange that brings the SDP into line
> with the chosen candidate pair.

- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
Version: GnuPG v1.4.12 (GNU/Linux)