Re: [MMUSIC] Trickle ICE

"Olle E. Johansson" <oej@edvina.net> Thu, 11 October 2012 20:00 UTC

Return-Path: <oej@edvina.net>
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 89AEF1F0C3E for <mmusic@ietfa.amsl.com>; Thu, 11 Oct 2012 13:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 0Qn3SdOWuuUM for <mmusic@ietfa.amsl.com>; Thu, 11 Oct 2012 13:00:25 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 53E4521F862B for <mmusic@ietf.org>; Thu, 11 Oct 2012 13:00:24 -0700 (PDT)
Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6B3E6754A8A7; Thu, 11 Oct 2012 20:00:22 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se>
Date: Thu, 11 Oct 2012 22:00:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <39EF1F75-DE97-4175-89A5-6A26278883A5@edvina.net>
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>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1499)
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: Thu, 11 Oct 2012 20:00:26 -0000

11 okt 2012 kl. 11:53 skrev Christer Holmberg <christer.holmberg@ericsson.com>:

> Hi,
> 
> 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),
>> 
>> Right, but we were hoping this would happen in a separate spec that
>> details use of trickle ICE with SIP.

I think that we should start that work in parallell. Doing trickle ICE with SIP O/A
can be trick(l)y and the solution for that may affect the Trickly ICE core.

I do think trickle ICE will help SIP quite a lot, especially in a b2bua situation.

/O

>> 
>>> 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.
>> 
>> Yes, that was the idea. The way 3840 describes it in Section 8.
>> 
>>> 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",
>> 
>> I was just about to say that ;).
>> 
>> But, seriously, determining and negotiating caps happens very
>> differently in different signalling protocols, so it doesn't seem
>> reasonable to try and find answers for all of them in the generic
>> trickle ICE spec.
>> 
>> XMPP for example, has this part covered pretty well. If we determine
>> that 3840 does not provide a way of doing the same then we can find
>> another way for SIP.
>> 
>> Eric had this idea, where a trickle ICE agent would simply fire a first
>> offer that only other trickle ICE agents would accept and that any other
>> SIP endpoint would answer with an error. This would be enough of a check
>> and if it fails the caller can fall back to vanilla ICE.
> 
> Sure, but that is not checking for trickle support before sending the trickle offer :)
> 
> Also, I guess I still haven't completely understood the backward compatibility issue, but I guess I need to do some more reading.
> 
>> Another option would be for trickle ICE agents to send empty INVITEs
>> that somehow indicate they will be trickling but contain no actual
>> offer. The offer that the remote side then adds in an OK response (or a
>> provisional one) would clearly indicate whether they support vanilla,
>> trickle, or no ICE at all, so the trickle agent would be able to answer
>> accordingly with the ACK.
> 
> I don't think we want to rely on empty INVITEs either, because there are a number of issues related to that.
> 
>>> we could do the same for BUNDLE, and we wouldn't have issues with
>>> re-using the same ports in multiple m- lines etc :)
>> 
>> Well, we are not saying that they should not be addressed at all, or
>> even now. Just that maybe they shouldn't be addressed by this specific
>> document.
> 
> Perhaps we shouldn't say anything about finding out in advance, then. At least not use SHOULD. 
> 
> We CAN describe what may happen if the remote peer does not support trickle ICE, but leave it to that.
> 
> 
> 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.
>> 
>> Good point! I think the text is indeed a bit unclear in that regard and
>> we might be making some non-stated assumptions about the relation
>> between 3264 Offer/Answer, the actual call answering, and the
>> connectivity checks phase. We'll fix this.
> 
> Thanx! :)
> 
> 
> 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.
>> 
>> Yes, sounds useful. Do you have any specific use cases in mind?
> 
> Well, I guess any case where the remote peer knows it has a public IP address (it will most likely be an ICE lite entity).
> 
>> I am also wondering what would happen if the answerer says "enough" too
>> early in the process and causes negotiation to fail. Is there a reason
>> why an agent would be willing to risk that? Or are we going to say that
>> it would only do that after finding at least one valid pair for every
>> component?
> 
> Well, the indication could mean please-try-whether-the-candidate-works-before-you-send-me-additional-ones :)
> 
> Regards,
> 
> Christer
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic