From magnus.westerlund@ericsson.com Tue Aug 2 05:16:47 2011 Return-Path: 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 82BD321F8E81 for ; Tue, 2 Aug 2011 05:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwY5sJZiGOzf for ; Tue, 2 Aug 2011 05:16:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 713F321F8E80 for ; Tue, 2 Aug 2011 05:16:46 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-11-4e37eaab89f9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6D.52.20773.BAAE73E4; Tue, 2 Aug 2011 14:16:43 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 2 Aug 2011 14:16:43 +0200 Message-ID: <4E37EAAB.3020708@ericsson.com> Date: Tue, 2 Aug 2011 14:16:43 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] New Milestones for RTCWEB WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 02 Aug 2011 12:16:47 -0000 WG, As raised in the WG meeting last week we plan to submit new milestones. These is to make the time line a bit more realistic to actually be meet. They also try to adjust to the picked document structure. Here they are: Oct 2011 Send Use Cases (draft-ietf-rtcweb-use-cases-and-requirements), Overview (draft-ietf-rtcweb-overview), Security and Privacy Documents (I-D) to W3C Dec 2011 Send Use Cases (draft-ietf-rtcweb-use-cases-and-requirements) document to IESG for publication as Informational Apr 2012 Send W3C input on what requirements the current solution has on API(s) May 2012 Send Overview (draft-ietf-rtcweb-overview), Security and Privacy Model documents to IESG for publication as Informational May 2012 Send Signalling and Negotiation, and NAT Traversal to IESG for publication as Proposed Standard Jun 2012 Send Media Transport, Media Processing, and Codecs to IESG for publication as Proposed Standard Jun 2012 Send Datagram Transport for non-media data to IESG for publication as Proposed Standard These will soon be submitted for official publication. If you have any issues please raise them on the list and we can discuss them. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From a.bakker@vu.nl Wed Aug 3 01:36:11 2011 Return-Path: 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 4DDF721F8B20 for ; Wed, 3 Aug 2011 01:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.002 X-Spam-Level: X-Spam-Status: No, score=-4.002 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 366+n+kp9I2g for ; Wed, 3 Aug 2011 01:36:10 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id 91A8E21F8880 for ; Wed, 3 Aug 2011 01:36:10 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 3 Aug 2011 10:36:33 +0200 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 3 Aug 2011 10:36:20 +0200 Message-ID: <4E390884.5050909@cs.vu.nl> Date: Wed, 3 Aug 2011 10:36:20 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: [rtcweb] New use case: Large multiparty session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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, 03 Aug 2011 08:36:11 -0000 Hi as proposed in the July 26th meeting I'd like to put forward a new use case: assume a client is involved in a large multiparty session but is unable (or unwilling) to upload his signals to all participants. This suggests forwarding support from the network is required, e.g. some relay server, multicast, or the future IETF peer-to-peer streaming protocol (PPSP). Thanks, Arno Bakker From partr@cisco.com Wed Aug 3 05:12:36 2011 Return-Path: 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 EE35F21F85AE for ; Wed, 3 Aug 2011 05:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.156 X-Spam-Level: X-Spam-Status: No, score=-10.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+OILKVPuEtX for ; Wed, 3 Aug 2011 05:12:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B0AE321F8AF0 for ; Wed, 3 Aug 2011 05:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=2452; q=dns/txt; s=iport; t=1312373567; x=1313583167; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=F99w8/12OimFDYW8Ro4GPQkGttZyERvJWLMehHdDj8k=; b=S1gOgMGemL6OKBZNFvgRP7cyAqZEbnHgupqW41azdt/t0Nrzwm9Rc3ut owAdSYZdxMJpjXxwN0/7xrOz8ziu0dS3ERWozremfP4Jbylhv3CHFa9ib Biqk8c7Gv0kmOJueOzetlkc8wJV1roIjsfHEqsvw9nGZ8B75m56mgp765 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAI06OU5Io8US/2dsb2JhbABCmAaPWHeBQAEBAQEDAQEBCQYBHT4XAgICAQgRAQMBAQsGFwEGARoMHwMGCAEBBAEKCAgTB4dOoToBnmYChWFfBIcrLZAzi1w X-IronPort-AV: E=Sophos;i="4.67,310,1309737600"; d="scan'208";a="106481518" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2011 12:12:45 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p73CCjV4008374; Wed, 3 Aug 2011 12:12:45 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 17:42:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2011 17:42:44 +0530 Message-ID: In-Reply-To: <4E37EAAB.3020708@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] New Milestones for RTCWEB WG Thread-Index: AcxRDhbCeJUZg+AwRQuKpfJi1S6TwgAx7pog References: <4E37EAAB.3020708@ericsson.com> From: "Parthasarathi R (partr)" To: "Magnus Westerlund" , X-OriginalArrivalTime: 03 Aug 2011 12:12:45.0536 (UTC) FILETIME=[A71BA600:01CC51D6] Subject: Re: [rtcweb] New Milestones for RTCWEB WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 12:12:37 -0000 Hi Magnus,=20 The current RTCWeb overview, usecase & requirement document does not = have architecture diagrams. Please clarify which one of the RTCWeb WG = item below will cover RTCWeb architecture. Thanks Partha=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund > Sent: Tuesday, August 02, 2011 5:47 PM > To: rtcweb@ietf.org > Subject: [rtcweb] New Milestones for RTCWEB WG >=20 > WG, >=20 > As raised in the WG meeting last week we plan to submit new=20 > milestones. > These is to make the time line a bit more realistic to=20 > actually be meet. > They also try to adjust to the picked document structure. >=20 > Here they are: > Oct 2011 Send Use Cases=20 > (draft-ietf-rtcweb-use-cases-and-requirements), > Overview (draft-ietf-rtcweb-overview), Security and Privacy Documents > (I-D) to W3C >=20 > Dec 2011 Send Use Cases (draft-ietf-rtcweb-use-cases-and-requirements) > document to IESG for publication as Informational >=20 > Apr 2012 Send W3C input on what requirements the current=20 > solution has on > API(s) >=20 > May 2012 Send Overview (draft-ietf-rtcweb-overview), Security=20 > and Privacy Model documents to IESG for publication as Informational >=20 > May 2012 Send Signalling and Negotiation, and NAT Traversal=20 > to IESG for publication as Proposed Standard >=20 > Jun 2012 Send Media Transport, Media Processing, and Codecs=20 > to IESG for publication as Proposed Standard >=20 > Jun 2012 Send Datagram Transport for non-media data to IESG=20 > for publication as Proposed Standard >=20 > These will soon be submitted for official publication. If you=20 > have any issues please raise them on the list and we can discuss them. >=20 > cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From randell-ietf@jesup.org Wed Aug 3 05:52:20 2011 Return-Path: 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 B14E521F8B2D for ; Wed, 3 Aug 2011 05:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt9O9nJ4MXAo for ; Wed, 3 Aug 2011 05:52:20 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4779721F8B2A for ; Wed, 3 Aug 2011 05:52:20 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qoaw3-0002gR-Ca for rtcweb@ietf.org; Wed, 03 Aug 2011 07:52:31 -0500 Message-ID: <4E394434.3040802@jesup.org> Date: Wed, 03 Aug 2011 08:51:00 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E390884.5050909@cs.vu.nl> In-Reply-To: <4E390884.5050909@cs.vu.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] New use case: Large multiparty session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 12:52:20 -0000 On 8/3/2011 4:36 AM, Arno Bakker wrote: > Hi > > as proposed in the July 26th meeting I'd like to put forward a new use > case: assume a client is involved in a large multiparty session but is > unable (or unwilling) to upload his signals to all participants. > > This suggests forwarding support from the network is required, e.g. > some relay server, multicast, or the future IETF peer-to-peer streaming > protocol (PPSP). So the use case is: User is part of a multiparty (3 or greater) session, but for one of several reasons (such as available upstream bandwidth) cannot send media to all other participants ("mesh" conferencing). This requires that another node, either a central network node (such as a conferencing server) or another member in the session, relay or mix the user's media to distribute to the rest of the members of the session. -- Randell Jesup randell-ietf@jesup.org From a.bakker@vu.nl Wed Aug 3 06:37:25 2011 Return-Path: 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 05E5D21F8B2E for ; Wed, 3 Aug 2011 06:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BGF3VBUECE1 for ; Wed, 3 Aug 2011 06:37:24 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3F14B21F854D for ; Wed, 3 Aug 2011 06:37:23 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 3 Aug 2011 15:34:59 +0200 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 3 Aug 2011 15:34:46 +0200 Message-ID: <4E394E76.2030302@cs.vu.nl> Date: Wed, 3 Aug 2011 15:34:46 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: References: <4E390884.5050909@cs.vu.nl> <4E394434.3040802@jesup.org> In-Reply-To: <4E394434.3040802@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [rtcweb] New use case: Large multiparty session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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, 03 Aug 2011 13:37:25 -0000 On 03/08/2011 14:51, Randell Jesup wrote: > On 8/3/2011 4:36 AM, Arno Bakker wrote: >> >> assume a client is involved in a large multiparty session but is >> unable (or unwilling) to upload his signals to all participants. >> >> This suggests forwarding support from the network is required, e.g. >> some relay server, multicast, or the future IETF peer-to-peer streaming >> protocol (PPSP). > > So the use case is: > > User is part of a multiparty (3 or greater) session, but for one of > several reasons (such as > available upstream bandwidth) cannot send media to all other > participants ("mesh" conferencing). > This requires that another node, either a central network node (such as > a conferencing server) > or another member in the session, relay or mix the user's media to > distribute to the rest of the > members of the session. > Yes. Although your wording suggests a single relay node (central or member) is used. Please leave the option of true peer-to-peer distribution (or IP multicast) of the signal open. CU, Arno From randell-ietf@jesup.org Wed Aug 3 07:12:27 2011 Return-Path: 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 460A121F861E for ; Wed, 3 Aug 2011 07:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vbfbcUNz1g8 for ; Wed, 3 Aug 2011 07:12:26 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id B7FCC21F8658 for ; Wed, 3 Aug 2011 07:12:25 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QocBZ-0002Oa-60 for rtcweb@ietf.org; Wed, 03 Aug 2011 09:12:37 -0500 Message-ID: <4E3956F9.1000309@jesup.org> Date: Wed, 03 Aug 2011 10:11:05 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2C6FA49B-5D95-4C45-AD67-EA5D042F972C@cisco.com> In-Reply-To: <2C6FA49B-5D95-4C45-AD67-EA5D042F972C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Rohan Red Cross Use Case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 14:12:27 -0000 On 7/18/2011 2:30 PM, Cullen Jennings wrote: > I'd like to add an use case along the following lines... > > Rohan works for international aid agency and deploys wireless networks = in places where disasters have wiped out all the existing infrastructure.= There's just been an earthquake in Haiti. Betty works for Canada Red Cro= ss and need to get the Red Cross location in Haiti connected to other aid= groups in Haiti to help arrange complex logistics of things like what or= der various aid agencies are even going to use the limited resources of t= he runway at the airport. Rohan and Betty both use the AidNet web applica= tion for communicating and have cached copies using the HTML5 offline sup= port on their computers or, if they can't get their computers into the co= untry, can at least get copy in via USB key and find a local computer wit= h a browser. Rohan sets up a wireless access point on the tallest thing h= e can find and managed to provide wireless coverage for many square miles= =2E Betty connects to that and manages to call Rohan to coordinate and le= t Rohan know the location of RedCross so that better wireless can be arra= nged there. > > This one more or less one of the use cases for P2PSIP work to be able t= o set up an ad hoc voice communications system before one even had access= to DNS server or any global internet infrastructure. I think that the wh= ole P2PSIP system could be done inside browser (or a system similar to it= ). The underling transport of P2PSIP is very close to the proposal here i= ncluding the use of ICE. One would probably need to define a new transpor= t that an Reload overlay could use but other than that, I think one could= meet this use case using something along the lines of Reload running in = browser. This is an interesting use-case - how would this really work in terms of = discovery (does it require some external application to handle=20 discovery?), what support would it likely need in the browser, and what=20 are the security implications? --=20 Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Wed Aug 3 07:23:35 2011 Return-Path: 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 8346721F8AF1 for ; Wed, 3 Aug 2011 07:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itWjh1hrJE3v for ; Wed, 3 Aug 2011 07:23:35 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id E1FE721F8AE9 for ; Wed, 3 Aug 2011 07:23:34 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QocMM-0003yt-Tq for rtcweb@ietf.org; Wed, 03 Aug 2011 09:23:46 -0500 Message-ID: <4E395997.80803@jesup.org> Date: Wed, 03 Aug 2011 10:22:15 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20110704113719.18992.44580.idtracker@ietfa.amsl.com> In-Reply-To: <20110704113719.18992.44580.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 14:23:35 -0000 > A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirements-01.txt >4.2.6. Multiparty video communication > >4.2.6.1. Description > > In this use case the simple video communication service is extended > by allowing multiparty sessions. No central server is involved - the > browser of each participant sends and receives streams to and from > all other session participants. The web application in the browser > of each user is responsible for setting up streams to all receivers. > > The audio sent by each participant is a mono stream. However, in > order to enhance intelligibility, the web application pans the audio > from different participants differently when rendering the audio. > This is done automatically, but users can change how the different > participants are placed in the (virtual) room. Note that this covers the request from Arno for peer-to-peer distribution. Also, I would remove the audio is mono reference. I see no need to add that restriction. -- Randell Jesup randell-ietf@jesup.org From matthew.kaufman@skype.net Wed Aug 3 07:57:07 2011 Return-Path: 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 D114921F8AF8 for ; Wed, 3 Aug 2011 07:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L2eCafGRWDe for ; Wed, 3 Aug 2011 07:57:07 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1CE21F8A66 for ; Wed, 3 Aug 2011 07:57:06 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 2DCC716E2; Wed, 3 Aug 2011 16:57:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=2OkKaHozdNb0hb JQwZl++hHNY0Q=; b=JuNvbmtbOGJEq3/e9dS+Qpraf1xKCBD3tILtUmoKDBVLLS 7T1RDTCGWyYtpPNqEwIT85fLKBA5rRtndGwuOCVkncImvuaP5KUjffGHneQnKsBw b5QLKDv6NMeYFJZOEA0yMev+OOS2ba9Asz0sSA8MdWAhhsJdtNHzlIdVlrnbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=UPH+00dCLd+n7J7QjPe7WS /VWGs0y2AInjP2yi9r1XHv/ebKNhGkGjHH3scc2Pw1JIl3YmzhMkU4RYOgAxSjBv xHucNvTpDCm/qOqvAwq0VxrCSEV+vUGfFjPMo1DlS+p9ztmKuZOvG0V3QLcWYTgI B2Xe1rFX1sEDJg+UHolTU= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 2C5847F6; Wed, 3 Aug 2011 16:57:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 0964C3507FE5; Wed, 3 Aug 2011 16:57:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDog66ST78fK; Wed, 3 Aug 2011 16:57:15 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id A80C73507FDF; Wed, 3 Aug 2011 16:57:14 +0200 (CEST) Message-ID: <4E3961C9.7030609@skype.net> Date: Wed, 03 Aug 2011 07:57:13 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Cullen Jennings References: <2C6FA49B-5D95-4C45-AD67-EA5D042F972C@cisco.com> In-Reply-To: <2C6FA49B-5D95-4C45-AD67-EA5D042F972C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Rohan Red Cross Use Case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 14:57:07 -0000 On 7/18/2011 11:30 AM, Cullen Jennings wrote: > I'd like to add an use case along the following lines... > > Rohan works for international aid agency and deploys wireless networks = in places where disasters have wiped out all the existing infrastructure.= There's just been an earthquake in Haiti. Betty works for Canada Red Cro= ss and need to get the Red Cross location in Haiti connected to other aid= groups in Haiti to help arrange complex logistics of things like what or= der various aid agencies are even going to use the limited resources of t= he runway at the airport. Rohan and Betty both use the AidNet web applica= tion for communicating and have cached copies using the HTML5 offline sup= port on their computers or, if they can't get their computers into the co= untry, can at least get copy in via USB key and find a local computer wit= h a browser. Rohan sets up a wireless access point on the tallest thing h= e can find and managed to provide wireless coverage for many square miles= =2E Betty connects to that and manages to call Rohan to coordinate and le= t Rohan know the location of RedCross so that > better wireless can be arranged there. > > This one more or less one of the use cases for P2PSIP work to be able t= o set up an ad hoc voice communications system before one even had access= to DNS server... If Rohan can't figure out how to include a DNS resolver that is=20 advertised via DHCP with some locally-resolvable names (and, if needed,=20 a web landing page that has some basic info about what to configure and=20 where to get help) then Rohan shouldn't be in charge of setting up the=20 wireless access point. This is of course the same argument we had years ago on the original=20 p2psip list. Matthew Kaufman From igor.faynberg@alcatel-lucent.com Wed Aug 3 10:29:23 2011 Return-Path: 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 9A86821F84F4 for ; Wed, 3 Aug 2011 10:29:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yK-Yv5Qeedqi for ; Wed, 3 Aug 2011 10:29:23 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1126721F84F2 for ; Wed, 3 Aug 2011 10:29:22 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p73HTZah019480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 3 Aug 2011 12:29:35 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p73HTYbL010287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 3 Aug 2011 12:29:35 -0500 Received: from [135.222.134.166] (USMUYN0L055118.mh.lucent.com [135.222.134.166]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p73HTY3L007885; Wed, 3 Aug 2011 12:29:34 -0500 (CDT) Message-ID: <4E39857E.3040407@alcatel-lucent.com> Date: Wed, 03 Aug 2011 13:29:34 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E390884.5050909@cs.vu.nl> <4E394434.3040802@jesup.org> In-Reply-To: <4E394434.3040802@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] New use case: Large multiparty session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com 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, 03 Aug 2011 17:29:23 -0000 I strongly support the use case, but I was under the impression that there has been a use case thar required a similar architecture: a "central" server (of course, it can be replicated) for accumulating input and distributing output. For one thing, the music collaboration use case, I believe, calls for this architecture. Perhaps one thing to watch for in the use case write-ups is separation between a use case and architecture. These are two different things because one architecture can fit many (and maybe all) use cases. Igor On 8/3/2011 8:51 AM, Randell Jesup wrote: > On 8/3/2011 4:36 AM, Arno Bakker wrote: >> Hi >> >> as proposed in the July 26th meeting I'd like to put forward a new use >> case: assume a client is involved in a large multiparty session but is >> unable (or unwilling) to upload his signals to all participants. >> >> This suggests forwarding support from the network is required, e.g. >> some relay server, multicast, or the future IETF peer-to-peer streaming >> protocol (PPSP). > > So the use case is: > > User is part of a multiparty (3 or greater) session, but for one of > several reasons (such as > available upstream bandwidth) cannot send media to all other > participants ("mesh" conferencing). > This requires that another node, either a central network node (such > as a conferencing server) > or another member in the session, relay or mix the user's media to > distribute to the rest of the > members of the session. > From ted.ietf@gmail.com Wed Aug 3 13:22:39 2011 Return-Path: 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 D47E921F855B for ; Wed, 3 Aug 2011 13:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ru8DI4zasusx for ; Wed, 3 Aug 2011 13:22:39 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D48A921F8538 for ; Wed, 3 Aug 2011 13:22:38 -0700 (PDT) Received: by gyd5 with SMTP id 5so789032gyd.31 for ; Wed, 03 Aug 2011 13:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=WCpnVTMKZWGDW3GaK27MeIiKMWQ3khR9DiWRadaHGkA=; b=Lx65JEYrPkRUYXTIQwwuji1MSyu5XyucG9WxkMXK9JKdWpUialFvo68UpdOdMfjtGi W9AlcNDwLhW122UhaEeA6ej85hq6roABCwIEpT6lLvDI2H/cQxeZXXEZcppCDZFQSvg5 esbCwSZ95NpMDAGuT4m+PuppOUDB7fvYbdpaY= MIME-Version: 1.0 Received: by 10.236.180.68 with SMTP id i44mr3947797yhm.191.1312402970595; Wed, 03 Aug 2011 13:22:50 -0700 (PDT) Received: by 10.236.109.39 with HTTP; Wed, 3 Aug 2011 13:22:48 -0700 (PDT) Date: Wed, 3 Aug 2011 13:22:48 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Poll on dates for Virtual Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 20:22:39 -0000 There is a poll at http://doodle.com/w9q95yfdunddn9r7 . Please fill it out with the dates you are available and times you prefer. The chairs realize that folks are on vacation, but in order to nail this down somewhat, we plan on closing the poll August 10th. We assume we'll get a representative sample by then, even if we don't catch all the potential attendees. We're still working on the agenda, but we assume that we'll talk about security, rtp muxing, and the non-real time data flows. regards, Ted, Cullen, Magnus From partr@cisco.com Wed Aug 3 16:59:46 2011 Return-Path: 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 1808C11E80AD for ; Wed, 3 Aug 2011 16:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.165 X-Spam-Level: X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUeXEisqGHYY for ; Wed, 3 Aug 2011 16:59:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2369521F86CA for ; Wed, 3 Aug 2011 16:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=2653; q=dns/txt; s=iport; t=1312415998; x=1313625598; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=9w5l2apjfVNYCByPTqnJOaun203FVA+DSvXwIOEt4t4=; b=BeH7vzM8fg4p1ATHRKKac0VLDy5oBMdsGzuSVCJmi2omxpb1EM8PEB7T 0i4gWAIIdB9G3vsWEOacWov2ka1QUtqPA/llQZk1hllTqtrwUvUQOwxg6 P2rXPaEhhfcbjEolph8o75KVTs8HxumsiXKZ7f4U+wzuPyq4GYtUDaqgo c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAMHfOU5Io8UQ/2dsb2JhbABCmAePWneBQAEBAQEDAQEBDwEdCjQXBAIBGQEDAQEBCgYXAQYBJh8DBggBAQQBCggIGodOohcBnm2FY18Eh1iQM4tc X-IronPort-AV: E=Sophos;i="4.67,313,1309737600"; d="scan'208";a="106639976" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2011 23:59:56 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p73NxuSv006300; Wed, 3 Aug 2011 23:59:56 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 05:29:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2011 05:29:53 +0530 Message-ID: In-Reply-To: <4E39857E.3040407@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTCWeb architecture text requirement [Was RE: [rtcweb] New use case: Large multiparty session] Thread-Index: AcxSAu74TGtrbXRsRrGplxMMMgjXuwANQN7g References: <4E390884.5050909@cs.vu.nl> <4E394434.3040802@jesup.org> <4E39857E.3040407@alcatel-lucent.com> From: "Parthasarathi R (partr)" To: , X-OriginalArrivalTime: 03 Aug 2011 23:59:56.0291 (UTC) FILETIME=[71CF0D30:01CC5239] Subject: [rtcweb] RTCWeb architecture text requirement [Was RE: New use case: Large multiparty session] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 23:59:46 -0000 Hi all, >=20 > Perhaps one thing to watch for in the use case write-ups is=20 > separation between a use case and architecture. These are two=20 > different things because one architecture can fit many (and=20 > maybe all) use cases. >=20 As mentioned by Igor, I'm also looking for the architecture document which provide the insight into RTCWeb deployment possibilities. draft-rosenberg-rtcweb-framework-00 is one of the RTCWeb document which is in the similar line. I'm interested in hearing others opinion on this.=20 Thanks Partha=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Igor Faynberg > Sent: Wednesday, August 03, 2011 11:00 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] New use case: Large multiparty session >=20 > I strongly support the use case, but I was under the=20 > impression that there has been a use case thar required a=20 > similar architecture: a "central" server (of course, it can=20 > be replicated) for accumulating input and distributing output. >=20 > For one thing, the music collaboration use case, I believe,=20 > calls for this architecture. >=20 > Perhaps one thing to watch for in the use case write-ups is=20 > separation between a use case and architecture. These are two=20 > different things because one architecture can fit many (and=20 > maybe all) use cases. >=20 > Igor >=20 > On 8/3/2011 8:51 AM, Randell Jesup wrote: > > On 8/3/2011 4:36 AM, Arno Bakker wrote: > >> Hi > >> > >> as proposed in the July 26th meeting I'd like to put forward a new=20 > >> use > >> case: assume a client is involved in a large multiparty=20 > session but=20 > >> is unable (or unwilling) to upload his signals to all participants. > >> > >> This suggests forwarding support from the network is required, e.g. > >> some relay server, multicast, or the future IETF peer-to-peer=20 > >> streaming protocol (PPSP). > > > > So the use case is: > > > > User is part of a multiparty (3 or greater) session, but for one of=20 > > several reasons (such as available upstream bandwidth) cannot send=20 > > media to all other participants ("mesh" conferencing). > > This requires that another node, either a central network=20 > node (such=20 > > as a conferencing server) or another member in the session,=20 > relay or=20 > > mix the user's media to distribute to the rest of the=20 > members of the=20 > > session. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From a.bakker@vu.nl Thu Aug 4 00:32:09 2011 Return-Path: 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 2DA2F21F8B68 for ; Thu, 4 Aug 2011 00:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.234 X-Spam-Level: X-Spam-Status: No, score=-4.234 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZI63KTVS4I5 for ; Thu, 4 Aug 2011 00:32:08 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id 70B6A21F8B66 for ; Thu, 4 Aug 2011 00:32:08 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 4 Aug 2011 09:32:35 +0200 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 4 Aug 2011 09:32:21 +0200 Message-ID: <4E3A4B06.5090007@cs.vu.nl> Date: Thu, 4 Aug 2011 09:32:22 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: References: <20110704113719.18992.44580.idtracker@ietfa.amsl.com> <4E395997.80803@jesup.org> In-Reply-To: <4E395997.80803@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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: Thu, 04 Aug 2011 07:32:09 -0000 On 03/08/2011 16:22, Randell Jesup wrote: >> A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirements-01.txt > > >> 4.2.6. Multiparty video communication >> > > Note that this covers the request from Arno for peer-to-peer distribution. > Yes. But perhaps we should rephrase requirement F11 to "The browser MUST be able to transmit streams to at least one peer" (peer could be other browser or relay server) to more properly highlight the problem of insufficient upload in larger sessions. CU, Arno From stefan.lk.hakansson@ericsson.com Thu Aug 4 00:57:21 2011 Return-Path: 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 6073321F8B6E for ; Thu, 4 Aug 2011 00:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4THnueqQ586S for ; Thu, 4 Aug 2011 00:57:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6522F21F8B7A for ; Thu, 4 Aug 2011 00:57:20 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-28-4e3a50eda047 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FD.3D.20773.DE05A3E4; Thu, 4 Aug 2011 09:57:33 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.110]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 4 Aug 2011 09:57:33 +0200 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: "public-webrtc@w3.org" , "rtcweb@ietf.org" Date: Thu, 4 Aug 2011 09:57:32 +0200 Thread-Topic: Use cases: summary of status Thread-Index: AQHMUnwqEjlFeNrbIU+Jw5nErkrerQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Use cases: summary of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 04 Aug 2011 07:57:21 -0000 All, =20 sorry for cross-posting. =20 As one of the editors for the use case doc, I would like to summarize the u= se case discussion a bit. A and B below is my understanding of the status r= egarding use cases after attending the webrtc meeting Sat July 23rd and the= first rtcweb session of IETF 81, and after trying to digest the mail lists= . C discusses how we could move forward, D where we should discuss and fina= lly E my opinion as an individual. Input/feedback is appreciated. =20 A. Existing (old) use cases=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The use cases listed in http://datatracker.ietf.org/doc/draft-ietf-rtcweb-u= se-cases-and-requirements/ where not questioned, all survived. However, the= document type should be changed. B. New use cases =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I noted (as not immediately dismissed) the following proposals: =20 1. Distributed music band, discussed at the webrtc meeting 2. Use cases regarding different situations when being invited to a =93= session=94, e.g. browser open, browser open but another tab active, browser= open but active in session, browser closed, =85. (Matthew Kaufman); discus= sed at webrtc meeting 3. Different TURN provider scenarios (Cullen Jennings); discussed at th= e webrtc meeting 4. More challenging NAT case (Matthew Kaufman); UDP blocked http://www.= ietf.org/mail-archive/web/rtcweb/current/msg00468.html 5. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/rtcweb/cur= rent/msg00525.html 6. Local Recording (John Ewell) at webrtc meeting 7. Remote recording (John) http://www.ietf.org/mail-archive/web/rtcweb= /current/msg00472.html 8. Emergency access for disabled (Bernard Aboba) http://www.ietf.org/ma= il-archive/web/rtcweb/current/msg00478.html 9. Clue use cases (Roni Even) http://tools.ietf.org/html/draft-ietf-clu= e-telepresence-use-cases-01 10. Rohan red cross (Cullen Jennings); proposed a bit earlier http://ww= w.ietf.org/mail-archive/web/rtcweb/current/msg00323.html Probably I have missed a few. =20 C. Way forward =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The proper way forward would probably be to have people draft text describi= ng these use cases and derive requirements they add, and then have a discus= sion on whether they should be included for version one of the standard or = not. =20 In some cases the description exists already (Rohan red cross, emergency ac= cess for disabled, clue use cases) but not requirements. =20 Are there volunteers (maybe the ones proposing them)? D. Where to discuss =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This mail is sent to both public-webrtc at w3.org and to rtcweb at ietf.org= . We have discussed that there should be only one use case document that is= common for the webrtc and the rtcweb WGs, possibly the current ietf use ca= se doc (http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-req= uirements/). Does this mean that it would be OK to discuss use cases on the= rtcweb list only, or should we cross post? Some of the proposed new use cases (2, 6) have relatively little bearing on= IETF IMO; they are more W3C related, perhaps they should be documented and= discussed in a webrtc context only. E. Opinion as individual =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My personal opinion is that we at this stage should focus on the basic use = cases, and solve those in a good way. To me that would mean that we should = add 3 (to allow different providers) and 4 (if you can=92t connect no use c= ase can be supported). I think that these use cases can be added as twists = of/extensions to the first use case (Simple Video Communication Service). =20 In my view it also means that we should add text and requirements for 2 to = make sure that the communication capabilites we are adding to the browser i= s usable in everyday scenarios. Presumable this would lead requirements (e.= g. background execution capability) that are transferred to other W3C WGs -= not to requirements in the webrtc/rtcweb space. =20 >From a W3C perspective it could also make sense to add a recording use case= (as it seems that other W3C WGs rely on webrtc to provide an API for recor= ding). The rest of the new proposed use cases, IMO, could be looked into in a seco= nd stage when we've established the basics. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 Comments? =20 Stefan= From stefan.lk.hakansson@ericsson.com Thu Aug 4 01:07:23 2011 Return-Path: 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 875E121F850C for ; Thu, 4 Aug 2011 01:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.24 X-Spam-Level: X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Axx8A0rcWl4m for ; Thu, 4 Aug 2011 01:07:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AF92D21F8507 for ; Thu, 4 Aug 2011 01:07:22 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-51-4e3a53479bdc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 98.C0.09774.7435A3E4; Thu, 4 Aug 2011 10:07:35 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.110]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 4 Aug 2011 10:07:35 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Magnus Westerlund , "rtcweb@ietf.org" Date: Thu, 4 Aug 2011 10:07:35 +0200 Thread-Topic: [rtcweb] New Milestones for RTCWEB WG Thread-Index: AcxRDhU9WJHLuA1iTWaZf4MWcOVhDwBbo7ZM Message-ID: References: <4E37EAAB.3020708@ericsson.com> In-Reply-To: <4E37EAAB.3020708@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] New Milestones for RTCWEB WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 04 Aug 2011 08:07:23 -0000 As one of the webrtc chairs I have the generic comment that the sooner info= rmation is available the better. In particular, webrtc is planning a f2f me= eting at the W3C TPAC (Oct 31 and Nov 1). To get the most out of that meeti= ng it would be good if the Use Cases and Sec/Priv documents are available, = and if there can be some advance info on what reqs the "current solution" h= as on the API(s) by then. Cheers, Stefan ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Magnus= Westerlund [magnus.westerlund@ericsson.com] Sent: Tuesday, August 02, 2011 2:16 PM To: rtcweb@ietf.org Subject: [rtcweb] New Milestones for RTCWEB WG WG, As raised in the WG meeting last week we plan to submit new milestones. These is to make the time line a bit more realistic to actually be meet. They also try to adjust to the picked document structure. Here they are: Oct 2011 Send Use Cases (draft-ietf-rtcweb-use-cases-and-requirements), Overview (draft-ietf-rtcweb-overview), Security and Privacy Documents (I-D) to W3C Dec 2011 Send Use Cases (draft-ietf-rtcweb-use-cases-and-requirements) document to IESG for publication as Informational Apr 2012 Send W3C input on what requirements the current solution has on API(s) May 2012 Send Overview (draft-ietf-rtcweb-overview), Security and Privacy Model documents to IESG for publication as Informational May 2012 Send Signalling and Negotiation, and NAT Traversal to IESG for publication as Proposed Standard Jun 2012 Send Media Transport, Media Processing, and Codecs to IESG for publication as Proposed Standard Jun 2012 Send Datagram Transport for non-media data to IESG for publication as Proposed Standard These will soon be submitted for official publication. If you have any issues please raise them on the list and we can discuss them. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Thu Aug 4 08:05:09 2011 Return-Path: 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 EAE6621F8B47 for ; Thu, 4 Aug 2011 08:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J0f0644UWIT for ; Thu, 4 Aug 2011 08:05:09 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 252F621F8B25 for ; Thu, 4 Aug 2011 08:05:08 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QozUA-0001G8-Tf; Thu, 04 Aug 2011 10:05:22 -0500 Message-ID: <4E3AB4D4.4070308@jesup.org> Date: Thu, 04 Aug 2011 11:03:48 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org, public-webrtc@w3.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Use cases: summary of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 04 Aug 2011 15:05:10 -0000 On 8/4/2011 3:57 AM, Stefan Håkansson LK wrote: > > B. New use cases > =========== > I noted (as not immediately dismissed) the following proposals: > > 1. Distributed music band, discussed at the webrtc meeting > 2. Use cases regarding different situations when being invited to a “session”, e.g. browser open, browser open but another tab active, browser open but active in session, browser closed, …. (Matthew Kaufman); discussed at webrtc meeting > 3. Different TURN provider scenarios (Cullen Jennings); discussed at the webrtc meeting > 4. More challenging NAT case (Matthew Kaufman); UDP blocked http://www.ietf.org/mail-archive/web/rtcweb/current/msg00468.html > 5. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/rtcweb/current/msg00525.html > 6. Local Recording (John Ewell) at webrtc meeting Would this cover all "voicemail" and "videomail" cases? I.e. having a client accept connections in the background if the call is not answered, optionally play a message, and record incoming audio/video, and allow the remote user to interact with it. Also remote playback of messages. If not (and if it's not covered by the current document, we need to add this usecase. Note that there are two variants: one local (local client handles it, which has more security issues around camera access and pre-approval), and one for remote recording (after some time with no answer or if not "registered" call is forwarded to a message server that answers it). Note that there are security identity issues here (key chains, etc). > > 7. Remote recording (John) http://www.ietf.org/mail-archive/web/rtcweb/current/msg00472.html > 8. Emergency access for disabled (Bernard Aboba) http://www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html > 9. Clue use cases (Roni Even) http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-01 > 10. Rohan red cross (Cullen Jennings); proposed a bit earlier http://www.ietf.org/mail-archive/web/rtcweb/current/msg00323.html > > Probably I have missed a few. I'd add: 11. Remote assistance (ala VNC or RDP) - User is helping another user on their computer with either view-only or view-with-control, either of just the browser of the the entire screen. Computer audio is optionally sent as well. They are optionally talking and/or viewing each other while this is occurring. They may be transferring files over a reliable data connection during this session. Commentary: How often have you talked to your father/mother/brother/etc and tried to debug their computer problems remotely? And getting them to install a specific remote-assistance package, and to use it, and get it to work through firewalls, can be very painful. (There are other uses of this ability to copilot as well, including classroom instruction, distance learning, etc.) This use-case enables someone to build a JS app to provide this functionality. (Note that for the W3 and browser vendors there will be significant security issues to resolve.) I think this is actually a fairly important use-case. Additional resulting requirements: * Need to be able to select a "video" source other than a camera (window or screen) (W3 issue) * Need to be able to send multiple video and audio streams from different sources (probably already covered, mostly W3 issue) * Need to be able to use a reliable data connection (for mouse/keyboard/etc control, plus file transfer) 12. Security camera/baby monitor usage - use a persistent or temporary connection to provide basic security camera operation, including switching cameras or mics, or with the ability to remotely request review of recent data recorded. Should be able to switch to 2-way audio and/or video remotely. Additional requirements: * Need to be able to select a "video" source other than a camera (file) (W3 issue) * Remote control of camera/mic selection and enabling (W3 issue) - may require reliable data connection * May need control from JS over codecs used, at least voice vs audio, etc, and max video framerate/resolution/bandwidth (W3 issue largely?) > > > E. Opinion as individual > =============== > My personal opinion is that we at this stage should focus on the basic use cases, and solve those in a good way. To me that would mean that we should add 3 (to allow different providers) and 4 (if you can’t connect no use case can be supported). I think that these use cases can be added as twists of/extensions to the first use case (Simple Video Communication Service). > > In my view it also means that we should add text and requirements for 2 to make sure that the communication capabilites we are adding to the browser is usable in everyday scenarios. Presumable this would lead requirements (e.g. background execution capability) that are transferred to other W3C WGs - not to requirements in the webrtc/rtcweb space. > > > From a W3C perspective it could also make sense to add a recording use case (as it seems that other W3C WGs rely on webrtc to provide an API for recording). > > The rest of the new proposed use cases, IMO, could be looked into in a second stage when we've established the basics. I'd very much want to include the "remote assistance" case, and I think the voicemail cases could be very important in overall acceptance and utility, especially given the issues over whether someone's machine is running and accepting calls. Security cam/baby-monitor is less important, but highlights some controls that we may want to expose to the JS over maximum bitrate/framerate/resolution/etc, and of course a slew of security issues for W3 to think about. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Thu Aug 4 08:38:30 2011 Return-Path: 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 C2D6521F8AFD for ; Thu, 4 Aug 2011 08:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdqnQU68ndhp for ; Thu, 4 Aug 2011 08:38:30 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id B581221F86AF for ; Thu, 4 Aug 2011 08:38:29 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qp00S-0004pj-DT; Thu, 04 Aug 2011 10:38:44 -0500 Message-ID: <4E3ABCA6.30706@jesup.org> Date: Thu, 04 Aug 2011 11:37:10 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org, public-webrtc@w3.org References: <4E3AB4D4.4070308@jesup.org> In-Reply-To: <4E3AB4D4.4070308@jesup.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Use cases: summary of status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 04 Aug 2011 15:38:30 -0000 Responding to myself: > 11. Remote assistance (ala VNC or RDP) - User is helping another user on > their computer with either view-only or view-with-control, either of just > the browser of the the entire screen. Computer audio is optionally sent > as well. They are optionally talking and/or viewing each other while this > is occurring. They may be transferring files over a reliable data > connection during this session. > > > Commentary: How often have you talked to your father/mother/brother/etc > and tried to debug their computer problems remotely? And getting them to > install a specific remote-assistance package, and to use it, and get it to > work through firewalls, can be very painful. (There are other uses of this > ability to copilot as well, including classroom instruction, distance learning, > etc.) This use-case enables someone to build a JS app to provide this > functionality. (Note that for the W3 and browser vendors there will be > significant security issues to resolve.) I think this is actually a fairly > important use-case. Other uses this use-case covers: Meetecho - ability to use as a video source a window on your computer (i.e. presentation), while also optionally exchanging or sending audio and/or video, and optionally having a (reliable) data channel for side-chat ala the meetecho chat window. Note that this is most useful if the window can be any window, not just the browser. Very useful for business/sales presentations as well (could help avoid a whole bunch of travel by sales engineers and the like). I don't believe this would add any new requirements. -- Randell Jesup randell-ietf@jesup.org From ekr@rtfm.com Thu Aug 4 09:46:56 2011 Return-Path: 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 B520621F8BBA for ; Thu, 4 Aug 2011 09:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrsG8qiOShcI for ; Thu, 4 Aug 2011 09:46:55 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD9621F8AF6 for ; Thu, 4 Aug 2011 09:46:55 -0700 (PDT) Received: by wyg8 with SMTP id 8so642152wyg.31 for ; Thu, 04 Aug 2011 09:47:10 -0700 (PDT) Received: by 10.227.55.20 with SMTP id s20mr943513wbg.15.1312476429942; Thu, 04 Aug 2011 09:47:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.63.11 with HTTP; Thu, 4 Aug 2011 09:46:49 -0700 (PDT) From: Eric Rescorla Date: Thu, 4 Aug 2011 09:46:49 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] More on authorization and endpoint authentication X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 04 Aug 2011 16:46:56 -0000 I wanted to follow up to something I said at the microphone last week with regard to Cullen's presentation (http://www.ietf.org/proceedings/81/slides/rtcweb-13.pdf) and in particular slide 9, which argues that using a first-class signaling protocol for the actual signaling has better security properties. I got on Cullen pretty hard about this, but in retrospect I think I may have been a bit hasty. The basic imperative for securing the camera and microphone in RTCWeb is that you be able to determine who the media will go to (e.g., you are talking to Ford.) What I had in my head in my slides was that we would do this by restricting access to the JavaScript APIs. I.e., that you would grant www.ford.com the right to use the WebRTC APIs. I.e., the policy would be: P1: Allow any script coming from www.ford.com to call anywhere. The way (or at least a way) you use this to get a call is that DoubleClick brings up an IFRAME on Ford's site that loads up JS calling the right location at Ford. And since the browser has direct access to the origin, it can evaluate this policy directly. If you're not willing to have a hosted IFRAME like this, then the permissions reduces to letting DC call alyone. The model in slide 9, however, is different: instead of restricting access to the APIs to a given site, it instead allows anyone to invoke the APIs, but *calls* are restricted to a given site. So, in this case, the access control policy would be: P2: Allow anyone to place a call provided that it goes to *@ford.com. The browser evaluates this (in the simplest case) by connecting to ford.com's SIP server and verifying that it is indeed ford.com. My (rather loud) argument at the microphone was that P1 and P2 have similar security properties and I was trying to push back on Cullen's claim that P2 was better. In either case, ford.com gets to capture your audio and video and send it wherever it wants. And obviously, if it just wants to turn on your camera and send it to your ex-wife it can. However, thinking about it more, I think that claim is too strong; there are two differences, one technical and one social. The technical difference is simply that in one case Ford has to stand up a bunch of new technical infrastructure to serve/service the WebRTC code that establishes its origin and initiates the call [0]. By contrast, the solution Cullen proposes allows reuse of all the existing calling technical infrastructure (whether SIP or Jingle) that Ford already has. The social difference is about the assertion that Ford is making. In the former case, Ford is saying "I'll do something with this call, and you'll like it." In the second they are saying "you are making a call to someone at Ford." So, while from a technical security guy perspective, they are equally able to screw you over in either case by lying, if they *aren't* lying then the policy your browser is enforcing on your behalf is a lot clearer: "only call people who have Ford addresses." At a higher level, I think we've been failing to draw the distinction between two cases which are socially (and arguably technically) very different: 1. The calling service is permitted to place a call but all the information about who you are actually calling is accessible only to the JS provided by the calling service. 2. The calling service is permitted to place a call but the browser has independent information about who you are actually talking to. [and could at least in principle render it to the user.] Matthew's UI document and Cullen's presentation both point towards the notion that #2 is valuable as well, with Cullen's presentation being more oriented towards signaling and Matthew's more oriented towards the media-level security, but in both cases suggesting that we may not just want to authorize the calling service and let it call wherever with no other independent security mechanisms. I'm not sure whether this concept covers all the relevant cases, since at least conceptually it depends on the notion that everyone has an actual name that is somehow qualified by a universally meaningful name and there are probably cases where I just want to phone home to the Web site. However, it seems like it's at least plausibly a useful piece of functionality in addition to what I had been thinking of as an origin-based API restriction. -Ekr [0] It can of course outsource that with