Re: [MMUSIC] Trickle ICE for SIP Questions

Marc Petit-Huguenin <> Fri, 05 July 2013 23:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7101C21F9B4D for <>; Fri, 5 Jul 2013 16:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.525
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SDvwftO7bkrX for <>; Fri, 5 Jul 2013 16:14:42 -0700 (PDT)
Received: from ( [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by (Postfix) with ESMTP id 635BB21F9A13 for <>; 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 "" (verified OK)) by (Postfix) with ESMTPS id 62BAB20415; Sat, 6 Jul 2013 01:14:36 +0200 (CEST)
Message-ID: <>
Date: Fri, 05 Jul 2013 16:14:33 -0700
From: Marc Petit-Huguenin <>
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 <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Jul 2013 23:14:43 -0000

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
>>>> <> 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

>>>>> 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.


>>>>> 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 ;)

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
>>>>> --
>>>> 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 

- -- 
Marc Petit-Huguenin
Version: GnuPG v1.4.12 (GNU/Linux)