Re: [pntaw] Real-time media over TCP

"Parthasarathi R" <partha@parthasarathi.co.in> Mon, 14 October 2013 18:56 UTC

Return-Path: <partha@parthasarathi.co.in>
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 B3DBE21E80EE for <pntaw@ietfa.amsl.com>; Mon, 14 Oct 2013 11:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level:
X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 88K0-Ig6hM6r for <pntaw@ietfa.amsl.com>; Mon, 14 Oct 2013 11:55:56 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.237]) by ietfa.amsl.com (Postfix) with ESMTP id C57E721F9A44 for <pntaw@ietf.org>; Mon, 14 Oct 2013 11:55:43 -0700 (PDT)
Received: from userPC (unknown [122.172.182.21]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id D2D8D639142 for <pntaw@ietf.org>; Mon, 14 Oct 2013 18:54:40 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1381776881; bh=q8lahyL0G8mARxNfVaFH1PNECeJuMTe/NA0B/E83qJ0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=RNWPwTPiamIWcuptklZSs4Eg8E1h60zOjwzvcELVESx769SKtIAcmkxPeH2QosIti seEMmXYPtFzjxO91XPj032sIDZt15NEXAhH3WuFiXvVNBWtrahaidFHrofFetNJUY5 d9rQrU4n5UAzZ6otSsJgLcO3HU67+CsSW/xOrLfQ=
From: "Parthasarathi R" <partha@parthasarathi.co.in>
To: <pntaw@ietf.org>
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> <E44893DD4E290745BB608EB23FDDB7620A0E2DC6@008-AM1MPN1-043.mgdnok.nokia.com> <9F33F40F6F2CD847824537F3C4E37DDF17BEFB3E@MCHP04MSX.global-ad.net> <BLU402-EAS357ECBFC621A567B9D3A7B4931A0@phx.gbl> <525C148F.8070502@gmail.com>
In-Reply-To: <525C148F.8070502@gmail.com>
Date: Tue, 15 Oct 2013 00:24:37 +0530
Message-ID: <00d401cec90e$d688d5a0$839a80e0$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7I9jgo2wfDX8ucSuitWLbDOSb1HwAFgCTQ
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020208.525C3DF1.00F9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142
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: Mon, 14 Oct 2013 18:56:01 -0000

Hi all,

My point is that the direct media connection has to be given priority over
TURN based mechanism. In case of ICE-TCP, there is a possibility for the
direction connection between two browsers involved in the WebRTC session and
should be given priority over TURN based mechanism. So, 6) TCP based
candidates (ICE-TCP) - MUST

There is an assumption in the discussion that the incoming TCP traffic is
not allowed through firewall. In case it is the problem to be solved, RTCWeb
usecase and requirement has to be updated. I noticed in
draft-ietf-rtcweb-use-cases-and-requirements-12 (published today) that there
is no such requirement. I'll write the mail in RTCWeb WG to get the clarity
on the requirement in case the firewall forbidding incoming TCP traffic is a
matter of missing text in the requirement.

Thanks
Partha  

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
> Of Sergio Garcia Murillo
> Sent: Monday, October 14, 2013 9:28 PM
> To: pntaw@ietf.org
> Subject: Re: [pntaw] Real-time media over TCP
> 
> +1,
> 
> IMO 6) will only have some benefits in the case one of the endpoint
> been
> a gateway, but you would still have to deal with 5), so you won't avoid
> needing a TURN server (in any of its flavors ;)
> 
> BR
> Sergio
> El 14/10/2013 17:08, Bernard Aboba escribió:
> > Agree on Markus's summary. I am also not convinced on #6 being a MUST
> because so far there hasn't been a compelling use case.
> >
> >> On Oct 14, 2013, at 7:42 AM, "Hutton, Andrew"
> <andrew.hutton@siemens-enterprise.com>; wrote:
> >>
> >> On: 11 October 2013 13:22  Markus.Isomaki@nokia.com Wrote
> >>
> >>
> >>> 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.
> >> Totally agree with the nice summary above and agree that 5) is
> necessary we have use cases in draft-ietf-rtcweb-use-cases-and-
> requirements that say we do. We need some mechanism that is HTTP
> compatible and we have these two options available and to me there is
> very little difference between them it is just a matter of whether the
> use of the additional websockets layers give us any benefit. I am not
> convinced that 6) is needed but might be some corner cases it
> satisfies.
> >>
> >> Andy
> >> _______________________________________________
> >> 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
> 
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw