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

Iñaki Baz Castillo <ibc@aliax.net> Tue, 11 October 2011 08:03 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 260CB21F8CBC for <rtcweb@ietfa.amsl.com>; Tue, 11 Oct 2011 01:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.205
X-Spam-Level:
X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, 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 7dQcjjbbiopv for <rtcweb@ietfa.amsl.com>; Tue, 11 Oct 2011 01:03:18 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A567F21F8C1F for <rtcweb@ietf.org>; Tue, 11 Oct 2011 01:03:18 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so6536173vcb.31 for <rtcweb@ietf.org>; Tue, 11 Oct 2011 01:03:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.35.34 with SMTP id e2mr17043971vdj.52.1318320198060; Tue, 11 Oct 2011 01:03:18 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Tue, 11 Oct 2011 01:03:18 -0700 (PDT)
In-Reply-To: <4E93B43C.3060106@jdrosen.net>
References: <4E8B192E.80809@ericsson.com> <E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr> <4E935A8B.8020700@alvestrand.no> <CABcZeBNd0wnAv3KHkzCa4g6tFmGJhADOQDCz-7G=DYwp1yOGzA@mail.gmail.com> <4E9389C0.5050607@jesup.org> <4E93B43C.3060106@jdrosen.net>
Date: Tue, 11 Oct 2011 10:03:18 +0200
Message-ID: <CALiegfnE3bfstrCzOyZPGB5BZgycoNWS7Xy0k7-WAsNHLhew9g@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Jonathan Rosenberg <jdrosen@jdrosen.net>
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: Tue, 11 Oct 2011 08:03:19 -0000

2011/10/11 Jonathan Rosenberg <jdrosen@jdrosen.net>;:
> Security issues aside, the proposed solution does not work with existing
> SIP/RTP implementations. The main drawback of the ICE solution is that it
> won't work with deployed equipment. I see little benefit in specifying
> another solution which does not fix the main limitation we have with ICE.

I agree. IMHO it's time for SIP vendors to implement escurity in SIP
devices (let's say ICE and SRTP, some specifications originally
designed for SIP).

SIP is deployed in different scenarios and each scenario has its own
requirements (some of them require certain codecs, SIP over TLS,
UPDATE/PRACK methods and so on). I consider RTCweb to be another
multimedia communication scenario (but very big!!) so it can impose
its own requirements (for example ICE+SRTP which sounds appropriate
given the open Internet nature).

So if SIP vendors want to interoperate with RTCweb devices, then
implement ICE+SRTP, that's the key.

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