Subject: [rtcweb] New version of use-case draft uploaded

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 6 Feb 2014 10:52:43 +0000

Hi,

I've uploaded a new version -13 [1]. I have made changes based on input
from Mary, Magnus and Chenxing+Andy, for details read further down.

I hope I have caught most things; what remains to my knowledge is:
* Include the requirement text the first time a requirement is derived
* Group (and re-number) the claims

I am hesitating to do the last thing 'cause of the risk of getting all
internal references into a mess, but one day soon I will feel brave
enough :-)

Stefan

[1]
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/

======================================
On 2014-01-15 21:57, Mary Barnes wrote:
> I had thought I had previously done a detailed review of this doc, but
I can't find it to know whether changes suggested have been
incorporated. So, I have re-reviewed the document and I think it's
almost ready to progress. I think it needs some editorial clarifications
and nits to be fixed as summarized below. Note, I did not review the
appendix.
> Regards,
> Mary.
> In general, I still find the style of this document very difficult to
grok since the requirements are not grouped in categories and one has to
keep switching back and forth in the document to match requirements to
use cases.
> Questions/Comments for clarification:
> ----------------------------------------------------
> 1) Section 1, 1st paragraph, last sentence. It's not clear to me that
"e.g., a telephone" is meaningful. I don't think you're intending to
interworking with a legacy PSTN connected black phone. So, it might be
more accurate to say " e.g., a mobile phone or a SIP UA".

Changed.

> 2) Section 3.3.1.1. Next to last paragraph. I'm not sure what you mean
by different "makes". I think you mean different types of devices (e.g.,
mobile, SIP UA, etc. ). That all said, I don't think that's not so
relevant. I think simply stating different OSs and different browsers is
sufficient.

Changed.

> 3) Section 3.3.6.1. It's not at all clear to me why this requirement
is considered specific to WebRTC. I would think the access network
changes should be transparent to WebRTC. Certainly, the device needs to
know what's happening, but I think whether this works is entirely based
on the internals of the device and the specific access network
technology, and not WebRTC application.

It is not WebRTC specific per se, but is important for the use-case.
What parts that solve it is of less importance IMO.

> 4) Section 3.3.10.1. Why is F24 not considered an additional
requirement here? Also, do you not need to have a statement as to what
other use case is the basis for this one such that the core requirements
are reference?

I added F24 (it belongs here). I don't think we need a statement
regarding the basis, it is covered in section 3.2

> 5) Section 3.3.11.1, 2nd paragraph, 1st sentence. I don't understand
what this is trying to say. What is meant by "enhance intelligibility"?
And, what is meant by "pans the audio from different participants
differently when rendering the audio".
> [As an aside, I will note that some of the CLUE use cases likely
encompass what you are trying to communicate here in this requirements
(including subsequent paragraphs and the last "Note:"), so you may want
to look at those and use similar terminology and concepts, that CLUE
spent a lot of time developing. ]

I updated (using similar terminology to Clue).

> 6) Section 3.4. I would expect F27 to be referenced by at least one of
these use cases.

I added it to 3.4.1

> 7) Section 4.2.
> - General: I am a bit confused as there are requirements in this
section that aren't referenced in section 3, including F19, F23, and F27
. Perhaps, that's because there are some missing references in section 3
(see item 7)? If not, then why are they there. At a minimum you should
add a sentence to section 4.1 indicating that not all the requirements
are derived from the use cases (contrary to what is currently stated).

F19 has been removed. I added ref to F23 (and F24!) from ues-case
"multi-party game with voice communication". Ref to F27 added to 3.4.1.

> - What's the difference between F24 and F34?

I don't know, and I removed F34

> - F30. I had to read this several times to understand it due to
structure. I would suggest changing as follows:
> OLD:
> F30 The browser must be able to use the screen (or
> a specific area of the screen) or what a certain
> application displays on the screen to generate
> streams.
> NEW:
> F30 The browser must be able to generate streams using the entire user
display, a specific area of the user's display or the information being
displayed by a specific application.

Updated.

> On this one, I also think it would be good to clarify what type of
stream - are you talking about using protocol to share content or or is
this just a video stream? Or would you have two separate requirement to
cover both of these?

I would like to avoid going into detail; the idea is that it is some
kind of "stream" that allows sharing what is rendered on your screen,
the requirement does not need to go into what kind it is.

> - F32. I can't quite grok this one. Maybe you are trying to say
something like the following?
> OLD:
> 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).
> NEW:
> F32 The browser must support the use of STUN and TURN
> servers that are supplied by entities
> other than the web application (i.e. the network
> provider).

Updated.

