Re: [pntaw] Real-time media over TCP

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
>