Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls)

Saúl Ibarra Corretgé <> Mon, 03 October 2011 07:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD84B21F8AF2 for <>; Mon, 3 Oct 2011 00:36:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.704
X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hIOCGk+UQPu1 for <>; Mon, 3 Oct 2011 00:36:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9E52A21F8AEC for <>; Mon, 3 Oct 2011 00:36:40 -0700 (PDT)
Received: by (Postfix, from userid 5001) id 36981B01B7; Mon, 3 Oct 2011 09:39:41 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 46BDDB01B0; Mon, 3 Oct 2011 09:39:29 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Saúl Ibarra Corretgé <>
In-Reply-To: <>
Date: Mon, 03 Oct 2011 09:39:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <4E82678E.6060304@s> <>
To: Roman Shpount <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: 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: Mon, 03 Oct 2011 07:36:42 -0000


Sorry for coming a bit late...

> You just repeated the same thing that I said, just a bit more clearly. 
> I guess we are making a conscientious not to be able to communicate with any of the existing VoIP infrastructure including IP phones and SIP trunking providers and expect them to implement ICE support. Until this happens RTC end points will have to rely on some sort of media proxy to communicate with existing infrastructure. Is this correct?
> Do we have anybody in this list who has real life experience with deploying large scale ICE based solutions over public internet? I just want to make sure that we are not putting all of our eggs in the basket that no one ever used.

We do deploy ICE-enabled network infrastructure to our customers, the free site is an example of such a platform.

The problem we faced with ICE was the fact that in most cases NAT is fixed by modifying the SDP and changing c/m lines in order to put a media relay in between, but this breaks ICE negotiation because there is no candidate for the new c line. We solved this in two Open Source projects: OpenSIPS and MediaProxy by also adding a new candidate which would appear to be a TURN server, so both ends are fooled to believe there was a candidate. The media relay lets STUN probes pass so that ICE connectivity checks will succeed.

This ensures that if both endpoints do support ICE the negotiation will succeed. Unfortunately, not many endpoints do implement ICE, so those that don't would need to be gateway-ed, but IMHO it's for a greater good.


Saúl Ibarra Corretgé
AG Projects