Re: [MMUSIC] Trickle ICE
Emil Ivov <emcho@jitsi.org> Thu, 11 October 2012 21:34 UTC
Return-Path: <emil@sip-communicator.org>
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 4118A1F0C4A for <mmusic@ietfa.amsl.com>; Thu, 11 Oct 2012 14:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 J6+cI1Qa5-he for <mmusic@ietfa.amsl.com>; Thu, 11 Oct 2012 14:34:48 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id D426A1F041F for <mmusic@ietf.org>; Thu, 11 Oct 2012 14:34:45 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so2359788wib.13 for <mmusic@ietf.org>; Thu, 11 Oct 2012 14:34:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=BmB02Cgvz6vCPYXAtrUGyV91gqTFPLSMms2/PN86gkE=; b=hud16YRzZxV5dL6yitceRij7ixKvrNsecFNNXD6vOiFcYhcpAfxwP2rPlCy5lj5Xh6 fViP/X1c17mU+YznZQPU4qCOJe8kVH7qv6j9+7UWB88LBa7lPd/XRgNe5Mvi19n4sQEK QNRgF7Q99isZakjccnMOFv8NsCbsIgfgCsg3xFyy8D4NWepI4GMPNC/1gAYAQbzKb7ec a2dqZoK2dPYei/8FcjeuacA2eaND0sHlBxvS4QVo9ScPl+vdSzMDiV5hFSdS8a50yUWR zbLAYAFSjtcVykf/tA0++qv4+59TwAW5mDfjTzkdLgFub/5x+Q2ZSKy8A/GZ70ome8HZ MgRg==
Received: by 10.181.13.239 with SMTP id fb15mr834853wid.22.1349991284934; Thu, 11 Oct 2012 14:34:44 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:8495:bad6:30a7:8ed9]) by mx.google.com with ESMTPS id p4sm723347wix.0.2012.10.11.14.34.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Oct 2012 14:34:44 -0700 (PDT)
Message-ID: <50773B73.6060508@jitsi.org>
Date: Thu, 11 Oct 2012 23:34:43 +0200
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
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> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnB1GGeb9YyMrzFwthGhzdvxnAI6gQomXRAIcW5WXo8s1upHRsxEybUW5YcWpquVwbEsiOi
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 21:34:49 -0000
Hey Christer, On 11.10.12, 21:23, Christer Holmberg wrote: > > 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. >>>> >>>>> 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 :) >> >> Yes, the wording may need to be reviewed if we go for this. >> >>> Also, I guess I still haven't completely understood the backward >>> compatibility issue, but I guess I need to do some more reading. >> >> We describe these in Section 3 but the main problem is that a >> vanilla ICE agent that gets a first subset of candidates (that may >> also be empty) would declare failure prematurely. > > The text gives an example where the receiver (Bob) receives a > host-candidate-only offer, and start checks which fail. > > I think it's quite strange if Bob would reject the call at that > point. Because, no matter how many candidates the offer contains, > there might still be peer reflexive candidates created later, How does Bob know that there's going to be a "later" ? It's just a vanilla ICE agent that assumed it received a full set of candidates, it checked them all, all checks failed. Now, we could rely on Bob not doing anything rash and waiting patiently for reINVITEs from Alice in order to get more candidates ... but that might be about as risky as relying on empty INVITEs to be handled properly by everyone or on OPTIONS to be transmitted end-to-end. Besides there are other possible failures, like for example the case where I get your server reflexive candidates long before you get mine so we perform checks out of sync (the case that I also described in my other mail to Martin). > once > the offerer (Alice) starts sending the STUN binding requests. So, one > would think that Bob at least would wait for those. > >>>> 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. >> >> Well, it might be worth investigating exactly what they are. The >> same applies to using OPTIONS and 3840. > > Well, to start with, empty INVITEs will work very badly with legacy. You mean, because legacy devices don't properly implement 3261 in that regard? That might actually be a good thing. An error response at this point would be a good indication that there's no trickle ICE support at the remote side. > In addition, there migth be other functions which do not work with > empty INVITEs. OK, I agree. It's a clumsy solution at best. It would be impossible for SIP user agents to translate a user request to start an audio, audio/video or some other media session (which is the typical rant you get for handling empty INVITEs). It was just a thought :) > And, I am not sure how it would work with JSEP. You mean, in cases of gatewaying SIP to WebRTC? I suppose it could just be translated to some custom signalling that actually does capability negotiation and then triggers a remote INVITE ... OK I know, it's a stretch. > > >>>>>> 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. >>> >>> What we'd like to avoid is having trickle ICE offers to vanilla >>> ICE agents and then having them fail in a user-perceptible way. >>> >> Maybe we could modify the "SHOULD verify support" to "SHOULD verify >> support or provide a mechanism for transparent fallback to vanilla >> ICE" > > In my opinion, if one has to do something extra (e.g. send OPTIONS), > the whole idea of trickle-ICE goes away, because at the end of the > day you won't save any time in call establishment. The OPTIONS request does not need to be sent right before the call. It can be done once, upon bootstrap. > Now, if the browser is communicating with a ICE terminating gateway, > and if the browser performs SIP registration, then the gateway can > indicate trickle-ICE during registration. > > But, in the peer-to-peer case I don't know how it would work. It's > not even sure OPTIONS would reach the same remote peer as the > INVITE... I agree. Not sure what to say other than, I agree that SIP does not have good mechanisms for XMPP like negotiation of entity caps but, personally, I do believe that finding one would be helpful here. Maybe we can work on making sure that 3840 (or some other mechanism) would better allow for caps to be discovered in advance. At the very least, if we can't find a way to do this gracefully with SIP, we can RECOMMEND it whenever the protocol allows it and try to devise a fall back strategy when it does not (e.g. with SIP). > 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). >> >> Right, but in such cases the offerer would also know that a certain >> pair has succeeded so if they continue it might be with the purpose >> of finding a better RTT or a higher priority local candidate. >> >> I guess what I am trying to say is that a Binding Response is >> enough of an indication that trickling can stop. If it doesn't then >> maybe it's for a reason. > > Maybe it is enough... In any case I think it would be good to > document :) OK. Agreed. > Also, at least in cases where the remote peer only provide a host > candidate (because it has a public IP address), one should be smart > enough to figure out that there most likely will be no better > alternative. I am not sure I got this. Cheers, Emil > > > Regards, > > Christer > >
- [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