Re: [MMUSIC] Trickle ICE for SIP Questions

Dan Wing <> Wed, 03 July 2013 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9115811E821E for <>; Wed, 3 Jul 2013 12:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.476
X-Spam-Status: No, score=-110.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iRyLCfo-bfSw for <>; Wed, 3 Jul 2013 12:01:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C1C8A11E8221 for <>; Wed, 3 Jul 2013 12:01:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3314; q=dns/txt; s=iport; t=1372878107; x=1374087707; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oM7l2byjw4n12r2zdxGixgBMiraAvGOSvVlELQiLAG4=; b=Wg/505QoXaRPSvnt2BKq4GKTIIgp8I0vXEmTfZerj4b43KdPX9RgbBWe SVil2xbjas7wt6Nijfy3t/ry1YcFh/t4fAfc2QTxF6JW3dowqInTmi7Bk JhVNg68OQUfy3CRdiGWN9jtKEtVhjlluxUdNkzNQ93nHzCpjHPnHLFRXj Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,989,1363132800"; d="scan'208";a="85214316"
Received: from ([]) by with ESMTP; 03 Jul 2013 19:01:47 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r63J1kLT014443; Wed, 3 Jul 2013 19:01:46 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <>
In-Reply-To: <>
Date: Wed, 03 Jul 2013 12:01:46 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Emil Ivov <>
X-Mailer: Apple Mail (2.1508)
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: Wed, 03 Jul 2013 19:01:59 -0000

On Jul 3, 2013, at 7: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.

I might work, because each re-transmission would probably have additional candidates (because the STUN/TURN transactions will have completed), and thus more likely that those re-transmissions (containing those additional candidates) would result in the remote endpoint sending a STUN binding request.


> 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