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

Randell Jesup <> Tue, 11 October 2011 04:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B8F921F8C26 for <>; Mon, 10 Oct 2011 21:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wAeKC8+fkn+G for <>; Mon, 10 Oct 2011 21:26:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0351221F8C1A for <>; Mon, 10 Oct 2011 21:26:18 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1RDTv0-0002Ep-9W for; Mon, 10 Oct 2011 23:26:18 -0500
Message-ID: <>
Date: Tue, 11 Oct 2011 00:22:03 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: 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 04:26:19 -0000

On 10/10/2011 11:13 PM, Jonathan Rosenberg wrote:
> 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.

The only thing I've come up with that can work with existing equipment 
is a variant of CORS.

Basically, if the destination doesn't respond to ICE (or more likely the 
app tells you it won't) you do a CORS-style 'preflight' check to the 
same IP address.  If you're told "I'm an RTP gateway that accepts 
non-ICE traffic" with a valid handshake from the signalling (ala an ICE 
check), then traffic can flow/continue flowing (you may want to allow it 
to start before the check is complete, with a limited time/data until 
verification is required to continue).

In practice, this could be implemented by redirecting HTTP/HTTPS traffic 
to the gateway's IP to an internal webserver that would respond.  This 
allows layering onto existing gateways permission for a webrtc/rtcweb 
client to send to them, without modifying the gateway itself.

Downsides: More complex.  Assumes the gateway can either run a (dummy) 
webserver, at least enough to redirect, or it's behind a firewall that 
can port-forward traffic.

An advantage, if the gateway is willing to risk DoS attempts, is that 
the gateway could indicate a max age for the CORS-type check, and so 
indicate that for future calls to that address the browser doesn't have 
to check.  This is optional, though, and just saves checks (and if 
pre-check-complete data sending isn't allowed, then it may save setup 
time as well, except on the first call to a particular gateway).

Is it workable?  I think so.  Is it worthwhile?  I don't know.  I'm 
somewhat skeptical since it solves only a subset of the problem space 
(for connecting to legacy devices/gateways).

Randell Jesup