Re: [rtcweb] Requiring ICE for RTC calls

Cullen Jennings <> Wed, 28 September 2011 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A963A1F0C5E for <>; Wed, 28 Sep 2011 10:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.054
X-Spam-Status: No, score=-103.054 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id waSMZi6Uux7B for <>; Wed, 28 Sep 2011 10:01:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2AF601F0C56 for <>; Wed, 28 Sep 2011 10:01:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3009; q=dns/txt; s=iport; t=1317229456; x=1318439056; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PNY+90/xejHZG//8OW40XGmRTGwdc9GNDuZVSnvTHG8=; b=BwpXOthp0qFnO0lyd+C2b2V5kGObiT7bfJIoyeSIrrosbZyY6ew7QVQ2 kxH0a665+XoPwcMWM7XJRZBgSI2nyNiZ9xM9pixVjw5xRqVLLlqKy1Qqc X3BrGlfPRKdyjmhunxspMFyCxh/TM8zH35HfrZ92yHEWP0pkwyDt9MkGR 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EABlTg06rRDoH/2dsb2JhbABCqAp4gVMBAQEBAgESASc/EAsYLlcGExsHh1aaKQGeK4YrYQSHcotjhSKMMg
X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4809371"
Received: from ([]) by with ESMTP; 28 Sep 2011 17:04:15 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p8SH4D8v006473; Wed, 28 Sep 2011 17:04:14 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <>
In-Reply-To: <>
Date: Wed, 28 Sep 2011 11:04:13 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Roman Shpount <>
X-Mailer: Apple Mail (2.1084)
Cc: Randell Jesup <>,
Subject: Re: [rtcweb] Requiring ICE for RTC calls
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: Wed, 28 Sep 2011 17:01:27 -0000

On Sep 28, 2011, at 10:01 AM, Roman Shpount wrote:

> On Wed, Sep 28, 2011 at 10:42 AM, Cullen Jennings <> wrote:
> Many service providers front end their services with an SBC for a wide variety of reasons - and that is the place they would likely run ICE Lite (note it's not even full ICE they need).
> I understand that this can be considered advertisement on the forum, but does ACME, Sonus and Genband SBC support ICE or ICE lite? As far as I know they do not. If I am wrong and they do, how long did they have this support? If they do not, does anybody know what their plans are?

I'll note some vendors have both SBC and endpoints that do ICE but clearly not all of them - only the ones where there was a market for it. My experience with ACME and Sonus has been they will provide what the market needs. Today the "SIP Trunking" is used in situation where no ICE is needed and keep in mind most the SBC vendors have other solutions for the pure NAT traversal part of the problem that predate ICE. 

When a single large voice provider asked it's sip trunking providers to add iLBC, they asked the gateway providers to add it. Pretty much every major gateway vendor added it - for a single voice service provider - and that was probably harder than adding ICE. Vendors don't build something because the IETF made an RFC - they build it because it meets a customer need. If we could solve this problem without ICE, or something about the same, clearly we would, but if we can't, vendors will build the minimum they need to meet market needs. The fact they will build the minimum is why VoIP, and the internet, just barely works. There no point in doing more than that.

> Sorry for such direct line of questioning, but dealing with SIP trunk providers in US, you interface to an SBC from one of those vendors. So, if these vendors support ICE, most of the SIP trunk providers would be able to support ICE.
> Even with this covered, we still have an issue of supporting ICE by PBXs and IP Phones. As far as I know (and my information can be outdated), Polycom and Cisco phones do not support ICE. I am not sure about the others, but from what I've generally seen hardware phones in vast majority do not support ICE.

I agree with you point that the majority of deployed phones don't support ICE. But so what, what do you propose to do. One thing that is not going to happen is browser vendors do something which makes browsers such a security threat that the browsers are banned from every corporate network. Solutions like CORS solve the problem but short of something like that, I don't see browser vendors deciding that remove same origin policy is a good idea. 

> Please correct me if I am wrong about any of this. I am mostly trying to determine the level of current market support for ICE.
> _____________
> Roman Shpount