Re: [MMUSIC] Trickle ICE for SIP Questions
"Stach, Thomas" <thomas.stach@siemens-enterprise.com> Mon, 08 July 2013 09:44 UTC
Return-Path: <thomas.stach@siemens-enterprise.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 A2B8A11E81BA for <mmusic@ietfa.amsl.com>; Mon, 8 Jul 2013 02:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_19=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAcwH-3W9d4f for <mmusic@ietfa.amsl.com>; Mon, 8 Jul 2013 02:44:16 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id ADB0F11E819F for <mmusic@ietf.org>; Mon, 8 Jul 2013 02:44:15 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 18AEF1EB85A4; Mon, 8 Jul 2013 11:44:15 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Mon, 8 Jul 2013 11:44:14 +0200
From: "Stach, Thomas" <thomas.stach@siemens-enterprise.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions
Thread-Index: AQHOd/eUM0XqJDBgnkG3edAtUHILLJlUd8BAgAGKMgCAACstAIAEXPYA
Date: Mon, 08 Jul 2013 09:44:14 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE12114A1153@MCHP04MSX.global-ad.net>
References: <51D43186.2010907@jitsi.org> <F81CEE99482EFE438DAE2A652361EE12114A0200@MCHP04MSX.global-ad.net> <51D6D456.7090900@jitsi.org> <51D6F88E.5000209@alum.mit.edu>
In-Reply-To: <51D6F88E.5000209@alum.mit.edu>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
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: Mon, 08 Jul 2013 09:44:25 -0000
Paul, inline > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, 05 July, 2013 18:47 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions > > On 7/5/13 10:12 AM, Emil Ivov wrote: > > Hey Thomas > > > > On 04.07.13, 15:15, Stach, Thomas wrote: > >> Emil, > >> inline > >> > >>> -----Original Message----- > >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >>> Behalf Of Emil Ivov > >>> Sent: Wednesday, 03 July, 2013 16:13 > >>> To: MMUSIC IETF WG > >>> Subject: [MMUSIC] Trickle ICE for SIP Questions > >>> > >>> Hey all, > >>> > >>> Christer, Enrico and I are preparing the next version of Trickle > ICE > >>> for > >>> SIP. Now that discussions on BUNDLE and the plans seem to be > winding > >>> down, we wanted to run a few questions by the working group. > >>> > >>> Q1: Making reliable provisional responses and PRACK mandatory. > > Yes. > > >>> Obviously > >>> this would be nice to avoid, so the question is: is there a > reasonable > >>> mechanism to achieve this (and by reasonable, we mean something > that > >>> wouldn't be harder than implementing support for PRACK). > >>> > >>> There was some discussion about this back in April and there was a > >>> suggestion for implementing a 5245-style hack where the answerer > >>> basically resends the 180 until it knows that it has been received. > >>> > >>> 5245 uses connectivity checks for this (i.e. it stops 180 > >>> retransmissions when the first connectivity check is received) but > we > >>> don't have that option here since the 180 may contain either none > or > >>> only host candidates so there are strong chances that no binding > >>> request > >>> would be received on them. > >>> > >>> Thomas also suggested a second option which would be to also use > INFO > >>> requests with trickled candidates as an indication that 180 was > >>> received. This however wouldn't work with half trickle so we are > >>> basically back to vanilla ICE for all (non-re) INVITEs. > >>> > >>> Another option would be to mandate an INFO request with > >>> "end-of-candidates" in response to the 180, but that would be just > the > >>> same as mandating PRACK support. > >>> > >>> Thomas also suggested that the answerer can start sending INFOs > right > >>> after it sends its answer in the 180 and then it can just resend > the > >>> 180 > >>> if the INFOs result in a 481 response. > >>> > >>> Personally I think this could potentially be made to work, but it > would > >>> imply a level of complexity that considerably exceeds PRACK > support. > >> [TS] I'm not convinced about the different level of complexity. > >> If you use PRACK you have SIP timer T1 running and would re-transmit > >> the 180 in case that the PRACK is not received. > > > > Right. > > > >> Assuming that you want to wait with sending of the INFO until you > saw > >> the PRACK, would lead to delay in that case. > > > > True. Is this the only problem that we are trying to optimize? Save > half > > an RTT? (This is a really a question. I am not trying to make a > point. I > > am simply trying to understand why PRACK is an issue.) > > Yes, why is it such an issue to require PRACK? [TS] I see potential for easier GW/SBC interworking with vanilla-ICE UAs, that did not implement PRACK > It is a good thing to implement for many reasons. [TS] There are also good reasons against PRACK. e.g. the much more complicated state machine. So in conjunction > with > defining other new functionality, why not require it? [TS] We did not need to require PRACK for vanilla ICE, why require it now. There is a proposal on the table that solves the problem without the complexity of PRACK. As already said I don't object to recommending PRACK (as in 5245), I just don't want it mandatory. > > >> If you don't wait you would also have to treat a 481 response to the > >> INFO. > > > > I am always a bit nervous when it comes to interpreting error > responses. > > We are indeed likely to get a 481 when sending INFOs and the 180 > hasn't > > yet made it to the remote side. However 481 might also imply that our > > dialog is simply dead for some reason and in this case 3261 says: > > > > > > If the response for a request within a dialog is a 481 > > (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the > UAC > > SHOULD terminate the dialog. > > > >> ... and you would detect quicker that the 180 was lost than by > waiting > >> for the PRACK. > > This just highlights how "delicate" things get if you start trying to > work around the lack of PRACK. It might be possible to get something > that seems to work, but its a house of cards. [TS] Please refer to my reply to Emil, the rule above does not apply here. > > > As said above: a lost 180 is not the only possible cause for a 408 in > > this case. > > > >> BTW: 5245 recommends to use PRACK. However it does not mandate it, > but > >> gives the alternative procedures as an option. > >> You could do the same here. > > > > Of course. I should have made that clearer: all alternative > approaches > > were meant as something we could have in addition to the PRACK one. > > > > Also, keep in mind that the 180 carries an entire SDP answer. If > INFOs > > are competing with 180s then they may potentially need to carry that > too > > (or at least the ICE parts) and it would be good if we don't have to > > open that can of worms. > > Yes. The trickle ICE INFOs are *relative* to what was set up in the > O/A. > In the absence of the answer the trickle ICE is problematic. > > >>> Opinions? > >>> > >>> Q2: How do we send INFOs? Are they blocking or do we just send them > in > >>> parallel? If the latter, then what happens when an INFO fails > because > >>> it > >>> is received out of order? Do we just tell the application to resend > the > >>> candidates asap? > > *If* you are going to send in a non-blocking way then they should be > cumulative. > > If you treat them as blocking, then they don't have to be, but it might > still be better. > > >> [TS] I would go with the proposal below and send cumulatively. You > >> also have the CSeq: header field to detect late arrivals. > > Yes, you can detect the late arrival. But you have at that point > already > acted on the one that should have been preceded by it. [TS] What is the problem? The previous INFO had fewer candidates, you just got all additional candidates. I can't see a case were a candidate got removed in a subsequent INFO. > > >>> This also leads to the following question: > >>> > >>> Q3: What exactly do we send in INFOs? Just the latest batch of > freshly > >>> learned candidates or all candidates we've learned so far? Dale > >>> suggested that if we do this cumulatively we wouldn't need to worry > >>> about the case with the out-of-order INFOs from Q2 since the > >>> information > >>> gets resent anyway. > > Exactly. > > >>> A drawback here would obviously be that this adds > >>> more complexity for trickle ICE users (WebRTC applications > >>> specifically) > >> [TS] Again I'm not convinced about the complexity. Both peer know > >> their candidates, what is the issue in putting all of them into the > INFO? > > > > I am not sure how current WebRTC stacks handle provisioning of > repeating > > candidates. If they don't then it would be up to the receiving JS > app, > > to sort our which are the new candidates and which were already > there. > > > > The sending side would be similarly tricky for a JS app: it would > need > > to construct SDP so that the a=candidate attributes appear under the > > right "a=mid" line. > > I don't know enough about ICE to comment specifically on this. > > But ISTM that this is analogous to what a SIP device must do to manage > the target set of destinations for a request - it is required to keep > track and not add the same address to the target set more than once. > > Thanks, > Paul > > >>> A third option would be to allow both and leave it to the > application. > >> [TS] This now adds complexity. ;-) > > > > Likely yes. > > > > Emil > > > >> I would just always send all candidates. > > > > > > > > > >> Regards > >> Thomas > >>> > >>> Comments are most welcome! > >>> > >>> Emil > >>> > >>> -- > >>> https://jitsi.org > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >> > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Dan Wing
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Marc Petit-Huguenin
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Marc Petit-Huguenin
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Marc Petit-Huguenin
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Cullen Jennings (fluffy)
- Re: [MMUSIC] Trickle ICE for SIP Questions Alan Johnston
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Parthasarathi R
- Re: [MMUSIC] Trickle ICE for SIP Questions Vijaya Mandava (vimandav)
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Cullen Jennings (fluffy)
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Parthasarathi R
- Re: [MMUSIC] Trickle ICE for SIP Questions Parthasarathi R
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Vijaya Mandava (vimandav)
- Re: [MMUSIC] Trickle ICE for SIP Questions Parthasarathi R
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- [MMUSIC] UPDATE vs INFO for SIP Trickle ICE [was … Parthasarathi R