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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 23 Jan 2014 02:54:18 +0000

Changes proposed by Chenxin look good.

-Tiru.

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Parthasarathi R
> Sent: Thursday, January 23, 2014 4:49 AM
> To: 'Magnus Westerlund'; 'Chenxin (Xin)'; 'Hutton, Andrew'; 'Christer
> Holmberg'; [email-masked]
> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-
> requirements-12
> 
> I support Chenxin proposal.
> 
> > -----Original Message-----
> > From: Magnus Westerlund [mailto:[email-masked]]
> > Sent: Wednesday, January 15, 2014 3:50 PM
> > To: Chenxin (Xin); Hutton, Andrew; Christer Holmberg; Parthasarathi R;
> > [email-masked]
> > Subject: Re: [rtcweb] Query/Comment on
> > draft-ietf-rtcweb-use-cases-and-
> > requirements-12
> >
> > WG,
> >
> > It has been quite some time since the WG last call ended and a new
> > revision was submitted. As Document Shepherd I want to push this
> > document to publication request.
> >
> > Chenxin proposed below three different sets of changes to the document.
> > Does the WG support making these changes? Please indicate within the
> > next week if you support or want to reject these changes.
> >
> > Thanks
> >
> > Magnus
> >
> >
> > On 2013-10-17 12:23, Chenxin (Xin) wrote:
> > > Hi Andy,
> > >
> > >
> > >
> > >   I think you means F29 not F27:). When I read it , I realize that
> > there
> > > is cross and ambiguous between 3.3.2 and 3.3.3
> > >
> > >
> > >
> > >   More details:
> > >
> > >
> > >
> > >   The topic of 3.3.2 is "Simple Video Communication Service,
> > > *NAT/FW* that blocks UDP". But in the description and requirement,
> > > only *NAT*
> > is
> > > considered.
> > >
> > >   The topic of 3.3.3 is "Simple Video Communication Service, FW that
> > > only allows http", But only *http proxy* deployed scenarios is
> > considered.
> > >
> > >
> > >
> > >   There are other usecases " FW block UDP, incoming TCP, Http
> > allowing
> > > FW without http proxy deplolyed under the permission of FW policy" ,
> > > which is lost in the description. If we need consider these usecases
> > , I
> > > suggest to make some change to the description.
> > >
> > >
> > >
> > >   Proposal 1 :
> > >
> > >
> > >
> > >   add FW related words to section 3.3.2
> > >
> > > -------------------------------------------------
> > >
> > > 3.3.2.  Simple Video Communication Service, NAT/FW that blocks UDP
> > >
> > >
> > >
> > > 3.3.2.1.  Description
> > >
> > >
> > >
> > >    This use-case is almost identical to the Simple Video
> > Communication
> > >
> > >    Service use-case (Section 3.3.1).  The difference is that one of
> > the
> > >
> > >    users is behind a NAT*/FW* that blocks UDP traffic.
> > >
> > > .
> > >
> > >
> > >
> > > 3.3.2.2.  Additional Requirements
> > >
> > >
> > >
> > >    F29     The browser must be able to send streams and
> > >
> > >            data to a peer in the presence of NATs *and FWs* that
> > >
> > >            block UDP traffic ,* when FW policy allows WebRTC
> > traffic*.
> > >
> > > -------------------------------------------------------
> > >
> > >    Proposal 2: If the" Http allowing FW without http proxy deployed"
> > > case is impliedly included in F29. I suggest to change the topics of
> > > 3.3.3 to "Simple Video Communication Service, FW that only allows
> > > traffic via a http proxy". So the 3.3.3 is a specific case.
> > >
> > >
> > >
> > >     Proposal 3: If " Http allowing FW without http proxy deployed"
> > case
> > > need to be explicitly mentioned. I suggest to add some descriptions
> > to 3.3.3
> > >
> > > -----------------------------------------------------------------
> > >
> > > 3.3.3.  Simple Video Communication Service, FW that only allows http
> > >
> > >
> > >
> > > 3.3.3.1.  Description
> > >
> > >
> > >
> > >    This use-case is almost identical to the Simple Video
> > Communication
> > >
> > >    Service use-case (Section 3.3.1).  The difference is that one of
> > the
> > >
> > >    users is behind a http allowing FW or a FW that only allows
> > traffic
> > > via a HTTP Proxy.
> > >
> > >
> > >
> > > 3.3.3.2.  Additional Requirements
> > >
> > >
> > >
> > >    F37     The browser must be able to send streams and
> > >
> > >            data to a peer in the presence of http allowing FWs or
> > > FWs that only
> > >
> > >            allows traffic via a HTTP Proxy, when FW policy
> > >
> > >            allows WebRTC traffic.
> > >
> > > -------------------------------------------------------------------
> > >
> > >
> > >
> > >
> > >
> > > Best Regards,
> > >
> > >      Xin
> > >
> > >
> > >
> >
> >
> > --
> >
> > Magnus Westerlund
> >
> > ----------------------------------------------------------------------
> > Services, Media and Network features, Ericsson Research EAB/TXM
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  +46 10 7148287
> > Färögatan 6                 | Mobile +46 73 0949079
> > SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> > ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 23 Jan 2014 05:35:21 +0000

Hi Partha,

Inline

> From: Parthasarathi R [mailto:[email-masked]]
> Sent: Thursday, January 23, 2014 5:03 AM
> To: Tirumaleswar Reddy (tireddy); 'Magnus Westerlund'; 'Chenxin (Xin)';
> 'Hutton, Andrew'; 'Christer Holmberg'; [email-masked]
> Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-
> requirements-12
> 
> Hi Thiru,
> 
> I agree with you that PCP is yet another alternative. It is not clear to me from
> your mail whether you are fine with the word "TURN" in the requirement
> draft to refer PCP as a solution in the later stage.
> 
> It is confusing to me when I'm discussing about WebRTC FW proposal to
> others as they assume that it is "TURN" as per requirement draft.

I don't see any specific mention in the requirements section that TURN is the only way to solve the WebRTC FW traversal problem.  

-Tiru.

> Partha
> > From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> > Sent: Tuesday, January 21, 2014 2:48 PM
> > To: Magnus Westerlund; Parthasarathi R; 'Chenxin (Xin)'; 'Hutton,
> > Andrew'; 'Christer Holmberg'; [email-masked]
> > Subject: RE: [rtcweb] Query/Comment on
> > > From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus
> > > Westerlund
> > > Sent: Monday, January 20, 2014 3:29 PM
> > > To: Parthasarathi R; 'Chenxin (Xin)'; 'Hutton, Andrew'; 'Christer
> > Holmberg';
> > > [email-masked]
> > > Hi Partha,
> > > On 2014-01-18 19:18, Parthasarathi R wrote:
> > > > 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.
> > >
> > > Noted, I like to get more input from the WG if they think this
> > > should
> > be
> > > changed to use media relay.
> > >
> > > >
> > > > ICE-TCP and TURN server are two different relay mechanism whenever
> > > > browser is not possible to transport the media in UDP.
> > >
> > > My personal opinion is that the above is incorrect statement. I
> > believe you
> > > may be able to realize a higher layer gateway using ICE-TCP. But ICE
> > TCP per
> > > say is not a relay mechanism. To my understanding the core part of
> > ICE-TCP
> > > is the establishment of an end-to-end TCP connection between the ICE
> > > agents. I also note that with our current transport stacks you still
> > need a
> > > framing on top of the TCP connection to realize the datagrams that
> > carries
> > > the RTP or DTLS packets.
> > >
> > >  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.
> > >
> > > I personally are uncertain if there exist any need for changing the
> > use-case
> > > and requirements draft. I would like to note the following text in
> > the use-case
> > > and requirements draft:
> > >
> > >    This document was developed in an initial phase of the work with
> > >    rather minor updates at later stages.  It has not really served
> > > as
> > a
> > >    tool in deciding features or scope for the WGs efforts so far.
> > > It
> > is
> > >    proposed to be used in a later phase to evaluate the protocols and
> > >    solutions developed by the WG.
> > >
> > > So, I believe the basic NAT/FW requirement exist. It might be to
> > solution
> > > focused in its description. However, it is also clear that we have a
> > number of
> > > solution parts that exist beyond the requirements.
> >
> > Yes, there could other solutions to solve the FW problem for example
> > by using PCP (http://tools.ietf.org/search/draft-penno-rtcweb-pcp-
> > 00#section-3.1)
> >
> > -Tiru.
> >
> > >
> > > So, I still see need WG participants to provide feedback on this to
> > determine
> > > if there exist any consensus to modify the use-case document or not.
> > >
> > > Cheers
> > >
> > > Magnus Westerlund
> > >
> > > --------------------------------------------------------------------
> > > -
> > -
> > > --------------------------------------------------------------------
> > > -
> > -
> > > --------------------------------------------------------------------
> > > -
> > -
> > >