Re: [rtcweb] Summary of ICE discussion

<> Tue, 11 October 2011 08:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A04C421F8CD2 for <>; Tue, 11 Oct 2011 01:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.06
X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[AWL=1.189, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id abj+3mG4Q5x7 for <>; Tue, 11 Oct 2011 01:02:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E706621F8C1F for <>; Tue, 11 Oct 2011 01:02:37 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 614B540035; Tue, 11 Oct 2011 10:00:51 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id 47E844002D; Tue, 11 Oct 2011 10:00:51 +0200 (CEST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 10:00:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Tue, 11 Oct 2011 10:00:05 +0200
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Summary of ICE discussion
Thread-Index: AcyGn/6FcwsFLHX3QXeqrlBNhu/ItgBSnkag
References: <><> <>
From: <>
To: <>
X-OriginalArrivalTime: 11 Oct 2011 08:00:06.0238 (UTC) FILETIME=[C9F717E0:01CC87EB]
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:02:38 -0000

Hi Iñaki,

>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. 

-----Message d'origine-----
De : Iñaki Baz Castillo [] 
Envoyé : dimanche 9 octobre 2011 18:24
Cc :;
Objet : Re: [rtcweb] Summary of ICE discussion

2011/10/9  <>om>:
> This mechanism provides basic media consent verification and if it turns out
> that it provides less security properties than ICE or other drawbacks (e.g.
> increasing media session establishment delay, issues with the few initial RTP
> packets,..), it could be seen as a fallback media consent verification
> when ICE is not implemented at each end of media terminations.
> Looking forward to hearing feedbacks from the group on this.


ICE is clearly the best solution as it handles NAT, security (peer
verification) and allows IPv4/IPv6 transition. SIP endpoints *MUST*
implement it or continue working in vendors wallen gardens. Bad luck
for them.

But creating a new spec (as you suggest) just to allow lazy SIP
vendors (those who has never cared about security) to interoperate
with RTCweb world instead on forcing them to implement ICE is IMHO a
very bad idea.

SIP vendors MUST do their homeworks. ICE and SRTP were initially
designed for SIP. So SIP devices MUST implement them.

Iñaki Baz Castillo