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

"Chenxin (Xin)" <hangzhou.chenxin@huawei.com> Wed, 16 October 2013 09:28 UTC

Return-Path: <hangzhou.chenxin@huawei.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFCB21F9D04 for <rtcweb@ietfa.amsl.com>; Wed, 16 Oct 2013 02:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQU600Ze4ouy for <rtcweb@ietfa.amsl.com>; Wed, 16 Oct 2013 02:28:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8211E8169 for <rtcweb@ietf.org>; Wed, 16 Oct 2013 02:28:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZD14843; Wed, 16 Oct 2013 09:28:22 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 16 Oct 2013 10:27:29 +0100
Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 16 Oct 2013 10:28:21 +0100
Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0146.000; Wed, 16 Oct 2013 17:28:13 +0800
From: "Chenxin (Xin)" <hangzhou.chenxin@huawei.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Parthasarathi R <partha@parthasarathi.co.in>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12
Thread-Index: AQHOyRG+14fmt6ButUmt5DEypMFDB5n2lTUA///engCAAJWaIA==
Date: Wed, 16 Oct 2013 09:28:13 +0000
Message-ID: <9E34D50A21D1D1489134B4D770CE039768082747@SZXEMA504-MBX.china.huawei.com>
References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> <00d601cec911$b0fd4b60$12f7e220$@co.in> <9E34D50A21D1D1489134B4D770CE0397680826A3@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFAC8@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BFAC8@ESESSMB209.ericsson.se>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.166.41.125]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 16 Oct 2013 09:28:28 -0000

Hi Christer,

>Hi,
>
>>  +1. I think we should wait for the result of PNTAW@ietf.org discussion
>before modifying the related use case and requirement. there seems no clear
>consensus by now.
>>
>>  The related use case is 3.3.2 , F29 , 3.3.3 and F37.
>
>Consensus on what?

Should we just consider the case that " one of the users is behind a FW that only allows traffic via a HTTP Proxy "? what will happen if there is no http proxy deployed? 

There are two options to solve this usecase discussed in PNTAW mailing list. "5)UDP relay candidates via some HTTP/TLS compatible transport (TURN) - MUST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets have been proposed."  List in http://www.ietf.org/mail-archive/web/pntaw/current/msg00162.html
Also there is other discussions in http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. 

That all mention that we should consider more than the http proxy scenarios. 

I believe that the PNTAW mailing list is used for discussion of these similar transport problems, including the related use case and requirement. In the end , some consensus should be make to decide what problem we need handle and how to solve it , which will influence the use case and requirement to make it more clear.  Is my thought right? Or miss something...

Best Regards,
     Xin
>
>Note that the draft is only talking about requirements.
>
>Regards,
>
>Christer
>
>
>>-----Original Message-----
>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>>Behalf Of Parthasarathi R
>>Sent: Tuesday, October 15, 2013 3:15 AM
>>To: 'Christer Holmberg'; rtcweb@ietf.org
>>Subject: [rtcweb] Query/Comment on
>>draft-ietf-rtcweb-use-cases-and-requirements-12
>>
>>Hi Christer & all,
>>
>>In PNTAW mailing list, there is a discussion on firewall blocking
>>incoming TCP traffic when the firewall blocks UDP or allows only HTTP
>>traffic. The related link is
>>http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html.
>>
>>Could you please clarify whether F29 & F37 requirement implicitly
>>indicates that incoming TCP/HTTP traffic is blocked for browser when
>>these requirements are met. If so, Please update the below requirement
>>text with those details.
>>
>>Thanks
>>Partha
>>
>>Note:
>>
>>----------------------------------------------------------------
>>   F29     The browser must be able to send streams and
>>           data to a peer in the presence of NATs that
>>           block UDP traffic.
>>
>>----------------------------------------------------------------
>>  F37     The browser must be able to send streams and
>>           data to a peer in the presence of FWs that only
>>           allows traffic via a HTTP Proxy, when FW policy
>>           allows WebRTC traffic.
>>
>>_______________________________________________
>>rtcweb mailing list
>>rtcweb@ietf.org
>>https://www.ietf.org/mailman/listinfo/rtcweb