Re: [pntaw] Real-time media over TCP

<Markus.Isomaki@nokia.com> Wed, 09 October 2013 17:36 UTC

Return-Path: <Markus.Isomaki@nokia.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E6421E814A for <pntaw@ietfa.amsl.com>; Wed, 9 Oct 2013 10:36:59 -0700 (PDT)
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=[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 e-rK-pfdCaXJ for <pntaw@ietfa.amsl.com>; Wed, 9 Oct 2013 10:36:54 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 951B421E805F for <pntaw@ietf.org>; Wed, 9 Oct 2013 10:36:54 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.26]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r99HTtZN021602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 9 Oct 2013 20:29:55 +0300
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.224]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.03.0136.001; Wed, 9 Oct 2013 17:29:54 +0000
From: Markus.Isomaki@nokia.com
To: partha@parthasarathi.co.in, simon.perreault@viagenie.ca, pntaw@ietf.org
Thread-Topic: [pntaw] Real-time media over TCP
Thread-Index: AQHOpWlrwk9eq/rvIEmYBkw2NSNGdZmyI/aAgACifgCAAN6pAIAApSuAgAAM8oCAACMQgIA1SsoAgAAHUgCAAYcrAIAACRcAgAF6zgCAAAPgcA==
Date: Wed, 09 Oct 2013 17:29:54 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A0D672F@008-AM1MPN1-042.mgdnok.nokia.com>
References: <CAGTXFp92jSzQz05uHngzscz88n=fT_JPbEvQRxgeUUqPVRQUyQ@mail.gmail.com> <52244DD7.1020900@alvestrand.no> <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl> <522590EE.7070508@alvestrand.no> <C632A223-A55A-47F4-B083-9BDC447DA959@cisco.com> <52262657.3080208@alvestrand.no> <A2C315DB-1882-4BD1-A8C0-E8AF7DEA48F4@cisco.com> <00ca01cec387$f881cae0$e98560a0$@co.in> <BLU406-EAS274696C3D9DFE505F96B8E393130@phx.gbl> <004201cec44f$381a47f0$a84ed7d0$@co.in> <52544E0E.5080405@viagenie.ca> <003b01cec511$27e1abe0$77a503a0$@co.in>
In-Reply-To: <003b01cec511$27e1abe0$77a503a0$@co.in>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IhueGIqUfGX1Vo3TN0QuXNLYJ0nYlxFdLFJ5gcB/PGe53F84VK518ganGlutIy+o0MU6sTNCUH7/ZKSzG1tsY08YZ1WSe3114qbZYLHJo/sijV3LmoKgzfDvxeg6LXMqY0XjGFDVD13ObRalSFs0aBBTUObDVKdYN/pUpib2TAy6Ie0vW48/ap31ZEtJhVVVpx2PW4Gb8laD1xJakbzopy9luigbwLJJQAWEdev5+7Kn
x-originating-ip: [10.163.168.177]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: Re: [pntaw] Real-time media over TCP
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Oct 2013 17:36:59 -0000

Hi,

I think the clarification is that it is not possible to initiate TCP connections from the "outside" of any NAT or most of the firewalls. So even if the FW does not block TCP per se, it only allows TCP connections to be opened from the "inside". 

I believe ICE-TCP will typically work only in cases where at least one of the endpoints is NOT behind a NAT or FW. In cases where both endpoints are behind firewalls completely blocking all UDP, the only option is to use a relay (TURN) with endpoint initiated TCP connections. ICE allows us to optimize connectivity in special cases, but I think we need also to make the worst case scenarios to work. For that reason I don't see that ICE-TCP could replace TURN as a requirement for every browser to implement. In some specific deployments it may be that TURN does not get used much or at all, but browsers are used everywhere.

Markus 

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
> Of ext Parthasarathi R
> Sent: 09 October, 2013 20:01
> To: 'Simon Perreault'; pntaw@ietf.org
> Subject: Re: [pntaw] Real-time media over TCP
> 
> Hi Simon,
> 
> I have seen only two requirements in
> draft-ietf-rtcweb-use-cases-and-requirements-11, NAT/FW that blocks UDP
> and FW that only allows http. The relevant draft snippet is attached as a note
> of this mail. I'm discussing about NAT/FW that blocks UDP requirement. In
> case you foresee that the requirement is not detailed now, we need to sort
> out the requirement first before discussion the solutions.
> 
> Regards
> Partha
> 
> PS: In draft-ietf-rtcweb-use-cases-and-requirements-11 snippet,
> 
> 3.2.2.  Simple Video Communication Service, NAT/FW that blocks UDP
> 
> 3.2.2.1.  Description
> 
>    This use-case is almost identical to the Simple Video Communication
>    Service use-case (Section 3.2.1).  The difference is that one of the
>    users is behind a NAT that blocks UDP traffic.
> 
> 3.2.3.  Simple Video Communication Service, FW that only allows http
> 
> 3.2.3.1.  Description
> 
>    This use-case is almost identical to the Simple Video Communication
>    Service use-case (Section 3.2.1).  The difference is that one of the
>    users is behind a FW that only allows http traffic.
> 
> > -----Original Message-----
> > From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On
> Behalf
> > Of Simon Perreault
> > Sent: Tuesday, October 08, 2013 11:55 PM
> > To: pntaw@ietf.org
> > Subject: Re: [pntaw] Real-time media over TCP
> >
> > Le 2013-10-08 19:52, Parthasarathi R a écrit :
> > > I understand that two WebRTC endpoint are behind firewall scenario
> > wherein
> > > TURN server is unavoidable. Most of the SP & Enterprise deployment
> > wherein
> > > one of the endpoint is not surely going to be behind UDP blocking
> > Firewall,
> > > mandating TURN server as a mechanism is overkill. As ICE is mandated
> > in
> > > WebRTC, supporting ICE-TCP should not be such a complex activity.
> >
> > A firewall that blocks UDP but allows incoming TCP is not very common,
> > is it?
> >
> > Or did I miss something?
> >
> > 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
> > _______________________________________________
> > pntaw mailing list
> > pntaw@ietf.org
> > https://www.ietf.org/mailman/listinfo/pntaw
> 
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw