Re: [rtcweb] Summary of ICE discussion

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Wed, 05 October 2011 06:05 UTC

Return-Path: <pravindran@sonusnet.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D8621F8B08 for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 23:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level:
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_00=-2.599, FRT_BELOW2=2.154]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0fm8-9mHfhA for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 23:05:17 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 062B521F8B1A for <rtcweb@ietf.org>; Tue, 4 Oct 2011 23:05:16 -0700 (PDT)
Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p95688g9006597; Wed, 5 Oct 2011 02:08:08 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 02:07:35 -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 11:37:32 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F142C@sonusinmail02.sonusnet.com>
In-Reply-To: <4E8B192E.80809@ericsson.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Summary of ICE discussion
Thread-Index: AcyCorg6pM9PKEv5QH2os56S0Yz+CAAgYuQw
References: <4E8B192E.80809@ericsson.com>
From: "Ravindran Parthasarathi" <pravindran@sonusnet.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>, <rtcweb@ietf.org>
X-OriginalArrivalTime: 05 Oct 2011 06:07:35.0334 (UTC) FILETIME=[13A26460:01CC8325]
Subject: Re: [rtcweb] Summary of ICE discussion
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2011 06:05:18 -0000

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.

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.

The other reason like NAT & FW is not mandatory for intranet RTCWeb applications. I have mentioned as part of http://www.ietf.org/mail-archive/web/rtcweb/current/msg01619.html

Thanks
Partha

>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>Of Magnus Westerlund
>Sent: Tuesday, October 04, 2011 8:03 PM
>To: rtcweb@ietf.org
>Subject: [rtcweb] Summary of ICE discussion
>
>WG,
>
>I have bellow tired to summarize the result of the ICE discussion. This
>is intended as furthering this discussion and form a basis for going
>forward in the consensus process. I do expect people that disagree with
>my summary of the discussion to speak up.
>
>Major requirements
>
>- Need for data transmission consent for protocols using UDP as the
>traffic receiver needs to consent to receiving the data
>
>- Perform NAT and FW traversal when ever needed
>
>- Support IPv4 to IPv6 transition
>
>Desired behavior:
>
>- Be interoperable with deployed legacy systems as SIP Trunk, PSTN
>gateways, VoIP phones.
>
>WG chairs conclusion of discussion so far:
>
>- ICE is so far the only solution that provides the security goals and
>have any legacy deployment.
>
>- ICE usage will require that STUN connectivity MUST have succeeded
>prior to any data transmission to fulfill security goals.
>
>  * The Browser will enforce this requirement to prevent being an attack
>vector in all cases.
>
>- If anyone can find a solution that fulfill the security goals and have
>improved legacy interoperability people would be interested in that
>solution. So far RTCP has been discarded as insufficient.
>
>- Media Gateway can support a reduced functionality set from Full ICE
>
>Cheers
>
>Magnus Westerlund
>as WG chair
>
>----------------------------------------------------------------------
>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: magnus.westerlund@ericsson.com
>----------------------------------------------------------------------
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb