Re: [MMUSIC] Trickle ICE

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 10 October 2012 18:18 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 BF03F21F84F9 for <mmusic@ietfa.amsl.com>; Wed, 10 Oct 2012 11:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.108
X-Spam-Level:
X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 9Tymbi5W58t2 for <mmusic@ietfa.amsl.com>; Wed, 10 Oct 2012 11:18:53 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A449D21F84D5 for <mmusic@ietf.org>; Wed, 10 Oct 2012 11:18:52 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-74-5075bc0a3151
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 91.D9.25676.A0CB5705; Wed, 10 Oct 2012 20:18:50 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 10 Oct 2012 20:18:50 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Emil Ivov <emcho@jitsi.org>, MMUSIC IETF WG <mmusic@ietf.org>
Date: Wed, 10 Oct 2012 20:18:49 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2m87HnACo1FkrWQ+uPdBOjq/I3SQABO+FW
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org>
In-Reply-To: <5075864F.3030700@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrS7XntIAg7v9uhZrdk5gsZi6/DGL A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgytjxfTNzwQa5igk/W5gbGHdKdDFyckgImEhs u3OMDcIWk7hwbz2QzcUhJHCKUWLr4QmsIAkhgbmMEgs/unUxcnCwCVhIdP/TBgmLCDhKXGs5 D9bLIqAqcXv5aiYQW1hAUeLW8U1sEDVKEs+fT2KFsI0kpnU0M4PYvALhEpfetbNBjI+T6Dv8 EyzOKaApcXbJVrA4I9A930+tAZvJLCAucevJfCaIOwUkluw5zwxhi0q8fPyPFaJeVOJO+3pG iHodiQW7P7FB2NoSyxa+htorKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFM5NzMxJLzfS Sy3KTC4uzs/TK07dxAiMj4NbfqvuYLxzTuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGLu8y69tNTukdDEp6U/E8Zp31pP+iV09oHd80UEZf8OTnjfZvL40bMor3pDT v+Xg7e/BxyO4V1gtX32Q65LY8ienf0zRlot75m6ayrH25Lv3SlGuzzZzzzhYc6P8Jf/Jy5Of 6FY0t3/0zY1audQ3pU6aJTZOs070/XlXs34elw8716oKnPBfMkuJpTgj0VCLuag4EQDURKjZ XQIAAA==
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: Wed, 10 Oct 2012 18:18:53 -0000

Hi,

Thanks for submitting the document!

A couple of initial comments.


Q1: Remote endpoint support (SIP):
--------------------------------------------

You say that, before the first offer is sent, one SHOULD determine whether the remote endpoint supports trickle ICE. 

For SIP, you give RFC 3840 as an example. I am not sure how that will work. Yes, you can use 3840 to request that the offer is sent to an entity which supports trickle ICE (for that, btw, you will also need to define an option tag, or something similar), but you cannot use it to determine whether the remote endpoint supports trickle ICE. In addition, you typically use 3840 at the same time when you send the initial offer.

Of course, you could use SIP OPTIONS. But, there are a number of issues related to that, and I don't think we want to define a mechanism which relies on the usage of OPTIONS.

And, if we simply say that it's "outside the scope of the document", we could do the same for BUNDLE, and we wouldn't have issues with re-using the same ports in multiple m- lines etc :)



Q2: Offer/Answer Alignment:
------------------------------------

I assume the offers and answer are sent according to the rules in RFC 3264.

If so, when you talk about offers and/or answers "being sent at any point", I think it needs to be clear that it's within the rules of 3264.


Q3: Enough is enough:
----------------------------

I think it could be useful for the answerer to tell the offerer that it doesn't want/need any more candidates.




Thanks!

Regards,

Christer





________________________________________
From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Emil Ivov [emcho@jitsi.org]
Sent: Wednesday, October 10, 2012 5:29 PM
To: MMUSIC IETF WG
Subject: [MMUSIC] Trickle ICE

Hey all,

Eric, Justin and I have just submitted a first version of the
specification of a mechanism for incremental provisioning of ICE
candidates, also known as "Trickle ICE".

The spec is in an early state and will undoubtedly see a lot of changes
as implementations progress. It does however describe the main idea so
comments and questions are most welcome!

Cheers,
Emil


-------- Original Message --------
Subject: New Version Notification for
draft-rescorla-mmusic-ice-trickle-00.txt
Date: Wed, 10 Oct 2012 07:16:00 -0700
From: internet-drafts@ietf.org
To: emcho@jitsi.org
CC: justin@uberti.name, ekr@rtfm.com


A new version of I-D, draft-rescorla-mmusic-ice-trickle-00.txt
has been successfully submitted by Emil Ivov and posted to the
IETF repository.

Filename:        draft-rescorla-mmusic-ice-trickle
Revision:        00
Title:           Trickle ICE: Incremental Provisioning of Candidates for the
Interactive Connectivity Establishment (ICE) Protocol
Creation date:   2012-10-10
WG ID:           Individual Submission
Number of pages: 14
URL:
http://www.ietf.org/internet-drafts/draft-rescorla-mmusic-ice-trickle-00.txt
Status:
http://datatracker.ietf.org/doc/draft-rescorla-mmusic-ice-trickle
Htmlized:
http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00


Abstract:
   This document describes an extension to the Interactive Connectivity
   Establishment (ICE) protocol that allows ICE agents to send and
   receive candidates incrementally rather than exchanging complete
   lists.  With such incremental provisioning, ICE agents can begin
   connectivity checks while they are still gathering candidates and
   considerably shorten the time necessary for ICE processing to
   complete.

   The above mechanism is also referred to as "trickle ICE".





The IETF Secretariat




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic