Re: [MMUSIC] Trickle ICE for SIP Questions

"Stach, Thomas" <thomas.stach@siemens-enterprise.com> Mon, 08 July 2013 09:25 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 ADA2621F8D6D for <mmusic@ietfa.amsl.com>; Mon, 8 Jul 2013 02:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 dlxj-2kQvl1p for <mmusic@ietfa.amsl.com>; Mon, 8 Jul 2013 02:25:24 -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 ACE4921F920B for <mmusic@ietf.org>; Mon, 8 Jul 2013 02:25:11 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0A5F71EB85AF; Mon, 8 Jul 2013 11:24:59 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Mon, 8 Jul 2013 11:24:56 +0200
From: "Stach, Thomas" <thomas.stach@siemens-enterprise.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions
Thread-Index: AQHOd/eUM0XqJDBgnkG3edAtUHILLJlUd8BAgAGKMgCABH+3wA==
Date: Mon, 08 Jul 2013 09:24:55 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE12114A1127@MCHP04MSX.global-ad.net>
References: <51D43186.2010907@jitsi.org> <F81CEE99482EFE438DAE2A652361EE12114A0200@MCHP04MSX.global-ad.net> <51D6D456.7090900@jitsi.org>
In-Reply-To: <51D6D456.7090900@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: 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: Mon, 08 Jul 2013 09:25:38 -0000

A few thoughts/response inline

> -----Original Message-----
> From: Emil Ivov [mailto:emcho@jitsi.org]
> Sent: Friday, 05 July, 2013 16:13
> To: Stach, Thomas
> Cc: MMUSIC IETF WG
> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
> 
> 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.
> >> 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.)
[TS] Saving the half RTT is not my primary goal. When implementing ICE we got away without requiring PRACK. 
I want to keep this property, since it allows 
> 
> > 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.
[TS] We are actually specifying new behavior here. 
Thus, we can specify the rule for the new info package and its application for trickle-ICE in way as exact as possible such that there would be no need for interpretation or nervousness.

> 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.
[TS] We are in the dialog establishing phase here and when the 180 was lost we don't even have an early dialog.
So this rule does not apply. The 481 to the INFO would rather be the indicator for this situation. As stated above we can prescribe that the 481 (and only the 481) is to be sent for the INFO and what happens next, i.e. retransmit the 180.
> 
> > ... and you would detect quicker that the 180 was lost than by
> waiting for the PRACK.
> 
> As said above: a lost 180 is not the only possible cause for a 408 in
> this case.
[TS] I assume you mean 481.
> 
> > 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.
[TS] For the trickle-ICE application of the info-package I would just recommend sending (all) the ICE candidates.
This eliminates the competition, you just take what you got last.
> 
> >> 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?
> > [TS] I would go with the proposal below and send cumulatively. You
> also have the CSeq: header field to detect late arrivals.
> >
> >>
> >> 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)
> > [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. 
[TS] As Trickle-ICE is just being specified, we are in a position to specify this handling.
>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.
[TS] As the ICE/STUN logic resides in the browser not in the JS app, this would be a matter of the API definition to always provide all known candidates towards the JS APP for sending. On the receiving side the JS APP would also just have to push all received candidates through the browser API.

Regards
Thomas
> 
> >> 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
> >
> 
> --
> https://jitsi.org