> 8) Section 7. I have mixed feelings about leaving this list with URLs
in the document. I think it's good to highlight the use cases that
weren't incorporated and why they weren't. I think it would add a lot
more value to provide a concise summary of the reasons they weren't
added than just including links, in particular, since we usually don't
like to publish RFCs with links.

I think the entire list should go before publication. The list has been
kept there as a reminder of what we included and what we did not
included. I have removed it in this version.

> Nits:
> ------
> 1) Section 1, 1st paragraph, last sentence, "at least one of the
end-user client" -> "at least one of the end-user clients"
> 2) Section 3.2, 1st paragraph, 1st sentence:
> - "retrives" -> "retrieves"
> - add a section reference for "Simple Video Communication Service"
> 3) Section 3.2. , next to last sentence. "retrieved from" -> "derived
from"
> 4) Section 3.3.5.1, 3rd paragraph,
> - 1st sentence. "session" - "session"
> - 2nd sentence. "straddle the boundary between the internal network
and external." -> "straddles the boundary between the internal and
external networks.
> 5) Section 3.3.5.1, 4th paragraph. "they still want to have the
traffic to stay" -> "they still want the traffic to say"
> 6) Section 3.3.61. 1st paragraph. I'm not sure why this ends with ":"
> 7) Section 3.3.6.1, 2nd paragraph. "device used by one of the users
have several" -> "device used by one of the users has several"
> 8) Section 3.3.11.1, 1st para, 1st sentence. "In this use case is the
Simple..." -> "In this use case, the Simple...."
> 9) Section 3.3.11.1 3rd from last paragraph. "use experience" -> "user
experience"
> 10) Section 3.4.3.1, 2nd paragraph. "participant send" -> "participant
sends"
> 11) Section 4.2:
> - F35. "of that streams" -> "that streams"

Most Nit's fixed

=============================================

On 2014-01-29 10:29, Magnus Westerlund wrote:
> 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:
>
> "Note that TURN support being mandatory does not preclude a WebRTC
> endpoint from supporting additional traversal mechanisms."

I added this to section 3.3.4.1

>
>
> 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:
>> 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
>>
>>
>>
>>
>> On Jan 24, 2014 10:17 AM, "Simon Perreault" <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>>
>>> Le 2014-01-24 12:14, Parthasarathi R a écrit :
>>>
>>>> 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.
>>>
>>>
>>> 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."
>>>
>>>
>>
>> +1 for the above text.
>>
>> CB
>>
>>> 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
>>> _______________________________________________
>>> rtcweb mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>

========================================

On 2014-01-16 15:18, Hutton, Andrew wrote:
> Some comments in the text below.
>
> As a general comment I suggest changing all the "FW" abbreviations to
"Firewall" are have at least a first use definition.

Done

>
>
> Andy
>
>
>> -----Original Message-----
>> From: Magnus Westerlund [mailto:[email-masked]]
>> Sent: 15 January 2014 10:20
>> 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.
>>>
>>> .
>
> [AndyH] - I support this change.

Changed

>
>
>>>
>>>
>>>
>>> 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*.
>
> [AndyH] - I support this change.

Changed

>
>
>>>
>>> -------------------------------------------------------
>>>
>>> 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.
>>>
>
> [AndyH] Yes the heading of 3.3.3 should have been changed during the
last edit to "Simple Video Communication Service, FW that only allows
traffic via a HTTP Proxy". I support this change.

Changed.

>
>
>>>
>>>
>>> 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.
>>>
>>>
>
> [AndyH] I don't believe the intention here was to state a requirement
that WebRTC media should be able to flow through a FW only allowing
HTTP. Therefore I think the original description is ok it is just the
heading that needs to change.
>
>
>>>
>>> 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.
>>>
>
> [AndyH] The existing text is in the 012 draft is ok and I don't think
this change is needed as again I don't believe the intention here was to
state a requirement that WebRTC media should be able to flow through a
FW only allowing HTTP.
>
>
>>> -------------------------------------------------------------------
>>>
>>>
>
>>>
>>>
>>>
>>> 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: "Parthasarathi R" <[email-masked]>
Date: Fri, 7 Feb 2014 22:09:27 +0530

Hi Stefan,

> endpoint from supporting additional traversal mechanisms."

Whereas Sec 3.3.4.1 updated as 

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

