IETF Logo Mail Archive

Re: [pntaw] Real-time media over TCP

<Markus.Isomaki@nokia.com> Fri, 11 October 2013 12:26 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 AFF7621E80FB for <pntaw@ietfa.amsl.com>; Fri, 11 Oct 2013 05:26:53 -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 Qis-wLo8j5CS for <pntaw@ietfa.amsl.com>; Fri, 11 Oct 2013 05:26:47 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id F2BB921E81B8 for <pntaw@ietf.org>; Fri, 11 Oct 2013 05:26:36 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.26]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r9BCLcox023472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 11 Oct 2013 15:21:39 +0300
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.235]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.03.0136.001; Fri, 11 Oct 2013 12:21:38 +0000
From: Markus.Isomaki@nokia.com
To: partha@parthasarathi.co.in, hangzhou.chenxin@huawei.com, simon.perreault@viagenie.ca, pntaw@ietf.org
Thread-Topic: [pntaw] Real-time media over TCP
Thread-Index: AQHOpWlrwk9eq/rvIEmYBkw2NSNGdZmyI/aAgACifgCAAN6pAIAApSuAgAAM8oCAACMQgIA1SsoAgAAHUgCAAYcrAIAACRcAgAF6zgCAAAPgcIAAkKAAgAEIx4CAAS4k0A==
Date: Fri, 11 Oct 2013 12:21:37 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A0E2DC6@008-AM1MPN1-043.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> <E44893DD4E290745BB608EB23FDDB7620A0D672F@008-AM1MPN1-042.mgdnok.nokia.com> <9E34D50A21D1D1489134B4D770CE039768081AC9@SZXEMA504-MBX.china.huawei.com> <004e01cec5df$cf8daaf0$6ea900d0$@co.in>
In-Reply-To: <004e01cec5df$cf8daaf0$6ea900d0$@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.166.235]
Content-Type: text/plain; charset="us-ascii"
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: Fri, 11 Oct 2013 12:26:54 -0000

Hi Partha,

Parthasarathi R [mailto:partha@parthasarathi.co.in] wrote:
> 
> Hi all,
> 
> As I mentioned below, ICE-TCP is not replacement for TURN but ICE-TCP
> helps for the browser-to-browser media flow without middle box (TURN
> Server).
> Also, please note that both browsers behind UDP blocked firewall is not the
> worst case scenario for WebRTC firewall requirements. The actual worst case
> scenario is that both browsers are behind HTTP only firewalls and in this
> scenario, both TURN server and ICE-TCP will not work. There is a need of one
> more solution.
>

Agree. And we need to consider that BOTH endpoints may be behind such firewalls.
 
> AFAIK, HTTP allowing firewall is not happen by mis-configuration but it is
> policy of the given network. It is more appropriate to pass the media over
> HTTP based mechanism rather than finding the workarounds. The advantage
> with Media over HTTP is that HTTP friendly firewall shall filter out media from
> HTTP traffic if required. IMO, Media over HTTP based mechanism has to be
> used for HTTP only firewall (Sec 3.2.3 of
> draft-ietf-rtcweb-use-cases-and-requirements) requirement and ICE-TCP
> shall be used for (Sec 3.2.3 of draft-ietf-rtcweb-use-cases-and-
> requirements)
> requirement.
> 

So, what is the overall set of traversal / connectivity / address gathering mechanisms the browser should support that you are advocating? Mine is:

1.) UDP host candidates (native interface) - MUST
2.)UDP server-reflexive candidates (STUN) - MUST
3.) UDP relay candidates via UDP (TURN) - MUST
4.) UDP relay candidates via TCP (TURN) - MUST
5.) UDP relay candidates via some HTTP/TLS compatible transport (TURN) - MUST/SHOULD
   (TLS via HTTP CONNET or TURN over WebSockets have been proposed.)
6.) TCP based candidates (ICE-TCP) - MAY/SHOULD

I believe 1.), 2.) and 3.) we all have consensus on, probably even on 4.). What we are discussing on this list is whether and how to do 5.), and how important 6.) is. 

My opinion is that 5.) becomes necessary due to the HTTP-limited environments you mention above. So the communication needs to be compliant with HTTP and its upgrade mechanisms. 6.) I see as an optimization to 4.) in cases where you can't do UDP but can establish outgoing TCP connections and the other peer can actually receive them. But that optimization does not hold very often, since most of the time browsers are in networks where they can't receive TCP connections from the "outside world". So that's why I see it as MAY or SHOULD. You may argue that often browsers may talk to gateways or central points that are reachable by TCP, and in those scenarios ICE-TCP might make sense. 

Markus

v2.23.0 | Report a Bug | By Email