Re: [pntaw] Real-time media over TCP

"Parthasarathi R" <partha@parthasarathi.co.in> Sun, 20 October 2013 16:11 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 05C0111E822F for <pntaw@ietfa.amsl.com>; Sun, 20 Oct 2013 09:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.932
X-Spam-Level:
X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_20=-0.74, 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 O-AWJB6x6Dbe for <pntaw@ietfa.amsl.com>; Sun, 20 Oct 2013 09:11:01 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.237]) by ietfa.amsl.com (Postfix) with ESMTP id B634111E81F0 for <pntaw@ietf.org>; Sun, 20 Oct 2013 09:11:01 -0700 (PDT)
Received: from userPC (unknown [122.179.103.73]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id D7B1C639103; Sun, 20 Oct 2013 16:10:57 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1382285460; bh=1U7qGbkS1K8Wmy2yYY7RwBO+VWk1aPEl/CiEeKfu2V8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=kCOgEa9AGmJwYmf/TNznU6EE8nMYe2Sq+GQTMmH4DeNZ17RAnh8/W7jAUu653lju9 UtNDjLtuGTowCoEy+wegAD/pCqRlpNJTFirMfL6Kxgx/tmglzexGs9Y4wOUQDSs/F5 m6Jdb6+ijn4g+jP/A6L4u+F9ZebIiO9m/JS9mP6I=
From: Parthasarathi R <partha@parthasarathi.co.in>
To: 'Harald Alvestrand' <harald@alvestrand.no>, pntaw@ietf.org
References: <CAGTXFp92jSzQz05uHngzscz88n=fT_JPbEvQRxgeUUqPVRQUyQ@mail.gmail.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> <00d401cec90e$d688d5a0$839a80e0$@co.in> <E44893DD4E2 90745BB608EB23FDDB7620A0E7172@008-AM1MPN1-043.mgdnok.nokia.com> <A51F486D-3BC0-4090-80CD-B4A15AC3EE69@cisco.com> <913383AAA69FF945B8F946018B75898A2000EB57@xmb-rcd-x10.cisco.com> <8F31D947-AB62-431A-875D-FCBAA2D38290@cisco.com> <525E806B.5060401@ alvestrand.no>
In-Reply-To: <525E806B.5060401@alvestrand.no>
Date: Sun, 20 Oct 2013 21:40:53 +0530
Message-ID: <000801cecdae$f6713160$e3539420$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7KZ6iicREpjHj0Tm+KWS0ONEzwnADQ9BdA
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020203.52640094.0053, 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-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: Sun, 20 Oct 2013 16:11:06 -0000

Hi Harald & all,

I agree that ICE-TCP qualifies for "MAY" requirement in case both browsers
are behind firewall. ICE-TCP is good for usecase wherein only one of the
browsers is behind firewall. Existing WebRTC usecase namely FedEx call is
good example for only one browser behind firewall wherein IVR is not going
to be behind UDP blocking firewall. In those usecases, ICE-TCP candidates
has merits over TURN relay candidates. IMO, ICE-TCP MUST be considered.

The current WebRTC FW usecase is (accidentially) inline with one of the
browser behind firewall scenario as mentioned in sec 3.3.2.1 of
draft-ietf-rtcweb-use-cases-and-requirements-12:

"The difference is that one of the users is behind a NAT that blocks UDP
traffic."

Thanks
Partha

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
> Of Harald Alvestrand
> Sent: Wednesday, October 16, 2013 5:33 PM
> To: pntaw@ietf.org
> Subject: Re: [pntaw] Real-time media over TCP
> 
> On 10/15/2013 06:15 PM, Dan Wing wrote:
> > On Oct 14, 2013, at 11:02 PM, Tirumaleswar Reddy (tireddy)
> <tireddy@cisco.com> wrote:
> >
> >>> -----Original Message-----
> >>> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On
> Behalf Of Dan
> >>> Wing (dwing)
> >>> Sent: Tuesday, October 15, 2013 5:31 AM
> >>> To: Markus.Isomaki@nokia.com
> >>> Cc: pntaw@ietf.org; partha@parthasarathi.co.in
> >>> Subject: Re: [pntaw] Real-time media over TCP
> >>>
> >>>
> >>> On Oct 14, 2013, at 12:06 PM, Markus.Isomaki@nokia.com wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> In practice I doubt you find many situations where UDP is
> completely blocked
> >>> but incoming TCP connections from anywhere are allowed.
> >>>
> >>> Agreed.
> >>>
> >>> But if both ends are trying to communicate with each other, their
> >>> communications will appear as a TCP simultaneous-open.  That could
> (in fact,
> >>> "should") work across a firewall because the firewall will see an
> outbound SYN
> >>> to a host/port after which it will see an inbound SYN from that
> same
> >>> host/port.
> >> But firewall TCP inspection causes the inbound SYN from the same
> host/port to be dropped (Firewalls typically do not permit TCP
> simultaneous-open). Even with NAT as per the survey results in ICE TCP
> (http://tools.ietf.org/html/rfc6544#appendix-A) TCP simultaneous-open
> worked only in roughly 45% of the cases.
> > If avoiding TURN improves the user experience, and IT policy says TCP
> is allowed, I expect firewall vendors would make sure TCP simultaneous
> open works.
> >
> >
> If something improves the user experience if it is possible to do it,
> but the basic functionality works without it, and it's unclear whether
> the special circumstances under which it's going to improve the user
> experience in fact exist in the field, I think that's perfect for a MAY
> implement.
> 
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw