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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 21 Jan 2014 09:18:10 +0000

> -----Original Message-----
> 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]
> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-
> requirements-12
> 
> 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
> 
> ----------------------------------------------------------------------
> 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: "Parthasarathi R" <[email-masked]>
Date: Thu, 23 Jan 2014 05:03:13 +0530

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.

Thanks
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 draft-ietf-rtcweb-use-cases-and-
> requirements-12
> 
> 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.
> 
> >

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 23 Jan 2014 10:17:33 +0000

> as they assume that it is "TURN" as per requirement draft.

In the early phases of the use-case draft we did not use the words
"ICE", "STUN" or "TURN" - things were stated more technology neutral.

But at some stage it was pretty clear that ICE was the solution the WG
was going for; and at the same time many wanted to have ICE specific
requirements (such as "The browser must be able to use several STUN and
TURN servers") included.

So we made the change and started talking about ICE, STUN and TURN in
the document (but note that in the description it is still said
"Assuming that ICE will be used").

I am not super happy about having the requirements depend on choosing a
certain solution, but at the same time I think that ICE is a corner
stone so for me it is livable to have in the document.

Stefan

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 24 Jan 2014 06:43:51 +0530

Hi Stefan,

Thanks a lot for providing the background. We are in the same page w.r.t
ICE. My concern is w.r.t TURN word usage only. It will be great in case
"TURN" is replaced with "Firewall traversal" in the below mentioned snippet
of the draft.
 
<snip>
Sec 3.3.4.1
the service provider would like to be able to provide several STUN and TURN
servers (via the app) to the browser;

Sec 3.3.5.1
It must be possible to configure the browsers used in the enterprise with
network specific STUN and TURN servers.

The RTCWEB functionality will need to utilize both network specific STUN and
TURN resources and STUN and TURN servers provisioned by the web application.

Sec 4.2

 F31     The browser must be able to use several STUN
           and TURN servers
   ----------------------------------------------------------------
   F32     There browser must support that STUN and TURN
           servers to use are supplied by other entities
           than via the web application (i.e. the network
           provider).
   ----------------------------------------------------------------

Appendix A

 A22     The Web API must provide means for the application to specify
several STUN and/or TURN servers to use.
</snip>

Also, Could you plese add the statement in the line of that "Firewall
traversal mechanism in this document shall be TURN, ICE-TCP, TURN over
WebSocket, PCP" to provide more clarity.

Thanks
Partha

> From: Stefan Håkansson LK [mailto:[email-masked]]
> Sent: Thursday, January 23, 2014 3:48 PM
> To: Parthasarathi R; 'Tirumaleswar Reddy (tireddy)'; Magnus Westerlund;
> 'Chenxin (Xin)'; 'Hutton, Andrew'; Christer Holmberg; [email-masked]
> >>> Noted, I like to get more input from the WG if they think this
> should
> >> be
> >>> may be able to realize a higher layer gateway using ICE-TCP. But
> ICE
> >> TCP per
> >>> agents. I also note that with our current transport stacks you
> still
> >> need a
> >>>> for browser-to-webrtc gateway. The related mail thread is
> discussed
> >> in
> >>>> PNTAW as
> >>>    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
> >>> focused in its description. However, it is also clear that we have
> a
> >> number of
> >>> -------------------------------------------------------------------
> --
> >> -
> >>> -------------------------------------------------------------------
> --
> >> -
> >>> -------------------------------------------------------------------
> --
> >> -
> =

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 24 Jan 2014 06:56:56 +0530

Hi Stefan,

The word has to be "NAT/Firewall traversal" instead of "Firewall traversal".

Thanks
Partha

> From: Parthasarathi R [mailto:[email-masked]]
> Sent: Friday, January 24, 2014 6:44 AM
> To: 'Stefan Håkansson LK'; 'Tirumaleswar Reddy (tireddy)'; 'Magnus
> Westerlund'; 'Chenxin (Xin)'; 'Hutton, Andrew'; 'Christer Holmberg';
> [email-masked]'
> Thanks a lot for providing the background. We are in the same page
> w.r.t ICE. My concern is w.r.t TURN word usage only. It will be great
> in case "TURN" is replaced with "Firewall traversal" in the below
> mentioned snippet of the draft.
> 
> <snip>
> Sec 3.3.4.1
> the service provider would like to be able to provide several STUN and
> TURN servers (via the app) to the browser;
> 
> Sec 3.3.5.1
> It must be possible to configure the browsers used in the enterprise
> with network specific STUN and TURN servers.
> 
> The RTCWEB functionality will need to utilize both network specific
> STUN and TURN resources and STUN and TURN servers provisioned by the
> web application.
> 
> 
> Sec 4.2
> 
> > > I agree with you that PCP is yet another alternative. It is not
> clear
> > to me
> > > It is confusing to me when I'm discussing about WebRTC FW proposal
> to
> > others
> > >> Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-
> cases-
> > and-
> > >> requirements-12
> > >>
> > >>> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-
> cases-
> > >> and-
> > >>> requirements-12
> > >>>
> > >>> Hi Partha,
> > >>>
> > >>>
> > >>>> I have trouble in the usage of TURN instead of media relay
> server
> > >> in
> > >>> say is not a relay mechanism. To my understanding the core part
> of
> > >> ICE-TCP
> > >>> framing on top of the TCP connection to realize the datagrams
> that
> > >> carries
> > >>> the RTP or DTLS packets.
> > >>>
> > >>>> http://www.ietf.org/mail-
> archive/web/pntaw/current/msg00185.html.
> > >> So,
> > >>>> I preferred to have the separate requirement as discussed in
> this
> > >> mail
> > >>> 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:
> > >>>
> > >> Yes, there could other solutions to solve the FW problem for
> example
> > by
> > >>> So, I still see need WG participants to provide feedback on this
> to
> > >> determine

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Jan 2014 09:18:24 -0500

>   F31     The browser must be able to use several STUN

FWIW, I would completely disagree with that change. It makes no sense to me.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 24 Jan 2014 21:53:28 +0530

Simon,

I could not understand how does it make sense for you to refer "TURN" in the
requirement whereas it implies "PCP" or "ICE-TCP" or "TURN over WebSocket"
in the solution.

Thanks
Partha

> From: rtcweb [mailto:[email-masked]] On Behalf Of Simon
> Perreault
> Sent: Friday, January 24, 2014 7:48 PM
> To: [email-masked]
> w.r.t
> STUN and

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Jan 2014 11:30:34 -0500

> requirement whereas it implies "PCP" or "ICE-TCP" or "TURN over WebSocket"

I understand the text you're suggesting to mean that WebRTC clients 
would be required support at least one in the set { TURN, ICE-TCP, TURN 
over WebSocket, PCP }. This would be broken. A client that chooses to 
support, for example, only PCP would be ridiculously broken. All clients 
MUST support TURN as a base traversal mechanism. Other mechanisms are 
icing on the cake.

I'm fairly sure this is not what you were suggesting though, since that 
would be so obviously broken. That's why I said that your suggestion 
makes no sense to me.

Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 24 Jan 2014 17:32:22 +0100

Where can I find: " "PCP" or "ICE-TCP" or "TURN over WebSocket" in the
solution. " ?
(Haven't followed for a while.)

/Karl

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För Parthasarathi R
Skickat: den 24 januari 2014 17:23
Till: 'Simon Perreault'; [email-masked]
Ämne: Re: [rtcweb] Query/Comment on
draft-ietf-rtcweb-use-cases-and-requirements-12

Simon,

Thanks
Partha

> > Also, Could you plese add the statement in the line of that 
> > "Firewall traversal mechanism in this document shall be TURN, 
> > ICE-TCP, TURN
> over

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 24 Jan 2014 22:31:05 +0530

Hi Karl,

Please look into draft-hutton-rtcweb-nat-firewall-considerations-03.txt for
the initial understanding. The discussion about RTCWeb firewall/NAT is going
on in  Pntaw mailing alias.

Hope you agree that TURN does not mean "PCP" or "ICE-TCP" or "TURN over
WebSocket" in the requirement level after reading the documents.

Thanks
Partha
 
> From: Karl Stahl [mailto:[email-masked]]
> Sent: Friday, January 24, 2014 10:02 PM
> To: 'Parthasarathi R'; 'Simon Perreault'; [email-masked]
> Subject: SV: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-
> requirements-12
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 24 Jan 2014 22:44:10 +0530

Simon,

Please note that when non-IETFers read this requirement document, they come
to the conclusion that IETF RTCWeb WG recommends TURN and not other
mechanisms. I'm saying that requirement document should not be used as the
mechanism to eliminate the other alternatives when there is a discussion
going-on in PNTAW alias. So, I'm asking for the change. 

Let us discuss in PNTAW alias which Firewall/NAT mechanisms have to be used
by WebRTC client, WebRTC gateway/server (Sec 4.3 of
draft-ietf-rtcweb-use-cases-and-requirements-12) and not as part of the
requirement draft.

Thanks
Partha    

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Friday, January 24, 2014 10:01 PM
> To: Parthasarathi R; [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Jan 2014 13:17:38 -0500

> going-on in PNTAW alias. So, I'm asking for the change.

I would totally agree with that sentiment, although I don't see your 
proposed text change reflecting it accurately. How about simply:

"Note that TURN support being mandatory does not preclude a WebRTC 
endpoint from supporting additional traversal mechanisms."

Simon

---

From: Cb B <[email-masked]>
Date: Fri, 24 Jan 2014 16:52:19 -0800

+1 for the above text.

CB

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 25 Jan 2014 22:16:14 +0530

Hi Simon,

Thanks for your understanding about my firewall/NAT related problem
statement in this draft. 

I have proposed the firewall/NAT related text by which the specific
mechanism is not highlighted in the requirement document as there is no WG
consensus for any of the mechanism including TURN. It is possible to argue
hypothetically in PNTAW alias that PCP is the only mechanism required in
WebRTC endpoint.   Also, I’m more interested in WebRTC gateway/server (Sec
4.3. of draft-ietf-rtcweb-use-cases-and-requirements-12) requirements
wherein it is not required to support TURN and the related mail thread is
http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html. 

IMO, my proposed text without mentioning any firewall/NAT mechanism in the
requirement document helps to move forward without depend on the solution
discussion in PNTAW alias.

Thanks

Partha

From: Cb B [mailto:[email-masked]] 
Sent: Saturday, January 25, 2014 6:22 AM
To: Simon Perreault
Cc: [email-masked]; Parthasarathi R
Subject: Re: [rtcweb] Query/Comment on
draft-ietf-rtcweb-use-cases-and-requirements-12

+1 for the above text. 

CB

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Jan 2014 10:28:52 +0100

Hi Partha and WG,

I don't see any support for the changes you proposes in this discussion.
What I see some support for is to add a statement making clear that
there might be additional NAT/Firewall traversal mechanisms than
STUN/TURN. Simon proposed:

However, looking at the document as it is currently written, I am
uncertain where this would be added. The first mention of TURN is in
Section 3.3.4.1, and that section is focused on the global service
provider perspective and the need for location based provisioning of
NAT/Firewall traversal server resources.

I think it can be added to Section 3.3.5.1 without being misplaced, but
it would be given a slightly narrower scope.

I any of you want to be more explicit where this should be included,
please be. If you are not forthcoming I will request the authors to add
this in what they consider sensible position.

Cheers

Magnus

On 2014-01-25 17:46, Parthasarathi R wrote:
> mechanism is not highlighted in the requirement document as there is no
> WG consensus for any of the mechanism including TURN. It is possible to
> argue hypothetically in PNTAW alias that PCP is the only mechanism
> required in WebRTC endpoint.   Also, I’m more interested in WebRTC
> gateway/server (Sec 4.3. of
> draft-ietf-rtcweb-use-cases-and-requirements-12) requirements wherein it
> is not required to support TURN and the related mail thread is
> IMO, my proposed text without mentioning any firewall/NAT mechanism in
> the requirement document helps to move forward without depend on the
> solution discussion in PNTAW alias.
> 
>  
> 
> Thanks
> 
> Partha
> 
>  
> 
> *From:*Cb B [mailto:[email-masked]]
> *Sent:* Saturday, January 25, 2014 6:22 AM
> *To:* Simon Perreault
> *Cc:* [email-masked]; Parthasarathi R
> *Subject:* Re: [rtcweb] Query/Comment on
> On Jan 24, 2014 10:17 AM, "Simon Perreault" <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
>> [email-masked] <mailto:[email-masked]>

-- 

Magnus Westerlund

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 31 Jan 2014 06:56:26 +0530

Hi Magnus,

I can live with Simon text in case it is documented in Sec 4.2  as 

   F31     The browser must be able to use several STUN
           and TURN servers. Note that TURN support being mandatory 
           does not preclude the browser from supporting 
           additional traversal mechanisms.
   ----------------------------------------------------------------
   F32     There browser must support that STUN and TURN
           servers to use are supplied by other entities
           than via the web application (i.e. the network
           provider). Note that TURN support being mandatory 
           does not preclude the browser from supporting 
           additional traversal mechanisms.

and also Appendix A:

A22     The Web API must provide means for the
           application to specify several STUN and/or
           TURN servers to use. Note that TURN support being mandatory 
           does not preclude a Web API from supporting 
           additional traversal mechanisms.

Please let me know in case you have any issue in the above text. 

BTW, just for the record, draft-ietf-rtcweb-use-cases-and-requirements-12
does not specify the list of traversal mechanism requirements for WebRTC
Gateway/Server.

Thanks
Partha

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Wednesday, January 29, 2014 2:59 PM
> To: Parthasarathi R; 'Cb B'; 'Simon Perreault'
> Cc: [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Jan 2014 10:01:38 +0100

Hi Partha,

Personal opinion:

I think the below places the text in the wrong context. The note is in
my mind relevant in the context of the general NAT/FW traversal
requirements, not the one discussing need to support multiple NAT/FW
traversal servers. Thus, I think Section 3.3.2 and thus requirement F29.
Or potentially regarding Requirement F2. Is more appropriate places to
include this.

Cheers

Magnus

On 2014-01-31 02:26, Parthasarathi R wrote:
>>> required in WebRTC endpoint.   Also, I'm more interested in WebRTC

-- 

Magnus Westerlund