Apart from this, Tiru
(http://www.ietf.org/mail-archive/web/rtcweb/current/msg11246.html) and
myself (http://www.ietf.org/mail-archive/web/rtcweb/current/msg11241.html)
mentioned in the different mail thread that Sec 3.3.4.1 is not only the
right place to put the above text. Could you please correct the F31, F32
requirement text in the next revision of the draft.

Thanks
Partha

> From: rtcweb [mailto:[email-masked]] On Behalf Of Stefan
> Håkansson LK
> Sent: Thursday, February 06, 2014 4:23 PM
> To: [email-masked]
> Subject: [rtcweb] New version of use-case draft uploaded
> 
> Hi,
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 7 Feb 2014 18:29:01 +0000

Hi Partha!

>    endpoint from supporting additional traversal mechanisms."

Yes, I did that change (TURN -> ICE). My understanding was that ICE is
what is used/mandated (and it in turn makes use of STUN and TURN).

> requirement text in the next revision of the draft.

I can update them to what you propose. But I think it is a little bit
silly. If we add that note, then we should probably add to F28 "The
browser must support a baseline audio and video codec" a note saying
"this does not preclude the browser from supporting additional codecs"
and so on. After all, the requirements are meant to be what must be
supported; they do not say that additions are not allowed.

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 8 Feb 2014 14:42:48 +0530

Hi Stefan,

<snip>
> what is used/mandated (and it in turn makes use of STUN and TURN).
</snip>

ICE is mandated in RTCWeb but I disagree to your assumption that ICE in turn
makes use of TURN. My concern is that The requirement document is misleading
about TURN requirements. ICE-TCP avoids TURN server as the middle-box in the
network. ICE-TCP is host candidate whereas TURN is relay candidate and as
per ICE candidate selection, host candidate is preferred over relay
candidates. 

In case of WebRTC servers (like conference)/gateway implementation, WebRTC
server is never going to be behind firewall, ICE-TCP serve the purpose and
there is no need of TURN server as a middle-box in the network. So, Could
you please correct the F31, F32 requirement text in the next revision of the
draft.
  
Thanks
Partha

> From: Stefan Håkansson LK [mailto:[email-masked]]
> Sent: Friday, February 07, 2014 11:59 PM
> To: Parthasarathi R; [email-masked]
> Subject: Re: [rtcweb] New version of use-case draft uploaded
> 
> Hi Partha!
> 
> > myself (http://www.ietf.org/mail-
> archive/web/rtcweb/current/msg11241.html)
> >> grok since the requirements are not grouped in categories and one
> has
> >> to
> >> relevant. I think simply stating different OSs and different
> browsers
> >> is
> >> sufficient.
> >>
> >> Changed.
> >>
> >> . Perhaps, that's because there are some missing references in
> section
> >> 3
> >>>> 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
> >>>> IMO, my proposed text without mentioning any firewall/NAT
> mechanism
> >> in
> >>>> 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,
> >>>>
> >>>>> FW without http proxy deplolyed under the permission of FW
> policy"
> >> ,
> >> this change is needed as again I don't believe the intention here
> was
> >> to
> >>>> ------------------------------------------------------------------
> --
> >> --
> >>>> ------------------------------------------------------------------
> --
> >> --
> >>>> ------------------------------------------------------------------
> --
> >> --
> =

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Feb 2014 12:02:03 +0100

Hi Partha,

See inline

> per ICE candidate selection, host candidate is preferred over relay

I will agree that the note as currently worded is not completely
accurate and clear. Based on the text in the preceding section, it makes
sense to note that ICE using STUN and TURN is not the only solution
including additional ICE modes or relay services. I request the authors
propose a new formulation of the note.

> you please correct the F31, F32 requirement text in the next revision of the

This is a request to change two requirements. I have not seen a clear
consensus on this change. Thus, the change is rejected for now.

>From my perspective your proposal for ICE-TCP based solution is a choice
to fulfill F2 and F29, not F31 and F32. Thus, I don't see an issue for
F31 and F32 being STUN and TURN specific.

Is really the current formulations in the requirement documents a hinder
against the WG considering an ICE-TCP based traversal addition? I don't
see it, and if you do, can you please be clearer in your explanation
what the issue is? If not, I think your time is better spent working on
building a clear motivation why ICE-TCP is needed to help establish a WG
consensus on this.

Cheers

Magnus Westerlund
(As co-chair)

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 11 Feb 2014 00:39:10 +0530

Hi Magnus,

Thanks for proposing a new formulation of the note by the authors. I agree
with you that F2 and F29 are generic WebRTC NAT/Firewall requirements which
does not restrict ICE-TCP as one of the solution.

The confusion with F31 and F32 requirements is because of the missing of
WebRTC server/gateway requirements. F31 and F32 leads to the assumption of
mandating TURN servers in the WebRTC server/gateway (by some of the WebRTC
gateway Providers) as there is no text in this usecase & requirement
document to clarify. I have already wrote in the separate mail thread
(http://www.ietf.org/mail-archive/web/rtcweb/current/msg11338.html) to
provide WebRTC server/gateway guidelines document for more clarity.

Thanks
Partha

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

> Sent: Monday, February 10, 2014 4:32 PM
> To: Parthasarathi R; 'Stefan Håkansson LK'; [email-masked]

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 11 Feb 2014 10:15:39 +0000

> propose a new formulation of the note.

Proposal:

"Note that ICE support being mandatory does not preclude a WebRTC 
endpoint from supporting more traversal mechanisms than ICE using STUN 
and TURN."

OK?

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Feb 2014 13:47:23 +0100

On 2014-02-10 20:09, Parthasarathi R wrote:
> document to clarify.

Sorry, I fail to understand which of multiple possible angles you are
arguing here.

A) That the use case document is missing a whole requirement related to
WebRTC Servers. WebRTC server, is something I am uncertain to what you
refer to, a Web server or a media plan related server dealing with peer
connections?

B) That F31 and F32 would lead to an assumption of mandating something,
which currently is the only solution described?

C) That there needs to be text describing some aspect of the global
presence?

 I have already wrote in the separate mail thread
