Re: [MMUSIC] Trickle ICE for SIP Questions

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 25 July 2013 23:33 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6011721F8EEA for <mmusic@ietfa.amsl.com>; Thu, 25 Jul 2013 16:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.316
X-Spam-Level:
X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqtMyU+Cebzu for <mmusic@ietfa.amsl.com>; Thu, 25 Jul 2013 16:33:00 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7E421F81FF for <mmusic@ietf.org>; Thu, 25 Jul 2013 16:32:59 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 4nUd1m0030bG4ec5BnYxVz; Thu, 25 Jul 2013 23:32:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id 4nYw1m0183ZTu2S3PnYwHS; Thu, 25 Jul 2013 23:32:57 +0000
Message-ID: <51F1B5A7.1060400@alum.mit.edu>
Date: Thu, 25 Jul 2013 19:32:55 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Emil Ivov <emcho@jitsi.org>
References: <51D43186.2010907@jitsi.org> <F81CEE99482EFE438DAE2A652361EE12114A0200@MCHP04MSX.global-ad.net> <51D6D456.7090900@jitsi.org> <F81CEE99482EFE438DAE2A652361EE12114A1127@MCHP04MSX.global-ad.net> <51DAE06C.1030203@alum.mit.edu> <F81CEE99482EFE438DAE2A652361EE12114A31B0@MCHP04MSX.global-ad.net> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> <51EC2EF7.1090000@jitsi.org> <51EC5569.60106@alum.mit.edu> <51EC5B75.1020306@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F366B@ESESSMB209.ericsson.se> <51ED0C24.30206@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F685F@ESESSMB209.ericsson.se> <51EEB807.6010704@jitsi.org>
In-Reply-To: <51EEB807.6010704@jitsi.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374795177; bh=OI3YxB4c2NNuxLtuyW7bJDm/9njsrcULb6au54yf8aA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VZNk2zfftoXovFhAz19iRmBrZycmoQqZLJB6qyFnkfcJ4wjPpaXw8ZOUvcol12CDs fUn5+gj2K5oszx/uvF4GSDLZ4Td2d1AqD1HqOogLtwylCM/6Ck04Zx5CB2yGTe3IhF W9yH6aHfYq4Unq+FjTPLpNSZc42KIO4xhbZPjkM1TE7woYvUPBAmZF02190XOnSO2t xYShsy26mPtmw+uO5n1KfGaFUnagPS0/JhoOubcgkfIt4pdBX1RWNtl7a8nqVuqe/E TWyVsn8tSR5FUB7vbgvS9qT+ZkihuczLhece7M3MA5NmfihTLXWbUxIh8oA90UA+cB EMkb0FkqTotEA==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 23:33:06 -0000

On 7/23/13 1:06 PM, Emil Ivov wrote:

> I actually think we could pull this off with simple PRACKs. Only, rather
> than using the "100rel" tag we go for something like "100rel-lite" which
> could be defined to indicate that a UA supports PRACK but only for
> reliability (and PRACK bodies are not allowed).

This is crazy!

Every new option presents backward compatibility issues, implementation 
issues, ...

It doesn't make sense to define a new option that is a subset of a long 
time existing option. This is *not* rocket science. Just tell people 
they need to support 100rel as a precondition for trickle ICE. If they 
find trickle ice worthwhile they can implement it.

I'd be amazed if there are any SBCs that don't support PRACK. (But 
Hadriel will fill us in about that.)

	Thanks,
	Paul