Re: [rtcweb] Summary of ICE discussion

Iñaki Baz Castillo <> Tue, 11 October 2011 08:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E5C021F8CBC for <>; Tue, 11 Oct 2011 01:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.189
X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ek1nbenHupEG for <>; Tue, 11 Oct 2011 01:08:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D9D6221F8C64 for <>; Tue, 11 Oct 2011 01:08:19 -0700 (PDT)
Received: by vws5 with SMTP id 5so6550290vws.31 for <>; Tue, 11 Oct 2011 01:08:19 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id by14mr17176876vdb.18.1318320499314; Tue, 11 Oct 2011 01:08:19 -0700 (PDT)
Received: by with HTTP; Tue, 11 Oct 2011 01:08:19 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 11 Oct 2011 10:08:19 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Summary of ICE discussion
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Oct 2011 08:08:20 -0000

2011/10/11  <>om>:
>>ICE is clearly the best solution as it handles NAT, security (peer
>>verification) and allows IPv4/IPv6 transition.
> Of course, this solution doesn't mean to address NAT traversal issues, nor multihoming.
> ICE still remains the best candidate for such requirements and it is in no way my intent to
> question the use of ICE for RTC-Web compliant agents : my proposal's goal is only to permit
> the minimal interoperability costs with existing SIP endpoints whilst trying to address RTC-Web
> specific security challenges (i.e. media consent verification). Again, it doesn't preclude the
> use of ICE for media consent verification, should all endpoints support ICE.

Hi Sebastien,

As I've said in other mails, ICE and SRTP was designed for SIP. If SIP
vendors don't care about security (due to wallen gardens in which most
of SIP is deployed) neither IPv4/IPv6 migration (again due the same
reasons) that is their fault.

If SIP vendors just react when needed, this is a good time for that,
as the "market" will be Internet full of RTCweb capable web browsers
implementing ICE+SRTP (being safer that 99% of current SIP devices,
which is really sad).

It's time for implementing ICE+SRTP in SIP. Please don't give SIP
vendors another oportunity to avoid implementing that by offering them
some workaround for media verification.

Iñaki Baz Castillo