Re: [MMUSIC] Trickle ICE for SIP Questions

Marc Petit-Huguenin <petithug@acm.org> Fri, 05 July 2013 23:14 UTC

Return-Path: <petithug@acm.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 7101C21F9B4D for <mmusic@ietfa.amsl.com>; Fri, 5 Jul 2013 16:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level:
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 SDvwftO7bkrX for <mmusic@ietfa.amsl.com>; Fri, 5 Jul 2013 16:14:42 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 635BB21F9A13 for <mmusic@ietf.org>; Fri, 5 Jul 2013 16:14:37 -0700 (PDT)
Received: from [IPv6:2601:9:4b80:4a:68a3:ec9a:408:988c] (unknown [IPv6:2601:9:4b80:4a:68a3:ec9a:408:988c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 62BAB20415; Sat, 6 Jul 2013 01:14:36 +0200 (CEST)
Message-ID: <51D75359.30409@acm.org>
Date: Fri, 05 Jul 2013 16:14:33 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: Emil Ivov <emcho@jitsi.org>
References: <51D43186.2010907@jitsi.org> <51D70236.5070508@acm.org> <CAPvvaaK2QGvSaw1HFGZ7F4maJzoDDF+EMDeq4zRaiJ8iJdxsHQ@mail.gmail.com> <51D74C85.2080700@acm.org> <51D74E6A.7020902@jitsi.org>
In-Reply-To: <51D74E6A.7020902@jitsi.org>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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: Fri, 05 Jul 2013 23:14:43 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/05/2013 03:53 PM, Emil Ivov wrote:
> 
> 
> On 06.07.13, 00:45, Marc Petit-Huguenin wrote: On 07/05/2013 02:59 PM, Emil
> Ivov wrote:
>>>> On Fri, Jul 5, 2013 at 7:28 PM, Marc Petit-Huguenin
>>>> <petithug@acm.org> wrote: Hi,
>>>> 
>>>> I did not receive much comments on my proposal to use STUN packets
>>>> to carry the new ICE candidates.  To summarize, instead of using the
>>>> SDP in an INFO and or UPDATE transaction, the new candidates can be
>>>> sent on the same path that the media will use by default (i.e. using
>>>> the candidate that is copied in the m= and c= line).  Because this
>>>> candidate is chosen to always succeed (using a TURN server), the
>>>> candidate will always reach their destination.  This will remove any
>>>> problem in the signaling path, because it is no longer used to update
>>>> the candidates.
>>>> 
>>>>> Here's my take: Default candidates are not guaranteed to work.
> 
> Sorry, my summary was incorrect.  It is assumed that half-trickle is used
> (for the same reason than in draft-ivov-mmusic-trickle-ice-sip section 3),
> so the offerer sends the full set of candidates.
> 
>> Are you suggesting that we would always need to do half trickle, even
>> when we know the other party has support for trickle and can switch to
>> full?

No, I just am saying that the solution that I propose does not take in account
full-trickle.

> 
>>>>> Also, you only get to place one candidate as default. What if your
>>>>> peer is IPv6 only and you chose an IPv4 candidate?
> 
> With the offerer full set of candidates, it is easy to find the IPv6 TURN 
> candidate.
> 
>>>> Or, what if you are both on the same LAN with
>>>>> limited Internet connectivity? Or what if the service you use
>>>>> doesn't even have a TURN server?
> 
> Then what about sending the answerer candidates using all the offerer 
> candidates available, but in reversed priority order?
> 
>> Even then, endpoint dependent filtering (which seems to be the default
>> these days) requires that both ends start sending packets simultaneously
>> for server-reflexive addresses to work.
> 
>> In the case above the trickled candidates wouldn't be able to reach the
>> offerer because it wouldn't be sending anything toward the answerer.

Right.

> 
>>>>> I am sure we can come up with many other similar situations.
>>>> 
>>>>> The only transport that's guaranteed to work prior to ICE is
>>>>> signalling. There's nothing else that's as reliable as this. (If
>>>>> there was then we probably wouldn't even need ICE in the first
>>>>> place).
> 
> ICE is less about reliability than about latency,
> 
>> I believe it's always been about both. (Otherwise we would have probably
>> stopped at STUN).

You mean TURN?  As long as you do not care about latency, TURN is all you need
as it always works (and that's all we used for a long time, even if it was not
called TURN).  ICE was invented because latency was important - so STUN was
useful - but there is no reliable way to predict if it will work.

> 
> i.e. so far nobody proposed to tunnel the media over SIP :-)
> 
>> You'd be surprised ;)
> 
>> https://java.net/projects/jain-sip-applet-phone

Hmm, I do not see SIP as media transport in this project.  What I meant was
something like transporting the media in a SIP INFO.

> 
>> Emil
> 
>>>> 
>>>>> Emil
>>>> 
>>>>> -- https://jitsi.org
>>>> 
>>>> 
>>>> Thanks.
>>>> 
>>>> On 07/03/2013 07:13 AM, Emil Ivov 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
>>>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________ mmusic mailing list 
>>>> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
>>>> 
> 
>> 
> 

- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJR11NYAAoJECnERZXWan7ECZwP/0skdKa9lXHs4/ogcAR+IFUA
INllP0esEp62ZtB5jOMJ2HrMEqOdyi/kFS1Ya5MnK+l5UzYnxCwDWIxC8EH/RHkp
k8MoT2W98lcIevlSiF1qZnOw8b8EJjUBbM2uQA0r3wiksRL6McbKF1iCnhhIoFOG
W4i8ap7XJYy2vc5SNUcyWyDboIG6lMt2RFAw0FZiHoCZmtSjQBVJUIxqdrfQ0zvA
gFJLnKLSCAyuk7wtpeQhXvys8I4ZmGBx2J2WRORE1lyoxGJm8C0f3Eh+4IsjMcL3
JKgdRiOIpCjBDvtD4mONp+zsVTc6O5+ngn49ew5yUnqE+IEiysMWFvKzQKuwzFqE
q1OYXU8tY3W+r39qcGy8ov0Eiyuyf7i7O5pcMeRGhDvgQZkFxI9iP2ArSEKUSxOZ
FnWBESZ5Z3HkXbbS1Rw+4RxaMOT7DvJzDvKNbfW08DK4lpifPpcNThIvOlHnoO8u
F6iZpuQ8PHYBw3ZFn2255KvwK3LA8vwcKj2ZYSY7btHBg/gP6PoVK2KNewxp+CDa
kn+8SpETE8BcbirJPKoMVxGFMYBQQBnHx9i7ikpDLOxS8G85M6mRnPQdH3D3Gavg
BBgXp+dvMV4hTKz5Kd9BmACUaxD47RAp3Faplrq/lmDcC3xqsLmqu0/C5UdPR5Jm
CzjedrEUr+QNmpmd/VFU
=sbN1
-----END PGP SIGNATURE-----