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

Simon Perreault <simon.perreault@viagenie.ca> Wed, 13 November 2013 17:40 UTC

Return-Path: <simon.perreault@viagenie.ca>
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 7F38C11E81A8 for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 09:40:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 Tu6vyD2wnAYZ for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 09:40:30 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E36A321E8151 for <rtcweb@ietf.org>; Wed, 13 Nov 2013 09:39:13 -0800 (PST)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d5d4:b853:2212:f683]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EF541403CF; Wed, 13 Nov 2013 12:38:51 -0500 (EST)
Message-ID: <5283B92B.4080304@viagenie.ca>
Date: Wed, 13 Nov 2013 12:38:51 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <parthasarathi.ravindran@nsn.com>, ext Magnus Westerlund <magnus.westerlund@ericsson.com>, Harald Tveit Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <5282391D.3050002@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net> <5283291E.7090108@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net>
In-Reply-To: <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 17:40:31 -0000

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