Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12

["Parthasarathi R" <[e-mail]>]

Hi Magnus,

I have trouble in the usage of TURN instead of media relay server in the
requirement document as TURN is the solution and not the requirement. 

ICE-TCP and TURN server are two different relay mechanism whenever browser
is not possible to transport the media in UDP. TURN server is good in case
of browser-to-browser scenario wherein ICE-TCP is preferred approach for
browser-to-webrtc gateway. The related mail thread is discussed in PNTAW as
http://www.ietf.org/mail-archive/web/pntaw/current/msg00185.html. So, I
preferred to have the separate requirement as discussed in this mail thread
which leads to the conclusion as part of PNTAW alias discussion. Please let
me know your opinion on the same.

Thanks
Partha

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Wednesday, January 15, 2014 4:04 PM
> To: Parthasarathi R; 'Chenxin (Xin)'; 'Hutton, Andrew'; 'Christer
> Holmberg'; [e-mail]
> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-
> requirements-12
> 
> Hi Partha,
> 
> I see this as an outstanding question on the use-cases document and I
> want to resolve it prior to the publication request.
> 
> I want to check my understanding of the points you bring up. See below.
> 
> On 2013-10-20 18:35, Parthasarathi R wrote:
> > Hi Xin & all,
> >
> >
> >
> > Apart from modified F29 by Xin, the following requirement has to be
> > discussed:
> >
> > 1)      New requirement for blocking incoming TCP connection:
> >
> > a.        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
> 
> So the point of this requirement would be to differentiate to the other
> existing requirements that a NAT/FW combination may provide no UDP and
> no support for incoming TCP. Thus, if one goes into solution space, you
> need a proxy/relay solution where a peer can establish a point of
> presence outside of the NAT/FW which is reachable over non-UDP, thus
> assuming TCP as only alternative.
> 
> From my perspective the combination of F2 and F29 implicitly demands
> the
> support of a relay solution, and that it is unnecessary to add an
> explicit requirement. This as the failure rate for incoming TCP
> connections through any NAT is high irrespective of explicit blocking
> of
> incoming TCP or not.
> 
> >
> > 2)      New requirement to cover both browsers are behind the
> firewall
> >
> > a.         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)
> 
> I think this is unclear, as there are two aspects of this. The peers
> are
> either behind different FW or the same FW/NAT. If it is the second, I
> think this will simply work the same way two client on an non
> firewalled
> network would work. At least ICE will find it. If it is the first, I
> think that is implicitly included in F2.
> 
> Thus I question if there any utility in adding anything about this in
> the use-case document.
> 
> WG, please contribute your views on this and if we need to make any
> changes to the document in regards to this proposal.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------