> provide WebRTC server/gateway guidelines document for more clarity.

Good, can you leave with the text and Stefan's text proposal for the note?

Cheers

Magnus Westerlund

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 11 Feb 2014 21:50:06 +0530

Hi Stefan,

<snip> > "Note that ICE support being mandatory does not preclude a WebRTC
</snip>

OK for me.

Thanks
Partha

> Sent: Tuesday, February 11, 2014 3:46 PM
> To: Magnus Westerlund; Parthasarathi R; [email-masked]

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 11 Feb 2014 22:48:16 +0530

Hi Magnus,

Please read inline.

Thanks
Partha

> Sent: Tuesday, February 11, 2014 6:17 PM
<Partha> WebRTC server/gateway is a server which is a combination of Web
Server which handles WebRTC signaling and Media Plane server which deals
with peer-connection. Sec 3.4 of
draft-ietf-rtcweb-use-cases-and-requirements-13 describes 3 usecases for the
same. Unfortunately, draft-ietf-rtcweb-use-cases-and-requirements-13 is
missing NAT/Firewall traversal requirement related to WebRTC server/gateway.
</Partha>

> which currently is the only solution described?
<Partha> 
IMO, WebRTC server/gateway does not require TURN server and ICE-TCP serve
the purpose (Maximum of single WebRTC endpoint behind the firewall scenario
in a two party WebRTC session). As F31 and F32 mandates for TURN and there
is no NAT/Firewall explicit requirement for WebRTC server/gateway, it leads
to the conclusion of TURN server as an only solution by some of WebRTC
gateway providers. Hope this clarifies.
</Partha>

> C) That there needs to be text describing some aspect of the global
<Partha> It is good to have the text which describe NAT/firewall traversal
for WebRTC server/gatway perspective as well. I could not understand why you
are not allowing the changing F31 and F32 or adding the text about WebRTC
server NAT/firewall traversal in sec 3.4. Could you please clarify.
</Partha>

> Good, can you leave with the text and Stefan's text proposal for the
<Partha> I agree for Stefan's proposal in the separate mail thread as it is
related to WebRTC endpoints requirement. </Partha>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Feb 2014 09:16:53 +0100

See inline

> missing NAT/Firewall traversal requirement related to WebRTC server/gateway.

Well, the Media plane functions are logically separate from the Web
Server providing the JS and providing the signalling protocol
functionality. Thus, I think this is unnecessary bunching together
functionality.

When it comes to NAT/FW requirements we have them on the whole solution.
Why aren't these sufficient?

> gateway providers. Hope this clarifies.

If we look at the media functionality side, as the Webserver NAT/FW
traversal is basic requirement to even get the signaling to establish a
peer connection working. Then we have general requirements. We have
requirements that NAT/FW traversal is required. We have F31 and F32
which are requirement that was created after we taken a decision on at
least requiring ICE with STUN and TURN support for WebRTC endpoints.
Thus, F31 and F32 applies assuming that you will use these. I would
prefer a requirements formulation that isn't technology specific. But
you edits doesn't resole that concern.

> server NAT/firewall traversal in sec 3.4. Could you please clarify.

First of all, I do believe we have requirements on the functionality you
discuss. Secondly, your proposal to change does not appear to achieve
any consensus. My personal view, which I just count as one view here is
that your proposal for change does not improve the situation, it only
confuses it more. If you had a proposal which there appear to exist
consensus around then I would request the authors to change the document.

Cheers

Magnus Westerlund