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

[Magnus Westerlund <[e-mail]>]

See inline



On 2014-02-11 18:18, Parthasarathi R wrote:
>>
>> 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?
>>
> <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>

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?

> 
>> B) That F31 and F32 would lead to an assumption of mandating something,
>> 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>

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.

> 
>> C) That there needs to be text describing some aspect of the global
>> presence?
>>
> <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>

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

----------------------------------------------------------------------
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]
----------------------------------------------------------------------