Re: [MMUSIC] Trickle ICE for SIP Questions

"Stach, Thomas" <thomas.stach@siemens-enterprise.com> Sun, 28 July 2013 14:37 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 1D91021F9DA9 for <mmusic@ietfa.amsl.com>; Sun, 28 Jul 2013 07:37:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPeWNOU76Dd1 for <mmusic@ietfa.amsl.com>; Sun, 28 Jul 2013 07:36:52 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 180BF21F9C4E for <mmusic@ietf.org>; Sun, 28 Jul 2013 07:36:48 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 8C6A923F04AE; Sun, 28 Jul 2013 16:36:46 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.30]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Sun, 28 Jul 2013 16:36:46 +0200
From: "Stach, Thomas" <thomas.stach@siemens-enterprise.com>
To: Emil Ivov <emcho@jitsi.org>, Alan Johnston <alan.b.johnston@gmail.com>
Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions
Thread-Index: AQHOiB3rOpQLK3xMc0CKfL3MA1dNd5lzc2MAgAAEQYCABrTt4A==
Date: Sun, 28 Jul 2013 14:36:46 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE1214978846@MCHP04MSX.global-ad.net>
References: <51D43186.2010907@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB1136080A7@xmb-aln-x02.cisco.com> <CAKhHsXH5+58am748qLsojC_kzdgfEpkEy5GM_XTRN5MPMMVWcw@mail.gmail.com> <51EFA5DD.3000805@jitsi.org>
In-Reply-To: <51EFA5DD.3000805@jitsi.org>
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
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, MMUSIC IETF WG <mmusic@ietf.org>
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: Sun, 28 Jul 2013 14:37:02 -0000

... chiming in after vacation

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Emil Ivov
> Sent: Wednesday, 24 July, 2013 12:01
> To: Alan Johnston
> Cc: Cullen Jennings (fluffy); MMUSIC IETF WG
> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
> 
> Hey Alan, Cullen,
> 
> On 24.07.13, 11:45, Alan Johnston wrote:
> > Agree with Cullen - if there is a reasonable approach (such as
> > retransmitting 180) that avoids PRACK, then we should use this
> approach.
> 
> There is one and it comes down to requiring the remote side to send an
> INFO request as soon as it gets it. The INFO request could contain
> trickled candidates (in the case of full trickle) or just
> end-of-candidates (in the case of half-trickle).
> 
> This could work and, personally, I have no issue with it.
[TS] I think this also works for me.
> 
> I believe the suggestion that Christer made was: given how the above
> basically works as a PRACK minus the O/A and given how the O/A in
> PRACKs
> seems to be a deal breaker for many, 
[TS] It is not only the O/A in PRACK, but also the arbitrary number of further O/As in UPDATEs before the 200OK to the initial INVITE.
> then we might want to generalize
> the above mechanism so that other specs can also use it.
[TS] Yes, I think that would be good. 
Paul also seemed to propose to do something generic with my INFO/481/ re-send 18x proposal. 
http://www.ietf.org/mail-archive/web/mmusic/current/msg11754.html 
I liked that as well, but as said above I could also live with acknowledging the 18x with an immediate INFO from the UAC.
Regards 
Thomas
> 
> Cheers,
> Emil
> 
> 
> > - Alan -
> >
> >
> > On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy)
> > <fluffy@cisco.com <mailto:fluffy@cisco.com>> wrote:
> >
> >
> >     I prefer the 180 resend approach and all the right things are
> >     already looking at them.  I have always objected to mandating use
> of
> >     PRACK. Obviously I'm fine with things that have PRACK can use it
> but
> >     I want some solution for things that don't.
> >
> >     One small note, the SDP in the 180 can change as long as the to-
> tag
> >     is also changed.
> >
> >
> >
> >     On Jul 3, 2013, at 8:13 AM, Emil Ivov <emcho@jitsi.org
> >     <mailto:emcho@jitsi.org>> wrote:
> >
> >      > 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.
> >     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.
> >      >
> >      > 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?
> >      >
> >      > 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. A drawback here would obviously
> be
> >     that this adds more complexity for trickle ICE users (WebRTC
> >     applications specifically)
> >      >
> >      > A third option would be to allow both and leave it to the
> >     application.
> >      >
> >      > Comments are most welcome!
> >      >
> >      > Emil
> >      >
> >      > --
> >      > https://jitsi.org
> >      > _______________________________________________
> >      > mmusic mailing list
> >      > mmusic@ietf.org <mailto:mmusic@ietf.org>
> >      > https://www.ietf.org/mailman/listinfo/mmusic
> >
> >     _______________________________________________
> >     mmusic mailing list
> >     mmusic@ietf.org <mailto:mmusic@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/mmusic
> >
> >
> 
> --
> https://jitsi.org
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic