Re: [pntaw] Real-time media over TCP

On Fri, Nov 8, 2013 at 3:58 PM, <Markus.Isomaki@nokia.com> wrote:

>  Hi Justin,
>
>
>
> It’s great to hear that at least one browser will be able to do ICE-TCP.
> It is an optimization, but definitely a useful one for certain central
> server and gateway situations. I have heard also from other service/gateway
> providers that they want to avoid the TURN-TCP “hop” for the same reasons
> you state. After listening to them, I’d say ICE-TCP ought to be rather a
> “SHOULD” instead of “MAY” in the RTCWeb NAT traversal framework.
>

Sounds good.

>
>
> I suppose that when real-time media runs over TCP, it is in general best
> to avoid bundling, but to run the different medias over separate TCP
> connections. That way a single lost packet only affects the rate of one of
> the medias instead of the aggregate.
>
>
>
That is an interesting idea, but I think it is probably difficult to make
work because the BUNDLE decision happens separately from ICE candidate pair
selection.

I think what we really want is some sort of multi-TCP transport, where we
can open several simultaneous TCP connections and rotate between them. Or
maybe a Minion TCP-based approach. These would have their own issues, but
be conceptually simpler.

>  I wonder if you already have a plan in Chrome if and how to deal with
> HTTP (and TLS) restricted firewalls. Are you OK with the idea of connecting
> to a TURN server with HTTP CONNECT, or do you see some issues with that?
>

We already use HTTP CONNECT with ICE-TCP, TURN-TCP, and TURN-TLS. It works.

>
>
> Markus
>
>
>
>
>
> *From:* pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] *On Behalf
> Of *ext Justin Uberti
> *Sent:* 09 November, 2013 01:33
> *To:* Parthasarathi R
> *Cc:* Harald Alvestrand; pntaw@ietf.org
>
> *Subject:* 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
>
>
>