Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion)

Iñaki Baz Castillo <ibc@aliax.net> Mon, 10 October 2011 23:09 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70AC21F8B7E for <rtcweb@ietfa.amsl.com>; Mon, 10 Oct 2011 16:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.375
X-Spam-Level:
X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-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 3t0Amkts+oY7 for <rtcweb@ietfa.amsl.com>; Mon, 10 Oct 2011 16:09:58 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBDB721F8B6D for <rtcweb@ietf.org>; Mon, 10 Oct 2011 16:09:57 -0700 (PDT)
Received: by vws5 with SMTP id 5so6268970vws.31 for <rtcweb@ietf.org>; Mon, 10 Oct 2011 16:09:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.25.75 with SMTP id a11mr15810902vdg.1.1318288192762; Mon, 10 Oct 2011 16:09:52 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Mon, 10 Oct 2011 16:09:52 -0700 (PDT)
In-Reply-To: <CABcZeBNd0wnAv3KHkzCa4g6tFmGJhADOQDCz-7G=DYwp1yOGzA@mail.gmail.com>
References: <4E8B192E.80809@ericsson.com> <E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr> <4E935A8B.8020700@alvestrand.no> <CABcZeBNd0wnAv3KHkzCa4g6tFmGJhADOQDCz-7G=DYwp1yOGzA@mail.gmail.com>
Date: Tue, 11 Oct 2011 01:09:52 +0200
Message-ID: <CALiegf=UTzkKQ7LAGUhGBpm5aEBgxV-0pz6dUPrbQgBRxDXu1Q@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Oct 2011 23:09:59 -0000

2011/10/11 Eric Rescorla <ekr@rtfm.com>;:
> It's also unclear to me why this is significantly easier than just
> doing ICE Lite.

And it does not solve NAT neither allows IPv4/IPv6 interoperability.
Why to make SIP devices to implement that instead of ICE (or
ICE-Lite)?

ICE was designed for SIP but now there are much more XMPP clients
implementing it than SIP... how much must we wait in SIP? now it's
clearly the moment but instead of endorsing ICE, do we really prefer
to create a new pseudo-spec just to make SIP devices RTC-web
compliant? And then, what will we do when IPv6 arrives?

I strongly vote for using ICE and requiring ICE in SIP world (they
just MUST, this is the time).

-- 
Iñaki Baz Castillo
<ibc@aliax.net>;