Re: [pntaw] Real-time media over TCP

Justin Uberti <juberti@google.com> Fri, 08 November 2013 23:33 UTC

Return-Path: <juberti@google.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 7133711E80DE for <pntaw@ietfa.amsl.com>; Fri, 8 Nov 2013 15:33:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.778
X-Spam-Level:
X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 TAy6PL5gQ-Sp for <pntaw@ietfa.amsl.com>; Fri, 8 Nov 2013 15:33:03 -0800 (PST)
Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9D79421E8085 for <pntaw@ietf.org>; Fri, 8 Nov 2013 15:33:02 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id c14so1828895vea.18 for <pntaw@ietf.org>; Fri, 08 Nov 2013 15:33:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZqenHQWGocM+Hcv2YwuT+gZVZXBIGD2lZppX+zEc4y8=; b=H07PZPFgtScdazyjrzY5ppJOqExFLMKb+c38Riu3vYxtfugUxcdYJEoTo6wNYWOZP5 EgsLS1TvMEOjQqIC3VaVUrOQ4QqrYTxOBlPUXs9xBuz/BBazlD3OMR8PouB5tzrkv8Rb VHC3g1d6jCvrlZjwfZdKHf4DrkTx038FWz5b37PevCN9XS6YytWtltU/8ezJnd5HjFdB 3oa2LvP9XZykXbEQKX9PrxFu+QGxpPuJPIVdZpMzDvyzbg1d48QNHu+rw7z9aQB7tKcV bxtbuYOhan1ULA1Qn/wFTwdbQogK/8um50yeXTTci+JPMADORXGo2zzlgU0ars+68ClI PrWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZqenHQWGocM+Hcv2YwuT+gZVZXBIGD2lZppX+zEc4y8=; b=ff0tD3au5B8v+NdQxvcBr17U6ED2juqOpaeUtvOC/M8zWgle7mzS+u+JdqQT+VZSkE aFO61rVYrYTzJmR41oWK06NNX4CD8m869p58STt2hko5OaHsb8rth3YAqqmeSgDiGHBZ mr6NPReCGb5Lfixl6EgUIPeS1O8DNYIKRKxLTWIxomffxZI9HtjJ0Ke6OcIZh2GLp4lp oWWfWr+AO+Uvh7fW2e+l2cfaU0i3ksLb/SU59DOjJ52MnKgPR+J/CyinR7KN0qxyLtBT agZAEARhS8qtE4Fx4fsNQfmN7mnCBXFSfLVQNRFdnFAjQidEl5QPl0eHCgStUxTU9lWz 9fJA==
X-Gm-Message-State: ALoCoQnO0bj7dUza5SDAHyn/Qt9GwyiQqwp2BDBteooQPkRSZWdiIyDC4Swf++UHFWlS9ee1Kh9J8B/T4IOBQNwmOJ9QOKBCvseIdvT0MH4q1jNuRbTqL1AZJj8BZjClaboZ9HuWhYHlAJl/HPgvhCQY4Ci6RjIme2f3oyz8nofXUlEcLIgDKXn9PK/vy2RqnbTwfIFvCDRq
X-Received: by 10.52.187.138 with SMTP id fs10mr11607198vdc.10.1383953581530; Fri, 08 Nov 2013 15:33:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 8 Nov 2013 15:32:41 -0800 (PST)
In-Reply-To: <000801cecdae$f6713160$e3539420$@co.in>
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> <A51F486D-3BC0-4090-80CD-B4A15AC3EE69@cisco.com> <913383AAA69FF945B8F946018B75898A2000EB57@xmb-rcd-x10.cisco.com> <8F31D947-AB62-431A-875D-FCBAA2D38290@cisco.com> <525E806B.5060401@alvestrand.no> <000801cecdae$f6713160$e3539420$@co.in>
From: Justin Uberti <juberti@google.com>
Date: Fri, 8 Nov 2013 15:32:41 -0800
Message-ID: <CAOJ7v-3W7Kj_Bn7pTPs+=-wPZRSvC1DzAHB9=2cnK8JiAoK3ug@mail.gmail.com>
To: Parthasarathi R <partha@parthasarathi.co.in>
Content-Type: multipart/alternative; boundary=bcaec548a3859cfe2a04eab2cdbf
Cc: Harald Alvestrand <harald@alvestrand.no>, pntaw@ietf.org
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, 08 Nov 2013 23:33:06 -0000

FWIW: we use ICE-TCP to connect to a conferencing server, instead of
TURN-TCP, to avoid the extra TURN hop and the whole TURN credentials
business. It's an optimization for sure, but a useful one.

I don't think ICE-TCP will be all that useful for P2P connectivity in the
near future. The scenarios that require ICE-TCP are the exact ones where
simultaneous open will probably be impossible.


On Sun, Oct 20, 2013 at 9:10 AM, Parthasarathi R <partha@parthasarathi.co.in
> wrote:

> 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
>
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw
>