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
- [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Martin Thomson
- Re: [MMUSIC] Trickle ICE Christer Holmberg
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Christer Holmberg
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Martin Thomson
- Re: [MMUSIC] Trickle ICE Martin Thomson
- Re: [MMUSIC] Trickle ICE Christer Holmberg
- Re: [MMUSIC] Trickle ICE Olle E. Johansson
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Lishitao
- Re: [MMUSIC] Trickle ICE Christer Holmberg
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Christer Holmberg
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Martin Thomson
- Re: [MMUSIC] Trickle ICE Martin Thomson
- Re: [MMUSIC] Trickle ICE Christer Holmberg
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Christer Holmberg
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Emil Ivov
- Re: [MMUSIC] Trickle ICE Martin Thomson
- Re: [MMUSIC] Trickle ICE Bernard Aboba
- Re: [MMUSIC] Trickle ICE Christer Holmberg
- Re: [MMUSIC] Trickle ICE Christer Holmberg
- Re: [MMUSIC] Trickle ICE Olle E. Johansson
- Re: [MMUSIC] Trickle ICE Christer Holmberg