Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12
"Parthasarathi R" <partha@parthasarathi.co.in> Sun, 20 October 2013 16:35 UTC
Return-Path: <partha@parthasarathi.co.in>
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 B4F0E11E82A9 for <rtcweb@ietfa.amsl.com>; Sun, 20 Oct 2013 09:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.923
X-Spam-Level:
X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 Xd5n7wmj-lBe for <rtcweb@ietfa.amsl.com>; Sun, 20 Oct 2013 09:35:45 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.153]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE2711E8200 for <rtcweb@ietf.org>; Sun, 20 Oct 2013 09:35:36 -0700 (PDT)
Received: from userPC (unknown [122.179.103.73]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 2271B86920B; Sun, 20 Oct 2013 16:35:26 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1382286933; bh=BL7HNU2EGLnDYFzOnooBETDaHYQgo0Xt279ednY3paA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=WKPNxq97dLoUSlviVEcx30xb6Ooz6jEAuhQSz/lANwIEZ9/z3syEzPFgLh0Y8VE/C 6RWs0GS56MMLntSOoPTvMTUJa1dIprZomQPQTmmumXmcqyyMWp/VyKU1nvZYoHniT9 BNP8XF+jm2uAhP258rIg3CYcgXcxgQyMifq4a7pU=
From: Parthasarathi R <partha@parthasarathi.co.in>
To: "'Chenxin (Xin)'" <hangzhou.chenxin@huawei.com>, "'Hutton, Andrew'" <andrew.hutton@unify.com>, 'Christer Holmberg' <christer.holmberg@ericsson.com>, rtcweb@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> <00d601cec911$b0fd4b60$12f7e220$@co.in> <9E34D50A21D1D1489134B4D770CE0397680826A3@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFAC8@ESESSMB209.ericsson.se> <9E34D50A21D1D1489134B4D770CE039768082747@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFDA9@ESESSMB209.ericsson.se> <9F33F40F6F2CD847824537F3C4E37DDF17BF5B80@MCHP04MSX.global-ad.net> <9E34D50A21D1D1489134B4D770CE039768082A1A@SZXEMA504-MBX.china.huawei.com>
In-Reply-To: <9E34D50A21D1D1489134B4D770CE039768082A1A@SZXEMA504-MBX.china.huawei.com>
Date: Sun, 20 Oct 2013 22:05:23 +0530
Message-ID: <000d01cecdb2$63c1ef90$2b45ceb0$@co.in>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01CECDE0.7D7A2B90"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOypqiDFNQXq+XsEKEiGC0JWGDqZn4Hd7ggAWs/6A=
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020205.52640654.0113, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.154
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: Sun, 20 Oct 2013 16:36:04 -0000
Hi Xin & all, Apart from modified F29 by Xin, the following requirement has to be discussed: 1) New requirement for blocking incoming TCP connection: a. The browser must be able to send streams and data to a peer in the presence of NATs and FWs that block UDP traffic and incoming TCP connection 2) New requirement to cover both browsers are behind the firewall a. The browser must be able to send streams and data to a peer in the presence of NATs and FWs that block UDP traffic and incoming TCP connection in both browser side as well as in the peer side (TURN only works) Thanks Partha From: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com] Sent: Thursday, October 17, 2013 3:54 PM To: Hutton, Andrew; Christer Holmberg; Parthasarathi R; rtcweb@ietf.org Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 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. . 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*. ------------------------------------------------------- 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. 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. 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. ------------------------------------------------------------------- Best Regards, Xin >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@unify.com] >Sent: Thursday, October 17, 2013 2:08 AM >To: Christer Holmberg; Chenxin (Xin); Parthasarathi R; rtcweb@ietf.org >Subject: RE: [rtcweb] Query/Comment on >draft-ietf-rtcweb-use-cases-and-requirements-12 > >Hi Xin, > >I see the PNTAW mailing list as being there to discuss potential solutions to >these requirements which are documented in the use case draft. > >The requirement F37 is specific to the case when there is a HTTP Proxy and F27 >would include the case when there is no proxy. > >Do you see other use cases and requirements that need to be explicitly brought >out in draft-ietf-rtcweb-use-cases-and-requirements? > >Regards >Andy > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Christer Holmberg >> Sent: 16 October 2013 10:32 >> To: Chenxin (Xin); Parthasarathi R; rtcweb@ietf.org >> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and- >> requirements-12 >> >> Hi Xin, >> >> So, you are saying we shouldn't finalize the use-case-requirements >> document yet? >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com] >> Sent: 16. lokakuuta 2013 12:28 >> To: Christer Holmberg; Parthasarathi R; rtcweb@ietf.org >> Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and- >> requirements-12 >> >> 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 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Draft new version: draft-ietf-rtcweb-use… Christer Holmberg
- Re: [rtcweb] Draft new version: draft-ietf-rtcweb… Rauschenbach, Uwe (NSN - DE/Munich)
- Re: [rtcweb] Draft new version: draft-ietf-rtcweb… Christer Holmberg
- [rtcweb] Query/Comment on draft-ietf-rtcweb-use-c… Parthasarathi R
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Chenxin (Xin)
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Christer Holmberg
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Chenxin (Xin)
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Christer Holmberg
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Hutton, Andrew
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Chenxin (Xin)
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Chenxin (Xin)
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Parthasarathi R
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Magnus Westerlund
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Magnus Westerlund
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Hutton, Andrew
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Parthasarathi R
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Magnus Westerlund
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Hutton, Andrew
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Parthasarathi R
- Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-u… Magnus Westerlund