Re: [MMUSIC] Trickle ICE for SIP Questions

Emil Ivov <> Tue, 09 July 2013 22:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4298721F9CD7 for <>; Tue, 9 Jul 2013 15:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R6V87uZabqz0 for <>; Tue, 9 Jul 2013 15:41:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AA2E921F9B97 for <>; Tue, 9 Jul 2013 15:41:07 -0700 (PDT)
Received: by with SMTP id z11so5303440wgg.10 for <>; Tue, 09 Jul 2013 15:41:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=0MVWkRFiNvPyX53C0AgILe2WzgX7go8Rlb1mIslH/BI=; b=nvWshb+EqGYzqW35JaRKT4rsY52E1ywqMJsT40VIQfXEEqvZCeB2hOCAeA1DYaz8Az NQDdeEgIBHL9PRHscF2hXrBeSYAHFOqFad8gbBrNrIQ19+bwcUiPPBeZYutmUDNtDQ1A IymeLmGFj1oMv066W1bZbHBEQ6xoaxhwbLVicEpstuuSjPo12x4E5rbbPpYj43XV2Ikd uHzf2HF3ZqcWkOWLzLGB0bh9h/ZVGg4xIwoRBNJ1R1YbGuQ99Yke13TWl0NqiiOEeZ0j u4QWZQfppVP8myZZqh6NryOfKVLjW/xiDsUwFq4rmOsdV9VWhCKorON5d/29kf6pmqO/ Iz2w==
X-Received: by with SMTP id j8mr15436962wib.15.1373409666724; Tue, 09 Jul 2013 15:41:06 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:2403:2255:f094:fc64]) by with ESMTPSA id cz9sm19169405wib.3.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 15:41:05 -0700 (PDT)
Message-ID: <>
Date: Wed, 10 Jul 2013 00:41:04 +0200
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; 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
X-Gm-Message-State: ALoCoQn1SbTy7Zqph553XIshBI/bkp/e3SwKfFcG1itM7oX0t78jiClOn9KUwxrFm5Eepo+brd5s
Cc: "" <>, Paul Kyzivat <>
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 22:41:12 -0000

A few cross mail replies:

On 09.07.13, 23:20, Stach, Thomas wrote:
> 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.

What does this change for anyone? Clients have no way of knowing whether
there would be UDP hops along the way so they would always need to be
ready for this option.

> [TS] As Trickle-ICE is just being specified, we are in a position to
> specify this handling.

While this is true, I see the following issue here: cumulative sending
is only necessary for SIP/UDP (which is quite a paradox because SIP/UDP
with ICE would break in a big number of cases).

> [TS] As the ICE/STUN logic resides in the browser not in the JS app,
> this would be a matter of the API definition to always provide all
> known candidates towards the JS APP for sending. On the receiving
> side the JS APP would also just have to push all received candidates
> through the browser API.

I find it strange that we would be imposing constraints on a new generic
API because of a broken use case that only exists with one usage
protocol. Especially given that the said use case (SIP+ICE over UDP) is
NOT going to work anyway because of MTUs and improper IP fragmentation
handling on various devices today.

>>> We are indeed likely to get a 481 when sending INFOs and the 180
>>> hasn't yet made it to the remote side. However 481 might also
>>> imply that our dialog is simply dead for some reason and in this
>>> case 3261 says:
>>> 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.

I am not sure this is true. There *is* an early dialog at the side 
that's sending the 180. The INFO is a second request within that same 
dialog and 3261 is very clear that a 481 would lead to termination of 
the dialog. Specifying different behaviour here would mean that many 
developers may need to start fighting/changing their SIP stacks.