Re: [pntaw] Real-time media over TCP

[Harald Alvestrand <[e-mail]>]

On 11/10/2013 06:31 PM, Ravindran, Parthasarathi (NSN - IN/Bangalore) wrote:
>
> Hi Harald,
>
>  
>
> Even though there is a note  in Sec 3.4.3.1  for ability to traverse
> very restrictive FWs, there is no additional requirement because of
> this usecase. I attached the exact note and relevant requirement in
> the mail for easy reference.
>

You're right - this note was a leftover when the requirements in section
3.1 were factored out to be "applicable to all scenarios".

The relevant point in 3.1 is:

   o  Clients can be on firewalled networks with no UDP allowed


So are you saying that we should add a requirement in 3.1 to say

 * Clients can be on firewalled network with no UDP or incoming TCP allowed

?

> Also, there is no additional requirement as part of Sec 3.4.1
> (Telephony terminal) or Sec 3.4.2 (WebEx call) w.r.t to traverse very
> restrictive FW. I’m requesting for adding the explicit additional
> requirement in Sec 3.4.3.1 or  Sec 3.4.2.2 or Sec 3.4.3.3 to provide
> the better clarity between ICE-TCP based solution and TURN based
> solution. The requirement shall be in the line of:
>
>  
>
> “The browser should be able to send streams and data to a peer in the
> presence of NATs and FWs that block UDP traffic and incoming TCP
> connection.”
>
>  
>
> I have mailed these requirement change as part of
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09101.html in
> IETF RTCWeb WG. The requirement difference in this mail and archive is
> that “should” is mentioned here whereas “must” was mentioned earlier.
> Also update the existing NAT/FW requirement is to state both browser
> behind firewall scenario as follows:
>
>  
>
> “The browser must be able to send streams and data to a peer in the
> presence of NATs and FWs that block UDP traffic and incoming TCP
> connection in both browser side as well as in the peer side” (TURN
> only works)
>
>  
>
> Thanks
>
> Partha
>
>  
>
> Note: Sec 3.4.3.1 note -
>
>    This use-case adds requirements on support for fast stream
>
>    switches F7, on encryption of media and on ability to traverse very
>
>    restrictive FWs.  There exist several solutions that enable the
>
>    server to forward one high resolution and several low resolution
>
>    video streams: a) each browser could send a high resolution, but
>
>    scalable stream, and the server could send just the base layer for
>
>    the low resolution streams, b) each browser could in a simulcast
>
>    fashion send one high resolution and one low resolution stream, and
>
>    the server just selects or c) each browser sends just a high
>
>    resolution stream, the server transcodes into low resolution streams
>
>    as required.
>
> *3.4.3.2*
> <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12#section-3.4.3.2>*. 
> Additional Requirements*
>
>  
>
>  
>
>    F17
>
>  
>
>    A17
>
>  
>
> Browser requirement:
>
> --
>
>  F17     The browser must be able to mix several
>
>            audio streams.
>
>  
>
> F7      The browser must support insertion of reference frames
>
>            in outgoing media streams when requested by a peer.
>
>  
>
>  
>
>  
>
> *From:*[e-mail] [mailto:[e-mail]] *On
> Behalf Of *ext Harald Alvestrand
> *Sent:* Sunday, November 10, 2013 3:52 AM
> *To:* Parthasarathi R; 'Justin Uberti'; [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [pntaw] Real-time media over TCP
>
>  
>
> 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]>
> [mailto:[e-mail]] *On Behalf Of *Justin Uberti
> *Sent:* Saturday, November 09, 2013 7:27 AM
> *To:* [e-mail] <mailto:[e-mail]>
> *Cc:* Harald Tveit Alvestrand; [e-mail] <mailto:[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.


-- 
Surveillance is pervasive. Go Dark.