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

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 10 February 2014 11:02 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED8B1A07FE for <rtcweb@ietfa.amsl.com>; Mon, 10 Feb 2014 03:02:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_gNRg52v25w for <rtcweb@ietfa.amsl.com>; Mon, 10 Feb 2014 03:02:05 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 47F161A07F9 for <rtcweb@ietf.org>; Mon, 10 Feb 2014 03:02:05 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-ce-52f8b1ac88cd
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 73.43.04249.CA1B8F25; Mon, 10 Feb 2014 12:02:04 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Feb 2014 12:02:04 +0100
Message-ID: <52F8B1AB.70305@ericsson.com>
Date: Mon, 10 Feb 2014 12:02:03 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Parthasarathi R <partha@parthasarathi.co.in>, 'Stefa n Håkansson LK' <stefan.lk.hakansson@ericsson.com>, rtcweb@ietf.org
References: <1447FA0C20ED5147A1AA0EF02890A64B1CF4A182@ESESSMB209.ericsson.se> <007601cf2423$2d571210$88053630$@co.in> <1447FA0C20ED5147A1AA0EF02890A64B1CF533B8@ESESSMB209.ericsson.se> <004601cf24ad$f3a1c0c0$dae54240$@co.in>
In-Reply-To: <004601cf24ad$f3a1c0c0$dae54240$@co.in>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3RnfNxh9BBr1P9S0mf+pjtVj7r53d gcljyZKfTB4f5n9hD2CK4rJJSc3JLEst0rdL4MpYtngaU8F34Yqtn64zNzD+4O9i5OSQEDCR WLnlNwuELSZx4d56ti5GLg4hgSOMEt0XJkM5yxklTj3/xAxSxSugKfGm/RUTiM0ioCqx6s0z dhCbTcBC4uaPRjYQW1QgWOLWtAfsEPWCEidnPmEBGSQisIpR4vL+7WBFwgI2Ev8unGKH2HCf UeJHyxRWkAQn0E3PTl0AsjmAbhKX6GkMAgkzC+hJTLnawghhy0s0b50NdpCQgLZEQ1MH6wRG wVlI9s1C0jILScsCRuZVjBzFqcVJuelGBpsYgYF5cMtvix2Ml//aHGKU5mBREuf9+NY5SEgg PbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjpp5SsSgT/UXPZEISq4oe+7Xc35KbdHLGfdYkqzvM nJPWJ9aFBQYf+HV7Nuf39d6OT/YLv1sVGRi4+A1jQbJL/ZVLnx8bv2/xqXdWK4l1SZeY/uZe 0tQ/3J7lPPbSq0w+WVxmzf8XG8SY8Uj9d/8KN/fl1YYXrYLtHjRqWM9ZxGv7TD+34b8SS3FG oqEWc1FxIgBa5Sx0GgIAAA==
Subject: Re: [rtcweb] New version of use-case draft uploaded
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2014 11:02:07 -0000

Hi Partha,

See inline

On 2014-02-08 10:12, Parthasarathi R wrote:
> Hi Stefan,
> 
> <snip>
>> 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).
>>
> </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. 

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.

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

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)

----------------------------------------------------------------------
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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------