Re: [MMUSIC] Trickle ICE for SIP Questions

Paul Kyzivat <> Mon, 08 July 2013 15:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92B4321F9D5D for <>; Mon, 8 Jul 2013 08:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.015
X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OhL3LcByrW7h for <>; Mon, 8 Jul 2013 08:53:38 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:64]) by (Postfix) with ESMTP id 0116621F9D57 for <>; Mon, 8 Jul 2013 08:53:18 -0700 (PDT)
Received: from ([]) by with comcast id xpDp1l0050QuhwU57rtHug; Mon, 08 Jul 2013 15:53:17 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id xrtH1l00m3ZTu2S3NrtH2h; Mon, 08 Jul 2013 15:53:17 +0000
Message-ID: <>
Date: Mon, 08 Jul 2013 11:53:16 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1373298797; bh=6Q/zSoLsbn6ffEv3jNjZHzw6k1+Ia+MDHzj6zO9U29c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AoyX7MN3bKr/ynkz5llLvtFn9s0kNJdygJn6dL/BgyS+/7DDKMB77rmdMr4S+S+5i NGgb9di4kmyCKHw60foxPLVA9mGcEaeXDnJ/RldXp0vasTdV4qC+jLsXIajJP6hPLv FdKiLGj24YcPCNf/YtEtBId0Jy0iRJuPwbXa6NbmJ9FfMvgdAtW2TjDuswk04nvcrc PNDC8Uu0Iz0LuoU+fCQ7HgzI1ny7tlmBUOyFzzTiWNvZxVpjkNLJMevOvX/K6l9jCe zcYPRf+rUmVL8TDyw2xgZRJoQ16YxJzkBYnmILsaC5bFYhmZ6RSu5v6HsHVcQJNxxM KbRgVn55w3b3Q==
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: Mon, 08 Jul 2013 15:53:45 -0000


On 7/8/13 5:24 AM, Stach, Thomas wrote:

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

I get it that you think PRACK is hard to implement.
But hard compared to *what*? I suspect that this will introduce 
complexity elsewhere.

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

This is part of the house of cards that I was talking about.
You seem to be saying that a special rule should be be adopted, allowing 
INFO to be sent from INVITE-UAS before it is known that the dialog has 
been established. And then a special rule for processing 481 responses 
to INFO in this context.

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

Certainly it will be simpler if all candidates are sent each time.
But I don't think that means you can just take what you got last. You 
still need to check if what you got is *older* than what you already 
have, and if so ignore it.