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 18:02 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 5277111E81A0 for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 10:02:55 -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 Ze-Dm3KmsouP for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 10:02:50 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 909CE11E813A for <rtcweb@ietf.org>; Wed, 13 Nov 2013 10:02:50 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rADI2lxw024593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Nov 2013 19:02:47 +0100
Received: from SGSIHTC001.nsn-intra.net ([10.159.225.18]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rADI2jJM030585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 19:02:47 +0100
Received: from SGSIMBX006.nsn-intra.net ([169.254.6.69]) by SGSIHTC001.nsn-intra.net ([10.159.225.18]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 02:02:45 +0800
From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <parthasarathi.ravindran@nsn.com>
To: ext Simon Perreault <simon.perreault@viagenie.ca>, 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+s8TOpoh62lQgABRywCAARYGsP//lbOAgACJnKA=
Date: Wed, 13 Nov 2013 18:02:45 +0000
Message-ID: <40AFDF4AF1909E4CB42B6D91CE6C419D19C74E3B@SGSIMBX006.nsn-intra.net>
References: <5282391D.3050002@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net> <5283291E.7090108@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net> <5283B92B.4080304@viagenie.ca>
In-Reply-To: <5283B92B.4080304@viagenie.ca>
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: 2260
X-purgate-ID: 151667::1384365767-00005753-BC8B197A/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 18:02:55 -0000

Hi Simon,

Please note that I'm only taking about Gateway/conference/IVR server usecases wherein Gateway/conference/IVR server will not be behind restrictive firewall and only the browser may be behind the restrictive firewall. 

TURN server will also make TCP connection to the GW provider in the mentioned scenario. So, there is no difference between ICE-TCP/TURN w.r.t TCP connection creation. In case TCP connection could not made between GW provider and the browser, the call will fail irrespective of firewall traversal mechanism (TURN/ICE-TCP) used. Also, there is no need of fallback to TURN server for these usecases. It is one of the reason, I'm asking for the separate usecase which clarify the requirements easily.

Thanks
Partha

-----Original Message-----
From: ext Simon Perreault [mailto:simon.perreault@viagenie.ca] 
Sent: Wednesday, November 13, 2013 11:09 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); ext Magnus Westerlund; Harald Tveit Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

Le 2013-11-13 11:33, Ravindran, Parthasarathi (NSN - IN/Bangalore) a écrit :
> 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.

All this relies on the possibility that a TCP peer-to-peer connection 
could be successfully established where a UDP one couldn't. IMHO this is 
very unlikely to happen in practice. So unlikely in fact that any 
possible gain over just falling back on a TURN relay wouldn't be worth 
the additional implementation cost.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

v2.23.0 | Report a Bug | By Email