Re: [MMUSIC] Trickle ICE for SIP Questions

"Stach, Thomas" <> Tue, 09 July 2013 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C625111E8156 for <>; Tue, 9 Jul 2013 14:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1cZzruPPmcIK for <>; Tue, 9 Jul 2013 14:20:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0521821F9D3A for <>; Tue, 9 Jul 2013 14:20:43 -0700 (PDT)
Received: from (unknown []) by (Server) with ESMTP id CD48D1EB8457; Tue, 9 Jul 2013 23:20:30 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 9 Jul 2013 23:20:30 +0200
From: "Stach, Thomas" <>
To: Paul Kyzivat <>, "" <>
Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions
Date: Tue, 09 Jul 2013 21:20:29 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: de-AT, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:20:48 -0000

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

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


> >> Also, keep in mind that the 180 carries an entire SDP answer. If
> >> 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