Re: [MMUSIC] Trickle ICE for SIP Questions

Marc Petit-Huguenin <> Fri, 05 July 2013 22:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE82521F9D7A for <>; Fri, 5 Jul 2013 15:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Az0BBwGoaCWP for <>; Fri, 5 Jul 2013 15:45:30 -0700 (PDT)
Received: from ( [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by (Postfix) with ESMTP id A0D5E21F9D78 for <>; Fri, 5 Jul 2013 15:45:30 -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 05E1520415; Sat, 6 Jul 2013 00:45:27 +0200 (CEST)
Message-ID: <>
Date: Fri, 05 Jul 2013 15:45:25 -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 22:45:32 -0000

Hash: SHA256

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.

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

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

>> 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.e. so far nobody proposed
to tunnel the media over SIP :-)

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