Re: [rtcweb] Summary of ICE discussion

"Ravindran Parthasarathi" <> Wed, 05 October 2011 14:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D9AD21F8AF7 for <>; Wed, 5 Oct 2011 07:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YWlV01orb0sC for <>; Wed, 5 Oct 2011 07:34:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 27F9C21F8CA9 for <>; Wed, 5 Oct 2011 07:34:46 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p95EcKH6014721; Wed, 5 Oct 2011 10:38:20 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 10:37:42 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 5 Oct 2011 20:07:39 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Summary of ICE discussion
Thread-Index: AcyDN3onXBChTObjQmqkKm4vgz75PQAMS3Bg
References: <> <> <>
From: "Ravindran Parthasarathi" <>
To: "Magnus Westerlund" <>
X-OriginalArrivalTime: 05 Oct 2011 14:37:42.0979 (UTC) FILETIME=[57366130:01CC836C]
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: Wed, 05 Oct 2011 14:34:47 -0000

Hi Magnus,

Thanks for the clarification about the issue in webserver based trust model. I agree for ICE as there is no other known solution for user consent in the proposed trust model. Still, data transmission consent is an open item.


>-----Original Message-----
>From: Magnus Westerlund []
>Sent: Wednesday, October 05, 2011 1:49 PM
>To: Ravindran Parthasarathi
>Subject: Re: [rtcweb] Summary of ICE discussion
>On 2011-10-05 08:07, Ravindran Parthasarathi wrote:
>> In case user consent is the reason for ICE, ICE may not be right
>> choice because of the multiplexing RTP in RTCWeb and user may be
>> consent for audio and not for video which is not possible to indicate
>> through ICE. It is possible to achieve by having different streams
>> for each media but I strongly believe that it is not interesting
>> topic for RTCWeb.
>No, it is not user consent, it is data transmission consent that is the
>issue here.
>> I think that trust model with browser---RTCWeb server---browser for
>> the user consent with individual media stream works because browser
>> user trust RTCWeb server. I could think of offer/answer as user
>> consent with media stream mechanism because offer or answer indicates
>> media port is allocated in browser and listening for media from
>> remote party, the consent reaches remote browser through RTCWeb
>> server. The advantage in the model is that RTCWeb server shall have
>> the policy to control media. Please let me know your comments on
>> this.
>My interpretation is that several has disagreed with you on this model.
>I personally also disagree with this. There is a big difference between
>allowing a webservice access to my media devices, i.e. microphone and
>video as will expect it to perform a communication service where I at
>least see parts of that communication happening. However, the user has
>no way of verifying that of the media streams being setup by the web
>service that it in fact not in addition uses the users resources for a
>DoS attack. It is the destination of the media stream that needs to
>consent to the media delivery, not the siganlling node for it. Thus a
>path based media verification that ensures that information from the
>signalling and the media path agrees provides a reasonable but not
>perfect security against attacks. This is still vulnerable to attackers
>that have the capability of both running the web service and intercept
>and inject packets in the network on path between the web client and the
>target of the attack.
>> The other reason like NAT & FW is not mandatory for intranet RTCWeb
>> applications. I have mentioned as part of
>My interpretation of your statement was that it was disputed and that
>the disputing statement was not faulty.
>Magnus Westerlund
>Multimedia Technologies, Ericsson Research EAB/TVM
>Ericsson AB                | Phone  +46 10 7148287
>Färögatan 6                | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden| mailto: