IETF Logo Mail Archive

Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

"Ravindran, Parthasarathi (NSN - IN/Bangalore)" <parthasarathi.ravindran@nsn.com> Wed, 13 November 2013 16:34 UTC

Return-Path: <parthasarathi.ravindran@nsn.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 6D76421E814A for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 08:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 DvbRKVa1EczC for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 08:34:13 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 03BDA21E8134 for <rtcweb@ietf.org>; Wed, 13 Nov 2013 08:34:04 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rADGXu7I006554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Nov 2013 17:33:57 +0100
Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rADGXsEV008980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 17:33:55 +0100
Received: from SGSIHTC007.nsn-intra.net (10.159.225.24) by SGSIHTC002.nsn-intra.net (10.159.225.19) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 14 Nov 2013 00:33:53 +0800
Received: from SGSIMBX006.nsn-intra.net ([169.254.6.69]) by SGSIHTC007.nsn-intra.net ([10.159.225.24]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 00:33:53 +0800
From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <parthasarathi.ravindran@nsn.com>
To: ext Magnus Westerlund <magnus.westerlund@ericsson.com>, Harald Tveit Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
Thread-Index: AQHO37I3PiD2CpYvFEa5TFD9+s8TOpoh62lQgABRywCAARYGsA==
Date: Wed, 13 Nov 2013 16:33:52 +0000
Message-ID: <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net>
References: <5282391D.3050002@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net> <5283291E.7090108@ericsson.com>
In-Reply-To: <5283291E.7090108@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.225.123]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2392
X-purgate-ID: 151667::1384360438-00005753-CF4F4233/0-0/0-0
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
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, 13 Nov 2013 16:34:17 -0000

Hi Magnus,

In case of Browser - GW/Server use cases (Sec 3.4 of draft-ietf-rtcweb-use-cases-and-requirements-12), the end-to-end TCP connection is between browser & Gateway directly. Here, GW/server acts as RTP endpoint/mixer in the middle of the network and acts as "RTP relay" [Note 1] to the actual remote endpoint. TURN server (TCP to UDP relay) is becoming "second middle box" in case GW/server provider has to deploy TURN server as well. ICE-TCP solves the issue as it creates the host candidates from GW/Server.

As Justin indicated in PNTAW, TURN 3rd party authentication is not required in case of ICE-TCP from GW/Server.

Thanks
Partha

Note 1: I could not think of more appropriate IETF terminology.

-----Original Message-----
From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] 
Sent: Wednesday, November 13, 2013 12:54 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Harald Tveit Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

Hi Partha

On 2013-11-12 19:33, Ravindran, Parthasarathi (NSN - IN/Bangalore) wrote:
> Hi Magnus,
> 
> ICE-TCP shall be used by WebRTC gateways and conference scenario. The
> related usecases are discussed in
> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html
> (PNTAW mailing alias). So, it should not be simply be removed.
> '

Sorry, I don't understand what your use case is for ICE-TCP. When do you
need to establish an end-to-end TCP connection between two WebRTC
endpoints. I fail to see the motivation for this given that you are
going to establish a PeerConnection across it, with the purpose of
running STUN, RTP, DTLS-SRTP and DTLS/SCTP messages across it.

So please elaborate on why ICE-TCP with an framing for datagrams is not
just redundant from a functionality perspective with TURN/TCP or
TURN/TLS/TCP?

Cheers

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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email