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

Magnus Westerlund <> Wed, 12 February 2014 08:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 02B3A1A08B3 for <>; Wed, 12 Feb 2014 00:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.551
X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZqwwzqI-oXvy for <>; Wed, 12 Feb 2014 00:16:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ECE041A0886 for <>; Wed, 12 Feb 2014 00:16:55 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-eb-52fb2df6a011
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C2.22.10875.6FD2BF25; Wed, 12 Feb 2014 09:16:54 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Wed, 12 Feb 2014 09:16:53 +0100
Message-ID: <>
Date: Wed, 12 Feb 2014 09:16:53 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Parthasarathi R <>, 'Stefa n Håkansson LK' <>,
References: <> <007601cf2423$2d571210$88053630$> <> <004601cf24ad$f3a1c0c0$dae54240$> <> <013901cf2693$97c1eb30$c745c190$> <> <016901cf274d$44332000$cc996000$>
In-Reply-To: <016901cf274d$44332000$cc996000$>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3Rveb7u8gg0sH5Cwmf+pjtVj7r53d gcljyZKfTB4f5n9hD2CK4rJJSc3JLEst0rdL4Mo49GgBY8F/mYo5t7ezNTBeFe9i5OSQEDCR OHx7PguELSZx4d56ti5GLg4hgUOMEj8XHYJyljNK/JrXA+RwcPAKaEv82moO0sAioCrx5/pa NhCbTcBC4uaPRjBbVCBYYueB34wgNq+AoMTJmU9YQOaICKxilLi8fztYkbCAjcS/C6fYIRa8 ZZLY8qSVFSTBCXTSo+fTmUGWSQiIS/Q0BoGEmQX0JKZcbWGEsOUlmrfOZgaxhYDuaWjqYJ3A KDgLyb5ZSFpmIWlZwMi8ipE9NzEzJ73ccBMjMCgPbvmtu4Px1DmRQ4zSHCxK4rwf3joHCQmk J5akZqemFqQWxReV5qQWH2Jk4uCUamCc8eSc/eOouLO1MutuLRSrWbCgcgPvXKt/XNOqvp+V 2599VbN9OWvov2CPH6/8rRXzQ/xflTM5PWb8c8h5Vtn8+Mtet567uk+6t/K5hV2b6tepN5av +GxXlH7D6oqVzM2zHiHPmXZs5Jyw223rPofpRTH1Ex+8UOp+ldfM9m3y+33BmgUZBnvWKLEU ZyQaajEXFScCAHzBfQ4YAgAA
Subject: Re: [rtcweb] New version of use-case draft uploaded
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Feb 2014 08:16:59 -0000

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

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.


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: