Re: [MMUSIC] Trickle ICE for SIP Questions

Paul Kyzivat <> Tue, 09 July 2013 21:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A38DB11E8185 for <>; Tue, 9 Jul 2013 14:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.105
X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[AWL=0.332, 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 64giHNC5dqDH for <>; Tue, 9 Jul 2013 14:52:47 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:16]) by (Postfix) with ESMTP id 548FF11E817C for <>; Tue, 9 Jul 2013 14:52:37 -0700 (PDT)
Received: from ([]) by with comcast id yKpR1l0020bG4ec51Msayl; Tue, 09 Jul 2013 21:52:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id yMsa1l00d3ZTu2S3PMsaMQ; Tue, 09 Jul 2013 21:52:34 +0000
Message-ID: <>
Date: Tue, 09 Jul 2013 17:52:33 -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
To: "Stach, Thomas" <>
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=1373406754; bh=06AyjRxh1JRDI+EzrliJBKijNMzfj0HPQ43bYbV36vw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nZunLlGzBUzGH0UdEc7WUcFAT00cjNH6h1PMmZY6is9VTwdn6FF6Y7kwzxexyTS8V JljBT7lHtSHhW/AwCG7NGTdysm3FIrRSSYZMGA0ya9ft3OfdFxhquf4NNY0B4bpqQS 1uX3xA21dUKIwo7V5v9U59TAYKmonz0ZPrn2OOBScRFUDvQpXYktESBkxyStg6ejBd iDvRUsdQ0bIGW//kDCDiavMnwdwbuJI/dC/VGVeaiCftqndNn7t91wL/qUvIDmlqQS pDFHExXgZpzjp9vJbsT+KqqtmIqZHv8rItZd+0Xi9q/nCSMbTY+zaaCWfyfr59Rj25 anKBvVBGz0z5Q==
Cc: "" <>
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: Tue, 09 Jul 2013 21:52:51 -0000

On 7/9/13 5:20 PM, Stach, Thomas wrote:
>> -----Original Message-----
>> From: [] On
>> Behalf Of Paul Kyzivat
>> Sent: Monday, 08 July, 2013 17:53
>> To:
>> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
>> Thomas,
>> 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
> [TS] The remainder of the sentence got lost. It should have read "... since it allows easier introduction RTCWEB client with trickle ICE into a SIP network that never used PRACK."
>> I get it that you think PRACK is hard to implement.
>> But hard compared to *what*? I suspect that this will introduce
>> complexity elsewhere.
> [TS] With respect to this complexity I just see the 481 handling for the INFO.
> Compared to all the new states that I need when I implement PRACK (which can include a new offer as you know), I just have to keep the previously sent provisional response together with the INFO request. The latter I have to keep anyhow for potential retransmissions.
> If I get a 481, I resent the 18x and the INFO request.
> BTW: Just form emphasis. This is only needed if there is a UDP hop somewhere, in case of TCP/TLS the 18x would never be lost.

With PRACK, the work is implementing it as it is specified. And then you 
can use it everywhere, not just for trickle-ICE.

I'm not sure I understand your proposal for using info in the context, 
but I *think* you are asking for *special* handling of 481 for INFO, 
contrary to how specs call for it to be implemented. For one think, this 
would effectively be a revision to some existing specification. And 
maybe you only what this handling when INFO is used for trickle-ICE?

Remember, introducing this will often mean using an existing 
implementation of INFO for this purpose.

>>>>      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.
> [TS] Let me reject the comparison with a "house of cards". We are currently specifying a new feature. There are no deployed implementations yet. Thus we can exactly specify what should happen at the UAC when it receives an out-of-dialog INFO because the dialog establishing unreliable 18x was lost, i.e. to send 481.
> On the UAS side we can also specify what to do when the INFO gets a 481. I.e. resend the 18x and the INFO request.
> I consider this closer to a solid foundation than to a house of cards.

Lets first decide in you are proposing a special mechanism for use with 
trickle-ICE, or if you are proposing a revison (bug fix?) to INFO, or to 
3261 & 5057.

If you are proposing a change in how INFO works exclusively when used 
for trickle-ICE then I think it is a non-starter.

If you are proposing a revision regarding the handling of presumed-to-be 
in-dialog requests from UAS to UAC before the UAS has proof that the UAC 
knows of the dialog, then we can talk.


> Regards
> Thomas
>>>> 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.
>> 	Thanks,
>> 	Paul
>> _______________________________________________
>> mmusic mailing list