Re: [rtcweb] Requiring ICE for RTC calls

Roman Shpount <> Tue, 27 September 2011 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A60021F8E24 for <>; Tue, 27 Sep 2011 09:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oeJeIvn-E3Hr for <>; Tue, 27 Sep 2011 09:28:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5E26D21F8C89 for <>; Tue, 27 Sep 2011 09:28:15 -0700 (PDT)
Received: by ywa6 with SMTP id 6so6859742ywa.31 for <>; Tue, 27 Sep 2011 09:31:01 -0700 (PDT)
Received: by with SMTP id t4mr7273939ybe.408.1317141060967; Tue, 27 Sep 2011 09:31:00 -0700 (PDT)
Received: from ( []) by with ESMTPS id z6sm80029724anf.22.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 09:31:00 -0700 (PDT)
Received: by gyd12 with SMTP id 12so6682746gyd.31 for <>; Tue, 27 Sep 2011 09:30:59 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id w4mr9259452pbh.20.1317141059169; Tue, 27 Sep 2011 09:30:59 -0700 (PDT)
Received: by with HTTP; Tue, 27 Sep 2011 09:30:59 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Tue, 27 Sep 2011 12:30:59 -0400
Message-ID: <>
From: Roman Shpount <>
To: Matthew Kaufman <>
Content-Type: multipart/alternative; boundary="bcaec520f27df36f3a04adeecc95"
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: Tue, 27 Sep 2011 16:28:16 -0000


One possible solution would be to have a slow rate RTP start, if remote end
point does not indicate ICE support. Instead of sending real media, RTC end
point will send no-media RTP packets at the rate of 2-3 per second for 10-15
seconds. If it receives a valid RTP packet back from the destination IP, it
will consider RTP flow verified and switch to sending media at normal rate,
otherwise media stream is terminated. We can have a better timing mechanism
for RTP packets to match the number of packets in the initial STUN handshake
in ICE, but the general idea is to get interoperability with existing
networks at the cost of 20 packet handshake. I do realize that the problem
with this that the RTP packets can be spoofed to force the web end point to
transmit, but this is the best solution I see so far.

If we do decide that ICE is a requirement, we can also have a local policy,
web site can be specified for which the calls are allowed without ICE.

Independently from all of this, SRTP should be optional. It does present
privacy concerns, but they are no different then privacy concerns over HTTP.
Roman Shpount

On Tue, Sep 27, 2011 at 11:15 AM, Matthew Kaufman <
> wrote:

> On 9/27/2011 7:46 AM, Roman Shpount wrote:
>> How real or big do you think this problem is going to be? None of the
>> current SIP/VoIP clients address this now, and we have quite a number of
>> them out there. I understand that this is an attack vector but how big of an
>> attack vector is this going to be if we ask for user confirmation?
> There is no plan to ask for user confirmation to open a connection, receive
> media, or send and receive data. The only user confirmation that is expected
> would be for camera and/or microphone access.
> I've seen a dozen messages from you arguing that the requirement for a STUN
> connectivity check is a barrier and should be removed, but I have not yet
> seen an alternative proposal that meets the requirements of browser authors
> with regard to preventing attacks on behind-firewall infrastructure from the
> browser platform.
> Matthew Kaufman