Re: [pntaw] Real-time media over TCP

[Harald Alvestrand <[e-mail]>]

On 11/09/2013 10:55 AM, Parthasarathi R wrote:
>
> Hi Justin,  Markus & all,
>
>  
>
> It is good to know that conference server usecase as well for ICE-TCP
> usage. I think that it is better to request for adding conference/IVR
> Server/Gateway with firewall usecases explicitly in the RTCWeb usecase
> & requirement document in case there is no other objection in this
> mail thread.
>

Section 3.4.3 "Video conferencing system with central server" seems to
already cover this case.

In particular (from -12):

   Note: This use-case adds requirements on ..... ability to traverse very
   restrictive FWs.

>  
>
> Thanks
>
> Partha
>
>  
>
> *From:*[e-mail] [mailto:[e-mail]] *On
> Behalf Of *Justin Uberti
> *Sent:* Saturday, November 09, 2013 7:27 AM
> *To:* [e-mail]
> *Cc:* Harald Tveit Alvestrand; [e-mail]; Parthasarathi R
> *Subject:* Re: [pntaw] Real-time media over TCP
>
>  
>
>  
>
>  
>
> On Fri, Nov 8, 2013 at 3:58 PM, <[e-mail]
> <mailto:[e-mail]>> 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:*[e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail] <mailto:[e-mail]>]
>     *On Behalf Of *ext Justin Uberti
>     *Sent:* 09 November, 2013 01:33
>     *To:* Parthasarathi R
>     *Cc:* Harald Alvestrand; [e-mail] <mailto:[e-mail]>
>
>
>     *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
>     <[e-mail] <mailto:[e-mail]>>
>     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: [e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail] <mailto:[e-mail]>] On
>     Behalf
>
>     > Of Harald Alvestrand
>     > Sent: Wednesday, October 16, 2013 5:33 PM
>     > To: [e-mail] <mailto:[e-mail]>
>     > 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)
>     > <[e-mail] <mailto:[e-mail]>> wrote:
>     > >
>     > >>> -----Original Message-----
>     > >>> From: [e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail] <mailto:[e-mail]>] On
>     > Behalf Of Dan
>     > >>> Wing (dwing)
>     > >>> Sent: Tuesday, October 15, 2013 5:31 AM
>     > >>> To: [e-mail] <mailto:[e-mail]>
>     > >>> Cc: [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>
>     > >>> Subject: Re: [pntaw] Real-time media over TCP
>     > >>>
>     > >>>
>     > >>> On Oct 14, 2013, at 12:06 PM, [e-mail]
>     <mailto:[e-mail]> 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
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/pntaw
>
>     _______________________________________________
>     pntaw mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/pntaw
>
>      
>
>  
>


-- 
Surveillance is pervasive. Go Dark.