From nobody Wed Jul 1 16:07:07 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF021A9047; Wed, 1 Jul 2015 16:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jek4Dz8Kq4Be; Wed, 1 Jul 2015 16:07:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 951D21A9077; Wed, 1 Jul 2015 16:07:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150701230703.20061.57203.idtracker@ietfa.amsl.com> Date: Wed, 01 Jul 2015 16:07:03 -0700 Archived-At: Cc: rtcweb mailing list , rtcweb chair , RFC Editor Subject: [rtcweb] Protocol Action: 'Web Real-Time Communication (WebRTC): Media Transport and Use of RTP' to Proposed Standard (draft-ietf-rtcweb-rtp-usage-25.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 23:07:06 -0000 The IESG has approved the following document: - 'Web Real-Time Communication (WebRTC): Media Transport and Use of RTP' (draft-ietf-rtcweb-rtp-usage-25.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ Technical Summary The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, and other media between two peers' web-browsers. This document describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. Working Group Summary The document passed initial WG last call at version 14, with an outstanding issue about FEC remaining; that has since been split into a new document (draft-ietf-rtcweb-fec). Between that draft and this there were also additional comments on video orientation and media stream identification which resulted in new text. I do not believe there were areas where consensus is particularly rough at this point. Document Quality There are multiple implementations of the WebRTC framework and they generally interoperate. The review of the draft by the working group was adequate, if prolonged. It should be noted that some less-used aspects of RTP processing are well-understood by only a small number of participants, but the related matters appear to be resolved. Personnel Ted Hardie is the Document Shepherd. Alissa Cooper is the Responsible Area Director. RFC Editor Note draft-ietf-avtcore-rtp-topologies-update should be changed from a normative reference to an informative reference. From nobody Thu Jul 2 10:55:58 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08921A1B61; Thu, 2 Jul 2015 10:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63zMA06XZEq7; Thu, 2 Jul 2015 10:55:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 924B51A1B18; Thu, 2 Jul 2015 10:55:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150702175553.22797.97637.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 10:55:53 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] Last Call: (STUN Usage for Consent Freshness) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 02 Jul 2015 17:55:54 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'STUN Usage for Consent Freshness' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-07-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This document was previously last called on May 1 and has been updated as a result of comments submitted during that last call. Abstract To prevent WebRTC applications, such as browsers, from launching attacks by sending media to unwilling victims, periodic consent to send needs to be obtained from remote endpoints. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Jul 5 17:09:30 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB491B29B1; Sun, 5 Jul 2015 17:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQjW43Te3GOR; Sun, 5 Jul 2015 17:09:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BDE1B29AC; Sun, 5 Jul 2015 17:09:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706000926.25346.38153.idtracker@ietfa.amsl.com> Date: Sun, 05 Jul 2015 17:09:26 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 06 Jul 2015 00:09:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-11.txt Pages : 75 Date : 2015-07-05 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 01:35:24 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC951A90A7 for ; Mon, 6 Jul 2015 01:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8dMueKphOXO for ; Mon, 6 Jul 2015 01:35:17 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 361151A90C0 for ; Mon, 6 Jul 2015 01:35:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 36F127C3758; Mon, 6 Jul 2015 10:35:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF2b-8W3ONuG; Mon, 6 Jul 2015 10:35:14 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:ec4f:9b88:6776:d956] (unknown [IPv6:2001:470:de0a:27:ec4f:9b88:6776:d956]) by mork.alvestrand.no (Postfix) with ESMTPSA id 91DCA7C3752; Mon, 6 Jul 2015 10:35:14 +0200 (CEST) Message-ID: <559A3DC2.5020905@alvestrand.no> Date: Mon, 06 Jul 2015 10:35:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Cullen Jennings References: <5587EF5F.5040805@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] LS groups (Re: Cullen Notes from RTCWeb interim on June 18, 2015) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 08:35:23 -0000 Den 29. juni 2015 19:24, skrev Cullen Jennings: > > I think that LS makes more sense. Doing both LS and MSID was a comprise the WG came to long ago. We need for a say to synchronized audio and video and the IETF has already defined a widely deployed way of doing that so I don't see a gain in ignoring it and inventing something else. As I've said before, I've got no qualms about adding LS for interoperability, for the cases where it makes sense. I do have strong qualms about changing the definition of LS so that stuff only interoperates some of the time (the "make it declarative" solution). I have also heard some people mumble about discarding the MSID mechanism and only using LS; this is a proposal that I do not think will satisfy the group's requirements. And with regard to whether the WG came to the conclusion that we should do both LS and MSID "long ago": I was present long ago, and I don't recall the group coming to such a conclusion. I've found a proposal for such a solution (draft-jennings-rtcweb-plan-01, February 25 2013, section 7 bullet 7), but that proposal seems to ignore the one-way nature of MediaStreams (which is what led to the current isuse), and I've found no evidence of a WG consensus on that part of that specification. > > >> On Jun 22, 2015, at 5:19 AM, Harald Alvestrand wrote: >> >> On 06/18/2015 08:00 PM, Cullen Jennings (fluffy) wrote: >>> * make sure to add note well slide to slide deck >>> >>> LS Behavior >>> - Magnus points out that if JSEP overrides 5888, we will have issue with legacy things >>> - Martin points needs more thought to make declarative groups >>> - Martin raised point that we might be able to add some extra signaling that indicates that we can support this declarative LS usage >>> >>> Conclusion: Magnus will dig into more analysis of options on this and send to list. No decision on Option 1,2 >>> >> Just FWIW: >> >> Personally, I don't see the added value in adding LS groups. >> >> We already have a well defined, declarative (=one-way) means of declaring synchronization in the form of the MSID values, which bind MediaStreamTracks into MediaStreams, which you're supposed to try syncing if you can (it's not a hard requirement in the spec that you should succeed). >> >> If we want to be extra helpful for non-WebRTC implementations, and end up in the case where we have one audio and one video track from one stream in one direction using the same media descriptions as an audio and video track in the other direction (which will be the normal case when your application is trying to emulate a single-channel VC unit), I have no particular problems with adding LS group markings to those media descriptions - but I don't want to spend resources changing the semantics of LS groups (and thereby imperiling the exact interworking we're trying to make easier) when we already have something that fulfils all the requirements for a pure WebRTC scenario. >> >> My $0.02. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Jul 6 13:08:53 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD361B31A8 for ; Mon, 6 Jul 2015 13:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDQlNvx_c8pK for ; Mon, 6 Jul 2015 13:08:50 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4B01B31AC for ; Mon, 6 Jul 2015 13:08:42 -0700 (PDT) Received: by widjy10 with SMTP id jy10so170609701wid.1 for ; Mon, 06 Jul 2015 13:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HPW+u24uvvY48Y87SDgD2doXWze1Yj4p+PlEk2YE2bw=; b=D11mNUtgECQQTJCWDnNJNLaofqHbyiJLeSgKMM6MTuvE/a77Wxp9cQgcnEXpes6RKD iLGFs4huUbmedNrtc1kxQqwKCr9e8cXglT/+OSEmBXei6wx7IEW9A3ss3SshsbomPEba wHzI2gEBDv5GSlYp7cOirMmGOZXWSNLdU6NPefZaRXlUxGgb7SurSqjaixAXKKLdmwL6 Z6YbCYg1UKvwWecf2QwS2w9XE9+kkkZYvrWrqzJSxn8WkW3Nb9Xw2G+va1hISREiiGEC fiEzmI4TEyEq5oG45WV0nei9mu5yuFWqP1PyQsaD88IcvpVfMQ9k3ORrRMMcI6vGDUuP 8PnA== MIME-Version: 1.0 X-Received: by 10.180.9.111 with SMTP id y15mr55192993wia.18.1436213321575; Mon, 06 Jul 2015 13:08:41 -0700 (PDT) Received: by 10.194.25.74 with HTTP; Mon, 6 Jul 2015 13:08:41 -0700 (PDT) Date: Mon, 6 Jul 2015 13:08:41 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a11c24888dab3a9051a3a7868 Archived-At: Subject: [rtcweb] Tentative agenda X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 20:08:52 -0000 --001a11c24888dab3a9051a3a7868 Content-Type: text/plain; charset=UTF-8 https://www.ietf.org/proceedings/93/agenda/agenda-93-rtcweb corrections or suggestions to the list, please. Ted, Cullen, and Sean --001a11c24888dab3a9051a3a7868 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
https://www.ietf.org/proceedings/93/agenda/agenda-9= 3-rtcweb

corrections or suggestions to the list,= please.

Ted, Cullen, and Sean
--001a11c24888dab3a9051a3a7868-- From nobody Mon Jul 6 14:20:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D50C1A004C; Mon, 6 Jul 2015 14:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLetgKAymnaI; Mon, 6 Jul 2015 14:20:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A2C1A0041; Mon, 6 Jul 2015 14:20:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706212025.31090.49494.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 14:20:25 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 06 Jul 2015 21:20:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Transports for WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-09.txt Pages : 15 Date : 2015-07-06 Abstract: This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 15:01:13 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D16F1A1A6A for ; Mon, 6 Jul 2015 15:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEX040QC5guj for ; Mon, 6 Jul 2015 15:01:10 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED331A1A3B for ; Mon, 6 Jul 2015 15:01:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E6D1C7C3764; Tue, 7 Jul 2015 00:01:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abTtmnt-vD_B; Tue, 7 Jul 2015 00:01:07 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:18ae:b7c4:5e3a:9fb6] (unknown [IPv6:2001:470:de0a:27:18ae:b7c4:5e3a:9fb6]) by mork.alvestrand.no (Postfix) with ESMTPSA id A7D2F7C3763; Tue, 7 Jul 2015 00:01:07 +0200 (CEST) Message-ID: <559AFAA3.70803@alvestrand.no> Date: Tue, 07 Jul 2015 00:01:07 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ted Hardie , "rtcweb@ietf.org" , Cullen Jennings , Sean Turner References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Tentative agenda X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:01:12 -0000 Den 06. juli 2015 22:08, skrev Ted Hardie: > https://www.ietf.org/proceedings/93/agenda/agenda-93-rtcweb > > corrections or suggestions to the list, please. > > Ted, Cullen, and Sean > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Note - I have just submitted an update to -transports. I don't think the change needs agenda time (it was just the DTLS paragraph we discussed long ago), but if anyone has any other issues with it, I'd appreciate it if they were filed at https://github.com/rtcweb-wg/rtcweb-transport/issues so that I don't lose track of them - and if the chairs think we need agenda time for them, I'll be there. Harald From nobody Mon Jul 6 15:15:04 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937691A1A2D; Mon, 6 Jul 2015 15:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBdHctpA6I5K; Mon, 6 Jul 2015 15:14:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA54A1A1B7D; Mon, 6 Jul 2015 15:14:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706221457.6336.79129.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 15:14:57 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-gateways-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 06 Jul 2015 22:15:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : WebRTC Gateways Authors : Harald Alvestrand Uwe Rauschenbach Filename : draft-ietf-rtcweb-gateways-01.txt Pages : 7 Date : 2015-07-06 Abstract: This document describes interoperability considerations for a class of WebRTC-compatible endpoints called "WebRTC gateways", which interconnect between WebRTC endpoints and devices that are not WebRTC endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-gateways/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-gateways-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-gateways-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 15:19:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95581A1AB6 for ; Mon, 6 Jul 2015 15:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNo1w39566kW for ; Mon, 6 Jul 2015 15:19:10 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id CF90C1A1A2D for ; Mon, 6 Jul 2015 15:19:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0C4F87C3764 for ; Tue, 7 Jul 2015 00:19:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoByfmuOTefC for ; Tue, 7 Jul 2015 00:19:08 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:18ae:b7c4:5e3a:9fb6] (unknown [IPv6:2001:470:de0a:27:18ae:b7c4:5e3a:9fb6]) by mork.alvestrand.no (Postfix) with ESMTPSA id 30FB97C3763 for ; Tue, 7 Jul 2015 00:19:08 +0200 (CEST) Message-ID: <559AFEDB.4070205@alvestrand.no> Date: Tue, 07 Jul 2015 00:19:07 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Updated -gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:19:11 -0000 Uwe and I have prepared a new -gateways draft (version -01). I don't think there's much controversial in it, and there's only one issue that I think needs WG time at this time: Should it be Informational or Standards-track? An informational document defines guidance for how gateways should behave, but nobody needs to pay attention if they don't want to. A standards-track document (which no other RTCWEB document should be dependent on) defines requirements for how things that call themselves "WebRTC gateways" should behave, but nobody needs to call their gateways that, and anyway, there's no protocol police, so the difference isn't all that much in practice. More important: What do people want it to be? Harald From nobody Mon Jul 6 15:35:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF641A1B4C for ; Mon, 6 Jul 2015 15:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKwhWSG-nRlV for ; Mon, 6 Jul 2015 15:35:23 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D871A1AE1 for ; Mon, 6 Jul 2015 15:35:23 -0700 (PDT) Received: by wgqq4 with SMTP id q4so152633911wgq.1 for ; Mon, 06 Jul 2015 15:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mc3kE/0cTeBcHzNzS76II/Zgxd/UYBMZpWoApWxrYgQ=; b=G1gcTPLOV8bW4CSC9UXWNrTGlOFVpfdre6YX7tA1HXKGhR0/fbz7O7zNEdAYK89Gt9 pYRsX+4tMhBUj88o1rhNb8Rma/XR72e3BzPd+HkTH0uiZ9ZOf0vxasLHk5QGDVEAL4t/ xlKPkKQ8oVILpvjZoKFs7i7QapHc6g9DEnJj8hnamQi3u6uwMXN7WARVpZJJGrZiAaKH ScJ9vCfHoxH405UlS5zZkTxRSJS2dxwB/Zs6ySnhaXsVorWrWlsOmm14MYAfiJo3QuTZ mZeOpqcpJ5NVjFRTHsDbFx8tCwjFzwpRW5PCx+g5tryGNQWlZ8CXYSfIfxfp4yomndSF 62Hg== MIME-Version: 1.0 X-Received: by 10.194.189.80 with SMTP id gg16mr2152286wjc.9.1436222122161; Mon, 06 Jul 2015 15:35:22 -0700 (PDT) Received: by 10.194.25.74 with HTTP; Mon, 6 Jul 2015 15:35:22 -0700 (PDT) In-Reply-To: <559AFEDB.4070205@alvestrand.no> References: <559AFEDB.4070205@alvestrand.no> Date: Mon, 6 Jul 2015 15:35:22 -0700 Message-ID: From: Ted Hardie To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7bb03f9c68fdaa051a3c8552 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated -gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:35:25 -0000 --047d7bb03f9c68fdaa051a3c8552 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 6, 2015 at 3:19 PM, Harald Alvestrand wrote: > Uwe and I have prepared a new -gateways draft (version -01). > > I don't think there's much controversial in it, and there's only one > issue that I think needs WG time at this time: > > Should it be Informational or Standards-track? > > An informational document defines guidance for how gateways should > behave, but nobody needs to pay attention if they don't want to. > > A standards-track document (which no other RTCWEB document should be > dependent on) defines requirements for how things that call themselves > "WebRTC gateways" should behave, but nobody needs to call their gateways > that, and anyway, there's no protocol police, so the difference isn't > all that much in practice. > > More important: What do people want it to be? > > =E2=80=8BI think we adopted it in part because 3GPP had a dependency on it.= Does it need to be standards track for them to reference it? Ted=E2=80=8B > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bb03f9c68fdaa051a3c8552 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 6, 2015 at 3:19 PM,= Harald Alvestrand <harald@alvestrand.no> wrote:
Uwe and I have prepare= d a new -gateways draft (version -01).

I don't think there's much controversial in it, and there's onl= y one
issue that I think needs WG time at this time:

Should it be Informational or Standards-track?

An informational document defines guidance for how gateways should
behave, but nobody needs to pay attention if they don't want to.

A standards-track document (which no other RTCWEB document should be
dependent on) defines requirements for how things that call themselves
"WebRTC gateways" should behave, but nobody needs to call their g= ateways
that, and anyway, there's no protocol police, so the difference isn'= ;t
all that much in practice.

More important: What do people want it to be?


=E2=80=8BI think we adopted it in part = because 3GPP had a dependency on it.=C2=A0 Does it need to be standards tra= ck for them to reference it?

Ted=E2=80=8B

<= br>=C2=A0
Harald

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bb03f9c68fdaa051a3c8552-- From nobody Mon Jul 6 15:48:53 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFCC1A8881 for ; Mon, 6 Jul 2015 15:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11I4ZMAE3KDJ for ; Mon, 6 Jul 2015 15:48:47 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4731A8850 for ; Mon, 6 Jul 2015 15:48:47 -0700 (PDT) Received: by wgqq4 with SMTP id q4so152814789wgq.1 for ; Mon, 06 Jul 2015 15:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OiOLJyMANxjFUVEwGY/LQNt/4CNinYgBA6f25tlB/Dw=; b=z3spCa8yGjcGq5X7/ZNkI03imPaYhPLWjUmUhjIL7xqveuTKJtqZVD36Vj/UGUkmnA TgrcsfQn27YVQK+Th4LYf0Hbyh+xZPUiEyRC82njd3EYl4H0fXXygp2yZEi6EltpST/G /h9Pgj7iMrPAvI1sr/ubui/2iEBdMvDqTb+2fT4dn4ju39sZPR8gAodeFgx0Kcx2c/WJ c0JNtBhORkujnUFu/DGDI16oP6+a0rk2mcf/UGqJhQeluYFx7Fp5XD8KnXFUQ46DgqMx kRbaDVK8Mrxkg3h1gLllHswj4y9N75eUuWmUMMU+u7FIZB2AqMBPph7abeoIWsPH567a XAiQ== MIME-Version: 1.0 X-Received: by 10.194.62.228 with SMTP id b4mr2438878wjs.2.1436222926190; Mon, 06 Jul 2015 15:48:46 -0700 (PDT) Received: by 10.28.155.202 with HTTP; Mon, 6 Jul 2015 15:48:46 -0700 (PDT) In-Reply-To: <20150706184419.5823.65536.idtracker@ietfa.amsl.com> References: <20150706184419.5823.65536.idtracker@ietfa.amsl.com> Date: Mon, 6 Jul 2015 17:48:46 -0500 Message-ID: From: Alan Johnston To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bacc110557ceb051a3cb5a3 Archived-At: Subject: [rtcweb] Fwd: New Version Notification for draft-johnston-rtcweb-zrtp-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:48:50 -0000 --047d7bacc110557ceb051a3cb5a3 Content-Type: text/plain; charset=UTF-8 FYI - a minor update of the draft with the implementation status. Anyone interested in working on an open source ZRTP in JavaScript library, contact me off list or in Prague. - Alan - ---------- Forwarded message ---------- From: Date: Mon, Jul 6, 2015 at 1:44 PM Subject: New Version Notification for draft-johnston-rtcweb-zrtp-02.txt To: Alan Johnston , Travis Cross < tc@traviscross.com>, John Yoakum , Philip Zimmermann < prz@mit.edu>, Jon Callas A new version of I-D, draft-johnston-rtcweb-zrtp-02.txt has been successfully submitted by Alan Johnston and posted to the IETF repository. Name: draft-johnston-rtcweb-zrtp Revision: 02 Title: Using ZRTP to Secure WebRTC Document date: 2015-07-06 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-johnston-rtcweb-zrtp-02.txt Status: https://datatracker.ietf.org/doc/draft-johnston-rtcweb-zrtp/ Htmlized: https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-johnston-rtcweb-zrtp-02 Abstract: WebRTC, Web Real-Time Communications, is a set of protocols and APIs used to enable web developers to add real-time communications into their web pages and applications with a few lines of JavaScript. WebRTC media flows are encrypted and authenticated by SRTP, the Secure Real-time Transport Protocol while the key agreement is provided by DTLS-SRTP, Datagram Transport Layer Security for Secure Real-time Transport Protocol. However, without some third party identity service or certificate authority, WebRTC media flows have no protection against a man-in-the-middle (MitM) attack. ZRTP, Media Path Key Agreement for Unicast Secure RTP, RFC 6189, does provide protection against MitM attackers using key continuity augmented with a Short Authentication String (SAS). This specification describes how ZRTP can be used over the WebRTC data channel to provide MitM protection for WebRTC media flows keyed using DTLS-SRTP. This provides users protection against MitM attackers without requiring browsers to support ZRTP or users to download a plugin or extension to implement ZRTP. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --047d7bacc110557ceb051a3cb5a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI - a minor update of the draft with the implementation = status.=C2=A0 Anyone interested in working on an open source ZRTP in JavaSc= ript library, contact me off list or in Prague.

- Alan -=

---------- Forwarded message ----= ------
From: <internet-drafts@ietf.org><= /span>
Date: Mon, Jul 6, 2015 at 1:44 PM
Subject: New Version Notific= ation for draft-johnston-rtcweb-zrtp-02.txt
To: Alan Johnston <alan.b.johnston@gmail.com>, T= ravis Cross <tc@traviscross.com>, John Yoakum <yoakum@avaya.com= >, Philip Zimmermann <prz@mit.edu<= /a>>, Jon Callas <jon@callas.org>



A new version of I-D, draft-johnston-rtcweb-zrtp-02.txt
has been successfully submitted by Alan Johnston and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-johnston-rtcweb-zrtp Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Using ZRTP to Secure WebRTC
Document date:=C2=A0 2015-07-06
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-johnston-rtcweb-= zrtp-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-johnston-rtcweb-zrtp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-johnston-rtcweb-zrtp-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-johnston-rtcweb-zrtp-= 02

Abstract:
=C2=A0 =C2=A0WebRTC, Web Real-Time Communications, is a set of protocols an= d APIs
=C2=A0 =C2=A0used to enable web developers to add real-time communications = into
=C2=A0 =C2=A0their web pages and applications with a few lines of JavaScrip= t.
=C2=A0 =C2=A0WebRTC media flows are encrypted and authenticated by SRTP, th= e
=C2=A0 =C2=A0Secure Real-time Transport Protocol while the key agreement is=
=C2=A0 =C2=A0provided by DTLS-SRTP, Datagram Transport Layer Security for S= ecure
=C2=A0 =C2=A0Real-time Transport Protocol.=C2=A0 However, without some thir= d party
=C2=A0 =C2=A0identity service or certificate authority, WebRTC media flows = have no
=C2=A0 =C2=A0protection against a man-in-the-middle (MitM) attack.=C2=A0 ZR= TP, Media
=C2=A0 =C2=A0Path Key Agreement for Unicast Secure RTP, RFC 6189, does prov= ide
=C2=A0 =C2=A0protection against MitM attackers using key continuity augment= ed with
=C2=A0 =C2=A0a Short Authentication String (SAS).=C2=A0 This specification = describes
=C2=A0 =C2=A0how ZRTP can be used over the WebRTC data channel to provide M= itM
=C2=A0 =C2=A0protection for WebRTC media flows keyed using DTLS-SRTP.=C2=A0= This
=C2=A0 =C2=A0provides users protection against MitM attackers without requi= ring
=C2=A0 =C2=A0browsers to support ZRTP or users to download a plugin or exte= nsion
=C2=A0 =C2=A0to implement ZRTP.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--047d7bacc110557ceb051a3cb5a3-- From nobody Tue Jul 7 04:33:31 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593DF1A9308 for ; Tue, 7 Jul 2015 04:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eof8s2F5I72U for ; Tue, 7 Jul 2015 04:33:28 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F011A92FE for ; Tue, 7 Jul 2015 04:33:27 -0700 (PDT) Received: by laar3 with SMTP id r3so191535641laa.0 for ; Tue, 07 Jul 2015 04:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type; bh=GOEEZsARDC4hg+m8nWJZXWtaXxisCRQ3iS5aybOJV0M=; b=tUCKcceLXsPvw+utHHk79EhZpFiZDRWEoR44jU6CXeV749KqO2r7vOw+vQ6VaDM/c+ 6lPlHv0o6+0g5tGhLVbQ5+hcrbouWD+t0+4XPmtre3OXlFOW3Ftg3e4MDeXh8GS4WhTk oLrqlZ8br5oHbSsfrrlBuK2wfcg88rlbEDI/7ATqaFS2vG0MovdQA+b5S+aTLyMPphNP suzmgeTaLDW07pNkeImB0HmCXflGfFj3xtWEKWO/JriKr41gJaI3HLreEbUhlLGpl8LH +ugd+bG8UMMvLq48o9Yew3bEt1Jb8qNP+RQeyGyyp+/Duzmsn9AJcdhrLYmi8QoNvOaS wFgQ== X-Received: by 10.152.2.38 with SMTP id 6mr3648098lar.80.1436268805620; Tue, 07 Jul 2015 04:33:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.162.1 with HTTP; Tue, 7 Jul 2015 04:33:06 -0700 (PDT) In-Reply-To: <20150706000926.25346.38153.idtracker@ietfa.amsl.com> References: <20150706000926.25346.38153.idtracker@ietfa.amsl.com> From: Barry Dingle Date: Tue, 7 Jul 2015 21:33:06 +1000 Message-ID: Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e013c6b92f60811051a476365 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 11:33:29 -0000 --089e013c6b92f60811051a476365 Content-Type: text/plain; charset=UTF-8 In JSEP 5.1.1 Implementation Requirements, the second requirement states: R-2 [RFC5764 ] MUST be supported for signaling the UDP/TLS/RTP/SAVPF [RFC5764 ] and TCP/DTLS/RTP/SAVPF [I-D.nandakumar-mmusic-proto-iana-registration ] RTP profiles. The second [RFC5764] appears to an editorial error. However, I am not sure that the remaining text makes sense as RFC2764 appears to relate to UDP stacks only and appears to explicitly exclude TCP stacks (see its Section 8.) Do we need two requirements - one for UDP stacks and another for TCP stacks? /Barry Dingle On Mon, Jul 6, 2015 at 10:09 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > Working Group of the IETF. > > Title : Javascript Session Establishment Protocol > Authors : Justin Uberti > Cullen Jennings > Eric Rescorla > Filename : draft-ietf-rtcweb-jsep-11.txt > Pages : 75 > Date : 2015-07-05 > > Abstract: > This document describes the mechanisms for allowing a Javascript > application to control the signaling plane of a multimedia session > via the interface specified in the W3C RTCPeerConnection API, and > discusses how this relates to existing signaling protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-11 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e013c6b92f60811051a476365 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In JSEP 5.1.1 Implementation Requirements, the second requ= irement states:=C2=A0

   R=
-2   [RFC5764] MUST be supporte=
d for signaling the UDP/TLS/RTP/SAVPF
         [RFC5764] and TCP/DTLS=
/RTP/SAVPF
         [I-D.nandakumar-mmusic-pr=
oto-iana-registration] RTP profiles. 
The second [RFC5764] appears to a=
n editorial error. 

However, I am not sure that the remaining text makes se=
nse as RFC2764 appears to relate to UDP stacks only and appears to explicitl=
y exclude TCP stacks (see its Section 8.)

Do we need two requir=
ements - one for UDP stacks and another for TCP stacks?
=

/Barry=C2=A0Dingle
=C2=A0=C2=A0
=

On Mon, Jul 6, 2015 at 10:09 AM, <= internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Javascript Session Establishment Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Cullen Jennings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Eric Rescorla
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-jsep-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 75
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-05

Abstract:
=C2=A0 =C2=A0This document describes the mechanisms for allowing a Javascri= pt
=C2=A0 =C2=A0application to control the signaling plane of a multimedia ses= sion
=C2=A0 =C2=A0via the interface specified in the W3C RTCPeerConnection API, = and
=C2=A0 =C2=A0discusses how this relates to existing signaling protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-= rtcweb-jsep/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-j= sep-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-rtcweb-jsep-11


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--089e013c6b92f60811051a476365-- From nobody Tue Jul 7 08:50:44 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3CA1A894F for ; Tue, 7 Jul 2015 08:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2DswSdg0Cgl for ; Tue, 7 Jul 2015 08:50:42 -0700 (PDT) Received: from smtp113.ord1c.emailsrvr.com (smtp113.ord1c.emailsrvr.com [108.166.43.113]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8F41ACCE1 for ; Tue, 7 Jul 2015 08:50:04 -0700 (PDT) Received: from smtp15.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5E9613800B4 for ; Tue, 7 Jul 2015 11:50:04 -0400 (EDT) Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0F45838016B for ; Tue, 7 Jul 2015 11:50:03 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 07 Jul 2015 15:50:04 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 7 Jul 2015 09:50:02 -0600 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [rtcweb] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 15:50:43 -0000 I'd like to get a brief amount of agenda time to discuss changes we = would need to some of the WebRTC WG drafts to make the ideas proposed in = draft-jennings-behave-rtcweb-firewall- work and make people aware of = this work.=20 Would it be possible to get 10 minutes on the agenda ?=20 Thanks, Cullen From nobody Tue Jul 7 09:17:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9B91A8A12 for ; Tue, 7 Jul 2015 09:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0QVp_k7YIdg for ; Tue, 7 Jul 2015 09:17:11 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17E91ACD97 for ; Tue, 7 Jul 2015 09:17:10 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so188161988wib.1 for ; Tue, 07 Jul 2015 09:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IxJbeLDuwaLagHDWkcvNCWaaq1vbom3J5cGciVM1IvU=; b=cZ92E8pexCXLQUqZjyZrlACF0cSEpuV9ry4s4iiAFnXHEUJ+/R7VthaDZuiPhSehqb QvGOimvbe+cgkhT5pQ2NYjjtgsgxFP0ueATd+g1T/xN4RJifIFl+0zVDg4uMBGw8o1+H FKQvcBONX4MK9eSMYRrJF102r8lyQutZpSjXE9Cn2uWEqVwN17NsFa0Ck2Fumsnmgu9y T8IAFLi9A3b7ZcZKo5PsKcy2y2GJLSrvjw49SzVBKYWdCIUw+KfWEytbvz1WIhLCQuPU 4vLRSvYNzFQ6OQlLAs4nmmypwx4qQB7xtaEUu6uX9IxZ4Uengk2bxuWxymbeZmyUliTR uYaw== MIME-Version: 1.0 X-Received: by 10.180.11.68 with SMTP id o4mr7646082wib.10.1436285829413; Tue, 07 Jul 2015 09:17:09 -0700 (PDT) Received: by 10.194.25.74 with HTTP; Tue, 7 Jul 2015 09:17:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jul 2015 09:17:09 -0700 Message-ID: From: Ted Hardie To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a11c25b68a88202051a4b5a24 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 16:17:12 -0000 --001a11c25b68a88202051a4b5a24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 7, 2015 at 8:50 AM, Cullen Jennings wrote: > > I'd like to get a brief amount of agenda time to discuss changes we would > need to some of the WebRTC WG drafts to make the ideas proposed in > draft-jennings-behave-rtcweb-firewall- work and make people aware of this > work. > > Would it be possible to get 10 minutes on the agenda ? > > =E2=80=8BThere is time on day 2, at this point, so it shouldn't be a proble= m. Ted=E2=80=8B > Thanks, Cullen > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c25b68a88202051a4b5a24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 7, 2015 at 8:50 AM,= Cullen Jennings <fluffy@iii.ca> wrote:

I'd like to get a brief amount of agenda time to discuss changes we wou= ld need to some of the WebRTC WG drafts to make the ideas proposed in draft= -jennings-behave-rtcweb-firewall- work and make people aware of this work.<= br>
Would it be possible to get 10 minutes on the agenda ?


=E2=80=8BThere is time on day 2, at thi= s point, so it shouldn't be a problem.

Ted=E2=80= =8B


=C2=A0
Thanks, Cullen


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a11c25b68a88202051a4b5a24-- From nobody Tue Jul 7 14:52:17 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DEA1A004B for ; Tue, 7 Jul 2015 14:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeeF7oq5Xqrv for ; Tue, 7 Jul 2015 14:52:15 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A879A1AD35E for ; Tue, 7 Jul 2015 14:52:14 -0700 (PDT) Received: by wgjx7 with SMTP id x7so179384186wgj.2 for ; Tue, 07 Jul 2015 14:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nZxdK3jXZsRTrHACCrfIh9PMfhFZmie3sZ2LidfvR9c=; b=dx2neBmxxJUh9aGGHNalPJe9Hr+LAis3AbtIMNYR/hIMMNic1Hp52E7ZC2YVMKDtzn xZVNiu/e7s9NDiWvt0oKBWFzL/k312HIohPy3LrH+ckisO/CuP8rBGZjV6/m6BxFSQ40 7QFbPiAaWnmQtwkfSCQ8WhBVHdkOxiPcjRBgTW0hT8BeBYsekwKs+rc+kRXcms5C7faU KqtVCw0jRCRLA3Up+d/r35hgfaLCz46JQyCaPlhe8GYSovL6KT2GcSv6Kk/Q0cAMUJle 9NT3LOXcEwdND4s0TdWoe1q9AZEnQANAHDrdAHuMkS34fGwpDCuJ76qWWsGTVFN5/OKD 2n1A== MIME-Version: 1.0 X-Received: by 10.194.189.80 with SMTP id gg16mr12711672wjc.9.1436305933488; Tue, 07 Jul 2015 14:52:13 -0700 (PDT) Received: by 10.194.25.74 with HTTP; Tue, 7 Jul 2015 14:52:13 -0700 (PDT) Date: Tue, 7 Jul 2015 14:52:13 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb03f9cf457ff051a5008cb Archived-At: Subject: [rtcweb] PERC pointer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 21:52:16 -0000 --047d7bb03f9cf457ff051a5008cb Content-Type: text/plain; charset=UTF-8 With the approval of the PERC working group, there is now IETF activity on privacy enhanced RTP conferencing--including a draft on WebRTC: https://www.ietf.org/internet-drafts/draft-westerlund-perc-webrtc-use-case-00.txt They've requested agenda time for it in the PERC WG and discussion should probably be on that list. regards, Ted /no hat --047d7bb03f9cf457ff051a5008cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With the approval of the PERC working group, the= re is now IETF activity on privacy enhanced RTP conferencing--including a d= raft on WebRTC:

https://www.ietf.=
org/internet-drafts/draft-westerlund-perc-webrtc-use-case-00.txt
<= br>
They've requested agenda time for it in the PERC WG = and discussion should probably be on that list.

rega= rds,

Ted
/no hat
--047d7bb03f9cf457ff051a5008cb-- From nobody Wed Jul 8 07:40:20 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D087D1B3703 for ; Wed, 8 Jul 2015 07:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-ZVEw4gbMZB for ; Wed, 8 Jul 2015 07:40:17 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22DF1B36E3 for ; Wed, 8 Jul 2015 07:40:16 -0700 (PDT) Received: by wifm2 with SMTP id m2so91726025wif.1 for ; Wed, 08 Jul 2015 07:40:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oxe6a7O4VAS98vE9fJOWhqJGLPeLrxvRdRB7h0nNWZg=; b=ffV6RaLtOcQqkvnhxPlgdGCMn9A9VS2tT37QqLeM9q7YThlrTux9AJ9lZM+sLHWYig v9Mp+Wh/HqnnOeMzpkp0dMa7SKqNAHHgzFw0tDLDT8VWTp+SVVPNQ5qTq+h9R7qONt37 uHcXPNnUwaQXLhIunfdz5xJgyFdoKisZNOENxvXotPjznn3Un0NCc1yFA0uDo1GeZDaY 5QURWNVus5/W+D+4307tBWPvow3gfq+rgOCcRTnqRngz1E51BV6tTgfABqE22MiZazTQ y0Ysf8U3QPoTKlUjGAFotcf1AX1/qJgeQgA851Ex7dqn8GV3w8pf2I0WbsSbfFWoRycj n3Fg== X-Gm-Message-State: ALoCoQnO1eWuMr1PNUU7G1iBUCbMuUi/+X13LA7nwgogZUeZdOoJAPkd5RzveBWYCeJKd4W16p8V X-Received: by 10.194.133.73 with SMTP id pa9mr19968110wjb.148.1436366415317; Wed, 08 Jul 2015 07:40:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.95.211 with HTTP; Wed, 8 Jul 2015 07:39:35 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 8 Jul 2015 07:39:35 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=089e011771a9f3e0bc051a5e1d40 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 14:40:19 -0000 --089e011771a9f3e0bc051a5e1d40 Content-Type: text/plain; charset=UTF-8 I have taken a brief look at this draft and I don't believe that the proposed pinhole/inspection algorithm provides the desired assurances of verifying consent: 1. If you open up an incoming/outgoing pinhole on outgoing packet, prior to receiving an incoming STUN packet, then if the internal implementation simply sends a new outgoing STUN packet every 5 seconds, then they never need to rely on external consent. 2. If you just require *a* incoming STUN packet to be received in order to extend the lifetime to 30 seconds, then an off-path attacker can forge a STUN response that will cause the pinhole to be open for 30 seconds. (Hence the need for the STUN transaction ID). It seems to me that you should be instead requiring a complete STUN transaction before allowing any non-STUN outgoing traffic. It would probably be safe-ish to require it before allowing any incoming traffic as well, though that leaves the chance that you get a small amount of clipping with packet drops or reordering. WRT to the origin attribute, I have mixed feelings. I agree that your SNI argument is strong, but there is also a move to figure out how to encrypt SNI, so every time we extend that argument it makes that harder. OTOH, STUN origin will be sent a lot less often than SNI, I imagine. I don't understand Section 6. Is this guidance to firewall vendors or to browser implementors. If the former, the firewall has no way of knowing what "requests" are if the connection use HTTPS (and if is uses HTTP, you have DPI-type methods for determining whether something is voice or video. If this is guidance to browser vendors, I consider it extremely unlikely that we would implement it. Point #4 in your security considerations section seems like an entirely lost cause, unless you assume that attackers are not really trying. -Ekr On Tue, Jul 7, 2015 at 8:50 AM, Cullen Jennings wrote: > > I'd like to get a brief amount of agenda time to discuss changes we would > need to some of the WebRTC WG drafts to make the ideas proposed in > draft-jennings-behave-rtcweb-firewall- work and make people aware of this > work. > > Would it be possible to get 10 minutes on the agenda ? > > Thanks, Cullen > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e011771a9f3e0bc051a5e1d40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have taken a brief look at this draft and I don't be= lieve that the proposed pinhole/inspection
algorithm provides the desir= ed assurances of verifying consent:

1. If you open= up an incoming/outgoing pinhole on outgoing packet, prior to
rec= eiving an incoming STUN packet, then if the internal implementation
simply sends a new outgoing STUN packet every 5 seconds, then they
=
never need to rely on external consent.

2. If= you just require *a* incoming STUN packet to be received in order to
=
extend the lifetime to 30 seconds, then an off-path attacker can forge=
a STUN response that will cause the pinhole to be open for 30 se= conds.
(Hence the need for the STUN transaction ID).
It seems to me that you should be instead requiring a complete= STUN
transaction before allowing any non-STUN outgoing traffic. = It would probably
be safe-ish to require it before allowing any i= ncoming traffic as well, though
that leaves the chance that you g= et a small amount of clipping with packet
drops or reordering.


WRT to the origin attribute, I have m= ixed feelings. I agree that your SNI argument
is strong, but ther= e is also a move to figure out how to encrypt SNI, so every time
= we extend that argument it makes that harder. OTOH, STUN origin will be
sent a lot less often than SNI, I imagine.

=
I don't understand Section 6. Is this guidance to firewa= ll vendors or to browser
implementors. If the former, the firewal= l has no way of knowing what "requests"
are if the conn= ection use HTTPS (and if is uses HTTP, you have DPI-type methods for
<= div>determining whether something is voice or video. If this is guidance to= browser
vendors, I consider it extremely unlikely that we would = implement it.


Point #4 in your secu= rity considerations section seems like an entirely lost
cause, un= less you assume that attackers are not really trying.

<= div>-Ekr




<= div>




<= /div>

On Tue, Jul = 7, 2015 at 8:50 AM, Cullen Jennings <fluffy@iii.ca> wrote:

I'd like to get a brief amount of agenda time to discuss changes we wou= ld need to some of the WebRTC WG drafts to make the ideas proposed in draft= -jennings-behave-rtcweb-firewall- work and make people aware of this work.<= br>
Would it be possible to get 10 minutes on the agenda ?

Thanks, Cullen


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--089e011771a9f3e0bc051a5e1d40-- From nobody Wed Jul 8 19:34:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6171A89FD for ; Wed, 8 Jul 2015 19:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uybWrwbzzJcw for ; Wed, 8 Jul 2015 19:34:19 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927831A89FF for ; Wed, 8 Jul 2015 19:34:19 -0700 (PDT) Received: by iecvh10 with SMTP id vh10so168333510iec.3 for ; Wed, 08 Jul 2015 19:34:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ojz1AbpKi/43Z6oTyJ/HmKON4WuQbE5YnAH00jCj/1Q=; b=jYTHmjXHIZEEtU3pT7jeqZaztVgBp0oHLdObDva/NGyI2x1GsFcDrLa3Yg/R+IPnCy e7YpVtnoUcNtotiAjM9ROJLa+RxfAk0YdwnaO1F8ADRNXqqw4VgqCyhjGd+c//6cqt66 9QgKR3nGFaiZ490gnHd1tKtvCoU8S+37+6oIx++L0BcoMWqoBRNqbRgZwPwgHkquOLQ6 BbW/vLUOcYqU2xFnNX4gcT9H9m7onexgaHkDUnugk16PeG1lXmoTkXH7WmDRyYhdHLbM V+XxbG6BJQH7/tJFA5yPz25mi1QdalDo5j5PqGBBcOHiOdGyjyJASv7TYAUM9zpz+GXY EDxw== X-Gm-Message-State: ALoCoQl9UaAwEpzoSDfkVGzt1gvw/24+o+Mlab93a+oWJ7lR4zM5j8wS0yTSlSY4sefCD2ps19Ve X-Received: by 10.107.129.230 with SMTP id l99mr22038103ioi.32.1436409259038; Wed, 08 Jul 2015 19:34:19 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:809f:b8f2:df6f:f59a]) by smtp.googlemail.com with ESMTPSA id n6sm15606902igv.17.2015.07.08.19.34.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 19:34:17 -0700 (PDT) Message-ID: <559DDDA7.4030901@andyet.net> Date: Wed, 08 Jul 2015 20:34:15 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] two questions about draft-ietf-rtcweb-return X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 02:34:21 -0000 First, this is a great document - very clear and easy to read. Kudos to the authors! I have two questions. 1. Section 4.2 states: A virtual interface can produce "host", "server-reflexive", and "relay" candidates, but may be restricted to only some type of candidate (e.g. UDP-only). How does that restriction work? Is it effected by the nature of the firewall (e.g., Section 6.1 mentions the possibility of a firewall that blocks all UDP traffic), by the configuration of the TURN proxy, by local policy in the WebRTC user agent, or by some other method? 2. Section 5.1 states: When a proxy is configured, by Auto-Discovery or a proprietary means, the browser MUST NOT report a "relay" candidate representing the proxy. [...] For a virtual interface representing a TURN proxy, this means that the browser MUST report the public-facing IP address and port acquired through TURN as a "host" candidate.... Have the authors considered how that rule might interact with the known (although poorly documented) improvement in call setup time that results from communicating only relayed candidates in the initial offer? Thanks! Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Jul 9 07:21:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841831A92B8 for ; Thu, 9 Jul 2015 07:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSru2LVZhFsi for ; Thu, 9 Jul 2015 07:21:37 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5823C1A92E1 for ; Thu, 9 Jul 2015 07:21:37 -0700 (PDT) Received: by igrv9 with SMTP id v9so224722428igr.1 for ; Thu, 09 Jul 2015 07:21:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FmR/HWGzxQA3yQ8lGD9jNspX8rvCINXWlhbVRcFqAP8=; b=UFPIEQTO1S0xTy5epnn1RsQSmW7BPaTJl4k0rpUHeUTW/CW32UrePXerf2i8doWzQE tc0BcSElXYulWSBqWm8P3+dkwxF+WHVyrPt7n031J8+SnmmGKQl3/FrBN5xLJuE86H0f Y3zkhRIAxwpGS1I1j+RlNzaa7iMgzmg/WVJEcOJEtzwuBlu/XhH4GNFXBvr23PYZEQRz SXxLYLhX7/waOmdxD4NSvq8ysGJzQMSO5agD0wmOcUYr+Wi6Ax9bZyRgyf+0EzcChnLd jHtFbPp61iUUSCRlu0NOtYntFPn0g02+10aDqSzQr9CEQnB0RHUpNzO/PIkC7eEUhxVO Z7Yg== X-Gm-Message-State: ALoCoQkEQ5mMSVGsDLe9A7rhrxBM+s7cyafoyYMGyH3Ud4bgBLVBtLz0rsvXwQ9NZz/f84p4lPh8 X-Received: by 10.50.39.20 with SMTP id l20mr440608igk.77.1436451696781; Thu, 09 Jul 2015 07:21:36 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by smtp.gmail.com with ESMTPSA id s5sm4351930igh.6.2015.07.09.07.21.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2015 07:21:35 -0700 (PDT) Received: by iggp10 with SMTP id p10so14932148igg.0 for ; Thu, 09 Jul 2015 07:21:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.7.104 with SMTP id i8mr434034iga.50.1436451694384; Thu, 09 Jul 2015 07:21:34 -0700 (PDT) Received: by 10.64.171.114 with HTTP; Thu, 9 Jul 2015 07:21:34 -0700 (PDT) In-Reply-To: <559DDDA7.4030901@andyet.net> References: <559DDDA7.4030901@andyet.net> Date: Thu, 9 Jul 2015 10:21:34 -0400 Message-ID: From: Benjamin Schwartz To: "Peter Saint-Andre - &yet" Content-Type: multipart/alternative; boundary=089e01183ebcfb5758051a71f878 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] two questions about draft-ietf-rtcweb-return X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 14:21:39 -0000 --089e01183ebcfb5758051a71f878 Content-Type: text/plain; charset=UTF-8 ]On Wed, Jul 8, 2015 at 10:34 PM, Peter Saint-Andre - &yet wrote: > First, this is a great document - very clear and easy to read. Kudos to > the authors! > Thanks! > I have two questions. > > 1. Section 4.2 states: > > A virtual interface can produce > "host", "server-reflexive", and "relay" candidates, but may be > restricted to only some type of candidate (e.g. UDP-only). > > How does that restriction work? Is it effected by the nature of the > firewall (e.g., Section 6.1 mentions the possibility of a firewall that > blocks all UDP traffic), by the configuration of the TURN proxy, by local > policy in the WebRTC user agent, or by some other method? > I would say "by the configuration of the TURN proxy". This statement was intended to be just a helpful reinforcement of the obvious: if a virtual interface represents paths through a TURN proxy, and the proxy is UDP-only (like most TURN implementations), then no TCP candidates will be generated for that interface. As always, language improvements welcome. > > 2. Section 5.1 states: > > When a proxy is configured, by Auto-Discovery or a proprietary means, > the browser MUST NOT report a "relay" candidate representing the > proxy. [...] > > For a virtual interface representing a TURN proxy, this means that > the browser MUST report the public-facing IP address and port > acquired through TURN as a "host" candidate.... > > Have the authors considered how that rule might interact with the known > (although poorly documented) improvement in call setup time that results > from communicating only relayed candidates in the initial offer? > My impression is that this improvement is only true when there are no publicly routable "host" candidates. If the proxy has a publicly routable external interface (as seems likely to be the common case), then I expect there should be no performance issue. This does suggest a discussion of how best to compute priority of these candidates, but I view that kind of performance tuning as a secondary concern. > > Thanks! > > Peter > > -- > Peter Saint-Andre > https://andyet.com/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e01183ebcfb5758051a71f878 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
]On = Wed, Jul 8, 2015 at 10:34 PM, Peter Saint-Andre - &yet <peter@andyet.ne= t> wrote:
First, this is a = great document - very clear and easy to read. Kudos to the authors!

Thanks!
=C2=A0
I have two questions.

1. Section 4.2 states:

=C2=A0 =C2=A0A virtual interface can produce
=C2=A0 =C2=A0"host", "server-reflexive", and "rela= y" candidates, but may be
=C2=A0 =C2=A0restricted to only some type of candidate (e.g.=C2=A0 UDP-only= ).

How does that restriction work? Is it effected by the nature of the firewal= l (e.g., Section 6.1 mentions the possibility of a firewall that blocks all= UDP traffic), by the configuration of the TURN proxy, by local policy in t= he WebRTC user agent, or by some other method?

I would say "by the configuration of the TURN proxy".=C2= =A0 This statement was intended to be just a helpful reinforcement of the o= bvious: if a virtual interface represents paths through a TURN proxy, and t= he proxy is UDP-only (like most TURN implementations), then no TCP candidat= es will be generated for that interface.

As always= , language improvements welcome.
=C2=A0

2. Section 5.1 states:

=C2=A0 =C2=A0When a proxy is configured, by Auto-Discovery or a proprietary= means,
=C2=A0 =C2=A0the browser MUST NOT report a "relay" candidate repr= esenting the
=C2=A0 =C2=A0proxy.=C2=A0 [...]

=C2=A0 =C2=A0For a virtual interface representing a TURN proxy, this means = that
=C2=A0 =C2=A0the browser MUST report the public-facing IP address and port<= br> =C2=A0 =C2=A0acquired through TURN as a "host" candidate....

Have the authors considered how that rule might interact with the known (al= though poorly documented) improvement in call setup time that results from = communicating only relayed candidates in the initial offer?

My impression is that this improvement is only true wh= en there are no publicly routable "host" candidates.=C2=A0 If the= proxy has a publicly routable external interface (as seems likely to be th= e common case), then I expect there should be no performance issue.

This does suggest a discussion of how best to compute pri= ority of these candidates, but I view that kind of performance tuning as a = secondary concern.
=C2=A0

Thanks!

Peter

--
Peter Saint-Andre
https:= //andyet.com/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--089e01183ebcfb5758051a71f878-- From nobody Thu Jul 9 07:53:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA3B1B2A3C for ; Thu, 9 Jul 2015 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyDsEzsgUAy2 for ; Thu, 9 Jul 2015 07:53:24 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EFAD1B2A3A for ; Thu, 9 Jul 2015 07:53:24 -0700 (PDT) Received: by obbgp5 with SMTP id gp5so60971682obb.0 for ; Thu, 09 Jul 2015 07:53:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MFW7+tqZzAfrrO3HMu24f+ndeRurhXv4dLWLF8GOvC4=; b=I8UgipHua2xK+BHSoXMdS9UHJj8ZhcITKSB+8N/FI3TqqfweI7PYq51Bc2PB0WfAys OxTzPYmKTKVcj5rEtwBstDQ8azgu82LKIRE50/hK7T1Dkc9b3UWkqjdlblE3MG5ZZsw/ 8Gp2Bbq0zkZypqS/tf+z9u++psXksgyMjuUs87SI+SC3R1PjJNcN9vhXAy7tCosGfblK nww+LkldEoPk6nuhdtcPSefU/PqlA0oWvSZ9h0pNMNRjEvI3kSjz4kgHz8nUDaFnX01y oK/9+7SIheoJEB8YSUTvF2CKMNUs1P9JLLGStk6eOpypWwwtZ3ppYtJC5DKrpWx0KAR8 zFeg== X-Gm-Message-State: ALoCoQnm1Lflc9CdHRQ5vM9AJuTDTi3w8STZkc84BlNQ6/6g4nVYBAvyCsMWkDdmvaVqZY0e5tG1 X-Received: by 10.202.204.78 with SMTP id c75mr5230866oig.12.1436453603836; Thu, 09 Jul 2015 07:53:23 -0700 (PDT) Received: from [192.168.1.44] ([24.53.47.130]) by smtp.googlemail.com with ESMTPSA id pn16sm2849789oeb.16.2015.07.09.07.53.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2015 07:53:22 -0700 (PDT) Message-ID: <559E8ADF.1030405@jive.com> Date: Thu, 09 Jul 2015 10:53:19 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Benjamin Schwartz , Peter Saint-Andre - &yet References: <559DDDA7.4030901@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] two questions about draft-ietf-rtcweb-return X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 14:53:25 -0000 Le 2015-07-09 10:21, Benjamin Schwartz a écrit : > How does that restriction work? Is it effected by the nature of the > firewall (e.g., Section 6.1 mentions the possibility of a firewall > that blocks all UDP traffic), by the configuration of the TURN > proxy, by local policy in the WebRTC user agent, or by some other > method? > > > I would say "by the configuration of the TURN proxy". This statement > was intended to be just a helpful reinforcement of the obvious: if a > virtual interface represents paths through a TURN proxy, and the proxy > is UDP-only (like most TURN implementations), then no TCP candidates > will be generated for that interface. > > As always, language improvements welcome. Ok then here's one: "TURN server" is the preferred term, instead of "TURN proxy". :) > Have the authors considered how that rule might interact with the > known (although poorly documented) improvement in call setup time > that results from communicating only relayed candidates in the > initial offer? > > > My impression is that this improvement is only true when there are no > publicly routable "host" candidates. If the proxy has a publicly > routable external interface (as seems likely to be the common case), > then I expect there should be no performance issue. I don't think that this is even true. I bet that most of the time when you have a publicly routable "host" candidate you will still be behind a NAT or a stateful firewall, and inbound connections will still be denied. The IP address range means very little. The fact is that we have ICE prioritization completely wrong. See RFC 5245 section 4.1.2.2 and note that the guidelines listed there relate to steady-state performance. That is worthless. Nomination is what is concerned with steady-state performance. Prioritization should only be concerned with how long it takes until I have a working candidate pair. This means that candidates with the highest chance of working and the lowest expected setup time should be tried first. That's probably TURN candidates. As soon as you have something that works you can start using it. Then you can take your time and evaluate the other candidate pairs more-or-less in depth, perhaps do some actual measurements, then nominate the candidate pair that has the best steady-state performance. Simon From nobody Sat Jul 11 09:43:02 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16EB1A9004 for ; Sat, 11 Jul 2015 09:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQEdAO9a0IN2 for ; Sat, 11 Jul 2015 09:43:00 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DA01A8FD5 for ; Sat, 11 Jul 2015 09:43:00 -0700 (PDT) Received: by qkdv3 with SMTP id v3so31278005qkd.3 for ; Sat, 11 Jul 2015 09:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=iAt8icM0CXjgOCiZD1Iece40aVG+Y1EXKp31lbPVLhY=; b=U7QboQLfn3pHyG7v81YcX5W3njYp3mWFjJQzCFbdm59Pa7UPdJp2Etqg4al7hzf2o0 UHH/atO2GA3EwGa3JBZafoqxhqiw7VDhCh6kEb65GDxPiJ7Co88V5iJSgsuOj5MhG4H8 qsbNzJnnD238HhWzptcKoEGxTcXbyfkKzTAcTPJgGUL5PPow3uB1AXXkv/UuboZ2qDNO LFb3i7ZmajjSAor/v49M1V9DlyZyup6OH1w9FU0ZqNSDnElW56mc8t1AU02yYl2EHH6T rK9IWqS6noKKF2yv5hfZlfNQDIXETAHJESb8eG/cnRQbeQyV9wO5SGhLvBoWmcrwKLOn 5oyg== X-Received: by 10.55.31.85 with SMTP id f82mr40764734qkf.88.1436632979319; Sat, 11 Jul 2015 09:42:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.130 with HTTP; Sat, 11 Jul 2015 09:42:29 -0700 (PDT) From: Daniel Roesler Date: Sat, 11 Jul 2015 09:42:29 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 16:43:01 -0000 Howdy all, this is mostly a re-surfacing of the discussion about IP address leaking back in April[1], which unfortunately I did not discover until recently. One of the items in the new proposal was "WebRTC already requires permission to access getUserMedia. Why not use that permission to control interface enumeration?" That item didn't really get discussed much in the thread, but I think it's one of the most important issues. Why? There is now a documented case where a third party on nytimes.com is using a fake webRTC datachannel to silently gather user local (and potentially "real" ISP) IP addresses. https://twitter.com/incloud/status/619624021123010560 So I'd like to voice my support for adding a consent requirement that would prevent this type of silent behavior. A user that is purposefully visiting a site that has a legitimate reason for using a webRTC data channel will have the necessary context to give consent, just like they have to get consent on getUserMedia. I'm really unclear on why it's so important to have the silent webRTC data channel behavior. P2P data connections should be held to the same consent requirements just like P2P video and voice connections. In addition to the silent third party local IP tracking, a silent P2P data channel opens up users to silently becoming nodes in a web-based file sharing network. For example, webtorrent[2] can be silently embedded on a website so that all of the users to that website start seeding content they don't know they are seeding. Possible fix: 1. Require user consent before calling the callback on createOffer(). 2. If the user has already given consent via getUserMedia, the user consent requirement is satisfied. 3. If there's no previous gUM consent, then ask the user for consent. This implementation requires no updates to current webRTC demos, since you have to wait for a callback on createOffer anyway. I'm open to other ways, such as making createDataChannel asynchronous like gUM, but that would require updates to existing apps that use createDataChannel. Thanks! Daniel Roesler [1]: https://www.ietf.org/mail-archive/web/rtcweb/current/msg14494.htm [2]: https://github.com/feross/webtorrent From nobody Sat Jul 11 21:26:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83381A1A5D for ; Sat, 11 Jul 2015 21:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL-PCT75liS9 for ; Sat, 11 Jul 2015 21:26:30 -0700 (PDT) Received: from mail.eeph.com (mail.eeph.com [IPv6:2001:470:826a:d2::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6EC1A1A5B for ; Sat, 11 Jul 2015 21:26:30 -0700 (PDT) Received: from [IPv6:2001:470:826a:d0:d5fe:6e06:c62e:6418] (unknown [IPv6:2001:470:826a:d0:d5fe:6e06:c62e:6418]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id E4B792A334D for ; Sat, 11 Jul 2015 21:26:29 -0700 (PDT) Message-ID: <55A1EC76.4030802@matthew.at> Date: Sat, 11 Jul 2015 21:26:30 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 04:26:31 -0000 On 7/11/2015 9:42 AM, Daniel Roesler wrote: > Howdy all, this is mostly a re-surfacing of the discussion about IP > address leaking back in April[1], which unfortunately I did not > discover until recently. > > One of the items in the new proposal was "WebRTC already requires > permission to access getUserMedia. Why not use that permission to > control interface enumeration?" That item didn't really get discussed > much in the thread, but I think it's one of the most important issues. > > Why? There is now a documented case where a third party on nytimes.com > is using a fake webRTC datachannel to silently gather user local (and > potentially "real" ISP) IP addresses. > ... On the IPv6 Internet, the IP address you use to reach the web site is almost certainly the same as your "local" IP address. There's no additional information exposed by allowing an application to discover that information directly via JavaScript. The IPv4 Internet is essentially out of addresses and in the process of being retired. I don't believe there's any reason at this point to disable functionality in order to improve compatibility with this legacy network. Matthew Kaufman ps. You can also gather all these addresses for any browser with Flash Player installed by asking Flash to connect via RTMFP to a server, whereupon it will report the full enumeration of available IPv4 and IPv6 addresses to that server. From nobody Sun Jul 12 01:49:34 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AAB1A8739 for ; Sun, 12 Jul 2015 01:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHMsDYYfyFQW for ; Sun, 12 Jul 2015 01:49:30 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88661A702D for ; Sun, 12 Jul 2015 01:49:29 -0700 (PDT) Received: by wgkl9 with SMTP id l9so5817956wgk.1 for ; Sun, 12 Jul 2015 01:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=0SoOUvQLSTVjykbPSECtbf7hHNg+ODqVEv5htxKgBSQ=; b=NgvsPVBO7IiHtOhVh5lZHrLFkBmOr7ObzPs0VesNlGrTsr7duJR+oSWJuEqt5FHDfI ULKAB+jiSPTqlxfcdO/ayPOuWOwgKbbkP7jq87PP49rwpVqm4oSInZQm+0gfCoGRbFvp 4E5guQKYXmMWjHc8oMSpOuSkq6E+VqTkJywc8gOqPFrDrYKq3sLGB/m6Sr9tUJf791qU 2uM40Fmpp+6/jfDyZQziUMrUGE/dullBwPfrkuwxLnIIcjK7ljORqPY9gXde2vqQF3W+ SLtrd8LUK14N4mn0td+vy5tS6UVCSyrQ43k+j6n9ko4yNqhIfb+oO1vIUqekLR8i91pb qGvA== X-Received: by 10.194.250.69 with SMTP id za5mr21230227wjc.90.1436690968682; Sun, 12 Jul 2015 01:49:28 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by smtp.googlemail.com with ESMTPSA id ck7sm22166178wjc.43.2015.07.12.01.49.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jul 2015 01:49:27 -0700 (PDT) To: rtcweb@ietf.org References: From: Sergio Garcia Murillo Message-ID: <55A22A1B.4000202@gmail.com> Date: Sun, 12 Jul 2015 10:49:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 08:49:32 -0000 Hi, While acknowledging that there might be a potential privacy issue, I don't think agree on your analysis on the issue that you have made nor your proposal. The information available in the ICE gathering process and made available to the JS app is the following: -Host candidates, mostly private IP addresses -Server reflexive candidates, exposing the public IP address as shown by the TURN/STUN server -Relay candidates, hosted by the TURN server My understanding of the issue is that the leak happens when the application is able to retrieve information not already available to it. That happens either when the user is using a VPN and have multiple public IP addresses or using an external PROXY so the http/ws connection have a different originator public IP address. AFAIK there should be no potential danger in leaking the private IP4 addresses (here you got mine, in case you are interested 127.0.0.1 and 192.168.64.2 ;). I have not much background on IPv6, so please complete any missing info and how would it affect here. I don't think it is a good idea to tight the solution of requesting user permission, to not leak IP information, as theoretically a user could be interested in using webrtc (audio/video/datachannels) and still don't disclose their public IP address (i.e. forcing all the data to go via a TURN server). One possible solution would be that the browser don't gather/announce host&reflexive candidates when an HTTP proxy is set, and only use turn relay candidates instead. The second solution (which I think it is already discussed somewhere else) would be to allow the user to configure a TURN server to override the app settings and force all connection to go through it. (Then build a chained-TURN infrastructure into TOR and you could have a killer combo ;) Regarding the issue that the browser becomes a CDN peer, not sure if anyone has ever raised the issue before. From my point of view, there is not, but in any case, I think it is orthogonal to the leak issue. Best regards Sergio On 11/07/2015 18:42, Daniel Roesler wrote: > Howdy all, this is mostly a re-surfacing of the discussion about IP > address leaking back in April[1], which unfortunately I did not > discover until recently. > > One of the items in the new proposal was "WebRTC already requires > permission to access getUserMedia. Why not use that permission to > control interface enumeration?" That item didn't really get discussed > much in the thread, but I think it's one of the most important issues. > > Why? There is now a documented case where a third party on nytimes.com > is using a fake webRTC datachannel to silently gather user local (and > potentially "real" ISP) IP addresses. > > https://twitter.com/incloud/status/619624021123010560 > > So I'd like to voice my support for adding a consent requirement that > would prevent this type of silent behavior. A user that is > purposefully visiting a site that has a legitimate reason for using a > webRTC data channel will have the necessary context to give consent, > just like they have to get consent on getUserMedia. > > I'm really unclear on why it's so important to have the silent webRTC > data channel behavior. P2P data connections should be held to the same > consent requirements just like P2P video and voice connections. In > addition to the silent third party local IP tracking, a silent P2P > data channel opens up users to silently becoming nodes in a web-based > file sharing network. For example, webtorrent[2] can be silently > embedded on a website so that all of the users to that website start > seeding content they don't know they are seeding. > > Possible fix: > > 1. Require user consent before calling the callback on createOffer(). > 2. If the user has already given consent via getUserMedia, the user > consent requirement is satisfied. > 3. If there's no previous gUM consent, then ask the user for consent. > > This implementation requires no updates to current webRTC demos, since > you have to wait for a callback on createOffer anyway. I'm open to > other ways, such as making createDataChannel asynchronous like gUM, > but that would require updates to existing apps that use > createDataChannel. > > Thanks! > Daniel Roesler > > [1]: https://www.ietf.org/mail-archive/web/rtcweb/current/msg14494.htm > [2]: https://github.com/feross/webtorrent > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Jul 12 12:19:37 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37081A883F for ; Sun, 12 Jul 2015 12:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3ld-P7XTkNi for ; Sun, 12 Jul 2015 12:19:34 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF63E1A87F2 for ; Sun, 12 Jul 2015 12:19:33 -0700 (PDT) Received: by qget71 with SMTP id t71so148556894qge.2 for ; Sun, 12 Jul 2015 12:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9JPMeDj7yGKnmmjYHlwYtt5SQkUIvqxqmhZCt35Z4Qc=; b=ykEfzEIwUWt1BnS1pi3aa60RG111DX522wSI2vYtrBi6bdV4O8/I1l+Bg6FsOPXySt FuXJEmU4H2xIg5Oe3TXIbJage/DWeTnyNjTuOpwqgSkhwaeGsiw1RcbLq1AnJVjqBUTj ZXcNRI0TFFX8VPf6E5Fl9ANm8HeJ10LTgeDBuo3ZsBxrYR6slDEmKB6VxuaxFXk7fEAd AXW4hZ9hJ+iHu/ln7edb9oCLhMHtf4oDU0ijFLnCbthjuC48G98DKx8TMQA2TCxgWGoz y2qAK1L0GUIc7y9JftOUVwVt8iB9ThwehJfdA9D/puwkanZOa0ahXsP4pKSQ9QzrB4zc WPgQ== X-Received: by 10.140.32.38 with SMTP id g35mr47614075qgg.74.1436728773050; Sun, 12 Jul 2015 12:19:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.130 with HTTP; Sun, 12 Jul 2015 12:19:03 -0700 (PDT) In-Reply-To: <55A22A1B.4000202@gmail.com> References: <55A22A1B.4000202@gmail.com> From: Daniel Roesler Date: Sun, 12 Jul 2015 12:19:03 -0700 Message-ID: To: Sergio Garcia Murillo , Matthew Kaufman Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 19:19:37 -0000 Thanks very much for the responses! Going to try and address both inline below. On Sat, Jul 11, 2015 at 9:26 PM, Matthew Kaufman wrote: > > On the IPv6 Internet, the IP address you use to reach the web site is almost > certainly the same as your "local" IP address. There's no additional > information exposed by allowing an application to discover that information > directly via JavaScript. > > The IPv4 Internet is essentially out of addresses and in the process of > being retired. I don't believe there's any reason at this point to disable > functionality in order to improve compatibility with this legacy network. > I disagree with this sentiment. IPv4 will be around for many more years and many ISPs still do not assign their customers IPv6 addresses. If IPv6 is replacing IPv4 so readily, why not only offer WebRTC through IPv6? It's a huge double standard to say that we won't support privacy issues of one network while at the same time supporting connectivity though it. > > ps. You can also gather all these addresses for any browser with Flash > Player installed by asking Flash to connect via RTMFP to a server, whereupon > it will report the full enumeration of available IPv4 and IPv6 addresses to > that server. Yes, however flash can easily be blocked using click-to-enable (i.e. user consent) and will not be installed on the majority of modern browsers (mobile devices). WebRTC will be. What I'm asking for here is a similar flash-blocking behavior to what is possible in Chromium (built-in setting) and Firefox (via FlashBlock addons), so that users can choose to click-to-enable based on context (just like they need to already in getUserMedia). On Sun, Jul 12, 2015 at 1:49 AM, Sergio Garcia Murillo wrote: > Hi, > > While acknowledging that there might be a potential privacy issue, I don't > think agree on your analysis on the issue that you have made nor your > proposal. I'd like to strongly encourage everyone here to stop treating this issue as "might be a potential privacy issue". There have been numerous news articles[1][2][3][4], discussion by VPNs/Tor[5][6][7][8], my github proof-of-concept has over 1,500 stars and 195 forks[9], the Mozilla Firefox bug has over 100 comments and is marked as sec-moderate[10], and we are now seeing it exploited in the wild to detect VPN users[11]. This is not "might be a potential privacy issue". This is an existing, significant privacy issue. [1]: https://torrentfreak.com/huge-security-flaw-leaks-vpn-users-real-ip-addresses-150130/ [2]: http://lifehacker.com/how-to-see-if-your-vpn-is-leaking-your-ip-address-and-1685180082 [3]: https://threatpost.com/webrtc-found-leaking-local-ip-addresses/110803 [4]: http://news.softpedia.com/news/WebRTC-in-Firefox-and-Chrome-Reveals-IPs-Behind-VPN-471881.shtml [5]: https://www.expressvpn.com/blog/explaining-webrtc-ip-leak-vulnerability-affecting-web-browsers/ [6]: https://trac.torproject.org/projects/tor/ticket/5578 [7]: https://ipleak.net/ [8]: https://www.privateinternetaccess.com/forum/discussion/8204/ [9]: https://github.com/diafygi/webrtc-ips [10]: https://bugzilla.mozilla.org/show_bug.cgi?id=959893 [11]: https://twitter.com/incloud/status/619624021123010560 > > The information available in the ICE gathering process and made available to > the JS app is the following: > > -Host candidates, mostly private IP addresses > -Server reflexive candidates, exposing the public IP address as shown by the > TURN/STUN server > -Relay candidates, hosted by the TURN server > > My understanding of the issue is that the leak happens when the application > is able to retrieve information not already available to it. > That happens either when the user is using a VPN and have multiple public IP > addresses or using an external PROXY so the http/ws connection have a > different originator public IP address. AFAIK there should be no potential > danger in leaking the private IP4 addresses (here you got mine, in case you > are interested 127.0.0.1 and 192.168.64.2 ;). I have not much background on > IPv6, so please complete any missing info and how would it affect here. If you read the above articles and discussion surrounding the leak. The concern is not around local or private IPs, it's around public IPs for VPN users. Personal VPN use is extremely widespread internationally, mostly for censorship and content-blocking circumvention. Chinese users use them to get around the great firewall. Australian users use them to be able to watch Netflix. Tor is often not a suitable option because the web service they are trying to reach blocks Tor (e.g. bank website) or is too data heavy (e.g. streaming video). >From the popularity of the issue, it's clear that the vast majority of users thought that using a VPN hid their real IP address from the websites they were visiting. It has been a huge shock (including for me) that default VPN configurations let the browser (and thus WebRC) know the real IP. Is that an operating system or VPN software issue? Either way, due to WebRTC this real IP access issue has now spread to javascript, so that any website can access your real IP. "AFAIK there should be no potential danger in leaking the private IP4 addresses" Here's a real-life example of the danger this has. China started injecting malicious javascript into people's Baidu searches when those searches came from outside China[12]. This was used to DDOS Github, but what if that javascript contained a webrtc data channel setup? All of a sudden, China could obtain the real Chinese IPs of citizens who were using VPNs. The result of this could definitely be life-threatening. Again, just saying "use Tor" means those citizens cannot use many modern internet services (especially streaming video). Personal VPNs are a fantastic compromise that provide access at quite good speeds while retaining a good-enough-for-Netflix level or privacy. WebRTC's real IP leaking removes this middle ground compromise. [12]: http://arstechnica.com/security/2015/03/github-battles-largest-ddos-in-sites-history-targeted-at-anti-censorship-tools/ > > I don't think it is a good idea to tight the solution of requesting user > permission, to not leak IP information, as theoretically a user could be > interested in using webrtc (audio/video/datachannels) and still don't > disclose their public IP address (i.e. forcing all the data to go via a TURN > server). > > One possible solution would be that the browser don't gather/announce > host&reflexive candidates when an HTTP proxy is set, and only use turn relay > candidates instead. The second solution (which I think it is already > discussed somewhere else) would be to allow the user to configure a TURN > server to override the app settings and force all connection to go through > it. (Then build a chained-TURN infrastructure into TOR and you could have a > killer combo ;) I'm fully supportive of removing the real IPs from the onicecandidate results. However, as we saw in April's discussion thread and now in this thread, identifying that IP is a complex topic that likely doesn't have an easy answer and might require significant browser or operating system-level changes. So, I'm suggesting here that an easier solution is to make data channels require user-consent (again, just like what already happens with audio and video channels). > > Regarding the issue that the browser becomes a CDN peer, not sure if anyone > has ever raised the issue before. From my point of view, there is not, but > in any case, I think it is orthogonal to the leak issue. It is orthogonal to the privacy issue, but this user-consent proposal also helps address this issue, too. Thanks again for the responses! Daniel From nobody Sun Jul 12 12:36:04 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1406E1A8892 for ; Sun, 12 Jul 2015 12:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKMIVGj2D6IJ for ; Sun, 12 Jul 2015 12:36:00 -0700 (PDT) Received: from smtpcmd01231.aruba.it (smtpcmd01231.aruba.it [62.149.158.231]) by ietfa.amsl.com (Postfix) with ESMTP id B18A61A888A for ; Sun, 12 Jul 2015 12:35:59 -0700 (PDT) Received: from rainpc ([80.116.203.23]) by smtpcmd01.ad.aruba.it with bizsmtp id rXbw1q0090WoBYY01Xbws7; Sun, 12 Jul 2015 21:35:57 +0200 Date: Sun, 12 Jul 2015 21:35:56 +0200 From: Lorenzo Miniero To: Daniel Roesler Message-ID: <20150712213556.19f6a696@rainpc> In-Reply-To: References: <55A22A1B.4000202@gmail.com> Organization: Meetecho X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 19:36:03 -0000 On Sun, 12 Jul 2015 12:19:03 -0700 Daniel Roesler wrote: > Thanks very much for the responses! Going to try and address both inline below. > > On Sat, Jul 11, 2015 at 9:26 PM, Matthew Kaufman wrote: > > > > On the IPv6 Internet, the IP address you use to reach the web site is almost > > certainly the same as your "local" IP address. There's no additional > > information exposed by allowing an application to discover that information > > directly via JavaScript. > > > > The IPv4 Internet is essentially out of addresses and in the process of > > being retired. I don't believe there's any reason at this point to disable > > functionality in order to improve compatibility with this legacy network. > > > > I disagree with this sentiment. IPv4 will be around for many more > years and many ISPs still do not assign their customers IPv6 > addresses. If IPv6 is replacing IPv4 so readily, why not only offer > WebRTC through IPv6? It's a huge double standard to say that we won't > support privacy issues of one network while at the same time > supporting connectivity though it. > > > > > ps. You can also gather all these addresses for any browser with Flash > > Player installed by asking Flash to connect via RTMFP to a server, whereupon > > it will report the full enumeration of available IPv4 and IPv6 addresses to > > that server. > > Yes, however flash can easily be blocked using click-to-enable (i.e. > user consent) and will not be installed on the majority of modern > browsers (mobile devices). WebRTC will be. What I'm asking for here is > a similar flash-blocking behavior to what is possible in Chromium > (built-in setting) and Firefox (via FlashBlock addons), so that users > can choose to click-to-enable based on context (just like they need to > already in getUserMedia). > > On Sun, Jul 12, 2015 at 1:49 AM, Sergio Garcia Murillo > wrote: > > Hi, > > > > While acknowledging that there might be a potential privacy issue, I don't > > think agree on your analysis on the issue that you have made nor your > > proposal. > > I'd like to strongly encourage everyone here to stop treating this > issue as "might be a potential privacy issue". There have been > numerous news articles[1][2][3][4], discussion by > VPNs/Tor[5][6][7][8], my github proof-of-concept has over 1,500 stars > and 195 forks[9], the Mozilla Firefox bug has over 100 comments and is > marked as sec-moderate[10], and we are now seeing it exploited in the > wild to detect VPN users[11]. This is not "might be a potential > privacy issue". This is an existing, significant privacy issue. > > [1]: https://torrentfreak.com/huge-security-flaw-leaks-vpn-users-real-ip-addresses-150130/ > [2]: http://lifehacker.com/how-to-see-if-your-vpn-is-leaking-your-ip-address-and-1685180082 > [3]: https://threatpost.com/webrtc-found-leaking-local-ip-addresses/110803 > [4]: http://news.softpedia.com/news/WebRTC-in-Firefox-and-Chrome-Reveals-IPs-Behind-VPN-471881.shtml > [5]: https://www.expressvpn.com/blog/explaining-webrtc-ip-leak-vulnerability-affecting-web-browsers/ > [6]: https://trac.torproject.org/projects/tor/ticket/5578 > [7]: https://ipleak.net/ > [8]: https://www.privateinternetaccess.com/forum/discussion/8204/ > [9]: https://github.com/diafygi/webrtc-ips > [10]: https://bugzilla.mozilla.org/show_bug.cgi?id=959893 > [11]: https://twitter.com/incloud/status/619624021123010560 > > > > > The information available in the ICE gathering process and made available to > > the JS app is the following: > > > > -Host candidates, mostly private IP addresses > > -Server reflexive candidates, exposing the public IP address as shown by the > > TURN/STUN server > > -Relay candidates, hosted by the TURN server > > > > My understanding of the issue is that the leak happens when the application > > is able to retrieve information not already available to it. > > That happens either when the user is using a VPN and have multiple public IP > > addresses or using an external PROXY so the http/ws connection have a > > different originator public IP address. AFAIK there should be no potential > > danger in leaking the private IP4 addresses (here you got mine, in case you > > are interested 127.0.0.1 and 192.168.64.2 ;). I have not much background on > > IPv6, so please complete any missing info and how would it affect here. > > If you read the above articles and discussion surrounding the leak. > The concern is not around local or private IPs, it's around public IPs > for VPN users. Personal VPN use is extremely widespread > internationally, mostly for censorship and content-blocking > circumvention. Chinese users use them to get around the great > firewall. Australian users use them to be able to watch Netflix. Tor > is often not a suitable option because the web service they are trying > to reach blocks Tor (e.g. bank website) or is too data heavy (e.g. > streaming video). > > >From the popularity of the issue, it's clear that the vast majority of > users thought that using a VPN hid their real IP address from the > websites they were visiting. It has been a huge shock (including for > me) that default VPN configurations let the browser (and thus WebRC) > know the real IP. Is that an operating system or VPN software issue? > Either way, due to WebRTC this real IP access issue has now spread to > javascript, so that any website can access your real IP. > > "AFAIK there should be no potential danger in leaking the private IP4 addresses" > > Here's a real-life example of the danger this has. China started > injecting malicious javascript into people's Baidu searches when those > searches came from outside China[12]. This was used to DDOS Github, > but what if that javascript contained a webrtc data channel setup? All > of a sudden, China could obtain the real Chinese IPs of citizens who > were using VPNs. The result of this could definitely be > life-threatening. Again, just saying "use Tor" means those citizens > cannot use many modern internet services (especially streaming video). > Personal VPNs are a fantastic compromise that provide access at quite > good speeds while retaining a good-enough-for-Netflix level or > privacy. WebRTC's real IP leaking removes this middle ground > compromise. > > [12]: http://arstechnica.com/security/2015/03/github-battles-largest-ddos-in-sites-history-targeted-at-anti-censorship-tools/ > > > > > I don't think it is a good idea to tight the solution of requesting user > > permission, to not leak IP information, as theoretically a user could be > > interested in using webrtc (audio/video/datachannels) and still don't > > disclose their public IP address (i.e. forcing all the data to go via a TURN > > server). > > > > One possible solution would be that the browser don't gather/announce > > host&reflexive candidates when an HTTP proxy is set, and only use turn relay > > candidates instead. The second solution (which I think it is already > > discussed somewhere else) would be to allow the user to configure a TURN > > server to override the app settings and force all connection to go through > > it. (Then build a chained-TURN infrastructure into TOR and you could have a > > killer combo ;) > > I'm fully supportive of removing the real IPs from the onicecandidate > results. However, as we saw in April's discussion thread and now in > this thread, identifying that IP is a complex topic that likely > doesn't have an easy answer and might require significant browser or > operating system-level changes. So, I'm suggesting here that an easier > solution is to make data channels require user-consent (again, just > like what already happens with audio and video channels). > I don't see how that would fix anything. Setting up a recvonly audio/video PeerConnection won't get you any user-consent request either. Forcing TURN in those cases seems more like it. Lorenzo > > > > Regarding the issue that the browser becomes a CDN peer, not sure if anyone > > has ever raised the issue before. From my point of view, there is not, but > > in any case, I think it is orthogonal to the leak issue. > > It is orthogonal to the privacy issue, but this user-consent proposal > also helps address this issue, too. > > Thanks again for the responses! > Daniel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Jul 12 13:14:45 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D801A8939 for ; Sun, 12 Jul 2015 13:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXuqMQYzUsa3 for ; Sun, 12 Jul 2015 13:14:41 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0FD01A895C for ; Sun, 12 Jul 2015 13:14:24 -0700 (PDT) Received: from [192.168.1.200] (p508F16B1.dip0.t-ipconnect.de [80.143.22.177]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7C5761C0C0BEE; Sun, 12 Jul 2015 22:14:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Michael Tuexen In-Reply-To: Date: Sun, 12 Jul 2015 22:14:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <804017F1-0211-43F0-9CE3-1F51A9C9E705@lurchi.franken.de> References: <55A22A1B.4000202@gmail.com> To: Daniel Roesler X-Mailer: Apple Mail (2.2102) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 20:14:44 -0000 > On 12 Jul 2015, at 21:19, Daniel Roesler wrote: >=20 > Thanks very much for the responses! Going to try and address both = inline below. >=20 > On Sat, Jul 11, 2015 at 9:26 PM, Matthew Kaufman = wrote: >>=20 >> On the IPv6 Internet, the IP address you use to reach the web site is = almost >> certainly the same as your "local" IP address. There's no additional >> information exposed by allowing an application to discover that = information >> directly via JavaScript. >>=20 >> The IPv4 Internet is essentially out of addresses and in the process = of >> being retired. I don't believe there's any reason at this point to = disable >> functionality in order to improve compatibility with this legacy = network. >>=20 >=20 > I disagree with this sentiment. IPv4 will be around for many more > years and many ISPs still do not assign their customers IPv6 > addresses. If IPv6 is replacing IPv4 so readily, why not only offer > WebRTC through IPv6? It's a huge double standard to say that we won't > support privacy issues of one network while at the same time > supporting connectivity though it. >=20 >>=20 >> ps. You can also gather all these addresses for any browser with = Flash >> Player installed by asking Flash to connect via RTMFP to a server, = whereupon >> it will report the full enumeration of available IPv4 and IPv6 = addresses to >> that server. >=20 > Yes, however flash can easily be blocked using click-to-enable (i.e. > user consent) and will not be installed on the majority of modern > browsers (mobile devices). WebRTC will be. What I'm asking for here is > a similar flash-blocking behavior to what is possible in Chromium > (built-in setting) and Firefox (via FlashBlock addons), so that users > can choose to click-to-enable based on context (just like they need to > already in getUserMedia). >=20 > On Sun, Jul 12, 2015 at 1:49 AM, Sergio Garcia Murillo > wrote: >> Hi, >>=20 >> While acknowledging that there might be a potential privacy issue, I = don't >> think agree on your analysis on the issue that you have made nor your >> proposal. >=20 > I'd like to strongly encourage everyone here to stop treating this > issue as "might be a potential privacy issue". There have been > numerous news articles[1][2][3][4], discussion by > VPNs/Tor[5][6][7][8], my github proof-of-concept has over 1,500 stars > and 195 forks[9], the Mozilla Firefox bug has over 100 comments and is > marked as sec-moderate[10], and we are now seeing it exploited in the > wild to detect VPN users[11]. This is not "might be a potential > privacy issue". This is an existing, significant privacy issue. >=20 > [1]: = https://torrentfreak.com/huge-security-flaw-leaks-vpn-users-real-ip-addres= ses-150130/ > [2]: = http://lifehacker.com/how-to-see-if-your-vpn-is-leaking-your-ip-address-an= d-1685180082 > [3]: = https://threatpost.com/webrtc-found-leaking-local-ip-addresses/110803 > [4]: = http://news.softpedia.com/news/WebRTC-in-Firefox-and-Chrome-Reveals-IPs-Be= hind-VPN-471881.shtml > [5]: = https://www.expressvpn.com/blog/explaining-webrtc-ip-leak-vulnerability-af= fecting-web-browsers/ > [6]: https://trac.torproject.org/projects/tor/ticket/5578 > [7]: https://ipleak.net/ > [8]: https://www.privateinternetaccess.com/forum/discussion/8204/ > [9]: https://github.com/diafygi/webrtc-ips > [10]: https://bugzilla.mozilla.org/show_bug.cgi?id=3D959893 > [11]: https://twitter.com/incloud/status/619624021123010560 >=20 >>=20 >> The information available in the ICE gathering process and made = available to >> the JS app is the following: >>=20 >> -Host candidates, mostly private IP addresses >> -Server reflexive candidates, exposing the public IP address as shown = by the >> TURN/STUN server >> -Relay candidates, hosted by the TURN server >>=20 >> My understanding of the issue is that the leak happens when the = application >> is able to retrieve information not already available to it. >> That happens either when the user is using a VPN and have multiple = public IP >> addresses or using an external PROXY so the http/ws connection have a >> different originator public IP address. AFAIK there should be no = potential >> danger in leaking the private IP4 addresses (here you got mine, in = case you >> are interested 127.0.0.1 and 192.168.64.2 ;). I have not much = background on >> IPv6, so please complete any missing info and how would it affect = here. >=20 > If you read the above articles and discussion surrounding the leak. > The concern is not around local or private IPs, it's around public IPs > for VPN users. Personal VPN use is extremely widespread > internationally, mostly for censorship and content-blocking > circumvention. Chinese users use them to get around the great > firewall. Australian users use them to be able to watch Netflix. Tor > is often not a suitable option because the web service they are trying > to reach blocks Tor (e.g. bank website) or is too data heavy (e.g. > streaming video). >=20 >> =46rom the popularity of the issue, it's clear that the vast majority = of > users thought that using a VPN hid their real IP address from the > websites they were visiting. It has been a huge shock (including for > me) that default VPN configurations let the browser (and thus WebRC) > know the real IP. Is that an operating system or VPN software issue? > Either way, due to WebRTC this real IP access issue has now spread to > javascript, so that any website can access your real IP. >=20 > "AFAIK there should be no potential danger in leaking the private IP4 = addresses" >=20 > Here's a real-life example of the danger this has. China started > injecting malicious javascript into people's Baidu searches when those > searches came from outside China[12]. This was used to DDOS Github, > but what if that javascript contained a webrtc data channel setup? All > of a sudden, China could obtain the real Chinese IPs of citizens who > were using VPNs. The result of this could definitely be > life-threatening. Again, just saying "use Tor" means those citizens > cannot use many modern internet services (especially streaming video). > Personal VPNs are a fantastic compromise that provide access at quite > good speeds while retaining a good-enough-for-Netflix level or > privacy. WebRTC's real IP leaking removes this middle ground > compromise. >=20 > [12]: = http://arstechnica.com/security/2015/03/github-battles-largest-ddos-in-sit= es-history-targeted-at-anti-censorship-tools/ >=20 >>=20 >> I don't think it is a good idea to tight the solution of requesting = user >> permission, to not leak IP information, as theoretically a user could = be >> interested in using webrtc (audio/video/datachannels) and still don't >> disclose their public IP address (i.e. forcing all the data to go via = a TURN >> server). >>=20 >> One possible solution would be that the browser don't gather/announce >> host&reflexive candidates when an HTTP proxy is set, and only use = turn relay >> candidates instead. The second solution (which I think it is already >> discussed somewhere else) would be to allow the user to configure a = TURN >> server to override the app settings and force all connection to go = through >> it. (Then build a chained-TURN infrastructure into TOR and you could = have a >> killer combo ;) >=20 > I'm fully supportive of removing the real IPs from the onicecandidate > results. However, as we saw in April's discussion thread and now in > this thread, identifying that IP is a complex topic that likely > doesn't have an easy answer and might require significant browser or > operating system-level changes. So, I'm suggesting here that an easier > solution is to make data channels require user-consent (again, just > like what already happens with audio and video channels). >=20 >>=20 >> Regarding the issue that the browser becomes a CDN peer, not sure if = anyone >> has ever raised the issue before. =46rom my point of view, there is = not, but >> in any case, I think it is orthogonal to the leak issue. >=20 > It is orthogonal to the privacy issue, but this user-consent proposal > also helps address this issue, too. Don't you ask for user consent for a peer connection? Best regards Michael >=20 > Thanks again for the responses! > Daniel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Sun Jul 12 13:15:17 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B7E1A8938 for ; Sun, 12 Jul 2015 13:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMLzCUuG4e8j for ; Sun, 12 Jul 2015 13:15:14 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529AD1A8928 for ; Sun, 12 Jul 2015 13:15:11 -0700 (PDT) Received: (qmail 7776 invoked from network); 12 Jul 2015 20:15:09 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 1497 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 12 Jul 2015 20:15:09 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 7765A18A0D50; Sun, 12 Jul 2015 21:15:09 +0100 (BST) Received: from [192.168.157.66] (unknown [192.67.4.66]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 46F3D18A0AEE; Sun, 12 Jul 2015 21:15:09 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D05EBB11-E9B6-45B5-A84E-CA1C149CA6BD" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: tim panton In-Reply-To: Date: Sun, 12 Jul 2015 21:15:08 +0100 Message-Id: <44B765D4-4685-4D22-A7F5-A137E76A167F@phonefromhere.com> References: <55A22A1B.4000202@gmail.com> To: Daniel Roesler X-Mailer: Apple Mail (2.2102) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 20:15:16 -0000 --Apple-Mail=_D05EBB11-E9B6-45B5-A84E-CA1C149CA6BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Jul 2015, at 20:19, Daniel Roesler wrote: >=20 > If you read the above articles and discussion surrounding the leak. > The concern is not around local or private IPs, it's around public IPs > for VPN users. Personal VPN use is extremely widespread > internationally, mostly for censorship and content-blocking > circumvention. Chinese users use them to get around the great > firewall. Australian users use them to be able to watch Netflix. Tor > is often not a suitable option because the web service they are trying > to reach blocks Tor (e.g. bank website) or is too data heavy (e.g. > streaming video). The problem is that those VPNs are misconfigured. If you want your VPN to ensure you don=E2=80=99t reveal the ISP provided = public IP, then you shouldn=E2=80=99t allow it to be the default route. You set the = default=20 route to the VPN - and then add a specific route to let just the VPN = packets flow=20 out with that IP. If you do this correctly the STUN address webRTC gets is that of the far = end of the=20 VPN tunnel - which your website already knew. I don=E2=80=99t think that just because some VPN service vendors can=E2=80= =99t update their=20 scripts correctly we should freeze web protocols. This doesn=E2=80=99t help http proxy services of course, but that = isn=E2=80=99t a VPN. Tim.= --Apple-Mail=_D05EBB11-E9B6-45B5-A84E-CA1C149CA6BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 12 Jul 2015, at 20:19, Daniel Roesler <diafygi@gmail.com> = wrote:

If you read the above articles and discussion = surrounding the leak.
The concern is not around = local or private IPs, it's around public IPs
for VPN users. Personal VPN use is extremely = widespread
internationally, mostly = for censorship and content-blocking
circumvention. Chinese users use them to get = around the great
firewall. Australian users = use them to be able to watch Netflix. Tor
is often not a suitable option because the web = service they are trying
to reach blocks Tor (e.g. = bank website) or is too data heavy (e.g.
streaming = video).

The = problem is that those VPNs are misconfigured.
If = you want your VPN to ensure you don=E2=80=99t reveal the ISP provided = public IP,
then you shouldn=E2=80=99t allow it to = be the default route. You set the default 
route= to the VPN - and then add a specific route to let just the VPN packets = flow 
out with that IP.
If you do this correctly the STUN = address webRTC gets is that of the far end of the 
VPN tunnel - which your website already knew.

I don=E2=80=99t think = that just because some VPN service vendors can=E2=80=99t update = their 
scripts correctly we should freeze web = protocols.

This = doesn=E2=80=99t help http proxy services of course, but that isn=E2=80=99t= a VPN.

Tim.
= --Apple-Mail=_D05EBB11-E9B6-45B5-A84E-CA1C149CA6BD-- From nobody Sun Jul 12 15:03:07 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564DF1A886D for ; Sun, 12 Jul 2015 15:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeBRZiH8cNLP for ; Sun, 12 Jul 2015 15:03:03 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB30F1A8873 for ; Sun, 12 Jul 2015 15:03:03 -0700 (PDT) Received: by pdbep18 with SMTP id ep18so213628803pdb.1 for ; Sun, 12 Jul 2015 15:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=dx5wBM8ep0rU8PFxe7engZgTEzR6YGu1T2VuPjdFuMw=; b=bhE+RYFmvAfrARxHfJSoubbUoVqsRWY55JK1Q/Y0wGUkxONSlDOuI/G3e07SeQp56w YRVbWDv6Z/ZxwoKmP25Lj5SvktMhHjc15uIbrV8ssTQURC3JM1qm5FS6x+5YW5KDobcH hXWqHz/zLN2lMW72raxDbswK1QD8e8OXp8fqD26bFXdGrDxr9C39EA1f3edYh6lSZF7x wBCFtVkfnUUfrZxrRBeQ/UkclWpXJLkeOh8bAmECUraAtLN6bpNZUI7b8LhqQ9Ey5zx5 6qOsYPFgoU+FJk2r1uTGLJak2H00jjX+MJxeYNy3n3c7SGJ8bD4RkvzP06YxSDSuweLY fLQw== X-Received: by 10.70.42.233 with SMTP id r9mr62873071pdl.140.1436738583521; Sun, 12 Jul 2015 15:03:03 -0700 (PDT) Received: from [10.69.168.48] ([166.170.36.144]) by smtp.gmail.com with ESMTPSA id x12sm487742pdj.83.2015.07.12.15.03.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Jul 2015 15:03:01 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12H143) From: Bernard Aboba Date: Sun, 12 Jul 2015 15:02:58 -0700 To: Daniel Roesler Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 22:03:05 -0000 Consent is an API issue not a protocol and therefore is owned by W3C, not IE= TF. Why not take it up there? > On Jul 11, 2015, at 9:42 AM, Daniel Roesler wrote: >=20 > Howdy all, this is mostly a re-surfacing of the discussion about IP > address leaking back in April[1], which unfortunately I did not > discover until recently. >=20 > One of the items in the new proposal was "WebRTC already requires > permission to access getUserMedia. Why not use that permission to > control interface enumeration?" That item didn't really get discussed > much in the thread, but I think it's one of the most important issues. >=20 > Why? There is now a documented case where a third party on nytimes.com > is using a fake webRTC datachannel to silently gather user local (and > potentially "real" ISP) IP addresses. >=20 > https://twitter.com/incloud/status/619624021123010560 >=20 > So I'd like to voice my support for adding a consent requirement that > would prevent this type of silent behavior. A user that is > purposefully visiting a site that has a legitimate reason for using a > webRTC data channel will have the necessary context to give consent, > just like they have to get consent on getUserMedia. >=20 > I'm really unclear on why it's so important to have the silent webRTC > data channel behavior. P2P data connections should be held to the same > consent requirements just like P2P video and voice connections. In > addition to the silent third party local IP tracking, a silent P2P > data channel opens up users to silently becoming nodes in a web-based > file sharing network. For example, webtorrent[2] can be silently > embedded on a website so that all of the users to that website start > seeding content they don't know they are seeding. >=20 > Possible fix: >=20 > 1. Require user consent before calling the callback on createOffer(). > 2. If the user has already given consent via getUserMedia, the user > consent requirement is satisfied. > 3. If there's no previous gUM consent, then ask the user for consent. >=20 > This implementation requires no updates to current webRTC demos, since > you have to wait for a callback on createOffer anyway. I'm open to > other ways, such as making createDataChannel asynchronous like gUM, > but that would require updates to existing apps that use > createDataChannel. >=20 > Thanks! > Daniel Roesler >=20 > [1]: https://www.ietf.org/mail-archive/web/rtcweb/current/msg14494.htm > [2]: https://github.com/feross/webtorrent >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jul 13 08:16:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF961B2BDB for ; Mon, 13 Jul 2015 08:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQl13venuG8c for ; Mon, 13 Jul 2015 08:16:38 -0700 (PDT) Received: from mail.eeph.com (mail.eeph.com [IPv6:2001:470:826a:d2::3]) by ietfa.amsl.com (Postfix) with ESMTP id DD5281B2BC3 for ; Mon, 13 Jul 2015 08:16:12 -0700 (PDT) Received: from [IPv6:2001:470:826a:d0:d5fe:6e06:c62e:6418] (unknown [IPv6:2001:470:826a:d0:d5fe:6e06:c62e:6418]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id BAF312A3509; Mon, 13 Jul 2015 08:16:12 -0700 (PDT) Message-ID: <55A3D63D.1020108@matthew.at> Date: Mon, 13 Jul 2015 08:16:13 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Daniel Roesler , Sergio Garcia Murillo References: <55A22A1B.4000202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 15:16:40 -0000 On 7/12/2015 12:19 PM, Daniel Roesler wrote: > Thanks very much for the responses! Going to try and address both inline below. > > On Sat, Jul 11, 2015 at 9:26 PM, Matthew Kaufman wrote: >> On the IPv6 Internet, the IP address you use to reach the web site is almost >> certainly the same as your "local" IP address. There's no additional >> information exposed by allowing an application to discover that information >> directly via JavaScript. >> >> The IPv4 Internet is essentially out of addresses and in the process of >> being retired. I don't believe there's any reason at this point to disable >> functionality in order to improve compatibility with this legacy network. >> > I disagree with this sentiment. IPv4 will be around for many more > years Maybe. > and many ISPs still do not assign their customers IPv6 > addresses. Only ones that don't expect to stay in business. > If IPv6 is replacing IPv4 so readily, why not only offer > WebRTC through IPv6? I would support such a proposal. > It's a huge double standard to say that we won't > support privacy issues of one network while at the same time > supporting connectivity though it. IPv6 won't have that "privacy", so there's no reason for IPv4 users to continue to expect such. Matthew Kaufman From nobody Mon Jul 13 11:55:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A781B2D37 for ; Mon, 13 Jul 2015 11:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRBtCD9fD89b for ; Mon, 13 Jul 2015 11:54:57 -0700 (PDT) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7041B2D2A for ; Mon, 13 Jul 2015 11:54:56 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 0E1C1C1D3A; Mon, 13 Jul 2015 18:54:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1U5ioq88M3M4; Mon, 13 Jul 2015 18:54:55 +0000 (UTC) Received: from [10.252.28.163] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id E92AAC2910; Mon, 13 Jul 2015 18:54:55 +0000 (UTC) Message-ID: <55A4097F.3060106@mozilla.com> Date: Mon, 13 Jul 2015 11:54:55 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: Michael Tuexen , Daniel Roesler References: <55A22A1B.4000202@gmail.com> <804017F1-0211-43F0-9CE3-1F51A9C9E705@lurchi.franken.de> In-Reply-To: <804017F1-0211-43F0-9CE3-1F51A9C9E705@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 18:54:59 -0000 Michael Tuexen wrote: > Don't you ask for user consent for a peer connection? No. Since there seems to be some misunderstanding on this thread: consent is required for getUserMedia (camera/microphone) access. This is true regardless of whether or not you send that data anywhere over the network. User consent is not required for a peer connection (since you cannot use it to send any data that you could not otherwise have just relayed through the server, e.g., via WebSockets). Consent *is* required by the other side to continue receiving your data (to prevent DDoS attacks), but that is automatic and does not require user intervention (other than viewing a page/running a program designed to operate the other end of the PeerConnection). These issues are all detailed in . I would encourage those participating in this thread to read that document. We could always benefit from additional review. From nobody Mon Jul 13 15:14:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F9D1A6F87 for ; Mon, 13 Jul 2015 15:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2SZJOAfYA3X for ; Mon, 13 Jul 2015 15:14:42 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E8F1A6FBC for ; Mon, 13 Jul 2015 15:14:40 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201507140014358248; Tue, 14 Jul 2015 00:14:35 +0200 From: "Karl Stahl" To: "'Eric Rescorla'" , "'Cullen Jennings'" References: In-Reply-To: Date: Tue, 14 Jul 2015 00:14:38 +0200 Message-ID: <008601d0bdb9$4f154da0$ed3fe8e0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01D0BDCA.129E1DA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdC5jAod9KfKML6ORtyPcAgnMQp6kgD4Sngw Content-Language: sv Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 22:14:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0087_01D0BDCA.129E1DA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have read this draft and the latest draft-ietf-rtcweb-return-00 and = draft-ietf-tram-turn-server-discovery-03 drafts from the point of view = of finally getting a good and working solution to the old NAT/Firewall = traversal issue with real-time communication, here specifically WebRTC = using ICE. =20 I find all these drafts to be in the right direction and should be = worked trough to RFCs. =20 Regarding the comment on Section 6 (=E2=80=9CThe IETF is designing = systems to send interactive audio and video such that it looks like = HTTPS and HTTP to the proxies and firewalls =E2=80=9C) and below: > extremely unlikely that we would implement it. =20 I hope this means that the IETF should go no further in the direction of = =E2=80=9Cfooling real-time traffic=E2=80=9D through firewalls, but = rather make RFCs that can allows good traversal of real-time traffic for = users on networks that want such traffic, and that we realize: =20 i) The network administrator wanting to block or make real-time traffic = bad and useless can always do that (exemplified in this behave draft, = but maybe the intent has to be clarified). And that taking further steps = in the direction of =E2=80=9Cfooling real-time traffic=E2=80=9D through = firewalls =E2=80=9Chas some risk of impacting normal HTTP traffic, so = there is a desire to provide guidance around ways to do that in this = draft.=E2=80=9D (quote from this behave draft) =20 ii) There may be legitimate reasons to e.g. allow surfing, but not voice = on a network. We cannot/should not rule against that, even if we all are = for net neutrality and against evil purposes for blocking e.g. voice and = SIP (which still sometimes seem to be the case). The network admin and = the firewall are in charge. If we want to use good real-time = communication, we have to use networks that wants to provide it = =E2=80=93 It should be a selling feature for using the network access. = Our efforts could possibly be advice how evil blocking could be = exposed/displayed so users can select other network accesses for = real-time communication. =20 I have lost track of where these repeatedly popping up suggestions to = =E2=80=9Cfool real-time traffic=E2=80=9D through the most restrictive = firewalls are, but the only real solution is to make these firewalls = less restrictive or to parallel them, which is what the RETURN + TURN = server DISCOVERY draft may achieve in a good way. =20 I think there could be (maybe is) consensus around this, and as a = comment to this behave draft=E2=80=9D: - Yes, it guides how a firewall could be less restrictive, but still = pretty secure, and allow STUN-based traversal of WebRTC real-time = traffic through the network default gateway. =20 However, that is not sufficient, it should in its =E2=80=9Cguidance to = firewall vendors=E2=80=9D (which I believe the draft is), also point out = the firewall traversal clarified in the RETURN draft (From the = introduction): =E2=80=9CThis TURN server may be placed inside the network, with a firewall configuration allowing it to communicate with the public internet, or it may be operated by a third party outside the network, with a firewall configuration that allows hosts inside the network to communicate with it. Use of the specified TURN server may be the only way for clients on the network to achieve a high quality WebRTC experience. This scenario is required to be supported by the WebRTC requirements document [I-D.ietf-rtcweb-use-cases-and-requirements] Section 3.3.5.1.=E2=80=9D =20 A firewall (designed to be secure AND to handle real-time communication = without having to be paralleled by an SBC or a TURN server) could very = well include such TURN server (or TURN Proxy or Border TURN server as it = is called in the RETURN draft). =20 Also, a network service provider offering such (sealed) TURN server (or = TURN Proxy or Border TURN server), typically has an enterprise firewall = in front of it: The firewall vendor should then be adviced to recommend = his customers to open a pinhole from the LAN to that TURN server (not to = use an own additional border TURN server requiring double RETURN or = something like that). =20 So, I suggest to add guidance about these things to this behave draft. =20 =20 Having expressed this, I believe the sealed, configuration and = authentication concept of the RETURN draft, and possible the DISCOVERY = draft needs to be clarified/extended, which will follow in next email. =20 /Karl =20 PS: I am separately posting this and the next email to the TRAM WG also, = since they were also address about this draft and is responsible for the = DISCOVERY draft =20 =20 Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Eric = Rescorla Skickat: den 8 juli 2015 16:40 Till: Cullen Jennings Kopia: rtcweb@ietf.org =C3=84mne: Re: [rtcweb] Agenda time for = draft-jennings-behave-rtcweb-firewall-00 ? =20 I have taken a brief look at this draft and I don't believe that the = proposed pinhole/inspection algorithm provides the desired assurances of verifying consent: =20 1. If you open up an incoming/outgoing pinhole on outgoing packet, prior = to receiving an incoming STUN packet, then if the internal implementation simply sends a new outgoing STUN packet every 5 seconds, then they never need to rely on external consent. =20 2. If you just require *a* incoming STUN packet to be received in order = to extend the lifetime to 30 seconds, then an off-path attacker can forge a STUN response that will cause the pinhole to be open for 30 seconds. (Hence the need for the STUN transaction ID). =20 It seems to me that you should be instead requiring a complete STUN transaction before allowing any non-STUN outgoing traffic. It would = probably be safe-ish to require it before allowing any incoming traffic as well, = though that leaves the chance that you get a small amount of clipping with = packet drops or reordering. =20 =20 WRT to the origin attribute, I have mixed feelings. I agree that your = SNI argument is strong, but there is also a move to figure out how to encrypt SNI, so = every time we extend that argument it makes that harder. OTOH, STUN origin will be sent a lot less often than SNI, I imagine. =20 =20 I don't understand Section 6. Is this guidance to firewall vendors or to = browser implementors. If the former, the firewall has no way of knowing what = "requests" are if the connection use HTTPS (and if is uses HTTP, you have DPI-type = methods for determining whether something is voice or video. If this is guidance to = browser vendors, I consider it extremely unlikely that we would implement it. =20 =20 Point #4 in your security considerations section seems like an entirely = lost cause, unless you assume that attackers are not really trying. =20 -Ekr =20 =20 =20 On Tue, Jul 7, 2015 at 8:50 AM, Cullen Jennings wrote: I'd like to get a brief amount of agenda time to discuss changes we = would need to some of the WebRTC WG drafts to make the ideas proposed in = draft-jennings-behave-rtcweb-firewall- work and make people aware of = this work. Would it be possible to get 10 minutes on the agenda ? Thanks, Cullen _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------=_NextPart_000_0087_01D0BDCA.129E1DA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I = have read this draft and the latest draft-ietf-rt= cweb-return-00 and = draft-ietf-tram-turn-server-discovery-03 drafts from the point of view of finally getting a = good and working solution to the old NAT/Firewall traversal issue with = real-time communication, here specifically WebRTC using = ICE.

 

I = find all these drafts to be in the right direction and should be worked = trough to RFCs.

 

Re= garding the comment on Section 6 (=E2=80=9CThe IETF is designing systems to = send interactive audio and video such that it looks like HTTPS and HTTP = to the proxies and firewalls = =E2=80=9C) and below:

&g= t; extremely unlikely that we would implement = it.

 

I = hope this means that the IETF should go no further in the direction of = =E2=80=9Cfooling real-time traffic=E2=80=9D through firewalls, but = rather make RFCs that can allows good traversal of real-time traffic for = users on networks that want such traffic, and that we = realize:

 

i)= The network administrator wanting to block or make real-time traffic = bad and useless can always do that (exemplified in this behave draft, = but maybe the intent has to be clarified). And that taking further steps = in the direction of =E2=80=9Cfooling real-time traffic=E2=80=9D through = firewalls =E2=80=9Chas some risk of impacting normal = HTTP traffic, so there is a desire to provide guidance around ways to do = that in this draft.=E2= =80=9D =C2=A0(quote from this behave draft)

 

ii= ) There may be legitimate reasons to e.g. allow surfing, but not voice = on a network. We cannot/should not rule against that, even if we all are = for net neutrality and against evil purposes for blocking e.g. voice and = SIP (which still sometimes seem to be the case). The network admin and = the firewall are in charge. If we want to use good real-time = communication, we have to use networks that wants to provide it = =E2=80=93 It should be a selling feature for using the network access. = Our efforts could possibly be advice how evil blocking could be = exposed/displayed so users can select other network accesses for = real-time communication.

 

I = have lost track of where these repeatedly popping up suggestions to = =E2=80=9Cfool real-time traffic=E2=80=9D through the most restrictive = firewalls are, but the only real solution is to make these firewalls = less restrictive or to parallel them, which is what the RETURN + TURN = server DISCOVERY draft may achieve in a good = way.

 

I = think there could be (maybe is) consensus around this, and as a comment = to this behave draft=E2=80=9D:

- = Yes, it guides how a firewall could be less restrictive, but still = pretty secure, and allow STUN-based traversal of =C2=A0WebRTC real-time = traffic through the network default gateway.

 

Ho= wever, that is not sufficient, it should in its =E2=80=9Cguidance to firewall vendors=E2=80=9D (wh= ich I believe the draft is), also point out the firewall traversal = clarified in the RETURN draft (From the = introduction):

=E2= =80=9CThis = TURN server may be placed inside the network, with = a

=C2=A0=C2=A0 firewall configuration = allowing it to communicate with the public

=C2=A0=C2=A0 internet, or it may be operated by a third party = outside the network,

=C2=A0=C2=A0 with a = firewall configuration that allows hosts inside the network = to

=C2=A0=C2=A0 communicate with = it.=C2=A0 Use of the specified TURN server may be = the

=C2=A0=C2=A0 only way for clients on = the network to achieve a high quality WebRTC

=C2=A0=C2=A0 experience.=C2=A0 This scenario is required to be = supported by the WebRTC

=C2=A0=C2=A0 requirements document = [I-D.ietf-rtcweb-use-cases-and-requirements]

=C2=A0=C2=A0 Section 3.3.5.1.=E2=80=9D

 

A = firewall (designed to be secure AND to handle real-time communication = without having to be paralleled by an SBC or a TURN server) could very = well include such TURN server (or TURN Proxy or Border TURN server as it = is called in the RETURN draft).

 

Al= so, a network service provider offering such (sealed) TURN server (or = TURN Proxy or Border TURN server), typically has an enterprise firewall = in front of it: The firewall vendor should then be adviced to recommend = his customers to open a pinhole from the LAN to that TURN server (not to = use an own additional border TURN server requiring double RETURN or = something like that).

 

So= , I suggest to add guidance about these things to this behave = draft.

 

 

Ha= ving expressed this, I believe the sealed, configuration and = authentication concept of the RETURN draft, and possible the DISCOVERY = draft needs to be clarified/extended, which will follow in next = email.

 

/K= arl

 

PS= : I am separately posting this and the next email to the TRAM WG also, = since they were also address about this draft and is responsible for the = DISCOVERY draft

 

 

Fr=C3=A5n: rtcweb = [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Eric = Rescorla
Skickat: den 8 juli 2015 16:40
Till: Cullen = Jennings
Kopia: rtcweb@ietf.org
=C3=84mne: Re: = [rtcweb] Agenda time for draft-jennings-behave-rtcweb-firewall-00 = ?

 

I have = taken a brief look at this draft and I don't believe that the proposed = pinhole/inspection

algorithm = provides the desired assurances of verifying = consent:

 

1. If you open up an incoming/outgoing pinhole on = outgoing packet, prior to

receiving an incoming STUN packet, then if the = internal implementation

simply sends a new outgoing STUN packet every 5 = seconds, then they

never = need to rely on external consent.

 

2. If you just require *a* incoming STUN packet to be = received in order to

extend the lifetime to 30 seconds, then an off-path = attacker can forge

a STUN = response that will cause the pinhole to be open for 30 = seconds.

(Hence the need = for the STUN transaction ID).

 

It seems to me that you should be instead requiring a = complete STUN

transaction = before allowing any non-STUN outgoing traffic. It would = probably

be safe-ish to = require it before allowing any incoming traffic as well, = though

that leaves the = chance that you get a small amount of clipping with = packet

drops or = reordering.

 

 

WRT to the origin attribute, I have mixed feelings. I = agree that your SNI argument

is strong, but there is also a move to figure out how = to encrypt SNI, so every time

we extend that argument it makes that harder. OTOH, = STUN origin will be

sent a = lot less often than SNI, I imagine.

 

 

I = don't understand Section 6. Is this guidance to firewall vendors or to = browser

implementors. If = the former, the firewall has no way of knowing what = "requests"

are = if the connection use HTTPS (and if is uses HTTP, you have DPI-type = methods for

determining = whether something is voice or video. If this is guidance to = browser

vendors, I = consider it extremely unlikely that we would implement = it.

 

 

Point #4 in your security considerations section seems = like an entirely lost

cause, unless you assume that attackers are not really = trying.

 

-Ekr

 

 

 

On Tue, = Jul 7, 2015 at 8:50 AM, Cullen Jennings <fluffy@iii.ca> = wrote:


I'd like to get a brief = amount of agenda time to discuss changes we would need to some of the = WebRTC WG drafts to make the ideas proposed in = draft-jennings-behave-rtcweb-firewall- work and make people aware of = this work.

Would it be possible to get 10 minutes on the agenda = ?

Thanks, = Cullen


_______________________________________________
rtcw= eb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 

------=_NextPart_000_0087_01D0BDCA.129E1DA0-- From nobody Mon Jul 13 15:19:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC871A7005 for ; Mon, 13 Jul 2015 15:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4pjDGvsmE2I for ; Mon, 13 Jul 2015 15:19:26 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D6C1A6FFF for ; Mon, 13 Jul 2015 15:19:25 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201507140019238663; Tue, 14 Jul 2015 00:19:23 +0200 From: "Karl Stahl" To: "'Benjamin Schwartz'" References: <20150513222927.5331.57264.idtracker@ietfa.amsl.com> In-Reply-To: <20150513222927.5331.57264.idtracker@ietfa.amsl.com> Date: Tue, 14 Jul 2015 00:19:26 +0200 Message-ID: <008b01d0bdb9$faa7e150$eff7a3f0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQJx3nsi5TPW+CoNulq21Pq7Z6VVFpyXT4Xw Content-Language: sv Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN discovery: X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 22:19:27 -0000 We need this draft implemented in WebRTC browsers as soon as possible, = so we can get good WebRTC in difficult places (for firewall traversal and for quality). Is there any implementation e.g. in Chrome that can be tried? Now having stated that I am positive to this draft, I have some concerns/questions/suggestions: 1) We need more levels than sealed/leaky It is not acceptable that WebRTC traffic between parties on a typical = LAN is forced through a TURN server, just because of a sealed configuration required for good WebRTC traffic over the WAN. This consequence is = pointed out under "5.11. Reusing the same TURN server", but IS a problem even = if it "work as expected". Such TURN resource consumption, waste of bandwidth and possible = performance degradation do not happen today, and can easily be avoided. I realize this consequence of "sealed" is required to meet some of the requirements under "3.2. Independent Path Control", but we simply need = an "exo-sealed" level, in addition to the proposed strictly sealed and = leaky, allowing local endpoints to connect media directly, while external = traffic is forced to use the TURN server (rather than STUN through the default gateway).=20 Such "exo-sealed" configuration should be the default configuration if a network provided TURN server is made available for good (non-evil) = purposes. 2) Mobile devices need to work on various networks, without individual configuration=20 I am not clear about the thoughts behind the "configuration" of sealed = level and requirements for authentication of the turn server, but if there are methods where an enterprise network (LAN) admin can provide credentials = and force a certain sealed level upon the WebRTC-browser when used at that = LAN, or if the user has the possibility to configure manually, I am OK with = that this can and should OVERRIDE any default configuration or other configuration (on that particular network). However, for mobile devices - Don't we all happily connect our browsers = via WiFi here and there? - there must be a way for a network provider with a good intent to offer an exo-sealed TURN server that automatically should = be used, e.g. to achieve the purpose of offering better RTC quality than is available through the default gateway WAN path on that network.=20 A network provided TURN-server can easily be made available ONLY to the network users that it is serving, so there is no need for authentication = and credentials to protect against illegal usage of a valuable resource, = like it is with the application provided turn server. Network provided TURN = servers are simply deployed for the network users to be use without other authentication than being granted an IP address and a default gateway to = use on that particular network in itself. The same goes for trusting the TURN server with our real-time traffic - = If we would trust the same network provider with the same real-time traffic through the default gateway - we should also use the offered TURN server without other "authentication" than that it is available on our network: Data through the default gateway, RTC through the TURN path is why the = TURN server is provided! But do we know that it is not someone with the evil purpose of stealing = our (encrypted!) real time traffic that is offering the TURN server (instead = of the network provider), which leads us to my point 3). (If we really = think there is a risk of and danger with such attacks...) 3) Is it now good enough to simply use the auto discovered TURN server? = Hope so! There has been some recent improvements to draft-ietf-tram-turn-server-discovery-03 and hopefully that is = sufficient for assuming that the auto-discovered TURN server is offered by our = network provider (a service provider or the enterprise itself) that we trust = anyway, and the TURN server then simply shall be used and considered exo-sealed. (The current RETURN draft says a non configured TURN server should be leaky.) Some concerns regarding the DISCOVERY draft and whether these things = should be specified in the RETURN document: - Is the above the case with all discovery methods proposed? Or shall = the RETURN document make one method mandatory to implement? - Can that method then be the Anycast method (which by far seems to be = the most convenient to deploy and to implement and should work for all = network types and in all devices operating systems). I think what is said under "9.3. Anycast" under "9. Security Considerations" is sufficient for trusting such discovered TURN server. What should then go into the = RETURN draft - or should the DISCOVERY draft be more specific? I don't fully understand the DISCOVERY draft's: "... three discovery mechanisms. The reason for providing multiple mechanisms is to maximize = the opportunity for discovery," - Can we really put the burden upon all WebRTC devices to implement all methods and I doubt network providers will deploy more than one method. = That seems risking rather than maximizing discovery... It is high time to get this done - can we? /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r = internet-drafts@ietf.org Skickat: den 14 maj 2015 00:29 Till: i-d-announce@ietf.org Kopia: rtcweb@ietf.org =C4mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. Title : Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC Authors : Benjamin M. Schwartz Justin Uberti Filename : draft-ietf-rtcweb-return-00.txt Pages : 18 Date : 2015-05-13 Abstract: In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-return-00 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jul 13 18:16:20 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1721A874F for ; Mon, 13 Jul 2015 18:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spTgGcH6FVqH for ; Mon, 13 Jul 2015 18:16:14 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFFC31A8729 for ; Mon, 13 Jul 2015 18:16:13 -0700 (PDT) Received: by iggf3 with SMTP id f3so1676362igg.1 for ; Mon, 13 Jul 2015 18:16:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sSeWqXd3q3befsjZygukZf6WCLXi/YU9MxNMG4zcW1Y=; b=d3wyUo43zFugawVYBeiVkDKPaA6w4f1Dozeutx0tcjPhW0umGF9vmqAWrSCFFETUMj Id8hjm2O/X3tpDXSh/oQQC3DF9/OiCM2mQkzul5DqsmupIFpGDNu5/lLfwbeSdoeHRYJ XEV3/6qkWUuHDrdz1tC2yy0tXjgZh7QHiYqwkvgOdMXuAh5Zla6LLWumTeb5P5Q7vsCC tVHGIKGgjyM2/++UbTSynygA45ekeAcrxiXhLnufnNUCd+XSva5tF6X261PDEFGJjUh5 QBKoJt2xocORgoD2a+WpJb5pL/SarFZkJa+ex6heymxIsZ/Oi+naaugXqzlxHTHp6nNj o8SA== X-Gm-Message-State: ALoCoQmj5iNHvzPLODav6rq/Ih73PONd76Rqwi6Z+jBpZ7LeL6BV74xb5vStDbc7YMvD4LjuSuEX X-Received: by 10.107.33.74 with SMTP id h71mr20149430ioh.128.1436836573075; Mon, 13 Jul 2015 18:16:13 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com. [209.85.213.174]) by smtp.gmail.com with ESMTPSA id qh9sm6874021igb.20.2015.07.13.18.16.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2015 18:16:11 -0700 (PDT) Received: by igvi1 with SMTP id i1so44251818igv.1 for ; Mon, 13 Jul 2015 18:16:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.7.104 with SMTP id i8mr114418iga.50.1436836570686; Mon, 13 Jul 2015 18:16:10 -0700 (PDT) Received: by 10.64.171.114 with HTTP; Mon, 13 Jul 2015 18:16:10 -0700 (PDT) In-Reply-To: <55a4396c.e525700a.ff81b.11d4SMTPIN_ADDED_BROKEN@mx.google.com> References: <20150513222927.5331.57264.idtracker@ietfa.amsl.com> <55a4396c.e525700a.ff81b.11d4SMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 13 Jul 2015 21:16:10 -0400 Message-ID: From: Benjamin Schwartz To: Karl Stahl Content-Type: multipart/alternative; boundary=089e01183ebc65a076051acb9588 Archived-At: Cc: "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN discovery: X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 01:16:18 -0000 --089e01183ebc65a076051acb9588 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl wrote: > We need this draft implemented in WebRTC browsers as soon as possible, so > we > can get good WebRTC in difficult places (for firewall traversal and for > quality). Is there any implementation e.g. in Chrome that can be tried? > > Now having stated that I am positive to this draft, I have some > concerns/questions/suggestions: > > 1) We need more levels than sealed/leaky > > It is not acceptable that WebRTC traffic between parties on a typical LAN > is > forced through a TURN server, just because of a sealed configuration > required for good WebRTC traffic over the WAN. This consequence is pointe= d > out under "5.11. Reusing the same TURN server", but IS a problem even if > it > "work as expected". > > Such TURN resource consumption, waste of bandwidth and possible performan= ce > degradation do not happen today, and can easily be avoided. > > I realize this consequence of "sealed" is required to meet some of the > requirements under "3.2. Independent Path Control", but we simply need a= n > "exo-sealed" level, in addition to the proposed strictly sealed and leaky= , > allowing local endpoints to connect media directly, while external traffi= c > is forced to use the TURN server (rather than STUN through the default > gateway). > How do you propose to tell what is "local"? I don't know how to define that procedurally. I think my main concern here is that it requires us to "lie" to the remote party, by sending candidates that we may then refuse to use even if they work. This seems very strange. Such "exo-sealed" configuration should be the default configuration if a > network provided TURN server is made available for good (non-evil) > purposes. > > > 2) Mobile devices need to work on various networks, without individual > configuration > > I am not clear about the thoughts behind the "configuration" of sealed > level > and requirements for authentication of the turn server, but if there are > methods where an enterprise network (LAN) admin can provide credentials a= nd > force a certain sealed level upon the WebRTC-browser when used at that LA= N, > or if the user has the possibility to configure manually, I am OK with th= at > this can and should OVERRIDE any default configuration or other > configuration (on that particular network). > > However, for mobile devices - Don't we all happily connect our browsers v= ia > WiFi here and there? - there must be a way for a network provider with a > good intent to offer an exo-sealed TURN server that automatically should = be > used, e.g. to achieve the purpose of offering better RTC quality than is > available through the default gateway WAN path on that network. > > A network provided TURN-server can easily be made available ONLY to the > network users that it is serving, so there is no need for authentication > and > credentials to protect against illegal usage of a valuable resource, like > it > is with the application provided turn server. Network provided TURN serve= rs > are simply deployed for the network users to be use without other > authentication than being granted an IP address and a default gateway to > use > on that particular network in itself. > > The same goes for trusting the TURN server with our real-time traffic - I= f > we would trust the same network provider with the same real-time traffic > through the default gateway - we should also use the offered TURN server > without other "authentication" than that it is available on our network: > Data through the default gateway, RTC through the TURN path is why the TU= RN > server is provided! > > But do we know that it is not someone with the evil purpose of stealing o= ur > (encrypted!) real time traffic that is offering the TURN server (instead = of > the network provider), which leads us to my point 3). (If we really think > there is a risk of and danger with such attacks...) > > > 3) Is it now good enough to simply use the auto discovered TURN server? > Hope > so! > > There has been some recent improvements to > draft-ietf-tram-turn-server-discovery-03 and hopefully that is sufficient > for assuming that the auto-discovered TURN server is offered by our netwo= rk > provider (a service provider or the enterprise itself) that we trust > anyway, > and the TURN server then simply shall be used and considered exo-sealed. > (The current RETURN draft says a non configured TURN server should be > leaky.) > The security considerations in that document suggest that not all discovery mechanisms have equal additional exposure to local network interference. I would appreciate clearer guidance on that front. It seems to me that DHCP is the only listed mechanism that creates minimal additional exposure to network interference. > Some concerns regarding the DISCOVERY draft and whether these things shou= ld > be specified in the RETURN document: > > - Is the above the case with all discovery methods proposed? Or shall the > RETURN document make one method mandatory to implement? > > - Can that method then be the Anycast method (which by far seems to be th= e > most convenient to deploy and to implement and should work for all networ= k > types and in all devices operating systems). I think what is said under > "9.3. Anycast" under "9. Security Considerations" is sufficient for > trusting such discovered TURN server. What should then go into the RETURN > draft - or should the DISCOVERY draft be more specific? > > I don't fully understand the DISCOVERY draft's: "... three discovery > mechanisms. The reason for providing multiple mechanisms is to maximize t= he > opportunity for discovery," > > - Can we really put the burden upon all WebRTC devices to implement all > methods and I doubt network providers will deploy more than one method. > That > seems risking rather than maximizing discovery... > > > It is high time to get this done - can we? > > /Karl > > > > > > > > > > -----Ursprungligt meddelande----- > Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r internet-draf= ts@ietf.org > Skickat: den 14 maj 2015 00:29 > Till: i-d-announce@ietf.org > Kopia: rtcweb@ietf.org > =C3=84mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > Working Group of the IETF. > > Title : Recursively Encapsulated TURN (RETURN) for > Connectivity and Privacy in WebRTC > Authors : Benjamin M. Schwartz > Justin Uberti > Filename : draft-ietf-rtcweb-return-00.txt > Pages : 18 > Date : 2015-05-13 > > Abstract: > In the context of WebRTC, the concept of a local TURN proxy has been > suggested, but not reviewed in detail. WebRTC applications are > already using TURN to enhance connectivity and privacy. This > document explains how local TURN proxies and WebRTC applications can > work together. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-return-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e01183ebc65a076051acb9588 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 13, 2015 at 6:19 PM, Karl Stahl <karl.stahl@intertex.se&g= t; wrote:
We need this draft imple= mented in WebRTC browsers as soon as possible, so we
can get good WebRTC in difficult places (for firewall traversal and for
quality). Is there any implementation e.g. in Chrome that can be tried?

Now having stated that I am positive to this draft, I have some
concerns/questions/suggestions:

1) We need more levels than sealed/leaky

It is not acceptable that WebRTC traffic between parties on a typical LAN i= s
forced through a TURN server, just because of a sealed configuration
required for good WebRTC traffic over the WAN. This consequence is pointed<= br> out under "5.11.=C2=A0 Reusing the same TURN server", but IS a pr= oblem even if it
"work as expected".

Such TURN resource consumption, waste of bandwidth and possible performance=
degradation do not happen today, and can easily be avoided.

I realize this consequence of "sealed" is required to meet some o= f the
requirements under "3.2.=C2=A0 Independent Path Control", but we = simply need an
"exo-sealed" level, in addition to the proposed strictly sealed a= nd leaky,
allowing local endpoints to connect media directly, while external traffic<= br> is forced to use the TURN server (rather than STUN through the default
gateway).

How do you propose to tell wh= at is "local"?=C2=A0 I don't know how to define that procedur= ally.

I think my main concern here is that it requ= ires us to "lie" to the remote party, by sending candidates that = we may then refuse to use even if they work.=C2=A0 This seems very strange.=

Such "exo-sealed" configuration should be the default configurati= on if a
network provided TURN server is made available for good (non-evil) purposes= .


2) Mobile devices need to work on various networks, without individual
configuration

I am not clear about the thoughts behind the "configuration" of s= ealed level
and requirements for authentication of the turn server, but if there are methods where an enterprise network (LAN) admin can provide credentials and=
force a certain sealed level upon the WebRTC-browser when used at that LAN,=
or if the user has the possibility to configure manually, I am OK with that=
this can and should OVERRIDE any default configuration or other
configuration (on that particular network).

However, for mobile devices - Don't we all happily connect our browsers= via
WiFi here and there? - there must be a way for a network provider with a good intent to offer an exo-sealed TURN server that automatically should be=
used, e.g. to achieve the purpose of offering better RTC quality than is available through the default gateway WAN path on that network.

A network provided TURN-server can easily be made available ONLY to the
network users that it is serving, so there is no need for authentication an= d
credentials to protect against illegal usage of a valuable resource, like i= t
is with the application provided turn server. Network provided TURN servers=
are simply deployed for the network users to be use without other
authentication than being granted an IP address and a default gateway to us= e
on that particular network in itself.

The same goes for trusting the TURN server with our real-time traffic - If<= br> we would trust the same network provider with the same real-time traffic through the default gateway - we should also use the offered TURN server without other "authentication" than that it is available on our n= etwork:
Data through the default gateway, RTC through the TURN path is why the TURN=
server is provided!

But do we know that it is not someone with the evil purpose of stealing our=
(encrypted!) real time traffic that is offering the TURN server (instead of=
the network provider), which leads us to my point 3). (If we really think there is a risk of and danger with such attacks...)


3) Is it now good enough to simply use the auto discovered TURN server? Hop= e
so!

There has been some recent improvements to
draft-ietf-tram-turn-server-discovery-03 and hopefully that is sufficient for assuming that the auto-discovered TURN server is offered by our network=
provider (a service provider or the enterprise itself) that we trust anyway= ,
and the TURN server then simply shall be used and considered exo-sealed. (The current RETURN draft says a non configured TURN server should be
leaky.)

The security considerations in = that document suggest that not all discovery mechanisms have equal addition= al exposure to local network interference.=C2=A0 I would appreciate clearer= guidance on that front.=C2=A0 It seems to me that DHCP is the only listed = mechanism that creates minimal additional exposure to network interference.=
=C2=A0
Some concerns regarding the DISCOVERY draft and whether these things should=
be specified in the RETURN document:

- Is the above the case with all discovery methods proposed? Or shall the RETURN document make one method mandatory to implement?

- Can that method then be the Anycast method (which by far seems to be the<= br> most convenient to deploy and to implement and should work for all network<= br> types and in all devices operating systems). I think what is said under
"9.3.=C2=A0 Anycast" under "9.=C2=A0 Security Considerations= " is sufficient for
trusting such discovered TURN server. What should then go into the RETURN draft - or should the DISCOVERY draft be more specific?

I don't fully understand the DISCOVERY draft's: "... three dis= covery
mechanisms. The reason for providing multiple mechanisms is to maximize the=
opportunity for discovery,"

- Can we really put the burden upon all WebRTC devices to implement all
methods and I doubt network providers will deploy more than one method. Tha= t
seems risking rather than maximizing discovery...


It is high time to get this done - can we?

/Karl









-----Ursprungligt meddelande-----
Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r internet-drafts@ietf.org
Skickat: den 14 maj 2015 00:29
Till: i-d-announ= ce@ietf.org
Kopia: rtcweb@ietf.org=
=C3=84mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers
Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Recursively Encapsulated TURN (RETURN) for
Connectivity and Privacy in WebRTC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Benj= amin M. Schwartz
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Justin Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-return-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-05-13

Abstract:
=C2=A0 =C2=A0In the context of WebRTC, the concept of a local TURN proxy ha= s been
=C2=A0 =C2=A0suggested, but not reviewed in detail.=C2=A0 WebRTC applicatio= ns are
=C2=A0 =C2=A0already using TURN to enhance connectivity and privacy.=C2=A0 = This
=C2=A0 =C2=A0document explains how local TURN proxies and WebRTC applicatio= ns can
=C2=A0 =C2=A0work together.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-rtcweb-return/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb= -return-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb


--089e01183ebc65a076051acb9588-- From nobody Mon Jul 13 20:19:03 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE89A1A8A50 for ; Mon, 13 Jul 2015 20:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cP_SIIBHeu3 for ; Mon, 13 Jul 2015 20:19:00 -0700 (PDT) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332811A8A4E for ; Mon, 13 Jul 2015 20:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=YWf5cm60//W8OWCffhbUHDVjP+MPlUML3Iw5wBBP2Dw=; b=n7wDYBBZ8CUgVtSyWB0OO2zIYqPjG42458sWKHhnSsEDoWS4HzLXhMC2OjGwWRLLPEowGN9ZZrO+Z8f9ygLRimMQ975JsSugQgxSjv1YTYvDKfI9Sv6bsRCpklSHqV3Tr52EQ2TDE5r4VHmDFpWZgLk0DJ3c3OPRvU9W5E8MKk3ijLngm8dPt90ZZLATqBM+M0RzSZKZSj+09KEdtruZgNXARTjpkwa+zVFkvw7+LDiopUrzU1VKp2wcFhesaVtNieh3br4jHbKSxZcIACSN36WJ1gt20IBy6gi7G39oeV+pb5c4NNbh7F36HY+wDvrIkenJ49MA52R7MJpWk0AWsQ==; Received: from localhost ([127.0.0.1]:51047 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZEqkE-0015Gd-Ng; Mon, 13 Jul 2015 21:18:58 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 13 Jul 2015 22:18:58 -0500 From: ranjit@ranjitvoip.com To: Ted Hardie In-Reply-To: References: <559AFEDB.4070205@alvestrand.no> Message-ID: X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Updated -gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 03:19:01 -0000 Hi It would be good if it is a standards track as 3GPP depends on it and all implementations would confirm to it . having it as Informational is really not of much use. - Ranjit On 2015-07-06 5:35 pm, Ted Hardie wrote: > On Mon, Jul 6, 2015 at 3:19 PM, Harald Alvestrand > wrote: > >> Uwe and I have prepared a new -gateways draft (version -01). >> >> I don't think there's much controversial in it, and there's only >> one >> issue that I think needs WG time at this time: >> >> Should it be Informational or Standards-track? >> >> An informational document defines guidance for how gateways should >> behave, but nobody needs to pay attention if they don't want to. >> >> A standards-track document (which no other RTCWEB document should >> be >> dependent on) defines requirements for how things that call >> themselves >> "WebRTC gateways" should behave, but nobody needs to call their >> gateways >> that, and anyway, there's no protocol police, so the difference >> isn't >> all that much in practice. >> >> More important: What do people want it to be? > > ​I think we adopted it in part because 3GPP had a dependency on it. > Does it need to be standards track for them to reference it? > > Ted​ > >> Harald >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb [1] > > > > Links: > ------ > [1] https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jul 13 23:23:51 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90A21A1AB8 for ; Mon, 13 Jul 2015 23:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvAakCAZ-EV3 for ; Mon, 13 Jul 2015 23:23:46 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 860F31A1AB5 for ; Mon, 13 Jul 2015 23:23:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 620107C3966; Tue, 14 Jul 2015 08:23:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddxcw_1T41oh; Tue, 14 Jul 2015 08:23:43 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:adaa:faa8:8460:fbbf] (unknown [IPv6:2001:470:de0a:27:adaa:faa8:8460:fbbf]) by mork.alvestrand.no (Postfix) with ESMTPSA id B8CD07C373A; Tue, 14 Jul 2015 08:23:43 +0200 (CEST) Message-ID: <55A4AAEE.6090007@alvestrand.no> Date: Tue, 14 Jul 2015 08:23:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: ranjit@ranjitvoip.com, Ted Hardie References: <559AFEDB.4070205@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Updated -gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 06:23:49 -0000 Den 14. juli 2015 05:18, skrev ranjit@ranjitvoip.com: > Hi > It would be good if it is a standards track as 3GPP depends on it and > all implementations would confirm to it . having it as Informational is > really not of much use. Could you share some more detail here? - What 3GPP spec is depending on it? - What does the 3GPP spec depend on being in the draft? - What's the rules for referencing an IETF spec from a 3GPP spec, and why does the category matter? Harald > > - Ranjit > > On 2015-07-06 5:35 pm, Ted Hardie wrote: >> On Mon, Jul 6, 2015 at 3:19 PM, Harald Alvestrand >> wrote: >> >>> Uwe and I have prepared a new -gateways draft (version -01). >>> >>> I don't think there's much controversial in it, and there's only >>> one >>> issue that I think needs WG time at this time: >>> >>> Should it be Informational or Standards-track? >>> >>> An informational document defines guidance for how gateways should >>> behave, but nobody needs to pay attention if they don't want to. >>> >>> A standards-track document (which no other RTCWEB document should >>> be >>> dependent on) defines requirements for how things that call >>> themselves >>> "WebRTC gateways" should behave, but nobody needs to call their >>> gateways >>> that, and anyway, there's no protocol police, so the difference >>> isn't >>> all that much in practice. >>> >>> More important: What do people want it to be? >> >> ​I think we adopted it in part because 3GPP had a dependency on it. >> Does it need to be standards track for them to reference it? >> >> Ted​ >> >>> Harald >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb [1] >> >> >> >> Links: >> ------ >> [1] https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Jul 14 09:30:30 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7BF1A3BA3 for ; Tue, 14 Jul 2015 09:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_dQfxtwa13q for ; Tue, 14 Jul 2015 09:30:28 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E3D1A219E for ; Tue, 14 Jul 2015 09:30:27 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-fe-55a53921af14 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.F6.25217.12935A55; Tue, 14 Jul 2015 18:30:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.210.2; Tue, 14 Jul 2015 18:30:25 +0200 Message-ID: <55A53920.9040509@ericsson.com> Date: Tue, 14 Jul 2015 18:30:24 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: , "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" References: <20150702175553.22797.97637.idtracker@ietfa.amsl.com> In-Reply-To: <20150702175553.22797.97637.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvja6i5dJQg4M39C1WPHnEYrH2Xzu7 A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWx/8RJ9oIPghUXN/xla2A8zNfFyMkhIWAi cab/GhOELSZx4d56ti5GLg4hgaOMEo/e3mOGcJYzSsx6tZ0NpIpXQFti0/UDzCA2i4CqxIv9 O9hBbDYBC4mbPxrBakQFoiSmPl7HAlEvKHFy5hMWkEEiAn2MEg2tXxlBHGGBHkaJzcfXge0W EnCUmHD/NdgkTgEniQnvDwLFOTiYBewlHmwtAwkzC8hLNG+dzQxRri3R0NTBOoFRYBaSHbMQ OmYh6VjAyLyKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzAwD275bbWD8eBzx0OMAhyMSjy8 CrlLQoVYE8uKK3MPMUpzsCiJ887YnBcqJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbHCJ+yf wraX8QY+vEk3jpxqOiUt3Z7ROHdmt8T5L9vyvbbsSHh3t+X6U6Es27714TsPbfOa87azd7un i/3q8OOMOt3eAvujmF6FPb2tU+L/K94omoO5YOalhNpl0lq/dwqePNa2P7lpU5CPzf/Pugf7 TzJaBcU06G3gXlCy7cC19WaL+EWlvZVYijMSDbWYi4oTAUhadsotAgAA Archived-At: Subject: Re: [rtcweb] Last Call: (STUN Usage for Consent Freshness) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 16:30:30 -0000 Hi, I have reviewed this latest version and find nothing that warrants a comment, except: Can you please spell my name correctly in the acknowledgement section ;-). Cheers Magnus The IESG skrev den 2015-07-02 19:55: > > The IESG has received a request from the Real-Time Communication in > WEB-browsers WG (rtcweb) to consider the following document: > - 'STUN Usage for Consent Freshness' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-07-16. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > This document was previously last called on May 1 and has been updated as a result of comments submitted during that last call. > > Abstract > > > To prevent WebRTC applications, such as browsers, from launching > attacks by sending media to unwilling victims, periodic consent to > send needs to be obtained from remote endpoints. > > This document describes a consent mechanism using a new Session > Traversal Utilities for NAT (STUN) usage. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 14 09:34:15 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CC71A6EFE for ; Tue, 14 Jul 2015 09:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saBhlV04yvCe for ; Tue, 14 Jul 2015 09:34:12 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40291A6F2D for ; Tue, 14 Jul 2015 09:34:11 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-d7-55a53a02e8e0 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2C.E8.29223.20A35A55; Tue, 14 Jul 2015 18:34:10 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.210.2; Tue, 14 Jul 2015 18:34:09 +0200 Message-ID: <55A53A01.20803@ericsson.com> Date: Tue, 14 Jul 2015 18:34:09 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" , References: <5587D6B6.40609@ericsson.com> In-Reply-To: <5587D6B6.40609@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+JvjS6T1dJQg0l7hS3md6xjs1j7r53d gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mo42fSDpWCGcMXv+YtZGhj383cxcnJICJhI zJzdwAphi0lcuLeeDcQWEjjKKPFgRWUXIxeQvZxR4vmc98wgCV4BTYnll6cxgtgsAqoSj+fO YwKx2QQsJG7+aARrFhWIkpj6eB0LRL2gxMmZT8BsEYEgiXULu8HqhQV0JR4veQxUzwG0QFNi 09VEkDCngJbE2d4lTCBhZgF7iQdby0DCzALyEs1bZzNDnKYt0dDUwTqBUWAWkgWzEDpmIelY wMi8ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwIA9u+W2wg/Hlc8dDjAIcjEo8vAq5S0KF WBPLiitzDzFKc7AoifPO2JwXKiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR1cku63Pb4VTz suNhqQtYJ5ZsVFtl92r7xuXJIheSOI/p2TVN2Lr63WEj00PTPKOEfbZ+lVa2nn9ET6bu+zOX 0BvBixMz8h8uXXfR8nWWz+ETRknTOkS+qbilT7/qfcxdZsLTGC6B+Zw/L3Tkl7p7JvrkZmrF rju2sCG35I1TdGd65cPCvFYlluKMREMt5qLiRADjXUOIKQIAAA== Archived-At: Subject: Re: [rtcweb] JSEP: Imageattr and CVO X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 16:34:14 -0000 Hi, 3GPP SA4 had a meeting last week. Current status is that the issue is recognized in 3GPP SA4 and the required detailed changes to 3GPP TS 26.114 are being worked out. Their next meeting is 24 - 28 Aug 2015. Cheers Magnus Magnus Westerlund skrev den 2015-06-22 11:34: > Hi, > > I got an action point at the interim to check on what 3GPP and GSMA says > about their usage of a=imageattr and CVO (Coordination of Video > Orientation). > > 3GPP SA4 in TS 26.114 (Which defines CVO) there is discussion about the > usage of a=imageattr when a endpoint is not CVO capable, but it appears > to fail to be explicit about interpretation of imageattr when using CVO. > As the text says that for a non CVO capable endpoint one have to express > both orientations (x,y) and (y,x) in imageattr and perform the rotation > prior to encoding. > > This appear to support the proposed interpretation for JSEP, i.e. that > one expresses the supported max resolution without rotation using > imageattr. > > Bo Burman intend to prepare an contribution to 3GPP SA4 in their > upcoming meeting in two weeks time and see if SA4 can come to agreement > on this interpretation and write it into their specifications. So in > time for Prague we will hopefully be able to conclude on this. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 14 10:01:04 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141771A8A51 for ; Tue, 14 Jul 2015 10:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7Sf1rvH0PGK for ; Tue, 14 Jul 2015 10:00:58 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DDD1A8A3E for ; Tue, 14 Jul 2015 10:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3088; q=dns/txt; s=iport; t=1436893257; x=1438102857; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zYns/X6916IFeGycgCPMtEvK1ee9A1Da5XB68QAWv7o=; b=kVOPFMspWGFy9+1GfrBa5HXZznnFNJ/amDbXekZydRePEIEWZHpl+4tU 8IG1QH70dnUZ7z0HyqfSVVn3sx8Xjk8PpsLQINdRK6ywXsbXz1LUCizJY +5KCDQ3l1KyBAU3ZlsNCMjmXz+ds2HOGKXhv4+MKyCh21GOWA3/KFdNT2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCAwBqP6VV/4QNJK1bgxNUaQa7TgmBagyFK0oCgUw4FAEBAQEBAQGBCoQjAQEBBAEBAQliCwwCAgIBCBEDAQIkBAcbDAsUCQgCBA4FiC4NzxwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBASLSIUGBwaEJQWHCYUjOIdOAYRqhxuBQIQYkxYmY4FagT5vgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,473,1432598400"; d="scan'208";a="15345134" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP; 14 Jul 2015 17:00:56 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6EH0uDT031059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jul 2015 17:00:56 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.76]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 14 Jul 2015 12:00:55 -0500 From: "Ram Mohan R (rmohanr)" To: Magnus Westerlund Thread-Topic: [rtcweb] Last Call: (STUN Usage for Consent Freshness) to Proposed Standard Thread-Index: AQHQvlal0C0BEdbGx0iF/s0dkvg3Mw== Date: Tue, 14 Jul 2015 17:00:55 +0000 Message-ID: References: <20150702175553.22797.97637.idtracker@ietfa.amsl.com> <55A53920.9040509@ericsson.com> In-Reply-To: <55A53920.9040509@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.65.40.205] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (STUN Usage for Consent Freshness) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 17:01:03 -0000 Hi Magnus, Sorry for the typo. I will note the same and correct it in the next revision. Regards, Ram -----Original Message----- From: Magnus Westerlund Date: Tuesday, 14 July 2015 10:00 pm To: "rtcweb@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" Subject: Re: [rtcweb] Last Call: (STUN Usage for Consent Freshness) to Proposed Standard Resent-From: Resent-To: Resent-Date: Tuesday, 14 July 2015 10:00 pm >Hi, > >I have reviewed this latest version and find nothing that warrants a >comment, except: > >Can you please spell my name correctly in the acknowledgement section ;-). > >Cheers > >Magnus > >The IESG skrev den 2015-07-02 19:55: >> >> The IESG has received a request from the Real-Time Communication in >> WEB-browsers WG (rtcweb) to consider the following document: >> - 'STUN Usage for Consent Freshness' >> as Proposed >>Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2015-07-16. Exceptionally, comments may >>be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> This document was previously last called on May 1 and has been updated >>as a result of comments submitted during that last call. >> >> Abstract >> >> >> To prevent WebRTC applications, such as browsers, from launching >> attacks by sending media to unwilling victims, periodic consent to >> send needs to be obtained from remote endpoints. >> >> This document describes a consent mechanism using a new Session >> Traversal Utilities for NAT (STUN) usage. >> >> >> >> >> The file can be obtained via >>=20 >>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness >>/ >> >> IESG discussion can be tracked via >>=20 >>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness >>/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > >--=20 > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From nobody Tue Jul 14 11:18:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95761AD49B; Tue, 14 Jul 2015 11:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbMReumkcvci; Tue, 14 Jul 2015 11:18:27 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6801AD2B2; Tue, 14 Jul 2015 11:18:25 -0700 (PDT) Received: by widjy10 with SMTP id jy10so107110686wid.1; Tue, 14 Jul 2015 11:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gNZws9RhcC4HkIpb4k9L2THRb7QVmtI9Al6uNBYjK3Q=; b=Ol4iNsHuNUO+B3CNruETUqYuEJTgGs2GFoa0OH+g7Pom8TU9GTLNIifFNK+1dSZdIc kV5w82IkEAR/edReBjES34Dezo2PhtJSsL2Cs4HFDy4Cn1j66gZKoS0FubbPTQb58B25 zt405fxu6ZZdzYm4RH1G5Uh16L4njEiyAlXRLRjE8jgL8NP0Uwy6UlKOUdqAAli1RUSg nNiECLh8eS3XUT4KoQs3Lgn99dMBtluX/97on6yCA8HaCW6MMKpRNjTOvvR9Xgmz3SsD kHaDAGSs/GEcvaEWhA/09dvns4LNpTWUDrd9oD+k7CaFzgmbAdxuejR5OL80tdE0gkQp ugMg== MIME-Version: 1.0 X-Received: by 10.180.80.138 with SMTP id r10mr7803328wix.18.1436897904660; Tue, 14 Jul 2015 11:18:24 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Tue, 14 Jul 2015 11:18:24 -0700 (PDT) In-Reply-To: References: <558C4C02.3000404@cisco.com> <558C5CA3.7020108@cisco.com> Date: Tue, 14 Jul 2015 11:18:24 -0700 Message-ID: From: Ted Hardie To: "Orit Levin (LCA)" , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d0444038a2f94a8051ad9dd9c Archived-At: Cc: "appsdir@ietf.org" , Eliot Lear Subject: Re: [rtcweb] [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:18:31 -0000 --f46d0444038a2f94a8051ad9dd9c Content-Type: text/plain; charset=UTF-8 (adding the WG) Hi Orit, Thanks for the review. regards, Ted Hardie On Tue, Jul 14, 2015 at 11:07 AM, Orit Levin (LCA) wrote: > Disclaimer: I am familiar with RTC and WebRTC, but I haven't followed the > RTCWeb work in the last few years. I read the two drafts for the first time. > Therefore, my apologies for potentially raising points that have been > discussed in the past. > > >From the APP (or ART) review perspective, my main comment is on the topic > of "Web-Based Peer Authentication". While it is not clear from the text, > which parts are already standardized concepts (e.g., by W3C) and which are > introduced here for the first time, the described approach seems to be (1) > useful to web applications beyond WebRTC, (2) under development and thus > probably not stable, and (3) too detailed for "an architecture" document. > As such, the concept of " Web-Based Peer Authentication" probably needs to > be introduced and standardized under the Security Area and then adopted by > WebRTC and other apps. > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > This document contains an excellent collection of security threats to > WebRTC and discusses many different ideas for their potential mitigation. > That being said, it is not an easy read. Specifically, from high level to > more specific: > 1. The intended status of the document is Standards Track, while a typical > status of a "security threat model" RFC is Informational. This discrepancy > probably lies in the current scope of the document. See the next comment > below. > 2. The scope of the document is not clear. In addition to describing the > security threats (and the requirements or user expectations related to > their prevention), in many places the document lists potential solutions > with their perceived limitations and/or applicability. Examples are > sections: 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.2.1, 4.3.2.2, 4.3.2.3. To improve > the document's readability and reduce overlaps, the solutions should be > introduced and explained in the companion "architecture" document. > Solutions' applicability to different use cases needs to be provided in a > non-bias way. > 3. Apart from the brief Introduction with a few examples, there is no > description of the WebRTC threat model putting all main types of threat in > one place. For example, the "Communications Security" aspect is introduced > for the first time in Section 4.3 only. The start of Section "4. Security > for WebRTC Applications" could be a logical place for introducing the > WebRTC threat model. > 4. The "simple WebRTC system" presented in the Introduction in Figure 1 is > inadequate to illustrate many of the scenarios and points discussed in the > document. For example, see the discussion around media origin vs. web > origin in Section 4.1.3. > 5. Section "3. The Browser Threat Model" is an overview of the existing > web security architecture and some current practices. As such, references > to relevant standards (e.g., W3C) and common practices need to be added > within the text to help the reader to understand the status of the > information and to follow the sources. > 6. The last paragraph in Section 4.1 conveys a key point in the whole > WebRTC threat model. As such, it needs to be moved to the start of the > discussion where the threat model is introduced (see comments above). > 7. Stylistically, the document would benefit from removing non-standards > vocabulary, i.e., "to bug", "to bug me", "no real way", "it is important to > require", "extremely aggressive intermediates", and "for obvious reasons", > etc. > 8. Suggestions for renaming some of the sections to improve readability: > "3. The Browser Threat Model" -> " 3. Overview of the Existing Web Threat > Model" > "4.1. Access to Local Devices" -> "4.1. Consent to Access Local Resources" > "4.1.2. Calling Scenarios and User Expectations" -> "4.1.2. Scope of > Consent in Various Calling Scenarios" > "4.1.2.1. Dedicated Calling Services" -> "4.1.2.1. Long-term Consent" > "4.1.2.2. Calling the site You're On" -> "4.1.2.2. Short-term Consent" > "4.1.3. Origin-Based Security" -> "4.1.3. Web Attackers and Origin-based > Security" > "4.1.4. Security Properties of the Calling Page" -> "4.1.4. Network > Attackers and Security Properties of the Calling Page" > "4.2. Communications Consent Verification" -> "4.2. Consent to Receive > Traffic" > "4.3.3. Malicious Peers" -> "4.3.3. Out of Scope" > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > This document is in a much better state in terms of its organization and > readability. It introduces the security architecture using an example and > then lists possible approaches to implement it. Some approaches are > described on a high level by referencing other documents, while others are > introduced for the first time in this document together with their > implementation details. By just reading the document, it is difficult to > judge whether these details are sufficient or stable enough for > implementation. In general, I doubt that this is the best approach for an > "architecture" document, which is supposed to serve as a long term stable > reference. > More specific comments: > 1. Different terminology is used throughout the document to address same > or close concepts. It would help a lot to explain the concepts upfront and > then to use the terminology consistently. Currently it includes "client", > "endpoint", "peer", "user"; "implementation", "browser", "chrome", "API", > "JS"; "application", "server", etc. > 2. The discussion is phrased in terms of "authentication" and "trust". In > think that "authorization" instead of "trust" would be a better technical > term, for example, in Section 3.1. > 3. In section 4. Overview, sentence "the tension between security (or > performance) and privacy" is not clear, especially because it doesn't seem > to correspond to Section 6.2. (BTW "tradeoff" would be a better word than > "tension".) > 4. Section "4.1. Initial Signaling", the text is inconsistent in terms of > whether Alice and Bob share or use different identity providers. > 5. Section "4.1. Initial Signaling", reference to PeerConnection needs to > be added. > 6. Section "4.2. Media Consent Verification" and Section "5.3 > Communications Consent": the name/terminology of this functionality needs > to be harmonized. The ICE-based solution with its pros, cons as well as the > alternatives (applicable to different use cases) need to be moved from the > companion threat model document to this "architecture" one. > 7. A suggestion: rename "5. Detailed Technical Description" to "5. > Security Architecture Components". > 8. In Section 5.2., "Implementations which support some form of direct > user authentication..." -> "Implementations that support some form of > direct user authentication..." > 9. Section "5.6. Web-Based Peer Authentication" and section "5.6.2. > Overview of operation": It is not clear, which parts are standardized > concepts (e.g., by W3C) and which are introduced here for the first time. > If exist, references to existing standards need to be added. The described > architecture and the technical details seem to be (1) under development and > thus probably not stable, (2) too detailed for "an architecture" document > and (3) useful beyond WebRTC. As such, the concept of the " Web-Based Peer > Authentication" probably needs be introduced under the Security Area and > then adopted by WebRTC. > 10. The web-based peer authentication using IdP is not the only mechanism > applicable to WebRTC. Moreover, the web-based peer authentication is not > the only approach applicable to WebRTC. Alternatives are listed in the > companion document and need to be moved here to the "architecture" document > with their pros and cons presented in an unbiased way. > 11. Stylistically, the document would benefit from removing non-standards > vocabulary, i.e., "some Web server", "can't really trust", "that much", > "fairly conventional", "simply have", "a little anticlimactic", etc. ;-) > > Thanks, > Orit. > > > -----Original Message----- > > From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Orit Levin > > (LCA) > > Sent: Thursday, June 25, 2015 1:17 PM > > To: Eliot Lear; appsdir@ietf.org > > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > security drafts > > > > Perfect! I have a very long flight on the 7th... So right after then or > earlier. > > Orit. > > > > > -----Original Message----- > > > From: Eliot Lear [mailto:lear@cisco.com] > > > Sent: Thursday, June 25, 2015 12:55 PM > > > To: Orit Levin (LCA); appsdir@ietf.org > > > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > > security drafts > > > > > > Thank you Orit! Can you try to have them done in about two weeks? > > > > > > Eliot > > > > > > On 6/25/15 9:52 PM, Orit Levin (LCA) wrote: > > > > I will be happy to take a look at them! > > > > Orit. > > > > > > > >> -----Original Message----- > > > >> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Eliot > > Lear > > > >> Sent: Thursday, June 25, 2015 11:44 AM > > > >> To: appsdir@ietf.org > > > >> Subject: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > > >> security drafts > > > >> > > > >> Dear Appsdir folk, > > > >> > > > >> Could I have a volunteer to review the following two drafts? > > > >> > > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > > > >> > > > >> and > > > >> > > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > > > >> > > > >> Ted is exempt, having made the request ;-) > > > >> > > > >> Eliot > > > > > > > _______________________________________________ > > appsdir mailing list > > appsdir@ietf.org > > https://www.ietf.org/mailman/listinfo/appsdir > > _______________________________________________ > appsdir mailing list > appsdir@ietf.org > https://www.ietf.org/mailman/listinfo/appsdir > --f46d0444038a2f94a8051ad9dd9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(adding the WG)

Hi Orit,<= br>
Thanks for the review.

regard= s,

Ted Hardie
On Tue, Jul 14, 2015 at 11:07 AM, Orit Levin (= LCA) <oritl@microsoft.com> wrote:
Disclaimer: I am familiar with RTC and WebRTC, but I haven't = followed the RTCWeb work in the last few years. I read the two drafts for t= he first time.
Therefore, my apologies for potentially raising points that have been discu= ssed in the past.

>From the APP (or ART) review perspective, my main comment is on the top= ic of "Web-Based Peer Authentication". While it is not clear from= the text, which parts are already standardized concepts (e.g., by W3C) and= which are introduced here for the first time, the described approach seems= to be (1) useful to web applications beyond WebRTC, (2) under development = and thus probably not stable, and (3) too detailed for "an architectur= e" document.=C2=A0 As such, the concept of " Web-Based Peer Authe= ntication" probably needs to be introduced and standardized under the = Security Area and then adopted by WebRTC and other apps.

https://datatracker.ietf.org/doc/draft-i= etf-rtcweb-security/
This document contains an excellent collection of security threats to WebRT= C and discusses many different ideas for their potential mitigation. That b= eing said, it is not an easy read. Specifically, from high level to more sp= ecific:
1. The intended status of the document is Standards Track, while a typical = status of a "security threat model" RFC is Informational. This di= screpancy probably lies in the current scope of the document. See the next = comment below.
2. The scope of the document is not clear. In addition to describing the se= curity threats (and the requirements or user expectations related to their = prevention), in many places the document lists potential solutions with the= ir perceived limitations and/or applicability. Examples are sections: 4.2.1= , 4.2.2, 4.2.3, 4.2.4, 4.3.2.1, 4.3.2.2, 4.3.2.3. To improve the document&#= 39;s readability and reduce overlaps,=C2=A0 the solutions should be introdu= ced and explained in the companion "architecture" document. Solut= ions' applicability to different use cases needs to be provided in a no= n-bias way.
3. Apart from the brief Introduction with a few examples, there is no descr= iption of the WebRTC threat model putting all main types of threat in one p= lace. For example, the "Communications Security" aspect is introd= uced for the first time in Section 4.3 only. The start of Section "4. = Security for WebRTC Applications" could be a logical place for introdu= cing the WebRTC threat model.
4. The "simple WebRTC system" presented in the Introduction in Fi= gure 1 is inadequate to illustrate many of the scenarios and points discuss= ed in the document. For example, see the discussion around media origin vs.= web origin in Section 4.1.3.
5. Section "3. The Browser Threat Model" is an overview of the ex= isting web security architecture and some current practices. As such, refer= ences to relevant standards (e.g., W3C) and common practices need to be add= ed within the text to help the reader to understand the status of the infor= mation and to follow the sources.
6. The last paragraph in Section 4.1 conveys a key point in the whole WebRT= C threat model. As such,=C2=A0 it needs to be moved to the start of the dis= cussion where the threat model is introduced (see comments above).
7. Stylistically, the document would benefit from removing non-standards vo= cabulary, i.e., "to bug", "to bug me", "no real wa= y", "it is important to require", "extremely aggressive= intermediates",=C2=A0 and "for obvious reasons", etc.
8. Suggestions for renaming some of the sections to improve readability: "3. The Browser Threat Model" -> " 3. Overview of the Exi= sting Web Threat Model"
"4.1. Access to Local Devices" -> "4.1. Consent to Access= Local Resources"
"4.1.2. Calling Scenarios and User Expectations" -> "4.1.= 2. Scope of Consent in Various Calling Scenarios"
"4.1.2.1. Dedicated Calling Services" -> "4.1.2.1. Long-t= erm Consent"
"4.1.2.2. Calling the site You're On" -> "4.1.2.2. Sh= ort-term Consent"
"4.1.3. Origin-Based Security" -> "4.1.3. Web Attackers a= nd Origin-based Security"
"4.1.4. Security Properties of the Calling Page" -> "4.1.= 4. Network Attackers and=C2=A0 Security Properties of the Calling Page"= ;
"4.2. Communications Consent Verification" -> "4.2. Conse= nt to Receive Traffic"
"4.3.3. Malicious Peers" -> "4.3.3. Out of Scope"
https://datatracker.ietf.org/doc/dr= aft-ietf-rtcweb-security-arch/
This document is in a much better state in terms of its organization and re= adability. It introduces the security architecture using an example and the= n lists possible approaches to implement it. Some approaches are described = on a high level by referencing other documents, while others are introduced= for the first time in this document together with their implementation det= ails. By just reading the document, it is difficult to judge whether these = details are sufficient or stable enough for implementation. In general, I d= oubt that this is the best approach for an "architecture" documen= t, which is supposed to serve as a long term stable reference.
More specific comments:
1. Different terminology is used throughout the document to address same or= close concepts. It would help a lot to explain the concepts upfront and th= en to use the terminology consistently. Currently it includes "client&= quot;, "endpoint",=C2=A0 "peer", "user"; &quo= t;implementation", "browser", "chrome", "API&= quot;, "JS"; "application", "server", etc. 2. The discussion is phrased in terms of "authentication" and &qu= ot;trust". In think that "authorization" instead of "tr= ust" would be a better technical term, for example, in Section 3.1. 3. In section 4. Overview, sentence "the tension between security (or = performance) and privacy" is not clear, especially because it doesn= 9;t seem to correspond to Section 6.2. (BTW "tradeoff" would be a= better word than "tension".)
4. Section "4.1. Initial Signaling", the text is inconsistent in = terms of whether Alice and Bob share or use different identity providers. 5. Section "4.1. Initial Signaling", reference to PeerConnection = needs to be added.
6. Section "4.2. Media Consent Verification" and Section "5.= 3 Communications Consent": the name/terminology of this functionality = needs to be harmonized. The ICE-based solution with its pros, cons as well = as the alternatives (applicable to different use cases) need to be moved fr= om the companion threat model document to this "architecture" one= .
7. A suggestion: rename "5. Detailed Technical Description" to &q= uot;5. Security Architecture Components".
8. In Section 5.2., "Implementations which support some form of direct= user authentication..." -> "Implementations that support some= form of direct user authentication..."
9. Section "5.6. Web-Based Peer Authentication" and section "= ;5.6.2. Overview of operation": It is not clear, which parts are stand= ardized concepts (e.g., by W3C) and which are introduced here for the first= time. If exist, references to existing standards need to be added. The des= cribed architecture and the technical details seem to be (1) under developm= ent and thus probably not stable, (2) too detailed for "an architectur= e" document and (3) useful beyond WebRTC.=C2=A0 As such, the concept o= f the " Web-Based Peer Authentication" probably needs be introduc= ed under the Security Area and then adopted by WebRTC.
10. The web-based peer authentication using IdP is not the only mechanism a= pplicable to WebRTC. Moreover, the web-based peer authentication=C2=A0 is n= ot the only approach applicable to WebRTC. Alternatives are listed in the c= ompanion document and need to be moved here to the "architecture"= document with their pros and cons presented in an unbiased way.
11. Stylistically, the document would benefit from removing non-standards v= ocabulary, i.e., "some Web server", "can't really trust&= quot;, "that much", "fairly conventional", "simply= have", "a little anticlimactic", etc. ;-)

Thanks,
Orit.

> -----Original Message-----
> From: appsdir [mailto:apps= dir-bounces@ietf.org] On Behalf Of Orit Levin
> (LCA)
> Sent: Thursday, June 25, 2015 1:17 PM
> To: Eliot Lear; appsdir@ietf.org
> Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of rtc= web-
> security drafts
>
> Perfect! I have a very long flight on the 7th... So right after then o= r earlier.
> Orit.
>
> > -----Original Message-----
> > From: Eliot Lear [mailto:lear@c= isco.com]
> > Sent: Thursday, June 25, 2015 12:55 PM
> > To: Orit Levin (LCA); appsdir= @ietf.org
> > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review o= f rtcweb-
> > security drafts
> >
> > Thank you Orit!=C2=A0 Can you try to have them done in about two = weeks?
> >
> > Eliot
> >
> > On 6/25/15 9:52 PM, Orit Levin (LCA) wrote:
> > > I will be happy to take a look at them!
> > > Orit.
> > >
> > >> -----Original Message-----
> > >> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Eliot
> Lear
> > >> Sent: Thursday, June 25, 2015 11:44 AM
> > >> To: appsdir@ietf.org=
> > >> Subject: [appsdir] Fwd: Request for Apps Directorate rev= iew of rtcweb-
> > >> security drafts
> > >>
> > >> Dear Appsdir folk,
> > >>
> > >> Could I have a volunteer to review the following two dra= fts?
> > >>
> > >> https://datatracker.i= etf.org/doc/draft-ietf-rtcweb-security/
> > >>
> > >> and
> > >>
> > >> https://datatrac= ker.ietf.org/doc/draft-ietf-rtcweb-security-arch/
> > >>
> > >> Ted is exempt, having made the request ;-)
> > >>
> > >> Eliot
> >
>
> _______________________________________________
> appsdir mailing list
> appsdir@ietf.org
> https://www.ietf.org/mailman/listinfo/appsdir<= br>
_______________________________________________
appsdir mailing list
appsdir@ietf.org
https://www.ietf.org/mailman/listinfo/appsdir

--f46d0444038a2f94a8051ad9dd9c-- From nobody Wed Jul 15 00:42:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4551A8840 for ; Wed, 15 Jul 2015 00:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klPAGrlTaMXO for ; Wed, 15 Jul 2015 00:42:09 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A91E1A883D for ; Wed, 15 Jul 2015 00:42:07 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-7d-55a60ecd3c79 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6D.67.25217.DCE06A55; Wed, 15 Jul 2015 09:42:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Wed, 15 Jul 2015 09:42:05 +0200 From: Christer Holmberg To: Harald Alvestrand , "ranjit@ranjitvoip.com" , Ted Hardie Thread-Topic: [rtcweb] Updated -gateways draft Thread-Index: AQHQuDnLo8SeEdvf+k2CJHOD/34edp3O5hsAgAtPjwCAADOdAIABxtog Date: Wed, 15 Jul 2015 07:42:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D916487@ESESSMB209.ericsson.se> References: <559AFEDB.4070205@alvestrand.no> <55A4AAEE.6090007@alvestrand.no> In-Reply-To: <55A4AAEE.6090007@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM+Jvje5ZvmWhBt/WKVsc6+tis5j5+yGb xdp/7ewWjXPtHFg8rky4wuqxc9Zddo8lS34yeexbYh7AEsVlk5Kak1mWWqRvl8CVsWvuT7aC SzIVk+/cZ25g/CLdxcjJISFgInFu9XUWCFtM4sK99WxdjFwcQgJHGSXmb1zJAuEsZpT4OvMX YxcjBwebgIVE9z9tkLiIQAOjxI+7S9hBupkF1CXuLD7HDlIjLKAr8eyfKEhYREBPYtqRTewQ tpvE2l9NjCA2i4CqxJop08AW8wr4Snx7vIMZYtcpRol/qw+zgSQ4geZc3zcRzGYEuu77qTVM ELvEJW49mc8EcbWAxJI955khbFGJl4//sULYihJXpy9nArmHWUBTYv0ufYhWRYkp3Q/ZIfYK Spyc+YRlAqPYLCRTZyF0zELSMQtJxwJGllWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgRF2 cMtvqx2MB587HmIU4GBU4uFdsG9pqBBrYllxZe4hRmkOFiVx3hmb80KFBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MEp7vej/dmz/sbvdor673L+sf+Mmmbwp5wOLqGti5MJq65h3rn2BE70E GYR3uZ68/Cl6/t1nN7Qbo+/vqXTNTWGafIJxwpPDs4UVbv6vFVi7YBv7+7L1vyYeiT4XMuF2 89Ejrs03Jrw3zcsVuv7Uc09g/HWFDYqdB9z/RgawP1stwlk7s0yi8p4SS3FGoqEWc1FxIgBJ HiB2kQIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated -gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 07:42:11 -0000 SGksDQoNCj4+IEl0IHdvdWxkIGJlIGdvb2QgaWYgaXQgaXMgYSBzdGFuZGFyZHMgdHJhY2sgYXMg M0dQUCBkZXBlbmRzIG9uIGl0IGFuZCANCj4+IGFsbCBpbXBsZW1lbnRhdGlvbnMgd291bGQgY29u ZmlybSB0byBpdCAuIGhhdmluZyBpdCBhcyBJbmZvcm1hdGlvbmFsIA0KPj4gaXMgcmVhbGx5IG5v dCBvZiBtdWNoIHVzZS4NCj4NCj4gQ291bGQgeW91IHNoYXJlIHNvbWUgbW9yZSBkZXRhaWwgaGVy ZT8NCj4NCj4gLSBXaGF0IDNHUFAgc3BlYyBpcyBkZXBlbmRpbmcgb24gaXQ/DQoNCjNHUFAgVFMg MjQuMzcxDQoNCj4gLSBXaGF0IGRvZXMgdGhlIDNHUFAgc3BlYyBkZXBlbmQgb24gYmVpbmcgaW4g dGhlIGRyYWZ0Pw0KDQpDdXJyZW50bHkgdGhlIHNwZWMgb25seSBzYXlzIHRoYXQgdGhlIGVQLUNT Q0YgKHdoaWNoIGlzIGFjdGluZyBhcyB0aGUgSU1TIFdlYlJUQyBnYXRld2F5KSBzaGFsbCBzdXBw b3J0IHRoZSBmdW5jdGlvbmFsaXR5IGluIHRoZSBkcmFmdC4NCg0KU28sIGFzIGZhciBhcyBJIGtu b3csIDNHUFAgZG9lc24ndCByZWFsbHkgcmVseSBvbiBhbnl0aGluZyBiZWluZyBpbiB0aGVyZSwg YmVjYXVzZSB0aGUgM0dQUCBzcGVjaWZpYyBwcm9jZWR1cmVzIGFyZSBhbnl3YXkgZGVmaW5lZCBp biB0aGUgM0dQUCBzcGVjLiAzR1BQIG9ubHkgd2FudHMgdGhlIGVQLUNTQ0YgdG8gYmUgYXMgYWxp Z25lZCB3aXRoIGEgZ2VuZXJpYyBnYXRld2F5IGFzIHBvc3NpYmxlLg0KDQo+IC0gV2hhdCdzIHRo ZSBydWxlcyBmb3IgcmVmZXJlbmNpbmcgYW4gSUVURiBzcGVjIGZyb20gYSAzR1BQIHNwZWMsIGFu ZCB3aHkgZG9lcyB0aGUgY2F0ZWdvcnkgbWF0dGVyPw0KDQpUaGF0IHF1ZXN0aW9uIEknbGwgbGV0 IHNvbWVvbmUgbGlrZSBLZWl0aCB0byBhbnN3ZXIgOikNCg0KQnV0LCBhcyBmYXIgYXMgSSBrbm93 LCB0aGUgY2F0ZWdvcnkgYXMgc3VjaCBzaG91bGRuJ3QgbWF0dGVyIC0gaXQgcmVhbGx5IGRlcGVu ZHMgb24gaG93IHRoZSBkcmFmdCBpcyB1c2VkLiANCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K DQoNCj4gT24gMjAxNS0wNy0wNiA1OjM1IHBtLCBUZWQgSGFyZGllIHdyb3RlOg0KPj4gT24gTW9u LCBKdWwgNiwgMjAxNSBhdCAzOjE5IFBNLCBIYXJhbGQgQWx2ZXN0cmFuZCANCj4+IDxoYXJhbGRA YWx2ZXN0cmFuZC5ubz4gd3JvdGU6DQo+Pg0KPj4+IFV3ZSBhbmQgSSBoYXZlIHByZXBhcmVkIGEg bmV3IC1nYXRld2F5cyBkcmFmdCAodmVyc2lvbiAtMDEpLg0KPj4+DQo+Pj4gSSBkb24ndCB0aGlu ayB0aGVyZSdzIG11Y2ggY29udHJvdmVyc2lhbCBpbiBpdCwgYW5kIHRoZXJlJ3Mgb25seSBvbmUg DQo+Pj4gaXNzdWUgdGhhdCBJIHRoaW5rIG5lZWRzIFdHIHRpbWUgYXQgdGhpcyB0aW1lOg0KPj4+ DQo+Pj4gU2hvdWxkIGl0IGJlIEluZm9ybWF0aW9uYWwgb3IgU3RhbmRhcmRzLXRyYWNrPw0KPj4+ DQo+Pj4gQW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCBkZWZpbmVzIGd1aWRhbmNlIGZvciBob3cg Z2F0ZXdheXMgc2hvdWxkIA0KPj4+IGJlaGF2ZSwgYnV0IG5vYm9keSBuZWVkcyB0byBwYXkgYXR0 ZW50aW9uIGlmIHRoZXkgZG9uJ3Qgd2FudCB0by4NCj4+Pg0KPj4+IEEgc3RhbmRhcmRzLXRyYWNr IGRvY3VtZW50ICh3aGljaCBubyBvdGhlciBSVENXRUIgZG9jdW1lbnQgc2hvdWxkIGJlIA0KPj4+ IGRlcGVuZGVudCBvbikgZGVmaW5lcyByZXF1aXJlbWVudHMgZm9yIGhvdyB0aGluZ3MgdGhhdCBj YWxsIA0KPj4+IHRoZW1zZWx2ZXMgIldlYlJUQyBnYXRld2F5cyIgc2hvdWxkIGJlaGF2ZSwgYnV0 IG5vYm9keSBuZWVkcyB0byBjYWxsIA0KPj4+IHRoZWlyIGdhdGV3YXlzIHRoYXQsIGFuZCBhbnl3 YXksIHRoZXJlJ3Mgbm8gcHJvdG9jb2wgcG9saWNlLCBzbyB0aGUgDQo+Pj4gZGlmZmVyZW5jZSBp c24ndCBhbGwgdGhhdCBtdWNoIGluIHByYWN0aWNlLg0KPj4+DQo+Pj4gTW9yZSBpbXBvcnRhbnQ6 IFdoYXQgZG8gcGVvcGxlIHdhbnQgaXQgdG8gYmU/DQo+Pg0KPj4g4oCLSSB0aGluayB3ZSBhZG9w dGVkIGl0IGluIHBhcnQgYmVjYXVzZSAzR1BQIGhhZCBhIGRlcGVuZGVuY3kgb24gaXQuDQo+PiBE b2VzIGl0IG5lZWQgdG8gYmUgc3RhbmRhcmRzIHRyYWNrIGZvciB0aGVtIHRvIHJlZmVyZW5jZSBp dD8NCj4+DQo+PiBUZWTigIsNCj4+DQo+Pj4gSGFyYWxkDQo+Pj4NCj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHJ0Y3dlYiBtYWlsaW5nIGxp c3QNCj4+PiBydGN3ZWJAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Y3dlYiBbMV0NCj4+DQo+Pg0KPj4NCj4+IExpbmtzOg0KPj4gLS0tLS0tDQo+ PiBbMV0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4+DQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcnRj d2ViIG1haWxpbmcgbGlzdA0KPj4gcnRjd2ViQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiANCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From nobody Wed Jul 15 01:03:52 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFF21A8877 for ; Wed, 15 Jul 2015 01:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQehJ5JmqaxW for ; Wed, 15 Jul 2015 01:03:48 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E2B1A88B1 for ; Wed, 15 Jul 2015 01:03:20 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 7BA7D3170CDC5; Wed, 15 Jul 2015 08:03:17 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6F83AJw019470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jul 2015 10:03:16 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 15 Jul 2015 10:02:25 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Harald Alvestrand , "ranjit@ranjitvoip.com" , Ted Hardie Thread-Topic: [rtcweb] Updated -gateways draft Thread-Index: AQHQuDnN3/JBjH3ISECTCktkw1ryoJ3O5hsAgAtPjwCAADOdAIAByPMA Date: Wed, 15 Jul 2015 08:02:25 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC7ADA8882@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <559AFEDB.4070205@alvestrand.no> <55A4AAEE.6090007@alvestrand.no> In-Reply-To: <55A4AAEE.6090007@alvestrand.no> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated -gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 08:03:50 -0000 RGVhciBBbGwsDQpzb21lIGJhY2tncm91bmQgaW5mbzoNCg0KdGhlIDNHUFAgYXJjaGl0ZWN0dXJl IHByb3ZpZGVzIGEgV2ViUlRDIGdhdGV3YXkgZnVuY3Rpb24gKHNpbmNlIDNHUFAgUmVsZWFzZSAx MikuDQpUaGUgM0dQUCBXZWJSVEMgZ2F0ZXdheSBlbnRpdHkgaXMgYmFzZWQgb24gdGhlIGRlY29t cG9zZWQgZ2F0ZXdheSBtb2RlbCBhY2NvcmRpbmcgSVRVLVQgSC4yNDgsIGkuZS4sIEguMjQ4IGlz IHVzZWQgYXMgKHZlcnRpY2FsKSBnYXRld2F5IGNvbnRyb2wgcHJvdG9jb2wuDQpUaGUgM0dQUCBX ZWJSVEMgZ2F0ZXdheSBmdW5jdGlvbiBpcyBtYXBwZWQgb24gdGhlIGV4aXN0aW5nIDNHUFAgUC1D U0NGL0lNUy1BTEcgZW50aXR5ICgidGhlIGNvbnRyb2xsZXIgcGFydCIpIGFuZCB0aGUgSU1TIGFj Y2VzcyBnYXRld2F5ICgidGhlIG1lZGlhIGdhdGV3YXkgcGFydCIpLg0KVGh1cywgdGhlIDNHUFAg V2ViUlRDIGdhdGV3YXkgcmVwcmVzZW50cyBhY3R1YWxseSBhbiAiSU1TIFdlYlJUQyBnYXRld2F5 IiAoaW4gUmVsLTEyIGFuZCAxMykuDQoNClRoZSAzR1BQIHNwZWNzIChmcm9tIFdlYlJUQyBnYXRl d2F5IHBlcnNwZWN0aXZlKSBhcmUNCmEpIDNHUFAgMjMuMzM0LCB3aGljaCBjb3ZlcnMgc2lnbmFs bGluZyByZXF1aXJlbWVudHMgYW5kIHByb2NlZHVyZXMgZm9yIHRoZSBnYXRld2F5IGNvbnRyb2wg aW50ZXJmYWNlIGFuZA0KYikgM0dQUCAyOS4zMzQsIHdoaWNoIHNwZWNpZmllcyB0aGUgcHJvdG9j b2wgc29sdXRpb24sIGtub3duIGFzIHNvIGNhbGxlZCAiSC4yNDggcHJvZmlsZSBzcGVjaWZpY2F0 aW9uIiAoaW4gY29udGV4dCBvZiBILjI0OCkuDQoNClRoZSAzR1BQIFdlYlJUQyBnYXRld2F5IHdv cmsgaXMgY29tcGxlbWVudGVkIGJ5IElUVS1UIFNHMTYsIGFzIHRoZSB0ZWNobm9sb2d5IG93bmVy IG9mIHRoZSBILjI0OCBwcm90b2NvbCwgYXMgcmVzcG9uc2libGUgaW5zdGFuY2UgZm9yIHRoZSBk ZXZlbG9wbWVudCBvZiBILjI0OCBwcm90b2NvbCBleHRlbnNpb25zIChjYWxsZWQgSC4yNDggcGFj a2FnZXMpLg0KDQpUaGUgYXNzb2NpYXRlZCBJVFUtVCB3b3JrIGl0ZW0gaXMgIkguMjQ4LldFQlJU QyIsIC0gYW5kIHRoZXJlIHdpbGwgYmUgYSBmaXJzdCBSZWNvbW1lbmRhdGlvbiBmb3IgIkguMjQ4 IFdlYlJUQyBnYXRld2F5cyIgc29vbiwgdW5kZXIgUmVjIG51bWJlciBJVFUtVCBILjI0OC45NC4N ClRoZSBKdW5lIGRyYWZ0IG1heSBiZSBmb3VuZCB1bmRlcjoNCiBodHRwOi8vd2Z0cDMuaXR1Lmlu dC9hdi1hcmNoL2F2Yy1zaXRlLzIwMTMtMjAxNi8xNTA2X0NoZS9URC0xMS56aXAgDQpUaGUgT2N0 b2JlciBtZWV0aW5nIGlucHV0IGZvciBuZXh0IElFVFUtVCBtZWV0aW5nIGlzIGF2YWlsYWJsZSAo Zm9yIElUVS1UIGRlbGVnYXRlcykgdW5kZXI6DQogaHR0cHM6Ly93d3cuaXR1LmludC9tZC9kb2xv Z2luX21kLmFzcD9sYW5nPWVuJmlkPVQxMy1TRzE2LTE1MTAxMi1URC1XUDEtMDI3OCEhTVNXLUUg DQoNClRoZSBzY29wZSBvZiB0aGUgSVRVLVQgSC4yNDggV2ViUlRDIGdhdGV3YXkgZnVuY3Rpb24g aXMgYWxpZ25lZCB0byBJRVRGIFJUQ1dFQiByZXF1aXJlbWVudHMgaW4gb3JkZXIgdG8gcHJvdmlk ZSBmdWxsIHN1cHBvcnQgZnJvbSBnYXRld2F5IHNpZGUuIEhlbmNlLCB0aGUgIklUVS1UIEguMjQ4 IFdlYlJUQyBnYXRld2F5IGZ1bmN0aW9uIiByZXByZXNlbnRzIGN1cnJlbnRseSBhIHN1cGVyc2V0 IGluIGNvbXBhcmlzb24gdG8gdGhlICIzR1BQIFJlbC0xMi8xMyBJTVMgSC4yNDggV2ViUlRDIGdh dGV3YXkgZnVuY3Rpb24iLiBBbGwgbWFqb3IgY2FwYWJpbGl0aWVzIGFyZSBzdXBwb3J0ZWQsIGJ1 dCB0aGVyZScgYXJlIGFsc28gc29tZSBkaWZmZXJlbmNlcyAuLi4NCg0KSGFyYWxkLCBkcmFmdCBI LjI0OC45NCAoSC4yNDguV0VCUlRDKSBpcyBhbHJlYWR5IHJlZmVyaW5nIHRvIGRyYWZ0LXJ0Y3dl Yi1nYXRld2F5cywgLSBiZWNhdXNlIHRoZSBILjI0OCBXZWJSVEMgZ2F0ZXdheSBhY3R1YWxseSBq dXN0IHJlYWxpemVzIHN1Y2ggYSBXZWJSVEMgZ2F0ZXdheSBlbnRpdHkgYXMgb3V0bGluZWQgYnkg dGhlIHJ0Y3dlYiBkcmFmdC4NCiANCkJUVzogSSdkIGxpa2UgdG8gdGFrZSB0aGUgY2hhbmNlIHRv IHBvaW50IG91dCBzb21lIGdhdGV3YXkgc3BlY2lmaWMgb2JzZXJ2YXRpb25zLCB3aGljaCBzaG91 bGQgYmUgYWRkcmVzc2VkIGFzIHdlbGwgYnkgdGhlIGdhdGV3YXkgZHJhZnQuIFNlZSBILjI0OC5X RUJSVEMsIEFwcGVuZGl4IEw2IExpdmluZyBMaXN0IOKAkyBEaXN0cmlidXRlZCBUZXh0LW92ZXIt SVAgZW5kcG9pbnRzIGZvciBXZWJSVEMgZGF0YSAndGV4dCcNCg0KQ29taW5nIGJhY2sgdG8gdGhl IG9yaWdpbmFsIHF1ZXN0aW9uOiB3aGV0aGVyIGl0IHNob3VsZCBiZSBJbmZvcm1hdGlvbmFsIG9y IFN0YW5kYXJkcy10cmFjaywgLSBJIGRvbid0IGtub3cuIEJ1dCBpdCBpcyBhcHBhcmVudCB0aGF0 IGJvdGgsIHRoZSAzR1BQIGFuZCBJVFUtVCB3b3JrIG9uIFdlYlJUQyBnYXRld2F5cyBuZWVkcyB0 byBiZSB0aWdodGx5IGNvdXBsZWQgYW5kIGxpbmtlZCB0byB0aGUgSUVURiBnYXRld2F5IGRyYWZ0 IGluIG15IG9waW5pb24uDQoNClJlZ2FyZHMsDQpBbGJyZWNodA0KDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSGFyYWxkIEFsdmVzdHJhbmQNClNlbnQ6IERpZW5zdGFnLCAxNC4g SnVsaSAyMDE1IDA4OjI0DQpUbzogcmFuaml0QHJhbmppdHZvaXAuY29tOyBUZWQgSGFyZGllDQpD YzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gVXBkYXRlZCAtZ2F0ZXdh eXMgZHJhZnQNCg0KRGVuIDE0LiBqdWxpIDIwMTUgMDU6MTgsIHNrcmV2IHJhbmppdEByYW5qaXR2 b2lwLmNvbToNCj4gSGkNCj4gSXQgd291bGQgYmUgZ29vZCBpZiBpdCBpcyBhIHN0YW5kYXJkcyB0 cmFjayBhcyAzR1BQIGRlcGVuZHMgb24gaXQgYW5kIA0KPiBhbGwgaW1wbGVtZW50YXRpb25zIHdv dWxkIGNvbmZpcm0gdG8gaXQgLiBoYXZpbmcgaXQgYXMgSW5mb3JtYXRpb25hbCANCj4gaXMgcmVh bGx5IG5vdCBvZiBtdWNoIHVzZS4NCg0KQ291bGQgeW91IHNoYXJlIHNvbWUgbW9yZSBkZXRhaWwg aGVyZT8NCg0KLSBXaGF0IDNHUFAgc3BlYyBpcyBkZXBlbmRpbmcgb24gaXQ/DQotIFdoYXQgZG9l cyB0aGUgM0dQUCBzcGVjIGRlcGVuZCBvbiBiZWluZyBpbiB0aGUgZHJhZnQ/DQotIFdoYXQncyB0 aGUgcnVsZXMgZm9yIHJlZmVyZW5jaW5nIGFuIElFVEYgc3BlYyBmcm9tIGEgM0dQUCBzcGVjLCBh bmQgd2h5IGRvZXMgdGhlIGNhdGVnb3J5IG1hdHRlcj8NCg0KSGFyYWxkDQoNCg0KPiANCj4gLSBS YW5qaXQNCj4gDQo+IE9uIDIwMTUtMDctMDYgNTozNSBwbSwgVGVkIEhhcmRpZSB3cm90ZToNCj4+ IE9uIE1vbiwgSnVsIDYsIDIwMTUgYXQgMzoxOSBQTSwgSGFyYWxkIEFsdmVzdHJhbmQgDQo+PiA8 aGFyYWxkQGFsdmVzdHJhbmQubm8+IHdyb3RlOg0KPj4NCj4+PiBVd2UgYW5kIEkgaGF2ZSBwcmVw YXJlZCBhIG5ldyAtZ2F0ZXdheXMgZHJhZnQgKHZlcnNpb24gLTAxKS4NCj4+Pg0KPj4+IEkgZG9u J3QgdGhpbmsgdGhlcmUncyBtdWNoIGNvbnRyb3ZlcnNpYWwgaW4gaXQsIGFuZCB0aGVyZSdzIG9u bHkgb25lIA0KPj4+IGlzc3VlIHRoYXQgSSB0aGluayBuZWVkcyBXRyB0aW1lIGF0IHRoaXMgdGlt ZToNCj4+Pg0KPj4+IFNob3VsZCBpdCBiZSBJbmZvcm1hdGlvbmFsIG9yIFN0YW5kYXJkcy10cmFj az8NCj4+Pg0KPj4+IEFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgZGVmaW5lcyBndWlkYW5jZSBm b3IgaG93IGdhdGV3YXlzIHNob3VsZCANCj4+PiBiZWhhdmUsIGJ1dCBub2JvZHkgbmVlZHMgdG8g cGF5IGF0dGVudGlvbiBpZiB0aGV5IGRvbid0IHdhbnQgdG8uDQo+Pj4NCj4+PiBBIHN0YW5kYXJk cy10cmFjayBkb2N1bWVudCAod2hpY2ggbm8gb3RoZXIgUlRDV0VCIGRvY3VtZW50IHNob3VsZCBi ZSANCj4+PiBkZXBlbmRlbnQgb24pIGRlZmluZXMgcmVxdWlyZW1lbnRzIGZvciBob3cgdGhpbmdz IHRoYXQgY2FsbCANCj4+PiB0aGVtc2VsdmVzICJXZWJSVEMgZ2F0ZXdheXMiIHNob3VsZCBiZWhh dmUsIGJ1dCBub2JvZHkgbmVlZHMgdG8gY2FsbCANCj4+PiB0aGVpciBnYXRld2F5cyB0aGF0LCBh bmQgYW55d2F5LCB0aGVyZSdzIG5vIHByb3RvY29sIHBvbGljZSwgc28gdGhlIA0KPj4+IGRpZmZl cmVuY2UgaXNuJ3QgYWxsIHRoYXQgbXVjaCBpbiBwcmFjdGljZS4NCj4+Pg0KPj4+IE1vcmUgaW1w b3J0YW50OiBXaGF0IGRvIHBlb3BsZSB3YW50IGl0IHRvIGJlPw0KPj4NCj4+IOKAi0kgdGhpbmsg d2UgYWRvcHRlZCBpdCBpbiBwYXJ0IGJlY2F1c2UgM0dQUCBoYWQgYSBkZXBlbmRlbmN5IG9uIGl0 Lg0KPj4gRG9lcyBpdCBuZWVkIHRvIGJlIHN0YW5kYXJkcyB0cmFjayBmb3IgdGhlbSB0byByZWZl cmVuY2UgaXQ/DQo+Pg0KPj4gVGVk4oCLDQo+Pg0KPj4+IEhhcmFsZA0KPj4+DQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBydGN3ZWIgbWFp bGluZyBsaXN0DQo+Pj4gcnRjd2ViQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWIgWzFdDQo+Pg0KPj4NCj4+DQo+PiBMaW5rczoNCj4+IC0t LS0tLQ0KPj4gWzFdIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4gDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpy dGN3ZWJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViDQo= From nobody Wed Jul 15 01:50:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7C11A892B for ; Wed, 15 Jul 2015 01:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78VGSXGZkn5H for ; Wed, 15 Jul 2015 01:50:23 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id DF2701A8927 for ; Wed, 15 Jul 2015 01:50:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0D4A07C3A7D; Wed, 15 Jul 2015 10:50:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9eTgPovJ1CB; Wed, 15 Jul 2015 10:50:19 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:3da7:4293:4c8b:1565] (unknown [IPv6:2001:470:de0a:27:3da7:4293:4c8b:1565]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8F61C7C3A0C; Wed, 15 Jul 2015 10:50:19 +0200 (CEST) Message-ID: <55A61ECA.9020008@alvestrand.no> Date: Wed, 15 Jul 2015 10:50:18 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" , "ranjit@ranjitvoip.com" , Ted Hardie References: <559AFEDB.4070205@alvestrand.no> <55A4AAEE.6090007@alvestrand.no> <786615F3A85DF44AA2A76164A71FE1AC7ADA8882@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC7ADA8882@FR711WXCHMBA03.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated -gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 08:50:26 -0000 Thank you very much for this information! It would seem to me to make sense to have an informative reference from the gateway draft to the H.248.WEBRTC draft, so that people can find a real worked example of such a gateway. The text-over-IP specification would seem to require additional work outside the scope of RTCWEB - this has been discussed before, and the decision was to declare it out of scope. I think this will be typical for applications that connect to gateways - they will require more things than just WebRTC for a complete specification; thus, having the example to point to is a Good Thing. Harald Den 15. juli 2015 10:02, skrev Schwarz, Albrecht (Albrecht): > Dear All, > some background info: > > the 3GPP architecture provides a WebRTC gateway function (since 3GPP Release 12). > The 3GPP WebRTC gateway entity is based on the decomposed gateway model according ITU-T H.248, i.e., H.248 is used as (vertical) gateway control protocol. > The 3GPP WebRTC gateway function is mapped on the existing 3GPP P-CSCF/IMS-ALG entity ("the controller part") and the IMS access gateway ("the media gateway part"). > Thus, the 3GPP WebRTC gateway represents actually an "IMS WebRTC gateway" (in Rel-12 and 13). > > The 3GPP specs (from WebRTC gateway perspective) are > a) 3GPP 23.334, which covers signalling requirements and procedures for the gateway control interface and > b) 3GPP 29.334, which specifies the protocol solution, known as so called "H.248 profile specification" (in context of H.248). > > The 3GPP WebRTC gateway work is complemented by ITU-T SG16, as the technology owner of the H.248 protocol, as responsible instance for the development of H.248 protocol extensions (called H.248 packages). > > The associated ITU-T work item is "H.248.WEBRTC", - and there will be a first Recommendation for "H.248 WebRTC gateways" soon, under Rec number ITU-T H.248.94. > The June draft may be found under: > http://wftp3.itu.int/av-arch/avc-site/2013-2016/1506_Che/TD-11.zip > The October meeting input for next IETU-T meeting is available (for ITU-T delegates) under: > https://www.itu.int/md/dologin_md.asp?lang=en&id=T13-SG16-151012-TD-WP1-0278!!MSW-E > > The scope of the ITU-T H.248 WebRTC gateway function is aligned to IETF RTCWEB requirements in order to provide full support from gateway side. Hence, the "ITU-T H.248 WebRTC gateway function" represents currently a superset in comparison to the "3GPP Rel-12/13 IMS H.248 WebRTC gateway function". All major capabilities are supported, but there' are also some differences ... > > Harald, draft H.248.94 (H.248.WEBRTC) is already refering to draft-rtcweb-gateways, - because the H.248 WebRTC gateway actually just realizes such a WebRTC gateway entity as outlined by the rtcweb draft. > > BTW: I'd like to take the chance to point out some gateway specific observations, which should be addressed as well by the gateway draft. See H.248.WEBRTC, Appendix L6 Living List – Distributed Text-over-IP endpoints for WebRTC data 'text' > > Coming back to the original question: whether it should be Informational or Standards-track, - I don't know. But it is apparent that both, the 3GPP and ITU-T work on WebRTC gateways needs to be tightly coupled and linked to the IETF gateway draft in my opinion. > > Regards, > Albrecht > > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: Dienstag, 14. Juli 2015 08:24 > To: ranjit@ranjitvoip.com; Ted Hardie > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Updated -gateways draft > > Den 14. juli 2015 05:18, skrev ranjit@ranjitvoip.com: >> Hi >> It would be good if it is a standards track as 3GPP depends on it and >> all implementations would confirm to it . having it as Informational >> is really not of much use. > > Could you share some more detail here? > > - What 3GPP spec is depending on it? > - What does the 3GPP spec depend on being in the draft? > - What's the rules for referencing an IETF spec from a 3GPP spec, and why does the category matter? > > Harald > > >> >> - Ranjit >> >> On 2015-07-06 5:35 pm, Ted Hardie wrote: >>> On Mon, Jul 6, 2015 at 3:19 PM, Harald Alvestrand >>> wrote: >>> >>>> Uwe and I have prepared a new -gateways draft (version -01). >>>> >>>> I don't think there's much controversial in it, and there's only one >>>> issue that I think needs WG time at this time: >>>> >>>> Should it be Informational or Standards-track? >>>> >>>> An informational document defines guidance for how gateways should >>>> behave, but nobody needs to pay attention if they don't want to. >>>> >>>> A standards-track document (which no other RTCWEB document should be >>>> dependent on) defines requirements for how things that call >>>> themselves "WebRTC gateways" should behave, but nobody needs to call >>>> their gateways that, and anyway, there's no protocol police, so the >>>> difference isn't all that much in practice. >>>> >>>> More important: What do people want it to be? >>> >>> ​I think we adopted it in part because 3GPP had a dependency on it. >>> Does it need to be standards track for them to reference it? >>> >>> Ted​ >>> >>>> Harald >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb [1] >>> >>> >>> >>> Links: >>> ------ >>> [1] https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> _______________________________________________ >>> 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 > From nobody Wed Jul 15 05:38:06 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A231A8A83 for ; Wed, 15 Jul 2015 05:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyQKnHlgipsH for ; Wed, 15 Jul 2015 05:38:00 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EDF1A8A61 for ; Wed, 15 Jul 2015 05:37:59 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t6FCc3gl025561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Jul 2015 14:38:03 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t6FCc31J025560 for rtcweb@ietf.org; Wed, 15 Jul 2015 14:38:03 +0200 Date: Wed, 15 Jul 2015 14:38:03 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150715123803.GA24976@lo.psyced.org> References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150421154657.GA4071@lo.psyced.org> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 12:38:03 -0000 It's not such a big deal, even casual readers understand the problem and suggest the simple solution: Someone called Michael writes: "local ip doesn’t seem that useful for marketers except as a user fingerprinting tool. They already have your public ip, this helps them differentiate between people behind nat. it’s a bit icky but not such a big deal. This issue blows up again when someone starts using it maliciously, which I’m sure will happen soon enough. I don’t get why exactly we don’t just prompt for this the same way we do camera and mic, it wouldn’t be a huge deal to work that into the spec. That being said, I don’t think it’s actually as big of a deal as it has been made either" (from https://bloggeek.me/webrtc-new-york-times/ - yet another privacy issue with mainstream web browsers, this time thanks to webrtc) The reason why this is a big deal is because they do NOT already have the public IP for some people and de-anonymizing Tor or VPN users can have life-threatening consequences as described below. Let me look at your official statements on the topic: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#page-15 says on the topic of "5.4. IP Location Privacy" : "The API MUST provide a mechanism to allow the JS to suppress ICE negotiation (though perhaps to allow candidate gathering) until the user has decided to answer the call" Eh? This is not solving the problem at all since the JS isn't in the slightest trustworthy. "The API MUST provide a mechanism for the calling application JS to indicate that only TURN candidates are to be used." Dito. "The API MUST provide a mechanism for the calling application to reconfigure an existing call to add non-TURN candidates. Taken together, this and the previous requirement allow ICE negotiation to start immediately on incoming call notification, thus reducing post-dial delay, but also to avoid disclosing the user's IP address until they have decided to answer." Yet nothing of it actually solves the issue it is supposed to solve, protecting IP Location Privacy, except when the involved websites are interested in protecting users from each other - which is just the least interesting threat model case. Further below you wrote: "Note that the protections provided here assume a non-malicious calling service. As the calling service always knows the users status and (absent the use of a technology like Tor) their IP address, they can violate the users privacy at will. Users who wish privacy against the calling sites they are using must use separate privacy enhancing technologies such as Tor. Combined WebRTC/Tor implementations SHOULD arrange to route the media as well as the signaling through Tor. Currently this will produce very suboptimal performance." Performance is irrelevant here. The problem is that WebRTC APIs are available for abuse even if people are not in the slightest interested in making actual use of them. The entire security assessment document is bypassing the real threat, as if Tor by itself could solve all problems and it were enough to just mention it. So I'll repeat Michael's sort-of key question: "I don’t get why exactly we don’t just prompt for this the same way we do camera and mic," It could be a single transaction, asking the user to allow access to all three things in order to allow for rtc apps to be initiated. There isn't even a need to make an *additional* prompt. On Tue, Apr 21, 2015 at 05:46:58PM +0200, carlo von lynX wrote: > Envision the typical young dissident with his Windows PC using > some VPN to access critical information. My impression is these > folks are not aware of how much safer they could be by using > TBB with Tor bridges, and for their purposes all the risks of > getting fingerprinted aren't even relevant *as long as the > authorities can't find a way to follow the fingerprinted browser > to its physical position* (something the NSA probably can, but > the NSA is outside of this threat model). So until everyone in > their social surroundings hasn't been taken away to prison, they > will continue as always - and if the web browser in the meantime > has introduced a way for authorities to reveal their whereabouts, > that could cost some lives. > > Possibly all the other bugs in the JS "security" model are not > half as dangerous to these people than the ability for an authority > to inject JS code that will reveal the physical IP number of a > dissident. > > Correct me if I got something wrong but to me it looks like we > have a serious case of lives at risk, in particular since this > weakness is now known to the general public.. those authorities > may be slow and dissidents like to make fun of them in order to > feel less helpless.. but these authorities might just pick any > time soon to start flying webrtc drones into living people. > > I hope I got something wrong. If nobody answered, I must assume I didn't get anything wrong (otherwise somebody would have been proud to show me how wrong I am). No, there exists no technology mailing list that doesn't have a political aspect to it, because technology is political at all times. But of course you can go on pretending people like me are a big bunch of trolls.. amazing how many trolls there are out there. Try facing the responsibility that lies upon you and you alone because corporations are by definition non-ethical. You, the technician, are the only ethical element in the equation. If you don't speak up on this issue, you will be responsible. Time is not on your side and the later you act, the more expensive it will get. Acting irresponsible now will harm the public image of WebRTC more and more. As Michael suggests it is only a question of time until some wikileak tells a story of WebRTC being abused for catching dissidents, or whatever else could possibly go wrong. I don't care, I don't have any stakes in this business. I don't mind if more browsers follow the good example of Torbrowser to disable WebRTC entirely. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Wed Jul 15 06:49:01 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6908A1A90D1 for ; Wed, 15 Jul 2015 06:48:59 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmjuU6DBxDke for ; Wed, 15 Jul 2015 06:48:56 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D601A90F3 for ; Wed, 15 Jul 2015 06:48:55 -0700 (PDT) Received: (qmail 50536 invoked from network); 15 Jul 2015 13:48:53 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 8339 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 15 Jul 2015 13:48:53 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id CD9D818A1402; Wed, 15 Jul 2015 14:48:51 +0100 (BST) Received: from [192.168.1.188] (178-22-142-142.sw.telcom.network [178.22.142.142]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B102218A121C; Wed, 15 Jul 2015 14:48:51 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: tim panton In-Reply-To: <20150715123803.GA24976@lo.psyced.org> Date: Wed, 15 Jul 2015 14:48:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> To: carlo von lynX X-Mailer: Apple Mail (2.2102) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 13:48:59 -0000 There are 4 ip addresses involved here - Lets assume a user with a PC - wifi connected to an ADSL router and = using a VPN 1) External VPN address : the IP address of the exit node from the VPN - = this is already known to everyone. 2) Internal VPN address : the IP address of the VPN interface on the PC = end of the VPN tunnel - not known - but not =E2=80=98secret' 3) ISP address : the address allocated by the ISP for the ADSL router - = this is the one that TOR and other VPNs mask 4) local IP address: the address returned by the router - typically = 192.168.0.2 or some such - this is not known=20 With current VPN configs (and I assume TOR) webRTC reveals all of these. The critical one is ISP address (correct me if I=E2=80=99m wrong) - = This can reveal location and identity via the ISP=E2=80=99s business = database. A small change to the VPN configuration will hide the ISP address - you = just have to set the default route to 2) rather than 3) then the STUN queries will return the external VPN address - which is = what you revealed anyway by loading the page. 'Just ask the user to enable webRTC' is a sledgehammer to crack a nut.=20= You are forgoing the huge advantages (including privacy) of P2P crypto = in webRTC just because the existing VPN=20 suppliers can=E2=80=99t figure out a default route and update their = scripts. The cynical part of me wonders if people with skin in the VPN game = don=E2=80=99t want an easy to use P2P crypto in the browser=E2=80=A6.. Tim. P.S. actually I=E2=80=99m =E2=80=98surprisingly reasonable=E2=80=99 in = person - so I=E2=80=99m happy to discuss off-line if that helps. P.P.S I have a second rant about why you want P2P to travel over the = local net where possible - but that can wait=E2=80=A6. > On 15 Jul 2015, at 13:38, carlo von lynX = wrote: >=20 > It's not such a big deal, even casual readers understand the > problem and suggest the simple solution: >=20 > Someone called Michael writes: > "local ip doesn=E2=80=99t seem that useful for marketers except as = a user fingerprinting tool. They already have your public ip, this helps = them differentiate between people behind nat. it=E2=80=99s a bit icky = but not such a big deal. This issue blows up again when someone starts = using it maliciously, which I=E2=80=99m sure will happen soon enough. I = don=E2=80=99t get why exactly we don=E2=80=99t just prompt for this the = same way we do camera and mic, it wouldn=E2=80=99t be a huge deal to = work that into the spec. That being said, I don=E2=80=99t think it=E2=80=99= s actually as big of a deal as it has been made either" >=20 > (from https://bloggeek.me/webrtc-new-york-times/ - yet another privacy > issue with mainstream web browsers, this time thanks to webrtc) >=20 > The reason why this is a big deal is because they do NOT already have=20= > the public IP for some people and de-anonymizing Tor or VPN users can > have life-threatening consequences as described below. > Let me look at your official statements on the topic: >=20 > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#page-15 > says on the topic of "5.4. IP Location Privacy" : >=20 > "The API MUST provide a mechanism to allow the JS to > suppress ICE negotiation (though perhaps to allow candidate > gathering) until the user has decided to answer the call" >=20 > Eh? This is not solving the problem at all since the JS isn't in > the slightest trustworthy. >=20 > "The API MUST provide a mechanism for the calling application=20 > JS to indicate that only TURN candidates are to be used." >=20 > Dito. >=20 > "The API MUST provide a mechanism for the calling > application to reconfigure an existing call to add non-TURN > candidates. Taken together, this and the previous requirement > allow ICE negotiation to start immediately on incoming call > notification, thus reducing post-dial delay, but also to avoid > disclosing the user's IP address until they have decided to > answer." >=20 > Yet nothing of it actually solves the issue it is supposed to solve, > protecting IP Location Privacy, except when the involved websites > are interested in protecting users from each other - which is just > the least interesting threat model case. >=20 > Further below you wrote: >=20 > "Note that the protections provided here assume a non-malicious > calling service. As the calling service always knows the users > status and (absent the use of a technology like Tor) their IP > address, they can violate the users privacy at will. Users who wish > privacy against the calling sites they are using must use separate > privacy enhancing technologies such as Tor. Combined WebRTC/Tor > implementations SHOULD arrange to route the media as well as the > signaling through Tor. Currently this will produce very suboptimal > performance." >=20 > Performance is irrelevant here. The problem is that WebRTC APIs are > available for abuse even if people are not in the slightest interested > in making actual use of them. The entire security assessment document > is bypassing the real threat, as if Tor by itself could solve all > problems and it were enough to just mention it. >=20 > So I'll repeat Michael's sort-of key question: >=20 > "I don=E2=80=99t get why exactly we don=E2=80=99t just prompt for = this the same way we do camera and mic," >=20 > It could be a single transaction, asking the user to allow access to > all three things in order to allow for rtc apps to be initiated. > There isn't even a need to make an *additional* prompt. >=20 > On Tue, Apr 21, 2015 at 05:46:58PM +0200, carlo von lynX wrote: >> Envision the typical young dissident with his Windows PC using >> some VPN to access critical information. My impression is these >> folks are not aware of how much safer they could be by using >> TBB with Tor bridges, and for their purposes all the risks of >> getting fingerprinted aren't even relevant *as long as the >> authorities can't find a way to follow the fingerprinted browser >> to its physical position* (something the NSA probably can, but >> the NSA is outside of this threat model). So until everyone in=20 >> their social surroundings hasn't been taken away to prison, they=20 >> will continue as always - and if the web browser in the meantime >> has introduced a way for authorities to reveal their whereabouts, >> that could cost some lives. >>=20 >> Possibly all the other bugs in the JS "security" model are not=20 >> half as dangerous to these people than the ability for an authority >> to inject JS code that will reveal the physical IP number of a >> dissident. >>=20 >> Correct me if I got something wrong but to me it looks like we >> have a serious case of lives at risk, in particular since this >> weakness is now known to the general public.. those authorities >> may be slow and dissidents like to make fun of them in order to >> feel less helpless.. but these authorities might just pick any=20 >> time soon to start flying webrtc drones into living people. >>=20 >> I hope I got something wrong. >=20 > If nobody answered, I must assume I didn't get anything wrong > (otherwise somebody would have been proud to show me how wrong I am). >=20 > No, there exists no technology mailing list that doesn't have > a political aspect to it, because technology is political at all > times. But of course you can go on pretending people like me are > a big bunch of trolls.. amazing how many trolls there are out there. >=20 > Try facing the responsibility that lies upon you and you alone > because corporations are by definition non-ethical. You, the > technician, are the only ethical element in the equation. If you > don't speak up on this issue, you will be responsible. Time is > not on your side and the later you act, the more expensive it > will get. Acting irresponsible now will harm the public image > of WebRTC more and more. As Michael suggests it is only a question > of time until some wikileak tells a story of WebRTC being abused > for catching dissidents, or whatever else could possibly go wrong. >=20 > I don't care, I don't have any stakes in this business. I don't=20 > mind if more browsers follow the good example of Torbrowser to=20 > disable WebRTC entirely. >=20 >=20 > --=20 > E-mail is public! Talk to me in private using encryption: > http://loupsycedyglgamf.onion/LynX/ > irc://loupsycedyglgamf.onion:67/lynX > https://psyced.org:34443/LynX/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Jul 15 06:52:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EDD1A90F9 for ; Wed, 15 Jul 2015 06:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TKDq8HzAu7Z for ; Wed, 15 Jul 2015 06:52:56 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04D01A90EE for ; Wed, 15 Jul 2015 06:52:55 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so41567145wic.1 for ; Wed, 15 Jul 2015 06:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=i1HxuZrBd7uln1cVJHeAeMxJJ7aZfov5OeXbAimnmH0=; b=cwUh3HHrobiw7B/Mn1LxgGJWZj0uK2VTiJZ8LNAA4w3IxHxWy7tMK5lIP/lRcB5Des 6rdPKfKMLplW3MmXCYihPZt8PluPyfec5v3l5EY9hvIbxzXlhGz9YRYOpzIZP/7ITGqO VbZ844vvAl9MAZXyK7FJBNbuUfzJFK5CcwpCf1wbhtJWITxCrGpL9GrW3LZj95YII+qj Rh3qfakKt6tLMAfzAMeRWsyNXMjEq6eNmj9CQTA484B3Ut36MY4voIWql1hccn6SbGx1 P2a+X+aJg+uXhwDaFAr8QbsVkWhxh56CkOaRqN0KpWVwulBvtv2Xyej850ux+Hp1mPur J6xw== X-Received: by 10.180.210.177 with SMTP id mv17mr16036591wic.90.1436968374502; Wed, 15 Jul 2015 06:52:54 -0700 (PDT) Received: from [192.168.1.46] (28.Red-79-144-16.dynamicIP.rima-tde.net. [79.144.16.28]) by smtp.googlemail.com with ESMTPSA id ju2sm9234891wid.12.2015.07.15.06.52.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jul 2015 06:52:53 -0700 (PDT) To: rtcweb@ietf.org References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> From: Sergio Garcia Murillo Message-ID: <55A665BB.9050103@gmail.com> Date: Wed, 15 Jul 2015 15:52:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 13:52:59 -0000 +1 I would add another type for completeness: 5) external HTTP Proxy, which behaves like 1) Best regards Sergio On 15/07/2015 15:48, tim panton wrote: > > There are 4 ip addresses involved here - > Lets assume a user with a PC - wifi connected to an ADSL router and using a VPN > > 1) External VPN address : the IP address of the exit node from the VPN - this is already known to everyone. > 2) Internal VPN address : the IP address of the VPN interface on the PC end of the VPN tunnel - not known - but not ‘secret' > 3) ISP address : the address allocated by the ISP for the ADSL router - this is the one that TOR and other VPNs mask > 4) local IP address: the address returned by the router - typically 192.168.0.2 or some such - this is not known > > With current VPN configs (and I assume TOR) webRTC reveals all of these. > The critical one is ISP address (correct me if I’m wrong) - This can reveal location and identity via the ISP’s business database. > > A small change to the VPN configuration will hide the ISP address - you just have to set the default route to 2) rather than 3) > then the STUN queries will return the external VPN address - which is what you revealed anyway by loading the page. > > 'Just ask the user to enable webRTC' is a sledgehammer to crack a nut. > > You are forgoing the huge advantages (including privacy) of P2P crypto in webRTC just because the existing VPN > suppliers can’t figure out a default route and update their scripts. > > The cynical part of me wonders if people with skin in the VPN game don’t want an easy to use P2P crypto in the browser….. > > > Tim. > P.S. actually I’m ‘surprisingly reasonable’ in person - so I’m happy to discuss off-line if that helps. > P.P.S I have a second rant about why you want P2P to travel over the local net where possible - but that can wait…. > > >> On 15 Jul 2015, at 13:38, carlo von lynX wrote: >> >> It's not such a big deal, even casual readers understand the >> problem and suggest the simple solution: >> >> Someone called Michael writes: >> "local ip doesn’t seem that useful for marketers except as a user fingerprinting tool. They already have your public ip, this helps them differentiate between people behind nat. it’s a bit icky but not such a big deal. This issue blows up again when someone starts using it maliciously, which I’m sure will happen soon enough. I don’t get why exactly we don’t just prompt for this the same way we do camera and mic, it wouldn’t be a huge deal to work that into the spec. That being said, I don’t think it’s actually as big of a deal as it has been made either" >> >> (from https://bloggeek.me/webrtc-new-york-times/ - yet another privacy >> issue with mainstream web browsers, this time thanks to webrtc) >> >> The reason why this is a big deal is because they do NOT already have >> the public IP for some people and de-anonymizing Tor or VPN users can >> have life-threatening consequences as described below. >> Let me look at your official statements on the topic: >> >> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#page-15 >> says on the topic of "5.4. IP Location Privacy" : >> >> "The API MUST provide a mechanism to allow the JS to >> suppress ICE negotiation (though perhaps to allow candidate >> gathering) until the user has decided to answer the call" >> >> Eh? This is not solving the problem at all since the JS isn't in >> the slightest trustworthy. >> >> "The API MUST provide a mechanism for the calling application >> JS to indicate that only TURN candidates are to be used." >> >> Dito. >> >> "The API MUST provide a mechanism for the calling >> application to reconfigure an existing call to add non-TURN >> candidates. Taken together, this and the previous requirement >> allow ICE negotiation to start immediately on incoming call >> notification, thus reducing post-dial delay, but also to avoid >> disclosing the user's IP address until they have decided to >> answer." >> >> Yet nothing of it actually solves the issue it is supposed to solve, >> protecting IP Location Privacy, except when the involved websites >> are interested in protecting users from each other - which is just >> the least interesting threat model case. >> >> Further below you wrote: >> >> "Note that the protections provided here assume a non-malicious >> calling service. As the calling service always knows the users >> status and (absent the use of a technology like Tor) their IP >> address, they can violate the users privacy at will. Users who wish >> privacy against the calling sites they are using must use separate >> privacy enhancing technologies such as Tor. Combined WebRTC/Tor >> implementations SHOULD arrange to route the media as well as the >> signaling through Tor. Currently this will produce very suboptimal >> performance." >> >> Performance is irrelevant here. The problem is that WebRTC APIs are >> available for abuse even if people are not in the slightest interested >> in making actual use of them. The entire security assessment document >> is bypassing the real threat, as if Tor by itself could solve all >> problems and it were enough to just mention it. >> >> So I'll repeat Michael's sort-of key question: >> >> "I don’t get why exactly we don’t just prompt for this the same way we do camera and mic," >> >> It could be a single transaction, asking the user to allow access to >> all three things in order to allow for rtc apps to be initiated. >> There isn't even a need to make an *additional* prompt. >> >> On Tue, Apr 21, 2015 at 05:46:58PM +0200, carlo von lynX wrote: >>> Envision the typical young dissident with his Windows PC using >>> some VPN to access critical information. My impression is these >>> folks are not aware of how much safer they could be by using >>> TBB with Tor bridges, and for their purposes all the risks of >>> getting fingerprinted aren't even relevant *as long as the >>> authorities can't find a way to follow the fingerprinted browser >>> to its physical position* (something the NSA probably can, but >>> the NSA is outside of this threat model). So until everyone in >>> their social surroundings hasn't been taken away to prison, they >>> will continue as always - and if the web browser in the meantime >>> has introduced a way for authorities to reveal their whereabouts, >>> that could cost some lives. >>> >>> Possibly all the other bugs in the JS "security" model are not >>> half as dangerous to these people than the ability for an authority >>> to inject JS code that will reveal the physical IP number of a >>> dissident. >>> >>> Correct me if I got something wrong but to me it looks like we >>> have a serious case of lives at risk, in particular since this >>> weakness is now known to the general public.. those authorities >>> may be slow and dissidents like to make fun of them in order to >>> feel less helpless.. but these authorities might just pick any >>> time soon to start flying webrtc drones into living people. >>> >>> I hope I got something wrong. >> If nobody answered, I must assume I didn't get anything wrong >> (otherwise somebody would have been proud to show me how wrong I am). >> >> No, there exists no technology mailing list that doesn't have >> a political aspect to it, because technology is political at all >> times. But of course you can go on pretending people like me are >> a big bunch of trolls.. amazing how many trolls there are out there. >> >> Try facing the responsibility that lies upon you and you alone >> because corporations are by definition non-ethical. You, the >> technician, are the only ethical element in the equation. If you >> don't speak up on this issue, you will be responsible. Time is >> not on your side and the later you act, the more expensive it >> will get. Acting irresponsible now will harm the public image >> of WebRTC more and more. As Michael suggests it is only a question >> of time until some wikileak tells a story of WebRTC being abused >> for catching dissidents, or whatever else could possibly go wrong. >> >> I don't care, I don't have any stakes in this business. I don't >> mind if more browsers follow the good example of Torbrowser to >> disable WebRTC entirely. >> >> >> -- >> E-mail is public! Talk to me in private using encryption: >> http://loupsycedyglgamf.onion/LynX/ >> irc://loupsycedyglgamf.onion:67/lynX >> https://psyced.org:34443/LynX/ >> >> _______________________________________________ >> 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 From nobody Wed Jul 15 07:40:10 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B9B1AC3A1 for ; Wed, 15 Jul 2015 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fazVv9njvvnJ for ; Wed, 15 Jul 2015 07:40:08 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B8E1AC3AB for ; Wed, 15 Jul 2015 07:40:04 -0700 (PDT) Received: by qkdv3 with SMTP id v3so29439883qkd.3 for ; Wed, 15 Jul 2015 07:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q4Iws5a7vmLI83YH1gk24j5MkaRQkDzpF380Vz7zkQ8=; b=Lyt8QzRrPwTLXIvlZ0SurOCgDpVhS7EqwhoyV38mNsRvtleE2HQkYRrgYhBu7JMMoy Br7GQQFCjqb4eeuGyMZ31Wixwo7fQHMD2KJr6pKaj7scDri5ShS8ZawxIJOcxX14EuoW +WnQoWX+J2/RzEhCxcFuoamvk3OPp6fpPIWLP3/mtBrlvCb18z1W1bwGLOcnUBggtXFc 21WSctHcqgCgYjpi+xbaxxtFY5a+oWXUM1mHWdCZC0x926MgZTe2NZ0fuDA1xtr3yXoi h4O/CenI28sUUSPdHL3BBuN+8o5PU8oXXn2bQIDKs/ohiuUD7wmeoJpyYq70jGp030T3 rhcg== MIME-Version: 1.0 X-Received: by 10.55.48.133 with SMTP id w127mr8830208qkw.53.1436971203866; Wed, 15 Jul 2015 07:40:03 -0700 (PDT) Received: by 10.140.108.130 with HTTP; Wed, 15 Jul 2015 07:40:03 -0700 (PDT) Received: by 10.140.108.130 with HTTP; Wed, 15 Jul 2015 07:40:03 -0700 (PDT) In-Reply-To: <20150715123803.GA24976@lo.psyced.org> References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> Date: Wed, 15 Jul 2015 07:40:03 -0700 Message-ID: From: Daniel Roesler To: carlo von lynX Content-Type: multipart/alternative; boundary=001a1149781c28c80a051aeaee29 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 14:40:09 -0000 --001a1149781c28c80a051aeaee29 Content-Type: text/plain; charset=UTF-8 On Jul 15, 2015 5:38 AM, "carlo von lynX" wrote: > > As Michael suggests it is only a question > of time until some wikileak tells a story of WebRTC being abused > for catching dissidents, or whatever else could possibly go wrong. > > I don't care, I don't have any stakes in this business. I don't > mind if more browsers follow the good example of Torbrowser to > disable WebRTC entirely. > FYI, in the leaked Hacking Team emails, they discussed using the WebRTC exploit. https://wikileaks.org/hackingteam/emails/emailid/119217 --001a1149781c28c80a051aeaee29 Content-Type: text/html; charset=UTF-8

On Jul 15, 2015 5:38 AM, "carlo von lynX" <lynX@i.know.you.are.psyced.org> wrote:
>
> As Michael suggests it is only a question
> of time until some wikileak tells a story of WebRTC being abused
> for catching dissidents, or whatever else could possibly go wrong.
>
> I don't care, I don't have any stakes in this business. I don't
> mind if more browsers follow the good example of Torbrowser to
> disable WebRTC entirely.
>

FYI, in the leaked Hacking Team emails, they discussed using the WebRTC exploit.

https://wikileaks.org/hackingteam/emails/emailid/119217

--001a1149781c28c80a051aeaee29-- From nobody Wed Jul 15 08:42:36 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5957A1ACE73 for ; Wed, 15 Jul 2015 08:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6jVL9QhQ8O1 for ; Wed, 15 Jul 2015 08:42:33 -0700 (PDT) Received: from smtp73.ord1c.emailsrvr.com (smtp73.ord1c.emailsrvr.com [108.166.43.73]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA5C1ACE71 for ; Wed, 15 Jul 2015 08:42:33 -0700 (PDT) Received: from smtp2.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 8FADD1800E3; Wed, 15 Jul 2015 11:42:32 -0400 (EDT) Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E1D331803A0; Wed, 15 Jul 2015 11:42:31 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from foo.ca (d204-191-202-154.abhsia.telus.net [204.191.202.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Wed, 15 Jul 2015 15:42:32 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Cullen Jennings In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC7ADA8882@FR711WXCHMBA03.zeu.alcatel-lucent.com> Date: Wed, 15 Jul 2015 09:42:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4F5BED26-28A6-4634-9AA7-EAF3BA8888BA@iii.ca> References: <559AFEDB.4070205@alvestrand.no> <55A4AAEE.6090007@alvestrand.no> <786615F3A85DF44AA2A76164A71FE1AC7ADA8882@FR711WXCHMBA03.zeu.alcatel-lucent.com> To: "Schwarz, Albrecht (Albrecht)" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated -gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 15:42:34 -0000 > On Jul 15, 2015, at 2:02 AM, Schwarz, Albrecht (Albrecht) = wrote: >=20 > Coming back to the original question: whether it should be = Informational or Standards-track, - I don't know. But it is apparent = that both, the 3GPP and ITU-T work on WebRTC gateways needs to be = tightly coupled and linked to the IETF gateway draft in my opinion. I'd be happy for Keith to correct me but my understanding is that 3GPP = does not really differentiate much on the RFC track and can have = normative references to informational RFC.=20 From nobody Wed Jul 15 09:41:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C315A1A87B9 for ; Wed, 15 Jul 2015 09:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.189 X-Spam-Level: * X-Spam-Status: No, score=1.189 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_44=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffmTbQaQTGRR for ; Wed, 15 Jul 2015 09:41:24 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D524D1A1B76 for ; Wed, 15 Jul 2015 09:41:23 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t6FGfVZK029639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Jul 2015 18:41:32 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t6FGfViB029638 for rtcweb@ietf.org; Wed, 15 Jul 2015 18:41:31 +0200 Date: Wed, 15 Jul 2015 18:41:30 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150715164129.GA27105@lo.psyced.org> References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 16:41:25 -0000 Concerning the HT mail, of course they find a local IP of little interest when you already p0wn the entire computer. On Wed, Jul 15, 2015 at 02:48:52PM +0100, tim panton wrote: > You are welcome to rant AFTER you have done your homework. Instead you postponed it by several weeks which made it worse. > There are 4 ip addresses involved here - > Lets assume a user with a PC - wifi connected to an ADSL router and using a VPN > > 1) External VPN address : the IP address of the exit node from the VPN - this is already known to everyone. > 2) Internal VPN address : the IP address of the VPN interface on the PC end of the VPN tunnel - not known - but not ‘secret' > 3) ISP address : the address allocated by the ISP for the ADSL router - this is the one that TOR and other VPNs mask > 4) local IP address: the address returned by the router - typically 192.168.0.2 or some such - this is not known > > With current VPN configs (and I assume TOR) webRTC reveals all of these. > The critical one is ISP address (correct me if I’m wrong) - This can reveal location and identity via the ISP’s business database. Point one, all of this discussion and explanation belongs into draft-ietf-rtcweb-security-arch. That is your homework for today. > A small change to the VPN configuration will hide the ISP address - you just have to set the default route to 2) rather than 3) > then the STUN queries will return the external VPN address - which is what you revealed anyway by loading the page. This does not sound like something your average Egyptian dissident will be able and sufficiently early informed about to go about. I frequently see this pattern of saying privacy problem X can be solved by manual intervention Y and it is not our problem if the general public will be unable to do such a manual intervention. Yes it is your problem. It is not okay to dismiss problems this way. Also the "solution" you suggest AFAIU does not work for people who use Tor in a non-NATted environment, for example on a fixed system in a university library with a static IP address. We know that browsers will allow fingerprinting even through Tor but it is a different calibre of problem if a browser actually allows the attacker to find out the REAL public IP of a person. > 'Just ask the user to enable webRTC' is a sledgehammer to crack a nut. No. It's like asking the user to click on the telephone icon before making a phone call. It is normal. What is abnormal is to have a web browser that is supposed to browse the web be enabled to do crazy non-web things without asking anyone. You guys are completely losing the perspective of normal human beings. And it's nothing new, you know these documents yourself: https://www.torproject.org/projects/torbrowser/design/#proxy-obedience WebRTC not respecting SOCKS configuration is a huge no-go. https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability And if local IP information is so super harmless, then why is it an obvious reason for TBB devs to disable the entire thing? I presume for the reasons I stated before. So when you do your homework please include all the points that I am making. Add your solid arguments to counter them. > You are forgoing the huge advantages (including privacy) of P2P crypto in webRTC just because the existing VPN > suppliers can’t figure out a default route and update their scripts. I don't know about VPN suppliers, I never used any VPN really, but it sounds like you have a moral obligation to venture out and inform them about the security problem you are introducing and to make sure they protect their users before anyone gets harmed. Also don't tell me any fairy tales about P2P crypto in web browsers. There is no architectural way you can provide E2E crypto that isn't in one way or another MITM'able by the involved servers. You are at *best* adding to the choice of opportunistic cryptography. Don't be so excessively proud of that considering that REAL P2P with REAL E2E authentication is out there and would have deserved better attention. > The cynical part of me wonders if people with skin in the VPN game don’t want an easy to use P2P crypto in the browser….. No idea about that, but I am certain the number of people with skin in the WebRTC game are in the majority on this mailing list - and you wouldn't like to be ignored in any privacy debate a priori just because you're in the WebRTC game, right? But if you go on this way, that is likely to be the outcome. By the time you start thinking of the consequences of your actions your credibility may already be gone downhill. > Thanks for exposing your feelings. > P.S. actually I’m ‘surprisingly reasonable’ in person - so I’m happy to discuss off-line if that helps. Me too, but this is very much on topic. > P.P.S I have a second rant about why you want P2P to travel over the local net where possible - but that can wait…. I already have P2P over the local net, so the local IP is indeed relevant in my configuration. From nobody Wed Jul 15 12:13:02 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744D91B29DB for ; Wed, 15 Jul 2015 12:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qNFUq_yAgCi for ; Wed, 15 Jul 2015 12:13:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40511B29DC for ; Wed, 15 Jul 2015 12:12:59 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id A943A1CE66293; Wed, 15 Jul 2015 19:12:54 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6FJCuMD028216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jul 2015 21:12:56 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 15 Jul 2015 21:12:56 +0200 From: "DRAGE, Keith (Keith)" To: Cullen Jennings , "Schwarz, Albrecht (Albrecht)" Thread-Topic: [rtcweb] Updated -gateways draft Thread-Index: AQHQuDnNhUB+gKZGCEGsm9l6KlhvuZ3aV0CLgAASBwCAAa3qgIAAgI4AgABLZDA= Date: Wed, 15 Jul 2015 19:12:56 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69742078@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <559AFEDB.4070205@alvestrand.no> <55A4AAEE.6090007@alvestrand.no> <786615F3A85DF44AA2A76164A71FE1AC7ADA8882@FR711WXCHMBA03.zeu.alcatel-lucent.com> <4F5BED26-28A6-4634-9AA7-EAF3BA8888BA@iii.ca> In-Reply-To: <4F5BED26-28A6-4634-9AA7-EAF3BA8888BA@iii.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated -gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 19:13:01 -0000 In general, 3GPP can quite happily normatively reference both informational= and standards track documents. The key is of course that the referenced ma= terial is suitable, i.e. that normatively referenced material is specified = in a suitable fashion to be a normative requirements. In previous mails I h= ave given at least one example of such requirements. However Albrecht does introduce a different complication. 3GPP does also normatively reference ITU-T documents for the H.248 function= ality, and if the ITU-T documents need then to normatively reference the IE= TF document to support that, then if I recall correctly, ITU-T does require= that to be a standards track document. What is clear is that we will have a mixture of normative material and info= rmational material. It is important that that distinction is clear. If that= is so, what is the issue with having a standards track document? Keith=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Cullen Jennings > Sent: 15 July 2015 16:43 > To: Schwarz, Albrecht (Albrecht) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Updated -gateways draft >=20 >=20 > > On Jul 15, 2015, at 2:02 AM, Schwarz, Albrecht (Albrecht)=20 > wrote: > >=20 > > Coming back to the original question: whether it should be=20 > Informational or Standards-track, - I don't know. But it is=20 > apparent that both, the 3GPP and ITU-T work on WebRTC=20 > gateways needs to be tightly coupled and linked to the IETF=20 > gateway draft in my opinion. >=20 > I'd be happy for Keith to correct me but my understanding is=20 > that 3GPP does not really differentiate much on the RFC track=20 > and can have normative references to informational RFC.=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Wed Jul 15 12:27:45 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FBF1ACE90 for ; Wed, 15 Jul 2015 12:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOJyfrcXD6IS for ; Wed, 15 Jul 2015 12:27:41 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7D21B2A09 for ; Wed, 15 Jul 2015 12:27:40 -0700 (PDT) Received: (qmail 80326 invoked from network); 15 Jul 2015 19:27:38 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 13048 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 15 Jul 2015 19:27:38 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id CD7C918A0620; Wed, 15 Jul 2015 20:27:34 +0100 (BST) Received: from [192.168.42.86] (unknown [85.255.233.156]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 0C5BA18A04A5; Wed, 15 Jul 2015 20:27:33 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C287A5FA-58DD-4346-8110-DCB60E98EAB0" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: tim panton In-Reply-To: <20150715164129.GA27105@lo.psyced.org> Date: Wed, 15 Jul 2015 20:27:31 +0100 Message-Id: References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> To: carlo von lynX X-Mailer: Apple Mail (2.2102) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 19:27:44 -0000 --Apple-Mail=_C287A5FA-58DD-4346-8110-DCB60E98EAB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Jul 2015, at 17:41, carlo von lynX = > = wrote: >=20 > Concerning the HT mail, of course they find a local IP of little > interest when you already p0wn the entire computer. >=20 > On Wed, Jul 15, 2015 at 02:48:52PM +0100, tim panton wrote: >> >=20 > You are welcome to rant AFTER you have done your homework. > Instead you postponed it by several weeks which made it worse. Um, if you check back in the archives, I brought this issue up earlier = this year. I think it is important. https://mailarchive.ietf.org/arch/msg/rtcweb/VnStGD7Emmvc1-QOPRtY2cFF79E = = >=20 >> There are 4 ip addresses involved here - >> Lets assume a user with a PC - wifi connected to an ADSL router and = using a VPN >>=20 >> 1) External VPN address : the IP address of the exit node from the = VPN - this is already known to everyone. >> 2) Internal VPN address : the IP address of the VPN interface on the = PC end of the VPN tunnel - not known - but not =E2=80=98secret' >> 3) ISP address : the address allocated by the ISP for the ADSL router = - this is the one that TOR and other VPNs mask >> 4) local IP address: the address returned by the router - typically = 192.168.0.2 or some such - this is not known=20 >>=20 >> With current VPN configs (and I assume TOR) webRTC reveals all of = these. >> The critical one is ISP address (correct me if I=E2=80=99m wrong) - = This can reveal location and identity via the ISP=E2=80=99s business = database. >=20 > Point one, all of this discussion and explanation belongs into > draft-ietf-rtcweb-security-arch. That is your homework for today. Thanks. >=20 >> A small change to the VPN configuration will hide the ISP address - = you just have to set the default route to 2) rather than 3) >> then the STUN queries will return the external VPN address - which is = what you revealed anyway by loading the page. >=20 > This does not sound like something your average Egyptian > dissident will be able and sufficiently early informed about > to go about. I have zero expectation that the Egyptian dissident should do this.=20 I do expect their software provider to keep up with developments. >=20 > I frequently see this pattern of saying privacy problem X > can be solved by manual intervention Y and it is not our > problem if the general public will be unable to do such a > manual intervention. >=20 > Yes it is your problem. That isn=E2=80=99t what I meant. I expect secure software providers to = keep their software abreast of new developments.=20 >=20 > It is not okay to dismiss problems this way. I=E2=80=99m really sorry you think I=E2=80=99m dismissing this problem, = I=E2=80=99m not. I happen to have the (no doubt under informed) opinion that this isn=E2=80=99t as simple as it has been made out to be. >=20 > Also the "solution" you suggest AFAIU does not work for people > who use Tor in a non-NATted environment, for example on a > fixed system in a university library with a static IP address. That is an interesting case. In that instance hiding the local IP would = be=20 valuable. I thought however those users would normally run a TOR os off=20= a usb stick in a VM. That would probably mask the local IP. > We know that browsers will allow fingerprinting even through > Tor but it is a different calibre of problem if a browser > actually allows the attacker to find out the REAL public IP > of a person. I totally agree. My solution is imho a better fix, since it also protects against many other apps that might get started from a browser page (email, dns, ipv6 tunnels, flash, mp3 players etc). >=20 >> 'Just ask the user to enable webRTC' is a sledgehammer to crack a = nut.=20 >=20 > No. It's like asking the user to click on the telephone icon > before making a phone call. It is normal. What is abnormal is > to have a web browser that is supposed to browse the web be > enabled to do crazy non-web things without asking anyone. No, really not. I want the VPN folks and the Tor folks to update their scripts after consultations about the best way forward. >=20 > You guys are completely losing the perspective of normal human beings. >=20 > And it's nothing new, you know these documents yourself: >=20 > https://www.torproject.org/projects/torbrowser/design/#proxy-obedience = >=20 > WebRTC not respecting SOCKS configuration is a huge no-go. I=E2=80=99m SOCKs ignorant. >=20 > = https://www.torproject.org/projects/torbrowser/design/#fingerprinting-link= ability = >=20 > And if local IP information is so super harmless, then why is it > an obvious reason for TBB devs to disable the entire thing? > I presume for the reasons I stated before. I have no idea, but I fear it is because no one has split these issues = out. >=20 > So when you do your homework please include all the points that > I am making. Add your solid arguments to counter them. >=20 >> You are forgoing the huge advantages (including privacy) of P2P = crypto in webRTC just because the existing VPN=20 >> suppliers can=E2=80=99t figure out a default route and update their = scripts. >=20 > I don't know about VPN suppliers, I never used any VPN really, > but it sounds like you have a moral obligation to venture out > and inform them about the security problem you are introducing > and to make sure they protect their users before anyone gets > harmed. Yep, I=E2=80=99ve been doing that, I clearly haven=E2=80=99t spoken to = enough people but there is only so much homework I can do. >=20 > Also don't tell me any fairy tales about P2P crypto in web > browsers. There is no architectural way you can provide E2E > crypto that isn't in one way or another MITM'able by the > involved servers. You are at *best* adding to the choice of > opportunistic cryptography. Don't be so excessively proud > of that considering that REAL P2P with REAL E2E authentication > is out there and would have deserved better attention. I think putting PFS strong crypto in the hands of 2bn people and=20 1m web developers is something to be slightly proud of. I=E2=80=99m of the view that there are _useful_ instances of P2P crypto in-browser - we will clearly have to disagree about that. >=20 >> The cynical part of me wonders if people with skin in the VPN game = don=E2=80=99t want an easy to use P2P crypto in the browser=E2=80=A6.. >=20 > No idea about that, but I am certain the number of people with skin > in the WebRTC game are in the majority on this mailing list - and > you wouldn't like to be ignored in any privacy debate a priori just > because you're in the WebRTC game, right? But if you go on this way, > that is likely to be the outcome. By the time you start thinking of > the consequences of your actions your credibility may already be > gone downhill. I=E2=80=99m not ignoring anyone or their views, just challenging the = conclusions they have drawn by providing a different viewpoint. T. --Apple-Mail=_C287A5FA-58DD-4346-8110-DCB60E98EAB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 15 Jul 2015, at 17:41, carlo von lynX = <lynX@i.know.you.are.psyced.org> wrote:

Concerning the HT = mail, of course they find a local IP of little
interest = when you already p0wn the entire computer.

On= Wed, Jul 15, 2015 at 02:48:52PM +0100, tim panton wrote:
<Rant>

You are welcome to rant AFTER you = have done your homework.
Instead you postponed it by = several weeks which made it worse.

Um, if you check back in = the archives, I brought this issue up earlier this year.
I think it is important.

https://mailarchive.ietf.org/arch/msg/rtcweb/VnStGD7Emmvc1-QOPR= tY2cFF79E


There are 4 ip addresses involved here -
Lets assume a user with a PC - wifi connected to an ADSL = router and using a VPN

1) External VPN = address : the IP address of the exit node from the VPN - this is already = known to everyone.
2) Internal VPN address : the IP = address of the VPN interface on the PC end of the VPN tunnel - not known = - but not =E2=80=98secret'
3) ISP address : the address = allocated by the ISP for the ADSL router - this is the one that TOR and = other VPNs mask
4) local IP address: the address returned = by the router - typically 192.168.0.2 or some such - this is not known =

With current VPN configs (and I assume = TOR) webRTC reveals all of these.
The critical one is =  ISP address (correct me if I=E2=80=99m wrong) - This can reveal = location and identity via the ISP=E2=80=99s business database.

Point one, all of this discussion = and explanation belongs into
draft-ietf-rtcweb-security-arch. That is your homework for = today.

Thanks.


A small change to the VPN configuration will = hide the ISP address - you just have to set the default route to 2) = rather than 3)
then the STUN queries will return the = external VPN address - which is what you revealed anyway by loading the = page.

This does not sound like = something your average Egyptian
dissident will be able and = sufficiently early informed about
to go about.

I have zero expectation that the Egyptian dissident should do = this. 
I do expect their software provider to = keep up with developments.


I frequently see this pattern = of saying privacy problem X
can be solved by manual = intervention Y and it is not our
problem if the general = public will be unable to do such a
manual intervention.

Yes it is your problem.

That isn=E2=80=99t what I meant. I expect secure software = providers to keep their
software abreast of new = developments. 


It is not okay to dismiss = problems this way.

I=E2=80=99m really sorry you think I=E2=80=99m = dismissing this problem, I=E2=80=99m not.
I happen = to have the (no doubt under informed) opinion that
this isn=E2=80=99t as simple as it has been made out to = be.


Also the "solution" you = suggest AFAIU does not work for people
who use Tor in a = non-NATted environment, for example on a
fixed system in a = university library with a static IP address.

That is an interesting case. In that instance hiding the = local IP would be 
valuable. I thought however = those users would normally run a TOR os off 
a = usb stick in a VM. That would probably mask the local IP.


We know that browsers will allow = fingerprinting even through
Tor but it is a different = calibre of problem if a browser
actually allows the = attacker to find out the REAL public IP
of a person.

I totally agree. My solution is imho a better fix, since = it
also protects against many other apps that might = get started from
a browser page (email, dns, ipv6 = tunnels, flash, mp3 players etc).



'Just ask = the user to enable webRTC' is a sledgehammer to crack a nut.

No. It's like asking the user to = click on the telephone icon
before making a phone call. It = is normal. What is abnormal is
to have a web browser that = is supposed to browse the web be
enabled to do crazy = non-web things without asking anyone.

No, really not. I want the VPN folks and the Tor folks to = update their
scripts after consultations about the = best way forward.


You guys are completely losing = the perspective of normal human beings.

And it's nothing = new, you know these documents yourself:

https://www.torproject.org/projects/torbrowser/design/#proxy-ob= edience

WebRTC not respecting SOCKS = configuration is a huge no-go.

I=E2=80=99m SOCKs = ignorant.


https://www.torproject.org/projects/torbrowser/design/#fingerpr= inting-linkability

And if local IP = information is so super harmless, then why is it
an = obvious reason for TBB devs to disable the entire thing?
I = presume for the reasons I stated before.

I have no idea, but I fear it is because no one has split = these issues out.


So when you do your homework = please include all the points that
I am making. Add your = solid arguments to counter them.

You are forgoing the huge advantages (including = privacy) of P2P crypto in webRTC just because the existing VPN
suppliers can=E2=80=99t figure out a default route and update = their scripts.

I don't know = about VPN suppliers, I never used any VPN really,
but it = sounds like you have a moral obligation to venture out
and = inform them about the security problem you are introducing
and to make sure they protect their users before anyone = gets
harmed.

Yep, I=E2=80=99ve been = doing that, I clearly haven=E2=80=99t spoken to enough people
but there is only so much homework I can do.


Also don't tell me any fairy tales about P2P crypto in web
browsers. There is no architectural way you can provide = E2E
crypto that isn't in one way or another MITM'able by = the
involved servers. You are at *best* adding to the = choice of
opportunistic cryptography. Don't be so = excessively proud
of that considering that REAL P2P with = REAL E2E authentication
is out there and would have = deserved better attention.

I think putting PFS = strong crypto in the hands of 2bn people and 
1m= web developers is something to be slightly proud of.

I=E2=80=99m of the view = that there are _useful_ instances of P2P crypto
in-browser - we will clearly have to disagree about = that.



The cynical part of me wonders if people with = skin in the VPN game don=E2=80=99t want an easy to use P2P crypto in the = browser=E2=80=A6..

No idea = about that, but I am certain the number of people with skin
in the WebRTC game are in the majority on this mailing list - = and
you wouldn't like to be ignored in any privacy debate = a priori just
because you're in the WebRTC game, right? = But if you go on this way,
that is likely to be the = outcome. By the time you start thinking of
the = consequences of your actions your credibility may already be
gone downhill.

I=E2=80=99m not ignoring = anyone or their views, just challenging the conclusions they
have drawn by providing a different viewpoint.

T.


= --Apple-Mail=_C287A5FA-58DD-4346-8110-DCB60E98EAB0-- From nobody Wed Jul 15 13:47:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0029D1B2B83 for ; Wed, 15 Jul 2015 13:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJrytY5a6eGC for ; Wed, 15 Jul 2015 13:47:23 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id C7E3E1B2B82 for ; Wed, 15 Jul 2015 13:47:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 70F3D7C3AB4 for ; Wed, 15 Jul 2015 22:47:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptdxeV1XZXVB for ; Wed, 15 Jul 2015 22:47:20 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:b8d1:439b:37a2:6769] (unknown [IPv6:2001:470:de0a:27:b8d1:439b:37a2:6769]) by mork.alvestrand.no (Postfix) with ESMTPSA id 514357C3AB0 for ; Wed, 15 Jul 2015 22:47:20 +0200 (CEST) Message-ID: <55A6C6D7.2040300@alvestrand.no> Date: Wed, 15 Jul 2015 22:47:19 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> In-Reply-To: <20150715164129.GA27105@lo.psyced.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 20:47:25 -0000 On 07/15/2015 06:41 PM, carlo von lynX wrote: > I don't know about VPN suppliers, I never used any VPN really, > but it sounds like you have a moral obligation to venture out > and inform them about the security problem you are introducing > and to make sure they protect their users before anyone gets > harmed. Sorry, I lost it. You're lecturing us (many of whom have used VPNs regularly for the last 20 years, some of whom have implemented them) about what we should tell VPN suppliers, and you haven't even *used* a VPN? May I suggest that the strong opinions being delivered here might be better served with slightly more respect for the fact that some of us actually have some experience worth considering? Just *explaining* this problem is complicated. And most of the "headline" statements made about this problem are either completely wrong or very incomplete. Being clear about what needs protection, and from what threat, is just the first step on the way to finding a consensus solution. And I don't think we're even there yet. (I recently learned of a couple of reasons why people think the local IP address (the 192.168 ones) are valuable to learn for some services - in that particular case, many would consider that particular purpose to have value to society. But it shows that once we reveal information, that information can be used in many different ways - some less obvious than others.) Harald --=20 Surveillance is pervasive. Go Dark. From nobody Wed Jul 15 23:50:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41881B3670 for ; Wed, 15 Jul 2015 23:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXylxpgFleH3 for ; Wed, 15 Jul 2015 23:50:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6DA1B366F for ; Wed, 15 Jul 2015 23:50:30 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 79A1F91CAA78; Thu, 16 Jul 2015 06:50:26 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6G6oHhS004714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Jul 2015 08:50:27 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 16 Jul 2015 08:50:20 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "DRAGE, Keith (Keith)" , Cullen Jennings Thread-Topic: [rtcweb] Updated -gateways draft Thread-Index: AQHQuDnN3/JBjH3ISECTCktkw1ryoJ3O5hsAgAtPjwCAADOdAIAByPMAgABlhQCAADrJAIAA41Hw Date: Thu, 16 Jul 2015 06:50:19 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC7ADA980A@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <559AFEDB.4070205@alvestrand.no> <55A4AAEE.6090007@alvestrand.no> <786615F3A85DF44AA2A76164A71FE1AC7ADA8882@FR711WXCHMBA03.zeu.alcatel-lucent.com> <4F5BED26-28A6-4634-9AA7-EAF3BA8888BA@iii.ca> <949EF20990823C4C85C18D59AA11AD8B69742078@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69742078@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated -gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 06:50:32 -0000 I could clarify the situation for Draft ITU-T H.248.94 (ex H.248.WebRTC): =3D> the reference to draft-rtcweb-gateways is INFORMATIVE only, and there = isn't any real need for a normative reference because the scope of this ITU= -T Recommendation is on "H.248 profile GUIDELINES" ("That's the reason why draft-rtcweb-gateways is listed in the Bibliography= section.") -Albrecht -----Original Message----- From: DRAGE, Keith (Keith)=20 Sent: Mittwoch, 15. Juli 2015 21:13 To: Cullen Jennings; Schwarz, Albrecht (Albrecht) Cc: rtcweb@ietf.org Subject: RE: [rtcweb] Updated -gateways draft In general, 3GPP can quite happily normatively reference both informational= and standards track documents. The key is of course that the referenced ma= terial is suitable, i.e. that normatively referenced material is specified = in a suitable fashion to be a normative requirements. In previous mails I h= ave given at least one example of such requirements. However Albrecht does introduce a different complication. 3GPP does also normatively reference ITU-T documents for the H.248 function= ality, and if the ITU-T documents need then to normatively reference the IE= TF document to support that, then if I recall correctly, ITU-T does require= that to be a standards track document. What is clear is that we will have a mixture of normative material and info= rmational material. It is important that that distinction is clear. If that= is so, what is the issue with having a standards track document? Keith=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen=20 > Jennings > Sent: 15 July 2015 16:43 > To: Schwarz, Albrecht (Albrecht) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Updated -gateways draft >=20 >=20 > > On Jul 15, 2015, at 2:02 AM, Schwarz, Albrecht (Albrecht) > wrote: > >=20 > > Coming back to the original question: whether it should be > Informational or Standards-track, - I don't know. But it is apparent=20 > that both, the 3GPP and ITU-T work on WebRTC gateways needs to be=20 > tightly coupled and linked to the IETF gateway draft in my opinion. >=20 > I'd be happy for Keith to correct me but my understanding is that 3GPP=20 > does not really differentiate much on the RFC track and can have=20 > normative references to informational RFC. >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Thu Jul 16 01:42:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA2A1B3797 for ; Thu, 16 Jul 2015 01:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhy38i5pdF4p for ; Thu, 16 Jul 2015 01:42:24 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA9C1B3795 for ; Thu, 16 Jul 2015 01:42:23 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t6G8gPVS011574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Jul 2015 10:42:25 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t6G8gPMe011573 for rtcweb@ietf.org; Thu, 16 Jul 2015 10:42:25 +0200 Date: Thu, 16 Jul 2015 10:42:25 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150716084225.GA29652@lo.psyced.org> References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 08:42:26 -0000 Harald, sorry if after getting ignored once and getting a rant on my second inquiry I start getting grumpy.. still let's stay on topic and figure this issue out.. I still hope I and everyone in blogland is wrong on this and exposing local IP is actually not problematic.. but the webrtc documentations should elaborate on this scenario and evaluate carefully in-depth on anything that could possibly go wrong, if they intend to recover credibility on this terrain rather than strengthening the general feeling that browser vendors are bulldozering over humans and citizen anytime the business model suggests so. On Wed, Jul 15, 2015 at 08:27:31PM +0100, tim panton wrote: > Um, if you check back in the archives, I brought this issue up earlier this year. > I think it is important. > > https://mailarchive.ietf.org/arch/msg/rtcweb/VnStGD7Emmvc1-QOPRtY2cFF79E Thank you. I see you brought up the same issues. Would have appreciated receiving such a pointer back in April when I first asked. Unfortunately I cannot read the follow-up discussion as somebody at IETF had the great idea of making the archives depend on Javascript execution. I don't grant execution of foreign code on my machines to any unencrypted or untrustworthy sources. Is there any reply I should read? What's its hash code? > >> A small change to the VPN configuration will hide the ISP address - you just have to set the default route to 2) rather than 3) > >> then the STUN queries will return the external VPN address - which is what you revealed anyway by loading the page. > > > > This does not sound like something your average Egyptian > > dissident will be able and sufficiently early informed about > > to go about. > > I have zero expectation that the Egyptian dissident should do this. > I do expect their software provider to keep up with developments. Yes, I dare to speak out of my 25 years of experience on the Internet even if I didn't have to use much VPN ever. I can imagine plenty of constellations where the VPN is NOT supposed to take over all communications on the system but rather offer a side route into a company's servers or suchlike. Therefore I worry if the software provider can always come up with a configuration that still does what the customers expect and at the same time deals with the new backdoor introduced by WebRTC. Of course anyone with better understanding can help clear up these worries. > That isn’t what I meant. I expect secure software providers to keep their > software abreast of new developments. Uh, not sure if that is an established pattern in the industry. Usually somebody does whatever fits into their business model best, then there is a public outcry and possibly some bloodspill, then all the players look at how they can make a good impression by reducing the collateral damages.. but if that doesn't work out cheap and easy.. tant pis. Let's continue with business. > I happen to have the (no doubt under informed) opinion that > this isn’t as simple as it has been made out to be. Well, in case of doubt it is important to pick the conservative option until the issue is properly analyzed rather than hoping for the general public to forget about the problem. > > Also the "solution" you suggest AFAIU does not work for people > > who use Tor in a non-NATted environment, for example on a > > fixed system in a university library with a static IP address. > > That is an interesting case. In that instance hiding the local IP would be > valuable. I thought however those users would normally run a TOR os off > a usb stick in a VM. That would probably mask the local IP. Now that this is more clear, have another look at my original mail that describes how such a dissident would use any Windows OS system standing around. I doubt anything advanced like TAILS sticks are out there as merely possessing one could be life-threatening. We are talking about people that act out of a need to act with very little understanding of technology. They would likely only start wondering if what they did was safe after they got caught. By introducing new vulnerabilities we may be tipping some very shaky balances to the wrong side. It is quite likely that a whole lot of people unconsciously rely on the principle that a web browser configured to use a proxy will actually do so. > > We know that browsers will allow fingerprinting even through > > Tor but it is a different calibre of problem if a browser > > actually allows the attacker to find out the REAL public IP > > of a person. > > I totally agree. My solution is imho a better fix, since it > also protects against many other apps that might get started from > a browser page (email, dns, ipv6 tunnels, flash, mp3 players etc). If you can convince Microsoft to update all the OS's in such countries in a way that VPN can no longer be configured to function in parallel to direct Internet access, that could be a viable solution to this problem. Introduces a new problem of not being backward compatible to other use cases of VPNs, correct? Again, expecting the dissidents to be magically internetworked and inform each other quickly enough on safer practices that only a few like us know about and may actually not be safer since they imply singling people out of the masses of Windows users... acting differently than the rest of the population can be a death sentence.. well then your proposed solution to the problem may not work out for real humans with real problems. > >> 'Just ask the user to enable webRTC' is a sledgehammer to crack a nut. > > > > No. It's like asking the user to click on the telephone icon > > before making a phone call. It is normal. What is abnormal is > > to have a web browser that is supposed to browse the web be > > enabled to do crazy non-web things without asking anyone. > > No, really not. I want the VPN folks and the Tor folks to update their > scripts after consultations about the best way forward. Breaking the proxy principle is neither a Tor nor a VPN problem. It's just browser vendors breaking a promise given to users that configured proxies would be respected. > I’m SOCKs ignorant. So we all have our knowledge deficiencies... good to be honest about them. > > And if local IP information is so super harmless, then why is it > > an obvious reason for TBB devs to disable the entire thing? > > I presume for the reasons I stated before. > > I have no idea, but I fear it is because no one has split these issues out. So let's dissect some more until we know what we are doing. > > I don't know about VPN suppliers, I never used any VPN really, > > but it sounds like you have a moral obligation to venture out > > and inform them about the security problem you are introducing > > and to make sure they protect their users before anyone gets > > harmed. > > Yep, I’ve been doing that, I clearly haven’t spoken to enough people > but there is only so much homework I can do. True. > > Also don't tell me any fairy tales about P2P crypto in web > > browsers. There is no architectural way you can provide E2E > > crypto that isn't in one way or another MITM'able by the > > involved servers. You are at *best* adding to the choice of > > opportunistic cryptography. Don't be so excessively proud > > of that considering that REAL P2P with REAL E2E authentication > > is out there and would have deserved better attention. > > I think putting PFS strong crypto in the hands of 2bn people and > 1m web developers is something to be slightly proud of. Perspective accepted. > I’m of the view that there are _useful_ instances of P2P crypto > in-browser - we will clearly have to disagree about that. I think we could improve the user's ability to ensure end-to-end authentication beyond server-based negotiation. Something like rendering persistent public keys into QR codes and having people exchange those QR codes at cocktail parties and hackathons. Servers would still be able to provide the signaling code, but users would be granted a guarantee that the E2E connection is authentic. > I’m not ignoring anyone or their views, just challenging the conclusions they > have drawn by providing a different viewpoint. Moi aussi. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Thu Jul 16 06:43:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF441B3B99 for ; Thu, 16 Jul 2015 06:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfR2J74Hf9tM for ; Thu, 16 Jul 2015 06:43:09 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0875E1B3B2F for ; Thu, 16 Jul 2015 06:43:08 -0700 (PDT) Received: by wgxm20 with SMTP id m20so58860435wgx.3 for ; Thu, 16 Jul 2015 06:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d7sfMkmy5HIT4q1jhsGFhAve9YEVI9XtZsxaN7yw1oQ=; b=FyNfVJV+v/5gncEzY4WA+whTRcfkwctuUm76fcQGptAJFAXCObYLl6BAQknzgU7zMW GDQvad8QxZwTEtM001CpXGyXxk5EG45hJVEXev4IzXy4vt6nABWf0CI26VCTRnVJ8+pC cU9GkfkRqJMHCQaZVtsCBSO/r68bXhJD4lUM++b4adcLS+Nun94nbI4bkKAwkzHtiAaI tbMi1UVnNFjaZOa0SKpc2ztpPtndCrX5GgG8sx5ravFkpPtFTmQhro4VUDd4AIikTxbf LhprMUT5wV4WQMwTmMlziUJ8r94xmCWGnSUcvA9FF1O3HuUmzrRNXjJc30dqqpaS6bHJ alHA== MIME-Version: 1.0 X-Received: by 10.181.25.234 with SMTP id it10mr7177170wid.0.1437054187528; Thu, 16 Jul 2015 06:43:07 -0700 (PDT) Received: by 10.28.16.14 with HTTP; Thu, 16 Jul 2015 06:43:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Jul 2015 15:43:07 +0200 Message-ID: From: Victor Pascual Avila To: Daniel Roesler Content-Type: multipart/alternative; boundary=001a1136cbd85ee8cf051afe40a1 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 13:43:10 -0000 --001a1136cbd85ee8cf051afe40a1 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 11, 2015 at 6:42 PM, Daniel Roesler wrote: > There is now a documented case where a third party on nytimes.com > is using a fake webRTC datachannel to silently gather user local (and > potentially "real" ISP) IP addresses. > > https://twitter.com/incloud/status/619624021123010560 > FYI - The company behind the NY Times IP tracking code turned it off. See our blog: https://webrtchacks.com/dear-ny-times/#comment-17504 Cheers, -Victor --001a1136cbd85ee8cf051afe40a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jul 11, 2015 at 6:42 PM, Daniel Roesler <diafygi@gmail.com> wrote:
There is now a documented case where a third party on nytimes.com
is using a fake webRTC datachannel to silently gath= er user local (and
potentially "real" ISP) IP addresses.

https://twitter.com/incloud/status/619624021123= 010560

FYI - The company behind the NY= Times IP tracking code turned it off. See our blog:=C2=A0https://webrtchacks.com/dear-ny-times/#comment= -17504

Cheers,
-Victor
--001a1136cbd85ee8cf051afe40a1-- From nobody Thu Jul 16 12:51:41 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCD01A6ED9 for ; Thu, 16 Jul 2015 12:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEYhm3RTC50T for ; Thu, 16 Jul 2015 12:51:38 -0700 (PDT) Received: from smtp97.ord1c.emailsrvr.com (smtp97.ord1c.emailsrvr.com [108.166.43.97]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7091A21C2 for ; Thu, 16 Jul 2015 12:51:38 -0700 (PDT) Received: from smtp21.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp21.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id BAA2838019C; Thu, 16 Jul 2015 15:51:37 -0400 (EDT) Received: by smtp21.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 4C22C38034A; Thu, 16 Jul 2015 15:51:37 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.255.247.206] (s75-152-227-63.ab.hsia.telus.net [75.152.227.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 16 Jul 2015 19:51:37 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Cullen Jennings In-Reply-To: Date: Thu, 16 Jul 2015 13:51:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <182AFB04-5F8E-4C93-A41C-6EFE9ECF04B3@iii.ca> References: To: Eric Rescorla , "rtcweb@ietf.org" X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [rtcweb] draft-jennings-behave-rtcweb-firewall-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 19:51:40 -0000 Good points.I will update the draft but in the meantime there is a copy = at=20 http://fluffy.github.io/iceTrav/ The summary of the algorithm is roughly: =E2=80=A2The firewall looks for any outgoing STUN requests to STUN port = (3478). When it finds one, it stores the 3 tuple of the source address = port and protocol=3DUDP and for the next 30 seconds checks any packets = from this 3 tuple to see if they are ICE connectivity checks.=20 =E2=80=A2When firewall sees an ICE connectivity check from the inside = host (which is a STUN Binding Request containing the ice username), it = stores that ice username value, and forwards the packet. Thereafter, = STUN Binding Requests and Binding Responses with matching 4-tuple = (inside IP address, protocol=3DUDP, inside port, and matching ice = username) are allowed in any direction (inside->outside and = outside->inside). For each 5-tuple, if a STUN Binding Request has a = Success STUN Binding Response (with same transaction ID), in either = direction, that 5-tuple is promoted to allow non-STUN traffic (DTLS, = SRTP, and anything else). =20 =E2=80=A2Both promoted and non-promoted pinholes are closed after 30 = seconds of not seeing a STUN Binding Request and Response transaction, = in either direction. =E2=80=A2(Note to match the ice username external requests will need the = halves on either side of =E2=80=9C:=E2=80=9D swapped) (and thanks to Dan Wing who came up with much of the above proposal )=20= more inline=20 > On Jul 8, 2015, at 8:39 AM, Eric Rescorla wrote: >=20 > I have taken a brief look at this draft and I don't believe that the = proposed pinhole/inspection > algorithm provides the desired assurances of verifying consent: >=20 > 1. If you open up an incoming/outgoing pinhole on outgoing packet, = prior to > receiving an incoming STUN packet, then if the internal implementation > simply sends a new outgoing STUN packet every 5 seconds, then they > never need to rely on external consent. >=20 > 2. If you just require *a* incoming STUN packet to be received in = order to > extend the lifetime to 30 seconds, then an off-path attacker can forge > a STUN response that will cause the pinhole to be open for 30 seconds. > (Hence the need for the STUN transaction ID). Yah, don't want outside stuff to extended it. Intent was only inside = stuff should extend.=20 >=20 > It seems to me that you should be instead requiring a complete STUN > transaction before allowing any non-STUN outgoing traffic. It would = probably > be safe-ish to require it before allowing any incoming traffic as = well, though > that leaves the chance that you get a small amount of clipping with = packet > drops or reordering. Agree - have changed to that.=20 >=20 >=20 > WRT to the origin attribute, I have mixed feelings. I agree that your = SNI argument > is strong, but there is also a move to figure out how to encrypt SNI, = so every time > we extend that argument it makes that harder. OTOH, STUN origin will = be > sent a lot less often than SNI, I imagine. Sounds like this is going to get discussed in Tram. Unfortunately I = think we have to choose between least evil on this topic.=20 >=20 >=20 > I don't understand Section 6. Is this guidance to firewall vendors or = to browser > implementors. If the former, the firewall has no way of knowing what = "requests" > are if the connection use HTTPS (and if is uses HTTP, you have = DPI-type methods for > determining whether something is voice or video. If this is guidance = to browser > vendors, I consider it extremely unlikely that we would implement it. advice for firewall vendors for more or less all TLS connections that = might be web traffic. It's horrific of course but since they are = implementing things along these lines we might as well be specific on = the algorithm so we understand the breakage. Or go deal with the root = causes that theses sort of things (basically trying to hide WebRTC = traffic inside HTTP) . I imagine this algorithm is not the best, it was = just a rough place holder. Its needs a bit of tuning to interact with = dash in a reasonable way.=20 >=20 >=20 > Point #4 in your security considerations section seems like an = entirely lost > cause, unless you assume that attackers are not really trying. >=20 > -Ekr >=20 >=20 >=20 From nobody Thu Jul 16 14:13:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D97C1A9040 for ; Thu, 16 Jul 2015 14:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX0csAj_U1dj for ; Thu, 16 Jul 2015 14:13:55 -0700 (PDT) Received: from mail.eeph.com (mail.eeph.com [IPv6:2001:470:826a:d2::3]) by ietfa.amsl.com (Postfix) with ESMTP id C5FC51A9035 for ; Thu, 16 Jul 2015 14:13:55 -0700 (PDT) Received: from Matthew-Kaufmans-MacBook-Air.local (unknown [167.220.23.18]) (Authenticated sender: matthew@matthew.at) by mail.eeph.com (Postfix) with ESMTPSA id 48C864E2DC1 for ; Thu, 16 Jul 2015 14:13:55 -0700 (PDT) Message-ID: <55A81E92.7060307@matthew.at> Date: Thu, 16 Jul 2015 14:13:54 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> In-Reply-To: <20150716084225.GA29652@lo.psyced.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 21:13:58 -0000 On 7/16/15 1:42 AM, carlo von lynX wrote: > I don't grant execution of foreign code on my machines to any > unencrypted or untrustworthy sources. If you can get everyone to do that, we won't even need RTCWEB Matthew Kaufman From nobody Thu Jul 16 17:43:54 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABCC1B2C30 for ; Thu, 16 Jul 2015 17:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxsLDxsBIRNi for ; Thu, 16 Jul 2015 17:43:52 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id 184321B2C40 for ; Thu, 16 Jul 2015 17:43:51 -0700 (PDT) Received: from userPC (unknown [122.172.200.169]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id DB76D1A2915; Fri, 17 Jul 2015 00:43:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1437093830; bh=Iys5ZNgPpJ8adZesLUfyFKoJBT44yqmTe0QLP2yTOZc=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=F5MD3QuAOs6f5z/SX5O4oaIPeHJ+1ftkuEHCeLmvp7jHSoWx+rJMKce5T3ddwbx1F 8/MUQeBEWxH6jBnUaUUYIZNt6GQZ+q+hKWIxBOe/ujqmP2tpvNhWWePI3CUD26bIJJ SbGp4Xv0zfzKOlxNPIINw5bO7M0+kAKuPLueYf6w= From: "Parthasarathi R" To: "'Schwarz, Albrecht \(Albrecht\)'" , "'DRAGE, Keith \(Keith\)'" , "'Cullen Jennings'" References: <559AFEDB.4070205@alvestrand.no> <55A4AAEE.6090007@alvestrand.no> <786615F3A85DF44AA2A76164A71FE1AC7ADA8882@FR711WXCHMBA03.zeu.alcatel-lucent.com> <4F5BED26-28A6-4634-9AA7-EAF3BA8888BA@iii.ca> <949EF20990823C4C85C18D59AA11AD8B69742078@FR712WXCHMBA11.zeu.alcatel-lucent.com> <786615F3A85DF44AA2A76164A71FE1AC7ADA980A@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC7ADA980A@FR711WXCHMBA03.zeu.alcatel-lucent.com> Date: Fri, 17 Jul 2015 06:13:40 +0530 Message-ID: <006301d0c029$a263dc70$e72b9550$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQuDnN3/JBjH3ISECTCktkw1ryoJ3O5hsAgAtPjwCAADOdAIAByPMAgABlhQCAADrJAIAA41HwgAEplnA= Content-Language: en-us X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=cdov1S3M c=1 sm=1 tr=0 a=Sq3+HGaW3WwrNcrrdvEeFg==:117 a=Sq3+HGaW3WwrNcrrdvEeFg==:17 a=-NIMs_s3AAAA:8 a=VQADlPdMAAAA:8 a=kj9zAlcOel0A:10 a=MKtGQD3n3ToA:10 a=ZZnuYtJkoWoA:10 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=-cRUznHHXZzduQ9SyWYA:9 a=aStlRR5a4WnnkotA:21 a=ShZZmNnN_gkkInK-:21 a=CjuIK1q_8ugA:10 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Updated -gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 00:43:54 -0000 Hi all, The main intent of this draft is to define WebRTC gateway entity in IETF itself as there are lot of discussions wherein it is not clear which WebRTC entity under discussion. This draft has to be in standards track as the draft relax some of the normative statements of WebRTC endpoint namely 1) ICE-lite 2) Non-bundle SDP support only 3) No need of TURN support 4) No need to support data channel. These information are clarified in Sec 2 of the -gateways draft. Of course, these relaxation has some impact in other WebRTC endpoints as well. The example is to support non-bundle SDP in the incoming offer to the WebRTC endpoint. Of course, we may see more in the relaxation list as the other RTCWeb drafts are yet to be matured as RFC. As Keith mentioned, some of the normative text is required in this draft. IMO, the standards track looks more appropriate for this draft. Thanks Partha > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Schwarz, > Albrecht (Albrecht) > Sent: Thursday, July 16, 2015 12:20 PM > To: DRAGE, Keith (Keith); Cullen Jennings > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Updated -gateways draft > > I could clarify the situation for Draft ITU-T H.248.94 (ex > H.248.WebRTC): > > => the reference to draft-rtcweb-gateways is INFORMATIVE only, and > there isn't any real need for a normative reference because the scope > of this ITU-T Recommendation is on "H.248 profile GUIDELINES" > > ("That's the reason why draft-rtcweb-gateways is listed in the > Bibliography section.") > > -Albrecht > > > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: Mittwoch, 15. Juli 2015 21:13 > To: Cullen Jennings; Schwarz, Albrecht (Albrecht) > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] Updated -gateways draft > > In general, 3GPP can quite happily normatively reference both > informational and standards track documents. The key is of course that > the referenced material is suitable, i.e. that normatively referenced > material is specified in a suitable fashion to be a normative > requirements. In previous mails I have given at least one example of > such requirements. > > However Albrecht does introduce a different complication. > > 3GPP does also normatively reference ITU-T documents for the H.248 > functionality, and if the ITU-T documents need then to normatively > reference the IETF document to support that, then if I recall > correctly, ITU-T does require that to be a standards track document. > > What is clear is that we will have a mixture of normative material and > informational material. It is important that that distinction is clear. > If that is so, what is the issue with having a standards track > document? > > Keith > > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen > > Jennings > > Sent: 15 July 2015 16:43 > > To: Schwarz, Albrecht (Albrecht) > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Updated -gateways draft > > > > > > > On Jul 15, 2015, at 2:02 AM, Schwarz, Albrecht (Albrecht) > > wrote: > > > > > > Coming back to the original question: whether it should be > > Informational or Standards-track, - I don't know. But it is apparent > > that both, the 3GPP and ITU-T work on WebRTC gateways needs to be > > tightly coupled and linked to the IETF gateway draft in my opinion. > > > > I'd be happy for Keith to correct me but my understanding is that > 3GPP > > does not really differentiate much on the RFC track and can have > > normative references to informational RFC. > > > > > > _______________________________________________ > > 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 From nobody Thu Jul 16 21:06:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222A71B29E0 for ; Thu, 16 Jul 2015 21:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t9EReRK2lLb for ; Thu, 16 Jul 2015 21:06:46 -0700 (PDT) Received: from ftx-008-i775.relay.mailchannels.net (ftx-008-i775.relay.mailchannels.net [50.61.143.75]) by ietfa.amsl.com (Postfix) with ESMTP id BB9341AD49F for ; Thu, 16 Jul 2015 21:06:45 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id 0080FA02B7 for ; Fri, 17 Jul 2015 04:06:42 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.244.170.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Fri, 17 Jul 2015 04:06:43 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1437106003168:3273903827 X-MC-Ingress-Time: 1437106003167 Received: from pool-108-36-235-74.phlapa.fios.verizon.net ([108.36.235.74]:61804 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZFwv3-000EHF-NE for rtcweb@ietf.org; Thu, 16 Jul 2015 23:06:41 -0500 Message-ID: <55A87F37.9040208@jesup.org> Date: Fri, 17 Jul 2015 00:06:15 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> In-Reply-To: <20150716084225.GA29652@lo.psyced.org> Content-Type: text/plain; charset=utf-8; format=flowed X-AuthUser: randell@jesup.org Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 04:06:48 -0000 On 7/16/2015 4:42 AM, carlo von lynX wrote: > >> I=E2=80=99m of the view that there are _useful_ instances of P2P crypt= o >> in-browser - we will clearly have to disagree about that. > I think we could improve the user's ability to ensure end-to-end > authentication beyond server-based negotiation. Something like > rendering persistent public keys into QR codes and having people > exchange those QR codes at cocktail parties and hackathons. > > Servers would still be able to provide the signaling code, but users > would be granted a guarantee that the E2E connection is authentic. Have you read the 'identity' support in the webrtc/rtcweb specs? Or=20 played with early implementations at=20 https://mozilla.github.io/webrtc-landing/pc_test.html? This is something we've cared about, since the beginning of this work. =20 We're also working out speccing calls where the JS application can't get=20 access to the datastreams (via WebAudio/canvas/etc). There's a lot of=20 work to do to spec this all out, and more to be done to implement it -=20 but these things are part of the goals of WebRTC. Witness also that we=20 decided to not only not require SDES (which puts keys directly in the=20 hands of the servers), but to actively require not supporting SDES. =20 We've also moved to requires PFS encryption=20 (https://hacks.mozilla.org/2015/02/webrtc-requires-perfect-forward-secrec= y-pfs-starting-in-firefox-38/) I'll also note that WebRTC+DataChannels can be used to build=20 non-centralized encrypted communication services using (for example)=20 distributed-hash addressing and a web of datachannel connections, such=20 that there's no single easily-blocked locus for communications (like=20 blocking twitter.com). There's a *bunch* of work to build a good,=20 secure service around this - but now it's feasible to do with just some=20 JS shared on a thumb drive (or any number of ways online - done right,=20 perhaps even in high-density QR-ish codes with compressed code to=20 bootstrap into the network. The webtorrent clients are the first step=20 towards this. --=20 Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much sp= am From nobody Fri Jul 17 01:29:45 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7E01B3181 for ; Fri, 17 Jul 2015 01:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXhH2160ljcX for ; Fri, 17 Jul 2015 01:29:42 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CB91B3163 for ; Fri, 17 Jul 2015 01:29:41 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t6H8Th34003565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Jul 2015 10:29:43 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t6H8Tgiw003564 for rtcweb@ietf.org; Fri, 17 Jul 2015 10:29:42 +0200 Date: Fri, 17 Jul 2015 10:29:42 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150717082942.GA1590@lo.psyced.org> References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <55A87F37.9040208@jesup.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A87F37.9040208@jesup.org> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: [rtcweb] Dreaming of serverless P2P over the web X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 08:29:44 -0000 Sorry for summoning up a change of topic. The main thread on the safety of browser users affected by the webrtc apis against their will is still open and unresolved. Here we just talk about the young dreams of a Javascript generation: On Fri, Jul 17, 2015 at 12:06:15AM -0400, Randell Jesup wrote: > Have you read the 'identity' support in the webrtc/rtcweb specs? Or > played with early implementations at > https://mozilla.github.io/webrtc-landing/pc_test.html? I know that the JS community is very adamant exploring fertile new grounds doing crazy things... I was to "data terra nemo" just recently.. I understand there is plenty of good intentions. I presume you have heard of where they likely lead to. > I'll also note that WebRTC+DataChannels can be used to build > non-centralized encrypted communication services using (for example) > distributed-hash addressing and a web of datachannel connections, Yes, these kind of good intentions.. the juvenile enthusiasm that thinks something as complicated as DHTs can be quickly thrown into a browser with "some JS on a thumb drive." My knowledge indicates the security issues with cheap off-the-mill DHT tech are impressive. It took gnunet a dozen of years to develop a sybil-attack resistant DHT routing system. Go ahead and show me how you will ship THAT in a bunch of .js files. Or do you think the world will be done any good if you throw even more insecure web apps at it? >From my understanding of technology JS dreamers are building castles on houses of cards and distracting entire communities of young minds from contributing to technologies that could actually work to repair the damage the Internet has afflicted democracy. But maybe you have some papers proving how a web-based distributed hash table can be made sybil-attack resistant and secure from eavesdropping. To me that is only achievable with such large amounts of low-level code and packet routing that it totally blows the architectural options of a web browser. So what's your take on this.. will you admit your plan is unlikely to work out or come up with wild arguments just so you can continue down the path of good intentions? -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Fri Jul 17 10:52:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6AE1ACDC0 for ; Fri, 17 Jul 2015 10:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cQ3PL25URcW for ; Fri, 17 Jul 2015 10:52:24 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217BB1ACDB4 for ; Fri, 17 Jul 2015 10:52:24 -0700 (PDT) Received: by qged69 with SMTP id d69so21168247qge.0 for ; Fri, 17 Jul 2015 10:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zEpoI7049JAcCQ6L27qJyevtY5eo0kSny8ZDxyg7YBw=; b=P/MEHBRl+MRa2CSId/KCheii45eV/FzB+1ezGbAbVvjl5hgscgjE1+cXjbPTfs/Otn PjlCaRkh0lEua3AE6/5DZkBI9QVdaanpVhgzbldu8cAkAobPLVnbTU24mveswf1CLUsa XbswioKAd0T8Qz05fy9m3VCd0MiHb1qjvwfvJ91WkEMRI0o9jLoROkOH6tIuLVTDIfv9 moednkFzXx5TZ58Ovh+T9pnlojnXur2PoqlojQFxL9qtITKi/kfdX6U+KvTElTl3dzJQ /eydpTEuf4zaaNTPRDKdcGPWnuCxIMJVIlkjFT/0WDILksGEdwtoMr0Io5vETUlye2wn 6v1w== X-Received: by 10.55.17.197 with SMTP id 66mr27642429qkr.90.1437155543375; Fri, 17 Jul 2015 10:52:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.130 with HTTP; Fri, 17 Jul 2015 10:51:53 -0700 (PDT) In-Reply-To: <55A4097F.3060106@mozilla.com> References: <55A22A1B.4000202@gmail.com> <804017F1-0211-43F0-9CE3-1F51A9C9E705@lurchi.franken.de> <55A4097F.3060106@mozilla.com> From: Daniel Roesler Date: Fri, 17 Jul 2015 10:51:53 -0700 Message-ID: To: "Timothy B. Terriberry" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 17:52:26 -0000 On Sun, Jul 12, 2015 at 1:15 PM, tim panton wrote: > > The problem is that those VPNs are misconfigured. > It appears that both built-in L2TP and PPTP VPN options for OSX cannot be configured to hide the real IP address from WebRTC, even if you select the option to route all traffic through the VPN[1]. You need to install an OpenVPN client like Tunnelblick in order to hide your real IP from WebRTC. As soon as I get some time on a Windows box, I'll investigate the default behavior there. [1]: https://i.imgur.com/Hyq1zLz.png Since this is the behavior for built-in VPN options, and even if you select the "send all traffic over VPN" setting, I disagree with the sentiment that it's the user's fault or that the VPN has been misconfigured. WebRTC should assume default behavior for operating system VPN behavior and apply additional security steps to protect the user when the operating system falls short. Blaming the operating system is no excuse when you know the problem exists and you have the means to protect the user. On Mon, Jul 13, 2015 at 11:54 AM, Timothy B. Terriberry wrote: > > These issues are all detailed in > . I would > encourage those participating in this thread to read that document. We could > always benefit from additional review. -------------- API Requirement: The API MUST provide a mechanism to allow the JS to suppress ICE negotiation (though perhaps to allow candidate gathering) until the user has decided to answer the call [note: determining when the call has been answered is a question for the JS.] This enables a user to prevent a peer from learning their IP address if they elect not to answer a call and also from learning whether the user is online. -------------- I'd like to request that "suppress ICE negotiation (though perhaps to allow candidate gathering)" be changed to "suppress ICE negotiation and candidate gathering". That would be enough to require user consent before local and VPN IP addresses are gathered. Daniel From nobody Fri Jul 17 10:58:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A766C1ACE2F for ; Fri, 17 Jul 2015 10:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHULJrmrVSgJ for ; Fri, 17 Jul 2015 10:58:44 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352A01ACE2E for ; Fri, 17 Jul 2015 10:58:44 -0700 (PDT) Received: by wgkl9 with SMTP id l9so87758997wgk.1 for ; Fri, 17 Jul 2015 10:58:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3ffMSN82/SeosWHPl/XzkPpXax9EqV5Bc8mPM3S+wsY=; b=j3UWWkXQTgU/uWNtmCtSYAuXs8EXGlKRrfyCkZiWvQUdeyYVkt9CVhmAl5320QzCGt 4tglo2myuConaIs6t7mG47hvOmF0H7WO93snzy2aj7mhP5qBs7ocsap8EHIRgsvs6AgX 3rNFb0LqRvQWcThoDDRNMuZmYCvOohWuM+p2hpiFDy0FMECnR6Kb8Z3anrR5rjr+TLQe NDlwqEwHW/5dzAnttqU15JFTAjDqlQXhDn5uMn4Lj+0gkAkUSLB8i4/bY9tXGkS5kpFx WAe2kz90Bf5ZI4Cgc5Nl5mc0o0kOTWFQpuRXbOYXiBR0O6Fogt3TfFc/JEFfPQTrIzKv J1OA== X-Gm-Message-State: ALoCoQnczviVhuf9L/2B0AbVhBZeFigGxqeQbjPHB1uajpi8vU562y4oCUSJvAFAeIbhyHkrq5iY X-Received: by 10.180.87.168 with SMTP id az8mr18038694wib.53.1437155922983; Fri, 17 Jul 2015 10:58:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Fri, 17 Jul 2015 10:58:03 -0700 (PDT) In-Reply-To: References: <55A22A1B.4000202@gmail.com> <804017F1-0211-43F0-9CE3-1F51A9C9E705@lurchi.franken.de> <55A4097F.3060106@mozilla.com> From: Eric Rescorla Date: Fri, 17 Jul 2015 10:58:03 -0700 Message-ID: To: Daniel Roesler Content-Type: multipart/alternative; boundary=90e6ba181b8246c571051b15f02b Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 17:58:46 -0000 --90e6ba181b8246c571051b15f02b Content-Type: text/plain; charset=UTF-8 On Fri, Jul 17, 2015 at 10:51 AM, Daniel Roesler wrote: > On Sun, Jul 12, 2015 at 1:15 PM, tim panton wrote: > > > > The problem is that those VPNs are misconfigured. > > > > It appears that both built-in L2TP and PPTP VPN options for OSX cannot > be configured to hide the real IP address from WebRTC, even if you > select the option to route all traffic through the VPN[1]. You need to > install an OpenVPN client like Tunnelblick in order to hide your real > IP from WebRTC. As soon as I get some time on a Windows box, I'll > investigate the default behavior there. > > [1]: https://i.imgur.com/Hyq1zLz.png > > Since this is the behavior for built-in VPN options, and even if you > select the "send all traffic over VPN" setting, I disagree with the > sentiment that it's the user's fault or that the VPN has been > misconfigured. WebRTC should assume default behavior for operating > system VPN behavior and apply additional security steps to protect the > user when the operating system falls short. Blaming the operating > system is no excuse when you know the problem exists and you have the > means to protect the user. Rather than trying to decide who's responsibility this is, I suggest it would be more productive to ask whether there's some way for the browser to determine whether the VPN has been configured in this way. If there is, then I at least would be willing to investigate whether it's possible for the browser to behave differently in these cases. For starters, I would ask what netstat -rn shows in these cases. > On Mon, Jul 13, 2015 at 11:54 AM, Timothy B. Terriberry > wrote: > > > > These issues are all detailed in > > . I would > > encourage those participating in this thread to read that document. We > could > > always benefit from additional review. > > -------------- > API Requirement: The API MUST provide a mechanism to allow the JS to > suppress ICE negotiation (though perhaps to allow candidate > gathering) until the user has decided to answer the call [note: > determining when the call has been answered is a question for the > JS.] This enables a user to prevent a peer from learning their IP > address if they elect not to answer a call and also from learning > whether the user is online. > -------------- > > I'd like to request that "suppress ICE negotiation (though perhaps to > allow candidate gathering)" be changed to "suppress ICE negotiation > and candidate gathering". That would be enough to require user consent > before local and VPN IP addresses are gathered. This wouldn't address your issue, because this is under *API* control. the purpose of this section is not to protect the user from the site but rather to allow the site to provide privacy features for the user. -Ekr --90e6ba181b8246c571051b15f02b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 17, 2015 at 10:51 AM, Daniel Roesler <= diafygi@gmail.com> wrote:
On S= un, Jul 12, 2015 at 1:15 PM, tim panton <tim@phonefromhere.com> wrote:
>
> The problem is that those VPNs are misconfigured.
>

It appears that both built-in L2TP and PPTP VPN options for OSX cann= ot
be configured to hide the real IP address from WebRTC, even if you
select the option to route all traffic through the VPN[1]. You need to
install an OpenVPN client like Tunnelblick in order to hide your real
IP from WebRTC. As soon as I get some time on a Windows box, I'll
investigate the default behavior there.

[1]: https://i.imgur.com/Hyq1zLz.png

Since this is the behavior for built-in VPN options, and even if you
select the "send all traffic over VPN" setting, I disagree with t= he
sentiment that it's the user's fault or that the VPN has been
misconfigured. WebRTC should assume default behavior for operating
system VPN behavior and apply additional security steps to protect the
user when the operating system falls short. Blaming the operating
system is no excuse when you know the problem exists and you have the
means to protect the user.

Rather than tryi= ng to decide who's responsibility this is, I suggest it would be
<= div>more productive to ask whether there's some way for the browser to = determine
whether the VPN has been configured in this way. If the= re is, then I at least
would be willing to investigate whether it= 's possible for the browser to
behave differently in these ca= ses.

For starters, I would ask what netstat -rn sh= ows in these cases.

=C2=A0
On Mon, Jul 13, 2015 at 11:54 AM, Timothy B. Terriberry
<tterriberry@mozilla.com&= gt; wrote:
>
> These issues are all detailed in
> <https://tools.ietf.org/html/draf= t-ietf-rtcweb-security-arch>. I would
> encourage those participating in this thread to read that document. We= could
> always benefit from additional review.

-------<snip from Section 5.4>-------
=C2=A0 =C2=A0API Requirement:=C2=A0 The API MUST provide a mechanism to all= ow the JS to
=C2=A0 =C2=A0 =C2=A0 suppress ICE negotiation (though perhaps to allow cand= idate
=C2=A0 =C2=A0 =C2=A0 gathering) until the user has decided to answer the ca= ll [note:
=C2=A0 =C2=A0 =C2=A0 determining when the call has been answered is a quest= ion for the
=C2=A0 =C2=A0 =C2=A0 JS.]=C2=A0 This enables a user to prevent a peer from = learning their IP
=C2=A0 =C2=A0 =C2=A0 address if they elect not to answer a call and also fr= om learning
=C2=A0 =C2=A0 =C2=A0 whether the user is online.
-------</snip from Section 5.4>-------

I'd like to request that "suppress ICE negotiation (though perhaps= to
allow candidate gathering)" be changed to "suppress ICE negotiati= on
and candidate gathering". That would be enough to require user consent=
before local and VPN IP addresses are gathered.

=
This wouldn't address your issue, because this is under *API* cont= rol.
the purpose of this section is not to protect the user from = the site but
rather to allow the site to provide privacy features= for the user.


-Ekr

<= /div>


--90e6ba181b8246c571051b15f02b-- From nobody Fri Jul 17 11:05:08 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDAC1ACE9F for ; Fri, 17 Jul 2015 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvkeMP8RJOaO for ; Fri, 17 Jul 2015 11:05:05 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C026C1ACE2D for ; Fri, 17 Jul 2015 11:05:05 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so1399825igb.0 for ; Fri, 17 Jul 2015 11:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QJPW0GLpZxyzUbvk64zfrRX+172++WMmQ1Rsr91Mqio=; b=GJQn1Ht9fviwZIVvhDnVIVTlBCfGwm/rm2AsWPcpZrgCLr0o+fpHNI+QKbA+AsBCTQ 7Kcg4+JmKfTVzPRL+9vdfMLulOzLJrQ++Dqx5zmx0OS4cKKfpS5kBk2Au/D3SIaZgyA3 03kQgsGvZL13dYAmsP6nM029W6H63IfBPTGaUPDu7AJriO1TlXKTDjRKC6UlOJh1bqQU 9yprpltfsUiMi+3DPsMR4pQieeB9xW/k8Q47eya2QMOizWEVK8Ol3jVHqGC4ATXcIq75 x7oDIbLp7zCNdahLiwioMR5u2Hd4rw92qr9p6lvzx98W7YpnncV2aGt/8ZbV5JY6H3uR 3C9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QJPW0GLpZxyzUbvk64zfrRX+172++WMmQ1Rsr91Mqio=; b=hlQApei7Cr/h3OmwpygQtBFYMtIh/PKm3hcdwxjiPhHPjeY6XTj094IP5Bd7Vrb0aK hRHnObrKPcCBaCi5HHV6FLfAqd8Mkov9KTBdUcXDr3xLbX5f6TfaKGJd6zVlv9oi4Ydv ZS/kD0oHKuAHZ3VCXknLHg53fHh9bphTEPrC11itiQYM5IXTR4nKJPSrRfZsV8I1Q3/5 tspN/upAL3lVXNnh/KYep2nLhRwRJgmIKAQ6+GR102FntlNk1jYF98muRuzqMo+DCd83 4MssD4WC3kPAesaRIZJUsAg16T9KU58RUxumselFvBJBypUD3cXrQDdau4OC2pVc8wnh HiPg== X-Gm-Message-State: ALoCoQlWT4eFlXpQyFZ3cFQfAyo4XCa6rMFZ+GcGtnscqq9YnRFA2AGYMwZUmvcBujfXpev2mkYc X-Received: by 10.50.29.75 with SMTP id i11mr12246410igh.50.1437156304942; Fri, 17 Jul 2015 11:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.233 with HTTP; Fri, 17 Jul 2015 11:04:45 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Fri, 17 Jul 2015 11:04:45 -0700 Message-ID: To: Daniel Roesler Content-Type: multipart/alternative; boundary=047d7bd767780b33d3051b1607b6 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 18:05:06 -0000 --047d7bd767780b33d3051b1607b6 Content-Type: text/plain; charset=UTF-8 > > > I'm really unclear on why it's so important to have the silent webRTC > data channel behavior. P2P data connections should be held to the same > consent requirements just like P2P video and voice connections. In > addition to the silent third party local IP tracking, a silent P2P > data channel opens up users to silently becoming nodes in a web-based > file sharing network. For example, webtorrent[2] can be silently > embedded on a website so that all of the users to that website start > seeding content they don't know they are seeding. > > > This is already possible using non-WebRTC technologies, e.g. web sockets. As such, I don't think that permission should be needed to create a data channel, or receive (but not send) media. That said, I agree that WebRTC should not allow drive-by harvesting of IP addresses, and we intend to make changes to Chrome to prevent this. --047d7bd767780b33d3051b1607b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm really unclear on why it's so important to have the silent webR= TC
data channel behavior. P2P data connections should be held to the same
consent requirements just like P2P video and voice connections. In
addition to the silent third party local IP tracking, a silent P2P
data channel opens up users to silently becoming nodes in a web-based
file sharing network. For example, webtorrent[2] can be silently
embedded on a website so that all of the users to that website start
seeding content they don't know they are seeding.



This is already possible using non= -WebRTC technologies, e.g. web sockets. As such, I don't think that per= mission should be needed to create a data channel, or receive (but not send= ) media.

That said, I agree that WebRTC should not= allow drive-by harvesting of IP addresses, and we intend to make changes t= o Chrome to prevent this.

--047d7bd767780b33d3051b1607b6-- From nobody Fri Jul 17 11:23:03 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73311AD0B0 for ; Fri, 17 Jul 2015 11:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7xvO5vbXq7W for ; Fri, 17 Jul 2015 11:23:00 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0491AD0AC for ; Fri, 17 Jul 2015 11:22:59 -0700 (PDT) Received: by qkdv3 with SMTP id v3so74792773qkd.3 for ; Fri, 17 Jul 2015 11:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PiUyTW1q29Vs16f9oYcfIs8C4g3IoAwb5dnnC+oGm90=; b=OKvOI1fcFw3hVGBSFF9kDg11+lZgtKgBRXxZnZ5JS7saG7DtXY7opI8Ftj5026t1TT Vr/dVW+zQh9oJHO3zrZ6sVlg7tt/ERnkk/vQYcnCWYIyn/3Bjj+1SFxeUULLRQ7p+hYV P8XlsEDg1FsPnBaysGdtGzUhLzR6SOMMmpjnzjmeKmu00IO+f0W1hhdsgpAcYzV/7A1K g49fH4pfpWdAy69ocNWpSILQIv3ahyoWqekS5vwBALqtUPjRAXNc+/XdfWPnfxue0neD p3K+dU3cNG75ZRph2ajwI7IOb7zf+YbqbNBGYmELC3T+H/TRrb9WRzfwDoZUpvIM3/U4 zY4Q== X-Received: by 10.55.43.75 with SMTP id r72mr28078414qkh.80.1437157379113; Fri, 17 Jul 2015 11:22:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.130 with HTTP; Fri, 17 Jul 2015 11:22:29 -0700 (PDT) In-Reply-To: References: From: Daniel Roesler Date: Fri, 17 Jul 2015 11:22:29 -0700 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 18:23:02 -0000 On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti wrote: > > This is already possible using non-WebRTC technologies, e.g. web sockets. As > such, I don't think that permission should be needed to create a data > channel, or receive (but not send) media. > The big difference is that Web Sockets starts off with an HTTP request, so it can be filtered by various plugins (PrivacyBadger, uBlock, Ghostery, etc.). WebRTC is invisible to those services since it does not have any HTTP requests at all. In fact, is WebRTC the only browser standard (i.e. not flash) that can fire off a DNS request that's not (at least at first) for an HTTP address[1]? Lacking an initial HTTP request makes it impossible for plugins to selectively filter these requests, so they have to fall back to an all-or-nothing config setting approach (which hurts WebRTC adoption in general)[2][3]. > That said, I agree that WebRTC should not allow drive-by harvesting of IP > addresses, and we intend to make changes to Chrome to prevent this. Great to hear! Thanks! Is there a bug that is tracking this? [1]: https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers [2]: https://github.com/EFForg/privacybadgerfirefox/issues/394 [3]: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3 Daniel From nobody Fri Jul 17 11:36:39 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FBB1B2A2A for ; Fri, 17 Jul 2015 11:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaiE6U9MlDb9 for ; Fri, 17 Jul 2015 11:36:37 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3EC1B2A27 for ; Fri, 17 Jul 2015 11:36:37 -0700 (PDT) Received: by igbij6 with SMTP id ij6so43585002igb.1 for ; Fri, 17 Jul 2015 11:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=t70uDl/PIX7FhCi4uP94oQTWmYGMBlvuCPLfO/IdlqQ=; b=CfLZ4/Gk39Vj2eJTNHyOBh8HwJJajslIYpyJMbXMxwMmfjetybSKQtr6KPDBcrzHWv 0BhUA2kWhaG+mxFozm5BYzIQQkOQH9587WMpAD5aoa26dHIaeohlJgwFUv/QIpSAC8CV f6MKBVHLfxM62s2TPJGvLXNOmaUQKJtE9+RVHSc0iKcdK+GUP0SyDVfBEv/xahQNDxnx St5Idi8a8AekrGCB02LS74IhkqnI1l2eLeIIFHlG9M+dLRhILQYJcsSVh3zKbQvYMNg3 hpV11tF4i8Lkw5T9En7kF4PGkH6+/zylmxbhLhqxyj3R7S4hyqjD/Q74PXht0oHqsjz1 V+Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=t70uDl/PIX7FhCi4uP94oQTWmYGMBlvuCPLfO/IdlqQ=; b=MXLrzNeGow2xuj3OhwmdZZBZJdGOH1nxSu/yhzVC/MgUDBXQFUxd3iHALIsnP/Cc7M MEfGgVuQ4dRfNd9/S+vX/Gd5DQQYeM9JTx4sYJJi0HKHHRDY+p/4IGx+D3hqCUUCkJl0 EA9NOHtfXXqc/TH7rrrqQwhEO5f57136E2KupIpLE4LS6nCHj6gneTFWoeSdINwCImG8 qGCeNk/yFwQezGZrnpD5puxvwqbSp/In+1cIegEQkmI6LeS7R0bYCxCUBw5WBvh/Y6yO 30ivIe/PwnHmwZRN7hlZ1xgzpbdgp8ISeC3jCtt2KNBoiZY9tYZz7dGgkcNvtUKqdSfW /szA== X-Gm-Message-State: ALoCoQnsiNHmR0ae2WwdMeU0Q+Dt9iJ7i+ojgB6iFWrb2rSek0dlOs8srqtWOGqOTQzkWZ0fwT1E X-Received: by 10.50.29.75 with SMTP id i11mr12408428igh.50.1437158196413; Fri, 17 Jul 2015 11:36:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.233 with HTTP; Fri, 17 Jul 2015 11:36:14 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Fri, 17 Jul 2015 11:36:14 -0700 Message-ID: To: Daniel Roesler Content-Type: multipart/alternative; boundary=047d7bd76778c8c164051b16775b Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 18:36:38 -0000 --047d7bd76778c8c164051b16775b Content-Type: text/plain; charset=UTF-8 The title is somewhat inaccurate, but https://code.google.com/p/chromium/issues/detail?id=457492 is the current bug for this. See also https://code.google.com/p/chromium/issues/detail?id=333752, from which the above bug was spun out. On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler wrote: > On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti > wrote: > > > > This is already possible using non-WebRTC technologies, e.g. web > sockets. As > > such, I don't think that permission should be needed to create a data > > channel, or receive (but not send) media. > > > > The big difference is that Web Sockets starts off with an HTTP > request, so it can be filtered by various plugins (PrivacyBadger, > uBlock, Ghostery, etc.). WebRTC is invisible to those services since > it does not have any HTTP requests at all. In fact, is WebRTC the only > browser standard (i.e. not flash) that can fire off a DNS request > that's not (at least at first) for an HTTP address[1]? Lacking an > initial HTTP request makes it impossible for plugins to selectively > filter these requests, so they have to fall back to an all-or-nothing > config setting approach (which hurts WebRTC adoption in > general)[2][3]. > > > That said, I agree that WebRTC should not allow drive-by harvesting of IP > > addresses, and we intend to make changes to Chrome to prevent this. > > Great to hear! Thanks! Is there a bug that is tracking this? > > > [1]: > https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers > [2]: https://github.com/EFForg/privacybadgerfirefox/issues/394 > [3]: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3 > > Daniel > --047d7bd76778c8c164051b16775b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The title is somewhat inaccurate, but=C2=A0https://code.google.com/p/chromium/issues/detail?id=3D457492 is the cu= rrent bug for this.=C2=A0
See also=C2=A0https://code.google.com/p/chromiu= m/issues/detail?id=3D333752, from which the above bug was spun out.

On Fri, J= ul 17, 2015 at 11:22 AM, Daniel Roesler <diafygi@gmail.com> = wrote:
On Fri, Jul 17, 2= 015 at 11:04 AM, Justin Uberti <ju= berti@google.com> wrote:
>
> This is already possible using non-WebRTC technologies, e.g. web socke= ts. As
> such, I don't think that permission should be needed to create a d= ata
> channel, or receive (but not send) media.
>

The big difference is that Web Sockets starts off with an HTTP
request, so it can be filtered by various plugins (PrivacyBadger,
uBlock, Ghostery, etc.). WebRTC is invisible to those services since
it does not have any HTTP requests at all. In fact, is WebRTC the only
browser standard (i.e. not flash) that can fire off a DNS request
that's not (at least at first) for an HTTP address[1]? Lacking an
initial HTTP request makes it impossible for plugins to selectively
filter these requests, so they have to fall back to an all-or-nothing
config setting approach (which hurts WebRTC adoption in
general)[2][3].

> That said, I agree that WebRTC should not allow drive-by harvesting of= IP
> addresses, and we intend to make changes to Chrome to prevent this.
Great to hear! Thanks! Is there a bug that is tracking this?


[1]: https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_= persistent_identifiers
[2]: https://github.com/EFForg/privacybadge= rfirefox/issues/394
[3]: https://github.com/gorhill/uBlock/release= s/tag/0.9.9.3

Daniel

--047d7bd76778c8c164051b16775b-- From nobody Fri Jul 17 11:40:14 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205001B2A37 for ; Fri, 17 Jul 2015 11:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILzJSxW-5YdT for ; Fri, 17 Jul 2015 11:40:10 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6619D1B2A3F for ; Fri, 17 Jul 2015 11:40:10 -0700 (PDT) Received: by iecuq6 with SMTP id uq6so83026483iec.2 for ; Fri, 17 Jul 2015 11:40:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2lKrWePBBAHHzfaSD+rkvQDdO8EsbVFHmShuxHTen4M=; b=BbLwJAj0xPHdO/Ko3KIx323/2nINCgEN08fc+cb4c9JhmFfFkRfGaOnQ2Qg/Ak1SUf fXgYUWQA2q8DJz0LPQtgo/dwbL5eoeEWzewl3MSCY4uIlq4u2ctCLdVmDErkAPJ4oGjf q/khBg94BJFy1fbhjPFEEAokh9efv/qmpSNloREOfIko8GFv3EvKZkAfIP6H8AiIrD00 iR8zgBUC/0DwTO7dkJ1PjUn13cxUBSFBtJfHW5ETKzyMaBCjXR8fHSs58i72jUkoIPVe BHn1skrsYGk6z/zOUzblIAF1cN0/YyfImsuGqQ9jh7JKslhCyp8JnbNh2mhENuLHQ55C L8cg== X-Gm-Message-State: ALoCoQnJHLEhvK2TN4r86gXVzpLjkh6GSUk5upkf6u6JpvhBrj7eA4sds3NQSzSIU5ulRJxiNMpf X-Received: by 10.50.20.135 with SMTP id n7mr12767560ige.58.1437158409663; Fri, 17 Jul 2015 11:40:09 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com. [209.85.213.170]) by smtp.gmail.com with ESMTPSA id ji7sm4447312igb.2.2015.07.17.11.40.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2015 11:40:08 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so43627385igc.0 for ; Fri, 17 Jul 2015 11:40:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.7.104 with SMTP id i8mr13448824iga.50.1437158407446; Fri, 17 Jul 2015 11:40:07 -0700 (PDT) Received: by 10.64.171.114 with HTTP; Fri, 17 Jul 2015 11:40:07 -0700 (PDT) In-Reply-To: <182AFB04-5F8E-4C93-A41C-6EFE9ECF04B3@iii.ca> References: <182AFB04-5F8E-4C93-A41C-6EFE9ECF04B3@iii.ca> Date: Fri, 17 Jul 2015 11:40:07 -0700 Message-ID: From: Benjamin Schwartz To: Cullen Jennings Content-Type: multipart/alternative; boundary=089e01183ebc5cc8d5051b1684ee Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-jennings-behave-rtcweb-firewall-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 18:40:13 -0000 --089e01183ebc5cc8d5051b1684ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Regarding the use of ORIGIN, the current text says > Does adding the ORIGIN reduce user privacy? ... when the original TLS connection for the HTTP was made, the Server Name Indication (SNI) in the TLS of the HTTPS connection also revealed facebook.com, largely for the same reasons - so that the firewall would be able to see which applications are using the network. I expect you're aware that this may not be true in TLS 1.3. On Thu, Jul 16, 2015 at 12:51 PM, Cullen Jennings wrote: > Good points.I will update the draft but in the meantime there is a copy a= t > http://fluffy.github.io/iceTrav/ > > The summary of the algorithm is roughly: > > =E2=80=A2The firewall looks for any outgoing STUN requests to STUN port (= 3478). > When it finds one, it stores the 3 tuple of the source address port and > protocol=3DUDP and for the next 30 seconds checks any packets from this 3 > tuple to see if they are ICE connectivity checks. > > =E2=80=A2When firewall sees an ICE connectivity check from the inside hos= t (which > is a STUN Binding Request containing the ice username), it stores that ic= e > username value, and forwards the packet. Thereafter, STUN Binding Reques= ts > and Binding Responses with matching 4-tuple (inside IP address, > protocol=3DUDP, inside port, and matching ice username) are allowed in an= y > direction (inside->outside and outside->inside). For each 5-tuple, if a > STUN Binding Request has a Success STUN Binding Response (with same > transaction ID), in either direction, that 5-tuple is promoted to allow > non-STUN traffic (DTLS, SRTP, and anything else). > > =E2=80=A2Both promoted and non-promoted pinholes are closed after 30 seco= nds of > not seeing a STUN Binding Request and Response transaction, in either > direction. > > =E2=80=A2(Note to match the ice username external requests will need the = halves on > either side of =E2=80=9C:=E2=80=9D swapped) > > (and thanks to Dan Wing who came up with much of the above proposal ) > > more inline > > > On Jul 8, 2015, at 8:39 AM, Eric Rescorla wrote: > > > > I have taken a brief look at this draft and I don't believe that the > proposed pinhole/inspection > > algorithm provides the desired assurances of verifying consent: > > > > 1. If you open up an incoming/outgoing pinhole on outgoing packet, prio= r > to > > receiving an incoming STUN packet, then if the internal implementation > > simply sends a new outgoing STUN packet every 5 seconds, then they > > never need to rely on external consent. > > > > 2. If you just require *a* incoming STUN packet to be received in order > to > > extend the lifetime to 30 seconds, then an off-path attacker can forge > > a STUN response that will cause the pinhole to be open for 30 seconds. > > (Hence the need for the STUN transaction ID). > > Yah, don't want outside stuff to extended it. Intent was only inside stuf= f > should extend. > > > > > It seems to me that you should be instead requiring a complete STUN > > transaction before allowing any non-STUN outgoing traffic. It would > probably > > be safe-ish to require it before allowing any incoming traffic as well, > though > > that leaves the chance that you get a small amount of clipping with > packet > > drops or reordering. > > Agree - have changed to that. > > > > > > > WRT to the origin attribute, I have mixed feelings. I agree that your > SNI argument > > is strong, but there is also a move to figure out how to encrypt SNI, s= o > every time > > we extend that argument it makes that harder. OTOH, STUN origin will be > > sent a lot less often than SNI, I imagine. > > Sounds like this is going to get discussed in Tram. Unfortunately I think > we have to choose between least evil on this topic. > > > > > > > I don't understand Section 6. Is this guidance to firewall vendors or t= o > browser > > implementors. If the former, the firewall has no way of knowing what > "requests" > > are if the connection use HTTPS (and if is uses HTTP, you have DPI-type > methods for > > determining whether something is voice or video. If this is guidance to > browser > > vendors, I consider it extremely unlikely that we would implement it. > > advice for firewall vendors for more or less all TLS connections that > might be web traffic. It's horrific of course but since they are > implementing things along these lines we might as well be specific on the > algorithm so we understand the breakage. Or go deal with the root causes > that theses sort of things (basically trying to hide WebRTC traffic insid= e > HTTP) . I imagine this algorithm is not the best, it was just a rough pla= ce > holder. Its needs a bit of tuning to interact with dash in a reasonable w= ay. > > > > > > > > Point #4 in your security considerations section seems like an entirely > lost > > cause, unless you assume that attackers are not really trying. > > > > -Ekr > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e01183ebc5cc8d5051b1684ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding the use of ORIGIN, the current text says

> Does adding the ORIGIN reduce user privacy?=C2=A0...= when the original TLS connection for the HTTP was made, the Server Name In= dication (SNI) in the TLS of the HTTPS connection also revealed facebook.com, largely for the same reasons - so th= at the firewall would be able to see which applications are using the netwo= rk.

I expect you're aware that this may not be true = in TLS 1.3.

On= Thu, Jul 16, 2015 at 12:51 PM, Cullen Jennings <fluffy@iii.ca> = wrote:
Good points.I will update the draf= t but in the meantime there is a copy at
http://fluffy.github.io/iceTrav/

The summary of the algorithm is roughly:

=E2=80=A2The firewall looks for any outgoing STUN requests to STUN port (34= 78). When it finds one, it stores the 3 tuple of the source address port an= d protocol=3DUDP and for the next 30 seconds checks any packets from this 3= tuple to see if they are ICE connectivity checks.

=E2=80=A2When firewall sees an ICE connectivity check from the inside host = (which is a STUN Binding Request containing the ice username), it stores th= at ice username value, and forwards the packet.=C2=A0 Thereafter, STUN Bind= ing Requests and Binding Responses with matching 4-tuple (inside IP address= , protocol=3DUDP, inside port, and matching ice username) are allowed in an= y direction (inside->outside and outside->inside).=C2=A0 For each 5-t= uple, if a STUN Binding Request has a Success STUN Binding Response (with s= ame transaction ID), in either direction, that 5-tuple is promoted to allow= non-STUN traffic (DTLS, SRTP, and anything else).

=E2=80=A2Both promoted and non-promoted pinholes are closed after 30 second= s of not seeing a STUN Binding Request and Response transaction, in either = direction.

=E2=80=A2(Note to match the ice username external requests will need the ha= lves on either side of =E2=80=9C:=E2=80=9D swapped)

(and thanks to=C2=A0 Dan Wing who came up with much of the above proposal )=

more inline

> On Jul 8, 2015, at 8:39 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> I have taken a brief look at this draft and I don't believe that t= he proposed pinhole/inspection
> algorithm provides the desired assurances of verifying consent:
>
> 1. If you open up an incoming/outgoing pinhole on outgoing packet, pri= or to
> receiving an incoming STUN packet, then if the internal implementation=
> simply sends a new outgoing STUN packet every 5 seconds, then they
> never need to rely on external consent.
>
> 2. If you just require *a* incoming STUN packet to be received in orde= r to
> extend the lifetime to 30 seconds, then an off-path attacker can forge=
> a STUN response that will cause the pinhole to be open for 30 seconds.=
> (Hence the need for the STUN transaction ID).

Yah, don't want outside stuff to extended it. Intent was only inside st= uff should extend.

>
> It seems to me that you should be instead requiring a complete STUN > transaction before allowing any non-STUN outgoing traffic. It would pr= obably
> be safe-ish to require it before allowing any incoming traffic as well= , though
> that leaves the chance that you get a small amount of clipping with pa= cket
> drops or reordering.

Agree - have changed to that.

>
>
> WRT to the origin attribute, I have mixed feelings. I agree that your = SNI argument
> is strong, but there is also a move to figure out how to encrypt SNI, = so every time
> we extend that argument it makes that harder. OTOH, STUN origin will b= e
> sent a lot less often than SNI, I imagine.

Sounds like this is going to get discussed in Tram. Unfortunately I think w= e have to choose between least evil on this topic.

>
>
> I don't understand Section 6. Is this guidance to firewall vendors= or to browser
> implementors. If the former, the firewall has no way of knowing what &= quot;requests"
> are if the connection use HTTPS (and if is uses HTTP, you have DPI-typ= e methods for
> determining whether something is voice or video. If this is guidance t= o browser
> vendors, I consider it extremely unlikely that we would implement it.<= br>
advice for firewall vendors for more or less all TLS connections that might= be web traffic. It's horrific of course but since they are implementin= g things along these lines we might as well be specific on the algorithm so= we understand the breakage. Or go deal with the root causes that theses so= rt of things (basically trying to hide WebRTC traffic inside HTTP) . I imag= ine this algorithm is not the best, it was just a rough place holder. Its n= eeds a bit of tuning to interact with dash in a reasonable way.


>
>
> Point #4 in your security considerations section seems like an entirel= y lost
> cause, unless you assume that attackers are not really trying.
>
> -Ekr
>
>
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--089e01183ebc5cc8d5051b1684ee-- From nobody Fri Jul 17 12:11:30 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749DA1A00B5 for ; Fri, 17 Jul 2015 12:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqPlTVma2N3R for ; Fri, 17 Jul 2015 12:11:27 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EBB1A00AC for ; Fri, 17 Jul 2015 12:11:26 -0700 (PDT) Received: by widjy10 with SMTP id jy10so48498106wid.1 for ; Fri, 17 Jul 2015 12:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=BizI0eL2qZonQ8irwz4HJBFHBDZ73Mln9jYthtORQEg=; b=R3yjbkr6gg5eH/HCD3W7fI1P+pCvMzbzgivnGwcfJI5+r8+GkZ1LTQ/BHUNsMj/KPg MzGRX+y95zLdka31k/Rh61JyR76SMZ9OcaRSLpDRCWBJLtNWizqRpj5X5SqXdi0+cBwd BA07oNEh6tU2SXN/iAjl2Si7sw7wnR+EiqTb/h2TQUEO0BZ+tE8D7IreVLttaSovkU9F 5G3dQy8Qb8BT3kvewDmhiBwqtI1pdCccxRGL2IOviwKy0HLjfs6MXupSdzMeoFs3/Pq3 J7QZb9z0s46RSbqrupJfrBO0/IRtYS0IGUGmoUZgJFpCdVX61wDO+8tObac5Rqpr13Pt nCHw== X-Received: by 10.194.81.67 with SMTP id y3mr31722473wjx.7.1437160285193; Fri, 17 Jul 2015 12:11:25 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by smtp.googlemail.com with ESMTPSA id lq9sm19539954wjb.35.2015.07.17.12.11.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2015 12:11:23 -0700 (PDT) To: rtcweb@ietf.org References: From: Sergio Garcia Murillo Message-ID: <55A95364.2070806@gmail.com> Date: Fri, 17 Jul 2015 21:11:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060507040108040800090400" Archived-At: Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 19:11:28 -0000 This is a multi-part message in MIME format. --------------060507040108040800090400 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit If I have understood the looong thread correctly, the issue is that Chrome overrides the OS default route and sends the STUN requests via all available interfaces, therefore leaking the IP addresses on the process. AFAIK, that behavior is a Chrome implementation decision (wrong in my opinion, but understandable) and it is not specified on WebRTC, so while acknowledging the importance of the issue, this is not something that we should discuss in this mailing list, except if we decide that we should decide to explicitly forbid this behavior and add it to the security draft. I will send a reply to discuss-webrtc to continue the discussion from a Chrome point of view. Best regards Sergio On 17/07/2015 20:36, Justin Uberti wrote: > The title is somewhat inaccurate, but > https://code.google.com/p/chromium/issues/detail?id=457492 is the > current bug for this. > See also https://code.google.com/p/chromium/issues/detail?id=333752, > from which the above bug was spun out. > > On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler > wrote: > > On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti > > wrote: > > > > This is already possible using non-WebRTC technologies, e.g. web > sockets. As > > such, I don't think that permission should be needed to create a > data > > channel, or receive (but not send) media. > > > > The big difference is that Web Sockets starts off with an HTTP > request, so it can be filtered by various plugins (PrivacyBadger, > uBlock, Ghostery, etc.). WebRTC is invisible to those services since > it does not have any HTTP requests at all. In fact, is WebRTC the only > browser standard (i.e. not flash) that can fire off a DNS request > that's not (at least at first) for an HTTP address[1]? Lacking an > initial HTTP request makes it impossible for plugins to selectively > filter these requests, so they have to fall back to an all-or-nothing > config setting approach (which hurts WebRTC adoption in > general)[2][3]. > > > That said, I agree that WebRTC should not allow drive-by > harvesting of IP > > addresses, and we intend to make changes to Chrome to prevent this. > > Great to hear! Thanks! Is there a bug that is tracking this? > > > [1]: > https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers > [2]: https://github.com/EFForg/privacybadgerfirefox/issues/394 > [3]: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3 > > Daniel > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060507040108040800090400 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
If I have understood the looong thread correctly, the issue is that Chrome overrides the OS default route and sends the STUN requests via all available interfaces, therefore leaking the IP addresses on the process.

AFAIK, that behavior is a Chrome implementation decision (wrong in my opinion, but understandable) and it is not specified on WebRTC, so while acknowledging the importance of the issue, this is not something that we should discuss in this mailing list, except if we decide that we should decide to explicitly forbid this behavior and add it to the security draft.

I will send a reply to discuss-webrtc to continue the discussion from a Chrome point of view.

Best regards
Sergio


On 17/07/2015 20:36, Justin Uberti wrote:
The title is somewhat inaccurate, but https://code.google.com/p/chromium/issues/detail?id=457492 is the current bug for this. 
See also https://code.google.com/p/chromium/issues/detail?id=333752, from which the above bug was spun out.

On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler <diafygi@gmail.com> wrote:
On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti <juberti@google.com> wrote:
>
> This is already possible using non-WebRTC technologies, e.g. web sockets. As
> such, I don't think that permission should be needed to create a data
> channel, or receive (but not send) media.
>

The big difference is that Web Sockets starts off with an HTTP
request, so it can be filtered by various plugins (PrivacyBadger,
uBlock, Ghostery, etc.). WebRTC is invisible to those services since
it does not have any HTTP requests at all. In fact, is WebRTC the only
browser standard (i.e. not flash) that can fire off a DNS request
that's not (at least at first) for an HTTP address[1]? Lacking an
initial HTTP request makes it impossible for plugins to selectively
filter these requests, so they have to fall back to an all-or-nothing
config setting approach (which hurts WebRTC adoption in
general)[2][3].

> That said, I agree that WebRTC should not allow drive-by harvesting of IP
> addresses, and we intend to make changes to Chrome to prevent this.

Great to hear! Thanks! Is there a bug that is tracking this?


[1]: https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers
[2]: https://github.com/EFForg/privacybadgerfirefox/issues/394
[3]: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3

Daniel



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------060507040108040800090400-- From nobody Fri Jul 17 12:20:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ECC1B2B7D for ; Fri, 17 Jul 2015 12:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz3g31yiIv2Q for ; Fri, 17 Jul 2015 12:20:31 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C931A908B for ; Fri, 17 Jul 2015 12:20:31 -0700 (PDT) Received: by qkfc129 with SMTP id c129so32904352qkf.1 for ; Fri, 17 Jul 2015 12:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cU7BX3xGOr3++TTJsc82lID6bUNFBrzILkVieKeU5Pg=; b=BeYFsBfxfJ8qiYeK62iUDezSAnNwxuLn2iKXoZSGBdIm99EMJ9Er4yhM1s1vTUfDyw pdWIKpZrvL4bTPfdXAlXVWCnIvCOssmIozluSthx2njSt8jAesvoOz0B6D01ltNxMq2w iZAUcdtMgZxoVZItaeLp0mUq26CQNeu6i5bcJ70FJFpIe8pAjonIf9cTFH5gi+sZ75Px FBoO8MpCefbSm5PwCq3Ty76eV2egNzCn82M1bfjYw1dQSlB4XSqt9yeoIgUEUz+UbPm6 Xd3ZSwMRVrcRF4qD5z+FTVZ/wPtxOsXJNwAmNNcP6hLRG939XBNbNOVZCqVJsITEc2Fk 5KXw== X-Received: by 10.140.234.142 with SMTP id f136mr21773444qhc.16.1437160830440; Fri, 17 Jul 2015 12:20:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.130 with HTTP; Fri, 17 Jul 2015 12:20:00 -0700 (PDT) In-Reply-To: <55A95364.2070806@gmail.com> References: <55A95364.2070806@gmail.com> From: Daniel Roesler Date: Fri, 17 Jul 2015 12:20:00 -0700 Message-ID: To: Sergio Garcia Murillo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 19:20:32 -0000 On Fri, Jul 17, 2015 at 12:11 PM, Sergio Garcia Murillo wrote: > If I have understood the looong thread correctly, the issue is that Chrome > overrides the OS default route and sends the STUN requests via all available > interfaces, therefore leaking the IP addresses on the process. Firefox has the same behavior in OSX. So it might also be OSX not really sending all the traffic through the VPN (like the setting says). Would love someone more competent than me to investigate in both OSX and Windows. I'd be willing to fund VPN subscriptions for them to use with their research (Private Internet Access supports L2TP, PPTP, OpenVPN, SOCKS, and they have their own client, but other VPNs are reported as having their own clients leak the IP, so I'm willing to fund those, too). Daniel From nobody Fri Jul 17 13:26:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705C21A1B0C for ; Fri, 17 Jul 2015 13:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAWZD8vGkcS5 for ; Fri, 17 Jul 2015 13:26:18 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CF01A1B05 for ; Fri, 17 Jul 2015 13:26:18 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so45538448igc.0 for ; Fri, 17 Jul 2015 13:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eCKJdgOXhJxPlXnL0etxXjSoeP61NrGT9e/DebrUYrI=; b=FZ1FB3s17RuCx0hl2XFrqCkKIt2iSGTfdQlKoCIcQ42Pzpyz2xkZ/GvtcSrC57vO4J TnjUpRRC17TGD/BWPKRKgUe9hCBvUYP2WHnaM/kj1yYN3Jy6gxgTEXGVtzfbV8fOBuXw fwygEpwdhTO/tUG4j8LEJuq2IVLXySo0SK08oWIyyycFRPH1yp59awO5bGrq+KvK168Z U198QJX3Zz9pXlyqvbdx5xImP4seuX+ZwIiNuzFsOGpcIRPaPQ4XvHIfHIAmllE1Sewf 5ZzDnWPSonng7wcHqbSjAv4Bfz7kKSba2xswjUMBJWJSvN0H+qWZfLC4dP1pBrTLM+27 LXzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eCKJdgOXhJxPlXnL0etxXjSoeP61NrGT9e/DebrUYrI=; b=aWjvT0kKK/D7JK4aVqCoYMbMDGBuak88SMYzmuOa3aFbBv4B+6EBCqJH8T01BjXaeE z7EH6KVmMoxE353Ly+zgVc/MrzRZWE53KXP74VkktGgbMcIyXTAfSmcp1CoxM7/TXmNv wi1dkoOpsl4yps4HIkAbjDEgN6iqNgseNnM42CsIP9DLgv6Z7YlcawwY0Af9bL0QgILM ExaythvO57XAK9Zf6jF0zffG1k0JVVPaOpIFStn2W6oMl7/4yi1Isyiy7eJ91Tm+kJXj AUboAprhuLjiFoe71xLF1DpS/pGTz5IuPjD8QmYd9Q31vN6AF1gKDXHqjyZGx4w8CGs7 NtmQ== X-Gm-Message-State: ALoCoQmUDP73Lwq8tIqjMMXNastNKqxpGiFXUdzi7h5KGsEtgmK3qf6UEgE7hUGU3i0VT3rHhFYn X-Received: by 10.50.29.75 with SMTP id i11mr288807igh.50.1437164777847; Fri, 17 Jul 2015 13:26:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.234 with HTTP; Fri, 17 Jul 2015 13:25:57 -0700 (PDT) In-Reply-To: <55A95364.2070806@gmail.com> References: <55A95364.2070806@gmail.com> From: Justin Uberti Date: Fri, 17 Jul 2015 13:25:57 -0700 Message-ID: To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=047d7bd76778116050051b180001 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 20:26:20 -0000 --047d7bd76778116050051b180001 Content-Type: text/plain; charset=UTF-8 What you describe is the proper operation of RFC5245, so this isn't a Chrome implementation decision (Firefox behaves the same way, and I assume Edge will as well). However, we have been thinking about whether refinements to the behaviors specified in RFC5245 are warranted in the web context. On Fri, Jul 17, 2015 at 12:11 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > If I have understood the looong thread correctly, the issue is that > Chrome overrides the OS default route and sends the STUN requests via all > available interfaces, therefore leaking the IP addresses on the process. > > AFAIK, that behavior is a Chrome implementation decision (wrong in my > opinion, but understandable) and it is not specified on WebRTC, so while > acknowledging the importance of the issue, this is not something that we > should discuss in this mailing list, except if we decide that we should > decide to explicitly forbid this behavior and add it to the security draft. > > I will send a reply to discuss-webrtc to continue the discussion from a > Chrome point of view. > > Best regards > Sergio > > > On 17/07/2015 20:36, Justin Uberti wrote: > > The title is somewhat inaccurate, but > > https://code.google.com/p/chromium/issues/detail?id=457492 is the current > bug for this. > See also https://code.google.com/p/chromium/issues/detail?id=333752, from > which the above bug was spun out. > > On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler > wrote: > >> On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti >> wrote: >> > >> > This is already possible using non-WebRTC technologies, e.g. web >> sockets. As >> > such, I don't think that permission should be needed to create a data >> > channel, or receive (but not send) media. >> > >> >> The big difference is that Web Sockets starts off with an HTTP >> request, so it can be filtered by various plugins (PrivacyBadger, >> uBlock, Ghostery, etc.). WebRTC is invisible to those services since >> it does not have any HTTP requests at all. In fact, is WebRTC the only >> browser standard (i.e. not flash) that can fire off a DNS request >> that's not (at least at first) for an HTTP address[1]? Lacking an >> initial HTTP request makes it impossible for plugins to selectively >> filter these requests, so they have to fall back to an all-or-nothing >> config setting approach (which hurts WebRTC adoption in >> general)[2][3]. >> >> > That said, I agree that WebRTC should not allow drive-by harvesting of >> IP >> > addresses, and we intend to make changes to Chrome to prevent this. >> >> Great to hear! Thanks! Is there a bug that is tracking this? >> >> >> [1]: >> https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers >> [2]: https://github.com/EFForg/privacybadgerfirefox/issues/394 >> [3]: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3 >> >> Daniel >> > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bd76778116050051b180001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What you describe is the proper operation of RFC5245, so t= his isn't a Chrome implementation decision (Firefox behaves the same wa= y, and I assume Edge will as well).

However, we have bee= n thinking about whether refinements to the behaviors specified in RFC5245 = are warranted in the web context.

On Fri, Jul 17, 2015 at 12:11 PM, Sergio Garcia Murillo= <sergio.garcia.murillo@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =20 =20 =20
If I have understood the looong thread correctly, the issue is that Chrome overrides the OS default route and sends the STUN requests via all available interfaces, therefore leaking the IP addresses on the process.

AFAIK, that behavior is a Chrome implementation decision (wrong in my opinion, but understandable) and it is not specified on WebRTC, so while acknowledging the importance of the issue, this is not something that we should discuss in this mailing list, except if we decide that we should decide to explicitly forbid this behavior and add it to the security draft.

I will send a reply to discuss-webrtc to continue the discussion from a Chrome point of view.

Best regards
Sergio


On 17/07/2015 20:36, Justin Uberti wrote:
The title is somewhat inaccurate, but=C2=A0https://code.google.com/p/chromium/issues/deta= il?id=3D457492 is the current bug for this.=C2=A0
See also=C2=A0https://code.go= ogle.com/p/chromium/issues/detail?id=3D333752, from which the above bug was spun out.

On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler <diafygi@gmail.com> wrote:
On Fri, Jul 17, 2015 at 11:0= 4 AM, Justin Uberti <j= uberti@google.com> wrote:
>
> This is already possible using non-WebRTC technologies, e.g. web sockets. As
> such, I don't think that permission should be needed to create a data
> channel, or receive (but not send) media.
>

The big difference is that Web Sockets starts off with an HTTP
request, so it can be filtered by various plugins (PrivacyBadger,
uBlock, Ghostery, etc.). WebRTC is invisible to those services since
it does not have any HTTP requests at all. In fact, is WebRTC the only
browser standard (i.e. not flash) that can fire off a DNS request
that's not (at least at first) for an HTTP address[1]? Lacking an
initial HTTP request makes it impossible for plugins to selectively
filter these requests, so they have to fall back to an all-or-nothing
config setting approach (which hurts WebRTC adoption in
general)[2][3].

> That said, I agree that WebRTC should not allow drive-by harvesting of IP
> addresses, and we intend to make changes to Chrome to prevent this.

Great to hear! Thanks! Is there a bug that is tracking this?


[1]: https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS= _entries_as_persistent_identifiers
[2]: https://github.com/EFForg/= privacybadgerfirefox/issues/394
[3]: https://github.com/gorhill/uB= lock/releases/tag/0.9.9.3

Daniel



________________________________________=
_______
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


--047d7bd76778116050051b180001-- From nobody Fri Jul 17 13:36:50 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422301A1B5F for ; Fri, 17 Jul 2015 13:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrpv7qUMeOrp for ; Fri, 17 Jul 2015 13:36:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F251A1AC6 for ; Fri, 17 Jul 2015 13:36:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BC475BE55 for ; Fri, 17 Jul 2015 21:36:46 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iona3sInEQQ0 for ; Fri, 17 Jul 2015 21:36:45 +0100 (IST) Received: from [31.133.139.135] (unknown [31.133.139.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7AE87BE53 for ; Fri, 17 Jul 2015 21:36:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437165405; bh=uODYCnWVWimyFI1DFveV2jNCuSOOHTmKgBzS9YjykMU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=R+HcKOwDiyHuKM1esgRi9B63hqKxAZHhAMZle3dVwjRnar3N8+KrwqM6ceume6GCp 3I/5ZsOHFtRdfqbCCjoUXwEJU2rk3usxGuRzr/1i+CieVqOVVXf8d4LuADN8hAKHrL v//GmBg803/zJPC2T+spjlc0RMQ6leLOlYgh6YOM= Message-ID: <55A9675D.2070007@cs.tcd.ie> Date: Fri, 17 Jul 2015 21:36:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <55A95364.2070806@gmail.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 20:36:49 -0000 On a related point. I'm not sure it's very compelling but there is a passing reference in [1] to using WebRTC to discover local IP addresses as a way of assisting in an attack on rc4 - presumably the NAT'd source address offers some more known plaintext to an attacker that can presumably see the WPA encrypted packets and hence helps speed up the attack. See [1] p12 for the mention, though it lacks details. I guess the point is that folks will find unexpected ways to (ab)use such knowledge once it's available. The right reaction of course in this case is to not use rc4, but equally it perhaps provides another example of the unexpected consequences of exposing addresses. S. [1] http://www.rc4nomore.com/vanhoef-usenix2015.pdf From nobody Fri Jul 17 14:03:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26D21A3B9B for ; Fri, 17 Jul 2015 14:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq02oU5odajo for ; Fri, 17 Jul 2015 14:03:25 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B1B1A21A0 for ; Fri, 17 Jul 2015 14:03:25 -0700 (PDT) Received: by widic2 with SMTP id ic2so47805868wid.0 for ; Fri, 17 Jul 2015 14:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=dHwmIVAEUt2V89D1RceGIwfMIUKnPAQWAfg2P6a6rYQ=; b=A4iDb2oo/TmHuXV6JXjc+aAg6wOMGQuOS8gcUq4R6hXxGB+th8l3woVWwfWQ3mdR7Q 7zJORVLwqewMg2sKQUwxgWD2QgW7WhHNMYQzNR/M1JzR1n8ld8IxNoYztcUe/ySHdL2I iPj324XZ41bIZEZFvBwzHp/bZjuqGVH+aFTLLJnQLfN/eglj5DrWPPQ7pTh6Hh0XDlVz pW87uAOQ0J9+0pG1tcmSIfWVdQ/UWckHZFD1MWzj2n7LssNbeh0ZT8D2z9KV4ay7RQR0 kiT+5nftTu3rnVY3GVerCe0Ii202pvRwP31OzsNflgq23B5Djz2vRwLYrEacjz7GupZn I9GA== X-Received: by 10.180.23.66 with SMTP id k2mr509572wif.85.1437167003779; Fri, 17 Jul 2015 14:03:23 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by smtp.googlemail.com with ESMTPSA id ck7sm19863546wjc.43.2015.07.17.14.03.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2015 14:03:22 -0700 (PDT) To: Justin Uberti References: <55A95364.2070806@gmail.com> From: Sergio Garcia Murillo Message-ID: <55A96DA3.1040907@gmail.com> Date: Fri, 17 Jul 2015 23:03:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020600030101070606090505" Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 21:03:27 -0000 This is a multi-part message in MIME format. --------------020600030101070606090505 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Justin, Thanks for pointing that out, can you point me were in RFC5245 is that behavior described? I fail to find it. The only references I found about multihoming are about HOST candidates, performing connectivity checks and priorization of candidates, but I cannot find a reference on sending STUN request to the TURN/STUN server via all the available interfaces in order to retrieve the server reflexive candidates that is where the leak is originating. Please correct me again if I am wrong. Anyway, this raises another attack vector, as the IP may be leaked not directly via the ICE reflexive candidates, but via the connectivity checks. That is, the "malicious" server may just not get the IP via the server reflexive candidates, but doing an SDP O/A with remote ice candidates of a fake ICE server, that correlates the STUN connectivity checks with the web visit (via ice username for example). They don't even need a STUN/TURN server deployed. Best regards Sergio On 17/07/2015 22:25, Justin Uberti wrote: > What you describe is the proper operation of RFC5245, so this isn't a > Chrome implementation decision (Firefox behaves the same way, and I > assume Edge will as well). > > However, we have been thinking about whether refinements to the > behaviors specified in RFC5245 are warranted in the web context. > > On Fri, Jul 17, 2015 at 12:11 PM, Sergio Garcia Murillo > > wrote: > > If I have understood the looong thread correctly, the issue is > that Chrome overrides the OS default route and sends the STUN > requests via all available interfaces, therefore leaking the IP > addresses on the process. > > AFAIK, that behavior is a Chrome implementation decision (wrong in > my opinion, but understandable) and it is not specified on WebRTC, > so while acknowledging the importance of the issue, this is not > something that we should discuss in this mailing list, except if > we decide that we should decide to explicitly forbid this behavior > and add it to the security draft. > > I will send a reply to discuss-webrtc to continue the discussion > from a Chrome point of view. > > Best regards > Sergio > > > On 17/07/2015 20:36, Justin Uberti wrote: >> The title is somewhat inaccurate, but >> https://code.google.com/p/chromium/issues/detail?id=457492 is the >> current bug for this. >> See also >> https://code.google.com/p/chromium/issues/detail?id=333752, from >> which the above bug was spun out. >> >> On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler >> > wrote: >> >> On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti >> > wrote: >> > >> > This is already possible using non-WebRTC technologies, >> e.g. web sockets. As >> > such, I don't think that permission should be needed to >> create a data >> > channel, or receive (but not send) media. >> > >> >> The big difference is that Web Sockets starts off with an HTTP >> request, so it can be filtered by various plugins (PrivacyBadger, >> uBlock, Ghostery, etc.). WebRTC is invisible to those >> services since >> it does not have any HTTP requests at all. In fact, is WebRTC >> the only >> browser standard (i.e. not flash) that can fire off a DNS request >> that's not (at least at first) for an HTTP address[1]? Lacking an >> initial HTTP request makes it impossible for plugins to >> selectively >> filter these requests, so they have to fall back to an >> all-or-nothing >> config setting approach (which hurts WebRTC adoption in >> general)[2][3]. >> >> > That said, I agree that WebRTC should not allow drive-by >> harvesting of IP >> > addresses, and we intend to make changes to Chrome to >> prevent this. >> >> Great to hear! Thanks! Is there a bug that is tracking this? >> >> >> [1]: >> https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers >> [2]: https://github.com/EFForg/privacybadgerfirefox/issues/394 >> [3]: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3 >> >> Daniel >> >> >> >> >> _______________________________________________ >> 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 > > --------------020600030101070606090505 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Justin,

Thanks for pointing that out, can you point me were in RFC5245 is that behavior described? I fail to find it.

The only references I found about multihoming are about HOST candidates, performing connectivity checks and priorization of candidates, but I cannot find a reference on sending STUN request to the TURN/STUN server via all the available interfaces in order to retrieve the server reflexive candidates that is where the leak is originating. Please correct me again if I am wrong.

Anyway, this raises another attack vector, as the IP may be leaked not directly via the ICE reflexive candidates, but via the connectivity checks. That is, the "malicious" server may just not get the IP via the server reflexive candidates, but doing an SDP O/A with remote ice candidates of a fake ICE server, that correlates the STUN connectivity checks with the web visit (via ice username for example).  They don't even need a STUN/TURN server deployed.

Best regards
Sergio


On 17/07/2015 22:25, Justin Uberti wrote:
What you describe is the proper operation of RFC5245, so this isn't a Chrome implementation decision (Firefox behaves the same way, and I assume Edge will as well).

However, we have been thinking about whether refinements to the behaviors specified in RFC5245 are warranted in the web context.

On Fri, Jul 17, 2015 at 12:11 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
If I have understood the looong thread correctly, the issue is that Chrome overrides the OS default route and sends the STUN requests via all available interfaces, therefore leaking the IP addresses on the process.

AFAIK, that behavior is a Chrome implementation decision (wrong in my opinion, but understandable) and it is not specified on WebRTC, so while acknowledging the importance of the issue, this is not something that we should discuss in this mailing list, except if we decide that we should decide to explicitly forbid this behavior and add it to the security draft.

I will send a reply to discuss-webrtc to continue the discussion from a Chrome point of view.

Best regards
Sergio


On 17/07/2015 20:36, Justin Uberti wrote:
The title is somewhat inaccurate, but https://code.google.com/p/chromium/issues/detail?id=457492 is the current bug for this. 
See also https://code.google.com/p/chromium/issues/detail?id=333752, from which the above bug was spun out.

On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler <diafygi@gmail.com> wrote:
On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti <juberti@google.com> wrote:
>
> This is already possible using non-WebRTC technologies, e.g. web sockets. As
> such, I don't think that permission should be needed to create a data
> channel, or receive (but not send) media.
>

The big difference is that Web Sockets starts off with an HTTP
request, so it can be filtered by various plugins (PrivacyBadger,
uBlock, Ghostery, etc.). WebRTC is invisible to those services since
it does not have any HTTP requests at all. In fact, is WebRTC the only
browser standard (i.e. not flash) that can fire off a DNS request
that's not (at least at first) for an HTTP address[1]? Lacking an
initial HTTP request makes it impossible for plugins to selectively
filter these requests, so they have to fall back to an all-or-nothing
config setting approach (which hurts WebRTC adoption in
general)[2][3].

> That said, I agree that WebRTC should not allow drive-by harvesting of IP
> addresses, and we intend to make changes to Chrome to prevent this.

Great to hear! Thanks! Is there a bug that is tracking this?


[1]: https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers
[2]: https://github.com/EFForg/privacybadgerfirefox/issues/394
[3]: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3

Daniel



 
_______________________________________________
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



--------------020600030101070606090505-- From nobody Fri Jul 17 14:42:02 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798441A88C0 for ; Fri, 17 Jul 2015 14:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIEWbZK_SwFp for ; Fri, 17 Jul 2015 14:41:56 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738531A8954 for ; Fri, 17 Jul 2015 14:41:54 -0700 (PDT) Received: by iggf3 with SMTP id f3so46321059igg.1 for ; Fri, 17 Jul 2015 14:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fbb+2dUIDMjAU2ucLcEJ8LDcT+g7i5G925wRwtV7X7U=; b=cSOcuIxeD+OxvB4kAcYiZpiDlxvXkgvcf/RLz6v4F+AzIK6NMvmmKPyLnYoQUjHqOj JOZr/cTJH0KAPB5jbLtDz5sJRlp/YIGCgRL9ynuOQ2tnD88uvOq/FaBB9ltRa1QhgE1y t4oj1s9RnxagaRgoD8SGByFWjGKr1e91jxbLXLILI86sA8IloOddP1g6KU4/5t6EgOxU rZH5uupXLQQQyu+XKPS7eSrdV7XZgYHpzZmxv/tPggTN/07Jz8Pjc70tnRXimlc/eJDu jnwGWfQOJH+Jnf7HN+yaYbg0rg/d6h+jAjls22VCja/iW+vVd+KdwI6S61zW18dyBmrW o7Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fbb+2dUIDMjAU2ucLcEJ8LDcT+g7i5G925wRwtV7X7U=; b=ODnuFZinpdrKAJ/idTsrg4ao5z6FSzI5LZ/eVvDlVbOOr86DDdWzKVvhGXFv6iVE/p lPjzjGf9uhaylO9FlB0MvC/cpsK3t5BnFKEYfcqnLcW3Ul4vYjuu/39C7zgWYYRBqiCe ElPE9g1hzjbGoRUA2wZnRkIOnkdbVeHuTRj65v8fUVf1pXqoRoKxULln9XMxBhNvbMWW 0FJCIPbPQdzSJml+YDqIOqVzAxwbvdGojChUL6BdwDpJlmcKB4iI6YNktVH27qpgUqvA y0iwGdEcZNLvqJEnRukbcT/WsMBLjYCZL2iV/Xzno1ncl/IojzN4r3QTuzfuh0y2x9nT 0L5Q== X-Gm-Message-State: ALoCoQkqjg+R3QldRI8CYrsZvUow+gs4GvS81ZiFeKBaE/0oZ3OLLoLzwlsU+mOCxsGZesA3RTve X-Received: by 10.107.16.223 with SMTP id 92mr23786617ioq.14.1437169313846; Fri, 17 Jul 2015 14:41:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.233 with HTTP; Fri, 17 Jul 2015 14:41:34 -0700 (PDT) In-Reply-To: <55A96DA3.1040907@gmail.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> From: Justin Uberti Date: Fri, 17 Jul 2015 14:41:34 -0700 Message-ID: To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=001a113ec94e6f5133051b190e9c Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 21:41:58 -0000 --001a113ec94e6f5133051b190e9c Content-Type: text/plain; charset=UTF-8 On Fri, Jul 17, 2015 at 2:03 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi Justin, > > Thanks for pointing that out, can you point me were in RFC5245 is that > behavior described? I fail to find it. > > The only references I found about multihoming are about HOST candidates, > performing connectivity checks and priorization of candidates, but I cannot > find a reference on sending STUN request to the TURN/STUN server via all > the available interfaces in order to retrieve the server reflexive > candidates that is where the leak is originating. Please correct me again > if I am wrong. > Section 2.1, paragraphs 2 and 3 talks about getting all interfaces, and then getting STUN and TURN candidates from said interfaces. > > Anyway, this raises another attack vector, as the IP may be leaked not > directly via the ICE reflexive candidates, but via the connectivity checks. > That is, the "malicious" server may just not get the IP via the server > reflexive candidates, but doing an SDP O/A with remote ice candidates of a > fake ICE server, that correlates the STUN connectivity checks with the web > visit (via ice username for example). They don't even need a STUN/TURN > server deployed. > > Best regards > Sergio > > > On 17/07/2015 22:25, Justin Uberti wrote: > > What you describe is the proper operation of RFC5245, so this isn't a > Chrome implementation decision (Firefox behaves the same way, and I assume > Edge will as well). > > However, we have been thinking about whether refinements to the > behaviors specified in RFC5245 are warranted in the web context. > > On Fri, Jul 17, 2015 at 12:11 PM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> If I have understood the looong thread correctly, the issue is that >> Chrome overrides the OS default route and sends the STUN requests via all >> available interfaces, therefore leaking the IP addresses on the process. >> >> AFAIK, that behavior is a Chrome implementation decision (wrong in my >> opinion, but understandable) and it is not specified on WebRTC, so while >> acknowledging the importance of the issue, this is not something that we >> should discuss in this mailing list, except if we decide that we should >> decide to explicitly forbid this behavior and add it to the security draft. >> >> I will send a reply to discuss-webrtc to continue the discussion from a >> Chrome point of view. >> >> Best regards >> Sergio >> >> >> On 17/07/2015 20:36, Justin Uberti wrote: >> >> The title is somewhat inaccurate, but >> https://code.google.com/p/chromium/issues/detail?id=457492 is the >> current bug for this. >> See also https://code.google.com/p/chromium/issues/detail?id=333752, >> from which the above bug was spun out. >> >> On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler < >> diafygi@gmail.com> wrote: >> >>> On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti >>> wrote: >>> > >>> > This is already possible using non-WebRTC technologies, e.g. web >>> sockets. As >>> > such, I don't think that permission should be needed to create a data >>> > channel, or receive (but not send) media. >>> > >>> >>> The big difference is that Web Sockets starts off with an HTTP >>> request, so it can be filtered by various plugins (PrivacyBadger, >>> uBlock, Ghostery, etc.). WebRTC is invisible to those services since >>> it does not have any HTTP requests at all. In fact, is WebRTC the only >>> browser standard (i.e. not flash) that can fire off a DNS request >>> that's not (at least at first) for an HTTP address[1]? Lacking an >>> initial HTTP request makes it impossible for plugins to selectively >>> filter these requests, so they have to fall back to an all-or-nothing >>> config setting approach (which hurts WebRTC adoption in >>> general)[2][3]. >>> >>> > That said, I agree that WebRTC should not allow drive-by harvesting of >>> IP >>> > addresses, and we intend to make changes to Chrome to prevent this. >>> >>> Great to hear! Thanks! Is there a bug that is tracking this? >>> >>> >>> [1]: >>> https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers >>> [2]: https://github.com/EFForg/privacybadgerfirefox/issues/394 >>> [3]: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3 >>> >>> Daniel >>> >> >> >> >> _______________________________________________ >> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > --001a113ec94e6f5133051b190e9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 17, 2015 at 2:03 PM, Sergio Garcia Murillo <= sergio.garcia.murillo@gmail.com> wrote:
=20 =20 =20
Hi Justin,

Thanks for pointing that out, can you point me were in RFC5245 is that behavior described? I fail to find it.

The only references I found about multihoming are about HOST candidates, performing connectivity checks and priorization of candidates, but I cannot find a reference on sending STUN request to the TURN/STUN server via all the available interfaces in order to retrieve the server reflexive candidates that is where the leak is originating. Please correct me again if I am wrong.

Section 2.1, paragraphs 2 and 3 talks abo= ut getting all interfaces, and then getting STUN and TURN candidates from s= aid interfaces.

Anyway, this raises another attack vector, as the IP may be leaked not directly via the ICE reflexive candidates, but via the connectivity checks. That is, the "malicious" server may ju= st not get the IP via the server reflexive candidates, but doing an SDP O/A with remote ice candidates of a fake ICE server, that correlates the STUN connectivity checks with the web visit (via ice username for example).=C2=A0 They don't even need a STUN/TURN server deployed.

Best regards
Sergio


On 17/07/2015 22:25, Justin Uberti wrote:
What you describe is the proper ope= ration of RFC5245, so this isn't a Chrome implementation decision (Firefo= x behaves the same way, and I assume Edge will as well).

However, we have been thinking about w= hether refinements to the behaviors specified in RFC5245 are warranted in the web context.

On Fri, Jul 17, 201= 5 at 12:11 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gma= il.com> wrote:
If I have understood the looong thread correctly, the issue is that Chrome overrides the OS default route and sends the STUN requests via all available interfaces, therefore leaking the IP addresses on the process.

AFAIK, that behavior is a Chrome implementation decision (wrong in my opinion, but understandable) and it is not specified on WebRTC, so while acknowledging the importance of the issue, this is not something that we should discuss in this mailing list, except if we decide that we should decide to explicitly forbid this behavior and add it to the security draft.

I will send a reply to discuss-webrtc to continue the discussion from a Chrome point of view.

Best regards
Sergio


On 17/07/2015 20:36, Justin Uberti wrote:
The title is somewhat inaccurate, but=C2=A0https://code.google.com/p/ch= romium/issues/detail?id=3D457492 is the current bug for this.=C2=A0 <= span>
See also=C2=A0https://code.goo= gle.com/p/chromium/issues/detail?id=3D333752, from which the above bug was spun out.

On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler <diafygi@gmail.com> wrote:
On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti <juberti@google.com> wrote:
>
> This is already possible using non-WebRTC technologies, e.g. web sockets. As
> such, I don't think that permission should be needed to create a data
> channel, or receive (but not send) media.
>

The big difference is that Web Sockets starts off with an HTTP
request, so it can be filtered by various plugins (PrivacyBadger,
uBlock, Ghostery, etc.). WebRTC is invisible to those services since
it does not have any HTTP requests at all. In fact, is WebRTC the only
browser standard (i.e. not flash) that can fire off a DNS request
that's not (at least at first) for an HTTP address[1]? Lacking an
initial HTTP request makes it impossible for plugins to selectively
filter these requests, so they have to fall back to an all-or-nothing
config setting approach (which hurts WebRTC adoption in
general)[2][3].

> That said, I agree that WebRTC should not allow drive-by harvesting of IP
> addresses, and we intend to make changes to Chrome to prevent this.

Great to hear! Thanks! Is there a bug that is tracking this?


[1]: https://www.w3.org/wiki/Privacy/IPAddresses#Us= ing_wildcard_DNS_entries_as_persistent_identifiers
[2]: https://gi= thub.com/EFForg/privacybadgerfirefox/issues/394
[3]: https://githu= b.com/gorhill/uBlock/releases/tag/0.9.9.3

Daniel



 
_______________________________________________
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/rt= cweb




--001a113ec94e6f5133051b190e9c-- From nobody Fri Jul 17 15:47:38 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1E1A8767 for ; Fri, 17 Jul 2015 15:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzbDJ_VEu1MS for ; Fri, 17 Jul 2015 15:47:35 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9A01A8746 for ; Fri, 17 Jul 2015 15:47:34 -0700 (PDT) Received: by wgkl9 with SMTP id l9so91933329wgk.1 for ; Fri, 17 Jul 2015 15:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=O3CbSaTi3Eyl4zaV1f3PalfjjVqGmL17z7saNS9qJBs=; b=tm951jl9F3UtygYBj1PHowEoJNYgjDMOjMl+9L76BmiYanIkturO2NzpdOTaVdSwPv m8OyfZUNzCEuJaALgK7kfFdNN0zEkNrEkP7mr6gmXyiLm7XOkxvi9Ho0Fp5bDnq/IJQc FYthVmv74B585Qxebm6Abw4fSODxz431ND+K1FLCKsgiwGTIRcUe1O3Y1A/lOhzBKJP0 qJiJQdXIOHEHw3JFU8TJOdIjf6TYNrbfwjO/nuHLFVIPfoM4I+iIixloYU+UfOVtqMyN q70+2oebb1u4exxQmcPIHvfRO7k02ft7LCKseDRd943Z9x1BDAjWykRIVx261PLHcj1L b5kQ== X-Received: by 10.194.84.179 with SMTP id a19mr33068158wjz.29.1437173253695; Fri, 17 Jul 2015 15:47:33 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by smtp.googlemail.com with ESMTPSA id ez4sm10298448wid.14.2015.07.17.15.47.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2015 15:47:32 -0700 (PDT) To: Justin Uberti References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> From: Sergio Garcia Murillo Message-ID: <55A9860D.8030903@gmail.com> Date: Sat, 18 Jul 2015 00:47:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030600000006000400060407" Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 22:47:37 -0000 This is a multi-part message in MIME format. --------------030600000006000400060407 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 17/07/2015 23:41, Justin Uberti wrote: > > > On Fri, Jul 17, 2015 at 2:03 PM, Sergio Garcia Murillo > > wrote: > > Hi Justin, > > Thanks for pointing that out, can you point me were in RFC5245 is > that behavior described? I fail to find it. > > The only references I found about multihoming are about HOST > candidates, performing connectivity checks and priorization of > candidates, but I cannot find a reference on sending STUN request > to the TURN/STUN server via all the available interfaces in order > to retrieve the server reflexive candidates that is where the leak > is originating. Please correct me again if I am wrong. > > > Section 2.1, paragraphs 2 and 3 talks about getting all interfaces, > and then getting STUN and TURN candidates from said interfaces. > That was the ones I was looking at, but my understanding of them is different: If an agent is multihomed, it obtains a candidate from each IP address. Depending on the location of the PEER (the other agent in the session) on the IP network relative to the agent, the agent may be reachable by the peer through one or more of those IP addresses. Consider, for example, an agent that has a local IP address on a private net 10 network (I1), and a second connected to the public Internet (I2). A candidate from I1 will be directly reachable when communicating with a peer on the same private net 10 network, while a candidate from I2 will be directly reachable when communicating with a peer on the public Internet. Rather than trying to guess which IP address will work prior to sending an offer, the offering agent includes both candidates in its offer. Here, what I understand is that they are talking about Host ICE candidates, an then, yes, one per interface, no issue here (If my understanding of the leak problem is correct). Next, the agent uses STUN or TURN to obtain additional candidates. These come in two flavors: translated addresses on the public side of a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers (RELAYED CANDIDATES). When TURN servers are utilized, both types of candidates are obtained from the TURN server. If only STUN servers are utilized, only server reflexive candidates are obtained from them. The relationship of these candidates to the host candidate is shown in Figure 2. In this figure, both types of candidates are discovered using TURN. In the figure, the notation X:x means IP address X and UDP port x. In this one is talking about getting server reflexive and relay candidates, but in no way I see that the stun server should be contacted by all the interfaces or overriding default routing from OS. What am I missing? Best regards Sergio --------------030600000006000400060407 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 17/07/2015 23:41, Justin Uberti wrote:


On Fri, Jul 17, 2015 at 2:03 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Hi Justin,

Thanks for pointing that out, can you point me were in RFC5245 is that behavior described? I fail to find it.

The only references I found about multihoming are about HOST candidates, performing connectivity checks and priorization of candidates, but I cannot find a reference on sending STUN request to the TURN/STUN server via all the available interfaces in order to retrieve the server reflexive candidates that is where the leak is originating. Please correct me again if I am wrong.

Section 2.1, paragraphs 2 and 3 talks about getting all interfaces, and then getting STUN and TURN candidates from said interfaces.


That was the ones I was looking at, but my understanding of them is different:

   If an agent is multihomed, it obtains a candidate from each IP
   address.  Depending on the location of the PEER (the other agent in
   the session) on the IP network relative to the agent, the agent may
   be reachable by the peer through one or more of those IP addresses.
   Consider, for example, an agent that has a local IP address on a
   private net 10 network (I1), and a second connected to the public
   Internet (I2).  A candidate from I1 will be directly reachable when
   communicating with a peer on the same private net 10 network, while a
   candidate from I2 will be directly reachable when communicating with
   a peer on the public Internet.  Rather than trying to guess which IP
   address will work prior to sending an offer, the offering agent
   includes both candidates in its offer.

Here, what I understand is that they are talking about Host ICE candidates, an then, yes, one per interface, no issue here (If my understanding of the leak problem is correct).

   Next, the agent uses STUN or TURN to obtain additional candidates.
   These come in two flavors: translated addresses on the public side of
   a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers
   (RELAYED CANDIDATES).  When TURN servers are utilized, both types of
   candidates are obtained from the TURN server.  If only STUN servers
   are utilized, only server reflexive candidates are obtained from
   them.  The relationship of these candidates to the host candidate is
   shown in Figure 2.  In this figure, both types of candidates are
   discovered using TURN.  In the figure, the notation X:x means IP
   address X and UDP port x.

In this one is talking about getting server reflexive and relay candidates, but in no way I see that the stun server should be contacted by all the interfaces or overriding default routing from OS.

What am I missing?

Best regards
Sergio
--------------030600000006000400060407-- From nobody Fri Jul 17 16:10:20 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EF81A8BB1 for ; Fri, 17 Jul 2015 16:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx3sNpMEG3Oo for ; Fri, 17 Jul 2015 16:10:17 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500B91A8A0E for ; Fri, 17 Jul 2015 16:10:17 -0700 (PDT) Received: by ietj16 with SMTP id j16so86719074iet.0 for ; Fri, 17 Jul 2015 16:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eqLrDKgx2Nn8QmL9ZTnP80LQjASd7dt7fem7adrF1EE=; b=YXjPDnAK5rOSX5HMkLIeJDDuUhfIlJ4ko2BHZBmDYIjIBOI0SHPpgw9MmKaXxXKBo+ LPcY5tr4m1r/QncprB6UcgEyKhhYfOPjPBExXndGxQRljrPaLkuNB7Po+JKMIfsPfDn+ W+LBxN9yI7hHlu5LlJ3sRzmKuh2TPoJRWQALA0EkV/tPx/SU3y6Y9+MbuvsZH/W7eBHy bT3nfwm6RocXdiTFFrhy5Aeo1y+kUaJ5KpYWeLJlMtkumsYWLqZ+6rmRKhnZ22tzlS+R GPorMUMLreFk6I/jLCxOik7fVfjkkv9ahUlX+BmIe39bRQh4R9JfsEkzLfg2L0jQPpVJ dZ8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eqLrDKgx2Nn8QmL9ZTnP80LQjASd7dt7fem7adrF1EE=; b=Q04H96kkouPmKJPIUWlG5KtwBixzeKL7joVFv7gsc6+iT9kMdYXY+hm4yTaifdsMr5 jECx9b2yKxesDtiWDR++gBJagobB8G6MzmOZ4A19S5LsFTl+2mcEK5k4y7z1v9V+VqV0 m4ZLEpBpaBLEQxx+om8wIGDxHYwWD4bnleJPLqHrq7MiycpoJrlE+qepWafxN56oFobc IbRMRfNA135YFZmHPSW9HGlN1WDTRS7l9Zre5kMCquuy0dzA0ScPyclcBug1SvatgFgg c//bBVlxqEoLgwMKltHE6IStBz02tPQjz3DI34pP12P6DziL587OTc6IDjfD89cAk3WR YNAA== X-Gm-Message-State: ALoCoQkU3tiUY5Zplx2KTaJadNP3DHkOpzZENJ4DUhN0thSdmsiWu5bPY+ZRtd4xldnU34a1FT+x X-Received: by 10.50.102.7 with SMTP id fk7mr922363igb.49.1437174616655; Fri, 17 Jul 2015 16:10:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.233 with HTTP; Fri, 17 Jul 2015 16:09:56 -0700 (PDT) In-Reply-To: <55A9860D.8030903@gmail.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> From: Justin Uberti Date: Fri, 17 Jul 2015 16:09:56 -0700 Message-ID: To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=047d7b10c87181c0df051b1a4a2c Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 23:10:19 -0000 --047d7b10c87181c0df051b1a4a2c Content-Type: text/plain; charset=UTF-8 On Fri, Jul 17, 2015 at 3:47 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 17/07/2015 23:41, Justin Uberti wrote: > > > > On Fri, Jul 17, 2015 at 2:03 PM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> Hi Justin, >> >> Thanks for pointing that out, can you point me were in RFC5245 is that >> behavior described? I fail to find it. >> >> The only references I found about multihoming are about HOST candidates, >> performing connectivity checks and priorization of candidates, but I cannot >> find a reference on sending STUN request to the TURN/STUN server via all >> the available interfaces in order to retrieve the server reflexive >> candidates that is where the leak is originating. Please correct me again >> if I am wrong. >> > > Section 2.1, paragraphs 2 and 3 talks about getting all interfaces, and > then getting STUN and TURN candidates from said interfaces. > > > That was the ones I was looking at, but my understanding of them is > different: > > If an agent is multihomed, it obtains a candidate from each IP > address. Depending on the location of the PEER (the other agent in > the session) on the IP network relative to the agent, the agent may > be reachable by the peer through one or more of those IP addresses. > Consider, for example, an agent that has a local IP address on a > private net 10 network (I1), and a second connected to the public > Internet (I2). A candidate from I1 will be directly reachable when > communicating with a peer on the same private net 10 network, while a > candidate from I2 will be directly reachable when communicating with > a peer on the public Internet. Rather than trying to guess which IP > address will work prior to sending an offer, the offering agent > includes both candidates in its offer. > > Here, what I understand is that they are talking about Host ICE candidates, an then, yes, one per interface, no issue here (If my understanding of the leak problem is correct). > > Agreed. > Next, the agent uses STUN or TURN to obtain additional candidates. > These come in two flavors: translated addresses on the public side of > a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers > (RELAYED CANDIDATES). When TURN servers are utilized, both types of > candidates are obtained from the TURN server. If only STUN servers > are utilized, only server reflexive candidates are obtained from > them. The relationship of these candidates to the host candidate is > shown in Figure 2. In this figure, both types of candidates are > discovered using TURN. In the figure, the notation X:x means IP > address X and UDP port x. > > In this one is talking about getting server reflexive and relay candidates, but in no way I see that the stun server should be contacted by all the interfaces or overriding default routing from OS. > > It is pretty clear from the diagram on page 10 that for each host candidate X:x, the agent will gather a srflx candidate X1':x1' and relay candidate Y:y. This is also spelled out in the text underneath the diagram: When the agent sends the TURN Allocate request from IP address and port X:x, the NAT (assuming there is one) will create a binding X1':x1', mapping this server reflexive candidate to the host candidate X:x. Ergo, one tries to gather srflx and relay candidates for each host candidate X:x. --047d7b10c87181c0df051b1a4a2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 17, 2015 at 3:47 PM, Sergio Garcia Murillo <= sergio.garcia.murillo@gmail.com> wrote:
=20 =20 =20
On 17/07/2015 23:41, Justin Uberti wrote:


On Fri, Jul 17, 2015 at 2:03 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail= .com> wrote:
Hi Justin,

Thanks for pointing that out, can you point me were in RFC5245 is that behavior described? I fail to find it.

The only references I found about multihoming are about HOST candidates, performing connectivity checks and priorization of candidates, but I cannot find a reference on sending STUN request to the TURN/STUN server via all the available interfaces in order to retrieve the server reflexive candidates that is where the leak is originating. Please correct me again if I am wrong.

Section 2.1, paragraphs 2 and 3 talks about getting all interfaces, and then getting STUN and TURN candidates from said interfaces.


 That was the ones I was looking at, but my understanding of them is different:

   If an agent is multihomed, it obtains a =
candidate from each IP
   address.  Depending on the location of the PEER (the other agent in
   the session) on the IP network relative to the agent, the agent may
   be reachable by the peer through one or more of those IP addresses.
   Consider, for example, an agent that has a local IP address on a
   private net 10 network (I1), and a second connected to the public
   Internet (I2).  A candidate from I1 will be directly reachable when
   communicating with a peer on the same private net 10 network, while a
   candidate from I2 will be directly reachable when communicating with
   a peer on the public Internet.  Rather than trying to guess which IP
   address will work prior to sending an offer, the offering agent
   includes both candidates in its offer.

Here, what I understand is that they are talking about Host ICE candidates,=
 an then, yes, one per interface, no issue here (If my understanding of the=
 leak problem is correct).

Agre= ed.
   Next, the agent uses STUN or TURN to obtain additio=
nal candidates.
   These come in two flavors: translated addresses on the public side of
   a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers
   (RELAYED CANDIDATES).  When TURN servers are utilized, both types of
   candidates are obtained from the TURN server.  If only STUN servers
   are utilized, only server reflexive candidates are obtained from
   them.  The relationship of these candidates to the host candidate is
   shown in Figure 2.  In this figure, both types of candidates are
   discovered using TURN.  In the figure, the notation X:x means IP
   address X and UDP port x.

In this one is talking about getting server reflexive and relay candidates,=
 but in no way I see that the stun server should be contacted by all the in=
terfaces or overriding default routing from OS.

It is pretty clear from the diagram on page 10 that for ea= ch host candidate X:x, the agent will gather a srflx candidate X1':x1&#= 39; and relay candidate Y:y. This is also spelled out in the text underneat= h the diagram:

=C2=A0 =C2=A0When the agent se= nds the TURN Allocate request from IP address and
=C2=A0 =C2=A0po= rt X:x, the NAT (assuming there is one) will create a binding
=C2= =A0 =C2=A0X1':x1', mapping this server reflexive candidate to the h= ost
=C2=A0 =C2=A0candidate X:x.=C2=A0

<= div>Ergo, one tries to gather srflx and relay candidates for each host cand= idate X:x.
--047d7b10c87181c0df051b1a4a2c-- From nobody Fri Jul 17 16:35:17 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7011A92DD for ; Fri, 17 Jul 2015 16:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_KO2DTiOugN for ; Fri, 17 Jul 2015 16:35:13 -0700 (PDT) Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F861A8A65 for ; Fri, 17 Jul 2015 16:35:12 -0700 (PDT) Received: by ykay190 with SMTP id y190so101558031yka.3 for ; Fri, 17 Jul 2015 16:35:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=7y6MIOB9m7CJX5j7NFtEVvYGXVclacBBC7mGK8ap75g=; b=hXr9oB5U4Roci+aCBYVr2WV1gOp6g6SqHlJTC5ZDc9IviaSr6aADwKDgNF2YocsTwP 2FqW/1ArfkC1r4z2DjI7F+qncHCfEq3oRWYO1CjSwNzNf8rxfpsLnB/znp6JAe3O7CG5 EvHsB+XeWtdYsXIfxQbo+x7ts+w4YGJieZ3QUUFPZ5ooxzsjpsBF4Hb+lt6fRqauqARG VDGeMdX8qZZExL6E52MOPNyOXCz8LHFGVRgEp+MHfGkTIpJzwmPD9+gEFT3zC50VQy7y 1jPK1KYvblUFhMYIs+atnpv3I7ZL94XiSkRJqpSEK12ORyG2kVHtMPfMiasrj4+VXc5m mwDg== X-Gm-Message-State: ALoCoQl7co8JOl/M0pyl8GNVuhokuGUApRVw9rhERYfAZyN5BrY8JIJqskFiAEL5LbQ7v4UEQNhn X-Received: by 10.13.255.2 with SMTP id p2mr843939ywf.149.1437176112257; Fri, 17 Jul 2015 16:35:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Fri, 17 Jul 2015 16:34:52 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 18 Jul 2015 01:34:52 +0200 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 23:35:15 -0000 2015-07-18 1:09 GMT+02:00 Justin Uberti : > It is pretty clear from the diagram on page 10 that for each host candida= te > X:x, the agent will gather a srflx candidate X1':x1' and relay candidate > Y:y. This is also spelled out in the text underneath the diagram: > > When the agent sends the TURN Allocate request from IP address and > port X:x, the NAT (assuming there is one) will create a binding > X1':x1', mapping this server reflexive candidate to the host > candidate X:x. > > Ergo, one tries to gather srflx and relay candidates for each host candid= ate > X:x. That's not what I understand. What I understand is that the browser should bind on 0.0.0.0 (or ::0) and send the STUN/TURN request, and the underlying OS would decide the proper interface and source IP. So probably just one or two (IPv4 and IPv6) STUN/TURN attempts would be performed during the gathering, and when *that* happens the quoted text above applies (being X the IP of the candidate matching the source IP chosen by the OS to route the STUN/TURN request). Said that, and omitting the above confusing text: what is the purpose of sending STUN/TURN requests over all the interfaces? How is that good at all? AFAIK in most cases that will just mean timeouts waiting for STUN responses (which is bad if trickle ICE is not being used). To be even more clear: STUN/TURN servers are typically in the public Internet, although they may also be placed in local networks. Anyhow, computers within that network have a single and already configured route to reach the STUN/TURN server (usually the default route). Sending STUN/TURN requests from other interfaces will just fail. --=20 I=C3=B1aki Baz Castillo From nobody Fri Jul 17 16:35:31 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2591A92E1 for ; Fri, 17 Jul 2015 16:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id go7VM5MoeJM8 for ; Fri, 17 Jul 2015 16:35:29 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D5D1A92DD for ; Fri, 17 Jul 2015 16:35:29 -0700 (PDT) Received: by wgav7 with SMTP id v7so26937980wga.2 for ; Fri, 17 Jul 2015 16:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=qITXIYei9XgHhUG7FUCLDADz0MqYeRnKdFXaGFEZPI8=; b=lvXjFByYzCeEgLtqPilSlbcrgX6pdzglbI9bqkikFAKlqdOiPZXVyPZvY7ELMaHq+h kj+MYHKkwjWEWnqoBHsMjy9XoIThdoVCzL92BEEtip3dL9JEEM8ePr1qVjI7+Z63F2O9 HhV2kZYvTa1whp5hy1rcLLjDgy9AfnX/EbiBa8X1+PitPFeTwRuuPeDF5lhlYGtvoF18 fOqVBQgFSgHeyqk/qLGIwUgn0L0G96agcg6RmDRkArYaeA9CFBoPRmyM52j1onpozVS6 EmGTgyKCQBTEulSyu7Y7pG7uvhTKa8mQ2Xb9L0Uv7IOYM26CsJOTkBY7+5lGizt3og6E YP9Q== X-Received: by 10.180.99.71 with SMTP id eo7mr1260141wib.95.1437176128291; Fri, 17 Jul 2015 16:35:28 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by smtp.googlemail.com with ESMTPSA id jy6sm20309771wjc.4.2015.07.17.16.35.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2015 16:35:27 -0700 (PDT) To: Justin Uberti References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> From: Sergio Garcia Murillo Message-ID: <55A99148.1040105@gmail.com> Date: Sat, 18 Jul 2015 01:35:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 23:35:30 -0000 On 18/07/2015 1:09, Justin Uberti wrote: > Next, the agent uses STUN or TURN to obtain additional candidates. > These come in two flavors: translated addresses on the public side of > a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers > (RELAYED CANDIDATES). When TURN servers are utilized, both types of > candidates are obtained from the TURN server. If only STUN servers > are utilized, only server reflexive candidates are obtained from > them. The relationship of these candidates to the host candidate is > shown in Figure 2. In this figure, both types of candidates are > discovered using TURN. In the figure, the notation X:x means IP > address X and UDP port x. > > In this one is talking about getting server reflexive and relay candidates, but in no way I see that the stun server should be contacted by all the interfaces or overriding default routing from OS. > > It is pretty clear from the diagram on page 10 that for each host > candidate X:x, the agent will gather a srflx candidate X1':x1' and > relay candidate Y:y. This is also spelled out in the text underneath > the diagram: > > When the agent sends the TURN Allocate request from IP address and > port X:x, the NAT (assuming there is one) will create a binding > X1':x1', mapping this server reflexive candidate to the host > candidate X:x. > > Ergo, one tries to gather srflx and relay candidates for each host > candidate X:x. Agree, for each HOST candidate, it should send a STUN request to the turn server from that IP:port. But shouldn't the VPN configuration prevent the non-VPN-host-candidate STUN request to be sent via the non-VPN-interface? (i.e. applying default route based on dest?) Best regards Sergio From nobody Fri Jul 17 16:41:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F891A92F2 for ; Fri, 17 Jul 2015 16:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZd9fyP0RomD for ; Fri, 17 Jul 2015 16:41:30 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22031A92F1 for ; Fri, 17 Jul 2015 16:41:29 -0700 (PDT) Received: by ykay190 with SMTP id y190so101631195yka.3 for ; Fri, 17 Jul 2015 16:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r715+MjkDogLj5PGXE+hHEK8gKA0c6mKgbUmE5o/TOw=; b=BAVTWg1NOxwK9/Yka/DaMrFOszfmM9C8v2f0QvDiaKvHqvi/Lct2R2piTrJfhY3QIl h+mTaKLcPhLV+hfLS8SF06qP88rmKgqIMx/hDWb9gXiCf7frKFqmzAdWHh//KQrMbklc g6VOROQLDHwz0kE+GNgdacU/LDCPF/6jAznSKL8wfUJRExZPsYT7icfzMaaIszP3k3l0 C7Fp8+tc/uYnsU3jbKJEDojley3ioYAISOHsbSbU6UclsGYsYGL1LOIOaDvOwqJkyatG Ti4mWtS73bvnetLdqq+bU8iqwRhuxRAk/+NlVs3ycm3SRN89NhzPzv/QPZG3ggEkdGPG 0iqw== MIME-Version: 1.0 X-Received: by 10.129.103.84 with SMTP id b81mr17711767ywc.55.1437176489289; Fri, 17 Jul 2015 16:41:29 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 17 Jul 2015 16:41:29 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 17 Jul 2015 16:41:29 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> Date: Fri, 17 Jul 2015 16:41:29 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11490eb81fac35051b1aba31 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 23:41:31 -0000 --001a11490eb81fac35051b1aba31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jul 17, 2015 4:35 PM, "I=C3=B1aki Baz Castillo" wrote: > What I understand is that the browser should bind on 0.0.0.0 (or ::0) > and send the STUN/TURN request, That works most of the time, but it is a cheat. What Chrome and Firefox do - bind to reach local interface separately - is the only reliable way to do this. If you bind to 0.0.0.0, you can't handle multiple interfaces correctly, and that reduces the odds of completing ICE with the best result= . --001a11490eb81fac35051b1aba31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 17, 2015 4:35 PM, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote:
> What I understand is that the browser should bind on 0.0.0.0 (or ::0)<= br> > and send the STUN/TURN request,

That works most of the time, but it is a cheat. What Chrome = and Firefox do - bind to reach local interface separately - is the only rel= iable way to do this. If you bind to 0.0.0.0, you can't handle multiple= interfaces correctly, and that reduces the odds of completing ICE with the= best result.

--001a11490eb81fac35051b1aba31-- From nobody Fri Jul 17 16:48:10 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846951A92FD for ; Fri, 17 Jul 2015 16:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy7bM11VYRpd for ; Fri, 17 Jul 2015 16:48:07 -0700 (PDT) Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com [209.85.160.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8281A9054 for ; Fri, 17 Jul 2015 16:48:07 -0700 (PDT) Received: by ykay190 with SMTP id y190so101708443yka.3 for ; Fri, 17 Jul 2015 16:48:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=61TltcxzRdbxw67qYzd67hSImJIzP0KLAuzWdCeTwsM=; b=cojq+wjHW/S0wasu+FsIy9WY7su2jXGGNgDdOt+JwRzJfBMZgLhUXfTKlKu1sa9QAO T4txBOvcNpAHJxvPWsQb0BwJgkC2zU/60J3oqyAs07Zq2lSQBQ2d7CSrOTCMGWc3Q+kw PLIBm9BiXMa5mdCH++GMsdquuiyuqOUR0rjSL8YS+c6ibauINiCp4eQfL0AJGIS+DKmv gV8y2B9sXwn3/j/odg955GL9Wzi2eTKsl3YgQMmHYCpEOeyje3KWc/u9qFBFsoYJX7Or OER1VTj8Vom/JjbPXlwQZULMjYoXuZYlj8IUsetbqfaR9Np5SUeT6ULa8jZAi1Iw8JoK VOAQ== X-Gm-Message-State: ALoCoQmDWIoZskfYPbFB6ByzgJpiO4HLW9RWOKYJSdw3Ngzcw6Dp3iGBB5rwvmzUpbr/zBKg3qIG X-Received: by 10.13.255.2 with SMTP id p2mr876008ywf.149.1437176887118; Fri, 17 Jul 2015 16:48:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Fri, 17 Jul 2015 16:47:47 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 18 Jul 2015 01:47:47 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 23:48:08 -0000 2015-07-18 1:41 GMT+02:00 Martin Thomson : > > On Jul 17, 2015 4:35 PM, "I=C3=B1aki Baz Castillo" wrote: >> What I understand is that the browser should bind on 0.0.0.0 (or ::0) >> and send the STUN/TURN request, > > That works most of the time, but it is a cheat. What Chrome and Firefox d= o - > bind to reach local interface separately - is the only reliable way to do > this. If you bind to 0.0.0.0, you can't handle multiple interfaces > correctly, and that reduces the odds of completing ICE with the best resu= lt. If you bind to 0.0.0.0 the OS will find out the proper interface to send the STUN/TURN request. The browser should then check the chosen source IP to match the associated local candidate. > If you bind to 0.0.0.0, you can't handle multiple interfaces > correctly, and that reduces the odds of completing ICE with the best resu= lt. Any real usecase in which that could be true? Why should the app override the OS routing table? --=20 I=C3=B1aki Baz Castillo From nobody Fri Jul 17 16:57:01 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBC31A9302 for ; Fri, 17 Jul 2015 16:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLbIrmoGQGQb for ; Fri, 17 Jul 2015 16:56:58 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C431A92F3 for ; Fri, 17 Jul 2015 16:56:58 -0700 (PDT) Received: by ykay190 with SMTP id y190so101809022yka.3 for ; Fri, 17 Jul 2015 16:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=veaYFOWBnu9odDU6y8HApMnK7F9eKR3PLjtYkX1N054=; b=K27St7/qQ3Qlkon/BMuwPud6nPfluhdkJxd+H3FYqOf7rI+DsMt2PTCYprAiROYIu8 hGdEiTOnC7E5RRwEQNHLKrpMZR44i9ptlDsGOskTUdrqHSsLqT7fR4VzoO3Y/2y3k5Cn y2dBasr69Fy7zKN2HF8fujBgfnNbNVdFwRQvhrKgI0kxTivbS5K8HpblO0gm0rMqUH0X wi2RsuhS00YgYV41G4CZB4VNWiluTGOPpToBA6tPI1MzLK4yusZ2rMIVAnTA+lNoDpZN mVqRSaBZmf1zhH1Jdz6aoQd6Zx1G3SxKmRmt6w7I6SI0LM/2MjFrPwRCO7J2o8TsI4Gk TLRA== MIME-Version: 1.0 X-Received: by 10.129.103.84 with SMTP id b81mr17750906ywc.55.1437177418042; Fri, 17 Jul 2015 16:56:58 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 17 Jul 2015 16:56:57 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 17 Jul 2015 16:56:57 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> Date: Fri, 17 Jul 2015 16:56:57 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11490eb87b5473051b1af16f Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 23:56:59 -0000 --001a11490eb87b5473051b1af16f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jul 17, 2015 4:48 PM, "I=C3=B1aki Baz Castillo" wrote: > If you bind to 0.0.0.0 the OS will find out the proper interface to > send the STUN/TURN request. No, that's the point, you need control too get this right. > The browser should then check the chosen > source IP to match the associated local candidate. That doesn't always work either. The source address of the packet you send isn't always reported correctly (not does it necessarily go out the interface you choose, but that is another problem). > > If you bind to 0.0.0.0, you can't handle multiple interfaces > > correctly, and that reduces the odds of completing ICE with the best result. > > Any real usecase in which that could be true? Why should the app > override the OS routing table? Which use case? ICE --001a11490eb87b5473051b1af16f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 17, 2015 4:48 PM, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote:
> If you bind to 0.0.0.0 the OS will find out the proper interface to > send the STUN/TURN request.

No, that's the point, you need control too get this righ= t.

> The browser should then check the chosen
> source IP to match the associated local candidate.

That doesn't always work either. The source address of t= he packet you send isn't always reported correctly (not does it necessa= rily go out the interface you choose, but that is another problem).

> >=C2=A0 If you bind to 0.0.0.0, you can't handle= multiple interfaces
> > correctly, and that reduces the odds of completing ICE with the b= est result.
>
> Any real usecase in which that could be true? Why should the app
> override the OS routing table?

Which use case? ICE

--001a11490eb87b5473051b1af16f-- From nobody Fri Jul 17 17:01:11 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4671A00C1 for ; Fri, 17 Jul 2015 17:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co1W2vfKUu6t for ; Fri, 17 Jul 2015 17:01:05 -0700 (PDT) Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B4D1A00E1 for ; Fri, 17 Jul 2015 17:01:05 -0700 (PDT) Received: by ykay190 with SMTP id y190so101858663yka.3 for ; Fri, 17 Jul 2015 17:01:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=6T1Cu4D2wzX3ZeBsbUE8ZcfvgBTioEZex14bFTlp4nE=; b=KSdQhv8w7Mzlj/yIMbSwLZlzdI3NrvB+jSYPxxMy7gJCXdvfJVXOVc7wzD8HEYIdJ0 1sDeX3EDQWEy+j3SvJCA8BRHO4KZQeNJq6HUh8uE8uZOl+TrXgHtmlYS90XpC6D5ytjZ gjKeFmNN4TKQhHC+ECnb3prVRFCJuXGgfQqGw7jT9aoJjUVff5x7GaKl89MCxCjm4fjw /eUYKYLcd0+TLXC/0Zbdl12wJ4BmwpGXAzavMGdD3ZiVd3TeB+n7qnA9f3Q7974F4djM JF1Tsd1A09jxCWc2rA6hwP6yvYRibeOQSJkPzFMaRWhLvjMNqfvR74/+/7HfejhxzSXQ r4qw== X-Gm-Message-State: ALoCoQkfipu6+emtmGrv0TyQZmU9rXNbN85z2gJnGSGL0qpIzjs7T3uzHff5QbNQhmlA0slRJ2I5 X-Received: by 10.129.79.4 with SMTP id d4mr18033763ywb.15.1437177665144; Fri, 17 Jul 2015 17:01:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Fri, 17 Jul 2015 17:00:45 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 18 Jul 2015 02:00:45 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 00:01:06 -0000 2015-07-18 1:56 GMT+02:00 Martin Thomson : >> The browser should then check the chosen >> source IP to match the associated local candidate. > > That doesn't always work either. The source address of the packet you sen= d > isn't always reported correctly (not does it necessarily go out the > interface you choose, but that is another problem). The point is that you don't even choose the interface. The OS will do for y= ou. >> > If you bind to 0.0.0.0, you can't handle multiple interfaces >> > correctly, and that reduces the odds of completing ICE with the best >> > result. >> >> Any real usecase in which that could be true? Why should the app >> override the OS routing table? > > Which use case? ICE I understand we are here discussing how ICE is supposed to work. What I wonder is: in which case it is useful to send packets to the STUN/TURN server on all the interfaces instead on relying on the interface the OS would choose to reach that server? --=20 I=C3=B1aki Baz Castillo From nobody Fri Jul 17 17:20:02 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E471A0BE8 for ; Fri, 17 Jul 2015 17:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrPAZdi06DHG for ; Fri, 17 Jul 2015 17:19:58 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFAF21A0AC8 for ; Fri, 17 Jul 2015 17:19:58 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so87013104ieb.1 for ; Fri, 17 Jul 2015 17:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WEaWtq8Yr4zrYFuHAbAlidR7y3W0MTqwOWKsuu3b1So=; b=IZA+mEdZVALQqa19QhHqbOy05pSkXecIV+RycWp/cnxBzCp1QHwm2OYS4oMbQ3ULdo joOGdOdK+fyyNpSjlomkv4eECc2odSRshyYwCaU3KqNfu12EosfVkYyH8WRekvvVi9PN HLPZWDUHyL6hxX2oSKtEONYriz0hfc1nliMa5OagX8th60r/kPYAfS6T7b71X5Uec7gc EdCoEQZ5w2Ire32ekp+qS9TYjcaKjgMXgCBhcWRo70SIYMA/TrqfWiLJ+quc+Rrrynkr gKwxUlFx/W5QUgRwPXmkecWzHxjDfRnqbNd3+fY6yih9TahFAgR6OEtR2+eW6vrJIBMg gVxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WEaWtq8Yr4zrYFuHAbAlidR7y3W0MTqwOWKsuu3b1So=; b=RIhCAU7yOXx5sAqEvOVly67UKe45Ik324S0ZXsfiRPa3nDfpcIbrbcyRJRIsq7aPI2 ZPdQoqx4Hp6OEwcRsg6w3oKnFD8vlhDaUjCkbGKbORoIZUcOq9Y7/HS/DsWuhIy3G5FI MaX59Usj8XjwigqPKqmPRpfN1ARba2Ol09Qoo3SSRGWCfHQrLiFcp/QLryffdqFgMGTX K3ssicz+/rxyuPxPWWy3z+2tro4esZFRmJxRj19Dr4RyGHhXDuTCFFK9CcX/YH1RtJot WGsiJUkn92MOjdHBSzxMyPdrQpgENMVhTeQE9F8ZeUcI7yYbbC+5ZILDNPvRhm9OJ7LN JcdQ== X-Gm-Message-State: ALoCoQnmBSLPKyqQNAb6yZqNwLS+lFz3uERq4tWv6dntB5TuuajwYKDY/uUwLFzgth8RPIzPlZWW X-Received: by 10.50.7.104 with SMTP id i8mr193729iga.50.1437178798065; Fri, 17 Jul 2015 17:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.233 with HTTP; Fri, 17 Jul 2015 17:19:38 -0700 (PDT) In-Reply-To: <55A99148.1040105@gmail.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <55A99148.1040105@gmail.com> From: Justin Uberti Date: Fri, 17 Jul 2015 17:19:38 -0700 Message-ID: To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=089e01183ebcbcf6d0051b1b431a Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 00:20:00 -0000 --089e01183ebcbcf6d0051b1b431a Content-Type: text/plain; charset=UTF-8 On Fri, Jul 17, 2015 at 4:35 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 18/07/2015 1:09, Justin Uberti wrote: > >> Next, the agent uses STUN or TURN to obtain additional candidates. >> These come in two flavors: translated addresses on the public side of >> a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers >> (RELAYED CANDIDATES). When TURN servers are utilized, both types of >> candidates are obtained from the TURN server. If only STUN servers >> are utilized, only server reflexive candidates are obtained from >> them. The relationship of these candidates to the host candidate is >> shown in Figure 2. In this figure, both types of candidates are >> discovered using TURN. In the figure, the notation X:x means IP >> address X and UDP port x. >> >> In this one is talking about getting server reflexive and relay >> candidates, but in no way I see that the stun server should be contacted by >> all the interfaces or overriding default routing from OS. >> >> It is pretty clear from the diagram on page 10 that for each host >> candidate X:x, the agent will gather a srflx candidate X1':x1' and relay >> candidate Y:y. This is also spelled out in the text underneath the diagram: >> >> When the agent sends the TURN Allocate request from IP address and >> port X:x, the NAT (assuming there is one) will create a binding >> X1':x1', mapping this server reflexive candidate to the host >> candidate X:x. >> >> Ergo, one tries to gather srflx and relay candidates for each host >> candidate X:x. >> > > Agree, for each HOST candidate, it should send a STUN request to the turn > server from that IP:port. But shouldn't the VPN configuration prevent the > non-VPN-host-candidate STUN request to be sent via the non-VPN-interface? > (i.e. applying default route based on dest?) > Replying to Sergio: Typically with a VPN, the non-VPN interface is locked down so it only has a single route: to the VPN server. However, split tunnel VPNs allow the non-VPN interface to route to other addresses (possibly, for performance reasons), so in this case, the non-VPN-host-candidate STUN request will be sent successfully from the non-VPN interface. Sometimes this will be desirable: imagine someone working from home who wants to connect to their corp VPN, but wants to have their video conferencing traffic not go through the VPN. Sometimes this will not be desirable, i.e. when the VPN is being used for privacy. This makes picking a perfect default setting difficult, although we have some ideas that we are exploring. --089e01183ebcbcf6d0051b1b431a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 17, 2015 at 4:35 PM, Sergio Garcia Murillo <= sergio.garcia.murillo@gmail.com> wrote:
On 18/07/2015 1:09, Justin Uberti wrote:
=C2=A0 =C2=A0 Next, the agent uses STUN or TURN to obtain additional candid= ates.
=C2=A0 =C2=A0 These come in two flavors: translated addresses on the public= side of
=C2=A0 =C2=A0 a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN ser= vers
=C2=A0 =C2=A0 (RELAYED CANDIDATES).=C2=A0 When TURN servers are utilized, b= oth types of
=C2=A0 =C2=A0 candidates are obtained from the TURN server.=C2=A0 If only S= TUN servers
=C2=A0 =C2=A0 are utilized, only server reflexive candidates are obtained f= rom
=C2=A0 =C2=A0 them.=C2=A0 The relationship of these candidates to the host = candidate is
=C2=A0 =C2=A0 shown in Figure 2.=C2=A0 In this figure, both types of candid= ates are
=C2=A0 =C2=A0 discovered using TURN.=C2=A0 In the figure, the notation X:x = means IP
=C2=A0 =C2=A0 address X and UDP port x.

In this one is talking about getting server reflexive and relay candidates,= but in no way I see that the stun server should be contacted by all the in= terfaces or overriding default routing from OS.

It is pretty clear from the diagram on page 10 that for each host candidate= X:x, the agent will gather a srflx candidate X1':x1' and relay can= didate Y:y. This is also spelled out in the text underneath the diagram:
=C2=A0 =C2=A0When the agent sends the TURN Allocate request from IP address= and
=C2=A0 =C2=A0port X:x, the NAT (assuming there is one) will create a bindin= g
=C2=A0 =C2=A0X1':x1', mapping this server reflexive candidate to th= e host
=C2=A0 =C2=A0candidate X:x.

Ergo, one tries to gather srflx and relay candidates for each host candidat= e X:x.

 Agree, for each HOST candidate, it should send a STUN request to the turn s= erver from that IP:port. But shouldn't the VPN configuration prevent th= e non-VPN-host-candidate STUN request to be sent via the non-VPN-interface?= (i.e. applying default route based on dest?)

Replying to Sergio:

Typically with a VPN, t= he non-VPN interface is locked down so it only has a single route: to the V= PN server. However, split tunnel VPNs allow the non-VPN interface to route = to other addresses (possibly, for performance reasons), so in this case, th= e non-VPN-host-candidate STUN request will be sent successfully from the no= n-VPN interface.

Sometimes this will be desirable:= imagine someone working from home who wants to connect to their corp VPN, = but wants to have their video conferencing traffic not go through the VPN. = Sometimes this will not be desirable, i.e. when the VPN is being used for p= rivacy. This makes picking a perfect default setting difficult, although we= have some ideas that we are exploring.
--089e01183ebcbcf6d0051b1b431a-- From nobody Fri Jul 17 18:31:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220691A0461 for ; Fri, 17 Jul 2015 18:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH5YAnADMjGD for ; Fri, 17 Jul 2015 18:31:30 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 488C51A0187 for ; Fri, 17 Jul 2015 18:31:30 -0700 (PDT) Received: by ykfw194 with SMTP id w194so22677816ykf.0 for ; Fri, 17 Jul 2015 18:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q+QqM0wst7m4oYmnapD9A/HPkZ+3zOtjLWfeKtdneiI=; b=W8Vb58ycLaNT445aW6eFnxifBnCAoMhdzi/ivVdwMZhW/ZqwkaMYYiCJb2l0WyxqvR eFatPls5ET9tpETXBXc2y8umlmBfo/inr6ERw6bZ+/RcoayqI+yFZf4KBQnG88aXzoLm pAEsq4s7IhkrKCbo92f9rwVZ8YFRxLsP+mVJj9OaRpX7ClyvQDs0d0/iEhoiW6OZu/vB Vag1FrUpyjfDGOKqYFCJTAjztqqLaIiDMY3waeETZJGZge669XpPLAUJAivqPcTMG/Ha aE6zXIU+uQtPE6jkJe++5jupMglu9hVWq3DJE3bRFopx/NyOoffd7IMBu8Gyr+VPFOWa ODIw== MIME-Version: 1.0 X-Received: by 10.170.86.132 with SMTP id d126mr1906511yka.57.1437183089749; Fri, 17 Jul 2015 18:31:29 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 17 Jul 2015 18:31:29 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 17 Jul 2015 18:31:29 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> Date: Fri, 17 Jul 2015 18:31:29 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a113a7f3e8ab728051b1c43e2 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 01:31:31 -0000 --001a113a7f3e8ab728051b1c43e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jul 17, 2015 5:01 PM, "I=C3=B1aki Baz Castillo" wrote: > > The point is that you don't even choose the interface. The OS will do for you. The OS can - and frequently does - get that wrong. The default route can fail when another might succeed. You can't allow that to happen if you care about connecting successfully. --001a113a7f3e8ab728051b1c43e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 17, 2015 5:01 PM, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote:
>
> The point is that you don't even choose the interface. The OS will= do for you.

The OS can - and frequently does - get that wrong. The defau= lt route can fail when another might succeed.

You can't allow that to happen if you care about connect= ing successfully.

--001a113a7f3e8ab728051b1c43e2-- From nobody Sat Jul 18 01:19:53 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988EA1AD0B1 for ; Sat, 18 Jul 2015 01:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hST71lbufQL5 for ; Sat, 18 Jul 2015 01:19:50 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 85B5D1AD0AD for ; Sat, 18 Jul 2015 01:19:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B3ACF7C3659 for ; Sat, 18 Jul 2015 10:19:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih3KR4VREz9n for ; Sat, 18 Jul 2015 10:19:48 +0200 (CEST) Received: from [IPv6:2001:67c:370:136:e190:20fd:9b5e:945d] (unknown [IPv6:2001:67c:370:136:e190:20fd:9b5e:945d]) by mork.alvestrand.no (Postfix) with ESMTPSA id AE72C7C0E3D for ; Sat, 18 Jul 2015 10:19:48 +0200 (CEST) Message-ID: <55AA0C23.4000808@alvestrand.no> Date: Sat, 18 Jul 2015 10:19:47 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 08:19:51 -0000 On 07/17/2015 08:22 PM, Daniel Roesler wrote: > In fact, is WebRTC the only > browser standard (i.e. not flash) that can fire off a DNS request > that's not (at least at first) for an HTTP address[1]? There's also the ftp: URL. And the gopher: URL. And the telnet: URL, if anyone still remembers that one. In fact, every single URL type that has an embedded hostname fires off a DNS query. There is no such thing as a HTTP address. There are only A and AAAA recor= ds. And ws: URLs don't have to point to a server that serves HTTP. So I'm not sure what the question is really asking, but for all the interpretations I can come up with that make sense to me, the answer is "no". --=20 Surveillance is pervasive. Go Dark. From nobody Sat Jul 18 01:37:08 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45AF1AD277 for ; Sat, 18 Jul 2015 01:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQtKXY9Vwjjg for ; Sat, 18 Jul 2015 01:37:06 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226E81AD272 for ; Sat, 18 Jul 2015 01:37:06 -0700 (PDT) Received: by wgbcc4 with SMTP id cc4so3846027wgb.3 for ; Sat, 18 Jul 2015 01:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=vdfpCWDKB34C8qI9sPfm+WSmMUhvnnY3MAz78qToXf4=; b=CSSz/ksMYBzz7J9/zeOFIBSZLzW+mHB/VY4ZmovfG4x7M0FHHWlcm6lt3SMFedSH7t PJx+omZgqVFFZMrI59Lon3fPYmG5rQcMikJHggEy9AAdZZDqlB4GwWiJWsfIBpZBAPj0 Cm7Rdfh7NxmnLYDHCVn9fzz0ZWU000OXfQqmWf++vwGloZ0X0m817kLnWMd3PKTa3yCp c7dztPua7zqu0wqlbtcAX1IQKIJzvLH9Na/A1jo33rWijcKe0dBYB9wXxTtc90H01pWY x/u4qnu+fA3ixkA0U9gNp1fzCSZlMheOf0N+0RBiN5dZ1ZOXWqj+GUqMrlcDgMSr8Diw 2Dmw== X-Received: by 10.194.185.180 with SMTP id fd20mr35239381wjc.16.1437208624902; Sat, 18 Jul 2015 01:37:04 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by smtp.googlemail.com with ESMTPSA id ft5sm1541047wib.4.2015.07.18.01.37.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 01:37:03 -0700 (PDT) To: Justin Uberti References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <55A99148.1040105@gmail.com> From: Sergio Garcia Murillo Message-ID: <55AA1039.7070403@gmail.com> Date: Sat, 18 Jul 2015 10:37:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090907020106050703060103" Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 08:37:07 -0000 This is a multi-part message in MIME format. --------------090907020106050703060103 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 18/07/2015 2:19, Justin Uberti wrote: > > On Fri, Jul 17, 2015 at 4:35 PM, Sergio Garcia Murillo > > wrote: > > On 18/07/2015 1:09, Justin Uberti wrote: > > Agree, for each HOST candidate, it should send a STUN request to > the turn server from that IP:port. But shouldn't the VPN > configuration prevent the non-VPN-host-candidate STUN request to > be sent via the non-VPN-interface? (i.e. applying default route > based on dest?) > > > Replying to Sergio: > > Typically with a VPN, the non-VPN interface is locked down so it only > has a single route: to the VPN server. However, split tunnel VPNs > allow the non-VPN interface to route to other addresses (possibly, for > performance reasons), so in this case, the non-VPN-host-candidate STUN > request will be sent successfully from the non-VPN interface. > > Sometimes this will be desirable: imagine someone working from home > who wants to connect to their corp VPN, but wants to have their video > conferencing traffic not go through the VPN. Sometimes this will not > be desirable, i.e. when the VPN is being used for privacy. This makes > picking a perfect default setting difficult, although we have some > ideas that we are exploring. Agree, but IMHO in the case of case of split tunnels, shouldn't that issue be solved better if the VPN is configured with the only the routes to the corporate system via the VPN and leave the default route for the non-VPN-interface for all the other traffic? You know that I am all for fixing connectivity issues in corp networks (my business depends on that!) but in this case I think the privacy of non-WebRTC users that has a VPN configured correctly should be more important than solving the issues of someone willing to do WebRTC but not doing enough to make it work. Could you share the ideas in the list? As Firefox and Edge might have the same behavior (and issues) I think it could be interesting if we can get to a good common solution and add it to the security draft (if you have not done it already ;) Best regards Sergio --------------090907020106050703060103 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 18/07/2015 2:19, Justin Uberti wrote:

On Fri, Jul 17, 2015 at 4:35 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

On 18/07/2015 1:09, Justin Uberti wrote:

 Agree, for each HOST candidate, it should send a STUN request to the turn server from that IP:port. But shouldn't the VPN configuration prevent the non-VPN-host-candidate STUN request to be sent via the non-VPN-interface? (i.e. applying default route based on dest?)

Replying to Sergio:

Typically with a VPN, the non-VPN interface is locked down so it only has a single route: to the VPN server. However, split tunnel VPNs allow the non-VPN interface to route to other addresses (possibly, for performance reasons), so in this case, the non-VPN-host-candidate STUN request will be sent successfully from the non-VPN interface.

Sometimes this will be desirable: imagine someone working from home who wants to connect to their corp VPN, but wants to have their video conferencing traffic not go through the VPN. Sometimes this will not be desirable, i.e. when the VPN is being used for privacy. This makes picking a perfect default setting difficult, although we have some ideas that we are exploring.

Agree, but IMHO in the case of case of split tunnels, shouldn't that issue be solved better if the VPN is configured with the only the routes to the corporate system via the VPN and leave the default route for the non-VPN-interface for all the other traffic?

You know that I am all for fixing connectivity issues in corp networks (my business depends on that!) but in this case I think the privacy of non-WebRTC users that has a VPN configured correctly should be more important than solving the issues of someone willing to do WebRTC but not doing enough to make it work.

Could you share the ideas in the list? As Firefox and Edge might have the same behavior (and issues) I think it could be interesting if we can get to a good common solution and add it to the security draft (if you have not done it already ;)

Best regards
Sergio
--------------090907020106050703060103-- From nobody Sat Jul 18 01:39:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3F31AD2AF; Sat, 18 Jul 2015 01:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.711 X-Spam-Level: X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2i6YEx6zla4; Sat, 18 Jul 2015 01:39:09 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76531AD277; Sat, 18 Jul 2015 01:39:09 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t6I8d2uc030583 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Jul 2015 04:39:02 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t6I8d2uc030583 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1437208744; bh=AXQUoRMHIaNFlQqa6WENgVD2M7E=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=eMo1L1wqEt7iCdWMJ1ZK6Sb05daHlnSF77GQKNJ3od6/9cllknDKWnm2Zox5ldw29 z/PZFEnw8WRoKkIBQNTUygOyr4ld4mQNVUK2YPDKBygDuzaEbK7B76F4+3KP/+tsT0 HRzuUJ+0Tls6LfSrRFXNK90hDB6zD+jbzY2wzVQI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t6I8d2uc030583 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd05.lss.emc.com (RSA Interceptor); Sat, 18 Jul 2015 04:38:42 -0400 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t6I8cgR0019829 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 Jul 2015 04:38:42 -0400 Received: from MXHUB102.corp.emc.com (10.253.58.15) by mxhub28.corp.emc.com (10.254.110.184) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sat, 18 Jul 2015 04:38:41 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.107]) by MXHUB102.corp.emc.com ([::1]) with mapi id 14.03.0224.002; Sat, 18 Jul 2015 04:38:41 -0400 From: "Black, David" To: Harald Alvestrand , "tsvwg@ietf.org" Thread-Topic: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs? Thread-Index: AdC44D8iwGtnK6zWTSSirTPJqHEqwwHDVNgAAFFZYrA= Date: Sat, 18 Jul 2015 08:38:41 +0000 Message-ID: References: <55A7B2BC.2090307@alvestrand.no> In-Reply-To: <55A7B2BC.2090307@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.76.188.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 08:39:11 -0000 Harald, [+rtcweb list] > This may or may not help, but should be considered in the discussion on > Wednesday. That should help, although I wonder about larger API concerns - my initial take is that the first JavaScript application API call that sends data traffic is likely to set the DSCP for the data channel for all data traffic for the RTCWEB session (or that DSCP will be a browser implementation constant, in which case, only DF appears to be defensible in full generalit= y, IMHO), especially as: > RTCWEB considered the option of supporting multiple SCTP channels, then > decided not to pursue that option - it just got a bit too messy. In contrast, the DSCP for audio/video traffic can vary within an RTCWEB ses= sion. Meanwhile, on multiple SCTP channels, I've heard *exactly* the opposite fro= m Cullen. I've already "volunteered" to show up in RTCWEB's second session o= n Friday to talk about the QoS draft (Paul, Cullen and I have talked - we thi= nk we know what has to be done, and hope to have draft text by Thu [and TSVWG currently has the rtcweb-qos draft on our Thu agenda, not Wed]). Could you and/or Cullen make sure that Diffserv/DSCP QoS in general and this multiple SCTP channel concern get onto RTCWEB's Friday agenda when that agenda gets bashed, please, as I really should be in TAPS during RTCWEB's Thu session? Thanks, --David > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Thursday, July 16, 2015 9:34 AM > To: Black, David; tsvwg@ietf.org > Subject: Re: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs? >=20 > Den 07. juli 2015 20:10, skrev Black, David: > > - For data, the WebRTC QoS draft uses four different sets of DSCPs > > across which there are no constraints on reordering: > > > > | Data | CS1 | DF | AF1x (10, | AF2x (18, = | > > | | (8) | (0) | 12, 14) | 20, 22) = | > > > > This is asking for trouble if all the data involved flows over a > > single SCTP association ... which appears to be exactly what WebRTC > > is going to do: > > > > https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-= 6 > > > > Something is definitely wrong here, as the DART draft clearly advises > > against more than one DSCP per SCTP association (from Section 6): >=20 > David, >=20 > draft-ietf-rtcweb-transport put in this language after discussing > reordering: >=20 >=20 > Implementations SHOULD attempt to set QoS on the packets sent, > according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos]. >=20 > ..... >=20 > All packets carrying data from the SCTP association supporting the > data channels MUST use a single DSCP code point. >=20 > All packets on one TCP connection, no matter what it carries, MUST > use a single DSCP code point. >=20 >=20 > What codepoint to pick is a good question (the one reflecting the > highest priority channel currently being sent is an obvious, but perhaps > not optimal choice). >=20 > RTCWEB considered the option of supporting multiple SCTP channels, then > decided not to pursue that option - it just got a bit too messy. >=20 > This may or may not help, but should be considered in the discussion on > Wednesday. >=20 > Harald From nobody Sat Jul 18 02:00:39 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155A71AD378 for ; Sat, 18 Jul 2015 02:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MALFORMED_FREEMAIL=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPk83HFguWZB for ; Sat, 18 Jul 2015 02:00:35 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C311AD375 for ; Sat, 18 Jul 2015 02:00:35 -0700 (PDT) Received: by wgbcc4 with SMTP id cc4so4083627wgb.3 for ; Sat, 18 Jul 2015 02:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:cc:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=+oOGvhq+mUuAoHgAb8S6tlaGkzgIZHQ1o7u9otwhC40=; b=NvODEVLBjE0ohDR9YxVbwSUN7go5BnvI2ffutqNgmEAO3LCdGphWEQPuSRzvxhtENt r0r0YHAZQbtFjiXZwPGqzm4SaHwSunGPn3q6dh8AY1admmVj6rpSzdZyo2yL1w8e/NOP 0ozmqmKbBnIEbWqI2fJOYgB0mlYz/SGbyU5syYNAq6FOeNq4WHk7Eee3k9pGJsqXZI1r OGxsen78ImZEPs8Sx2uaOQzEM+c58TQ1foIBEbC2wn2hrbMlruYFcNQeitPQYtsLC6BO T8VD+11BW7QGKZt+0GUVouou9gHvvEjqENlrVSh/ci871W9JEPz8WITFvhiQi1O2e+H2 5dQQ== X-Received: by 10.194.100.42 with SMTP id ev10mr35382796wjb.50.1437210034248; Sat, 18 Jul 2015 02:00:34 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by smtp.googlemail.com with ESMTPSA id gb16sm1626266wic.5.2015.07.18.02.00.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 02:00:33 -0700 (PDT) References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <55A99148.1040105@gmail.com> <55AA1039.7070403@gmail.com> Cc: "rtcweb@ietf.org" From: Sergio Garcia Murillo Message-ID: <55AA15AF.40908@gmail.com> Date: Sat, 18 Jul 2015 11:00:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55AA1039.7070403@gmail.com> Content-Type: multipart/alternative; boundary="------------030001080508050405060004" Archived-At: Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 09:00:37 -0000 This is a multi-part message in MIME format. --------------030001080508050405060004 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 18/07/2015 10:37, Sergio Garcia Murillo wrote: > On 18/07/2015 2:19, Justin Uberti wrote: >> >> On Fri, Jul 17, 2015 at 4:35 PM, Sergio Garcia Murillo >> > > wrote: >> >> On 18/07/2015 1:09, Justin Uberti wrote: >> >> Agree, for each HOST candidate, it should send a STUN request to >> the turn server from that IP:port. But shouldn't the VPN >> configuration prevent the non-VPN-host-candidate STUN request to >> be sent via the non-VPN-interface? (i.e. applying default route >> based on dest?) >> >> >> Replying to Sergio: >> >> Typically with a VPN, the non-VPN interface is locked down so it only >> has a single route: to the VPN server. However, split tunnel VPNs >> allow the non-VPN interface to route to other addresses (possibly, >> for performance reasons), so in this case, the non-VPN-host-candidate >> STUN request will be sent successfully from the non-VPN interface. >> >> Sometimes this will be desirable: imagine someone working from home >> who wants to connect to their corp VPN, but wants to have their video >> conferencing traffic not go through the VPN. Sometimes this will not >> be desirable, i.e. when the VPN is being used for privacy. This makes >> picking a perfect default setting difficult, although we have some >> ideas that we are exploring. > > Agree, but IMHO in the case of case of split tunnels, shouldn't that > issue be solved better if the VPN is configured with the only the > routes to the corporate system via the VPN and leave the default route > for the non-VPN-interface for all the other traffic? > > You know that I am all for fixing connectivity issues in corp networks > (my business depends on that!) but in this case I think the privacy of > non-WebRTC users that has a VPN configured correctly should be more > important than solving the issues of someone willing to do WebRTC but > not doing enough to make it work. > > Could you share the ideas in the list? As Firefox and Edge might have > the same behavior (and issues) I think it could be interesting if we > can get to a good common solution and add it to the security draft (if > you have not done it already ;) > BTW, shouldn't this conversation be crossposted/forwarded to the TRAM list as well? Best regards Sergio --------------030001080508050405060004 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 18/07/2015 10:37, Sergio Garcia Murillo wrote:
On 18/07/2015 2:19, Justin Uberti wrote:

On Fri, Jul 17, 2015 at 4:35 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

On 18/07/2015 1:09, Justin Uberti wrote:

 Agree, for each HOST candidate, it should send a STUN request to the turn server from that IP:port. But shouldn't the VPN configuration prevent the non-VPN-host-candidate STUN request to be sent via the non-VPN-interface? (i.e. applying default route based on dest?)

Replying to Sergio:

Typically with a VPN, the non-VPN interface is locked down so it only has a single route: to the VPN server. However, split tunnel VPNs allow the non-VPN interface to route to other addresses (possibly, for performance reasons), so in this case, the non-VPN-host-candidate STUN request will be sent successfully from the non-VPN interface.

Sometimes this will be desirable: imagine someone working from home who wants to connect to their corp VPN, but wants to have their video conferencing traffic not go through the VPN. Sometimes this will not be desirable, i.e. when the VPN is being used for privacy. This makes picking a perfect default setting difficult, although we have some ideas that we are exploring.

Agree, but IMHO in the case of case of split tunnels, shouldn't that issue be solved better if the VPN is configured with the only the routes to the corporate system via the VPN and leave the default route for the non-VPN-interface for all the other traffic?

You know that I am all for fixing connectivity issues in corp networks (my business depends on that!) but in this case I think the privacy of non-WebRTC users that has a VPN configured correctly should be more important than solving the issues of someone willing to do WebRTC but not doing enough to make it work.

Could you share the ideas in the list? As Firefox and Edge might have the same behavior (and issues) I think it could be interesting if we can get to a good common solution and add it to the security draft (if you have not done it already ;)


BTW, shouldn't this conversation be crossposted/forwarded to the TRAM list as well?

Best regards
Sergio
--------------030001080508050405060004-- From nobody Sat Jul 18 02:23:21 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2921B29D3 for ; Sat, 18 Jul 2015 02:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWTNPFxKlOpG for ; Sat, 18 Jul 2015 02:23:19 -0700 (PDT) Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5145F1B29CA for ; Sat, 18 Jul 2015 02:23:19 -0700 (PDT) Received: by ykax123 with SMTP id x123so107272991yka.1 for ; Sat, 18 Jul 2015 02:23:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=11fToxi27fYW9QtUC0R+lb6pfJVV6SwlfAUlW/17Y/o=; b=Lbu1uIK2Se2eTEGLyIRmectDJeOgUg7gz6Nfsv/Pp0KIzMopD/JLqbgRS3wPItX09a KgAkuJ6mvu9BSLLRC7ylN1kCb2X4FuKZClB0p9inYzLujZ8PhAZALTX1dVsmzwIyAXkQ V4NSygFHN3hKEFSHfDJB52Ju8G7yrWQg+UHTGyGpSV1hvPr//+83qitd1HmzNZ1EcNkS 3odo8BGH4MIOhIzMIWgQdAdWfLAYkyOe0m7AP+jx1pnze+fBY2n3Dmp0chrpqTq3x3aS wTb9RchQbaTqMXjbDz1j6/cU9c3D4JrTg9PhZfEeZ8u/iOAc9l2+MsCda1+HTRco0rgB dkdw== X-Gm-Message-State: ALoCoQmm2QRjWZyJBQoD8AJSENiyGnbuiBVjdmlx5ZXndDzQE1K2cRITCmJG722YAq7ShJAhGqFp X-Received: by 10.129.75.214 with SMTP id y205mr19796452ywa.65.1437211398697; Sat, 18 Jul 2015 02:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Sat, 18 Jul 2015 02:22:59 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 18 Jul 2015 11:22:59 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 09:23:20 -0000 2015-07-18 3:31 GMT+02:00 Martin Thomson : > The OS can - and frequently does - get that wrong. The default route can > fail when another might succeed. > > You can't allow that to happen if you care about connecting successfully. Are we talking about ICE gathering and STUN/TURN servers? or are we talking about p2p ICE connectivity? --=20 I=C3=B1aki Baz Castillo From nobody Sat Jul 18 02:32:06 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E83D1B29E2 for ; Sat, 18 Jul 2015 02:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9e_zzTt8Pzm for ; Sat, 18 Jul 2015 02:32:04 -0700 (PDT) Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423DD1B29DF for ; Sat, 18 Jul 2015 02:32:04 -0700 (PDT) Received: by ykax123 with SMTP id x123so107345379yka.1 for ; Sat, 18 Jul 2015 02:32:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=15bsETs5L+aih3P12qgtmxNPRv/qwS4g8TYDnrzVylg=; b=UKjaoesldh2eOIkHQBNFMZMbb5/cNG0FF/QHjCW8WWqKYJZDB9L/Bd1k58LE8phGrK 4H3uXB0UKYXwdpk6TNxWn75oTAyMpstvdpJbH1c4Z5noa1zSk5CWm4aDxYjsXGWLuX0b Fqh8jApXTB5sQNnoVzCmoR8lcI5XnGX9oP1QutTnl+D07JwpBSNn6QKM4lboaKu39fF2 4iMhXkOGKzAxJQ+5bNaFKHhzmoZd8bz/yzse+t2ZbyXw/w4sLZlefL4YCrHb67arQxw+ hU6tUSYobRg0f5KzTc3qfUelilX2b4gst5xgGHX+Hgv4oRfkg6f3WenTfxIOFAdok/Qy quxQ== X-Gm-Message-State: ALoCoQl/BSBTgR283sJAS4Ym5mMsyGmIYiSFYcbtOwyJuXE2sWo/F9OehE21mtUq+g7FjIgyogew X-Received: by 10.129.77.213 with SMTP id a204mr19898915ywb.40.1437211923681; Sat, 18 Jul 2015 02:32:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Sat, 18 Jul 2015 02:31:44 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <55A99148.1040105@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 18 Jul 2015 11:31:44 +0200 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 09:32:05 -0000 2015-07-18 2:19 GMT+02:00 Justin Uberti : > Typically with a VPN, the non-VPN interface is locked down so it only has= a > single route: to the VPN server. However, split tunnel VPNs allow the > non-VPN interface to route to other addresses (possibly, for performance > reasons), so in this case, the non-VPN-host-candidate STUN request will b= e > sent successfully from the non-VPN interface. Is that really the most common VNC scenario? Never seen that. I thought that usually the VNC client adds its own network routes to reach other users/servers within the same VNC network and leaves the default route (and others) intact. My worries are about ICE gathering and the timeout it causes when a STUN request is sent to the STUN/TURN server from all the local interfaces. Security/privacy issues (if we consider that leaking all the host and reflexive addresses is an issue) can happen during ICE gathering and also when connecting the remote peer. --=20 I=C3=B1aki Baz Castillo From nobody Sat Jul 18 02:38:41 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C32B1B29F4 for ; Sat, 18 Jul 2015 02:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8UGpdSC3Pl6 for ; Sat, 18 Jul 2015 02:38:38 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92AF91B29F5 for ; Sat, 18 Jul 2015 02:38:38 -0700 (PDT) Received: by igvi1 with SMTP id i1so49821722igv.1 for ; Sat, 18 Jul 2015 02:38:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1eMxQ5jGi+jj6f8D59gwab0BMPk33bxNY4MgU/2064c=; b=isfRJBFe0r54GDXZa81g9JZio7pAEHILe3GkMm2/ELY0zGWqCdAGqMmurq/oVPND8k 547Qa5J/tJvg8t7dvh4HpXNGYUvJq/18TmYxY000rlbXUQfJ2LV8KEwZHGcqX2VCv6QR +X5IB4o/P+a3ZCVm5Xn4iI7sKgU9krkZKbhQY2Vmj5TNRzx9o2cBwyMxAZEHgTZqgkIM l9Nz8iQVZGDzsPgZsUaG+wtNYEibFxrei+PIvOcUfvaKYzUcVI9PtvXCD2TKpkFdS4XT oOE4gEsBw3MPsvlf5idq5NvK4WdnZZLo2Lgoov1vqbK8mFDI2DQd8p6B8N9d+E5x9bKZ kfSA== X-Gm-Message-State: ALoCoQmI608kMhL5id3T+kzFisCct78Q14o45MOTWEt+UKpWzbIES0orAZtTw9/RpwOu5dKJ2LiN X-Received: by 10.107.41.11 with SMTP id p11mr21510708iop.148.1437212317964; Sat, 18 Jul 2015 02:38:37 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by smtp.gmail.com with ESMTPSA id l62sm9267650iol.36.2015.07.18.02.38.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 02:38:36 -0700 (PDT) Received: by iggf3 with SMTP id f3so52470279igg.1 for ; Sat, 18 Jul 2015 02:38:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.7.214 with SMTP id g83mr26437548ioi.28.1437212315614; Sat, 18 Jul 2015 02:38:35 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Sat, 18 Jul 2015 02:38:35 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> Date: Sat, 18 Jul 2015 05:38:35 -0400 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113f911c8a0807051b2311f5 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 09:38:40 -0000 --001a113f911c8a0807051b2311f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 17, 2015 at 9:31 PM, Martin Thomson wrote: > On Jul 17, 2015 5:01 PM, "I=C3=B1aki Baz Castillo" wrote: > > > > The point is that you don't even choose the interface. The OS will do > for you. > > The OS can - and frequently does - get that wrong. The default route can > fail when another might succeed. > > You can't allow that to happen if you care about connecting successfully. > Sending data to a particular destination over an interface that is not supposed to be used based on the local routing is definitely something that goes against the local policy and should be discouraged. For instance on a mobile device, not being able to reach a particular STUN/TURN server over WiFi, should not give the browser an automatic permission to send media over cell data interface and generate a huge bill for the customer. Forcibly overwriting default route is something that should need user consent. I understand that we want the call to succeed in as many cases as possible, but blindly assuming that the local routing policy exists for no reason whatsoever is somewhat dangerous. Would it make sense to use the default route when sending BIND requests to the STUN/TURN server and ICE connectivity checks? All the host interfaces, including non-default, should, of cause, be included as targets for remote connectivity checks. An extra option should enable using non-default interfaces to send ICE requests and it should only be enabled if user explicitly agrees to it. Vast majority of users will never need it anyway. Regards, _____________ Roman Shpount --001a113f911c8a0807051b2311f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 17, 2015 at 9:31 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:

On Jul 17, 2015 5:01 PM, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote: >
> The point is that you don't even choose the interface. The OS will= do for you.

The OS can - and frequently does - get that wrong. Th= e default route can fail when another might succeed.

You can't allow that to happen if you care about connect= ing successfully.

Sending data to a parti= cular destination over an interface that is not supposed to be used based o= n the local routing is definitely something that goes against the local pol= icy and should be discouraged. For instance on a mobile device, not being a= ble to reach a particular STUN/TURN server over WiFi, should not give the b= rowser an automatic permission to send media over cell data interface and g= enerate a huge bill for the customer. Forcibly overwriting default route is= something that should need user consent. I understand that we want the cal= l to succeed in as many cases as possible, but blindly assuming that the lo= cal routing policy exists for no reason whatsoever is somewhat dangerous.

Would i= t make sense to use the default route when sending BIND requests to the STU= N/TURN server and ICE connectivity checks? All the host interfaces, includi= ng non-default, should, of cause, be included as targets for remote connect= ivity checks. An extra option should enable using non-default interfaces to= send ICE requests and it should only be enabled if user explicitly agrees = to it. Vast majority of users will never need it anyway.

Regards,
_____________
Roman= Shpount

--001a113f911c8a0807051b2311f5-- From nobody Sat Jul 18 02:48:58 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4ECE1B2A15; Sat, 18 Jul 2015 02:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfKhtjotW3BR; Sat, 18 Jul 2015 02:48:55 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 1FABB1B2A12; Sat, 18 Jul 2015 02:48:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1F06F7C3659; Sat, 18 Jul 2015 11:48:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAZTOO7dgCMf; Sat, 18 Jul 2015 11:48:52 +0200 (CEST) Received: from [IPv6:2001:67c:370:136:e190:20fd:9b5e:945d] (unknown [IPv6:2001:67c:370:136:e190:20fd:9b5e:945d]) by mork.alvestrand.no (Postfix) with ESMTPSA id A20387C0E3D; Sat, 18 Jul 2015 11:48:51 +0200 (CEST) Message-ID: <55AA2102.9010300@alvestrand.no> Date: Sat, 18 Jul 2015 11:48:50 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Black, David" , "tsvwg@ietf.org" References: <55A7B2BC.2090307@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 09:48:58 -0000 On 07/18/2015 10:38 AM, Black, David wrote: > Harald, > [+rtcweb list] > >> This may or may not help, but should be considered in the discussion o= n >> Wednesday. > That should help, although I wonder about larger API concerns - my init= ial > take is that the first JavaScript application API call that sends data > traffic is likely to set the DSCP for the data channel for all data tra= ffic > for the RTCWEB session (or that DSCP will be a browser implementation > constant, in which case, only DF appears to be defensible in full gener= ality, > IMHO), If we can agree on and document what browsers *should* do, it is likely that this is what they'll end up doing. The implementors are in the room, after all. > especially as: > >> RTCWEB considered the option of supporting multiple SCTP channels, the= n >> decided not to pursue that option - it just got a bit too messy. > In contrast, the DSCP for audio/video traffic can vary within an RTCWEB= session. Yep. Both because tsvw-rtcweb-qos specifies multiple DSCP code points per priority level, and because the API as currently designed permits changing the priority of a media track. > > Meanwhile, on multiple SCTP channels, I've heard *exactly* the opposite= from > Cullen. I've already "volunteered" to show up in RTCWEB's second sessi= on on > Friday to talk about the QoS draft (Paul, Cullen and I have talked - we= think > we know what has to be done, and hope to have draft text by Thu [and TS= VWG > currently has the rtcweb-qos draft on our Thu agenda, not Wed]). Thanks for the fix! (was wrong in my notes) > > Could you and/or Cullen make sure that Diffserv/DSCP QoS in general and= > this multiple SCTP channel concern get onto RTCWEB's Friday agenda when= > that agenda gets bashed, please, as I really should be in TAPS during > RTCWEB's Thu session? Cullen's one of the chairs, I'm just a WG member; I'll try to help get it there. > > Thanks, > --David > >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Thursday, July 16, 2015 9:34 AM >> To: Black, David; tsvwg@ietf.org >> Subject: Re: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs? >> >> Den 07. juli 2015 20:10, skrev Black, David: >>> - For data, the WebRTC QoS draft uses four different sets of DSCPs >>> across which there are no constraints on reordering: >>> >>> | Data | CS1 | DF | AF1x (10, | AF2x (18= , | >>> | | (8) | (0) | 12, 14) | 20, 22)= | >>> >>> This is asking for trouble if all the data involved flows over a >>> single SCTP association ... which appears to be exactly what WebRTC >>> is going to do: >>> >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#sectio= n-6 >>> >>> Something is definitely wrong here, as the DART draft clearly advise= s >>> against more than one DSCP per SCTP association (from Section 6): >> David, >> >> draft-ietf-rtcweb-transport put in this language after discussing >> reordering: >> >> >> Implementations SHOULD attempt to set QoS on the packets sent, >> according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos]. >> >> ..... >> >> All packets carrying data from the SCTP association supporting the >> data channels MUST use a single DSCP code point. >> >> All packets on one TCP connection, no matter what it carries, MUST >> use a single DSCP code point. >> >> >> What codepoint to pick is a good question (the one reflecting the >> highest priority channel currently being sent is an obvious, but perha= ps >> not optimal choice). >> >> RTCWEB considered the option of supporting multiple SCTP channels, the= n >> decided not to pursue that option - it just got a bit too messy. >> >> This may or may not help, but should be considered in the discussion o= n >> Wednesday. >> >> Harald --=20 Surveillance is pervasive. Go Dark. From nobody Sat Jul 18 03:01:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108BE1B2A2F for ; Sat, 18 Jul 2015 03:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNoc-rcPB3Nr for ; Sat, 18 Jul 2015 03:01:46 -0700 (PDT) Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4554E1B2A2B for ; Sat, 18 Jul 2015 03:01:46 -0700 (PDT) Received: by ykay190 with SMTP id y190so107356902yka.3 for ; Sat, 18 Jul 2015 03:01:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Yg2BZZnqH7NDZrZ9x6bVJ9CxmledOTnl2dgLdIqtm7Q=; b=FnMiek6OxXJohB5kRx4etOeUzqztMp6Bzw4J8UBlQV0SmF7WjXvgx1sHOkX4R0eokY 3PKuZWld+G16wCfCMuZPKWYRn0YVX3L0NTjdfXHeM4klPZZWO3UBZI13TGDFvFYzEnIL DkrQxGSHwGecn1twldjsdV8VCNpzQZHn/DSZ3qwLad1XtYIA/mUSJbBAarkULJsGc0le 83BAdTcvRpGJQGyeLWP7Wa47PYwltKxUr2EnZDElBpe2SEqEm/r5FLyWG/nkz87VYavs mQ90HRzt58x/jGQoTQFifMlk4VY7h6cEiL+ctlvl+bM6dIFI+AnQ8nuGtYg+K0VgUdeR ygMQ== X-Gm-Message-State: ALoCoQnhQ6bat46m4MPRoCXqDOD2mea/m4FMDFfq8EHs1hUteRXJNOFuie0Izmc+pYwH9ZUuMvAM X-Received: by 10.13.255.2 with SMTP id p2mr2503798ywf.149.1437213705648; Sat, 18 Jul 2015 03:01:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Sat, 18 Jul 2015 03:01:26 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 18 Jul 2015 12:01:26 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 10:01:47 -0000 2015-07-18 11:38 GMT+02:00 Roman Shpount : > Sending data to a particular destination over an interface that is not > supposed to be used based on the local routing is definitely something th= at > goes against the local policy and should be discouraged. For instance on = a > mobile device, not being able to reach a particular STUN/TURN server over > WiFi, should not give the browser an automatic permission to send media o= ver > cell data interface and generate a huge bill for the customer. Forcibly > overwriting default route is something that should need user consent. I > understand that we want the call to succeed in as many cases as possible, > but blindly assuming that the local routing policy exists for no reason > whatsoever is somewhat dangerous. +1 --=20 I=C3=B1aki Baz Castillo From nobody Sat Jul 18 13:59:31 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A576D1A1AAD for ; Sat, 18 Jul 2015 13:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOkJsSje6VRF for ; Sat, 18 Jul 2015 13:59:28 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549CD1A1A6F for ; Sat, 18 Jul 2015 13:59:28 -0700 (PDT) Received: by iehx8 with SMTP id x8so16396734ieh.3 for ; Sat, 18 Jul 2015 13:59:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZmYlMoAHxNnBGrNFDOGDXH0MNXPUuA1maI4SIaNuDLs=; b=CvRcR4ROA9sqfDktmgVOFtPufQGCLoazp44YgBw8zTC93uVFEuZ81TjJnd1JyRyPqs eNR0p0pP1/MU0KD23OEYMIoMmXX6VAQZGO+hjfVL/76gTANeZmKyIWtL3qua/FcWiKmY fxuwwCAIscb1rb4o/7WQa4Gp06CZzHXDZFkDnNvj/cBnpQMy1yfxPQE7kxegSw2Q9PdU 5rOQxqWxKn00O/FTXcDQk1TZekcJrxa6jqb40FbVwSMXV2gdtc4tmIXRS8/m7EGK3wSk El/vocABUKuQuSK7RFHldxB7eveuixs9uQLrBZkHu+xDkefj0N8qDzGVqBQDRvfJZ6oP CJ9A== X-Gm-Message-State: ALoCoQl1n5jMucGfx6qBVMA6RqTv3kZPtT/GhPZtQnY3Orh3ueSynKNUxxnXleGhGQ9OuwAMFVnq X-Received: by 10.107.15.18 with SMTP id x18mr29676875ioi.167.1437253167704; Sat, 18 Jul 2015 13:59:27 -0700 (PDT) Received: from Simons-MacBook-Air.local ([206.47.252.21]) by smtp.googlemail.com with ESMTPSA id p82sm5659941ioi.14.2015.07.18.13.59.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 13:59:26 -0700 (PDT) Message-ID: <55AABE28.8070105@jive.com> Date: Sat, 18 Jul 2015 16:59:20 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Roman Shpount References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 20:59:29 -0000 Le 2015-07-18 06:01, Iñaki Baz Castillo a écrit : > 2015-07-18 11:38 GMT+02:00 Roman Shpount : >> Sending data to a particular destination over an interface that is not >> supposed to be used based on the local routing is definitely something that >> goes against the local policy and should be discouraged. For instance on a >> mobile device, not being able to reach a particular STUN/TURN server over >> WiFi, should not give the browser an automatic permission to send media over >> cell data interface and generate a huge bill for the customer. Forcibly >> overwriting default route is something that should need user consent. I >> understand that we want the call to succeed in as many cases as possible, >> but blindly assuming that the local routing policy exists for no reason >> whatsoever is somewhat dangerous. > > +1 -1 Justin and Martin are right. This is a concept that was explained during the ICE tutorial that was presented at IETF 92. Imagine the following multihomed host with three interfaces: - Wi-fi interface with default route. - Wired interface with default route. - VPN interface with default route. Which one should you use to talk to the STUN/TURN server? If you bind to 0.0.0.0 then the kernel *will* pick one, but only because it *has to. All three interfaces are equivalent: they all have a default route and can a priori be used to talk to the server. Being multihomed means multiple interfaces with a default route. There's no "going against the local policy" in this case when sending packets on any interface. The point is that in this case, all three interfaces can potentially yield different server-reflexive candidates, which is why they must be gathered separately. As for relayed candidates, they also need to be gathered separately because some interfaces may be faster for talking to the TURN server and it is useful to compare the candidates gathered on all 3 interfaces. Also nothing guarantees that you're allowed to reach the server server on any interface that has a default route, so you need to try them all. Simon From nobody Sat Jul 18 23:06:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF02C1A0056 for ; Sat, 18 Jul 2015 23:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wOmTnoCVRVD for ; Sat, 18 Jul 2015 23:06:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96EB1A0055 for ; Sat, 18 Jul 2015 23:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4114; q=dns/txt; s=iport; t=1437285989; x=1438495589; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=m8WvKWRZpq3rjO0pLUELPC7jaJKpuofYA4cNN7TlM30=; b=ApCLAaRlmLPw2BN4NpSGl2Ajb/HkjvMA7trLPG7JGeYI1Qa2D7MI57Mg tLhJkZGdAKORsGL5Nr5mFkXXsV0/nkZsAli+XYH0bfFA7lzVkA/jHF0JI xqQjuyG4NMSRZH7+YxkW6AA807leEY/ziCHPE0Lubx6X0y3JNbxiLx2Cl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeAwDvPatV/4ENJK1bgxNUaQaDHbhDCYFrCoUtSgIcgQE4FAEBAQEBAQGBCoQjAQEBAwEBAQEgEToLDAQCAQgOAwQBAQMCBh0DAgICJQsUAQgIAgQBDQUIiB4IDbV9lTMBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEiiiqEOxoWGwcGgmIvgRQFlFIBhG6IdYQakyomghIXgVNvAYFGgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,502,1432598400"; d="scan'208";a="11021493" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jul 2015 06:06:28 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6J66SVM017796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Jul 2015 06:06:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.123]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Sun, 19 Jul 2015 01:06:28 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Roman Shpount Thread-Topic: [rtcweb] Please require user consent for data channels Thread-Index: AQHQu/izWohR92uoXEOLCR4wOYsJlp3gUf+AgAAE9YCAAAPXAIAACd0AgAAUy4CAAAp/gIAACqEAgAASeYCAAAY4AIAABvcAgAAB2YCAAAHDgIAAApCAgAABD4CAABlagIAAiBiAgAAGYwCAALfQAIAAQehQ Date: Sun, 19 Jul 2015 06:06:28 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47894E34@xmb-rcd-x10.cisco.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <55AABE28.8070105@jive.com> In-Reply-To: <55AABE28.8070105@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.32.139] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 06:06:31 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNpbW9uIFBlcnJlYXVsdA0KPiBTZW50 OiBTdW5kYXksIEp1bHkgMTksIDIwMTUgMjoyOSBBTQ0KPiBUbzogScOxYWtpIEJheiBDYXN0aWxs bzsgUm9tYW4gU2hwb3VudA0KPiBDYzogcnRjd2ViQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb cnRjd2ViXSBQbGVhc2UgcmVxdWlyZSB1c2VyIGNvbnNlbnQgZm9yIGRhdGEgY2hhbm5lbHMNCj4g DQo+IExlIDIwMTUtMDctMTggMDY6MDEsIEnDsWFraSBCYXogQ2FzdGlsbG8gYSDDqWNyaXQgOg0K PiA+IDIwMTUtMDctMTggMTE6MzggR01UKzAyOjAwIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVy aXguY29tPjoNCj4gPj4gU2VuZGluZyBkYXRhIHRvIGEgcGFydGljdWxhciBkZXN0aW5hdGlvbiBv dmVyIGFuIGludGVyZmFjZSB0aGF0IGlzDQo+ID4+IG5vdCBzdXBwb3NlZCB0byBiZSB1c2VkIGJh c2VkIG9uIHRoZSBsb2NhbCByb3V0aW5nIGlzIGRlZmluaXRlbHkNCj4gPj4gc29tZXRoaW5nIHRo YXQgZ29lcyBhZ2FpbnN0IHRoZSBsb2NhbCBwb2xpY3kgYW5kIHNob3VsZCBiZQ0KPiA+PiBkaXNj b3VyYWdlZC4gRm9yIGluc3RhbmNlIG9uIGEgbW9iaWxlIGRldmljZSwgbm90IGJlaW5nIGFibGUg dG8gcmVhY2gNCj4gPj4gYSBwYXJ0aWN1bGFyIFNUVU4vVFVSTiBzZXJ2ZXIgb3ZlciBXaUZpLCBz aG91bGQgbm90IGdpdmUgdGhlIGJyb3dzZXINCj4gPj4gYW4gYXV0b21hdGljIHBlcm1pc3Npb24g dG8gc2VuZCBtZWRpYSBvdmVyIGNlbGwgZGF0YSBpbnRlcmZhY2UgYW5kDQo+ID4+IGdlbmVyYXRl IGEgaHVnZSBiaWxsIGZvciB0aGUgY3VzdG9tZXIuIEZvcmNpYmx5IG92ZXJ3cml0aW5nIGRlZmF1 bHQNCj4gPj4gcm91dGUgaXMgc29tZXRoaW5nIHRoYXQgc2hvdWxkIG5lZWQgdXNlciBjb25zZW50 LiBJIHVuZGVyc3RhbmQgdGhhdA0KPiA+PiB3ZSB3YW50IHRoZSBjYWxsIHRvIHN1Y2NlZWQgaW4g YXMgbWFueSBjYXNlcyBhcyBwb3NzaWJsZSwgYnV0IGJsaW5kbHkNCj4gPj4gYXNzdW1pbmcgdGhh dCB0aGUgbG9jYWwgcm91dGluZyBwb2xpY3kgZXhpc3RzIGZvciBubyByZWFzb24gd2hhdHNvZXZl ciBpcw0KPiBzb21ld2hhdCBkYW5nZXJvdXMuDQo+ID4NCj4gPiArMQ0KPiANCj4gLTENCj4gDQo+ IEp1c3RpbiBhbmQgTWFydGluIGFyZSByaWdodC4NCj4gDQo+IFRoaXMgaXMgYSBjb25jZXB0IHRo YXQgd2FzIGV4cGxhaW5lZCBkdXJpbmcgdGhlIElDRSB0dXRvcmlhbCB0aGF0IHdhcyBwcmVzZW50 ZWQNCj4gYXQgSUVURiA5Mi4NCj4gDQo+IEltYWdpbmUgdGhlIGZvbGxvd2luZyBtdWx0aWhvbWVk IGhvc3Qgd2l0aCB0aHJlZSBpbnRlcmZhY2VzOg0KPiANCj4gLSBXaS1maSBpbnRlcmZhY2Ugd2l0 aCBkZWZhdWx0IHJvdXRlLg0KPiAtIFdpcmVkIGludGVyZmFjZSB3aXRoIGRlZmF1bHQgcm91dGUu DQo+IC0gVlBOIGludGVyZmFjZSB3aXRoIGRlZmF1bHQgcm91dGUuDQo+IA0KPiBXaGljaCBvbmUg c2hvdWxkIHlvdSB1c2UgdG8gdGFsayB0byB0aGUgU1RVTi9UVVJOIHNlcnZlcj8gSWYgeW91IGJp bmQgdG8NCj4gMC4wLjAuMCB0aGVuIHRoZSBrZXJuZWwgKndpbGwqIHBpY2sgb25lLCBidXQgb25s eSBiZWNhdXNlIGl0ICpoYXMgdG8uDQo+IEFsbCB0aHJlZSBpbnRlcmZhY2VzIGFyZSBlcXVpdmFs ZW50OiB0aGV5IGFsbCBoYXZlIGEgZGVmYXVsdCByb3V0ZSBhbmQgY2FuIGEgcHJpb3JpDQo+IGJl IHVzZWQgdG8gdGFsayB0byB0aGUgc2VydmVyLg0KPiANCj4gQmVpbmcgbXVsdGlob21lZCBtZWFu cyBtdWx0aXBsZSBpbnRlcmZhY2VzIHdpdGggYSBkZWZhdWx0IHJvdXRlLiBUaGVyZSdzIG5vDQo+ ICJnb2luZyBhZ2FpbnN0IHRoZSBsb2NhbCBwb2xpY3kiIGluIHRoaXMgY2FzZSB3aGVuIHNlbmRp bmcgcGFja2V0cyBvbiBhbnkNCj4gaW50ZXJmYWNlLg0KPiANCj4gVGhlIHBvaW50IGlzIHRoYXQg aW4gdGhpcyBjYXNlLCBhbGwgdGhyZWUgaW50ZXJmYWNlcyBjYW4gcG90ZW50aWFsbHkgeWllbGQg ZGlmZmVyZW50DQo+IHNlcnZlci1yZWZsZXhpdmUgY2FuZGlkYXRlcywgd2hpY2ggaXMgd2h5IHRo ZXkgbXVzdCBiZSBnYXRoZXJlZCBzZXBhcmF0ZWx5LiBBcw0KPiBmb3IgcmVsYXllZCBjYW5kaWRh dGVzLCB0aGV5IGFsc28gbmVlZCB0byBiZSBnYXRoZXJlZCBzZXBhcmF0ZWx5IGJlY2F1c2Ugc29t ZQ0KPiBpbnRlcmZhY2VzIG1heSBiZSBmYXN0ZXIgZm9yIHRhbGtpbmcgdG8gdGhlIFRVUk4gc2Vy dmVyIGFuZCBpdCBpcyB1c2VmdWwgdG8NCj4gY29tcGFyZSB0aGUgY2FuZGlkYXRlcyBnYXRoZXJl ZCBvbiBhbGwgMyBpbnRlcmZhY2VzLiBBbHNvIG5vdGhpbmcgZ3VhcmFudGVlcw0KPiB0aGF0IHlv dSdyZSBhbGxvd2VkIHRvIHJlYWNoIHRoZSBzZXJ2ZXIgc2VydmVyIG9uIGFueSBpbnRlcmZhY2Ug dGhhdCBoYXMgYQ0KPiBkZWZhdWx0IHJvdXRlLCBzbyB5b3UgbmVlZCB0byB0cnkgdGhlbSBhbGwu DQoNClRoaXMgd2lsbCBjaGFuZ2UgaW4gdGhlIGZ1dHVyZSB3aXRoIG11bHRpcGxlIHByb3Zpc2lv bmluZyBkb21haW5zIChQVkQpIGRlZmluZWQgaW4gTUlGIFdHLCBuZXcgc29ja2V0IEFQSSB3aWxs IGJlIHByb3ZpZGVkIHRvIGFsbG93IGFwcGxpY2F0aW9ucyB0byBsZWFybiBhYm91dCBlYWNoIFBW RCBhbmQgdXNlIHRoZW0gc2VwYXJhdGVseSwgYW5kIGFzIGRpc2N1c3NlZCBpbiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzU1NiNzZWN0aW9uLTYuMyBhcHBsaWNhdGlvbiBtYXkgbm90 IG92ZXJyaWRlIGhhcmQgc2V0IHNlbGVjdGVkIGJ5IHRoZSB1c2VyLg0KDQotVGlydQ0KIA0KPiAN Cj4gU2ltb24NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gcnRjd2ViQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From nobody Sun Jul 19 00:21:24 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC431A044D for ; Sun, 19 Jul 2015 00:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt0EMTGMur9C for ; Sun, 19 Jul 2015 00:21:19 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA2F1A070E for ; Sun, 19 Jul 2015 00:21:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 888A87C0BD7 for ; Sun, 19 Jul 2015 09:21:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S886kUWtwikc for ; Sun, 19 Jul 2015 09:21:17 +0200 (CEST) Received: from [IPv6:2001:67c:370:176:e190:20fd:9b5e:945d] (unknown [IPv6:2001:67c:370:176:e190:20fd:9b5e:945d]) by mork.alvestrand.no (Postfix) with ESMTPSA id 276227C06F8 for ; Sun, 19 Jul 2015 09:21:17 +0200 (CEST) Message-ID: <55AB4FEC.7050805@alvestrand.no> Date: Sun, 19 Jul 2015 09:21:16 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <55AABE28.8070105@jive.com> <913383AAA69FF945B8F946018B75898A47894E34@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A47894E34@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 07:21:21 -0000 On 07/19/2015 08:06 AM, Tirumaleswar Reddy (tireddy) wrote: >> Being multihomed means multiple interfaces with a default route. There's no >> > "going against the local policy" in this case when sending packets on any >> > interface. >> > >> > The point is that in this case, all three interfaces can potentially yield different >> > server-reflexive candidates, which is why they must be gathered separately. As >> > for relayed candidates, they also need to be gathered separately because some >> > interfaces may be faster for talking to the TURN server and it is useful to >> > compare the candidates gathered on all 3 interfaces. Also nothing guarantees >> > that you're allowed to reach the server server on any interface that has a >> > default route, so you need to try them all. > This will change in the future with multiple provisioning domains (PVD) defined in MIF WG, new socket API will be provided to allow applications to learn about each PVD and use them separately, and as discussed in https://tools.ietf.org/html/rfc7556#section-6.3 application may not override hard set selected by the user. Rule #53 of the IETF: Things will change in the future, including deployment of just-completed iETF standards, but we don't know when and how. Solutions we engineer MUST work in the current Internet. +1 to Simon - the way systems are designed, implemented and deployed *now*, there may be multiple interfaces with multiple default addresses, and there's nothing intrinsically illegal, immoral or fattening about an application accessing them. (I have personal opinions about the APIs we use to access those interfaces, only some of which are suitable for repeating in polite company, but that is a completely different topic.) -- Surveillance is pervasive. Go Dark. From nobody Sun Jul 19 00:42:02 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1E21A1A8A for ; Sun, 19 Jul 2015 00:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mnw9wG5njFtU for ; Sun, 19 Jul 2015 00:42:00 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E06B1A00B8 for ; Sun, 19 Jul 2015 00:42:00 -0700 (PDT) Received: by iggf3 with SMTP id f3so62782824igg.1 for ; Sun, 19 Jul 2015 00:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2szdZ4f/KMo9KzEq2BkCra+4SgngTxT5SzEjMGT+b3Y=; b=WjB9VNT/NMd+kWYzj6JKKQ8gDc+grNWTQZBWYUtht6jBytwCWr5Jh6wo4dcTLitiJG nVgN+zte8GYoH1cX84TX6OrfRv60ZGfHZhLxER/vriIEbNjrGaAph3aU2/MhBQ3EU2RG nIchwAJXIzb4X+uNrgbCbjFyQQiaRLyl3NRGYPzHXKcy/QCmqeTOdZTC59Ecwmppli9v R+9AInfseKmRIO/44GWha2WDfBIPU/wtNzqGqg3nVsNkT7j8YtqEqvkB71XJUbGbzPUo GCYVKbPa6U/3Bzw3kZ2+9M4/na+R4mLlNbNNCWAOnB9eya7dRLYY0SwpGVX6u7rf/BJo DF1Q== MIME-Version: 1.0 X-Received: by 10.50.142.9 with SMTP id rs9mr6664480igb.17.1437291719598; Sun, 19 Jul 2015 00:41:59 -0700 (PDT) Received: by 10.107.168.195 with HTTP; Sun, 19 Jul 2015 00:41:59 -0700 (PDT) Received: by 10.107.168.195 with HTTP; Sun, 19 Jul 2015 00:41:59 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <55A99148.1040105@gmail.com> Date: Sun, 19 Jul 2015 09:41:59 +0200 Message-ID: From: Sergio Garcia Murillo To: Justin Uberti Content-Type: multipart/alternative; boundary=001a11c2ff1c62ab48051b358ecd Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 07:42:01 -0000 --001a11c2ff1c62ab48051b358ecd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 18/7/2015 2:19, "Justin Uberti" escribi=C3=B3: > > Sometimes this will be desirable: imagine someone working from home who wants to connect to their corp VPN, but wants to have their video conferencing traffic not go through the VPN. Sometimes this will not be desirable, i.e. when the VPN is being used for privacy. This makes picking a perfect default setting difficult, although we have some ideas that we are exploring. Most probably you already have thought about it, but how about adding an interface black/white list for webrtc in privacy settings? IIRC chrome was already skipping some hardcoded virtual interface names. Best regards Sergio --001a11c2ff1c62ab48051b358ecd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


El 18/7/2015 2:19, "Justin Uberti" <juberti@google.com> escribi=C3=B3:
>
> Sometimes this will be desirable: imagine someone working from home wh= o wants to connect to their corp VPN, but wants to have their video confere= ncing traffic not go through the VPN. Sometimes this will not be desirable,= i.e. when the VPN is being used for privacy. This makes picking a perfect = default setting difficult, although we have some ideas that we are explorin= g.

Most probably you already have thought about it, but how abo= ut adding an interface black/white list for webrtc in privacy settings? IIR= C chrome was already skipping some hardcoded virtual interface names.

Best regards
Sergio

--001a11c2ff1c62ab48051b358ecd-- From nobody Sun Jul 19 11:23:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FA71B2B8E; Sun, 19 Jul 2015 11:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gmB98hOhUKL; Sun, 19 Jul 2015 11:23:24 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BA31B2B85; Sun, 19 Jul 2015 11:23:21 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201507192023215297; Sun, 19 Jul 2015 20:23:21 +0200 From: "Karl Stahl" To: "'Benjamin Schwartz'" , "'Cullen Jennings \(fluffy\)'" References: <20150513222927.5331.57264.idtracker@ietfa.amsl.com> <55a4396c.e525700a.ff81b.11d4SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Sun, 19 Jul 2015 20:23:17 +0200 Message-ID: <021501d0c24f$fbe66650$f3b332f0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0216_01D0C260.BF6F3650" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdC90q5fMBdd1XATSX+N/CqPObKYhgC2/Rtw Content-Language: sv Archived-At: Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN discovery: X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 18:23:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0216_01D0C260.BF6F3650 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Benjamin =E2=80=93 your concern is valid =E2=80=93 I thought exo-sealed = was easy to do in the browser. =20 Below I list a firewall configuration assisted method to address the = TURN server and bandwidth resource consumption problem for local WebRTC = calls when using the sealed configuration. I believe my suggestion also = will meet all security/trust/privacy perspectives and give secure = auto-configuration, so mobile devices can to be used with high-quality = secure WebRTC communication =E2=80=9Ceverywhere you can surf=E2=80=9D = through proper use of Border TURN servers - which must be the (almost = already achieved) purpose of this RETURN draft. =20 After some consideration, to achieve the preferred exo-sealed = configuration, the RETURN drafts already prescribes the best default = configuration: =E2=80=9Cleaky=E2=80=9D ! :-)=20 Explanations inline below --> =20 Below are also some suggestions for inclusion in the drafts: draft-ietf-tram-turn-server-discovery-03 draft-jennings-behave-rtcweb-firewall-00 =20 /Karl =20 PS: Regarding the TURN Origin debate, I don=E2=80=99t have a clear view, = but am I not right in the understanding that: * The purpose of the TURN Origin draft was to reduce the pain of WebRTC = service providers having to deploy network hardware (the Application = Provided TURN server) to get their services used, by allowing the TURN = server to serve many applications (through a third party).=20 - The introduction of Border TURN servers releases WebRTC service = providers of that pain (when commonly deployed) (and also put security = back in the right place) (Until deployed commonly, yes these SPs = unfortunately have this pain to =E2=80=9Cfool their services=E2=80=9D = through users security devices =E2=80=93 the firewalls (something which = the discussed 3 drafts now finally can remedy (without the use of = Origin)) * However, the Application Provided TURN server may also be for (from = the RETURN draft: 3 Goals, 3.2 independent path control):=20 o improving quality of service by tunneling packets through a = network that is faster than the public internet, + monitoring the usage of UDP services, + troubleshooting and debugging problematic services, + logging connection metadata for legal or auditing reasons, + recording the entire contents of all connections, or - providing partial IP address anonymization (as described in = [I-D.ietf-rtcweb-security] Section 4.2.4). (+ and =E2=80=93 indicates the conflicting impact the use Origin will = bring for the listed purposes) =20 The RETURN draft honors the application=E2=80=99s efforts to enforce = media through such Application Provided TURN server (without judging the = purpose) (by use of the Recursively Encapsulation mechanism). =20 My advice now is just to not introduce the Origin discussion in these = drafts where we finally have to resolve the firewall traversal problem = with real-time traffic. We need these RFCs in place as soon as ever = possible. I see a risk in that draft-jennings-behave-rtcweb-firewall-00 = starts discussing Origin/SNI in an effort to make a pretty secure WebRTC = aware firewall somewhat more secure, and think the draft can advice = firewall vendors how to build firewalls that are fully secure and allows = real-time traffic and should also be able to provide a quality pipe for = the real-time traffic. Origin/SNI is not required for that. The Border = TURN server and this RETURN-draft will make that possible. =20 -- > Don=E2=80=99t forget the inline below -- > =20 Fr=C3=A5n: Benjamin Schwartz [mailto:bemasc@webrtc.org]=20 Skickat: den 14 juli 2015 03:16 Till: Karl Stahl Kopia: rtcweb@ietf.org; tram@ietf.org =C3=84mne: Re: [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, = Configuration and TURN discovery: =20 On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl = wrote: We need this draft implemented in WebRTC browsers as soon as possible, = so we can get good WebRTC in difficult places (for firewall traversal and for quality). Is there any implementation e.g. in Chrome that can be tried? Now having stated that I am positive to this draft, I have some concerns/questions/suggestions: 1) We need more levels than sealed/leaky It is not acceptable that WebRTC traffic between parties on a typical = LAN is forced through a TURN server, just because of a sealed configuration required for good WebRTC traffic over the WAN. This consequence is = pointed out under "5.11. Reusing the same TURN server", but IS a problem even = if it "work as expected". Such TURN resource consumption, waste of bandwidth and possible = performance degradation do not happen today, and can easily be avoided. I realize this consequence of "sealed" is required to meet some of the requirements under "3.2. Independent Path Control", but we simply need = an "exo-sealed" level, in addition to the proposed strictly sealed and = leaky, allowing local endpoints to connect media directly, while external = traffic is forced to use the TURN server (rather than STUN through the default gateway). =20 [BS] How do you propose to tell what is "local"? I don't know how to = define that procedurally. =20 [BS] I think my main concern here is that it requires us to "lie" to the = remote party, by sending candidates that we may then refuse to use even = if they work. This seems very strange. =20 [Karl] You are right. I assumed the preferred exo-sealed behavior could = be achieved as easily as we do it =E2=80=9Chardware wise=E2=80=9D today = on the inside of our open test-site https://webrtc.ingate.com where we = have a border placed TURN server paralleling our firewall/default = gateway. Our firewall looks for the magic STUN cookie and discards all = STUN packets from the LAN side. TURN is then automatically enforced and = today=E2=80=99s leaky WebRTC browsers automatically get the preferred = exo-sealed behavior. =20 (Just not using STUN in the browser, would have the same effect but not = fully, if there are more subnets on the LAN side. Crossing those subnets = would then take media through the dual trip via the TURN server that I = want to avoid.) =20 So, let=E2=80=99s enforce the preferred exo-sealed configuration by = configuration of the firewall/default gateway (Security from this = perspective is then also in the right hands - the network = admin=E2=80=99s):=20 - Today=E2=80=99s RETURN-draft=E2=80=99s leaky default configuration is = OK (since the firewalls discarding STUN automatically enforce the = preferred exo-sealed behavior) - Recommend in the RETURN-draft (and in = draft-jennings-behave-rtcweb-firewall-00) that the network admin = discards STUN packets from the LAN side through the default gateway = (consent STUNs will go OK through the TURN server), by looking for the = magic STUN cookie, by closing port 3478 or by closing all UDP (the = restrictive enterprise firewall can simply be left as it is) to achieve = exo-sealed leakiness.=20 - The network admin offers a Border TURN server for its network users = (LAN side only) =E2=80=93 no need for authentication (free to use from = LAN side being a Border TURN server configuration)=20 - The Border TURN server is offered by the network you are using = =E2=80=93 Just use it! (should the network provider have evil = intentions, he needs no TURN server, he can simply close or destroy = WebRTC in the firewall if he which, which Cullen just exemplified in = draft-jennings-behave-rtcweb-firewall-00) =20 As you may have noticed, I stress that NO credentials should be needed = for using an auto discovered border TURN server. That is also the goal = of TRAM=E2=80=99s discovery draft, but I have asked TRAM to clarify = that achievement. If we don=E2=80=99t fix that, we have failed to make = WebRTC usable on mobile devices =E2=80=93 or can anyone explain where we = would get those credentials from when we run around and have Web access = here and there and the goal of WebRTC was to use real-time = communication, securely and with high quality, everywhere we can surf, = wasn=E2=80=99t it?=20 =20 If anyone cries that we NEED AUTHENTICATION, they should remember the IP = authentication (simply being on a certain network) is the most commonly = used =E2=80=9Cauthentication method=E2=80=9D today and protecting huge = values (almost the whole telco industry) and also achieves privacy = (through the use of firewalls). No individual user credentials which are = impossible to handle must be required. =20 I will in next email propose this new variant of the Anycast method to = TRAM. It should work, shouldn=E2=80=99t it? And does it provide the claimed advantages/features? =E2=80=93 please = check. =20 Implicit discovery by interception of TURN allocate requests at a = default gateway =20 An enterprise firewall or a network server provider=E2=80=99s router at = a default gateway can intercept a TURN allocate request and respond with = a 300 (Try Alternate) just as described in the Anycast method above. The = following procedures and advantages are inherited from the anycast = method. =20 This variant adds the following features: - no separate deployment of discovery mechanism is required - no ANA allocated anycast address is required (works with any public ip = address)=20 - the default gateway router/firewall in charge of the local network = responds with the ip address of: (i) a Border TURN server (paralleling the default gateway), or=20 (ii) a TURN server behind that firewall/default gateway and opens a = path to that TURN server =20 - if the intercepted allocate request was intended for an application = provided TURN server, the TURN client (e.g. WebRTC browser) on behalf of = the user, can select to: (iii) only use the auto discovered TURN server (iv) honor an allocation request by really sending the real-time = traffic to the Application Provided TURN server, using the Recursively = Encapsulated method, unless (v) the TURN server connected in (ii) already is the Application = Provided TURN server =20 Security wise, the right party is in charge in all cases. A TURN server pinpointed by a firewall/router at the default gateway = should always be trusted (no explicit authentication with credentials is = needed) and used. (We trust the default gateway with all our traffic = anyway, and any evil intent to disturb real-time traffic can in such = case be implemented in a default gateway by easier means.) =20 =20 Such "exo-sealed" configuration should be the default configuration if a network provided TURN server is made available for good (non-evil) = purposes. 2) Mobile devices need to work on various networks, without individual configuration I am not clear about the thoughts behind the "configuration" of sealed = level and requirements for authentication of the turn server, but if there are methods where an enterprise network (LAN) admin can provide credentials = and force a certain sealed level upon the WebRTC-browser when used at that = LAN, or if the user has the possibility to configure manually, I am OK with = that this can and should OVERRIDE any default configuration or other configuration (on that particular network). However, for mobile devices - Don't we all happily connect our browsers = via WiFi here and there? - there must be a way for a network provider with a good intent to offer an exo-sealed TURN server that automatically should = be used, e.g. to achieve the purpose of offering better RTC quality than is available through the default gateway WAN path on that network. A network provided TURN-server can easily be made available ONLY to the network users that it is serving, so there is no need for authentication = and credentials to protect against illegal usage of a valuable resource, = like it is with the application provided turn server. Network provided TURN = servers are simply deployed for the network users to be use without other authentication than being granted an IP address and a default gateway to = use on that particular network in itself. The same goes for trusting the TURN server with our real-time traffic - = If we would trust the same network provider with the same real-time traffic through the default gateway - we should also use the offered TURN server without other "authentication" than that it is available on our network: Data through the default gateway, RTC through the TURN path is why the = TURN server is provided! But do we know that it is not someone with the evil purpose of stealing = our (encrypted!) real time traffic that is offering the TURN server (instead = of the network provider), which leads us to my point 3). (If we really = think there is a risk of and danger with such attacks...) 3) Is it now good enough to simply use the auto discovered TURN server? = Hope so! There has been some recent improvements to draft-ietf-tram-turn-server-discovery-03 and hopefully that is = sufficient for assuming that the auto-discovered TURN server is offered by our = network provider (a service provider or the enterprise itself) that we trust = anyway, and the TURN server then simply shall be used and considered exo-sealed. (The current RETURN draft says a non configured TURN server should be leaky.) =20 The security considerations in that document suggest that not all = discovery mechanisms have equal additional exposure to local network = interference. I would appreciate clearer guidance on that front. It = seems to me that DHCP is the only listed mechanism that creates minimal = additional exposure to network interference. =20 --- I am addressing TRAM about this and believe that the variant of the = Anycast method I suggest to be added, will fully resolve all security = concerns. I am also suggesting that it is up to this RTCWEB draft to = select from TRAM=E2=80=99s methods and advices for the WebRTC = application and its use cases. =20 --- See my deployment concerns regarding DHCP put in front of TRAM. I = think that the Anycast method with a short TTL-limitation is good enough = from the privacy aspect, when used to find Border TURN server. =20 --- Even though the new variant I propose is more secure and even easier = to deploy, I suggest that this RETURN draft mandates the use of the both = the Anycast method and its new variant. The reason is that already = today, all routers/firewalls at a default gateways can add the anycast = route required for discovery, while intercepting the TURN allocate = request and responding with the Try Alternate server probably requires a = software upgrade of installed firewalls and routers with default = gateways (a firewall in front of the default gateway can also do the = interception and response).=20 =20 Some concerns regarding the DISCOVERY draft and whether these things = should be specified in the RETURN document: - Is the above the case with all discovery methods proposed? Or shall = the RETURN document make one method mandatory to implement? - Can that method then be the Anycast method (which by far seems to be = the most convenient to deploy and to implement and should work for all = network types and in all devices operating systems). I think what is said under "9.3. Anycast" under "9. Security Considerations" is sufficient for trusting such discovered TURN server. What should then go into the = RETURN draft - or should the DISCOVERY draft be more specific? I don't fully understand the DISCOVERY draft's: "... three discovery mechanisms. The reason for providing multiple mechanisms is to maximize = the opportunity for discovery," - Can we really put the burden upon all WebRTC devices to implement all methods and I doubt network providers will deploy more than one method. = That seems risking rather than maximizing discovery... It is high time to get this done - can we? /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r = internet-drafts@ietf.org Skickat: den 14 maj 2015 00:29 Till: i-d-announce@ietf.org Kopia: rtcweb@ietf.org =C3=84mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. Title : Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC Authors : Benjamin M. Schwartz Justin Uberti Filename : draft-ietf-rtcweb-return-00.txt Pages : 18 Date : 2015-05-13 Abstract: In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-return-00 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------=_NextPart_000_0216_01D0C260.BF6F3650 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Be= njamin =E2=80=93 your concern is valid =E2=80=93 I thought exo-sealed = was easy to do in the browser.

 

Be= low I list a firewall configuration assisted method to address the TURN = server and bandwidth resource consumption problem for local WebRTC calls = when using the sealed configuration. I believe my suggestion also will = meet all security/trust/privacy perspectives and give secure = auto-configuration, so mobile devices can to be used with high-quality = secure WebRTC communication =E2=80=9Ceverywhere you can surf=E2=80=9D = =C2=A0through proper use of Border TURN servers - which must be the = (almost already achieved) purpose of this RETURN = draft.

 

Af= ter some consideration, to achieve the preferred exo-sealed = configuration, the RETURN drafts already prescribes the best default = configuration: =E2=80=9Cleaky=E2=80=9D ! :-)

Ex= planations inline below -->

 

Be= low are also some suggestions for inclusion in the = drafts:

draft-ietf-tr= am-turn-server-discovery-03

draft-jenning= s-behave-rtcweb-firewall-00

 

/K= arl

 

PS= : Regarding the TURN Origin debate, I don=E2=80=99t have a clear view, = but am I not right in the understanding that:

* = The purpose of the TURN Origin draft =C2=A0was to reduce the pain of = WebRTC service providers having to deploy network hardware (the = Application Provided TURN server) to get their services used, by = allowing the TURN server to serve many applications (through a third = party).

=C2= =A0- The introduction of Border TURN servers releases WebRTC service = providers of that pain (when commonly deployed) (and also put security = back in the right place) (Until deployed commonly, yes these SPs = unfortunately have this pain to =E2=80=9Cfool their services=E2=80=9D = through users security devices =E2=80=93 the firewalls (something which = the discussed 3 drafts now finally can remedy (without the use of = Origin))

* = However, the Application Provided TURN server may also be for (from the = RETURN draft: 3 Goals, 3.2 independent path control): =

=C2= =A0=C2=A0=C2=A0o=C2=A0 improving quality of service by tunneling packets = through a network that is faster than the public = internet,

=C2= =A0=C2=A0 +=C2=A0 monitoring the usage of UDP = services,

=C2= =A0=C2=A0 +=C2=A0 troubleshooting and debugging problematic = services,

=C2= =A0=C2=A0 +=C2=A0 logging connection metadata for legal or auditing = reasons,

=C2= =A0=C2=A0 +=C2=A0 recording the entire contents of all connections, = or

=C2= =A0=C2=A0 -=C2=A0 providing partial IP address anonymization (as = described in [I-D.ietf-rtcweb-security] Section = 4.2.4).

(+= and =E2=80=93 indicates the conflicting impact the use Origin will = bring for the listed purposes)

 

Th= e RETURN draft honors the application=E2=80=99s efforts to enforce media = through such Application Provided TURN server (without judging the = purpose) (by use of the Recursively Encapsulation = mechanism).

 

My= advice now is just to not introduce the Origin discussion in these = drafts where we finally have to resolve the firewall traversal problem = with real-time traffic. We need these RFCs in place as soon as ever = possible. I see a risk in that draft-jenning= s-behave-rtcweb-firewall-00 starts discussing = Origin/SNI in an effort to make a pretty secure WebRTC aware firewall = somewhat more secure, and think the draft can advice firewall vendors = how to build firewalls that are fully secure and allows real-time = traffic and should also be able to provide a quality pipe for the = real-time traffic. Origin/SNI is not required for that. The Border TURN = server and this RETURN-draft will make that = possible.

 

--= > Don=E2=80=99t forget the inline below -- = >

 

Fr=C3=A5n: Benjamin = Schwartz [mailto:bemasc@webrtc.org]
Skickat: den 14 juli 2015 = 03:16
Till: Karl Stahl
Kopia: rtcweb@ietf.org; = tram@ietf.org
=C3=84mne: Re: [rtcweb] = draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN = discovery:

 

On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

We need this draft implemented in WebRTC browsers as = soon as possible, so we
can get good WebRTC in difficult places (for = firewall traversal and for
quality). Is there any implementation e.g. = in Chrome that can be tried?

Now having stated that I am positive = to this draft, I have some
concerns/questions/suggestions:

1) = We need more levels than sealed/leaky

It is not acceptable that = WebRTC traffic between parties on a typical LAN is
forced through a = TURN server, just because of a sealed configuration
required for good = WebRTC traffic over the WAN. This consequence is pointed
out under = "5.11.  Reusing the same TURN server", but IS a problem = even if it
"work as expected".

Such TURN resource = consumption, waste of bandwidth and possible performance
degradation = do not happen today, and can easily be avoided.

I realize this = consequence of "sealed" is required to meet some of = the
requirements under "3.2.  Independent Path = Control", but we simply need an
"exo-sealed" level, in = addition to the proposed strictly sealed and leaky,
allowing local = endpoints to connect media directly, while external traffic
is forced = to use the TURN server (rather than STUN through the = default
gateway).

 

[BS] = How do you propose to tell what is = "local"?  I don't know how to define that = procedurally.

 

[BS] = I think my main concern here is that it = requires us to "lie" to the remote party, by sending = candidates that we may then refuse to use even if they work.  = This seems very strange.

 

[K= arl] You are right. I assumed the preferred exo-sealed behavior could be = achieved as easily as we do it =E2=80=9Chardware wise=E2=80=9D today on = the inside of our open test-site https://webrtc.ingate.com where = we have a border placed TURN server paralleling our firewall/default = gateway. Our firewall looks for the magic STUN cookie and discards all = STUN packets from the LAN side. TURN is then automatically enforced and = today=E2=80=99s leaky WebRTC browsers automatically get the preferred = exo-sealed behavior.

 

(J= ust not using STUN in the browser, would have the same effect but not = fully, if there are more subnets on the LAN side. Crossing those subnets = would then take media through the dual trip via the TURN server that I = want to avoid.)

 

So= , let=E2=80=99s enforce the preferred exo-sealed configuration by = configuration of the firewall/default gateway (Security from this = perspective is then also in the right hands - the network = admin=E2=80=99s):

- = Today=E2=80=99s RETURN-draft=E2=80=99s leaky default configuration is OK = (since the firewalls discarding STUN automatically enforce the preferred = exo-sealed behavior)

- = Recommend in the RETURN-draft (and in draft-jenning= s-behave-rtcweb-firewall-00) =C2=A0that the = network admin discards STUN packets from the LAN side through the = default gateway (consent STUNs will go OK through the TURN server), by = looking for the magic STUN cookie, by closing port 3478 or by closing = all UDP (the restrictive enterprise firewall can simply be left as it = is) to achieve exo-sealed leakiness.

- = The network admin offers a Border TURN server for its network users (LAN = side only) =E2=80=93 no need for authentication (free to use from LAN = side being a Border TURN server configuration)

- = The Border TURN server is offered by the network you are using =E2=80=93 = Just use it! (should the network provider have evil intentions, he needs = no TURN server, he can simply close or destroy WebRTC in the firewall if = he which,=C2=A0 which Cullen just exemplified in draft-jenning= s-behave-rtcweb-firewall-00)

 

As= you may have noticed, I stress that NO credentials should be needed for = using an auto discovered border TURN server. That is also the goal of = TRAM=E2=80=99s discovery draft, but I have asked TRAM =C2=A0to clarify = that achievement. If we don=E2=80=99t fix that, we have failed to make = WebRTC usable on mobile devices =E2=80=93 or can anyone explain where we = would get those credentials from when we run around and have Web access = here and there and the goal of WebRTC was to use real-time = communication, securely and with high quality, everywhere we can surf, = wasn=E2=80=99t it?

 

If= anyone cries that we NEED AUTHENTICATION, they should remember the IP = authentication (simply being on a certain network) is the most commonly = used =E2=80=9Cauthentication method=E2=80=9D today and protecting huge = values (almost the whole telco industry) and also achieves privacy = (through the use of firewalls). No individual user credentials which are = impossible to handle must be required.

 

I = will in next email propose this new variant of the Anycast method = =C2=A0to TRAM. It should work, shouldn=E2=80=99t = it?

An= d does it provide the claimed advantages/features? =E2=80=93 please = check.

 

Implicit discovery by interception = of TURN allocate requests at a default = gateway

 

An enterprise firewall = or a network server provider=E2=80=99s router at a default gateway can = intercept a TURN allocate request and respond with a 300 (Try Alternate) = just as described in the Anycast method above. The following procedures = and advantages are inherited from the anycast = method.

 

This variant adds the following features:

- no separate deployment of discovery mechanism is = required

- no ANA allocated anycast address = is required (works with any public ip address)

- the default gateway router/firewall in charge of the local = network responds with the ip address of:

(i) =C2=A0=C2=A0a Border TURN server (paralleling the default = gateway), or

(ii) =C2=A0a TURN = server behind that firewall/default gateway and opens a path to that = TURN server =C2=A0

- if the intercepted = allocate request was intended for an application provided TURN server, = the TURN client (e.g. WebRTC browser) on behalf of the user, can select = to:

(iii) only use the auto discovered = TURN server

(iv) =C2=A0honor an = allocation request by really sending the real-time traffic to the = Application Provided TURN server, using the Recursively Encapsulated = method, unless

(v) =C2=A0=C2=A0the = TURN=C2=A0 server connected in (ii) already is the Application Provided = TURN server

 

Security wise, the = right party is in charge in all cases.

A TURN server pinpointed by a firewall/router at the default = gateway should always be trusted (no explicit authentication with = credentials is needed) and used. (We trust the default gateway with all = our traffic anyway, and any evil intent to disturb real-time traffic can = in such case be implemented in a default gateway by easier = means.)

 

 

Such "exo-sealed" configuration should be the = default configuration if a
network provided TURN server is made = available for good (non-evil) purposes.


2) Mobile = devices need to work on various networks, without = individual
configuration

I am not clear about the thoughts = behind the "configuration" of sealed level
and requirements = for authentication of the turn server, but if there are
methods where = an enterprise network (LAN) admin can provide credentials and
force a = certain sealed level upon the WebRTC-browser when used at that = LAN,
or if the user has the possibility to configure manually, I am = OK with that
this can and should OVERRIDE any default configuration = or other
configuration (on that particular network).

However, = for mobile devices - Don't we all happily connect our browsers = via
WiFi here and there? - there must be a way for a network provider = with a
good intent to offer an exo-sealed TURN server that = automatically should be
used, e.g. to achieve the purpose of offering = better RTC quality than is
available through the default gateway WAN = path on that network.

A network provided TURN-server can easily = be made available ONLY to the
network users that it is serving, so = there is no need for authentication and
credentials to protect = against illegal usage of a valuable resource, like it
is with the = application provided turn server. Network provided TURN servers
are = simply deployed for the network users to be use without = other
authentication than being granted an IP address and a default = gateway to use
on that particular network in itself.

The same = goes for trusting the TURN server with our real-time traffic - If
we = would trust the same network provider with the same real-time = traffic
through the default gateway - we should also use the offered = TURN server
without other "authentication" than that it is = available on our network:
Data through the default gateway, RTC = through the TURN path is why the TURN
server is provided!

But = do we know that it is not someone with the evil purpose of stealing = our
(encrypted!) real time traffic that is offering the TURN server = (instead of
the network provider), which leads us to my point 3). (If = we really think
there is a risk of and danger with such = attacks...)


3) Is it now good enough to simply use the auto = discovered TURN server? Hope
so!

There has been some recent = improvements to
draft-ietf-tram-turn-server-discovery-03 and = hopefully that is sufficient
for assuming that the auto-discovered = TURN server is offered by our network
provider (a service provider or = the enterprise itself) that we trust anyway,
and the TURN server then = simply shall be used and considered exo-sealed.
(The current RETURN = draft says a non configured TURN server should = be
leaky.)

 

The security considerations in that document suggest = that not all discovery mechanisms have equal additional exposure to = local network interference.  I would appreciate clearer guidance on = that front.  It seems to me that DHCP is the only listed mechanism = that creates minimal additional exposure to network = interference.

 

--= - I am addressing TRAM about this and believe that the variant of the = Anycast method I suggest to be added, will fully resolve all security = concerns. I am also suggesting that it is up to this RTCWEB draft to = select from TRAM=E2=80=99s methods and advices for the WebRTC = application and its use cases.

 

--= - See my deployment concerns regarding DHCP put in front of TRAM. I = think that the Anycast method with a short TTL-limitation is good enough = from the privacy aspect, when used to find Border TURN = server.

 

--= - Even though the new variant I propose is more secure and even easier = to deploy, I suggest that this RETURN draft mandates the use of the both = the Anycast method and its new variant. The reason is that already = today, all routers/firewalls at a default gateways can add the anycast = route required for discovery, while intercepting the TURN=C2=A0 allocate = request and responding with the Try Alternate server probably requires a = software upgrade of installed =C2=A0firewalls and routers with default = gateways (a firewall in front of the default gateway can also do the = interception and response).

 

Some concerns = regarding the DISCOVERY draft and whether these things should
be = specified in the RETURN document:

- Is the above the case with = all discovery methods proposed? Or shall the
RETURN document = make one method mandatory to implement?

- Can that method then be = the Anycast method (which by far seems to be the
most convenient to = deploy and to implement and should work for all network
types and in = all devices operating systems). I think what is said = under
"9.3.  Anycast" under "9.  Security = Considerations" is sufficient for
trusting such discovered TURN = server. What should then go into the RETURN
draft - or should the = DISCOVERY draft be more specific?

I don't fully understand the = DISCOVERY draft's: "... three discovery
mechanisms. The reason = for providing multiple mechanisms is to maximize the
opportunity for = discovery,"

- Can we really put the burden upon all WebRTC = devices to implement all
methods and I doubt network providers will = deploy more than one method. That
seems risking rather than = maximizing discovery...


It is high time to get this done - = can we?

/Karl



-----Ursprungligt = meddelande-----
Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r internet-drafts@ietf.org
Skickat: den 14 maj = 2015 00:29
Till: i-d-announce@ietf.org
Kopia: rtcweb@ietf.org
=C3=84mne: [rtcweb] I-D Action: = draft-ietf-rtcweb-return-00.txt


A New Internet-Draft is = available from the on-line Internet-Drafts
directories.
 This = draft is a work item of the Real-Time Communication in = WEB-browsers
Working Group of the IETF.

      =   Title           : Recursively = Encapsulated TURN (RETURN) for
Connectivity and Privacy in = WebRTC
        Authors        =  : Benjamin M. Schwartz
          =                 Justin = Uberti
        Filename      =   : draft-ietf-rtcweb-return-00.txt
        = Pages           : 18
    =     Date            : = 2015-05-13

Abstract:
   In the context of WebRTC, = the concept of a local TURN proxy has been
   suggested, = but not reviewed in detail.  WebRTC applications are
  =  already using TURN to enhance connectivity and privacy.  = This
   document explains how local TURN proxies and WebRTC = applications can
   work together.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-retu= rn/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-return-00=


Please note that it may take a couple of minutes from = the time of submission
until the htmlized version and diff are = available at tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

________= _______________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 

------=_NextPart_000_0216_01D0C260.BF6F3650-- From nobody Mon Jul 20 04:43:35 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A7F1A21A4 for ; Mon, 20 Jul 2015 04:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McYI307tbcYs for ; Mon, 20 Jul 2015 04:43:31 -0700 (PDT) Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3167B1A1DBC for ; Mon, 20 Jul 2015 04:43:31 -0700 (PDT) Received: by ykay190 with SMTP id y190so136228553yka.3 for ; Mon, 20 Jul 2015 04:43:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=he1aQkE4imbtf08hpN79+W2EbKZIEWHmPKgAdcFDQ74=; b=YmVvsMe0Y2hlgPIzZTi9DuomKrjqpWiWgWgyBIBebfsPpg3BECtwS23CDEqElTNwMb eVdP+d2Mt4eiCFJobfFtvPWrlGyQRdHVR6X4Huq7LPkneOQG+3z7Fu1nihC028K+xa++ u4f0epQHJp4LXw8gHD7YeVhsxWTYn7I13VJ41MZTJ7xFGbwKJ59JIpH7D1SgNueAVgVP VpwTyWF76nLVHqOhufyYHpw1FfSZ3J8pa67YMOuaPBUYTc3DPD/IY57oQ177mcChFr5Z UexKlaIdiYjptxmC/4jZiUaU/y+q9NlweCO6SSMYgGOEJ7AKa1vT/GSTsEY954LcimdT LDcA== X-Gm-Message-State: ALoCoQmCUZDSoazFJfSkEd/CXg1391pZS8WEkY5bOr8uo7aqhwqRUuKJpwyAT+Y7NzvP8sdbR4yW X-Received: by 10.13.255.2 with SMTP id p2mr10726160ywf.149.1437392610583; Mon, 20 Jul 2015 04:43:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Mon, 20 Jul 2015 04:43:10 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Jul 2015 13:43:10 +0200 Message-ID: To: Tim Panton Content-Type: multipart/alternative; boundary=94eb2c0888f6f5129d051b4d0b2d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:43:33 -0000 --94eb2c0888f6f5129d051b4d0b2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-07-20 13:37 GMT+02:00 Tim Panton : > E.g. I=E2=80=99m at home and my chromebook pixel (or firefox tablet) is o= n wifi, > but I=E2=80=99ve left LTE enabled. > I (or the OS) is configured to prefer wifi wen available - but it happens > that for a specific peer LTE completes first. > So now my video call goes over LTE without my say-so and with no hint thi= s > is happening - costing me real > money. My only option is to completely disable LTE when I get home (and > lose SMS too) ? > Exactly. Setting the default network route should be enough to avoid that and to ensure a global network policy for the whole OS, unless an app (the browser) plays to be God. --=20 I=C3=B1aki Baz Castillo --94eb2c0888f6f5129d051b4d0b2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015= -07-20 13:37 GMT+02:00 Tim Panton <thp@westhawk.co.uk>:
=
E.g. I=E2=80=99m at home and my chromeb= ook pixel (or firefox tablet) is on wifi, but I=E2=80=99ve left LTE enabled= .
I (or the OS) is configured to prefer wifi wen available - but = it happens that for a specific peer LTE completes first.
So now m= y video call goes over LTE without my say-so and with no hint this is happe= ning =C2=A0- costing me real
money. My only option is to complete= ly disable LTE when I get home =C2=A0(and lose SMS too) ?

Exactly.

Setting the default network route should be enough to avoid t= hat and to ensure a global network policy for the whole OS, unless an app (= the browser) plays to be God.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
--94eb2c0888f6f5129d051b4d0b2d-- From nobody Mon Jul 20 05:23:18 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE201A21B4 for ; Mon, 20 Jul 2015 05:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2APkVkLDQcnZ for ; Mon, 20 Jul 2015 05:23:13 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0221A8028 for ; Mon, 20 Jul 2015 05:23:12 -0700 (PDT) Received: (qmail 22561 invoked from network); 20 Jul 2015 12:23:11 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 8130 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 20 Jul 2015 12:23:11 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1519118A1EEB; Mon, 20 Jul 2015 13:23:09 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id F060318A119C; Mon, 20 Jul 2015 13:23:08 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_627FF319-1132-431E-B675-8EA86B9B71BD" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Panton In-Reply-To: <20150716084225.GA29652@lo.psyced.org> Date: Mon, 20 Jul 2015 13:23:08 +0100 Message-Id: <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> To: carlo von lynX X-Mailer: Apple Mail (2.2102) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 12:23:17 -0000 --Apple-Mail=_627FF319-1132-431E-B675-8EA86B9B71BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Jul 2015, at 09:42, carlo von lynX = > = wrote: >=20 > Yes, I dare to speak out of my 25 years of experience on the > Internet even if I didn't have to use much VPN ever. I can > imagine plenty of constellations where the VPN is NOT supposed > to take over all communications on the system but rather offer > a side route into a company's servers or suchlike. Therefore > I worry if the software provider can always come up with a > configuration that still does what the customers expect and > at the same time deals with the new backdoor introduced by WebRTC. > Of course anyone with better understanding can help clear up > these worries. >=20 >> That isn=E2=80=99t what I meant. I expect secure software providers = to keep their >> software abreast of new developments.=20 It turns out that I was completely wrong. The browsers are currently so=20= thorough in their discovery of available interfaces and routes that no amount of changes by the sys admin or VPN supplier will fix this = problem. Sorry about that.=20 >=20 > Uh, not sure if that is an established pattern in the industry. > Usually somebody does whatever fits into their business model > best, then there is a public outcry and possibly some bloodspill, > then all the players look at how they can make a good impression > by reducing the collateral damages.. but if that doesn't work out > cheap and easy.. tant pis. Let's continue with business. >=20 >> I happen to have the (no doubt under informed) opinion that >> this isn=E2=80=99t as simple as it has been made out to be. At least I was right here. - It is even more complex than I believed. >=20 > Well, in case of doubt it is important to pick the conservative > option until the issue is properly analyzed rather than hoping > for the general public to forget about the problem. >=20 >>> Also the "solution" you suggest AFAIU does not work for people >>> who use Tor in a non-NATted environment, for example on a >>> fixed system in a university library with a static IP address. >>=20 >> That is an interesting case. In that instance hiding the local IP = would be=20 >> valuable. I thought however those users would normally run a TOR os = off=20 >> a usb stick in a VM. That would probably mask the local IP. >=20 > Now that this is more clear, have another look at my original mail > that describes how such a dissident would use any Windows OS system > standing around. I doubt anything advanced like TAILS sticks are > out there as merely possessing one could be life-threatening. Here too I find that I was wrong and the current situation not what I = assumed and is unsatisfactory. Most SOCKS proxies don't have support for ICE/STUN nor arbitrary UDP. The current browser implementations (backed by the ICE spec) take the = view that if SOCKS doesn=E2=80=99t do UDP, then they should go directly and send = UDP anyhow. I=E2=80=99m not clear that this is what a user might expect.=20 An alternative might be to detect a proxy config _only_ offer TURN over = TLS=20 candidates (and route the traffic over the proxy) - This would result in poor audio/video but would be more in keeping with the spirit of the = proxy config. (a variant might be to inspect the proxy in detail and use the address = whitelists to filter allowed traffic somehow?)=20 >>=20 >> I totally agree. My solution is imho a better fix, since it >> also protects against many other apps that might get started from >> a browser page (email, dns, ipv6 tunnels, flash, mp3 players etc). Turns out I was wrong - sigh - as I said the browsers are more = aggressive in finding routes than I assumed (or indeed than my ICE implementations = are). > Breaking the proxy principle is neither a Tor nor a VPN problem. > It's just browser vendors breaking a promise given to users that > configured proxies would be respected. >=20 >> I=E2=80=99m SOCKs ignorant. >=20 > So we all have our knowledge deficiencies... > good to be honest about them. >=20 And now that I=E2=80=99ve educated myself somewhat, I=E2=80=99m agreeing = with you. >>> And if local IP information is so super harmless, then why is it >>> an obvious reason for TBB devs to disable the entire thing? >>> I presume for the reasons I stated before. >>=20 >> I have no idea, but I fear it is because no one has split these = issues out. >=20 > So let's dissect some more until we know what we are doing. Which turns out to be the only useful contribution my made. >=20 >> I=E2=80=99m of the view that there are _useful_ instances of P2P = crypto >> in-browser - we will clearly have to disagree about that. >=20 > I think we could improve the user's ability to ensure end-to-end > authentication beyond server-based negotiation. Something like > rendering persistent public keys into QR codes and having people > exchange those QR codes at cocktail parties and hackathons. >=20 > Servers would still be able to provide the signaling code, but users > would be granted a guarantee that the E2E connection is authentic. >=20 https://yopet.us :-)=20 Tim.= --Apple-Mail=_627FF319-1132-431E-B675-8EA86B9B71BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 16 Jul 2015, at 09:42, carlo von lynX = <lynX@i.know.you.are.psyced.org> wrote:

Yes, I dare to speak out of my 25 years of = experience on the
Internet even if I didn't have to use = much VPN ever. I can
imagine plenty of constellations = where the VPN is NOT supposed
to take over all = communications on the system but rather offer
a side route = into a company's servers or suchlike. Therefore
I worry if = the software provider can always come up with a
configuration that still does what the customers expect = and
at the same time deals with the new backdoor = introduced by WebRTC.
Of course anyone with better = understanding can help clear up
these worries.

That = isn=E2=80=99t what I meant. I expect secure software providers to keep = their
software abreast of new developments. 

It turns out that I was completely = wrong. The browsers are currently so 
thorough = in their discovery of available interfaces and routes that no
amount of changes by the sys admin or VPN supplier will fix = this problem.

Sorry about that. 


Uh, not sure if = that is an established pattern in the industry.
Usually = somebody does whatever fits into their business model
best, = then there is a public outcry and possibly some bloodspill,
then all the players look at how they can make a good = impression
by reducing the collateral damages.. but if = that doesn't work out
cheap and easy.. tant pis. Let's = continue with business.

I happen to have the (no doubt under informed) = opinion that
this isn=E2=80=99t as simple as it has been = made out to be.

At least I was right = here. - It is even more complex than I believed.


Well, in case of doubt it is important to pick the = conservative
option until the issue is properly analyzed = rather than hoping
for the general public to forget about = the problem.

Also the "solution" you = suggest AFAIU does not work for people
who use Tor in a = non-NATted environment, for example on a
fixed system in a = university library with a static IP address.

That is an interesting case. In = that instance hiding the local IP would be 
valuable. = I thought however those users would normally run a TOR os off 
a usb stick in a VM. That would probably mask the local = IP.

Now that this is more = clear, have another look at my original mail
that = describes how such a dissident would use any Windows OS system
standing around. I doubt anything advanced like TAILS sticks = are
out there as merely possessing one could be = life-threatening.


Here= too I find that I was wrong and the current situation not what I = assumed
and is unsatisfactory.

Most SOCKS proxies don't = have support for ICE/STUN nor arbitrary UDP.
The = current browser implementations (backed by the ICE spec) take the view = that
if SOCKS doesn=E2=80=99t do UDP, then they = should go directly and send UDP anyhow.

I=E2=80=99m not clear that this is what = a user might expect. 
An alternative might be = to detect a proxy config _only_ offer TURN over TLS 
candidates (and route the traffic over the proxy) - This = would result in
poor audio/video but would be more = in keeping with the spirit of the proxy config.

(a variant might be to inspect the = proxy in detail and use the address whitelists
to = filter allowed traffic somehow?) 



I totally agree. My solution is imho a better = fix, since it
also protects against many other apps that = might get started from
a browser page (email, dns, ipv6 = tunnels, flash, mp3 players etc).


Turns out I was wrong - sigh - as I said the browsers are = more aggressive
in finding routes than I assumed = (or indeed than my ICE implementations are).

Breaking = the proxy principle is neither a Tor nor a VPN problem.
It's= just browser vendors breaking a promise given to users that
configured proxies would be respected.

I=E2=80=99m SOCKs = ignorant.

So we all have our = knowledge deficiencies...
good to be honest about them.


And now that I=E2=80=99ve educated = myself somewhat, I=E2=80=99m agreeing with you.


And if local IP information is so super harmless, then why is = it
an obvious reason for TBB devs to disable the entire = thing?
I presume for the reasons I stated before.

I have no idea, but I fear it is = because no one has split these issues out.

So let's dissect some more until we know what we are = doing.

Which turns out to be the only useful = contribution my <rant/> made.



I=E2=80=99m= of the view that there are _useful_ instances of P2P crypto
in-browser - we will clearly have to disagree about that.

I think we could improve the = user's ability to ensure end-to-end
authentication beyond = server-based negotiation. Something like
rendering = persistent public keys into QR codes and having people
exchange those QR codes at cocktail parties and = hackathons.

Servers would still be able to = provide the signaling code, but users
would be granted a = guarantee that the E2E connection is authentic.


https://yopet.us :-) 

Tim.
= --Apple-Mail=_627FF319-1132-431E-B675-8EA86B9B71BD-- From nobody Mon Jul 20 05:26:09 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F051A7007 for ; Mon, 20 Jul 2015 05:26:08 -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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc7M-Px978Oe for ; Mon, 20 Jul 2015 05:26:06 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C831A6FFC for ; Mon, 20 Jul 2015 05:26:05 -0700 (PDT) Received: (qmail 36903 invoked from network); 20 Jul 2015 12:26:04 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 8228 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 20 Jul 2015 12:26:04 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1BB4B18A0FBC; Mon, 20 Jul 2015 13:26:01 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id EFC2218A0BC0; Mon, 20 Jul 2015 13:26:00 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_74E349CF-115B-4059-9709-97857FCA9E63" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Panton In-Reply-To: Date: Mon, 20 Jul 2015 13:26:00 +0100 Message-Id: <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.2102) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 12:26:08 -0000 --Apple-Mail=_74E349CF-115B-4059-9709-97857FCA9E63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Jul 2015, at 02:31, Martin Thomson = wrote: >=20 >=20 > On Jul 17, 2015 5:01 PM, "I=C3=B1aki Baz Castillo" > wrote: > > > > The point is that you don't even choose the interface. The OS will = do for you. >=20 > The OS can - and frequently does - get that wrong. The default route = can fail when another might succeed. >=20 > You can't allow that to happen if you care about connecting = successfully. >=20 Gulp. Whilst I mostly see the logic - it is wholly unexpected behaviour = to the average sys admin.=20 Certainly not what I expected. It strikes me that binding to all interfaces might well give a vector = for attackers to map out a company=E2=80=99s internal networks. It also may restrict the user=E2=80=99s ability to manipulate which = medium is used.=20 E.g. I=E2=80=99m at home and my chromebook pixel (or firefox tablet) is = on wifi, but I=E2=80=99ve left LTE enabled. I (or the OS) is configured to prefer wifi wen available - but it = happens that for a specific peer LTE completes first. So now my video call goes over LTE without my say-so and with no hint = this is happening - costing me real money. My only option is to completely disable LTE when I get home (and = lose SMS too) ? Perhaps we should default to binding to 0.0.0.0 and allow a user = config=E2=80=99d preference for more exhaustive searching. Tim. --Apple-Mail=_74E349CF-115B-4059-9709-97857FCA9E63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 18 Jul 2015, at 02:31, Martin Thomson <martin.thomson@gmail.com> wrote:


On Jul 17, 2015 5:01 PM, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote:
>
> The point is that you don't even choose the interface. The OS will = do for you.

The OS can - and frequently = does - get that wrong. The default route can fail when another might = succeed.

You can't allow that to happen if = you care about connecting successfully.

Gulp. Whilst I = mostly see the logic - it is wholly unexpected behaviour to the average = sys admin. 
Certainly not what I expected.

It strikes me that = binding to all interfaces might well give a vector for attackers to map = out a company=E2=80=99s internal networks.
It also may restrict the = user=E2=80=99s ability to manipulate which medium is = used. 

E.g. I=E2=80=99m at home and = my chromebook pixel (or firefox tablet) is on wifi, but I=E2=80=99ve = left LTE enabled.
I (or the OS) is configured to prefer wifi wen = available - but it happens that for a specific peer LTE completes = first.
So = now my video call goes over LTE without my say-so and with no hint this = is happening  - costing me real
money. My only option is to = completely disable LTE when I get home  (and lose SMS too) = ?

Perhaps we should default to binding to 0.0.0.0 and = allow a user config=E2=80=99d preference for more exhaustive = searching.

Tim.

= --Apple-Mail=_74E349CF-115B-4059-9709-97857FCA9E63-- From nobody Mon Jul 20 05:32:58 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B521A86FC for ; Mon, 20 Jul 2015 05:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTUU5n95kYT5 for ; Mon, 20 Jul 2015 05:32:55 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CEE91A86E4 for ; Mon, 20 Jul 2015 05:32:55 -0700 (PDT) Received: by wgav7 with SMTP id v7so63898905wga.2 for ; Mon, 20 Jul 2015 05:32:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5QWCg5ZCkZ6R40ITt6zz9tCmvVsqX6gCLiSh0zln0XU=; b=hzsrZ0OjHMZfm70Qy5RH26qgUDxlcuZj2nhM1BJL53oxATWH6AiI6lIYA1oVeZ+eMZ YZ3TPO0KinBeuLTNTU8iU2fCxggTaiE/hdQ5mRRpk5rO5AMLEx/OsavDwIdAVzOT7mwe rCnZ8oW5yZLyvvzb5KznHKipptsrb3oPHHXD389bIoxjnJgoEZvNxTAQEQvg3MOMCqSR x1LOlGavOjoHBpkbAWvBCs3hMxChFGHvI11s2dqn34n8kFHbVbqDgVoMh6EYgD6i1gB7 hNVkbxjyCxATjHU1HueA+wWZAxlvUEoU2D3OrqFNJXNMcv8O0yl0+8dvQ74hotDvx8B3 XUYw== X-Gm-Message-State: ALoCoQmoDR4qq+wNXyvMtSJyXo5xrMf6WScNSEcFFbj5dVZx5clpCXRie9enY8XCkn+Adj6FCL3R X-Received: by 10.180.36.129 with SMTP id q1mr21752196wij.10.1437395573700; Mon, 20 Jul 2015 05:32:53 -0700 (PDT) Received: from dhcp-b3b5.meeting.ietf.org ([2001:67c:370:176:d1dd:6618:c053:161d]) by smtp.googlemail.com with ESMTPSA id jz4sm31807699wjb.16.2015.07.20.05.32.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 05:32:52 -0700 (PDT) Message-ID: <55ACEA74.8050300@jive.com> Date: Mon, 20 Jul 2015 14:32:52 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tim Panton , Martin Thomson References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> In-Reply-To: <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 12:32:56 -0000 Le 2015-07-20 14:26, Tim Panton a écrit : > Gulp. Whilst I mostly see the logic - it is wholly unexpected behaviour > to the average sys admin. > Certainly not what I expected. I don't know how you can expect ICE to work otherwise. > It strikes me that binding to all interfaces might well give a vector > for attackers to map out a company’s internal networks. You are sending your IP address(es) as payload so that your peer may connect to them. We've been doing this in various protocols for ages. Just take FTP for example, where data and signalling are separate. How is any of this different? > It also may restrict the user’s ability to manipulate which medium is used. > E.g. I’m at home and my chromebook pixel (or firefox tablet) is on wifi, > but I’ve left LTE enabled. > I (or the OS) is configured to prefer wifi wen available - but it > happens that for a specific peer LTE completes first. > So now my video call goes over LTE without my say-so and with no hint > this is happening - costing me real > money. My only option is to completely disable LTE when I get home (and > lose SMS too) ? That is a valid concern, and the answer to it is MIF. Simon From nobody Mon Jul 20 05:35:38 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB66E1A7D82 for ; Mon, 20 Jul 2015 05:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCfhHzPjdTJ3 for ; Mon, 20 Jul 2015 05:35:36 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 899AB1A1B07 for ; Mon, 20 Jul 2015 05:35:36 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 8CD1C1EB8409 for ; Mon, 20 Jul 2015 14:35:35 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0224.002; Mon, 20 Jul 2015 14:35:35 +0200 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: JSEP and -return- ICE Candidate Policy Thread-Index: AdDC6JNGvnJs4lAgQ4uNEahe4IEIvQ== Date: Mon, 20 Jul 2015 12:35:34 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E7FBFE7@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [rtcweb] JSEP and -return- ICE Candidate Policy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 12:35:38 -0000 https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-11#section-3.4.3 talks a= bout the application having control over the ICE Candidate Policy (RTCIceTr= ansportPolicy) but it also contains the following statement regarding local= policy: "In addition, administrators may also wish to control the set of ICE candid= ates, and so the browser SHOULD also allow control via local policy, with t= he most restrictive policy prevailing". This seems to imply that the admin and application policies are controlling= the same functionality in the browser but is this really true? https://tools.ietf.org/html/draft-ietf-rtcweb-return-00#section-4.3 also re= fers to to the ICE candidate policy section of JSEP and indicates states th= at: "Proxy configuration, including leakiness, maybe set by local policy ([I-D.= ietf-rtcweb-jsep], "ICE candidate policy") or other mechanisms". It seems something is wrong here and probably JSEP should not be talking ab= out the local policy as I assume this would not use the PeerConnection API = and the -return- draft should not be referring to JSEP regarding this local= policy as again this will not use the PC API. Andy From nobody Mon Jul 20 05:58:56 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65C21A8770 for ; Mon, 20 Jul 2015 05:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCfUMtIbZAw5 for ; Mon, 20 Jul 2015 05:58:53 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B157E1A8782 for ; Mon, 20 Jul 2015 05:58:52 -0700 (PDT) Received: (qmail 55606 invoked from network); 20 Jul 2015 12:58:51 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 8848 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 20 Jul 2015 12:58:51 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1FD9F18A1B47; Mon, 20 Jul 2015 13:58:48 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 0886B18A18CF; Mon, 20 Jul 2015 13:58:48 +0100 (BST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Panton In-Reply-To: <55ACEA74.8050300@jive.com> Date: Mon, 20 Jul 2015 13:58:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <55ACEA74.8050 300@jive.com> To: Simon Perreault X-Mailer: Apple Mail (2.2102) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 12:58:55 -0000 > On 20 Jul 2015, at 13:32, Simon Perreault wrote: >=20 > Le 2015-07-20 14:26, Tim Panton a =E9crit : >> Gulp. Whilst I mostly see the logic - it is wholly unexpected = behaviour >> to the average sys admin.=20 >> Certainly not what I expected. >=20 > I don't know how you can expect ICE to work otherwise. >=20 >> It strikes me that binding to all interfaces might well give a vector >> for attackers to map out a company=92s internal networks. >=20 > You are sending your IP address(es) as payload so that your peer may > connect to them. We've been doing this in various protocols for ages. > Just take FTP for example, where data and signalling are separate. How > is any of this different? I=92d hardly take FTP as a model citizen :-) But what is different is that we have removed _all_ the sysadmin=92s = levers to prevent mapping of internal address spaces. If I understand correctly we bind to each and every interface that is up and send out packets to all remote candidates down _every_ = interface, ignoring any preferences set by the admin in the local routing table = which were set to ensure (say) only critical traffic is sent down certain = interfaces. I can think of some financial institutions who=92s IDSs will go off when = packets to public external addresses start turning up on internal LANS . = (hopefully they=20 will get dropped at the egress router, but by then the IDS will have = paged someone). Likewise my fantastically expensive BGAN link which is used for emergencies only will suddenly start carrying STUN requests irrespective = of how I configure my routes ? >=20 >> It also may restrict the user=92s ability to manipulate which medium = is used.=20 >> E.g. I=92m at home and my chromebook pixel (or firefox tablet) is on = wifi, >> but I=92ve left LTE enabled. >> I (or the OS) is configured to prefer wifi wen available - but it >> happens that for a specific peer LTE completes first. >> So now my video call goes over LTE without my say-so and with no hint >> this is happening - costing me real >> money. My only option is to completely disable LTE when I get home = (and >> lose SMS too) ? >=20 > That is a valid concern, and the answer to it is MIF. And in the meanwhile ? Tim. >=20 > Simon From nobody Mon Jul 20 06:13:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B5D1A8782 for ; Mon, 20 Jul 2015 06:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzWu3imzAmoH for ; Mon, 20 Jul 2015 06:13:25 -0700 (PDT) Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB3C1A8778 for ; Mon, 20 Jul 2015 06:13:25 -0700 (PDT) Received: by ykdu72 with SMTP id u72so138001041ykd.2 for ; Mon, 20 Jul 2015 06:13:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0omYgNFt49VLOdkyVhNq0jTn0H+9kGbaWY9Z6+5CNtg=; b=AxVtyFfrxx7D4ALlXgnBqOc4AV+Ld+2AG1lLZo+uEfWOx9loUlPNdfqs2cDptEwcce P9+bJZx+UF00L8x5XmX6r2Vmm8T8ChMIQGqYxEnhRYEta0I9coDdCFQLZnXDY6I4zPao cPQ5Oon3vpGN0jclb8gVouShedfXYm1KKexdIF9ZMy6A0680RFKdQ6tA69lIshavSUI0 RR/4GMHepEk7eseKIykCfj85HSX0f3nic2fGw4ZFAs8FlDo0JX1mKErCoVjer+XRa1CI bqLKi5GC+tyAapcgX+jx04+g0kn05Ip1EUjrw0FzHFk8aIswH8JUz7xoSkNuvrp0DHTz msRg== X-Gm-Message-State: ALoCoQl3Go/0YF3pE6qT359cSxzD6I2G5XMjhoSq7MZEEWKp0MP6lc1tfiJ/xdJyIbfhngkUZcei X-Received: by 10.129.79.4 with SMTP id d4mr28552217ywb.15.1437398004828; Mon, 20 Jul 2015 06:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Mon, 20 Jul 2015 06:13:05 -0700 (PDT) In-Reply-To: <55ACEA74.8050300@jive.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <55ACEA74.8050300@jive.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Jul 2015 15:13:05 +0200 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a114dcd807abd1c051b4e4d79 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 13:13:27 -0000 --001a114dcd807abd1c051b4e4d79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-07-20 14:32 GMT+02:00 Simon Perreault : > Le 2015-07-20 14:26, Tim Panton a =C3=A9crit : > > Gulp. Whilst I mostly see the logic - it is wholly unexpected behaviour > > to the average sys admin. > > Certainly not what I expected. > > I don't know how you can expect ICE to work otherwise. > It would just work. The STUN/TURN server should be reachable using the OS configured routes, isn't it? Please, don't argument that "otherwise it would not work" because that is not true at all. > > > It strikes me that binding to all interfaces might well give a vector > > for attackers to map out a company=E2=80=99s internal networks. > > You are sending your IP address(es) as payload so that your peer may > connect to them. The fact that the client announces its (probably) private VPN addresses to the remote peer does not mean that it also reveals the associated public reflexive IP. That just happens if the client performs STUN procedures over that interface, which is exactly the issue being discussed (at least right now). > We've been doing this in various protocols for ages. > Just take FTP for example, where data and signalling are separate. How > is any of this different? > The FTP client does not override the OS routes but instead contacts both the FTP signaling address and the FTP data address using the OS configured routes (rather than forcing local interfaces to reach them). So yes, it is fully different IMHO. > > > It also may restrict the user=E2=80=99s ability to manipulate which med= ium is > used. > > E.g. I=E2=80=99m at home and my chromebook pixel (or firefox tablet) is= on wifi, > > but I=E2=80=99ve left LTE enabled. > > I (or the OS) is configured to prefer wifi wen available - but it > > happens that for a specific peer LTE completes first. > > So now my video call goes over LTE without my say-so and with no hint > > this is happening - costing me real > > money. My only option is to completely disable LTE when I get home (an= d > > lose SMS too) ? > > That is a valid concern, and the answer to it is MIF. Sorry, what does MIF stand for? --=20 I=C3=B1aki Baz Castillo --001a114dcd807abd1c051b4e4d79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2015-07-20 14:32 GMT+02:00 Simon Perreault <sperreault@jive.com><= /span>:
Le 2015-07-20 14= :26, Tim Panton a =C3=A9crit :
> Gulp. Whilst I mostly see the logic - it is wholly unexpected behaviou= r
> to the average sys admin.
> Certainly not what I expected.

I don't know how you can expect ICE to work otherwise.

It would just work. The STUN/TURN server should = be reachable using the OS configured routes, isn't it?

Please, don't argument that "otherwise it would not work&= quot; because that is not true at all.

=C2=A0

> It strikes me that binding to all interfaces might well give a vector<= br> > for attackers to map out a company=E2=80=99s internal networks.

You are sending your IP address(es) as payload so that your peer may=
connect to them.

The fact that the client = announces its (probably) private VPN addresses to the remote peer does not = mean that it also reveals the associated public reflexive IP. That just hap= pens if the client performs STUN procedures over that interface, which is e= xactly the issue being discussed (at least right now).

=
=C2=A0
We've been doing this i= n various protocols for ages.
Just take FTP for example, where data and signalling are separate. How
is any of this different?

The FTP clien= t does not override the OS routes but instead contacts both the FTP signali= ng address and the FTP data address using the OS configured routes (rather = than forcing local interfaces to reach them). So yes, it is fully different= IMHO.

=C2=A0

> It also may restrict the user=E2=80=99s ability to manipulate which me= dium is used.
> E.g. I=E2=80=99m at home and my chromebook pixel (or firefox tablet) i= s on wifi,
> but I=E2=80=99ve left LTE enabled.
> I (or the OS) is configured to prefer wifi wen available - but it
> happens that for a specific peer LTE completes first.
> So now my video call goes over LTE without my say-so and with no hint<= br> > this is happening=C2=A0 - costing me real
> money. My only option is to completely disable LTE when I get home=C2= =A0 (and
> lose SMS too) ?

That is a valid concern, and the answer to it is MIF.

Sorry, what does MIF stand for?


--
I= =C3=B1aki Baz Castillo
<ibc@aliax.net>
--001a114dcd807abd1c051b4e4d79-- From nobody Mon Jul 20 06:26:56 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16AF1A8844 for ; Mon, 20 Jul 2015 06:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akfDzL2f0AE8 for ; Mon, 20 Jul 2015 06:26:53 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149351A8846 for ; Mon, 20 Jul 2015 06:26:52 -0700 (PDT) Received: by wibud3 with SMTP id ud3so87765902wib.1 for ; Mon, 20 Jul 2015 06:26:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=htSRN64enufVjMGr0wYXCuT5OkNZABj5Y379p+wJLdE=; b=dkaxrPoiC0MjhIwqfwi4ot6nq/rTsIkB/x5SC1Fza51uiVmkCVpmOhxCjadDh0FK5x 6DwKksfy50Hi+2EFmpPVPyWAqijK3mnZ9KxWvFjYDS/7dJUksxyuTDWGySSwk2hpXC6f IRs312pKypZKYnsSA/Vf+T8bJ7vtt+aXBdH4UuHk+o2CJ/RVDCkHq4b5vAumyejtxJlX NCeTdZ5YUY5i72t+whvofhCPQzU0wDlZ6KQpItlbEHBqgBPzoDvkiZLMaE72omBJ5Bie 95hFLUOwDnpOJ0mUbIeNEPFnP4cAdVp0qS1kMA3YyQLlaXjkKEC0ItoLLyv7dztMc+XO FYgg== X-Gm-Message-State: ALoCoQkTxui+7wFiIMx+lOhe2BoqLVO35IqdKGEP1+dZWf19m8cvQ3awH2849pfa3rNu3xPx4ZWS X-Received: by 10.194.58.199 with SMTP id t7mr57860008wjq.45.1437398810748; Mon, 20 Jul 2015 06:26:50 -0700 (PDT) Received: from dhcp-b3b5.meeting.ietf.org ([2001:67c:370:176:8c28:2ddb:9d64:1c21]) by smtp.googlemail.com with ESMTPSA id pn6sm32011406wjb.36.2015.07.20.06.26.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 06:26:49 -0700 (PDT) Message-ID: <55ACF718.3010000@jive.com> Date: Mon, 20 Jul 2015 15:26:48 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tim Panton References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <55ACEA74.8050 300@jive.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> In-Reply-To: <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 13:26:55 -0000 Le 2015-07-20 14:58, Tim Panton a écrit : > If I understand correctly we bind to each and every interface > that is up and send out packets to all remote candidates down _every_ interface, > ignoring any preferences set by the admin in the local routing table which > were set to ensure (say) only critical traffic is sent down certain interfaces. I have difficulty understanding what it is that's bugging you. Is it the signalling payload (i.e., sending the list of address), or is it the connectivity checks that are done on all candidate pairs? > I can think of some financial institutions who’s IDSs will go off when packets > to public external addresses start turning up on internal LANS . (hopefully they > will get dropped at the egress router, but by then the IDS will have paged someone). But that's not going to happen unless there's a route. I think there could be a misunderstanding here. For example, if there's a VPN with a 10.0.0.0/8 route but no default route, the ICE client will *not* send a request to a TURN server listening on 192.0.2.1 over the VPN interface. That would make no sense whatsoever. > Likewise my fantastically expensive BGAN link which is used for > emergencies only will suddenly start carrying STUN requests irrespective of how I configure my > routes ? Only if it's possible to route the packet to the STUN server over the BGAN link. There must be a route. Simon From nobody Mon Jul 20 06:33:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAC41A8833 for ; Mon, 20 Jul 2015 06:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHkn9xgoLKlo for ; Mon, 20 Jul 2015 06:32:52 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B3F1A87AD for ; Mon, 20 Jul 2015 06:32:52 -0700 (PDT) Received: by wgkl9 with SMTP id l9so130594074wgk.1 for ; Mon, 20 Jul 2015 06:32:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KW4hi8E4VpT855f+CrNIIIsDBS1Et1Wd6fnByT6+7u0=; b=J63ZAZap99eUxApGeWK5PJNhn7WQIIw1JiT7UC1VTDwwPG/CX9BrQLRyWlxV3Phb2b PttxoSBX6pPLEkcIawfNpGv0YkfUM7xh0zmz34ywpzCZr+22YWcp9Yju/8+f8BliL+wy EaFrnllLwqH+rYXxCQYKWrZse4ohA2WA2s2jtAf7xCVwS/4Xlm/KDuHWQ4u7qbzWrD/7 SC3XDfyi0Pwf5CE1lBhms8gsAR8gZ9zQZPUilxWxQI/6eqrxpoVUQ22W6Ov9mDsfhlun LolAc8LgL3eMPcKWUsUp1E2iValPRdy9+m8ECK+/f1jc9W2MPVZTLhXfhv/7ieDZOE/f 4XLg== X-Gm-Message-State: ALoCoQksHvHfU1KS33pV69Qvq/w7YM8BASYwbFsWsJzc8jMumpwbJyPoXTEhcmXsQbM4lvWtF99p X-Received: by 10.180.231.40 with SMTP id td8mr22401913wic.9.1437399171028; Mon, 20 Jul 2015 06:32:51 -0700 (PDT) Received: from dhcp-b3b5.meeting.ietf.org ([2001:67c:370:176:8c28:2ddb:9d64:1c21]) by smtp.googlemail.com with ESMTPSA id n6sm11875083wix.1.2015.07.20.06.32.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 06:32:50 -0700 (PDT) Message-ID: <55ACF880.9090704@jive.com> Date: Mon, 20 Jul 2015 15:32:48 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <55ACEA74.8050300@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 13:32:59 -0000 Le 2015-07-20 15:13, Iñaki Baz Castillo a écrit : > > Gulp. Whilst I mostly see the logic - it is wholly unexpected behaviour > > to the average sys admin. > > Certainly not what I expected. > > I don't know how you can expect ICE to work otherwise. > > > It would just work. The STUN/TURN server should be reachable using the > OS configured routes, isn't it? I have no idea what you're talking about. Yes there must be a route. But that's completely orthogonal to which interface you're binding to. > Please, don't argument that "otherwise it would not work" because that > is not true at all. It is. But I'm not sure we're talking about the same "it" anymore. > > It strikes me that binding to all interfaces might well give a vector > > for attackers to map out a company’s internal networks. > > You are sending your IP address(es) as payload so that your peer may > connect to them. > > > The fact that the client announces its (probably) private VPN addresses > to the remote peer does not mean that it also reveals the associated > public reflexive IP. That just happens if the client performs STUN > procedures over that interface, which is exactly the issue being > discussed (at least right now). If you can find a server-reflexive candidate on the VPN interface, it means you can talk to the Internet using that interface, using that server-reflexive IP address. How is that private knowledge at all? How do you expect to keep your server-reflexive address private but still use it for communication? > We've been doing this in various protocols for ages. > Just take FTP for example, where data and signalling are separate. How > is any of this different? > > > The FTP client does not override the OS routes but instead contacts both > the FTP signaling address and the FTP data address using the OS > configured routes (rather than forcing local interfaces to reach them). > So yes, it is fully different IMHO. The routing table is *not* overridden by explicitly binding to an interface. > > It also may restrict the user’s ability to manipulate which medium is used. > > E.g. I’m at home and my chromebook pixel (or firefox tablet) is on wifi, > > but I’ve left LTE enabled. > > I (or the OS) is configured to prefer wifi wen available - but it > > happens that for a specific peer LTE completes first. > > So now my video call goes over LTE without my say-so and with no hint > > this is happening - costing me real > > money. My only option is to completely disable LTE when I get home (and > > lose SMS too) ? > > That is a valid concern, and the answer to it is MIF. > > > Sorry, what does MIF stand for? https://datatracker.ietf.org/wg/mif/documents/ The MIF WG is working on exactly this kind of problem. They are developing an API for solving precisely this kind of interface preference problem. IMHO ICE could perhaps be extended to make use of this API. But I see it as "just" an enhancement. Simon From nobody Mon Jul 20 06:45:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91D81A8847 for ; Mon, 20 Jul 2015 06:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Huys9HC2tUIC for ; Mon, 20 Jul 2015 06:45:23 -0700 (PDT) Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD4E1A1F70 for ; Mon, 20 Jul 2015 06:45:23 -0700 (PDT) Received: by ykax123 with SMTP id x123so139115548yka.1 for ; Mon, 20 Jul 2015 06:45:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LscKDWxrCgyrPH/hKbb19hsCIxFw3mqH7kiTvBt0thU=; b=m+unmdEFc2MIE2bSLu/EacbzsyrF9G8oNBUEfU0mI38ctfc20zzeDh28u5ZheJCIIn q11Kdbpk93aL787goosHEJ2JnYG6mTUE38JRwW5lomLUA8Wk6NvjVqUE57psSCv6OnFd tY3GP2vUKGcR2/smm7zn2zT0YjG82hPYJyVOvHVPZJQSZaFjKo6dJEhxJXQlS3BbdAzl /wiONcroOMh3mhe5V9glrBLdmOMauHpGYGcGJNSqmHdPGWSczChrLYh6nfEgxQo34mNo Rhn5zJDyanpWoVe7w5AFy86mrsDeFhRZmskNp2kEHOGlWe3UICZkbI4PS+LECZB5mZrf BEjQ== X-Gm-Message-State: ALoCoQn+MUFilVNwXUVkinHo5IeBJJJbzjB2DNO3vjCHXYgIyA8jUe6oRkfTcMJKDThou0whyFVk X-Received: by 10.129.77.213 with SMTP id a204mr29118368ywb.40.1437399923044; Mon, 20 Jul 2015 06:45:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Mon, 20 Jul 2015 06:45:03 -0700 (PDT) In-Reply-To: <55ACF718.3010000@jive.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> <55ACF718.3010000@jive.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Jul 2015 15:45:03 +0200 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a1140c552d0808b051b4ebf8f Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 13:45:26 -0000 --001a1140c552d0808b051b4ebf8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-07-20 15:26 GMT+02:00 Simon Perreault : > Le 2015-07-20 14:58, Tim Panton a =C3=A9crit : > > If I understand correctly we bind to each and every interface > > that is up and send out packets to all remote candidates down _every_ > interface, > > ignoring any preferences set by the admin in the local routing table > which > > were set to ensure (say) only critical traffic is sent down certain > interfaces. > > I have difficulty understanding what it is that's bugging you. Is it the > signalling payload (i.e., sending the list of address), or is it the > connectivity checks that are done on all candidate pairs? > Unfortunately we are mixing two probably separate concerns: 1) ICE gathering and possible sensitive IP leak when connecting the STUN/TURN server (decided by the web app) from all the interfaces (those that of course have a route to the server). 2) Same issue when the IPs are announced in the SDP and ICE connectivity checks with the remote peer are performed. We should focus :) > > > Likewise my fantastically expensive BGAN link which is used for > > emergencies only will suddenly start carrying STUN requests irrespectiv= e > of how I configure my > > routes ? > > Only if it's possible to route the packet to the STUN server over the > BGAN link. There must be a route. Yes, but the point is that one may have enabled a secondary route (a default route via eth2) but prefer to use another route as default (eth1). The browser will not respect that because it will try both eth1 and eth2. --=20 I=C3=B1aki Baz Castillo --001a1140c552d0808b051b4ebf8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015= -07-20 15:26 GMT+02:00 Simon Perreault <sperreault@jive.com>:
Le 2015-07-20 14:58,= Tim Panton a =C3=A9crit :
> If I understand correctly we bind to each and every interface
> that is up and send out packets to all remote candidates down _every_ = interface,
> ignoring any preferences set by the admin in the local routing table w= hich
> were set to ensure (say) only critical traffic is sent down certain in= terfaces.

I have difficulty understanding what it is that's bugging you. I= s it the
signalling payload (i.e., sending the list of address), or is it the
connectivity checks that are done on all candidate pairs?
<= div>
Unfortunately we are mixing two probably separate concer= ns:

1) ICE gathering and possible sensitive IP lea= k when connecting the STUN/TURN server (decided by the web app) from all th= e interfaces (those that of course have a route to the server).
<= br>
2) Same issue when the IPs are announced in the SDP and ICE c= onnectivity checks with the remote peer are performed.

=
We should focus :)


=C2=A0

> Likewise my fantastically expensive BGAN link which is used for
> emergencies only will suddenly start carrying STUN requests irrespecti= ve of how I configure my
> routes ?

Only if it's possible to route the packet to the STUN server ove= r the
BGAN link. There must be a route.

=C2=A0Yes= , but the point is that one may have enabled a secondary route (a default r= oute via eth2) but prefer to use another route as default (eth1). The brows= er will not respect that because it will try both eth1 and eth2.




--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
--001a1140c552d0808b051b4ebf8f-- From nobody Mon Jul 20 06:45:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76161A886F for ; Mon, 20 Jul 2015 06:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv674blR3XJw for ; Mon, 20 Jul 2015 06:45:37 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3990B1A8890 for ; Mon, 20 Jul 2015 06:45:37 -0700 (PDT) Received: (qmail 71025 invoked from network); 20 Jul 2015 13:45:35 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 9757 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 20 Jul 2015 13:45:35 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id A9ECA18A18CF; Mon, 20 Jul 2015 14:45:32 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 8F5E118A17F6; Mon, 20 Jul 2015 14:45:32 +0100 (BST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Panton In-Reply-To: <55ACF718.3010000@jive.com> Date: Mon, 20 Jul 2015 14:45:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <55ACEA74.8050 300@jive.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> <55ACF718.3010000@jive.com> To: Simon Perreault X-Mailer: Apple Mail (2.2102) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 13:45:39 -0000 > On 20 Jul 2015, at 14:26, Simon Perreault wrote: >=20 > Le 2015-07-20 14:58, Tim Panton a =E9crit : >> If I understand correctly we bind to each and every interface >> that is up and send out packets to all remote candidates down _every_ = interface, >> ignoring any preferences set by the admin in the local routing table = which >> were set to ensure (say) only critical traffic is sent down certain = interfaces. >=20 > I have difficulty understanding what it is that's bugging you. Is it = the > signalling payload (i.e., sending the list of address), or is it the > connectivity checks that are done on all candidate pairs? I=92m not worried about the signalling payload (i.e. the list of local = interface addresses -=20 except of course the mac-based ipv6 auto conf one). I am worried about what can be learnt from /caused by sending packets = down interfaces when the sysadmin isn=92t expecting it. (In the end some of those learnings may end up in signalling as = candidates too). >=20 >> I can think of some financial institutions who=92s IDSs will go off = when packets >> to public external addresses start turning up on internal LANS . = (hopefully they=20 >> will get dropped at the egress router, but by then the IDS will have = paged someone). >=20 > But that's not going to happen unless there's a route. I think there > could be a misunderstanding here. For example, if there's a VPN with a > 10.0.0.0/8 route but no default route, the ICE client will *not* send = a > request to a TURN server listening on 192.0.2.1 over the VPN = interface. > That would make no sense whatsoever. And yet that=92s what I read Martin to say :=20 "> The point is that you don't even choose the interface. The OS will do = for you. The OS can - and frequently does - get that wrong. The default route can = fail when another might succeed." I read that as 'another interface=92 - but if he means =91another = route=92 then I=92m happier - I think. Can @justin or @martin confirm what the browsers currently do ? >=20 >> Likewise my fantastically expensive BGAN link which is used for >> emergencies only will suddenly start carrying STUN requests = irrespective of how I configure my >> routes ? >=20 > Only if it's possible to route the packet to the STUN server over the > BGAN link. There must be a route. There must be a _locally_ configured route - It doesn=92t matter if the = egress router at the far end of the BGAN drops=20 the STUN packet I=92ve still wasted my money :-( >=20 > Simon Tim. From nobody Mon Jul 20 06:51:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA371A88A6 for ; Mon, 20 Jul 2015 06:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKsIE3uxl7xD for ; Mon, 20 Jul 2015 06:51:23 -0700 (PDT) Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9841A8895 for ; Mon, 20 Jul 2015 06:51:22 -0700 (PDT) Received: by ykdu72 with SMTP id u72so138872860ykd.2 for ; Mon, 20 Jul 2015 06:51:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JNAUqZ0lXtL8w2Dq5SPii8MBR4A6wboeV+eJUiPPdpo=; b=m08gzCVHLFOSUtQd/soybWM7UrTzCIiEeJ3JFR/pv7+6FD6bIg3ggn6g4WSFo05yIB 9DxpVdJrqyhDe4ge84ERYuX/q4ftVjXoVLmaY9xMGWVNpgdXtEhmQWIfZTq8BB+CLLqs s0rRB1sqm5HoGAbucpiifptZLyJYFdSLi+RcMQitMC+3wyF8x8et10i5Y3kRTNvI941y nERR4hvk08Xv3pDrBkwCez7h9ZZRq5wVhPV8Vybn9z/Xg7BFnRmufuul19Bo6/56p8sT 4iF51MKx+wPyY8AapK67GOz9r1gkIoWn+Up9RcKa7XRvumbSBbPSEUxI6dcrFUV6jU1E dUjQ== X-Gm-Message-State: ALoCoQnIRH4WnI7PHAwM45YR4pLtIlDh2IdtxPzcDt5Wbj+DHnZUtUu9CtCd7crfX7m67F4V6t1B X-Received: by 10.129.108.2 with SMTP id h2mr28260694ywc.161.1437400282197; Mon, 20 Jul 2015 06:51:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Mon, 20 Jul 2015 06:51:02 -0700 (PDT) In-Reply-To: <55ACF880.9090704@jive.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <55ACEA74.8050300@jive.com> <55ACF880.9090704@jive.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Jul 2015 15:51:02 +0200 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a114dae7a389dd5051b4ed540 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 13:51:25 -0000 --001a114dae7a389dd5051b4ed540 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-07-20 15:32 GMT+02:00 Simon Perreault : > > The fact that the client announces its (probably) private VPN addresses > > to the remote peer does not mean that it also reveals the associated > > public reflexive IP. That just happens if the client performs STUN > > procedures over that interface, which is exactly the issue being > > discussed (at least right now). > > If you can find a server-reflexive candidate on the VPN interface, it > means you can talk to the Internet using that interface, using that > server-reflexive IP address. How is that private knowledge at all? How > do you expect to keep your server-reflexive address private but still > use it for communication? > Ok, let's simplify this subject: - Computer with two default routes (A and B) and a private network route (C). - A is the preferred default route one so has priority in the routing table= . - Every packet whose destination is not C network should be sent over A. ... - or not? should a specific app override it? This seems more a moral issue. > The routing table is *not* overridden by explicitly binding to an > interface. > I meant "using a secondary default route". Sorry for the confusion. > > That is a valid concern, and the answer to it is MIF. > > > > > > Sorry, what does MIF stand for? > > https://datatracker.ietf.org/wg/mif/documents/ > > The MIF WG is working on exactly this kind of problem. They are > developing an API for solving precisely this kind of interface > preference problem. IMHO ICE could perhaps be extended to make use of > this API. But I see it as "just" an enhancement. Good to know. Thanks. --=20 I=C3=B1aki Baz Castillo --001a114dae7a389dd5051b4ed540 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015= -07-20 15:32 GMT+02:00 Simon Perreault <sperreault@jive.com>:
> The fact that t= he client announces its (probably) private VPN addresses
> to the remote peer does not mean that it also reveals the associated > public reflexive IP. That just happens if the client performs STUN
> procedures over that interface, which is exactly the issue being
> discussed (at least right now).

If you can find a server-reflexive candidate on the VPN interface, i= t
means you can talk to the Internet using that interface, using that
server-reflexive IP address. How is that private knowledge at all? How
do you expect to keep your server-reflexive address private but still
use it for communication?

Ok, let's= simplify this subject:

- Computer with two defaul= t routes (A and B) and a private network route (C).
- A is the pr= eferred default route one so has priority in the routing table.
-= Every packet whose destination is not C network should be sent over A.
...
- or not? should a specific app override it?

=C2=A0This seems more a moral issue.


=C2=A0
The routing ta= ble is *not* overridden by explicitly binding to an interface.

I meant "using a secondary default route"= . Sorry for the confusion.


>=C2=A0 =C2=A0 =C2=A0That is a valid concern, an= d the answer to it is MIF.
>
>
> Sorry, what does MIF stand for?

https://datatracker.ietf.org/wg/mif/documents/<= /a>

The MIF WG is working on exactly this kind of problem. They are
developing an API for solving precisely this kind of interface
preference problem. IMHO ICE could perhaps be extended to make use of
this API. But I see it as "just" an enhancement.




--
I=C3=B1aki Baz Casti= llo
<ibc@aliax.net= >
--001a114dae7a389dd5051b4ed540-- From nobody Mon Jul 20 06:56:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428BF1A87BC for ; Mon, 20 Jul 2015 06:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEA4zVC0XCdR for ; Mon, 20 Jul 2015 06:56:30 -0700 (PDT) Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0D21A1AAE for ; Mon, 20 Jul 2015 06:56:30 -0700 (PDT) Received: by ykax123 with SMTP id x123so139377795yka.1 for ; Mon, 20 Jul 2015 06:56:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=K276iS7VusmYEDxQ1vYBzYhZ+LXr/kaDUe3MPVFVWro=; b=HyU3QtmH+fEo7gPb0q7+5wIlemoTLD6xIrB1Y5mM/3+zuFiD4NSdA0DXF0hEJMUsyo 7d50x6QgtQurpEf2mCtk9i/12IbsylNuscJpcER5tqTatyzuL8D1xV7zwEstJLcj+oOG nDoEzYo5DPBG5CTZApwPYhiLu2lNRv2L7enIUy78Lk7+YR2EatNOsqr/WL5aeMFjkcBq Y7A34p4BcicvJE+hVrSglGCOXdUYOlErU8TNrJACQpjQzFMW4QmuzPiDdUmeDAKjZ+E7 3CYwOrWikYzaDWx6vwn+LTnyHt0xaz+hl/3zRJYodDQ5vv9ICEbiD6notssBtK4oOjfK kUNA== X-Gm-Message-State: ALoCoQnPKC2oKDHry6SgucmYfsLaZojbflll+dZKySEYj3v9S7xhBPYiqvTe1punZ5UBp06Tqia0 X-Received: by 10.170.219.4 with SMTP id l4mr20206149ykf.15.1437400589602; Mon, 20 Jul 2015 06:56:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Mon, 20 Jul 2015 06:56:10 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> <55ACF718.3010000@jive.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Jul 2015 15:56:10 +0200 Message-ID: To: Tim Panton Content-Type: multipart/alternative; boundary=001a113a346c8b42e6051b4ee716 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 13:56:31 -0000 --001a113a346c8b42e6051b4ee716 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-07-20 15:45 GMT+02:00 Tim Panton : > And yet that=E2=80=99s what I read Martin to say : > "> The point is that you don't even choose the interface. The OS will do > for you. > The OS can - and frequently does - get that wrong. The default route can > fail when another might succeed." > > I read that as 'another interface=E2=80=99 - but if he means =E2=80=98an= other route=E2=80=99 then > I=E2=80=99m happier - I think. > Can @justin or @martin confirm what the browsers currently do ? > I can confirm (OSX) that during ICE gathering STUN requests to the STUN server are not sent over interfaces not belonging to any network route that can reach the STUN/TURN server. This is, network routes are "respected". The issue is that all the existing routes capables of reaching the STUN server are tested (instead of the first one). Note that we should avoid the term "default route" here as it stands for 0.0.0.0. It may happen that the webrtc app uses a private STUN server which is just reachable via a VPN interface (and its specific route to reach the VPN network in which the STUN server is placed) so in this case the default route should not be tested because there is a route with higher priority to reach the server. --=20 I=C3=B1aki Baz Castillo --001a113a346c8b42e6051b4ee716 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015= -07-20 15:45 GMT+02:00 Tim Panton <tim@phonefromhere.com>:
And yet that=E2=80=99s what I read Martin to say :
"> The point is that you don't even choose the= interface. The OS will do for you.
The OS can - and frequently does - get that wrong. The default route can fa= il when another might succeed."

I read that as 'another interface=E2=80=99 - but if he means=C2= =A0 =E2=80=98another route=E2=80=99 then I=E2=80=99m happier - I think.
Can @justin or @martin confirm what the browsers currently do ?

I can confirm (OSX) that during ICE gathering STUN req= uests to the STUN server are not sent over interfaces not belonging to any = network route that can reach the STUN/TURN server. This is, network routes = are "respected". The issue is that all the existing routes capabl= es of reaching the STUN server are tested (instead of the first one).
=

Note that w= e should avoid the term "default route" here as it stands for 0.0= .0.0. It may happen that the webrtc app uses a private STUN server which is= just reachable via a VPN interface (and its specific route to reach the VP= N network in which the STUN server is placed) so in this case the default r= oute should not be tested because there is a route with higher priority to = reach the server.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
--001a113a346c8b42e6051b4ee716-- From nobody Mon Jul 20 07:00:37 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454581A889B for ; Mon, 20 Jul 2015 07:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbHp22bHZmQH for ; Mon, 20 Jul 2015 07:00:35 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6C31A889F for ; Mon, 20 Jul 2015 07:00:34 -0700 (PDT) Received: by wgav7 with SMTP id v7so65910223wga.2 for ; Mon, 20 Jul 2015 07:00:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vTNbWUPG9EdtAiWLv/0TDXClcxXnMZ7WRIe652Yyq2c=; b=JIIUb+hMTiJkQfVx3PP6dKhwhGwCToACdjm6rvacZ2j1XyA50Ll0X+W8hdbsz9PQn9 FytJib4p5kn9O3FKjWwM8CThUgWsY/b6gRsJ4jvfToLAJOMdI4d9C96dsysRtw0BAq9J 8SqZ6dh0hl2puwzor9YhMLammUNS8UJbPGyCDzSbwXAjqGCMfoLOsq8iTJoDs9njzJHZ TQXyrslmo7H/mok7KoMegz4+2RsC5a2t3kc68U78eYbC9c/Gl/ZkY4cC6OT5e/IFTRZm b2sFifxKowLEZpFgTu+jPlyNfEzm/Hewa3j47WUvXTMPzgYunNwWhpxXUI6uw4b37AO2 ihpQ== X-Gm-Message-State: ALoCoQmcH8w6lWO0eo2IjGOg/nz/4JjKt0MHDgBjC4b0zkOebxkc0oIxDl82odvAQJYYGnFsxXqx X-Received: by 10.180.91.40 with SMTP id cb8mr9368740wib.54.1437400833594; Mon, 20 Jul 2015 07:00:33 -0700 (PDT) Received: from dhcp-b3b5.meeting.ietf.org ([2001:67c:370:176:8c28:2ddb:9d64:1c21]) by smtp.googlemail.com with ESMTPSA id j7sm32165591wjz.11.2015.07.20.07.00.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 07:00:32 -0700 (PDT) Message-ID: <55ACFEFE.3030108@jive.com> Date: Mon, 20 Jul 2015 16:00:30 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tim Panton References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <55ACEA74.8050 300@jive.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> <55ACF718.3010000@jive.com> In-Reply-To: <55ACF718.3010000@jive.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:00:36 -0000 Le 2015-07-20 15:26, Simon Perreault a écrit : >> I can think of some financial institutions who’s IDSs will go off when packets >> > to public external addresses start turning up on internal LANS . (hopefully they >> > will get dropped at the egress router, but by then the IDS will have paged someone). > But that's not going to happen unless there's a route. I think there > could be a misunderstanding here. For example, if there's a VPN with a > 10.0.0.0/8 route but no default route, the ICE client will *not* send a > request to a TURN server listening on 192.0.2.1 over the VPN interface. > That would make no sense whatsoever. Just to be sure I am not going crazy, I just wrote this test: > #include > #include > > #include > #include > > int > main(int argc, char *argv[]) > { > int s; > struct sockaddr_in sin; > char foo[] = "bar"; > > s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); > > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = inet_addr("192.168.2.128"); > sin.sin_port = htons(1234); > memset(&sin.sin_zero, 0, sizeof(sin.sin_zero)); > bind(s, (struct sockaddr *)&sin, sizeof(sin)); > > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = inet_addr("192.168.2.200"); > sin.sin_port = htons(53); > memset(&sin.sin_zero, 0, sizeof(sin.sin_zero)); > sendto(s, foo, sizeof(foo), 0, (struct sockaddr *)&sin, sizeof(sin)); > > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = inet_addr("8.8.8.8"); > sin.sin_port = htons(53); > memset(&sin.sin_zero, 0, sizeof(sin.sin_zero)); > sendto(s, foo, sizeof(foo), 0, (struct sockaddr *)&sin, sizeof(sin)); > > return (0); > } I ran it on this system: > sperreault@debian:~$ ip a > 1: lo: mtu 16436 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 > link/ether 00:0c:29:66:b9:2c brd ff:ff:ff:ff:ff:ff > inet 192.168.2.128/24 brd 192.168.2.255 scope global eth0 > inet6 fe80::20c:29ff:fe66:b92c/64 scope link > valid_lft forever preferred_lft forever > sperreault@debian:~$ ip r > 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.128 > sperreault@debian:~$ Strace's output is: > bind(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("192.168.2.128")}, 16) = 0 > sendto(3, "bar\0", 4, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.2.200")}, 16) = 4 > sendto(3, "bar\0", 4, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, 16) = -1 ENETUNREACH (Network is unreachable) This confirms that bind() does not override the routing table. Simon From nobody Mon Jul 20 07:08:24 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE471A88A9 for ; Mon, 20 Jul 2015 07:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_zwxCBbZGne for ; Mon, 20 Jul 2015 07:08:22 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586821A889D for ; Mon, 20 Jul 2015 07:08:18 -0700 (PDT) Received: by qkdv3 with SMTP id v3so112484258qkd.3 for ; Mon, 20 Jul 2015 07:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A2lJIa/lsGk6P/5lMRQD3zZ4ptk9OItfaItu/sDPcjQ=; b=ZjUpkjCxYSrL6tqQVjeEuMuWQq5ZbMiHozbUteFWeniLGhH+N3h/+ntq6qYAxV16qL onp6FfpAdEq4FcpAdJWFZb5hmq2jaoKXtEYAVxhw0g4OX5wCrUKd8IYEIwzKvbOarcWL /HHA/Kq9LFfVFL7IrZaGHrt9aAteK6bfWM6Q3m9Ic+Q704L2ND8U6YAjthw3AgMZr0lA W0la3eBP/0ZFzeCxSbcyxTjZxWUbqBWxpPLgmO+HP9ob9emQOUDRVKAQ5SF8yxVetz4X tLxY8j3HKD4pFPpm1MzzQKo2JuYIhKwxOi+3eBtoFL1Atjyf3Zy73msrV61Vk9ZMfaHF HeAA== MIME-Version: 1.0 X-Received: by 10.140.233.70 with SMTP id e67mr39915503qhc.7.1437401295946; Mon, 20 Jul 2015 07:08:15 -0700 (PDT) Received: by 10.140.108.130 with HTTP; Mon, 20 Jul 2015 07:08:14 -0700 (PDT) Received: by 10.140.108.130 with HTTP; Mon, 20 Jul 2015 07:08:14 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> <55ACF718.3010000@jive.com> Date: Mon, 20 Jul 2015 07:08:14 -0700 Message-ID: From: Daniel Roesler To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11353652a5090b051b4f1180 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:08:23 -0000 --001a11353652a5090b051b4f1180 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jul 20, 2015 6:45 AM, "I=C3=B1aki Baz Castillo" wrote: > > Unfortunately we are mixing two probably separate concerns: > > 1) ICE gathering and possible sensitive IP leak when connecting the STUN/TURN server (decided by the web app) from all the interfaces (those that of course have a route to the server). > A gentle reminder to stop referring to this as a "possible" sensitive IP leak. It *is currently* a sensitive IP leak, and is already being exploited in the wild[1]. [1]: https://webrtchacks.com/dear-ny-times/ Daniel --001a11353652a5090b051b4f1180 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 20, 2015 6:45 AM, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote:
>
> Unfortunately we are mixing two probably separate concerns:
>
> 1) ICE gathering and possible sensitive IP leak when connecting the ST= UN/TURN server (decided by the web app) from all the interfaces (those that= of course have a route to the server).
>

A gentle reminder to stop referring to this as a "possi= ble" sensitive IP leak. It *is currently* a sensitive IP leak, and is = already being exploited in the wild[1].

[1]: http= s://webrtchacks.com/dear-ny-times/

Daniel

--001a11353652a5090b051b4f1180-- From nobody Mon Jul 20 07:09:51 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F212B1A8915 for ; Mon, 20 Jul 2015 07:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-vCIjBNUMnf for ; Mon, 20 Jul 2015 07:09:48 -0700 (PDT) Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E911A8913 for ; Mon, 20 Jul 2015 07:09:48 -0700 (PDT) Received: by ykax123 with SMTP id x123so139727371yka.1 for ; Mon, 20 Jul 2015 07:09:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Riov4ckOco3ZTEQOQObtC9YXNJ81Z/WuX12zadBF4RY=; b=Jmcc7OXXbzXeamyR0ND0UNmywtckGSfbaDq94FaywM9hJWOMgvyPD0GiO8Or/SdxI4 ifIcdqgVVJssOzh7AbCaroihy10x+OjB5a2ddjeEfmEQlUtocRxhfdfDGxzaYyrM2t5i 0opy4Sp5iPSU8giUTtWMyrjGBj86DrrK00r3GaPEuL3O6ASrQ6dcyRD32wn+buf4ZBaq aFgWJNpVm4FTZSoFmqKgIG/f8ZUkmjEgcWylUhNa742Y9/BNUmJkJiCpxHYy4YpBqJRw WL/zXDdrHN7XEDbo1sIEkxGcZckcLxdCIZq3N0y0lec9+Jbt2hR4PvvLanSONymoiFbH tLUg== X-Gm-Message-State: ALoCoQnQ9STQ/dgy+vU9bgKvyFPXvMNHukWz7oYjM3iptv7WDMs4jCFeXQ3iKgxwV2iNV/8XGoio X-Received: by 10.129.75.214 with SMTP id y205mr29247460ywa.65.1437401387359; Mon, 20 Jul 2015 07:09:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Mon, 20 Jul 2015 07:09:27 -0700 (PDT) In-Reply-To: <55ACFEFE.3030108@jive.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> <55ACF718.3010000@jive.com> <55ACFEFE.3030108@jive.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Jul 2015 16:09:27 +0200 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a113f3d0a1819b5051b4f179a Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:09:50 -0000 --001a113f3d0a1819b5051b4f179a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-07-20 16:00 GMT+02:00 Simon Perreault : > > bind(3, {sa_family=3DAF_INET, sin_port=3Dhtons(1234), > sin_addr=3Dinet_addr("192.168.2.128")}, 16) =3D 0 > > sendto(3, "bar\0", 4, 0, {sa_family=3DAF_INET, sin_port=3Dhtons(53), > sin_addr=3Dinet_addr("192.168.2.200")}, 16) =3D 4 > > sendto(3, "bar\0", 4, 0, {sa_family=3DAF_INET, sin_port=3Dhtons(53), > sin_addr=3Dinet_addr("8.8.8.8")}, 16) =3D -1 ENETUNREACH (Network is > unreachable) > > This confirms that bind() does not override the routing table. > Yes sure, I also confirmed that with some traces when Chrome performs ICE gathering having my OSX computer a VPN interface with no route to reach the STUN server. So we are talking about whether the browser should just try the OS preferred route capable of reaching the STUN server or all the capable ones= . --=20 I=C3=B1aki Baz Castillo --001a113f3d0a1819b5051b4f179a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2015-07-20 16:00 GMT+02:00 Simon Perreault <sperreault@jive.com><= /span>:
> bind(3, {sa_family=3DAF_INET, sin_port=3Dhtons= (1234), sin_addr=3Dinet_addr("192.168.2.128")}, 16) =3D 0
> sendto(3, "bar\0", 4, 0, {sa_family=3DAF_INET, sin_port=3Dht= ons(53), sin_addr=3Dinet_addr("192.168.2.200")}, 16) =3D 4
> sendto(3, "bar\0", 4, 0, {sa_family=3DAF_INET, sin_port=3Dht= ons(53), sin_addr=3Dinet_addr("8.8.8.8")}, 16) =3D -1 ENETUNREACH= (Network is unreachable)

This confirms that bind() does not override the routing table.

Yes sure, I also confirmed that with some traces when Chrom= e performs ICE gathering having my OSX computer a VPN interface with no rou= te to reach the STUN server.

So we are talking about whether the browser should j= ust try the OS preferred route capable of reaching the STUN server or all t= he capable ones.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
--001a113f3d0a1819b5051b4f179a-- From nobody Mon Jul 20 07:11:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714F31A88A7 for ; Mon, 20 Jul 2015 07:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6UkKqvb-lQT for ; Mon, 20 Jul 2015 07:11:39 -0700 (PDT) Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com [209.85.160.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E98D1A889B for ; Mon, 20 Jul 2015 07:11:39 -0700 (PDT) Received: by ykay190 with SMTP id y190so139348319yka.3 for ; Mon, 20 Jul 2015 07:11:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=l7B5NZ+OEYDrWk59wRjJbxV+MPl1sWQKIhmHMnuhAKk=; b=RBSsxTPNbqxgV+u+JHNf3YR65Ua6PWh78kOz+sFq8+JjLEjKr+H8caZyYtUQ8jpBou +xL+J3c+Ppg6NGj8zNqglWMUwH9EeSrpKVRMCjbX4VEhEt7OvdVxepUs+lGyHxu3xj1M 6A9HO9+9AgfZufImzp+UUFkVLRigbht20nepWVTCztDqYTbA9mm7Fu/wKH+W4lzUtWn7 rymxnrJCPReWdB2hHXo2kWRXwGYjGtmiP/0z5GxXo+VOwqqNvk2JBGcPCy1QVhK8IvPS ObglJ4+Px4qGS7eGq9DcN9RinykMdtM4MTKgWCApTYs1EJJR2fmL1ttdf9T/1yZsqvs1 J7eQ== X-Gm-Message-State: ALoCoQlBV3bnTlzrDCQi3QUx1BUZlW2y8yFb8OlIiYNVdoKt2tWQ36HNy4ypox/AjEBv+0dvO8QY X-Received: by 10.129.77.213 with SMTP id a204mr29240439ywb.40.1437401498723; Mon, 20 Jul 2015 07:11:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Mon, 20 Jul 2015 07:11:19 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> <55ACF718.3010000@jive.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Jul 2015 16:11:19 +0200 Message-ID: To: Daniel Roesler Content-Type: multipart/alternative; boundary=001a1140c552bb4ccc051b4f1dbd Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:11:40 -0000 --001a1140c552bb4ccc051b4f1dbd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-07-20 16:08 GMT+02:00 Daniel Roesler : > > 1) ICE gathering and possible sensitive IP leak when connecting the > STUN/TURN server (decided by the web app) from all the interfaces (those > that of course have a route to the server). > > > > A gentle reminder to stop referring to this as a "possible" sensitive IP > leak. It *is currently* a sensitive IP leak, and is already being exploit= ed > in the wild[1]. > > [1]: https://webrtchacks.com/dear-ny-times/ > I just added "possible" because that is the original subject discussed in this thread, and I didn't want to take part on it :) --=20 I=C3=B1aki Baz Castillo --001a1140c552bb4ccc051b4f1dbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015= -07-20 16:08 GMT+02:00 Daniel Roesler <diafygi@gmail.com>:

> 1) IC= E gathering and possible sensitive IP leak when connecting the STUN/TURN se= rver (decided by the web app) from all the interfaces (those that of course= have a route to the server).
>

A gentle reminder to stop referring to this as a &quo= t;possible" sensitive IP leak. It *is currently* a sensitive IP leak, = and is already being exploited in the wild[1].

[1]: https://webrtchacks.com/dear-ny-times/


I just added "possible" because that is the original subj= ect discussed in this thread, and I didn't want to take part on it :)



--
=
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
--001a1140c552bb4ccc051b4f1dbd-- From nobody Mon Jul 20 07:14:14 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E601A86FE for ; Mon, 20 Jul 2015 07:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCTx2PXx58Ki for ; Mon, 20 Jul 2015 07:14:12 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41761A891C for ; Mon, 20 Jul 2015 07:14:11 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so27989430wic.1 for ; Mon, 20 Jul 2015 07:14:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=loQNwsD/jbItcJUja+WtJDaJkNHjs1R0gQlcvXHMOxs=; b=dphCzzgVo2nlU48Ldri/ar3hMBfoNFdEPt+AT4Zh2zLyJxoAxJclWgOnJaaitVHXVg FV2BZKC1Jt1zbvhcIJ+gEHUS3fefx/S/N3wkoNZ4IifGs1FUYu8FQsqrXtMTu3W9ByJY GUpnTRRxeJTaap+excqyi2RqG48kap8cEqck6Czjl6MvBYtjRNaAS48Ky6+tkmX9nQbC SM4XmGX00fUVS8Qta1r8cmjityE1oWCBosTWQgKYhv60a3Ov+ghaZxsRXLp/STnt2jep uUoR+XtYl/uNkXrfZZoNjKpej3kt/LHXqQuk1XJniWhF6jz2UtOk4FMMTFBzssxXj07X 9m+w== X-Gm-Message-State: ALoCoQnvx5JX4bYGQ5OR6MQHZOQsA8xoKhgCq62wABuqRBFhy/Dr7ih0rNl8Oavf20DuAtDnrZZH X-Received: by 10.180.81.106 with SMTP id z10mr20934271wix.22.1437401650470; Mon, 20 Jul 2015 07:14:10 -0700 (PDT) Received: from dhcp-b3b5.meeting.ietf.org ([2001:67c:370:176:8c28:2ddb:9d64:1c21]) by smtp.googlemail.com with ESMTPSA id pn6sm32201917wjb.36.2015.07.20.07.14.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 07:14:09 -0700 (PDT) Message-ID: <55AD0230.5010903@jive.com> Date: Mon, 20 Jul 2015 16:14:08 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> <55ACF718.3010000@jive.com> <55ACFEFE.3030108@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:14:13 -0000 Le 2015-07-20 16:09, Iñaki Baz Castillo a écrit : > So we are talking about whether the browser should just try the OS > preferred route capable of reaching the STUN server or all the capable ones. Correct. Thanks for re-focusing the discussion. As for this precise question, I don't have an opinion. My intuition is it would perhaps make sense to reflect routing priorities into ICE prioritization or nomination criteria. But that would be very implementation-specific. Simon From nobody Mon Jul 20 07:16:05 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95121A21B2 for ; Mon, 20 Jul 2015 07:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wmwisg1c56ms for ; Mon, 20 Jul 2015 07:16:03 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696DA1A6F1E for ; Mon, 20 Jul 2015 07:16:03 -0700 (PDT) Received: by igbij6 with SMTP id ij6so83176505igb.1 for ; Mon, 20 Jul 2015 07:16:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5IO+5wY20GhjizZBxUrwkgwlKtcTfCuPYymENp96bEc=; b=bmsShXcCHWT+BYa9kj6DB1OjM2z50nMaKDlLvpyH5bW2hIaNI29sH7m1jPnmM+LILg 9ERs7LFemJT20SyYdoeyN4qnNwOPYwsSi41GdpKJGlaxDeO5A5xd+7b0iSCWEGw18LHX 9vkHjAVvkrDwduO5bU/8glqWaD7/8l/qzUaEBefqh3B0K/KnK8joeETv6Thx8uTkYSbL pZwlUN0Jua/qQmZFnaftzti8b0R+3J6pc75InlKgAaC2F2hHv4P6Kf/R+ke4plegL54c mQOMbFTEJoKhzHGLCPaYLNW3a6refGVCqTjh1HBdxpNKm3rUh5HaShNINTiZUMBtUcHg 9bEA== X-Gm-Message-State: ALoCoQmwThXv1lJGMOfNdYpEd/+CqdQyHhOAq0CFnXklm+jKkF8laTqSTksPPFMaWk5kkINytoUn X-Received: by 10.50.138.73 with SMTP id qo9mr15673141igb.64.1437401762932; Mon, 20 Jul 2015 07:16:02 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com. [209.85.213.169]) by smtp.gmail.com with ESMTPSA id rj5sm5327697igc.2.2015.07.20.07.16.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 07:16:01 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so38301888igb.0 for ; Mon, 20 Jul 2015 07:16:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.50.229 with SMTP id f5mr15247652igo.35.1437401760473; Mon, 20 Jul 2015 07:16:00 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Mon, 20 Jul 2015 07:16:00 -0700 (PDT) In-Reply-To: <55ACFEFE.3030108@jive.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> <55ACF718.3010000@jive.com> <55ACFEFE.3030108@jive.com> Date: Mon, 20 Jul 2015 10:16:00 -0400 Message-ID: From: Roman Shpount To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7bd752e4552ce1051b4f2d2d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:16:04 -0000 --047d7bd752e4552ce1051b4f2d2d Content-Type: text/plain; charset=UTF-8 Just to be completely clear, we are talking about the metric parameter in the route. If I set a lower metric on the route to some destination (or if OS sets a lower metric on the route to some destination), I expect this route to be used. On some operating systems, this can be overwritten by explicitly binding to a particular IP address (interface). This breaks things and is somewhat unexpected to the system administrator. This is also something that only happens in case of ICE. No other browser based protocol would send data over a route with higher metric. Regards, _____________ Roman Shpount --047d7bd752e4552ce1051b4f2d2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to be completely clear, we are talking about the metr= ic parameter in the route. If I set a lower metric on the route to some des= tination (or if OS sets a lower metric on the route to some destination), I= expect this route to be used. On some operating systems, this can be overw= ritten by explicitly binding to a particular IP address (interface). This b= reaks things and is somewhat unexpected to the system administrator. This i= s also something that only happens in case of ICE. No other browser based p= rotocol would send data over a route with higher metric.

Regards,
___= __________
Roman Shpount

--047d7bd752e4552ce1051b4f2d2d-- From nobody Mon Jul 20 07:34:24 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4BE1A891C for ; Mon, 20 Jul 2015 07:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDI7sDHXMWbI for ; Mon, 20 Jul 2015 07:34:21 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383361A88F2 for ; Mon, 20 Jul 2015 07:34:21 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6KEVMBQ020549; Mon, 20 Jul 2015 10:34:20 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1vndj4aphf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 10:34:20 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 09:34:19 -0500 From: Jonathan Lennox To: Roman Shpount Thread-Topic: [rtcweb] Please require user consent for data channels Thread-Index: AQHQwvidATEJsjYDbE6MWOsdwYypdJ3kwDCA Date: Mon, 20 Jul 2015 14:34:18 +0000 Message-ID: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> <55ACF718.3010000@jive.com> <55ACFEFE.3030108@jive.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.179.79] Content-Type: multipart/alternative; boundary="_000_A7E395E37C4D4C2EBC677F3619FF30A5vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-20_03:2015-07-20,2015-07-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507200236 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:34:22 -0000 --_000_A7E395E37C4D4C2EBC677F3619FF30A5vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdWwgMjAsIDIwMTUsIGF0IDQ6MTYgUE0sIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVy aXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KDQpKdXN0IHRvIGJlIGNv bXBsZXRlbHkgY2xlYXIsIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBtZXRyaWMgcGFyYW1ldGVy IGluIHRoZSByb3V0ZS4gSWYgSSBzZXQgYSBsb3dlciBtZXRyaWMgb24gdGhlIHJvdXRlIHRvIHNv bWUgZGVzdGluYXRpb24gKG9yIGlmIE9TIHNldHMgYSBsb3dlciBtZXRyaWMgb24gdGhlIHJvdXRl IHRvIHNvbWUgZGVzdGluYXRpb24pLCBJIGV4cGVjdCB0aGlzIHJvdXRlIHRvIGJlIHVzZWQuIE9u IHNvbWUgb3BlcmF0aW5nIHN5c3RlbXMsIHRoaXMgY2FuIGJlIG92ZXJ3cml0dGVuIGJ5IGV4cGxp Y2l0bHkgYmluZGluZyB0byBhIHBhcnRpY3VsYXIgSVAgYWRkcmVzcyAoaW50ZXJmYWNlKS4gVGhp cyBicmVha3MgdGhpbmdzIGFuZCBpcyBzb21ld2hhdCB1bmV4cGVjdGVkIHRvIHRoZSBzeXN0ZW0g YWRtaW5pc3RyYXRvci4gVGhpcyBpcyBhbHNvIHNvbWV0aGluZyB0aGF0IG9ubHkgaGFwcGVucyBp biBjYXNlIG9mIElDRS4gTm8gb3RoZXIgYnJvd3NlciBiYXNlZCBwcm90b2NvbCB3b3VsZCBzZW5k IGRhdGEgb3ZlciBhIHJvdXRlIHdpdGggaGlnaGVyIG1ldHJpYy4NCg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWlmLWhhcHB5LWV5ZWJhbGxzLWV4dGVuc2lvbg0KDQpB cHBsZSBoYXMgYW5ub3VuY2VkIHRoYXQgdGhlaXIgSFRUUCBjbGllbnQgaW1wbGVtZW50YXRpb24g d2lsbCBkbyAoc29tZXRoaW5nIGxpa2UpIHRoaXMgaW4gaU9TIDksIHRvIHNvbHZlIHRoZSDigJxQ YXJraW5nIGxvdCBXaUZp4oCdIHByb2JsZW0uDQoNCg== --_000_A7E395E37C4D4C2EBC677F3619FF30A5vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9010C0E69A1C7D428CE6FFCD846616AE@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwg MjAsIDIwMTUsIGF0IDQ6MTYgUE0sIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpy b21hbkB0ZWx1cml4LmNvbSIgY2xhc3M9IiI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SnVzdCB0byBiZSBjb21wbGV0ZWx5IGNs ZWFyLCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgbWV0cmljIHBhcmFtZXRlciBpbiB0aGUgcm91 dGUuIElmIEkgc2V0IGEgbG93ZXIgbWV0cmljIG9uIHRoZSByb3V0ZSB0byBzb21lIGRlc3RpbmF0 aW9uIChvciBpZiBPUyBzZXRzIGEgbG93ZXIgbWV0cmljIG9uIHRoZSByb3V0ZSB0byBzb21lIGRl c3RpbmF0aW9uKSwgSSBleHBlY3QgdGhpcyByb3V0ZSB0byBiZQ0KIHVzZWQuIE9uIHNvbWUgb3Bl cmF0aW5nIHN5c3RlbXMsIHRoaXMgY2FuIGJlIG92ZXJ3cml0dGVuIGJ5IGV4cGxpY2l0bHkgYmlu ZGluZyB0byBhIHBhcnRpY3VsYXIgSVAgYWRkcmVzcyAoaW50ZXJmYWNlKS4gVGhpcyBicmVha3Mg dGhpbmdzIGFuZCBpcyBzb21ld2hhdCB1bmV4cGVjdGVkIHRvIHRoZSBzeXN0ZW0gYWRtaW5pc3Ry YXRvci4gVGhpcyBpcyBhbHNvIHNvbWV0aGluZyB0aGF0IG9ubHkgaGFwcGVucyBpbiBjYXNlIG9m IElDRS4gTm8gb3RoZXINCiBicm93c2VyIGJhc2VkIHByb3RvY29sIHdvdWxkIHNlbmQgZGF0YSBv dmVyIGEgcm91dGUgd2l0aCBoaWdoZXIgbWV0cmljLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWlmLWhhcHB5LWV5ZWJhbGxzLWV4dGVuc2lvbiIgY2xh c3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWlmLWhhcHB5LWV5 ZWJhbGxzLWV4dGVuc2lvbjwvYT48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PkFwcGxlIGhhcyBhbm5vdW5jZWQgdGhhdCB0aGVpciBIVFRQIGNsaWVudCBpbXBsZW1lbnRh dGlvbiB3aWxsIGRvIChzb21ldGhpbmcgbGlrZSkgdGhpcyBpbiBpT1MgOSwgdG8gc29sdmUgdGhl IOKAnFBhcmtpbmcgbG90IFdpRmnigJ0gcHJvYmxlbS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A7E395E37C4D4C2EBC677F3619FF30A5vidyocom_-- From nobody Mon Jul 20 07:35:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83011A88F2 for ; Mon, 20 Jul 2015 07:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 587X_FxJ4xmY for ; Mon, 20 Jul 2015 07:35:16 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40731A890D for ; Mon, 20 Jul 2015 07:35:15 -0700 (PDT) Received: by iehx8 with SMTP id x8so38785634ieh.3 for ; Mon, 20 Jul 2015 07:35:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HRu0b806Y9D3JYhtnKfqk/WA7ARjJQuUUmpn6ghqXCs=; b=l0RB9+M9r6uaDKQBV9VdLLuCFvOrzGCuLB4zsEAnW1UmhaUJyOYYHox5GXv4q+LdpN aD/uE1denYjAjOdwpgH/R4dQBMli2zNQq1zXkFA8lZl+ZDTlTXNDeJkSA03mcMfYrEeY aYxn6faUzvsCEcELkRfBkIiztUFqEgabVb4ATGE6//GcfJsjO3OuASM4logMBXuHAVzN ZKl8quupSB7Lbr9WXFEHiptn722gDjiGpW47Jr2jKg7geCAOAVAhBbWsbtvrWNElWhHy QnufwG4jvxk28xtfmQDzv+GECzuUXrouYBQEwOSVrT4szPuXahzQuVqgtmllSAGf54D3 e2vQ== X-Gm-Message-State: ALoCoQlKe2zfxYE3NCt7Un0B4JdFzAszuLNWHBse/Z0opjP63IxJUvHsKoWLgbf6TgPCfHbm1xKf X-Received: by 10.107.3.224 with SMTP id e93mr29389802ioi.160.1437402913898; Mon, 20 Jul 2015 07:35:13 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com. [209.85.213.169]) by smtp.gmail.com with ESMTPSA id w4sm5329221igl.22.2015.07.20.07.35.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 07:35:12 -0700 (PDT) Received: by igvi1 with SMTP id i1so78076639igv.1 for ; Mon, 20 Jul 2015 07:35:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.7.214 with SMTP id g83mr40841337ioi.28.1437402539913; Mon, 20 Jul 2015 07:28:59 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Mon, 20 Jul 2015 07:28:59 -0700 (PDT) In-Reply-To: <55AABE28.8070105@jive.com> References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <55AABE28.8070105@jive.com> Date: Mon, 20 Jul 2015 10:28:59 -0400 Message-ID: From: Roman Shpount To: Simon Perreault Content-Type: multipart/alternative; boundary=001a113f911cca7a25051b4f5ba5 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:35:21 -0000 --001a113f911cca7a25051b4f5ba5 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 18, 2015 at 4:59 PM, Simon Perreault wrote: > This is a concept that was explained during the ICE tutorial that was > presented at IETF 92. > > Imagine the following multihomed host with three interfaces: > > - Wi-fi interface with default route. > - Wired interface with default route. > - VPN interface with default route. > On the multihomed host, all the default routes will have different metrics. In some cases these metrics are automatically calculated by OS. In some cases, they are set by the system administrator. In either case, ICE ignores the metric value and tries to route over all interfaces. This is unexpected and can be considered a violation of the local policy (i.e. if administrator added a route with a lower metric, it expects it to be used). No other browser protocol does this. > Which one should you use to talk to the STUN/TURN server? If you bind to > 0.0.0.0 then the kernel *will* pick one, but only because it *has to. > All three interfaces are equivalent: they all have a default route and > can a priori be used to talk to the server. > See above, this is not the case. All interfaces have a default route but they are not equal. If they were equal, OS will round robin among them. Being multihomed means multiple interfaces with a default route. There's > no "going against the local policy" in this case when sending packets on > any interface. > Once again, this is not the case. Metric value on the interface is local policy and should be respected. > The point is that in this case, all three interfaces can potentially > yield different server-reflexive candidates, which is why they must be > gathered separately. As for relayed candidates, they also need to be > gathered separately because some interfaces may be faster for talking to > the TURN server and it is useful to compare the candidates gathered on > all 3 interfaces. Also nothing guarantees that you're allowed to reach > the server server on any interface that has a default route, so you need > to try them all. > This is a policy decision on the local computer. As a network administrator I should be able to specified the preferred default route. It does not mean that I should remove the default routes for all the other interfaces. Setting a metric should be enough. On the other hand, if I prefer the browser to pick the best connection on its own, I should be able to allow this as well, but this is going to be a much less common case. Taking into account potential privacy or financial implications of this choice, I think the browser should error on the side of caution. _____________ Roman Shpount --001a113f911cca7a25051b4f5ba5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jul 18, 2015 at 4:59 PM, Simon Perreault <sperreault@jive.com&g= t; wrote:
This is a concept that was explained d= uring the ICE tutorial that was
presented at IETF 92.

Imagine the following multihomed host with three interfaces:

- Wi-fi interface with default route.
- Wired interface with default route.
- VPN interface with default route.

On = the multihomed host, all the default routes will have different metrics. In= some cases these metrics are automatically calculated by OS. In some cases= , they are set by the system administrator. In either case, ICE ignores the= metric value and tries to route over all interfaces. This is unexpected an= d can be considered a violation of the local policy (i.e. if administrator = added a route with a lower metric, it expects it to be used). No other brow= ser protocol does this.
=C2=A0
Which one sh= ould you use to talk to the STUN/TURN server? If you bind to
0.0.0.0 then the kernel *will* pick one, but only because it *has to.
All three interfaces are equivalent: they all have a default route and
can a priori be used to talk to the server.

=
See above, this is not the case. All interfaces have a default route b= ut they are not equal. If they were equal, OS will round robin among them.<= /div>

Being multihomed means multiple interf= aces with a default route. There's
no "going against the local policy" in this case when sending pac= kets on
any interface.

Once again, this is not = the case. Metric value on the interface is local policy and should be respe= cted.
=C2=A0
The point is that in this case= , all three interfaces can potentially
yield different server-reflexive candidates, which is why they must be
gathered separately. As for relayed candidates, they also need to be
gathered separately because some interfaces may be faster for talking to the TURN server and it is useful to compare the candidates gathered on
all 3 interfaces. Also nothing guarantees that you're allowed to reach<= br> the server server on any interface that has a default route, so you need to try them all.

This is a policy decis= ion on the local computer. As a network administrator I should be able to s= pecified the preferred default route. It does not mean that I should remove= the default routes for all the other interfaces. Setting a metric should b= e enough. On the other hand, if I prefer the browser to pick the best conne= ction on its own, I should be able to allow this as well, but this is going= to be a much less common case. Taking into account potential privacy or fi= nancial implications of this choice, I think the browser should error on th= e side of caution.

= _____________
Roman Shpount
=C2=A0
--001a113f911cca7a25051b4f5ba5-- From nobody Mon Jul 20 07:50:06 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05C51A896A for ; Mon, 20 Jul 2015 07:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxVCAkpV8x3n for ; Mon, 20 Jul 2015 07:50:03 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073691A88A7 for ; Mon, 20 Jul 2015 07:50:03 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so83173478igb.0 for ; Mon, 20 Jul 2015 07:50:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gZz9KRmimMTraUaXSNLywfIoQx0vW8ui/eUWTGGW6dk=; b=BxuL8y9dnaXqsRz+pJ4ETN4wj3JQSJbTqVQNXoUa9AJhAAed75Axj6P7gOJCAL+UR3 QYH5uU0UbDDp8AGvWkxBnwcMJ8UVW89egJxlf/68/bt+UmKPNMJjsAmyfspHZhYNIRcy ut8Zv2PKzuiu9an1b+TDn/i6HPabCaFEx+8jkyx9LOwecjGHoZX7i6EKaoxSSnqkaTf9 dOcPHv3rjiL+XPC/6ExFN4gUrAJlc6Ii6zHWNLFo4ENjTDYdAYUxanm4z5Rhg1kWpnRq yZVDMva9XAwZi1MyLg7K4/78M/4ge3xXISJExgJrHw3+DtZl2enJMS6IrotyB4LcyFqy qsiQ== X-Gm-Message-State: ALoCoQnHGb6JgpEdNe3t7Ltgm5t7UVgFtocCuP6mCL9ReBU8UMgcY5saRFCbd0Ckz7lLIFGTH3VO X-Received: by 10.107.33.65 with SMTP id h62mr35741323ioh.11.1437403802373; Mon, 20 Jul 2015 07:50:02 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com. [209.85.213.178]) by smtp.gmail.com with ESMTPSA id 76sm13840927iom.12.2015.07.20.07.50.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 07:50:01 -0700 (PDT) Received: by igbij6 with SMTP id ij6so84011088igb.1 for ; Mon, 20 Jul 2015 07:50:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.142.69 with SMTP id ru5mr15872025igb.61.1437403800151; Mon, 20 Jul 2015 07:50:00 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Mon, 20 Jul 2015 07:49:59 -0700 (PDT) In-Reply-To: <55AB4FEC.7050805@alvestrand.no> References: <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <55AABE28.8070105@jive.com> <913383AAA69FF945B8F946018B75898A47894E34@xmb-rcd-x10.cisco.com> <55AB4FEC.7050805@alvestrand.no> Date: Mon, 20 Jul 2015 10:49:59 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11c3b908e8380a051b4fa6a6 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:50:04 -0000 --001a11c3b908e8380a051b4fa6a6 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 19, 2015 at 3:21 AM, Harald Alvestrand wrote: > Solutions we engineer MUST work in the current Internet. > I agree completely. > +1 to Simon - the way systems are designed, implemented and deployed > *now*, there may be multiple interfaces with multiple default addresses, > and there's nothing intrinsically illegal, immoral or fattening about an > application accessing them. > If a local system administrator set a lower metric to a particular default (or any other route) vs all the other routes to a certain destination, this route should be used to reach this destination. This is the normal behavior for all other network communications from the browser (HTTP. WebSockets, or even FTP or gopher). With ICE, browsers depart from this model. I understand that this can enable browsers to set up a WebRTC media connection where it would not be able to do so otherwise. On other hand using secondary routes can produce some unexpected results, such as exposing reflexive addresses on secondary interfaces or sending data over LTE network when WiFi is available. I think using secondary routes should only be enabled after user consent or if an appropriate browser setting is enabled. In wast majority of cases, primary default route is sufficient to set up the WebRTC connection. My assumption is that using secondary default routes only improves the chances of connection in extremely small number of cases. Based on the systems I have worked with, we are talking about less then 1/10 of the percent of end users. Regards, _____________ Roman Shpount --001a11c3b908e8380a051b4fa6a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 19, 2015 at 3:21 AM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:
Solutions we engineer MUST work in the current Internet.

I agree completely.
=C2=A0
+1 to Simon - the way systems are designed, implemented and = deployed
*now*, there may be multiple interfaces with multiple default addresses, and there's nothing intrinsically illegal, immoral or fattening about a= n
application accessing them.

If a local = system administrator set a lower metric to a particular default (or any oth= er route) vs all the other routes to a certain destination, this route shou= ld be used to reach this destination. This is the normal behavior for all o= ther network communications from the browser (HTTP. WebSockets, or even FTP= or gopher). With ICE, browsers depart from this model. I understand that t= his can enable browsers to set up a WebRTC media connection where it would = not be able to do so otherwise. On other hand using secondary routes can pr= oduce some unexpected results, such as exposing reflexive addresses on seco= ndary interfaces or sending data over LTE network when WiFi is available. I= think using secondary routes should only be enabled after user consent or = if an appropriate browser setting is enabled. In wast majority of cases, pr= imary default route is sufficient to set up the WebRTC connection. My assum= ption is that using secondary default routes only improves the chances of c= onnection in extremely small number of cases. Based on the systems I have w= orked with, we are talking about less then 1/10 of the percent of end users= .

Regards,
_____________
Roman Shpount
=C2=A0
--001a11c3b908e8380a051b4fa6a6-- From nobody Mon Jul 20 07:58:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248141A8A4D for ; Mon, 20 Jul 2015 07:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoVUZJpqTBpL for ; Mon, 20 Jul 2015 07:58:56 -0700 (PDT) Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0841C1A8A42 for ; Mon, 20 Jul 2015 07:58:54 -0700 (PDT) Received: by ykay190 with SMTP id y190so140545984yka.3 for ; Mon, 20 Jul 2015 07:58:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oRI1ci8fFzqT0hxPOU9zhilHK7Nd4SJ+da+/9QV/YR4=; b=AeDNcDNapzqsxJm48TVumwwq2JNZkihW1GuV5YKByv82olGRdkKlPi0Ntba2bW9KLw MKVcpWYLAYrEJgWyCKkUdVNs1ijkfDP9ff/Ioo/Ard0eLz5xow6ICzL8yrePcjd/HtLE BAls74HefiqqlsOk8/wNQrZk2ZEx/yHvUh9DQftwC7+qe7yOJS9ZWL0mJu91iMlV7sKL x9W48bDjKUcBiFa51rZhV3mXUylBr36XQ6/yPcvjn6k2sF2MRouDJocp9oJu7H0b5BVz 1vs8fSr2hpGZLhgZIm/o+jG50GtFsCleG/6kQ1Tyu/INHS+25+1GmfG8qRGA3t8Nsoj1 cR7Q== X-Gm-Message-State: ALoCoQlGi4z3fxUrCD66TT4qanq9PWkvD7LvSftsWzlLBJm2GxMgyF9MaqKCf4wPqjzdc3mLkikP X-Received: by 10.13.255.2 with SMTP id p2mr11537090ywf.149.1437404333366; Mon, 20 Jul 2015 07:58:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Mon, 20 Jul 2015 07:58:33 -0700 (PDT) In-Reply-To: References: <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> <55AABE28.8070105@jive.com> <913383AAA69FF945B8F946018B75898A47894E34@xmb-rcd-x10.cisco.com> <55AB4FEC.7050805@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Jul 2015 16:58:33 +0200 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=94eb2c0888f6b08d9b051b4fc6ce Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:58:58 -0000 --94eb2c0888f6b08d9b051b4fc6ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-07-20 16:49 GMT+02:00 Roman Shpount : > If a local system administrator set a lower metric to a particular defaul= t > (or any other route) vs all the other routes to a certain destination, th= is > route should be used to reach this destination. This is the normal behavi= or > for all other network communications from the browser (HTTP. WebSockets, = or > even FTP or gopher). With ICE, browsers depart from this model. I > understand that this can enable browsers to set up a WebRTC media > connection where it would not be able to do so otherwise. On other hand > using secondary routes can produce some unexpected results, such as > exposing reflexive addresses on secondary interfaces or sending data over > LTE network when WiFi is available. I think using secondary routes should > only be enabled after user consent or if an appropriate browser setting i= s > enabled. In wast majority of cases, primary default route is sufficient t= o > set up the WebRTC connection. My assumption is that using secondary defau= lt > routes only improves the chances of connection in extremely small number = of > cases. Based on the systems I have worked with, we are talking about less > then 1/10 of the percent of end users. > Agreed. Important concerns here are: 1) The app (browser) should respect the routing local policy. It means that it should consider the metric/priority of the capable routes (as the administrator or OS decided), or that it should just use the best one (but this may also cause issues as stated in next bullet). 2) If the browser also uses a secondary capable route it may cause real mon= ey (if for example the secondary route goes through a LTE interface while the primary route is WiFi based). --=20 I=C3=B1aki Baz Castillo --94eb2c0888f6b08d9b051b4fc6ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015= -07-20 16:49 GMT+02:00 Roman Shpount <roman@telurix.com>:
If a local system administrator set a lower metric t= o a particular default (or any other route) vs all the other routes to a ce= rtain destination, this route should be used to reach this destination. Thi= s is the normal behavior for all other network communications from the brow= ser (HTTP. WebSockets, or even FTP or gopher). With ICE, browsers depart fr= om this model. I understand that this can enable browsers to set up a WebRT= C media connection where it would not be able to do so otherwise. On other = hand using secondary routes can produce some unexpected results, such as ex= posing reflexive addresses on secondary interfaces or sending data over LTE= network when WiFi is available. I think using secondary routes should only= be enabled after user consent or if an appropriate browser setting is enab= led. In wast majority of cases, primary default route is sufficient to set = up the WebRTC connection. My assumption is that using secondary default rou= tes only improves the chances of connection in extremely small number of ca= ses. Based on the systems I have worked with, we are talking about less the= n 1/10 of the percent of end users.

= Agreed. Important concerns here are:

1) The app (browser) should respect the rout= ing local policy. It means that it should consider the metric/priority of t= he capable routes (as the administrator or OS decided), or that it should j= ust use the best one (but this may also cause issues as stated in next bull= et).

2= ) If the browser also uses a secondary capable route it may cause=C2=A0real=C2=A0money (if for example the secondary route goes = through a LTE interface while the primary route is WiFi based).

<= br>
--
I=C3=B1aki Baz Castillo
&= lt;ibc@aliax.net>=
--94eb2c0888f6b08d9b051b4fc6ce-- From nobody Tue Jul 21 01:12:10 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BC11B29AF for ; Tue, 21 Jul 2015 01:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsHcUrynPn2X for ; Tue, 21 Jul 2015 01:12:07 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280E71AD49D for ; Tue, 21 Jul 2015 01:12:07 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so112788310wib.0 for ; Tue, 21 Jul 2015 01:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZY+2TQfxKggYba8DtFJzOMfrJtcumG6v1e9Fa7PoOkc=; b=mTzVOD6t2qRKI7dga2BnqBzz9FBnrgYZ6NUgzJTdrf+s9CcdqXUf4jtI8ENgfwMLkU QoOnRqIxshMEW17Ke626kqfHVNev79lQz+mdWZ2pwRVHg1gUZBbRFcdo456QiXzORwL/ BX3MlbOML4FZMjER03dbkVSerwo3rIkMRSjUvV89MQU6uznxecNT8eqijzMC/JO6guNg YLXagE1ZuXBPA1r59Z3+qKNRJfdqGNjNOOuYCI4ysAaLLL5NzXQg1kyZRWYjKDsZhb1T HwnleShRZRG6V7BJDwbMmQVT1JkOYrGiDt5qe91VragR2+RiFQrIcNrzGxm5ShjI3S/N 2iIA== X-Received: by 10.194.93.226 with SMTP id cx2mr63293610wjb.28.1437466325901; Tue, 21 Jul 2015 01:12:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.64.215 with HTTP; Tue, 21 Jul 2015 01:11:46 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E7FBFE7@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E7FBFE7@MCHP04MSX.global-ad.net> From: Bernard Aboba Date: Tue, 21 Jul 2015 10:11:46 +0200 Message-ID: To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=047d7bb04c1abb6f3c051b5e35da Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP and -return- ICE Candidate Policy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 08:12:09 -0000 --047d7bb04c1abb6f3c051b5e35da Content-Type: text/plain; charset=UTF-8 Andrew said: "It seems something is wrong here " [BA] I do not believe that is true. With respect to privacy, we have had two parallel discussions, reflecting two distinct threats. The original discussion centered around API-based control of ICE candidate policy, but the most recent one has been about malevolent JS that requires mitigation outside of the API, such as browser settings that could be considered "local". On Mon, Jul 20, 2015 at 2:35 PM, Hutton, Andrew wrote: > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-11#section-3.4.3 talks > about the application having control over the ICE Candidate Policy > (RTCIceTransportPolicy) but it also contains the following statement > regarding local policy: > > "In addition, administrators may also wish to control the set of ICE > candidates, and so the browser SHOULD also allow control via local policy, > with the most restrictive policy prevailing". > > This seems to imply that the admin and application policies are > controlling the same functionality in the browser but is this really true? > > https://tools.ietf.org/html/draft-ietf-rtcweb-return-00#section-4.3 also > refers to to the ICE candidate policy section of JSEP and indicates states > that: > > "Proxy configuration, including leakiness, maybe set by local policy > ([I-D.ietf-rtcweb-jsep], "ICE candidate policy") or other mechanisms". > > It seems something is wrong here and probably JSEP should not be talking > about the local policy as I assume this would not use the PeerConnection > API and the -return- draft should not be referring to JSEP regarding this > local policy as again this will not use the PC API. > > Andy > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bb04c1abb6f3c051b5e35da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andrew said:

"It seems= something is wrong here "

[BA] I do not beli= eve that is true.=C2=A0 With respect to privacy, we have had two parallel d= iscussions, reflecting two distinct threats.=C2=A0 The original discussion = centered around API-based control of ICE candidate policy, but the most rec= ent one has been about malevolent JS that requires mitigation outside of th= e API, such as browser settings that could be considered "local".= =C2=A0

On Mon, Jul 20, 2015 at 2:35 PM, Hutton, Andrew <andrew.hutton@uni= fy.com> wrote:
https://tools.ietf.org/html/draft-ietf-rtcwe= b-jsep-11#section-3.4.3 talks about the application having control over= the ICE Candidate Policy (RTCIceTransportPolicy) but it also contains the = following statement regarding local policy:

"In addition, administrators may also wish to control the set of ICE c= andidates, and so the browser SHOULD also allow control via local policy, w= ith the most restrictive policy prevailing".

This seems to imply that the admin and application policies are controlling= the same functionality in the browser but is this really true?

https://tools.ietf.org/html/draft= -ietf-rtcweb-return-00#section-4.3 also refers to to the ICE candidate = policy section of JSEP and indicates states that:

"Proxy configuration, including leakiness, maybe set by local policy (= [I-D.ietf-rtcweb-jsep], "ICE candidate policy") or other mechanis= ms".

It seems something is wrong here and probably JSEP should not be talking ab= out the local policy as I assume this would not use the PeerConnection API = and the -return- draft should not be referring to JSEP regarding this local= policy as again this will not use the PC API.

Andy

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bb04c1abb6f3c051b5e35da-- From nobody Tue Jul 21 01:27:47 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78C91B2A99 for ; Tue, 21 Jul 2015 01:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3la0gpXygZ0s for ; Tue, 21 Jul 2015 01:27:45 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E9DDC1B2A9B for ; Tue, 21 Jul 2015 01:27:44 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id DF75B23F0454; Tue, 21 Jul 2015 10:27:43 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0224.002; Tue, 21 Jul 2015 10:27:43 +0200 From: "Hutton, Andrew" To: Bernard Aboba Thread-Topic: [rtcweb] JSEP and -return- ICE Candidate Policy Thread-Index: AdDC6JNGvnJs4lAgQ4uNEahe4IEIvQAk4vkAAAR/0MA= Date: Tue, 21 Jul 2015 08:27:42 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E7FD721@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E7FBFE7@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP and -return- ICE Candidate Policy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 08:27:47 -0000 T246IDIxIEp1bHkgMjAxNSAxMDoxMiBCZXJuYXJkIEFib2JhIFdyb3RlOg0KPiANCj4gQW5kcmV3 IHNhaWQ6DQo+IA0KPiAiSXQgc2VlbXMgc29tZXRoaW5nIGlzIHdyb25nIGhlcmUgIg0KPiANCj4g W0JBXSBJIGRvIG5vdCBiZWxpZXZlIHRoYXQgaXMgdHJ1ZS7CoCBXaXRoIHJlc3BlY3QgdG8gcHJp dmFjeSwgd2UgaGF2ZQ0KPiBoYWQgdHdvIHBhcmFsbGVsIGRpc2N1c3Npb25zLCByZWZsZWN0aW5n IHR3byBkaXN0aW5jdCB0aHJlYXRzLsKgIFRoZQ0KPiBvcmlnaW5hbCBkaXNjdXNzaW9uIGNlbnRl cmVkIGFyb3VuZCBBUEktYmFzZWQgY29udHJvbCBvZiBJQ0UgY2FuZGlkYXRlDQo+IHBvbGljeSwg YnV0IHRoZSBtb3N0IHJlY2VudCBvbmUgaGFzIGJlZW4gYWJvdXQgbWFsZXZvbGVudCBKUyB0aGF0 DQo+IHJlcXVpcmVzIG1pdGlnYXRpb24gb3V0c2lkZSBvZiB0aGUgQVBJLCBzdWNoIGFzIGJyb3dz ZXIgc2V0dGluZ3MgdGhhdA0KPiBjb3VsZCBiZSBjb25zaWRlcmVkICJsb2NhbCIuDQo+IA0KDQpV bmRlcnN0b29kIHRoZSBvbmx5IHRoaW5nIHRoYXQgSSB0aGluayBpcyB3cm9uZyBpcyB0aGF0IHRo ZSAtcmV0dXJuLSBkcmFmdHMgcmVmZXJzIHRvIHRoZSBJQ0UgQ2FuZGlkYXRlIFBvbGljeSBpbiBK U0VQIGFzIHRoZSBtZWNoYW5pc20gZm9yIGNvbnRyb2xsaW5nIHRoZSBsb2NhbCBwb2xpY3kgd2hp Y2ggYXMgeW91IHNheSBzaG91bGQgYmUgc29tZXRoaW5nIG91dHNpZGUgb2YgdGhlIEFQSS4NCg0K VW5sZXNzIEkgbWlzdW5kZXJzdG9vZCBzb21ldGhpbmcgd2UgYXJlIGluIGFncmVlbWVudC4NCg0K QW5keQ0K From nobody Tue Jul 21 06:36:50 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32E61B2DB7 for ; Tue, 21 Jul 2015 06:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGJvhJ-LX7wf for ; Tue, 21 Jul 2015 06:36:44 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F6E1B2DA2 for ; Tue, 21 Jul 2015 06:36:44 -0700 (PDT) Received: by igr7 with SMTP id 7so40564620igr.0 for ; Tue, 21 Jul 2015 06:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vWGd2TzEtnI4o+uiN45DWBLwy0FR4ah5RlxFXmB2uPw=; b=DLIHz/eF50EtAK5cqmOQRMRH+LsyPQ/AB6C+LlfakC4lOYoNnwHI4akdWAE6FfaX6P wUtLnuRRqM0KDd1C1nLR8YqAIRwKJ2jTLHkHQdlyVBonMrB/JsH0TFk3fiH3ai6QKGVJ BmuL7rSLIEjhEwqaOwuzM2AE2BDpFikvkYXLgCP1Q3iLfAasKPcNMBzqz7u5dpU5GvkW 4FGqfMgHR4kxBdg0kqkdgBMlGY3sRdsIR6ZwR/rNHFlDBnuW5wshwd58HwVyCrMF4C/+ 01oXYbJ57mS6aekzUEmDAGVhGNyznTydbNrAGhSar9Lygs3rYzmKSoHJBlOjLuXJ4i5e IBpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vWGd2TzEtnI4o+uiN45DWBLwy0FR4ah5RlxFXmB2uPw=; b=CzaMF/ez8/ID01QYEJc11XiOq6zFaUg5hLM2Fuk73JUsEEZGjjN4W6S6MmCzoHfUpb pc/CsPXvHM3nww4o7YNGoDAVHM4aqydyF8G8OatRBwJEko+LRwLShRjEXg4zDLdAmekX LLOvbD+MmEH4Lj9jUg8OJwNL9Y5RTnGNEWFLxxFpp99MG7IMqNl5j9fSKSpW6dZ5wJr5 1SrMMQZ+cyndw/dcnJdZAG0zkLaZz+7kYl7oi4fpY6ROTx7khWLBIyyqjG7pfEuHcYua PuRZe5ThQOu0u0wxQKIxsHjEWZGv19Vf6f235Z7cvoWIh91iJSNaee5dE/2MosMnkOTX MN0Q== X-Gm-Message-State: ALoCoQn7U3yBacMjBgIg098K/uvT0LZiZsToPbkfPP+1fJL/PPhg9DpYgJENXbc/TxMI04Lb+EhP X-Received: by 10.107.132.154 with SMTP id o26mr19467584ioi.3.1437485803281; Tue, 21 Jul 2015 06:36:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.234 with HTTP; Tue, 21 Jul 2015 06:36:23 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E7FD721@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E7FBFE7@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E7FD721@MCHP04MSX.global-ad.net> From: Justin Uberti Date: Tue, 21 Jul 2015 06:36:23 -0700 Message-ID: To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=001a113f2782ace79c051b62bebe Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP and -return- ICE Candidate Policy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 13:36:46 -0000 --001a113f2782ace79c051b62bebe Content-Type: text/plain; charset=UTF-8 I think the confusion is regarding the use of RTCIceTransportPolicy. Clearly that doesn't make sense in the RETURN context. The point though is that the browser may have additional local policy, separate from RTCIceTransportPolicy, that governs what candidates it exposes. On Tue, Jul 21, 2015 at 1:27 AM, Hutton, Andrew wrote: > On: 21 July 2015 10:12 Bernard Aboba Wrote: > > > > Andrew said: > > > > "It seems something is wrong here " > > > > [BA] I do not believe that is true. With respect to privacy, we have > > had two parallel discussions, reflecting two distinct threats. The > > original discussion centered around API-based control of ICE candidate > > policy, but the most recent one has been about malevolent JS that > > requires mitigation outside of the API, such as browser settings that > > could be considered "local". > > > > Understood the only thing that I think is wrong is that the -return- > drafts refers to the ICE Candidate Policy in JSEP as the mechanism for > controlling the local policy which as you say should be something outside > of the API. > > Unless I misunderstood something we are in agreement. > > Andy > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113f2782ace79c051b62bebe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the confusion is regarding the use of=C2=A0RTCIceTransportPolicy. Clearly that doesn't m= ake sense in the RETURN context.

The point though i= s that the browser may have additional local policy, separate from RTCIceTr= ansportPolicy, that governs what candidates it exposes.
<= div class=3D"gmail_extra">
On Tue, Jul 21, 20= 15 at 1:27 AM, Hutton, Andrew <andrew.hutton@unify.com> wrote:
On: 21 July 201= 5 10:12 Bernard Aboba Wrote:
>
> Andrew said:
>
> "It seems something is wrong here "
>
> [BA] I do not believe that is true.=C2=A0 With respect to privacy, we = have
> had two parallel discussions, reflecting two distinct threats.=C2=A0 T= he
> original discussion centered around API-based control of ICE candidate=
> policy, but the most recent one has been about malevolent JS that
> requires mitigation outside of the API, such as browser settings that<= br> > could be considered "local".
>

Understood the only thing that I think is wrong is that the -return-= drafts refers to the ICE Candidate Policy in JSEP as the mechanism for con= trolling the local policy which as you say should be something outside of t= he API.

Unless I misunderstood something we are in agreement.

Andy
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a113f2782ace79c051b62bebe-- From nobody Tue Jul 21 07:11:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC4D1A885B for ; Tue, 21 Jul 2015 07:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xri2ZTTxBAOH for ; Tue, 21 Jul 2015 07:11:39 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4936E1A8859 for ; Tue, 21 Jul 2015 07:11:39 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 67DDD23F041D; Tue, 21 Jul 2015 16:11:38 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0224.002; Tue, 21 Jul 2015 16:11:37 +0200 From: "Hutton, Andrew" To: Justin Uberti Thread-Topic: [rtcweb] JSEP and -return- ICE Candidate Policy Thread-Index: AdDC6JNGvnJs4lAgQ4uNEahe4IEIvQAk4vkAAAR/0MAABtZ8gAAFOKIA Date: Tue, 21 Jul 2015 14:11:36 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E7FE415@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E7FBFE7@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E7FD721@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP and -return- ICE Candidate Policy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:11:40 -0000 T246IDIxIEp1bHkgMjAxNSAxNTozNiBKdXN0aW4gVWJlcnRpIFdyb3RlOg0KPiANCj4gSSB0aGlu ayB0aGUgY29uZnVzaW9uIGlzIHJlZ2FyZGluZyB0aGUgdXNlIG9mwqBSVENJY2VUcmFuc3BvcnRQ b2xpY3kuDQo+IENsZWFybHkgdGhhdCBkb2Vzbid0IG1ha2Ugc2Vuc2UgaW4gdGhlIFJFVFVSTiBj b250ZXh0Lg0KDQpFeGFjdGx5IHRoZSBjdXJyZW50IC1yZXR1cm4tIGRyYWZ0IHJlZmVycyB0byBS VENJY2VUcmFuc3BvcnRQb2xpY3ksDQoNCj4gDQo+IFRoZSBwb2ludCB0aG91Z2ggaXMgdGhhdCB0 aGUgYnJvd3NlciBtYXkgaGF2ZSBhZGRpdGlvbmFsIGxvY2FsIHBvbGljeSwNCj4gc2VwYXJhdGUg ZnJvbSBSVENJY2VUcmFuc3BvcnRQb2xpY3ksIHRoYXQgZ292ZXJucyB3aGF0IGNhbmRpZGF0ZXMg aXQNCj4gZXhwb3Nlcy4NCg0KQWdyZWVkLg0KDQpBbmR5DQo= From nobody Tue Jul 21 07:21:01 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053421B2E33 for ; Tue, 21 Jul 2015 07:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apEPYBPTg2k1 for ; Tue, 21 Jul 2015 07:20:59 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F302D1B2E60 for ; Tue, 21 Jul 2015 07:20:46 -0700 (PDT) Received: by iggf3 with SMTP id f3so108539403igg.1 for ; Tue, 21 Jul 2015 07:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3K6Sr9mMxTErwVX3vAdG0pKSXtZ1dnfz2woHkdrU9iM=; b=QsjnafDxkSZoSeWGQlhW9TjbOWiuO26AO6zZZbHEiqloRExlutxcBso4z41GBaSfu1 irgtQKQDuSOyyC7rFglVkc6+yXa+v1mkDs4oXC3GmVE4Y4qqAziC1OhdKxmPjWgWX62q 4Xh0PLwv3VPJ9hrGshJW31G6DkcxguLUSuwk8v+P1rhxu1W2UJJD/nxNvY+8MgYd/TCE 0DlRDoXWSsTAZpZ3jJ4HCMjVy90qR8TqHfUamayQQUSslN0oOlntUB4Crv37tHIy9/1d qOQEm4fLHUrzVH48/TwkYNv6OZSlESlqnMXoOR7Ab8r2pkvNBmDNCP/hJ8TaoYLIMtmM qSUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3K6Sr9mMxTErwVX3vAdG0pKSXtZ1dnfz2woHkdrU9iM=; b=mMQyTVexopTLaRHz8O/7qVLzQb+h6TOjkbucinZc0MmJ/TDU0fXPq9xuXiqps60l+O mZzsMhElHWSppWgHADqtmkyo+CN9GCmxJMQ5CqWOY6VYqD3uUzlE9um8XpD5DOtu6Dgp k7knZyyk8ZKUADucTtUucXz8aXeDihJbdixEHp4oOapApqs5A8plksHSLUzcamnNr5BV hA7qUPb3W8uwM70a5V7jZ4WEwbe5xPhlteFhUsTclNrerVYefjWIGNjBGTC27+0X8BMZ gzFUPyGOTbH4TCOU8oaEaAQLCdl4hZwCI7VcqJ8w0TWstIEcnx7D697/bMyLiLHqVp4N C1Dw== X-Gm-Message-State: ALoCoQnKk1txeak3+bPwVRX29y6BzU6LoF/P3aLBfl0WRkrDGR3GGZlByagN9nFf3iGPLDRmrsSM X-Received: by 10.107.37.14 with SMTP id l14mr51357902iol.12.1437488446461; Tue, 21 Jul 2015 07:20:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.234 with HTTP; Tue, 21 Jul 2015 07:20:24 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E7FE415@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E7FBFE7@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E7FD721@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E7FE415@MCHP04MSX.global-ad.net> From: Justin Uberti Date: Tue, 21 Jul 2015 07:20:24 -0700 Message-ID: To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=001a1140c4263886e1051b635ca4 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP and -return- ICE Candidate Policy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:21:00 -0000 --001a1140c4263886e1051b635ca4 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 21, 2015 at 7:11 AM, Hutton, Andrew wrote: > On: 21 July 2015 15:36 Justin Uberti Wrote: > > > > I think the confusion is regarding the use of RTCIceTransportPolicy. > > Clearly that doesn't make sense in the RETURN context. > > Exactly the current -return- draft refers to RTCIceTransportPolicy, > Well, not exactly - it refers to the "ICE Candidate Policy" section in JSEP, which says that there may be additional local policy. But I agree that this is confusing and could be better explained in JSEP. > > > > > The point though is that the browser may have additional local policy, > > separate from RTCIceTransportPolicy, that governs what candidates it > > exposes. > > Agreed. > > Andy > --001a1140c4263886e1051b635ca4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 21, 2015 at 7:11 AM, Hutton, Andrew <<= a href=3D"mailto:andrew.hutton@unify.com" target=3D"_blank">andrew.hutton@u= nify.com> wrote:
On: 21 July 2015 15:36 Justin Uberti Wrote:
>
> I think the confusion is regarding the use of=C2=A0RTCIceTransportPoli= cy.
> Clearly that doesn't make sense in the RETURN context.

Exactly the current -return- draft refers to RTCIceTransportPolicy,<= br>

Well, not exactly - it refers to the &q= uot;ICE Candidate Policy" section in JSEP, which says that there may b= e additional local policy. But I agree that this is confusing and could be = better explained in JSEP.
=C2=A0

>
> The point though is that the browser may have additional local policy,=
> separate from RTCIceTransportPolicy, that governs what candidates it > exposes.

Agreed.

Andy

--001a1140c4263886e1051b635ca4-- From nobody Thu Jul 23 01:38:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE91A1A8AF3 for ; Thu, 23 Jul 2015 01:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUXmUYXOfWBZ for ; Thu, 23 Jul 2015 01:38:20 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 7396D1ACDB4 for ; Thu, 23 Jul 2015 01:36:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 3C72D1E59F1; Thu, 23 Jul 2015 01:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmKbFKf17Ghz; Thu, 23 Jul 2015 01:35:15 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:7d1a:c316:efb6:558f] (unknown [IPv6:2001:67c:370:176:7d1a:c316:efb6:558f]) by c8a.amsl.com (Postfix) with ESMTPA id 7A37C1E59E0; Thu, 23 Jul 2015 01:35:14 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alexa Morris Date: Thu, 23 Jul 2015 01:36:00 -0700 Content-Transfer-Encoding: quoted-printable Sendlaterdate: Thu, 23 Jul 2015 01:36:00 -0700 Message-Id: To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [rtcweb] Virtual Queue for RTCWEB Sessions at IETF 93 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 08:38:22 -0000 RTCWEB WG Participants, If you are planning to participate in the RTCWEB sessions here at IETF = 93 =97 either locally in Prague or as a remote participant =97 we want = to make sure that you are aware that the IETF is providing remote = participants with a new way to ask questions or make comments. In = addition to using the Jabber room, for the RTCWEB session there is also = the opportunity for remote participants to enter a virtual queue and ask = questions directly into the meeting room.=20 This experimental queue was used in a few sessions at IETF 92, so you = may have already seen it in action. Some improvements have been made = since the last meeting, but the concept is the same. There will be two = queues for the RTCWEB sessions =97 a virtual queue and an actual = (in-room) queue. Remote attendees will log into the Meetecho platform = and will have a virtual mic line that they can enter if they have a = question or comment. In-room participants will continue to use normal = mic lines.=20 Instructions for remote participants are at = http://ietf93.conf.meetecho.com/index.php/Remote_Participation. Join the Meetecho session for RTCWEB at 13:00 today using this link: = http://www.meetecho.com/ietf93/rtcweb Join the Meetecho session for RTCWEB at 11:50 tomorrow using this link: = http://www.meetecho.com/ietf93/rtcweb_II Regards, Alexa From nobody Thu Jul 23 03:08:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8431A0275 for ; Thu, 23 Jul 2015 03:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.909 X-Spam-Level: X-Spam-Status: No, score=0.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJQ0gZcWs6Tu for ; Thu, 23 Jul 2015 03:08:17 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id C4CE71A026A for ; Thu, 23 Jul 2015 03:08:17 -0700 (PDT) Received: (qmail 18605 invoked by uid 0); 23 Jul 2015 10:08:14 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy4.mail.unifiedlayer.com with SMTP; 23 Jul 2015 10:08:14 -0000 Received: from box817.bluehost.com ([66.147.244.117]) by CMOut01 with id vloB1q00H2Yhrsa01loEqw; Thu, 23 Jul 2015 03:48:14 -0600 X-Authority-Analysis: v=2.1 cv=NJxGpSKg c=1 sm=1 tr=0 a=1ZWhLoquM75l/9xp6o4QLQ==:117 a=1ZWhLoquM75l/9xp6o4QLQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=KWLd9SN1AAAA:8 a=dXeZ1uqweWsA:10 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=6U2dO19vvw8A:10 a=JMHYQVG13d8A:10 a=zOBTXjUuO1YA:10 a=N1z6yVdWAAAA:8 a=2nFGiysaSxI39FQ3E40A:9 a=UyImb5V5oq-h3xqZ:21 a=NuzGRjpzpm-sxPTG:21 a=QEXdDO2ut3YA:10 a=l9YQt7dNOTcA:10 a=LuuTxNwEefwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sdiwc.info; s=default; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=ZOdb1tYxsaRTJVXJLdS/G98g7BAonYSsuKv9U/X90Ns=; b=HqPRWgS6Fle7kAs83zpBLA9cyizeXS518+hFDgIsnhQq/6tS3+ZR/Qzk+90X8GyT6JSMZK/QC/Jx9iOXoS4hfAOVeN4eNsb7rQzUlw0ZJy6O7rvc1EShB8kS7Ge4A9DY; Received: from localhost ([127.0.0.1]:60498 helo=box817.bluehost.com) by box817.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZID6p-0004FR-V1 for rtcweb@ietf.org; Thu, 23 Jul 2015 03:48:11 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 23 Jul 2015 03:48:09 -0600 From: Conference Alert To: rtcweb@ietf.org Message-ID: X-Sender: jackie@sdiwc.info User-Agent: Roundcube Webmail/1.0.5 X-Identified-User: {1337:box817.bluehost.com:sdiwcnet:sdiwc.info} {sentby:smtp auth 127.0.0.1 authed with jackie@sdiwc.info} Archived-At: Subject: [rtcweb] CfP: ICGCTI2015 - Malaysia X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 10:08:21 -0000 The Third International Conference on Green Computing, Technology and Innovation (ICGCTI2015) Universiti Putra Malaysia, Selangor, Malaysia 8-10 December 2015 http://sdiwc.net/conferences/icgcti2015/ The proposed conference on the above theme will held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. ICGCTI2015 aims to enable researchers build connections between different digital applications. The conference welcomes papers on the following (but not limited to) research topics: - Benefits of, and barriers to, adopting greener IT practices - Carbon metering and user feedback - Climate and ecosystem monitoring - Energy harvesting, storage, and recycling - Energy-aware high performance computing and applications - Energy-aware software - Energy-efficient network services and operations - Green IT metrics, maturity models, standards, and regulations - Green computing models, methodologies and paradigms - Green networking and communication - Life-cycle analysis of IT equipment - Management and profiling tools for energy efficient systems - Modeling-representations, simulation and validation for energy consumption optimization problems - Online dynamic optimization for energy efficient systems - Power-aware algorithms and protocols - Power-efficient delivery and cooling - Renewable energy models and prediction - Smart buildings and urban development - Smart homes, buildings, offices, streets - Stability of smart energy systems - Using IT to reduce carbon emissions - Carbon management policies and ecology- related issues with ICT - Characterization, metrics, and modeling - Creating green awareness using IT - Energy-aware computing - Energy-aware large scale distributed systems, such as Grids, Clouds and service computing - Energy-efficient mass data storage and processing - Governments’ roles in fostering and enforcing green initiatives - Green business process reengineering and management - Green design, manufacture, use, disposal, and recycling of computers and communication systems - Green software engineering - Low-power electronics and systems - Matching energy supply and demand - Network design optimization - Optimization of energy-efficient protocols - Power-aware software and hardware - Reliability, thermal behavior and control - Robustness and performance guarantees - Smart grid and microgrids - Smart transportation and manufacturing - Sustainable computing Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Important Dates ============== Submission Deadline : November 8, 2015 Notification of Acceptance : 2-4 weeks from the submission date Final Notification : November 20, 2015 Camera Ready Deadline : November 28, 2015 Registration Deadline : November 28, 2015 Conference Dates : December 8-10, 2015 Drop us an email at icgcti15@sdiwc.net From nobody Thu Jul 23 09:15:50 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13B41AD0D3 for ; Thu, 23 Jul 2015 09:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGVPa-djtuCI for ; Thu, 23 Jul 2015 09:15:46 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1768D1AD0AD for ; Thu, 23 Jul 2015 09:15:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2C9FE7C3C20 for ; Thu, 23 Jul 2015 18:15:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL8erQ2TUSIO for ; Thu, 23 Jul 2015 18:15:43 +0200 (CEST) Received: from [IPv6:2001:67c:370:160:c5a7:9419:2feb:bfa3] (unknown [IPv6:2001:67c:370:160:c5a7:9419:2feb:bfa3]) by mork.alvestrand.no (Postfix) with ESMTPSA id A79F17C3C19 for ; Thu, 23 Jul 2015 18:15:43 +0200 (CEST) Message-ID: <55B1132E.8070702@alvestrand.no> Date: Thu, 23 Jul 2015 18:15:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] Assigning MediaStreamTracks to media sections (with LS) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 16:15:48 -0000 Warning: This may be pretty incomprehensible to anyone who wasn't in the room for the discussion of the LS handling in Prague. Initial offer handling is pretty trivial. The one who creates the offer creates the LS groups (or not). The below is the algorithm for the initial answer. The algorithm for subsequent answers will have to take into account what assignments are already in effect (this is the same as for the before-LS case). When generating an initial answer, execute the following algorithm: A - Make a list of all the LS groups in the offer. If any media section is shared by two LS groups, merge the groups (they are all synchronized). If there are media sections not in any LS group, put them in the last group in the list. B - Make a list of all the MediaStreamTracks the answererer wants to send, grouped by MediaStream the MediaStreamTrack belongs to. If any track occurs in multiple MediaStreams, merge the groups. C - For each group "SG" in the MediaStreamTrack list: For each group "LSG" in the LS group list: If all MediaStreamTracks in SG can be sent using the media sections in LSG: Mark "SG" as being sent using "LSG" Mark all media sections that are assigned for use by "SG" as "in use". If all media sections in LSG are "in use": Remove "LSG" from the list of LS groups endif endif endfor If "SG" is not marked as being sendable set "must negotiate" flag endif endfor D - Generate the answer using the assignment above. All LS groups in the answer are the same as those in the offer. If the "must negotiate" flag is set: When the PC reaches a stable negotiation state, fire a "negotiationneeded" event. endif Note: When there are no LS groups, the algorithm trivially reduces to what we have already (there is only one group in that case). We still have to figure out what to do with leftover tracks, which may cause the need to send "negotiationneeded". So the only added complexity is the consideration of multiple LS groups. Note: When there is only one LS group consisting of an audio stream and a video stream, and the answerer only wants to send an audio stream and a video stream, this algorithm produces the right result. This may be its most important feature. Note: This algorithm doesn't generate LS groups for stuff that is sent using non-grouped media sections from the offer. If that's desired, we need to set the "must negotiate" flag when using media sections from that group. Note: For subsequent offers, if the offerer starts changing the LS groups, this will invalidate the assignment of MediaStreamTracks to media sections - something we have not contemplated in any other context. I suggest that we forbid changing LS groups at the offerer (he can only add new ones), and reject all modified LS groups if a subsequent offer from a non-WebRTC sender starts changing LS groups on us. This will keep media flowing, but will lose synchronization signalling - this is (hopefully) an edge case. Note: My preference is still to not do LS groups. But if we use them, we must define how. This is the least complicated algorithm I can see working. --=20 Surveillance is pervasive. Go Dark. From nobody Thu Jul 23 12:00:08 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041181A6FE7 for ; Thu, 23 Jul 2015 12:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ8fg72qMbv1 for ; Thu, 23 Jul 2015 12:00:04 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD621A1B71 for ; Thu, 23 Jul 2015 12:00:03 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-e8-55b139b1bcb0 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 63.66.25217.1B931B55; Thu, 23 Jul 2015 21:00:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Thu, 23 Jul 2015 21:00:00 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Thread-Topic: IETF#93: Minutes from 1st RTCWEB session Thread-Index: AdDFecidDyJtiT9lTey9Ik7ZDfKW2Q== Date: Thu, 23 Jul 2015 18:59:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348D1246@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348D1246ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje5Gy42hBtveKlrM2fWAyWLtv3Z2 ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSujaa5cwYnZjBXbmnYwNjB2dzJ2MXJySAiY SLy/uJ4JwhaTuHBvPVsXIxeHkMBRRonFS58zQziLGSUWXuxi6WLk4GATsJDo/qcN0iAikCEx Y/l5FhBbWMBQYtvMX4wgJSICZhKv17hDlOhJ7Fi9HayTRUBVYuZ0U5Awr4CvxPNV/9lBbEag td9PrQE7gVlAXOLWk/lQ5whILNlznhnCFpV4+fgfK4StJNG45AkrRH2+RM+BpewQMwUlTs58 wjKBUWgWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcWF+emGxnp pRZlJhcX5+fp5aWWbGIERsnBLb+tdjAefO54iFGAg1GJh/dB04ZQIdbEsuLK3EOM0hwsSuK8 MzbnhQoJpCeWpGanphakFsUXleakFh9iZOLglGpgnJr0TPPZR8UJG51UFjE9/G2VITd7ma9C 5ba+ObMV6ufUhkdMy+rkOOUx9/aL9qU3Txz5eM+8s+FW2K9J75VjY4xubG+u2LjwGmtouOG/ B+Zm341CJ913feZu+v+QxT/5CwXH43XFz/HODWwX/jGxvLxy+qmzDEVNiidn9h2+HueyYZno hInXNJRYijMSDbWYi4oTAUouBzNzAgAA Archived-At: Subject: [rtcweb] IETF#93: Minutes from 1st RTCWEB session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 19:00:07 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348D1246ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below are my notes from the 1st RTCWEB session. Regards, Christer -------------------------------------------------- Topic: JSEP Presenter: Eric Rescorla & Justin Uberti Draft: draft-ietf-rtcweb-jsep The presenters went through the list of open issues in the draft, and prese= nted suggestions on how to solve the issues. #162: LS Proposal: edge case - document that this is currently unsupported. The call= ee can accept what caller wanted or reject the call. There were two hums. The first hum was about who understands the problem, w= ith very little response. The second hum was whether to NOT agree to the su= ggested proposal, with a single objection. Outcome: The issue will be re-visited on Friday. Harald Alvestrand will pro= vide pseudo code for an alternative solution. #158: (imageattr and CVO) Proposal: always use a single SDP imageattr attribute. Outcome: The proposal was agreed. #122: AS->TIAS conversion Proposal: The following formula for calculating the TIAS from the AS was pr= oposed: TIAS =3D AS * 0.95 - packet_rate * hfr_size packet_rate =3D 50 hdr_size =3D 40 If more accurace is wanted, use TIAS instead of AS. Outcome: The proposal as such was agreed, but the formula will be fixed, so= that the same units are used for all variables. #125: BUNDLE and SDP mangling Proposal: Do not support this Outcome: The proposal was agreed. #155: Selecting between multiple aspect ratios Proposal: Implementations SHOULD pick imageattr with highest q=3D value tha= t doesn't require upscaling. Outcome: The proposal was agreed, but SHOUDLD will be changed to MUST. #143: Can you call CreateOffer in remote-pranswer Proposal: Simplest option - just allow this. Outcome: The proposal was agreed. #149: SSRC and clock rate RFC 7160 prohibits changing of the clock rate within a given SSRC. Currentl= y only a single SSRC value is provided per m- line, but an m- line can cont= ain multiple codes, with different clock rates. Proposal: document the limitation ad move on - note that when changing between codes with different clock rates, you wil= l get wacky RTP timestamps - can revisit moving away from usage of SSRC in the future once MID and ESI= D behaviours are better understood It was discussed whether we should signal multiple SSRCs (one for each cloc= k rate), and allow re-usage of SSRCs that have been previously used. HUM: 1) You must not switch between clock rates 2) You are allowed to switch, but the impacts must be described Not a clear consensus. Outcome: Author is requested to provide some text, which will be provided t= o the mailing list. #169 multiple a=3Dfingerprint lines Proposal: - Generate a=3Dfingerprint line for each certificate - Ensure received certification matches a=3Dfingerprint line with correspon= ding hash Outcome: The proposal was agreed. #15 Early Transport Warmup Randall J indicated that he is willing to provide an alternative solution. Outcome: Will be re-visited on Friday. Randall J will provide some details = on his alternative solution. --_000_7594FB04B1934943A5C02806D1A2204B348D1246ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Below are my notes from the 1st RTCWEB se= ssion.

 

Regards,

 

Christer

 

--------------------------------------------------

 

Topic:           JSEP<= o:p>

Presenter:       Eric Rescorla & Justin Ube= rti

Draft:           draft= -ietf-rtcweb-jsep

 

The presenters went through the list of open issues in the draft, and pr= esented suggestions on how to solve the issues.

 

#162: LS

 

Proposal: edge case - document that this is currently unsupported. The c= allee can accept what caller wanted or reject the call.

 

There were two hums. The first hum was about who understands the problem= , with very little response. The second hum was whether to NOT agree to the= suggested proposal, with a single objection.

 

Outcome: The issue will be re-visited on Friday. Harald Alvestrand will = provide pseudo code for an alternative solution.

 

 

#158: (imageattr and CVO)

 

Proposal: always use a single SDP imageattr attribute.=

 

Outcome: The proposal was agreed.

 

 

 

#122: AS->TIAS conversion

 

Proposal: The following formula for calculating the TIAS from the AS was= proposed:

 

TIAS =3D AS * 0.95 - packet_rate * hfr_size

packet_rate =3D 50

hdr_size =3D 40

If more accurace is wanted, use TIAS instead of AS.

 

Outcome: The proposal as such was agreed, but the formula will be fixed,= so that the same units are used for all variables.

 

 

 

#125: BUNDLE and SDP mangling

 

Proposal: Do not support this

 

Outcome: The proposal was agreed.

 

 

#155: Selecting between multiple aspect ratios

 

Proposal: Implementations SHOULD pick imageattr with highest q=3D value = that doesn't require upscaling.

 

Outcome: The proposal was agreed, but SHOUDLD will be changed to MUST.

 

 

 

#143: Can you call CreateOffer in remote-pranswer

 

Proposal: Simplest option - just allow this.

 

Outcome: The proposal was agreed.

 

 

#149: SSRC and clock rate

 

RFC 7160 prohibits changing of the clock rate within a given SSRC. Curre= ntly only a single SSRC value is provided per m- line, but an m- line can c= ontain multiple codes, with different clock rates.

 

 

Proposal: document the limitation ad move on

- note that when changing between codes with different clock rates, you = will get wacky RTP timestamps

- can revisit moving away from usage of SSRC in the future once MID and = ESID behaviours are better understood

 

It was discussed whether we should signal multiple SSRCs (one for each c= lock rate), and allow re-usage of SSRCs that have been previously used.

 

HUM:

 

      1) You must not switch between clock rate= s

      2) You are allowed to switch, but the imp= acts must be described

 

Not a clear consensus. 

 

Outcome: Author is requested to provide some text, which will be provide= d to the mailing list.

 

 

#169 multiple a=3Dfingerprint lines

 

Proposal:

 

- Generate a=3Dfingerprint line for each certificate

- Ensure received certification matches a=3Dfingerprint line with corres= ponding hash

 

Outcome: The proposal was agreed.

 

 

#15 Early Transport Warmup

 

Randall J indicated that he is willing to provide an alternative solutio= n.

 

Outcome: Will be re-visited on Friday. Randall J will provide some detai= ls on his alternative solution.        &= nbsp;

 

--_000_7594FB04B1934943A5C02806D1A2204B348D1246ESESSMB209erics_-- From nobody Thu Jul 23 14:53:44 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00F41AD067 for ; Thu, 23 Jul 2015 14:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.199 X-Spam-Level: * X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_18=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5PE1wf8i9hE for ; Thu, 23 Jul 2015 14:53:42 -0700 (PDT) Received: from nov-007-i574.relay.mailchannels.net (nov-007-i574.relay.mailchannels.net [46.232.183.128]) by ietfa.amsl.com (Postfix) with ESMTP id 888941ACF57 for ; Thu, 23 Jul 2015 14:53:39 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id CA82CA03C8; Thu, 23 Jul 2015 21:53:15 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com ([TEMPUNAVAIL]. [10.232.141.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Thu, 23 Jul 2015 21:53:17 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1437688397444:2835402188 X-MC-Ingress-Time: 1437688397444 Received: from pool-108-36-235-74.phlapa.fios.verizon.net ([108.36.235.74]:58326 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZIOQO-00077m-VC; Thu, 23 Jul 2015 16:53:09 -0500 Message-ID: <55B1624D.4050908@jesup.org> Date: Thu, 23 Jul 2015 17:53:17 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: Cc: Cullen Jennings , Eric Rescorla Subject: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 21:53:43 -0000 To expand on my idea at the mic today: The current proposal assumes prior agreement to persistent permissions to work well (and may 'light up' the camera/mic while the call is still waiting for the user to accept, which would be concerning to users). We should not require persistent permissions in order to "warm up" DTLS connections before "Accept" from the user. We also must NOT spin up the microphone or camera before the user has agreed to accept the call. We also want to avoid a=inactive and a=recvonly answers. Proposed solution: leverage 'dummy' tracks and replaceTrack (at the JS API level) to avoid renegotiation. We need to attach some sort of track to each one we expect to send on in order to make use of the warmed-up connection when Accept happens. Without persistent permissions, we need alternative streams. We have a few options: 1) WebAudio + canvas.captureStream() * Generate a silent WebAudio stream and generate a MediaStream/MediaStreamTrack (s) * Generate a blank (or not!) MediaStream/MediaStreamTrack from canvas.captureStream() (s) Note you'd tell it to use low-or-no-framerate (see below for another option). * Use MediaStream constructors to combine the audio and video track(s) * Attach to PeerConnection, and createOffer() (will typically be sendrecv (or sendonly if the other side is recvonly)). * On Accept by the user, use RTPSender.replaceTrack() on all accepted tracks, and sending will begin immediately; no renegotiation needed if all are accepted. * No new APIs needed, no W3 work. Requires implementing agreed-on APIs. 2) Add a new way to getUserMedia/whatever to create fake streams, ala fake:true in Firefox * Note that we'd want to modify Firefox's impl and not use fake:true (probably), since we generate a specific test pattern for video. * This is a W3 Media Capture issue, not IETF, but we should realize it requires aligning with them 3) Allow some form of fake track without creating one (perhaps related to Peter's comment at the mic), and then replaceTrack to null tracks. * Does not allow spinning up congestion. * Won't spin up other stuff (decoders, jitter buffers, etc). Some spec work required; may be dragons here. I prefer option 1. It requires no new APIs or protocol decisions, and no action by W3 WGs that are trying to finalize 1.0. We can do this as soon as people implement what we've already agreed to. As a side benefit, if you actually push video via the canvas stream via larger resolutions & framerates, it would spin up congestion control ahead of time as well - under control of the application. This could be a significant win. -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way oo much spam From nobody Thu Jul 23 15:32:38 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF451B2A19 for ; Thu, 23 Jul 2015 15:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzayk8hGVy4Z for ; Thu, 23 Jul 2015 15:32:35 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D661A88BA for ; Thu, 23 Jul 2015 15:32:34 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so3929544lbb.0 for ; Thu, 23 Jul 2015 15:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cqj9eEPG3LoKu0Zzgsvtc5TO94HD//RuSncSquTke6c=; b=ldEToV82BFVXmw0F4I6UIKbahnslzMhN/WA90OflDmytH79uDIJFNlpxC518KyVghe Xn7hatqK6xpIDx0agVCP++BAxsmy9It/m0Iymj3VSg51Aw+rAw5xwFVjQ7vuWk62a1Jw RWMcJXP+Z9KAxr4l2AKtazX1ZfYQjbMJjin/JMvNNoqcvRDUWJJDxGMtYCqJisbVgmBw 49dHwr6iSPk9KkGSPXIfLdS1GBMyyzByiTgHRETJzH0cHsMobaMgXh+CbkZGNJRZU+/a r+szVK0Q2hAQTmNyEdVDy8p5Ush+XBc/m9HIDGt2CD9Wb6plp1f65w5Pcdj8DRcBV+df aUFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cqj9eEPG3LoKu0Zzgsvtc5TO94HD//RuSncSquTke6c=; b=RdS0yrDEdJ/kaB4mqZ4a4pchGT5cUhJKlq9+6sJZ7Ol4Tn5NH8h7j/SG9ubpuJwLjC COGYJihJaUGwSTxHaKHIFMv2GKt2aY8dl/rlyAFSqJy/OtFgZO93G9+tspsg5FLvX5PY wKuiEy/X4ix94e+aY8cfprZ+wI/VbWpCl3Ayxcs8jEgEbxtuwHtkFZF0I2O9Cp5LsQx/ mIApCxEOEGJoVmzMD187l9j14c4j3N2AKpYtGmuoQr83RkQhY8Hp8pSzuNY/U/5hiloN UvLE5x+uXhUb41IKNrKe2jYJpcW6bJTYtnc4qsuW300qQXwUzCZbrza1bGiTDkAK98bA Wxyw== X-Gm-Message-State: ALoCoQl7wop1rOkTW+7MTop2X/tJNbQE5a9xXNN7l6rFqjpakl+h3FT54aEZs6yL8OGlPnAk9CsY X-Received: by 10.112.242.134 with SMTP id wq6mr8064740lbc.99.1437690753115; Thu, 23 Jul 2015 15:32:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.91.135 with HTTP; Thu, 23 Jul 2015 15:31:53 -0700 (PDT) In-Reply-To: <55B1624D.4050908@jesup.org> References: <55B1624D.4050908@jesup.org> From: Peter Thatcher Date: Thu, 23 Jul 2015 15:31:53 -0700 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=001a113495b2a31d13051b92763d Archived-At: Cc: Cullen Jennings , Eric Rescorla , "rtcweb@ietf.org" Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 22:32:37 -0000 --001a113495b2a31d13051b92763d Content-Type: text/plain; charset=UTF-8 Here is my idea: PeerConnection.addTrack(null) means "don't send anything until PeerConnection.replaceTrack is called with a non-null track". Then the code for the callee would something like the following (warning: it's late at night; I may have goofed up something): var pc = new PeerConnection(...); var sender = pc.addTrack(null); pc.setLocalDescriptioon(offer); var answer = pc.createAnswer(offer); pc.setRemoteDescription(answer); // send answer // getUserMedia and ring in parallel // get a track when the user accepts sender.setTrack(track); Then you don't need any fake things. It could spin up congestion and other stuff if we want it to. There is an RtpSender object there, after all. But I'm not sure we actually want to. On Thu, Jul 23, 2015 at 2:53 PM, Randell Jesup wrote: > To expand on my idea at the mic today: > > The current proposal assumes prior agreement to persistent permissions to > work well (and may 'light up' the camera/mic while the call is still > waiting for the user to accept, which would be concerning to users). > > We should not require persistent permissions in order to "warm up" DTLS > connections before "Accept" from the user. We also must NOT spin up the > microphone or camera before the user has agreed to accept the call. We > also want to avoid a=inactive and a=recvonly answers. > > Proposed solution: leverage 'dummy' tracks and replaceTrack (at the JS API > level) to avoid renegotiation. > > We need to attach some sort of track to each one we expect to send on in > order to make use of the warmed-up connection when Accept happens. Without > persistent permissions, we need alternative streams. We have a few options: > > 1) WebAudio + canvas.captureStream() > * Generate a silent WebAudio stream and generate a > MediaStream/MediaStreamTrack (s) > * Generate a blank (or not!) MediaStream/MediaStreamTrack from > canvas.captureStream() (s) > Note you'd tell it to use low-or-no-framerate (see below for > another option). > * Use MediaStream constructors to combine the audio and video track(s) > * Attach to PeerConnection, and createOffer() (will typically be > sendrecv (or sendonly if the other side is recvonly)). > * On Accept by the user, use RTPSender.replaceTrack() on all accepted > tracks, and sending will begin immediately; no renegotiation needed if all > are accepted. > * No new APIs needed, no W3 work. Requires implementing agreed-on > APIs. > > 2) Add a new way to getUserMedia/whatever to create fake streams, ala > fake:true in Firefox > * Note that we'd want to modify Firefox's impl and not use fake:true > (probably), since we generate a specific test pattern for video. > * This is a W3 Media Capture issue, not IETF, but we should realize it > requires aligning with them > > 3) Allow some form of fake track without creating one (perhaps related to > Peter's comment at the mic), and then replaceTrack to null tracks. > * Does not allow spinning up congestion. > * Won't spin up other stuff (decoders, jitter buffers, etc). Some spec > work required; may be dragons here. > > I prefer option 1. It requires no new APIs or protocol decisions, and no > action by W3 WGs that are trying to finalize 1.0. We can do this as soon > as people implement what we've already agreed to. > > As a side benefit, if you actually push video via the canvas stream via > larger resolutions & framerates, it would spin up congestion control ahead > of time as well - under control of the application. This could be a > significant win. > > -- > Randell Jesup -- rjesup a t mozilla d o t com > Please please please don't email randell-ietf@jesup.org! Way oo much spam > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113495b2a31d13051b92763d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is my idea:


Peer= Connection.addTrack(null) means "don't send anything until PeerCon= nection.replaceTrack is called with a non-null track".


Then the code for the callee would something like the fo= llowing (warning: it's late at night; I may have goofed up something):<= /div>

var pc =3D new PeerConnection(...);
var sender= =3D pc.addTrack(null);

pc.setLocalDescriptioon(offer)= ;
var answer =3D pc.createAnswer(offer);
pc.setRemoteDe= scription(answer);
// send answer

// getUserMe= dia and ring in parallel
// get a track when the user accepts
=
sender.setTrack(track);


Then you d= on't need any fake things. =C2=A0

It could spin up= congestion and other stuff if we want it to.=C2=A0 There is an RtpSender o= bject there, after all.=C2=A0 But I'm not sure we actually want to. =C2= =A0


On Thu, Jul 23, 2015 at 2:53 PM, Randell Jesup <<= a href=3D"mailto:randell-ietf@jesup.org" target=3D"_blank">randell-ietf@jes= up.org> wrote:
To expand on my idea at th= e mic today:

The current proposal assumes prior agreement to persistent permissions to w= ork well (and may 'light up' the camera/mic while the call is still= waiting for the user to accept, which would be concerning to users).

We should not require persistent permissions in order to "warm up"= ; DTLS connections before "Accept" from the user.=C2=A0 We also m= ust NOT spin up the microphone or camera before the user has agreed to acce= pt the call.=C2=A0 We also want to avoid a=3Dinactive and a=3Drecvonly answ= ers.

Proposed solution: leverage 'dummy' tracks and replaceTrack (at the= JS API level) to avoid renegotiation.

We need to attach some sort of track to each one we expect to send on in or= der to make use of the warmed-up connection when Accept happens.=C2=A0 With= out persistent permissions, we need alternative streams.=C2=A0 We have a fe= w options:

1) WebAudio + canvas.captureStream()
=C2=A0 =C2=A0 * Generate a silent WebAudio stream and generate a MediaStrea= m/MediaStreamTrack (s)
=C2=A0 =C2=A0 * Generate a blank (or not!) MediaStream/MediaStreamTrack fro= m canvas.captureStream() (s)
=C2=A0 =C2=A0 =C2=A0 =C2=A0Note you'd tell it to use low-or-no-framerat= e (see below for another option).
=C2=A0 =C2=A0 * Use MediaStream constructors to combine the audio and video= track(s)
=C2=A0 =C2=A0 * Attach to PeerConnection, and createOffer() (will typically= be sendrecv (or sendonly if the other side is recvonly)).
=C2=A0 =C2=A0 * On Accept by the user, use RTPSender.replaceTrack() on all = accepted tracks, and sending will begin immediately; no renegotiation neede= d if all are accepted.
=C2=A0 =C2=A0 * No new APIs needed, no W3 work.=C2=A0 Requires implementing= agreed-on APIs.

2) Add a new way to getUserMedia/whatever to create fake streams, ala fake:= true in Firefox
=C2=A0 =C2=A0 * Note that we'd want to modify Firefox's impl and no= t use fake:true (probably), since we generate a specific test pattern for v= ideo.
=C2=A0 =C2=A0 * This is a W3 Media Capture issue, not IETF, but we should r= ealize it requires aligning with them

3) Allow some form of fake track without creating one (perhaps related to P= eter's comment at the mic), and then replaceTrack to null tracks.
=C2=A0 =C2=A0 * Does not allow spinning up congestion.
=C2=A0 =C2=A0 * Won't spin up other stuff (decoders, jitter buffers, et= c). Some spec work required; may be dragons here.

I prefer option 1.=C2=A0 It requires no new APIs or protocol decisions, and= no action by W3 WGs that are trying to finalize 1.0.=C2=A0 =C2=A0We can do= this as soon as people implement what we've already agreed to.

As a side benefit, if you actually push video via the canvas stream via lar= ger resolutions & framerates, it would spin up congestion control ahead= of time as well - under control of the application. This could be a signif= icant win.

--
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!=C2=A0 Way oo much spam
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--001a113495b2a31d13051b92763d-- From nobody Thu Jul 23 15:42:11 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644671ACD37 for ; Thu, 23 Jul 2015 15:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_9hxfqgBqVE for ; Thu, 23 Jul 2015 15:42:09 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2E41A9245 for ; Thu, 23 Jul 2015 15:42:09 -0700 (PDT) Received: by iggf3 with SMTP id f3so2765729igg.1 for ; Thu, 23 Jul 2015 15:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=YQTy0Oz8etOJSmOg71w2Uhc6AgvElG//hViyA0JSgqY=; b=Nv8gNiQe9yL1sPPV6Ut7TZcBq0IQ6DpXK+/CIqqhlEfBCGg7bMoTzDA8dghSizwi09 qEiPIAbivUqEaSrkyuRz+qtPKHOn+gETt1KpXpgvk4AHlzp8GgEOpJ/t+quMAdfs7EJt rcdrNGf+8TrO+b3uabJFbwy2hXiDoSC9cTWiiGJsVH2FjuRg4OlWDTP1yxfjbfvJMDm+ +SINl/4YbPB5ky/61fsxQ97tV6fuSlQq/1Y+T/FuG0z6j4q1A5HRsXUG9kTWPAFgCi3e YVntHgiFqAvF1x5C5qn/YIS4YFQyD15ijP7IPjoe3NlMOW9X/TcMdBZ3IhpNaKC8HT0b FWrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=YQTy0Oz8etOJSmOg71w2Uhc6AgvElG//hViyA0JSgqY=; b=HcXuWBYeOAuu4aLhWhQ3eLt6iN9y8mvTrGcGgC4jN23+C3Z9NilMq39hqf5JwFbjQA rD2tzRlSQlcbhRJgllXUE1YW5Cn8/oIwHV1VGyFPLlf8ZXIMLzP+UDjjDmaXovgeVXC5 NE508uc46Ha8tH/83xmWZj7rjEzZw7VFBAplB1BChLfDITk0+NOEEV9Cr75k/ay6Kr8c ZLmjHo5wC0A5xS1kPKD1Z8t7VyMxDCS3N/gfIz/FGzAdHj4+xNKNpL/pghf0MQHt58yI A4BveGG0R4EzgobJ9F81k3ct4iawt/bDjk3QXMRDTzZJLJzSSOu7F2yZKznsmX84sCSb OOdg== X-Gm-Message-State: ALoCoQkdHRQNLhFnsSjJScJQSZaziGbLXPObGx/UkZa2iv+nlwXgkaXa3OLPeMkxj/5sAG5NWPeH X-Received: by 10.50.13.10 with SMTP id d10mr144573igc.20.1437691328670; Thu, 23 Jul 2015 15:42:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.233 with HTTP; Thu, 23 Jul 2015 15:41:49 -0700 (PDT) From: Justin Uberti Date: Fri, 24 Jul 2015 00:41:49 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e01184874f18812051b9298f5 Archived-At: Subject: [rtcweb] Fuller proposal for early ICE/DTLS warmup X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 22:42:10 -0000 --089e01184874f18812051b9298f5 Content-Type: text/plain; charset=UTF-8 *Graphical overview:* *Caller Callee* |--- offer 1 (sendrecv) --->| |<-- answer 1 (sendonly) ---| |<-----ICE/DTLS start------>| .time passes, caller accepts. |<-- offer 2 (sendrecv) ----| |<---- callee media!!! -----| |--- answer 2 (sendrecv) -->| |----- caller media!!! ---->| *New APIs needed:* - create dummy sender using addTrack(null) - RTCRtpReceiver.active property, which controls whether a receiver indicates that it actually wants to receive media (by setting a=sendonly instead of a=sendrecv) *Annotated code sample:* *- caller places call -* *- caller creates audio track and offers it -* track = gUM(audio) sender = addTrack(track) createOffer.then().setLD(offer).then().signal(offer) *// offer is a=sendrecv* *- callee gets offer, sets receiver as not active, adds dummy send track, answers -* offer = receive() setRD(offer) receiver = getReceivers()[0] receiver.active = false sender = addTrack(null) createAnswer.then().setLD(answer).then().signal(answer) *- answer is a=sendonly. Ensures caller doesn't send media during ring -* *- caller gets answer, o/a 1 complete -* answer = receive() setRD(answer) *- ICE and DTLS start -* *- time passes - * *- callee accepts call -* *- callee creates audio track, replaces dummy track, toggles receiver, offers -* track = gUM(audio) sender.setTrack(track) receiver.active = true createOffer.then().setLD(offer).then().signal(offer) // offer is a=sendrecv *- callee -> caller media flows -* *- callee gets offer, replies with normal answer - * offer = receive(); setRD(offer) createAnswer.then().setLD(answer).then().signal(answer) // answer is a=sendrecv *- caller -> callee media flows -* *- callee gets answer, o/a 2 complete -* answer = receive(); setRD(answer); --089e01184874f18812051b9298f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Graphical overview:
Caller =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Callee
=C2=A0 |--- offer 1 (sendrecv) --->|
=C2=A0 |<-- answer 1 (sendonly) ---|
=C2=A0 |<-----ICE/DTLS= start------>|

=
=C2=A0 .time passes, = caller accepts.

=C2=A0 |<-- offer 2 = (sendrecv) ----|
=C2=A0 |<---- callee media!!! -----|
=C2= =A0 |--- answer 2 (sendrecv) -->|
=C2=A0 |----- caller media!!! ---->|

New APIs needed:
- create dummy sender using addTrack(n= ull)
- RTCRtpReceiver.active property, which controls whether a r= eceiver indicates that it actually wants to receive media (by setting a=3Ds= endonly instead of a=3Dsendrecv)

Annotated code= sample:
- caller places call -

- caller creates audio track and offers it -
track =3D = gUM(audio)=C2=A0
sender =3D addTrack(track)=C2=A0
creat= eOffer.then().setLD(offer).then().signal(offer)=C2=A0
// offer= is a=3Dsendrecv

- callee gets offer, sets = receiver as not active, adds dummy send track, answers -
offe= r =3D receive()
setRD(offer)
receiver =3D getReceivers(= )[0]
receiver.active =3D false
sender =3D addTrack(null= )
createAnswer.then().setLD(answer).then().signal(answer)
- answer is a=3Dsendonly. Ensures caller doesn't send media durin= g ring -

- caller gets answer, o/a 1 co= mplete -
answer =3D receive()
setRD(answer)

- ICE and DTLS start -

- time passes -=C2=A0

- callee accepts cal= l -

- callee creates audio track, replaces = dummy track, toggles receiver, offers -
track =3D gUM(audio)<= /div>
sender.setTrack(track)
receiver.active =3D true
createOffer.then().setLD(offer).then().signal(offer) // offer is a=3Dsen= drecv

- callee -> caller media flows -

- callee gets offer, replies with normal answer = -=C2=A0
offer =3D receive();
setRD(offer)
createAnswer.then().setLD(answer).then().signal(answer) // answer is a=3Ds= endrecv

- caller -> callee media flows -=

- callee gets answer, o/a 2 complete -
answer =3D receive();
setRD(answer);

<= div>



--089e01184874f18812051b9298f5-- From nobody Thu Jul 23 15:44:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7655A1B2A37 for ; Thu, 23 Jul 2015 15:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLSxRaVveXl4 for ; Thu, 23 Jul 2015 15:44:30 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4191B2A2D for ; Thu, 23 Jul 2015 15:44:29 -0700 (PDT) Received: by ietj16 with SMTP id j16so5545079iet.0 for ; Thu, 23 Jul 2015 15:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=onmEjXovDB6s1OJrCuPHXrihEPEjkgL/CxT411nuwXE=; b=jxV6kn6jtoJjp09drVaXD0Tg0KX9pe/Bxti+F297R/tQkXB6ntH9EmctP5mra300lm cZqQqDnu4kIl8dtwwuAevyVPuAis8+WoKc+H5hPJctoGjJHV5u7UC1QIgNIYs1GCRQj6 Dtt6kAQs1JZ2A9ULJMcnqigzfrIYTvmfTIfllbYQw2mYdLDBTjh5uiBstXVKkUKFZ7Yc famiJuSwDmszUvFmEyqHegFdCh/mo4oQJgitk8nMpaUgpuG8CN1qXdyLsy7mEAAWm738 BRKZLzVMdl2Ls6SbA85CjeL3sITPyItYxtmFvDutabpyjJ1gbM3slNEN5Q/j08OA3iQN xO/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=onmEjXovDB6s1OJrCuPHXrihEPEjkgL/CxT411nuwXE=; b=YCh2qzVP7FXdIIvITOpgEEqU9MogNWGaCELajo41Zp8fRY4tlHmQT30O0BvbD0MfcY urf4ltKQKwsyC4StFVfIKWNFWjbmnUGVbZNy7YHVSWDMvgzuoL/3JnSGwSu49BmUG9lN djx69dbiRyIvR6dbTX3Fc2FDC0CIhskJe9fk9zQzg+NjMX8MwrcI9HtmFuvGIxB4QSfu atQbPHjLXiGoDcAjkMoNfY/oQ7hpBLvYK9icZ7nfhA0hlLLz0L+w2Llilbu7NtRzDt4H GfiMzh6R3pQLpqka4TcQX4Sa/NGhzweto7/o8dV6njtFQba25pZGBZA1HmvhLiSEyNZA uO5A== X-Gm-Message-State: ALoCoQnXLxp/GncpAnCfxrr9hGl9g5eZO13Atmv2/7ZglZsjvWab1l3Fd9h2xqCYsK3SGfFJaUBJ X-Received: by 10.107.16.223 with SMTP id 92mr17871632ioq.14.1437691469313; Thu, 23 Jul 2015 15:44:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.233 with HTTP; Thu, 23 Jul 2015 15:44:09 -0700 (PDT) In-Reply-To: References: <55B1624D.4050908@jesup.org> From: Justin Uberti Date: Fri, 24 Jul 2015 00:44:09 +0200 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a113ec94e537e4b051b92a19d Archived-At: Cc: Randell Jesup , Cullen Jennings , "rtcweb@ietf.org" , Eric Rescorla Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 22:44:32 -0000 --001a113ec94e537e4b051b92a19d Content-Type: text/plain; charset=UTF-8 Peter's proposal pretty much matches what I just posted, but I think a RTCRtpReceiver property is also needed to prevent caller->callee media during ringing, which at a minimum would violate user expectations. On Fri, Jul 24, 2015 at 12:31 AM, Peter Thatcher wrote: > Here is my idea: > > > PeerConnection.addTrack(null) means "don't send anything until > PeerConnection.replaceTrack is called with a non-null track". > > > Then the code for the callee would something like the following (warning: > it's late at night; I may have goofed up something): > > var pc = new PeerConnection(...); > var sender = pc.addTrack(null); > > pc.setLocalDescriptioon(offer); > var answer = pc.createAnswer(offer); > pc.setRemoteDescription(answer); > // send answer > > // getUserMedia and ring in parallel > // get a track when the user accepts > sender.setTrack(track); > > > Then you don't need any fake things. > > It could spin up congestion and other stuff if we want it to. There is an > RtpSender object there, after all. But I'm not sure we actually want to. > > > On Thu, Jul 23, 2015 at 2:53 PM, Randell Jesup > wrote: > >> To expand on my idea at the mic today: >> >> The current proposal assumes prior agreement to persistent permissions to >> work well (and may 'light up' the camera/mic while the call is still >> waiting for the user to accept, which would be concerning to users). >> >> We should not require persistent permissions in order to "warm up" DTLS >> connections before "Accept" from the user. We also must NOT spin up the >> microphone or camera before the user has agreed to accept the call. We >> also want to avoid a=inactive and a=recvonly answers. >> >> Proposed solution: leverage 'dummy' tracks and replaceTrack (at the JS >> API level) to avoid renegotiation. >> >> We need to attach some sort of track to each one we expect to send on in >> order to make use of the warmed-up connection when Accept happens. Without >> persistent permissions, we need alternative streams. We have a few options: >> >> 1) WebAudio + canvas.captureStream() >> * Generate a silent WebAudio stream and generate a >> MediaStream/MediaStreamTrack (s) >> * Generate a blank (or not!) MediaStream/MediaStreamTrack from >> canvas.captureStream() (s) >> Note you'd tell it to use low-or-no-framerate (see below for >> another option). >> * Use MediaStream constructors to combine the audio and video track(s) >> * Attach to PeerConnection, and createOffer() (will typically be >> sendrecv (or sendonly if the other side is recvonly)). >> * On Accept by the user, use RTPSender.replaceTrack() on all accepted >> tracks, and sending will begin immediately; no renegotiation needed if all >> are accepted. >> * No new APIs needed, no W3 work. Requires implementing agreed-on >> APIs. >> >> 2) Add a new way to getUserMedia/whatever to create fake streams, ala >> fake:true in Firefox >> * Note that we'd want to modify Firefox's impl and not use fake:true >> (probably), since we generate a specific test pattern for video. >> * This is a W3 Media Capture issue, not IETF, but we should realize >> it requires aligning with them >> >> 3) Allow some form of fake track without creating one (perhaps related to >> Peter's comment at the mic), and then replaceTrack to null tracks. >> * Does not allow spinning up congestion. >> * Won't spin up other stuff (decoders, jitter buffers, etc). Some >> spec work required; may be dragons here. >> >> I prefer option 1. It requires no new APIs or protocol decisions, and no >> action by W3 WGs that are trying to finalize 1.0. We can do this as soon >> as people implement what we've already agreed to. >> >> As a side benefit, if you actually push video via the canvas stream via >> larger resolutions & framerates, it would spin up congestion control ahead >> of time as well - under control of the application. This could be a >> significant win. >> >> >> -- >> Randell Jesup -- rjesup a t mozilla d o t com >> Please please please don't email randell-ietf@jesup.org! Way oo much >> spam >> >> _______________________________________________ >> 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 > > --001a113ec94e537e4b051b92a19d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter's proposal pretty much matches what I just poste= d, but I think a RTCRtpReceiver property is also needed to prevent caller-&= gt;callee media during ringing, which at a minimum would violate user expec= tations.

On Fri, J= ul 24, 2015 at 12:31 AM, Peter Thatcher <pthatcher@google.com> wrote:
Here is= my idea:


PeerConnection.addTrack(null) m= eans "don't send anything until PeerConnection.replaceTrack is cal= led with a non-null track".


Then th= e code for the callee would something like the following (warning: it's= late at night; I may have goofed up something):

var p= c =3D new PeerConnection(...);
var sender =3D pc.addTrack(null);

pc.setLocalDescriptioon(offer);
var answer = =3D pc.createAnswer(offer);
pc.setRemoteDescription(answer);
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">// send answer

// getUserMedia and ring in parallel<= /div>
// get a track when the user accepts
sender.setTrack(track)= ;


Then you don't need any fake th= ings. =C2=A0

It could spin up congestion and other stu= ff if we want it to.=C2=A0 There is an RtpSender object there, after all.= =C2=A0 But I'm not sure we actually want to. =C2=A0

<= div class=3D"gmail_extra">
On Thu, = Jul 23, 2015 at 2:53 PM, Randell Jesup <randell-ietf@jesup.org>= ; wrote:
To expand on my i= dea at the mic today:

The current proposal assumes prior agreement to persistent permissions to w= ork well (and may 'light up' the camera/mic while the call is still= waiting for the user to accept, which would be concerning to users).

We should not require persistent permissions in order to "warm up"= ; DTLS connections before "Accept" from the user.=C2=A0 We also m= ust NOT spin up the microphone or camera before the user has agreed to acce= pt the call.=C2=A0 We also want to avoid a=3Dinactive and a=3Drecvonly answ= ers.

Proposed solution: leverage 'dummy' tracks and replaceTrack (at the= JS API level) to avoid renegotiation.

We need to attach some sort of track to each one we expect to send on in or= der to make use of the warmed-up connection when Accept happens.=C2=A0 With= out persistent permissions, we need alternative streams.=C2=A0 We have a fe= w options:

1) WebAudio + canvas.captureStream()
=C2=A0 =C2=A0 * Generate a silent WebAudio stream and generate a MediaStrea= m/MediaStreamTrack (s)
=C2=A0 =C2=A0 * Generate a blank (or not!) MediaStream/MediaStreamTrack fro= m canvas.captureStream() (s)
=C2=A0 =C2=A0 =C2=A0 =C2=A0Note you'd tell it to use low-or-no-framerat= e (see below for another option).
=C2=A0 =C2=A0 * Use MediaStream constructors to combine the audio and video= track(s)
=C2=A0 =C2=A0 * Attach to PeerConnection, and createOffer() (will typically= be sendrecv (or sendonly if the other side is recvonly)).
=C2=A0 =C2=A0 * On Accept by the user, use RTPSender.replaceTrack() on all = accepted tracks, and sending will begin immediately; no renegotiation neede= d if all are accepted.
=C2=A0 =C2=A0 * No new APIs needed, no W3 work.=C2=A0 Requires implementing= agreed-on APIs.

2) Add a new way to getUserMedia/whatever to create fake streams, ala fake:= true in Firefox
=C2=A0 =C2=A0 * Note that we'd want to modify Firefox's impl and no= t use fake:true (probably), since we generate a specific test pattern for v= ideo.
=C2=A0 =C2=A0 * This is a W3 Media Capture issue, not IETF, but we should r= ealize it requires aligning with them

3) Allow some form of fake track without creating one (perhaps related to P= eter's comment at the mic), and then replaceTrack to null tracks.
=C2=A0 =C2=A0 * Does not allow spinning up congestion.
=C2=A0 =C2=A0 * Won't spin up other stuff (decoders, jitter buffers, et= c). Some spec work required; may be dragons here.

I prefer option 1.=C2=A0 It requires no new APIs or protocol decisions, and= no action by W3 WGs that are trying to finalize 1.0.=C2=A0 =C2=A0We can do= this as soon as people implement what we've already agreed to.

As a side benefit, if you actually push video via the canvas stream via lar= ger resolutions & framerates, it would spin up congestion control ahead= of time as well - under control of the application. This could be a signif= icant win.


--
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!=C2=A0 Way oo much spam
_______________________________________________
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


--001a113ec94e537e4b051b92a19d-- From nobody Thu Jul 23 22:17:07 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA171ACED0 for ; Thu, 23 Jul 2015 22:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79nxxYoLHPM0 for ; Thu, 23 Jul 2015 22:17:04 -0700 (PDT) Received: from aso-006-i435.relay.mailchannels.net (aso-006-i435.relay.mailchannels.net [23.91.64.116]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBC71A1A50 for ; Thu, 23 Jul 2015 22:17:03 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id 8175D1D013E for ; Fri, 24 Jul 2015 05:17:00 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.251.34.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Fri, 24 Jul 2015 05:17:01 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1437715020690:802358880 X-MC-Ingress-Time: 1437715020690 Received: from pool-108-36-235-74.phlapa.fios.verizon.net ([108.36.235.74]:60332 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZIVLu-0005vm-Nz for rtcweb@ietf.org; Fri, 24 Jul 2015 00:16:58 -0500 Message-ID: <55B1CA54.9050809@jesup.org> Date: Fri, 24 Jul 2015 01:17:08 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <55B1624D.4050908@jesup.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: Subject: [rtcweb] Congestion warmup X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 05:17:05 -0000 I'd love to be able to warm up congestion control, and not just DTLS. That requires sending data and allowing it to increase to probe the connection and open the congestion window, and preferably sending in both directions (i.e. a=sendrecv in the warm-up answer). We'd need to find a way to generically pad RTP packets to a target size (since encoding a static/black image won't use enough bytes). The obvious codec-agnostic mechanism would be a header extension. Since they can be any 4-byte-multiple size, that would pretty much work up to ~384K (1500 byte packets, 1/frame @30fps). However, we could run the fake video framerate arbitrarily high to hit any bandwidth target we need. Alternatively (and *much* better) we could use a "fake" codec (a=rtpmap:111 fake/90000) which doesn't actually include any real data, just padding. Advantages: no CPU code to encode/decode. No dealing with header extensions. Clear indication if the other side wants to do spinup (they can reject the codec if they don't want to). No encoding/decoding CPU use. The offer would include it as a least-preferred codec to indicate warmup support. If answerer answers with fake as the accepted codec (and real codecs following), it's a warmup answer. Both sides will send and receive fake data to spin up the congestion windows (and also the jitter buffers, etc). On actual answer, the fake codec would be dropped (or dropped to bottom priority). The answerer would start sending in a real codec, which would work since the warmup answer would have included that codec. The offerer would see the incoming real-codec packets, and decode them. When the real answer arrives, it will show the accepted codec has changed, and the offerer will install that answer and thus and start sending (real) media. We still need a way to tell the system at the answerer side "I want to accept but it's a warm-up accept" (and perhaps if we want to spin up congestion control or not while waiting), and a way to say on the offerer side "I want to offer/use warmups". For those API points see the previous options from myself and Peter - or simply a way to say createAnswer of a warmup answer, and have that agree to all tracks with fake codecs being primary. I'll note that all of these methods would benefit from a mechanism to indicate the desired bitrate targets for each fake track; for solutions that use some sort of fake video input (canvas.captureStream/etc) it inherently allows the application to define the size and framerate, which are the primary knobs used by the browser for setting 'max total bitrate' for the track. You don't want the application to set the bandwidth directly, you want it to define the parameters of the video stream so the system can set "reasonable" limits for that resolution & situation. From nobody Thu Jul 23 22:38:21 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1C11B2E13 for ; Thu, 23 Jul 2015 22:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXwa0tgVJl8Z for ; Thu, 23 Jul 2015 22:38:17 -0700 (PDT) Received: from nov-007-i591.relay.mailchannels.net (nov-007-i591.relay.mailchannels.net [46.232.183.145]) by ietfa.amsl.com (Postfix) with ESMTP id E0C5E1B2F0A for ; Thu, 23 Jul 2015 22:36:03 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id 6F7021D0341 for ; Fri, 24 Jul 2015 05:35:54 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com ([TEMPUNAVAIL]. [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Fri, 24 Jul 2015 05:35:54 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1437716154634:3575957949 X-MC-Ingress-Time: 1437716154634 Received: from pool-108-36-235-74.phlapa.fios.verizon.net ([108.36.235.74]:60430 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZIVe7-0001GI-Bn for rtcweb@ietf.org; Fri, 24 Jul 2015 00:35:47 -0500 Message-ID: <55B1CEBD.8090201@jesup.org> Date: Fri, 24 Jul 2015 01:35:57 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <55B1624D.4050908@jesup.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 05:38:19 -0000 On 7/23/2015 6:44 PM, Justin Uberti wrote: > Peter's proposal pretty much matches what I just posted, but I think a > RTCRtpReceiver property is also needed to prevent caller->callee media > during ringing, which at a minimum would violate user expectations. If we want to answer a=sendrev offers with a=sendonly (regardless of this use-case), we need something like that. However, we may not care much outside of this usecase. I'd love to be able to just answer a=sendrecv in the warm-up answer, and in any case the answerer must indicate somehow in conjunction with the warmup answer that it's not a real user answer (I do not consider parsing all the directions for a=sendonly a reasonable way to know). Since the answer comes along with "this is warmup" (somehow), the offerer can see that and replaceTrack with fake (or null) tracks before SetRemoteDescription, and so not send media (or send only fake congestion-spinup data). > On Fri, Jul 24, 2015 at 12:31 AM, Peter Thatcher > wrote: > > Here is my idea: > > > PeerConnection.addTrack(null) means "don't send anything until > PeerConnection.replaceTrack is called with a non-null track". > Note that this would be problematic on the offerer side (is it audio or video?) We'd have to figure out when this is valid and what it does when it id valid (in W3 land). Also, perhaps we could use addTrack(null) as an indicator to accept a 'fake' codec as the primary codec (see previous email on congestion spinup). This would enable (but not require) congestion spinup. > > > Then the code for the callee would something like the following > (warning: it's late at night; I may have goofed up something): > > var pc = new PeerConnection(...); > var sender = pc.addTrack(null); > > pc.setLocalDescriptioon(offer); > var answer = pc.createAnswer(offer); > pc.setRemoteDescription(answer); > // send answer > > // getUserMedia and ring in parallel > // get a track when the user accepts > sender.setTrack(track); > Another advantage of this (Peter's addTrack(null)) is that it doesn't send muted data (from webaudio or canvas.captureStream). This means when the user *does* answer, you swap to real sources and start encoding, so the offerer can key off incoming data to know it should start showing the data (before the final answer arrives). Note that the rtcpmap fake codec/payload idea would also work (the "decoder" would eat all data and never generate a frame of video, and would generate no audio or silent depending on how it works in the stack - then when the real answer happens, we switch to using a real encoder to encode real data, and it will end up decoding and showing). > > > Then you don't need any fake things. > > It could spin up congestion and other stuff if we want it to. > There is an RtpSender object there, after all. But I'm not sure we > actually want to. > Spinning congestion with 'null' tracks would be more complex - more API points probably (and needs a=sendrecv really, but per above we could). See previous message about how you'd do it. -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much spam From nobody Thu Jul 23 22:47:13 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0561C1B2F16 for ; Thu, 23 Jul 2015 22:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.311 X-Spam-Level: X-Spam-Status: No, score=-113.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_18=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bmu8skDuXmJZ for ; Thu, 23 Jul 2015 22:47:10 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152361B2EB4 for ; Thu, 23 Jul 2015 22:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3489; q=dns/txt; s=iport; t=1437716830; x=1438926430; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=qvmAuWstQRlefD0uRKMlby97B/3g+btddC8D55KhXog=; b=NmI0XQnpZlKj+sSU2rVeRD3FZCh/Zrz4/tTcKBH4+GHzCVzDEcUz/aQw yqjI7AlIC2nY+AAi1xZx1JZUs2sjFcooEeGvSDDse3Rr7LGvPeQ+kXbP7 gbrOgNyZUSJVUbGGeDJE4xiMroHyealyDLO/JLOQzY1O6c0NIOM9yLOQm M=; X-IronPort-AV: E=Sophos;i="5.15,536,1432598400"; d="scan'208";a="171937679" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP; 24 Jul 2015 05:47:09 +0000 Received: from [127.0.0.1] (ssh-sjc-2.cisco.com [171.68.46.188]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6O5l6eN016686; Fri, 24 Jul 2015 05:47:07 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <55B1624D.4050908@jesup.org> Date: Fri, 24 Jul 2015 07:47:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0BFFD6B3-2D53-47FA-A23C-F7EB3805126A@cisco.com> References: <55B1624D.4050908@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Eric Rescorla , "rtcweb@ietf.org" Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 05:47:12 -0000 My initial reaction to this was I can see how it would work but I sort = of hope we could get something that was easier for web developers and = that did not use bandwidth to send the media before there was real = media. Good food for thought.=20 > On Jul 23, 2015, at 11:53 PM, Randell Jesup = wrote: >=20 > To expand on my idea at the mic today: >=20 > The current proposal assumes prior agreement to persistent permissions = to work well (and may 'light up' the camera/mic while the call is still = waiting for the user to accept, which would be concerning to users). >=20 > We should not require persistent permissions in order to "warm up" = DTLS connections before "Accept" from the user. We also must NOT spin = up the microphone or camera before the user has agreed to accept the = call. We also want to avoid a=3Dinactive and a=3Drecvonly answers. >=20 > Proposed solution: leverage 'dummy' tracks and replaceTrack (at the JS = API level) to avoid renegotiation. >=20 > We need to attach some sort of track to each one we expect to send on = in order to make use of the warmed-up connection when Accept happens. = Without persistent permissions, we need alternative streams. We have a = few options: >=20 > 1) WebAudio + canvas.captureStream() > * Generate a silent WebAudio stream and generate a = MediaStream/MediaStreamTrack (s) > * Generate a blank (or not!) MediaStream/MediaStreamTrack from = canvas.captureStream() (s) > Note you'd tell it to use low-or-no-framerate (see below for = another option). > * Use MediaStream constructors to combine the audio and video = track(s) > * Attach to PeerConnection, and createOffer() (will typically be = sendrecv (or sendonly if the other side is recvonly)). > * On Accept by the user, use RTPSender.replaceTrack() on all = accepted tracks, and sending will begin immediately; no renegotiation = needed if all are accepted. > * No new APIs needed, no W3 work. Requires implementing agreed-on = APIs. >=20 > 2) Add a new way to getUserMedia/whatever to create fake streams, ala = fake:true in Firefox > * Note that we'd want to modify Firefox's impl and not use = fake:true (probably), since we generate a specific test pattern for = video. > * This is a W3 Media Capture issue, not IETF, but we should realize = it requires aligning with them >=20 > 3) Allow some form of fake track without creating one (perhaps related = to Peter's comment at the mic), and then replaceTrack to null tracks. > * Does not allow spinning up congestion. > * Won't spin up other stuff (decoders, jitter buffers, etc). Some = spec work required; may be dragons here. >=20 > I prefer option 1. It requires no new APIs or protocol decisions, and = no action by W3 WGs that are trying to finalize 1.0. We can do this as = soon as people implement what we've already agreed to. >=20 > As a side benefit, if you actually push video via the canvas stream = via larger resolutions & framerates, it would spin up congestion control = ahead of time as well - under control of the application. This could be = a significant win. >=20 > --=20 > Randell Jesup -- rjesup a t mozilla d o t com > Please please please don't email randell-ietf@jesup.org! Way oo much = spam >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jul 23 22:47:17 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB8B1B2F2C for ; Thu, 23 Jul 2015 22:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1DlGhWuqctE for ; Thu, 23 Jul 2015 22:47:12 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447FC1B2EB4 for ; Thu, 23 Jul 2015 22:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=791; q=dns/txt; s=iport; t=1437716833; x=1438926433; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=J28NM35l2m9URjxSN5kllKtCpQbDoRgkCb+wHRDBDSk=; b=YnHuoS/8hnoy7ACVqg0Qwze90XErj2RkIcIVBliv5UfB/9fIo6WYvGY7 MU0C6NnDXkjF2R6XUVV//HEsfruVmIil6qCWysdKMd4gZzj0BYDwpXiwZ gEjk24/BKOSkemY8djVuyu3NHlZ5mltkioO4gsAASWP9EOjD9zWuIL7UO 8=; X-IronPort-AV: E=Sophos;i="5.15,536,1432598400"; d="scan'208";a="171464177" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP; 24 Jul 2015 05:47:12 +0000 Received: from [127.0.0.1] (ssh-sjc-2.cisco.com [171.68.46.188]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6O5l6eO016686; Fri, 24 Jul 2015 05:47:10 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 24 Jul 2015 07:47:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0CBD9843-C0FC-4C6E-82A1-79C374894F6C@cisco.com> References: <55B1624D.4050908@jesup.org> To: Peter Thatcher X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Randell Jesup , Eric Rescorla , "rtcweb@ietf.org" Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 05:47:14 -0000 > On Jul 24, 2015, at 12:31 AM, Peter Thatcher = wrote: >=20 > PeerConnection.addTrack(null) means "don't send anything until = PeerConnection.replaceTrack is called with a non-null track". >=20 Would we need extra info to know if this was audio, video etc. I'm just = thinking about the issues where the PC creates an answer without knowing = anything about what is in the track then when the PC see the real track = (after answer is sent), I'm wondering if we could end up with a case = where what was in the track was not consistent with the answer that got = sent. I don't have a concrete example of a problem here but I have a = nagging feeling there might be problems here - particularly on things = where the encoding is done in hardware.=20= From nobody Fri Jul 24 00:33:20 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2003A1B2FC1 for ; Fri, 24 Jul 2015 00:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP14efiFOPJM for ; Fri, 24 Jul 2015 00:33:17 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C841B2FBD for ; Fri, 24 Jul 2015 00:33:17 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so53288161wic.0 for ; Fri, 24 Jul 2015 00:33:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oOY6BU0c+P2eQgT4kAQR2D9QYHC6obiki/YW+MBNKlM=; b=KEMYzBRhQOm/R5YOemigbTKeHFr5rAi+jUJ7ZPvkIeJ/qTsXt023ZEeJt6+5/N6/v7 5oJlCrx5ZEmwFX0bnQtxAxgnxxBmq3mSFTLpVK0gWLnXJretDXLUjCApA9b3C8W8wtJy 5rSCTGHTUQyPIB/gShW8MY8i/jtWTgM8vPzGrW90rnW1nvUCLDb2j69r4jzN2Dp4B9YJ YFY5twW8sA1+M8/OcTugbrQfLClKd4lplywC3EzH7ommk72ldFzVyWX5zIgH4YsCnKUC 0aRyljsJbJsHLxlkpVxlk1zcS/8fLNiA2qGz4MeBhs9/5VZHjWRaOlR3xI5vekjF5lk0 purw== X-Gm-Message-State: ALoCoQlqvzv6Zgzl1aR4ypiWXNCX1u9jn6tCZj7BzSN8J4SCF9EDEK27rh+y+EpqfVf5G09Tjsgt X-Received: by 10.180.83.137 with SMTP id q9mr4758833wiy.68.1437723196021; Fri, 24 Jul 2015 00:33:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Fri, 24 Jul 2015 00:32:36 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 24 Jul 2015 09:32:36 +0200 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=f46d04440196627ab2051b9a0456 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fuller proposal for early ICE/DTLS warmup X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 07:33:19 -0000 --f46d04440196627ab2051b9a0456 Content-Type: text/plain; charset=UTF-8 This seems generally reasonable, but share Cullen's concern about how the answerer PC knows the characteristics of the dummy track (this is something that would be addressed by Jesup's more explicit dummy track example). -Ekr On Fri, Jul 24, 2015 at 12:41 AM, Justin Uberti wrote: > *Graphical overview:* > *Caller Callee* > |--- offer 1 (sendrecv) --->| > |<-- answer 1 (sendonly) ---| > |<-----ICE/DTLS start------>| > > .time passes, caller accepts. > > |<-- offer 2 (sendrecv) ----| > |<---- callee media!!! -----| > |--- answer 2 (sendrecv) -->| > |----- caller media!!! ---->| > > *New APIs needed:* > - create dummy sender using addTrack(null) > - RTCRtpReceiver.active property, which controls whether a receiver > indicates that it actually wants to receive media (by setting a=sendonly > instead of a=sendrecv) > > *Annotated code sample:* > *- caller places call -* > > *- caller creates audio track and offers it -* > track = gUM(audio) > sender = addTrack(track) > createOffer.then().setLD(offer).then().signal(offer) > *// offer is a=sendrecv* > > *- callee gets offer, sets receiver as not active, adds dummy send track, > answers -* > offer = receive() > setRD(offer) > receiver = getReceivers()[0] > receiver.active = false > sender = addTrack(null) > createAnswer.then().setLD(answer).then().signal(answer) > > *- answer is a=sendonly. Ensures caller doesn't send media during ring -* > > *- caller gets answer, o/a 1 complete -* > answer = receive() > setRD(answer) > > *- ICE and DTLS start -* > > *- time passes - * > > *- callee accepts call -* > > *- callee creates audio track, replaces dummy track, toggles receiver, > offers -* > track = gUM(audio) > sender.setTrack(track) > receiver.active = true > createOffer.then().setLD(offer).then().signal(offer) // offer is a=sendrecv > > *- callee -> caller media flows -* > > *- callee gets offer, replies with normal answer - * > offer = receive(); > setRD(offer) > createAnswer.then().setLD(answer).then().signal(answer) // answer is > a=sendrecv > > *- caller -> callee media flows -* > > *- callee gets answer, o/a 2 complete -* > answer = receive(); > setRD(answer); > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d04440196627ab2051b9a0456 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems generally reasonable, but share Cullen's co= ncern about how the
answerer PC knows the characteristics of the dummy = track
(this is something that would be addressed by Jesup's m= ore explicit dummy
track example).

-Ekr

<= div class=3D"gmail_extra">
On Fri, Jul 24, 20= 15 at 12:41 AM, Justin Uberti <juberti@google.com> wrote:
Graphical overvie= w:
Caller =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Callee
=C2=A0 |--- offer 1 (sendr= ecv) --->|
=C2=A0 |= <-- answer 1 (sendonly) ---|
=C2=A0 |<-----ICE/DTLS start------>|

=C2=A0 .time passes, caller accepts.

=C2=A0 |<-- offer 2 (sendrecv) ----|
=C2=A0 |<---- callee media!!! = -----|
=C2=A0 |--- answer 2 (sendrecv) -->|
=C2=A0 |-----= caller media!!! ---->|

New APIs needed:
- c= reate dummy sender using addTrack(null)
- RTCRtpReceiver.active p= roperty, which controls whether a receiver indicates that it actually wants= to receive media (by setting a=3Dsendonly instead of a=3Dsendrecv)

Annotated code sample:
- caller place= s call -

- caller creates audio track and o= ffers it -
track =3D gUM(audio)=C2=A0
sender =3D ad= dTrack(track)=C2=A0
createOffer.then().setLD(offer).then().signal= (offer)=C2=A0
// offer is a=3Dsendrecv

- callee gets offer, sets receiver as not active, adds dummy send = track, answers -
offer =3D receive()
setRD(offer)
receiver =3D getReceivers()[0]
receiver.active =3D false=
sender =3D addTrack(null)
createAnswer.then().setLD(an= swer).then().signal(answer)
- answer is a=3Dsendonly. Ensures = caller doesn't send media during ring -

- caller gets answer, o/a 1 complete -
answer =3D receiv= e()
setRD(answer)

- ICE and DTLS star= t -

- time passes -=C2=A0
- callee accepts call -

- ca= llee creates audio track, replaces dummy track, toggles receiver, offers -<= /i>
track =3D gUM(audio)
sender.setTrack(track)
receiver.active =3D true
createOffer.then().setLD(offer).then(= ).signal(offer) // offer is a=3Dsendrecv

- call= ee -> caller media flows -

- callee gets= offer, replies with normal answer -=C2=A0
offer =3D receive(= );
setRD(offer)
createAnswer.then().setLD(answer).then(= ).signal(answer) // answer is a=3Dsendrecv

- ca= ller -> callee media flows -

- callee ge= ts answer, o/a 2 complete -
answer =3D receive();
s= etRD(answer);






_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--f46d04440196627ab2051b9a0456-- From nobody Fri Jul 24 00:50:13 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4CC1B3013 for ; Fri, 24 Jul 2015 00:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XYJBJtPEGv0 for ; Fri, 24 Jul 2015 00:50:09 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00F61B2FFA for ; Fri, 24 Jul 2015 00:50:06 -0700 (PDT) Received: by ykay190 with SMTP id y190so13630279yka.3 for ; Fri, 24 Jul 2015 00:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ydNBBgMaoXnFwCZX9qgnnI4xv1X+TbFpvnWv0yw9j5g=; b=zRSQK8Hti9NUE6Rhd2QAwQqd9bwDNTKDEIzq8r5xPL0v7huXvWPbbPIfqQuNLqGiUV hng5zhMn6t47Sm80NFSMxpcOcMZJGIW+n5I4iEcP5N5GXiDUKMIaDPxNo7XKH5PIzCuh JiVmJqSH+1NGTQRFh0alve8wJPMrbX4vp3VEih6z+Opzz7P4Cf5dexNX96YvRNpY0BJP GC84V/HOYwhh1QGwxEuKd3U93qz2RedqMwmyRW9uPLeZrTo+N1RCj6ajE5jpwlEY6u/T Z5ddnsec7B9NY7560c3ooVakkP0MTSuvHWWRd2XldUulndKBOc99YDOd1jx93que6P4u 0DZw== MIME-Version: 1.0 X-Received: by 10.129.36.14 with SMTP id k14mr13415006ywk.64.1437724206237; Fri, 24 Jul 2015 00:50:06 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 24 Jul 2015 00:50:06 -0700 (PDT) In-Reply-To: References: <55B1624D.4050908@jesup.org> Date: Fri, 24 Jul 2015 09:50:06 +0200 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Randell Jesup , Cullen Jennings , "rtcweb@ietf.org" , Eric Rescorla Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 07:50:12 -0000 On 24 July 2015 at 00:31, Peter Thatcher wrote: > PeerConnection.addTrack(null) I'm not entirely comfortable with the notion that we allow null arguments. Doing that could be a footgun. Especially since it is only to support what I consider to be a corner case (even though it might be an important one). From nobody Fri Jul 24 01:54:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998171A1B92 for ; Fri, 24 Jul 2015 01:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTHT6FrncgKG for ; Fri, 24 Jul 2015 01:54:56 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B621A1B2E for ; Fri, 24 Jul 2015 01:54:56 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so10940845lbb.0 for ; Fri, 24 Jul 2015 01:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wcEocUMhLKT6fcPVvwF8WHtKqvMUu8em+bZLyfbZhOI=; b=mlDErFxCLYbnIYVuS4E50jIPR1mebfvQ19QBRXC1k67W6Vc9In7ElHFq2a30kX5//q Mx8jS1SJY+WkkT4LoU+qDT5oAhVr1E+ELvK8s5gQkUiqqWr0dfuD1u4xOqOZ2gUVUJk1 tvBJh2BEUWMsZepoVJca0/bCQyda2K8cbx4ubsIBqsF9dCULk7CicWRaMfGF4y6XkQRH oL8tBInDElB2nlzKi0DDhtWaki72sXpfE5SU3ulphBCYBUK5JENZsdZTeADfz4P8Auxy rdkP+ZEphludVZl7E4pzV+o8EVAWnKfblpQxloWAbZiw2VUraaEpnMhrpRAt2H+TMgmg 6DfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wcEocUMhLKT6fcPVvwF8WHtKqvMUu8em+bZLyfbZhOI=; b=E+wN/8gJOFB5X6NZjQ3XrLtkArRpzIQxm2oeYSM+igQY+yf20fSyvfJjnkf8RtWSo9 rQIiRZD96bUyTKvizlwEx3dcYI4k/Dq8r7m8bC5KkrJ69jsw8QAvDtgbG4lXJ3yEltPn oQCGX0kLrGrSHA6KzXAD60EQniaNPbEcqKSvGUU06zim189ZvLZZNzFG7T4DSa9rhkx/ htXd4vjPctnUiYaq8JR+SfrvK68g2VHtTOkEued+PMPJlMHSPHSPbCPU4V8Q5dfUlVw3 QBD0XjKbXchkji75A8pQIjnQ335yYH6bqJXBbjaudMpNM+9zf1PLuQ9IvBBnifp8w7tD MaDw== X-Gm-Message-State: ALoCoQmTGl+eOSdZv/VXjrnd7SZRaMJAl28mawwAwX0WDwwjajdFibKWE2qkWaZQLJtt+8BchZ2Z X-Received: by 10.112.120.227 with SMTP id lf3mr12846627lbb.12.1437728094462; Fri, 24 Jul 2015 01:54:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.91.135 with HTTP; Fri, 24 Jul 2015 01:54:14 -0700 (PDT) In-Reply-To: <55B1CA54.9050809@jesup.org> References: <55B1624D.4050908@jesup.org> <55B1CA54.9050809@jesup.org> From: Peter Thatcher Date: Fri, 24 Jul 2015 01:54:14 -0700 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=047d7bfd05085acbfa051b9b28ba Archived-At: Cc: "" Subject: Re: [rtcweb] Congestion warmup X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 08:54:58 -0000 --047d7bfd05085acbfa051b9b28ba Content-Type: text/plain; charset=UTF-8 Could the new flexfec payload type be used for padding? On Thu, Jul 23, 2015 at 10:17 PM, Randell Jesup wrote: > I'd love to be able to warm up congestion control, and not just DTLS. > That requires sending data and allowing it to increase to probe the > connection and open the congestion window, and preferably sending in both > directions (i.e. a=sendrecv in the warm-up answer). > > We'd need to find a way to generically pad RTP packets to a target size > (since encoding a static/black image won't use enough bytes). The obvious > codec-agnostic mechanism would be a header extension. Since they can be > any 4-byte-multiple size, that would pretty much work up to ~384K (1500 > byte packets, 1/frame @30fps). However, we could run the fake video > framerate arbitrarily high to hit any bandwidth target we need. > > Alternatively (and *much* better) we could use a "fake" codec > (a=rtpmap:111 fake/90000) which doesn't actually include any real data, > just padding. Advantages: no CPU code to encode/decode. No dealing with > header extensions. Clear indication if the other side wants to do spinup > (they can reject the codec if they don't want to). No encoding/decoding > CPU use. > > The offer would include it as a least-preferred codec to indicate warmup > support. If answerer answers with fake as the accepted codec (and real > codecs following), it's a warmup answer. Both sides will send and receive > fake data to spin up the congestion windows (and also the jitter buffers, > etc). On actual answer, the fake codec would be dropped (or dropped to > bottom priority). The answerer would start sending in a real codec, which > would work since the warmup answer would have included that codec. The > offerer would see the incoming real-codec packets, and decode them. When > the real answer arrives, it will show the accepted codec has changed, and > the offerer will install that answer and thus and start sending (real) > media. > > We still need a way to tell the system at the answerer side "I want to > accept but it's a warm-up accept" (and perhaps if we want to spin up > congestion control or not while waiting), and a way to say on the offerer > side "I want to offer/use warmups". For those API points see the previous > options from myself and Peter - or simply a way to say createAnswer of a > warmup answer, and have that agree to all tracks with fake codecs being > primary. > > I'll note that all of these methods would benefit from a mechanism to > indicate the desired bitrate targets for each fake track; for solutions > that use some sort of fake video input (canvas.captureStream/etc) it > inherently allows the application to define the size and framerate, which > are the primary knobs used by the browser for setting 'max total bitrate' > for the track. You don't want the application to set the bandwidth > directly, you want it to define the parameters of the video stream so the > system can set "reasonable" limits for that resolution & situation. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bfd05085acbfa051b9b28ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Could the new flexfec payload type be used for padding?= =C2=A0

On Thu, Jul 23, 2015 at 10:17 PM, Randell Jesup <randell-ietf@jesup= .org> wrote:
I'd love t= o be able to warm up congestion control, and not just DTLS.=C2=A0 That requ= ires sending data and allowing it to increase to probe the connection and o= pen the congestion window, and preferably sending in both directions (i.e. = a=3Dsendrecv in the warm-up answer).

We'd need to find a way to generically pad RTP packets to a target size= (since encoding a static/black image won't use enough bytes).=C2=A0 Th= e obvious codec-agnostic mechanism would be a header extension.=C2=A0 Since= they can be any 4-byte-multiple size, that would pretty much work up to ~3= 84K (1500 byte packets, 1/frame @30fps). However, we could run the fake vid= eo framerate arbitrarily high to hit any bandwidth target we need.

Alternatively (and *much* better) we could use a "fake" codec (a= =3Drtpmap:111 fake/90000) which doesn't actually include any real data,= just padding.=C2=A0 Advantages: no CPU code to encode/decode.=C2=A0 No dea= ling with header extensions.=C2=A0 Clear indication if the other side wants= to do spinup (they can reject the codec if they don't want to).=C2=A0 = No encoding/decoding CPU use.

The offer would include it as a least-preferred codec to indicate warmup su= pport.=C2=A0 If answerer answers with fake as the accepted codec (and real = codecs following), it's a warmup answer.=C2=A0 Both sides will send and= receive fake data to spin up the congestion windows (and also the jitter b= uffers, etc).=C2=A0 On actual answer, the fake codec would be dropped (or d= ropped to bottom priority).=C2=A0 =C2=A0The answerer would start sending in= a real codec, which would work since the warmup answer would have included= that codec.=C2=A0 The offerer would see the incoming real-codec packets, a= nd decode them.=C2=A0 =C2=A0When the real answer arrives, it will show the = accepted codec has changed, and the offerer will install that answer and th= us and start sending (real) media.

We still need a way to tell the system at the answerer side "I want to= accept but it's a warm-up accept" (and perhaps if we want to spin= up congestion control or not while waiting), and a way to say on the offer= er side "I want to offer/use warmups".=C2=A0 For those API points= see the previous options from myself and Peter - or simply a way to say cr= eateAnswer of a warmup answer, and have that agree to all tracks with fake = codecs being primary.

I'll note that all of these methods would benefit from a mechanism to i= ndicate the desired bitrate targets for each fake track; for solutions that= use some sort of fake video input (canvas.captureStream/etc) it inherently= allows the application to define the size and framerate, which are the pri= mary knobs used by the browser for setting 'max total bitrate' for = the track.=C2=A0 =C2=A0You don't want the application to set the bandwi= dth directly, you want it to define the parameters of the video stream so t= he system can set "reasonable" limits for that resolution & s= ituation.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bfd05085acbfa051b9b28ba-- From nobody Fri Jul 24 01:57:53 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB4C1A6EE7 for ; Fri, 24 Jul 2015 01:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBRJkHAaefhP for ; Fri, 24 Jul 2015 01:57:44 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E95B1A6EE4 for ; Fri, 24 Jul 2015 01:57:44 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so10888620lbb.3 for ; Fri, 24 Jul 2015 01:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VzpJbOvVjRAVXho7rcjypnV7vkmZ/N4eZFMASgcyvgc=; b=BLPUmrVlikSZOACRg8p6W/FlQI0nWHSq/B72yEBk/FKxqiqQW+cnxiO1pkkeuHky5A H5ZasDo4jzvq73WFLLg2w/SeCFP5aX7TP1rN6FHrTnF34Zlk9LxFYB0+q7PCYFzyHUS4 hB4bpClla4YIFCwwClOVRF1KEraK1OYjQFIEKx4sVHe/tFXn+wgTNl/0xaZD5Z8K37Vs HJg8QY+ikuo8xdbh046r8SDAbK1fA1skwyOq3wPZkDbZOKW+r+eypuccK0tue+kNiSUz ZCn/TkEyW1QZAGV5PabVdtgHK6CX7DsigGiX+Om8kJFZ2PMvgWci4xDO+HOei99xjrA6 LvNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VzpJbOvVjRAVXho7rcjypnV7vkmZ/N4eZFMASgcyvgc=; b=OiOtJw2k3ZSdeumXOXgVOy2O3rJtZ4wdyfHwFLLGlxFwl9p6hvFDtRn1rTR2uM6aqw a8Sh7nGmCIrggL4oXmCRP+JiQjJcF3VSsmrAoV1U1nkKroMnEeoB4uTF+cZn3NDKlwop crFZo5/R2BNSmLyMjEdOgso22eyIeYXF9lU/jIaAgEAbUbUKbeQxbtvwNjE2vBaiLQtb 5HMPm7udkxJ6k2AU7Kjmmg7ds8An4OsxpgM1yh0QjsIBaoEQDZHyATQuctEuskSgMj86 XrFlpKeyHZK4ysH1x0Bue78A6SVBTHghB07V2jIwApOG3UyuDqV0MIzLm3jqDTtiPh5r t5MQ== X-Gm-Message-State: ALoCoQnoFqMhvP66FcxmLbB1Xo/6G08Ve5wPwA9Rorc8j+h5oaJZXca5LEfXhpAol0I9yhGGsmHS X-Received: by 10.152.10.148 with SMTP id i20mr12253860lab.63.1437728262671; Fri, 24 Jul 2015 01:57:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.91.135 with HTTP; Fri, 24 Jul 2015 01:57:03 -0700 (PDT) In-Reply-To: References: <55B1624D.4050908@jesup.org> From: Peter Thatcher Date: Fri, 24 Jul 2015 01:57:03 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11331df061837b051b9b3215 Archived-At: Cc: Randell Jesup , Cullen Jennings , "rtcweb@ietf.org" , Eric Rescorla Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 08:57:45 -0000 --001a11331df061837b051b9b3215 Content-Type: text/plain; charset=UTF-8 Would you be comfortable with either addTrack("audio") or createRtpSender("audio")? On Fri, Jul 24, 2015 at 12:50 AM, Martin Thomson wrote: > On 24 July 2015 at 00:31, Peter Thatcher wrote: > > PeerConnection.addTrack(null) > > I'm not entirely comfortable with the notion that we allow null > arguments. Doing that could be a footgun. Especially since it is > only to support what I consider to be a corner case (even though it > might be an important one). > --001a11331df061837b051b9b3215 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would you be comfortable with either addTrack("aud= io") or createRtpSender("audio")?

On Fri, Jul 24, 2015 at 12:50 AM= , Martin Thomson <martin.thomson@gmail.com> wrote:
On 24 July 2015 at 00:31, = Peter Thatcher <pthatcher@google= .com> wrote:
> PeerConnection.addTrack(null)

I'm not entirely comfortable with the notion that we allow null<= br> arguments.=C2=A0 Doing that could be a footgun.=C2=A0 Especially since it i= s
only to support what I consider to be a corner case (even though it
might be an important one).

--001a11331df061837b051b9b3215-- From nobody Fri Jul 24 01:59:11 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F0E1A6F30 for ; Fri, 24 Jul 2015 01:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VTW-Deor3OE for ; Fri, 24 Jul 2015 01:59:00 -0700 (PDT) Received: from gateway33.websitewelcome.com (gateway33.websitewelcome.com [192.185.145.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B674B1A1B81 for ; Fri, 24 Jul 2015 01:59:00 -0700 (PDT) Received: by gateway33.websitewelcome.com (Postfix, from userid 500) id 291A38E55A3A9; Fri, 24 Jul 2015 03:59:00 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway33.websitewelcome.com (Postfix) with ESMTP id 152FD8E55A367 for ; Fri, 24 Jul 2015 03:59:00 -0500 (CDT) Received: from [31.133.177.13] (port=49231 helo=dhcp-b10d.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZIYol-0008Ak-7I for rtcweb@ietf.org; Fri, 24 Jul 2015 03:58:59 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 24 Jul 2015 10:58:55 +0200 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.177.13 X-Exim-ID: 1ZIYol-0008Ak-7I X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-b10d.meeting.ietf.org) [31.133.177.13]:49231 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 17 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [rtcweb] Day 2 updated agenda and slides up X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 08:59:02 -0000 I=92ve updated/uploaded the agenda to = http://datatracker.ietf.org/meeting/93/materials.html spt= From nobody Fri Jul 24 02:01:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957411A6EE7 for ; Fri, 24 Jul 2015 02:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcpU487rPmtk for ; Fri, 24 Jul 2015 02:01:37 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42EFC1A023E for ; Fri, 24 Jul 2015 02:01:35 -0700 (PDT) Received: by wibud3 with SMTP id ud3so18565877wib.0 for ; Fri, 24 Jul 2015 02:01:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=X9YrnpVIFjgenAgUb2gHBX7fIOUWa7h5xaf4rD/zfgI=; b=j2OyLusqe3P4ckFW7xlRIXI6EYRQZtF7nq9EhDmGTxhwjNzeI0lsrczNbnzKYTrIOy o79ChHlgKEVSay9w7iDAWRxBZ36DFLsp/kDKVqDGJuiateb+nfWBde7vmq6+dGYHNCBm aNBo277rEmLUnxk0bVli4HRRWle0geKj1k0S7DdZ08Pd5sz83yKxQJnLHrmrnx61MGUt pBvUgPxXZTvOtsTQpm+83WcoQhK8NIt6tQik9mWeV1/y6Gg8qpVC01C5mluUVo4ai6Mr 3O3kzAY5j354UweYzmFJW9BhLuGvtHZGVArBpbbJqbn8+u04S+gwimZr+6l5IEY+7VtH GQ3g== X-Gm-Message-State: ALoCoQmquA+V+tjuThG9T7HGlRRZDqCQU3Be4IEgev3BhVvHUqTMwHK/JJIE7m8yXT4DaBO6tF2l X-Received: by 10.180.208.114 with SMTP id md18mr5199919wic.31.1437728494000; Fri, 24 Jul 2015 02:01:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Fri, 24 Jul 2015 02:00:54 -0700 (PDT) In-Reply-To: References: <55B1624D.4050908@jesup.org> From: Eric Rescorla Date: Fri, 24 Jul 2015 11:00:54 +0200 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a11c37eb82b2dba051b9b40ee Archived-At: Cc: Randell Jesup , Cullen Jennings , Eric Rescorla , "rtcweb@ietf.org" Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 09:01:38 -0000 --001a11c37eb82b2dba051b9b40ee Content-Type: text/plain; charset=UTF-8 On Fri, Jul 24, 2015 at 10:57 AM, Peter Thatcher wrote: > Would you be comfortable with either addTrack("audio") > This seems awful. > or createRtpSender("audio")? > This seems OKish -Ekr > On Fri, Jul 24, 2015 at 12:50 AM, Martin Thomson > wrote: > >> On 24 July 2015 at 00:31, Peter Thatcher wrote: >> > PeerConnection.addTrack(null) >> >> I'm not entirely comfortable with the notion that we allow null >> arguments. Doing that could be a footgun. Especially since it is >> only to support what I consider to be a corner case (even though it >> might be an important one). >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c37eb82b2dba051b9b40ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Jul 24, 2015 at 10:57 AM, Peter Thatcher <pthatcher@google.com<= /a>> wrote:
Would you be comfortabl= e with either addTrack("audio")

or createRtpSender("audio")?

This seems OKish

-Ekr
=C2=A0
On Fri, Jul 24, 2015 at 12:50 AM, Martin Tho= mson <martin.thomson@gmail.com> wrote:
On 24 July 2015 at 00:31, Peter = Thatcher <ptha= tcher@google.com> wrote:
> PeerConnection.addTrack(null)

I'm not entirely comfortable with the notion that we allow null<= br> arguments.=C2=A0 Doing that could be a footgun.=C2=A0 Especially since it i= s
only to support what I consider to be a corner case (even though it
might be an important one).


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--001a11c37eb82b2dba051b9b40ee-- From nobody Fri Jul 24 02:47:49 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572041A8797 for ; Fri, 24 Jul 2015 02:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdjwWgWcqOKR for ; Fri, 24 Jul 2015 02:47:44 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0686.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::686]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D635E1A872C for ; Fri, 24 Jul 2015 02:47:43 -0700 (PDT) Authentication-Results: google.com; dkim=none (message not signed) header.d=none; Received: from [193.147.51.18] (193.147.51.18) by VI1PR02MB1248.eurprd02.prod.outlook.com (10.163.164.148) with Microsoft SMTP Server (TLS) id 15.1.219.17; Fri, 24 Jul 2015 09:47:24 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_F867641C-6ED8-41D9-B36C-71C2ECA48F67" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: =?iso-8859-1?Q?Luis_L=F3pez_Fern=E1ndez?= In-Reply-To: Date: Fri, 24 Jul 2015 11:47:19 +0200 Message-ID: <8C392F53-3FC9-46B7-A8A5-C4D3F584DDED@urjc.es> References: <55B1624D.4050908@jesup.org> <55B1CA54.9050809@jesup.org> To: Peter Thatcher X-Mailer: Apple Mail (2.1510) X-Originating-IP: [193.147.51.18] X-ClientProxiedBy: AM3PR06CA022.eurprd06.prod.outlook.com (10.141.192.140) To VI1PR02MB1248.eurprd02.prod.outlook.com (25.163.164.148) X-Microsoft-Exchange-Diagnostics: 1; VI1PR02MB1248; 2:Tk4FeWqQK0ExG9GNtYXyzA1fNyiEEtFHUVWAS5We4LwPULUWxxRYaPQskavyOjVz; 3:s/rGK2b9BBQusb6h8rAsQl803CnKovMgDepj9RVyk8SnDahYkt3WwCYK8gXog8Uw24cMSrOpQLapvmYDgT/VgDzJhQoowe5TjtllMU/oUFQ+e48t+qyHCeCIzr66k7rhtL93Izp2VQYMo2P7nr7bgA==; 25:aMa2xk/ghmBuVr+QnqDOAJFl2EbVaIIeBug3FONx3f+1JTSdqYZuuDh06Iajw6k7fdIN6f0oo7xMG26zHc49OjvAJhiDXQ2VhklFajPOCZE/0KNajQSW+kb5NIcu0yi0VeU9eqZS33gsNQXA8+MomJ7JsOqGJuvpWazPoKXAUMvEPQbFasOjV3l7VGH6MPn7rptVXC46eH3RSV+wGfzGD4Rli+ofLBzkIaEYzyGfnQ1NQyRTSNNOxMnZpHvzDpG+ILPnqiEaY9huUnlo9UckwQ==; 20:vHC2KfIF3PxOmbBLxQyeXhBQXT+oQK97J2fflzPj8827522jHnOwlqPnQtgJEvbSul1gP/aJ7qKerYaAj/B8mUvRekvmsKOP654g8EC3QyyL5gbOSnBtA3tnnWuEtzt4QX4zDbGr9rig9SIRWUXa/gfojvjpdxL7Jt+TW6ZufoowCVYwKggpMSAfC46br8u7wi/mH5gmCwXH3U4NggwKI4mSvj5HpZQ3bZxIAbT7cFI1jJhwRQvZjF38qay/X5an5kkSxZyCDu5BW3L1BFbufqIbPFGAIjRrcbE9IhfU3PvKUT9zUPOKRwIgO1Org3N0GztB7r2scC+qoSwHbYrfZn629M2AY5gnmfJA9MMYSlSk+NTxCFlDZJ19+/iUlIKhgIQk4lMUDhdJ9N/ADFmRTNH/qj5zzMrioBID385MHmk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR02MB1248; VI1PR02MB1248: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:VI1PR02MB1248; BCL:0; PCL:0; RULEID:; SRVR:VI1PR02MB1248; X-Microsoft-Exchange-Diagnostics: 1; VI1PR02MB1248; 4:JrIoBcEKNP5vbtpy71/vm8PbBL6RYgQrJhvvYmztlJB5S0PqEzHixWXD9YzvelE7z4YYzu1j2/G9aKP+iWwO6QsySxk5SQllG3VDlCU39gEeShkXq3vdWT1NwpnrcNk1bgzlygxpOuJh21YbcKcAXfY2Aweh6mzTA6+7z4mRUDzrZZ0tRTSHqx/UkwTFtUaZDGj6KHs4kufNVJ4k5N1bxJW6yyR35E62BgEH8EWJgzn0aG3iqeRA73IeIEqfn6yXSDzM9QrZ9lNkArKj3vlqP+YOMiIdISP1LDmgf52PMCc= X-Forefront-PRVS: 0647963F84 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(377454003)(24454002)(479174004)(69556001)(93886004)(77096005)(19580395003)(122386002)(77156002)(19617315012)(57306001)(62966003)(82746002)(5001960100002)(92566002)(76176999)(87976001)(50986999)(66066001)(16236675004)(15975445007)(110136002)(50226001)(19580405001)(512934002)(36756003)(42186005)(2950100001)(74482002)(189998001)(86362001)(40100003)(83716003)(33656002)(84326002)(46102003)(3940600001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR02MB1248; H:[193.147.51.18]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR02MB1248; 23:fPQr8YB1OLJy/+9PYqIu4YneARw+atW+U6PQC3Tpy?= =?us-ascii?Q?UwsaToPmZifnAkYI8rzqU6fJwuTNtGmJk/BVZWR9TZwx60yAGt1sFIXnhWy2?= =?us-ascii?Q?oBobQPVDIuGvMq3VVi9bW46HqjqMebrtTt7MTKzbHi4xpP2ww6MG4M/WFACr?= =?us-ascii?Q?fJBZkmxP3gsoilzt0R9E4833i7LKRO7Q1pwLOWxVhaMW4j7BM+o5CJ1Slo7O?= =?us-ascii?Q?3Xp2LhcjYptQWVQaJuKDxeKvoUVGDtdqNMu+UePF3xBzB9ttFykkfbd7PPAC?= =?us-ascii?Q?Dh4/UkhDLkGdfJZKz2jmb4gtC9cuCixs72GlNNOIDdffY+YdISJX+ibaJ24I?= =?us-ascii?Q?NOkCL01F5NqeUriV+HSA8PsTn054PCY7lKfNFtUF+goZW1MXV9l5kW0r3PVE?= =?us-ascii?Q?yhGT+1bR8hofZmxsUP/Nqkn5V8+a30hSR4OH64MZDD3j4kB37PDoi6IeTqUK?= =?us-ascii?Q?pyqkYXHqB4JZp3ONqvwikL4UOD7TR4e3rcBAgZ0JHdvNKclo4kHzcUvFZckw?= =?us-ascii?Q?hRi3Z3+KVrikAjLE7BUtbIAQoicHW+EcRemUan3Yohe8aGwIOgxWqCBtgwM4?= =?us-ascii?Q?ZEg8E5v+hW6J+k05N29eH6EYLg1Y4pQ0VW4wl7ph3fJFb38aLVvpRs4t1ylM?= =?us-ascii?Q?AVaxQJQmSgWbEhDvw7l6w4Ci1V9RlCXsB93zLHttObGvrg7Fbz2Str6mMZGZ?= =?us-ascii?Q?93QRxdM/BaSbcLdVLYMWYFvllrCE7HR4Wi4qrMD2B2WzqN657F0lk+TEjC1C?= =?us-ascii?Q?s7ToqWCeCFu9uneCYUyfX6AegMzvSsN9nQjxlA2i4l830BzaAp0xu39Nu45f?= =?us-ascii?Q?VVI8voMlRntcUH6froLQQuyxOGUEjAwKEPY5tFhkCV1rWaTqwm1hqKxUOn34?= =?us-ascii?Q?cJckcVg/6rrso+eKXygcCnczBNpG4yprdj5zV2MZ56r3N40gtoJy7uhOkGGh?= =?us-ascii?Q?roQBPF8RvIPJsCDyEk9bFoHPvDVAuC8xlocQJl/t2THkujsIt27QZOyoN+jz?= =?us-ascii?Q?HFIqPmRp1vUzKAAneX291gMO8X4olUL2DwlQKhezHp8+EJ7vnTWkQwMLsRMd?= =?us-ascii?Q?VRiDLo=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR02MB1248; 5:Gg7t8hhYVOQSg16u3jUT+dq0fQLzs1y3DW16EGpcv08v5ly+TnwPRaBXUbap9Vw8gchZpkxW+5zz2roiIGvjoJbrlDPI2cgkMlS01GwsTBPNrsK8vE7MysrBPchBWhmQRRTpJSumjIqDYGQRU2WAYA==; 24:XMikWVQwi/yQ0UlePPhZ37HW3IbuedxsPYR3vetQ+xC8DQsPBdo67kfxikkLzmM5Ng/qLQFu+Bu8sw43tZAlPBc5JFEwl7/8dY8iH9OyooI=; 20:UvNOY7CphNBoaZ05cB9j3zTbv8vSiumQiqyNOYRwO1dvDa6MtVCeO+cgU/Zyr1MGo07tqeS7HpHZKcVkqEE6Zw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: urjc.es X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2015 09:47:24.8514 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR02MB1248 Archived-At: Cc: Randell Jesup , "" Subject: Re: [rtcweb] Congestion warmup X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 09:47:47 -0000 --Apple-Mail=_F867641C-6ED8-41D9-B36C-71C2ECA48F67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" This is an interesting possibility. Using some kind of fec as padding = could make possible to avoid using a fake codec allowing receivers to = behave normally and without requiring implementing a different behavior = for the fake codec data. In addition, this protection of the encoded = static/black image may avoid PLIs in case of severe packet loss when = hitting a BW during the probe. This could be even used as a probe = mechanism for BW estimation with the call fully open, but this is = another story. El 24/07/2015, a las 10:54, Peter Thatcher = escribi=F3: > Could the new flexfec payload type be used for padding? =20 >=20 > On Thu, Jul 23, 2015 at 10:17 PM, Randell Jesup = wrote: > I'd love to be able to warm up congestion control, and not just DTLS. = That requires sending data and allowing it to increase to probe the = connection and open the congestion window, and preferably sending in = both directions (i.e. a=3Dsendrecv in the warm-up answer). >=20 > We'd need to find a way to generically pad RTP packets to a target = size (since encoding a static/black image won't use enough bytes). The = obvious codec-agnostic mechanism would be a header extension. Since = they can be any 4-byte-multiple size, that would pretty much work up to = ~384K (1500 byte packets, 1/frame @30fps). However, we could run the = fake video framerate arbitrarily high to hit any bandwidth target we = need. >=20 > Alternatively (and *much* better) we could use a "fake" codec = (a=3Drtpmap:111 fake/90000) which doesn't actually include any real = data, just padding. Advantages: no CPU code to encode/decode. No = dealing with header extensions. Clear indication if the other side = wants to do spinup (they can reject the codec if they don't want to). = No encoding/decoding CPU use. >=20 > The offer would include it as a least-preferred codec to indicate = warmup support. If answerer answers with fake as the accepted codec = (and real codecs following), it's a warmup answer. Both sides will send = and receive fake data to spin up the congestion windows (and also the = jitter buffers, etc). On actual answer, the fake codec would be dropped = (or dropped to bottom priority). The answerer would start sending in a = real codec, which would work since the warmup answer would have included = that codec. The offerer would see the incoming real-codec packets, and = decode them. When the real answer arrives, it will show the accepted = codec has changed, and the offerer will install that answer and thus and = start sending (real) media. >=20 > We still need a way to tell the system at the answerer side "I want to = accept but it's a warm-up accept" (and perhaps if we want to spin up = congestion control or not while waiting), and a way to say on the = offerer side "I want to offer/use warmups". For those API points see = the previous options from myself and Peter - or simply a way to say = createAnswer of a warmup answer, and have that agree to all tracks with = fake codecs being primary. >=20 > I'll note that all of these methods would benefit from a mechanism to = indicate the desired bitrate targets for each fake track; for solutions = that use some sort of fake video input (canvas.captureStream/etc) it = inherently allows the application to define the size and framerate, = which are the primary knobs used by the browser for setting 'max total = bitrate' for the track. You don't want the application to set the = bandwidth directly, you want it to define the parameters of the video = stream so the system can set "reasonable" limits for that resolution & = situation. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_F867641C-6ED8-41D9-B36C-71C2ECA48F67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
This is an interesting possibility. Using = some kind of fec as padding could make possible to avoid using a fake = codec allowing receivers to behave normally and without requiring = implementing a different behavior for the fake codec data. In addition, = this protection of the encoded static/black image may avoid PLIs in case = of severe packet loss when hitting a BW during the probe. This could be = even used as a probe mechanism for BW estimation with the call fully = open, but this is another story.

El 24/07/2015, a las 10:54, Peter Thatcher <pthatcher@google.com> = escribi=F3:

Could the new flexfec = payload type be used for padding?  

On Thu, Jul 23, = 2015 at 10:17 PM, Randell Jesup <randell-ietf@jesup.org> = wrote:
I'd love to be able to = warm up congestion control, and not just DTLS.  That requires = sending data and allowing it to increase to probe the connection and = open the congestion window, and preferably sending in both directions = (i.e. a=3Dsendrecv in the warm-up answer).

We'd need to find a way to generically pad RTP packets to a target size = (since encoding a static/black image won't use enough bytes).  The = obvious codec-agnostic mechanism would be a header extension.  = Since they can be any 4-byte-multiple size, that would pretty much work = up to ~384K (1500 byte packets, 1/frame @30fps). However, we could run = the fake video framerate arbitrarily high to hit any bandwidth target we = need.

Alternatively (and *much* better) we could use a "fake" codec = (a=3Drtpmap:111 fake/90000) which doesn't actually include any real = data, just padding.  Advantages: no CPU code to = encode/decode.  No dealing with header extensions.  Clear = indication if the other side wants to do spinup (they can reject the = codec if they don't want to).  No encoding/decoding CPU use.

The offer would include it as a least-preferred codec to indicate warmup = support.  If answerer answers with fake as the accepted codec (and = real codecs following), it's a warmup answer.  Both sides will send = and receive fake data to spin up the congestion windows (and also the = jitter buffers, etc).  On actual answer, the fake codec would be = dropped (or dropped to bottom priority).   The answerer would = start sending in a real codec, which would work since the warmup answer = would have included that codec.  The offerer would see the incoming = real-codec packets, and decode them.   When the real answer = arrives, it will show the accepted codec has changed, and the offerer = will install that answer and thus and start sending (real) media.

We still need a way to tell the system at the answerer side "I want to = accept but it's a warm-up accept" (and perhaps if we want to spin up = congestion control or not while waiting), and a way to say on the = offerer side "I want to offer/use warmups".  For those API points = see the previous options from myself and Peter - or simply a way to say = createAnswer of a warmup answer, and have that agree to all tracks with = fake codecs being primary.

I'll note that all of these methods would benefit from a mechanism to = indicate the desired bitrate targets for each fake track; for solutions = that use some sort of fake video input (canvas.captureStream/etc) it = inherently allows the application to define the size and framerate, = which are the primary knobs used by the browser for setting 'max total = bitrate' for the track.   You don't want the application to = set the bandwidth directly, you want it to define the parameters of the = video stream so the system can set "reasonable" limits for that = resolution & situation.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

= --Apple-Mail=_F867641C-6ED8-41D9-B36C-71C2ECA48F67-- From nobody Fri Jul 24 02:52:20 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E04D1A879A for ; Fri, 24 Jul 2015 02:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_MKmC8THwEx for ; Fri, 24 Jul 2015 02:52:16 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993B31A8028 for ; Fri, 24 Jul 2015 02:52:14 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so31738880igb.0 for ; Fri, 24 Jul 2015 02:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WP6vRTMRBS5SMwkPtQuKttTC9VlF7wVO5owrBmtYIek=; b=K35RVER/cCUPTTOC5sOyxQ/uFJEybCwdwveYoF4w98JN0vSrx1oEouBbc4WA0TmtPq TxrRbf7VuByYdFKvygUdI4cKYqdvxDRIE4wdwQo18ZsKUAg2dZWE80FCQWm84c7mYvKv BYVOJB3WJh6TslUll9uTDBB4M1mVxwPIEZipX8/yt90tpAxseJRkK4awqI+9jjX7mGf+ qjd0tx+lGPgztSWcll+9J8XG9lrRefSw2K05n8XSUi70u3hRvhpr0lt7pWrY/ZI/44oj oK63bKFsZO+X8X4+/H8YaIUNXIlgOadCcNwwnBY04Y03AaP52p4nAyzvhm3gs3DLYSGB xoWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WP6vRTMRBS5SMwkPtQuKttTC9VlF7wVO5owrBmtYIek=; b=PCRsT4htjShDv6zMKbv0y+U5JgfkOp0BWWy/t+/gvc+nNC65zA8CU1ye1vwqjR4S6f 927+liC+VRe8oyytq6xUc8Sh9SkXd0pudKRPPgYc7zMkZBmOpE9c1VL7Scib/nKYCLQI LMi1EOUOUXlajvaG8GiPmH+OGxE+ARcKucGlcatSblWCYXXp9Jz4ePXQe48kFDZq/o29 qy/11fYMo+JuLle1u6eVw4U/A4L0QhRhBe6/cFILOtDdP4bKmTbFipJm8ItWOMV0tOvd 9Rc9dbazkbF2XG+XhMGBMMlst2ndvqXjE6oGtwKO3FmxReW/HYfLRdE9dBDDc4WcLJvj 38+w== X-Gm-Message-State: ALoCoQk4JjtUUw0WClWNwYL0t0xoHl419Ivth+GHrdjuGiATk51iAPOJZpMGBm560WFNVpu0Jd0S X-Received: by 10.50.102.7 with SMTP id fk7mr5263782igb.49.1437731534065; Fri, 24 Jul 2015 02:52:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.234 with HTTP; Fri, 24 Jul 2015 02:51:54 -0700 (PDT) In-Reply-To: <8C392F53-3FC9-46B7-A8A5-C4D3F584DDED@urjc.es> References: <55B1624D.4050908@jesup.org> <55B1CA54.9050809@jesup.org> <8C392F53-3FC9-46B7-A8A5-C4D3F584DDED@urjc.es> From: Justin Uberti Date: Fri, 24 Jul 2015 11:51:54 +0200 Message-ID: To: =?UTF-8?Q?Luis_L=C3=B3pez_Fern=C3=A1ndez?= Content-Type: multipart/alternative; boundary=047d7b10c8715f09af051b9bf5e3 Archived-At: Cc: Randell Jesup , "" Subject: Re: [rtcweb] Congestion warmup X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 09:52:18 -0000 --047d7b10c8715f09af051b9bf5e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I tend to think BWE warmup is out of scope for this discussion. It's not clear that the callee wants to receive perhaps substantial amounts of traffic prior to having accepted the call. On Fri, Jul 24, 2015 at 11:47 AM, Luis L=C3=B3pez Fern=C3=A1ndez wrote: > This is an interesting possibility. Using some kind of fec as padding > could make possible to avoid using a fake codec allowing receivers to > behave normally and without requiring implementing a different behavior f= or > the fake codec data. In addition, this protection of the encoded > static/black image may avoid PLIs in case of severe packet loss when > hitting a BW during the probe. This could be even used as a probe mechani= sm > for BW estimation with the call fully open, but this is another story. > > El 24/07/2015, a las 10:54, Peter Thatcher > escribi=C3=B3: > > Could the new flexfec payload type be used for padding? > > On Thu, Jul 23, 2015 at 10:17 PM, Randell Jesup > wrote: > >> I'd love to be able to warm up congestion control, and not just DTLS. >> That requires sending data and allowing it to increase to probe the >> connection and open the congestion window, and preferably sending in bot= h >> directions (i.e. a=3Dsendrecv in the warm-up answer). >> >> We'd need to find a way to generically pad RTP packets to a target size >> (since encoding a static/black image won't use enough bytes). The obvio= us >> codec-agnostic mechanism would be a header extension. Since they can be >> any 4-byte-multiple size, that would pretty much work up to ~384K (1500 >> byte packets, 1/frame @30fps). However, we could run the fake video >> framerate arbitrarily high to hit any bandwidth target we need. >> >> Alternatively (and *much* better) we could use a "fake" codec >> (a=3Drtpmap:111 fake/90000) which doesn't actually include any real data= , >> just padding. Advantages: no CPU code to encode/decode. No dealing wit= h >> header extensions. Clear indication if the other side wants to do spinu= p >> (they can reject the codec if they don't want to). No encoding/decoding >> CPU use. >> >> The offer would include it as a least-preferred codec to indicate warmup >> support. If answerer answers with fake as the accepted codec (and real >> codecs following), it's a warmup answer. Both sides will send and recei= ve >> fake data to spin up the congestion windows (and also the jitter buffers= , >> etc). On actual answer, the fake codec would be dropped (or dropped to >> bottom priority). The answerer would start sending in a real codec, wh= ich >> would work since the warmup answer would have included that codec. The >> offerer would see the incoming real-codec packets, and decode them. Wh= en >> the real answer arrives, it will show the accepted codec has changed, an= d >> the offerer will install that answer and thus and start sending (real) >> media. >> >> We still need a way to tell the system at the answerer side "I want to >> accept but it's a warm-up accept" (and perhaps if we want to spin up >> congestion control or not while waiting), and a way to say on the offere= r >> side "I want to offer/use warmups". For those API points see the previo= us >> options from myself and Peter - or simply a way to say createAnswer of a >> warmup answer, and have that agree to all tracks with fake codecs being >> primary. >> >> I'll note that all of these methods would benefit from a mechanism to >> indicate the desired bitrate targets for each fake track; for solutions >> that use some sort of fake video input (canvas.captureStream/etc) it >> inherently allows the application to define the size and framerate, whic= h >> are the primary knobs used by the browser for setting 'max total bitrate= ' >> for the track. You don't want the application to set the bandwidth >> directly, you want it to define the parameters of the video stream so th= e >> system can set "reasonable" limits for that resolution & situation. >> >> _______________________________________________ >> 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 mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b10c8715f09af051b9bf5e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I tend to think BWE warmup is out of scope for this discus= sion. It's not clear that the callee wants to receive perhaps substanti= al amounts of traffic prior to having accepted the call.

On Fri, Jul 24, 2015 at 11:47 = AM, Luis L=C3=B3pez Fern=C3=A1ndez <luis.lopez@urjc.es> wro= te:
<= div>This is an interesting possibility. Using some kind of fec as padding c= ould make possible to avoid using a fake codec allowing receivers to behave= normally and without requiring implementing a different behavior for the f= ake codec data. In addition, this protection of the encoded static/black im= age may avoid PLIs in case of severe packet loss when hitting a BW during t= he probe. This could be even used as a probe mechanism for BW estimation wi= th the call fully open, but this is another story.

El 24/07/2015, a las 10:54, Peter Thatcher <pthatcher@google.com> es= cribi=C3=B3:

Could t= he new flexfec payload type be used for padding? =C2=A0

On Thu, Jul 23, 2015 at 1= 0:17 PM, Randell Jesup <randell-ietf@jesup.org> wrote:<= br>
I'd love to be able to warm up conges= tion control, and not just DTLS.=C2=A0 That requires sending data and allow= ing it to increase to probe the connection and open the congestion window, = and preferably sending in both directions (i.e. a=3Dsendrecv in the warm-up= answer).

We'd need to find a way to generically pad RTP packets to a target size= (since encoding a static/black image won't use enough bytes).=C2=A0 Th= e obvious codec-agnostic mechanism would be a header extension.=C2=A0 Since= they can be any 4-byte-multiple size, that would pretty much work up to ~3= 84K (1500 byte packets, 1/frame @30fps). However, we could run the fake vid= eo framerate arbitrarily high to hit any bandwidth target we need.

Alternatively (and *much* better) we could use a "fake" codec (a= =3Drtpmap:111 fake/90000) which doesn't actually include any real data,= just padding.=C2=A0 Advantages: no CPU code to encode/decode.=C2=A0 No dea= ling with header extensions.=C2=A0 Clear indication if the other side wants= to do spinup (they can reject the codec if they don't want to).=C2=A0 = No encoding/decoding CPU use.

The offer would include it as a least-preferred codec to indicate warmup su= pport.=C2=A0 If answerer answers with fake as the accepted codec (and real = codecs following), it's a warmup answer.=C2=A0 Both sides will send and= receive fake data to spin up the congestion windows (and also the jitter b= uffers, etc).=C2=A0 On actual answer, the fake codec would be dropped (or d= ropped to bottom priority).=C2=A0 =C2=A0The answerer would start sending in= a real codec, which would work since the warmup answer would have included= that codec.=C2=A0 The offerer would see the incoming real-codec packets, a= nd decode them.=C2=A0 =C2=A0When the real answer arrives, it will show the = accepted codec has changed, and the offerer will install that answer and th= us and start sending (real) media.

We still need a way to tell the system at the answerer side "I want to= accept but it's a warm-up accept" (and perhaps if we want to spin= up congestion control or not while waiting), and a way to say on the offer= er side "I want to offer/use warmups".=C2=A0 For those API points= see the previous options from myself and Peter - or simply a way to say cr= eateAnswer of a warmup answer, and have that agree to all tracks with fake = codecs being primary.

I'll note that all of these methods would benefit from a mechanism to i= ndicate the desired bitrate targets for each fake track; for solutions that= use some sort of fake video input (canvas.captureStream/etc) it inherently= allows the application to define the size and framerate, which are the pri= mary knobs used by the browser for setting 'max total bitrate' for = the track.=C2=A0 =C2=A0You don't want the application to set the bandwi= dth directly, you want it to define the parameters of the video stream so t= he system can set "reasonable" limits for that resolution & s= ituation.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

=

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b10c8715f09af051b9bf5e3-- From nobody Fri Jul 24 02:56:14 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EBC1A8925 for ; Fri, 24 Jul 2015 02:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp6ED05PxAMs for ; Fri, 24 Jul 2015 02:56:11 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6C81A88D3 for ; Fri, 24 Jul 2015 02:56:07 -0700 (PDT) Received: by iecri3 with SMTP id ri3so14681149iec.2 for ; Fri, 24 Jul 2015 02:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LraeUOWe8EWEVRKM/IAUlOEdoCYaoB2dMiCvCW+at+o=; b=TCa3CNrM2Theg6gQxZQg8jeGyp9VSthrBVUPZLxl7plMQ01aAHwq7dJEusQ+e+bzbl tAyibLQ4hzLfyyWnP72DxyJMFczW1DIpO73P46pN6pVShUpWZDYWqsBYBH2h53YjtXLI yvOKj6tDSjK5cRyWDJACCvcp9K8GRhkL0pJAthNpsXKPy9yAC0BrGP43BW1Fmp1MP+to LvoFWaA91DX2QGpeVzMYThimM/zu+UZtk8tBcCKd63pBcw7Xp8LirBRbHtzwZ2Hj8PFx gEib8e4QfhUh8EKThuW0VDmLDLzJ+GLL1NPpQmz1fxoM6FiOjdm24JrGRUfKRFeLy3RV DUAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LraeUOWe8EWEVRKM/IAUlOEdoCYaoB2dMiCvCW+at+o=; b=KTGScLxqg/cEwpIUZfIfqKe/y1S7ThyRPxGOW0DVKOluZ4gOeNjH7SQCVbw739kZyA DmR51gaEbHy5LPOi6Sf8reTbJ91TbNnbakmydr6KQ5cUV0K0pcPLuB97sFTGqKByHjVW 6NEKXroKIzOmlxTSbvvQeU49GWzrsj9uJ/q5T1QDsWhYHTnWf4TO39tlU9jJCOdBDY9E f37SOaJKZVN+PHBTKyx6ENvQqXU8xVRajclEOM26ikrTu/GZcDwbLWFhV5blMoYbq5n8 uixqkjQII4oK5pWNAGf7dqDe3EhgVVep0n6IpJXJUfJdN0rjdvxwqPED++4cfUTyWGdu vKcw== X-Gm-Message-State: ALoCoQlYtCcQsCU5Ts620N89KVMyxns3l53cWPlwIqJOP5B7S8vhF7KYLNOEYe6Bf4unUXDpvmXb X-Received: by 10.107.37.14 with SMTP id l14mr22450506iol.12.1437731463324; Fri, 24 Jul 2015 02:51:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.234 with HTTP; Fri, 24 Jul 2015 02:50:41 -0700 (PDT) In-Reply-To: References: <55B1624D.4050908@jesup.org> From: Justin Uberti Date: Fri, 24 Jul 2015 11:50:41 +0200 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140c426279403051b9bf1fd Archived-At: Cc: Randell Jesup , Cullen Jennings , Eric Rescorla , "rtcweb@ietf.org" Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 09:56:12 -0000 --001a1140c426279403051b9bf1fd Content-Type: text/plain; charset=UTF-8 How about: track = new MediaStreamTrack("audio") addTrack(track) or track = new MediaStreamTrack(); track.kind = "audio"; addTrack(track) On Fri, Jul 24, 2015 at 11:00 AM, Eric Rescorla wrote: > > On Fri, Jul 24, 2015 at 10:57 AM, Peter Thatcher > wrote: > >> Would you be comfortable with either addTrack("audio") >> > > This seems awful. > > > >> or createRtpSender("audio")? >> > > This seems OKish > > -Ekr > > >> On Fri, Jul 24, 2015 at 12:50 AM, Martin Thomson < >> martin.thomson@gmail.com> wrote: >> >>> On 24 July 2015 at 00:31, Peter Thatcher wrote: >>> > PeerConnection.addTrack(null) >>> >>> I'm not entirely comfortable with the notion that we allow null >>> arguments. Doing that could be a footgun. Especially since it is >>> only to support what I consider to be a corner case (even though it >>> might be an important one). >>> >> >> >> _______________________________________________ >> 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 > > --001a1140c426279403051b9bf1fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How about:

track =3D new MediaStreamTra= ck("audio")
addTrack(track)

or= =C2=A0

track =3D new MediaStreamTrack();
track.kind =3D "audio";
addTrack(track)

On Fri, Jul 24, = 2015 at 11:00 AM, Eric Rescorla <ekr@rtfm.com> wrote:

On Fri, Jul 24, 2015 at 10:57 AM, P= eter Thatcher <pthatcher@google.com> wrote:
Would you be comfortable with either addTrack("audio&= quot;)

This seems awful.=

=C2=A0
or create= RtpSender("audio")?

T= his seems OKish

-Ekr
=C2=A0
On Fri, Jul 24, 2015 at 12:50 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 24 July 2015 at 00:31, Peter Thatcher <pthatcher@google.com= > wrote:
> PeerConnection.addTrack(null)

I'm not entirely comfortable with the notion that we allow null<= br> arguments.=C2=A0 Doing that could be a footgun.=C2=A0 Especially since it i= s
only to support what I consider to be a corner case (even though it
might be an important one).


_______________________________________________=
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


--001a1140c426279403051b9bf1fd-- From nobody Fri Jul 24 03:08:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC7C1B2F8A for ; Thu, 23 Jul 2015 23:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6gx0QLCpnP9 for ; Thu, 23 Jul 2015 23:44:57 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391321B2F88 for ; Thu, 23 Jul 2015 23:44:57 -0700 (PDT) Received: by igbij6 with SMTP id ij6so9394674igb.1 for ; Thu, 23 Jul 2015 23:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=YOKons5XP+3YCOTkkuEBEd7PQyQPE9wmnP/PU9c3Ehs=; b=wGy6Lwe5Yn9xakn+sy1PBiMz9VbrgDbc0XZ7lCnbMUN5kCvauinKRK8sSKB0PqRia3 WbdWfJTKMBG2vl6xbAONMM40J2z5tiTAcSieoZPP+p+qnlea+zKJtVq6mGGsAvxgDCkF 9KZhS0z/Zbwa7STvjGyZp2TPga9U2KXLHgqo4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc:content-type; bh=YOKons5XP+3YCOTkkuEBEd7PQyQPE9wmnP/PU9c3Ehs=; b=KGgGJ1/9rc7WkaaRR2YKduhuFi8Mhm+UhB79h8jTovlvBBCB+lZjLSno/J7CNUnTw8 +gY0owt4MM0lHChTa2EXcewoIMtwD6Ky1yxLC/3Hwpr2KY/Q38gSCFU2B8nFLCDSvC94 eGz5OxXuxdGKfZuKXqqO43a67se+T+0Z/whsUC5imghEo2BqQxWumCkc1pAH3KWhaq5u xGKbyilEUaqrwHkUO0yHlltFbKI6XWKL01E3Bev5EOWRx35EGb8duY1Ah1n1wVVO6y4U 5KpnC0uWEJ6oUfghYv92hi0DUwiS96zggX8+jIB01xC+wMyNwW3dUuAYZkiniIujC2Zm L9zQ== X-Gm-Message-State: ALoCoQk6kIU0H8eIU0Ac9WJT2KRTBCUSjvtuaAX4xL5q8Iq50QneOUCJraTjhGumg1nL5vJXBdh6S8Qzio44Md5FTbxNmaJ6t1NWhFlZmitgUwtKHHPt8bPtfVBNXT4rTXn96/FwL8xL X-Received: by 10.107.12.141 with SMTP id 13mr20724679iom.157.1437720296624; Thu, 23 Jul 2015 23:44:56 -0700 (PDT) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDF3DW1eJN5BJkjRTOuzGr2bdezjg== Date: Fri, 24 Jul 2015 08:44:41 +0200 Message-ID: <850ae9384ef867f8e2ec079d1050b60f@mail.gmail.com> To: "Black, David" , fluffy@iii.ca, Michael Tuexen Content-Type: multipart/alternative; boundary=001a113f9656913488051b995788 X-DomainID: tieto.com Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 03:08:29 -0700 Cc: rtcweb@ietf.org, tsvwg@ietf.org Subject: [rtcweb] diffserv marking for rtcwb data channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 06:44:59 -0000 --001a113f9656913488051b995788 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable HI, I don=E2=80=99t think that it makes much difference (though see further bel= ow=E2=80=A6) whether one use different sctp associations for multiple data channels with different diffserv code points or have this feature be built into SCTP. The differences I can think of are: =C2=B7 end-point performance (only significant if cache and cpu constrained) =C2=B7 flow control handling =E2=80=93 can be both good and bad to = have separate receiver windows perhaps I do question, however, whether it is a =E2=80=9Cgood=E2=80=9D choice to us= e the diffserv marking and sctp association split for prioritization of the traffic instead of SCTP scheduling differentiation within one and the same association over a non-marked or homogeneously marked network. Especially the two have very different characteristics from a (coupled) congestion control perspective (including loss recovery). But if both possibilities go in, I suppose that we will learn much more about this in the future. But one should perhaps do well to provide some starting ground rules for when one or the other is considered most appropriate to use =E2=80=93 possible try to describe the conditions u= nder which one would like to use one or the other. Finally there was a comment at the tsvwg meeting that the same 5-tuple with different diffserv markings would not get through the network =E2=80=93 if that generally is correct, then the solut= ion is very easy: one MUST use different associations to get port (5-tuple) differentiation. I think that if this is correct, one also wants to ask what happens if the diffserv is changed for the same 5-tuple =E2=80=93 i.e., is the network robust to this change even if it is not robust to concurrent usage of different markings for the same 5-tuple. BR, Karen --001a113f9656913488051b995788 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

HI,<= /p>

=C2=A0

I don=E2=80=99t think that it makes much difference (though see fu= rther below=E2=80=A6) whether one use

different = sctp associations for multiple data channels with different

diffserv code points or have this feature be built into SCTP.

=C2=A0

The differences I= can think of are:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 end-point performance (only significant if cache and cpu constrained)

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 flow control h= andling =E2=80=93 can be both good and bad to have separate receiver window= s perhaps

=C2=A0

I do q= uestion, however, whether it is a =E2=80=9Cgood=E2=80=9D choice to use the = diffserv marking and sctp association split for

p= rioritization of the traffic instead of SCTP scheduling differentiation wit= hin one and the same association over a non-marked

or homogeneously marked network.

Especially th= e two have very different characteristics from a (coupled) congestion contr= ol perspective (including loss recovery).

=C2=A0<= /p>

But if both possibilities go in, I suppose that w= e will learn much more about this in the future.

= But one should perhaps do well =C2=A0to provide some starting ground rules = for when one or the other is considered

most appr= opriate to use =E2=80=93 possible try to describe the conditions under whic= h one would like to use one or

the other. =C2=A0<= /p>

=C2=A0

Finally there wa= s a comment at the tsvwg meeting that the same 5-tuple with different diffs= erv markings would not get

through the network = =E2=80=93 if that generally is correct, =C2=A0then the solution is very eas= y: one MUST use different associations to get port (5-tuple) differentiatio= n.

I think that if this is correct, one also want= s to ask what happens if the diffserv is changed for the same 5-tuple =E2= =80=93 i.e., is the network

robust to this chang= e even if it is not robust to concurrent usage of different markings for th= e same 5-tuple.

=C2=A0

= BR, Karen =C2=A0

=C2= =A0

=C2=A0

=C2=A0

--001a113f9656913488051b995788-- From nobody Fri Jul 24 03:08:34 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87D61B2FE6; Fri, 24 Jul 2015 01:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCPwZepRH3Bw; Fri, 24 Jul 2015 01:00:40 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23E01B3033; Fri, 24 Jul 2015 01:00:15 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail91.telekom.de with ESMTP; 24 Jul 2015 10:00:09 +0200 X-IronPort-AV: E=Sophos;i="5.15,537,1432591200"; d="scan'208,217";a="877488525" Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 24 Jul 2015 10:00:10 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 24 Jul 2015 10:00:09 +0200 From: To: Date: Fri, 24 Jul 2015 10:00:07 +0200 Thread-Topic: [tsvwg] diffserv marking for rtcwb data channel Thread-Index: AdDF3DW1eJN5BJkjRTOuzGr2bdezjgAA7uAg Message-ID: References: <850ae9384ef867f8e2ec079d1050b60f@mail.gmail.com> In-Reply-To: <850ae9384ef867f8e2ec079d1050b60f@mail.gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CA7A7C64CC4ADB458B74477EA99DF6F505296744A0HE111643EMEA1_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 03:08:29 -0700 Cc: rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] diffserv marking for rtcwb data channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 08:00:43 -0000 --_000_CA7A7C64CC4ADB458B74477EA99DF6F505296744A0HE111643EMEA1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2FyZW4sDQoNCiAgICAgIEZpbmFsbHkgdGhlcmUgd2FzIGEgY29tbWVudCBhdCB0aGUgdHN2d2cg bWVldGluZyB0aGF0IHRoZSBzYW1lIDUtdHVwbGUgd2l0aA0KICAgICAgIGRpZmZlcmVudCBkaWZm c2VydiBtYXJraW5ncyB3b3VsZCBub3QgZ2V0IHRocm91Z2ggdGhlIG5ldHdvcmsg4oCTIGlmIHRo YXQgZ2VuZXJhbGx5DQogICAgICAgaXMgY29ycmVjdCwgIHRoZW4gdGhlIHNvbHV0aW9uIGlzIHZl cnkgZWFzeTogb25lIE1VU1QgdXNlIGRpZmZlcmVudCBhc3NvY2lhdGlvbnMgdG8NCiAgICAgICBn ZXQgcG9ydCAoNS10dXBsZSkgZGlmZmVyZW50aWF0aW9uLg0KICAgICAgIEkgdGhpbmsgdGhhdCBp ZiB0aGlzIGlzIGNvcnJlY3QsIG9uZSBhbHNvIHdhbnRzIHRvIGFzayB3aGF0IGhhcHBlbnMgaWYg dGhlIGRpZmZzZXJ2IGlzDQogICAgICAgY2hhbmdlZCBmb3IgdGhlIHNhbWUgNS10dXBsZSDigJMg aS5lLiwgaXMgdGhlIG5ldHdvcmsgcm9idXN0IHRvIHRoaXMgY2hhbmdlIGV2ZW4gaWYNCiAgICAg ICBpdCBpcyBub3Qgcm9idXN0IHRvIGNvbmN1cnJlbnQgdXNhZ2Ugb2YgZGlmZmVyZW50IG1hcmtp bmdzIGZvciB0aGUgc2FtZSA1LXR1cGxlLg0KDQpUYWxraW5nIGFib3V0IHRoZSBwb2xpY2llcyBv ZiB0aGUgY29tcGFueSBJIHdvcmsgZm9yIG9ubHk6DQoNClBvc3NpYmlsaXRpZXMgdG8gZW5mb3Jj ZSBRb1MgcG9saWNpZXMgYXQgYSBwcm92aWRlciBCUkFTIG9yIEJORyB0ZXJtaW5hdGluZyB3aXJl ZA0KY29uc3VtZXIgYWNjZXNzZXMgYXJlIGxpbWl0ZWQuIFFvUyBwb2xpY2llcyBiYXNlZCBvbiBm dWxsIDUgdHVwbGUgYXJlIHZlcnkNCmNvbnNlcnZhdGl2ZSBhbmQgaGFyZCB0byBtYWludGFpbi4g SSB3b3VsZG7igJl0IGV4cGVjdCBmdWxsIDUgdHVwbGUgYXMgYmFzaXMgZm9yIGEgUW9TDQpwb2xp Y3kgdGhlbi4gVHJ1c3QgaW4gdGhlIGNvcnJlY3QgaW5mb3JtYXRpb24gb24gd2hpY2ggYSBCUkFT L0JORyBjYW4NCmJhc2UgUW9TIGNsYXNzaWZpY2F0aW9uIGlzIGFuIGltcG9ydGFudCBpc3N1ZS4g SW4gYW55IGNhc2UsIEnigJlkIG5vdCBleHBlY3QNCm1vcmUgdGhhbiBvbmUgRFNDUCBpcyBhc3Np Z25lZCBiYXNlZCBvbiBzdWNoIGEgcG9saWN5IGZvciB0aGUgdGltZQ0KYmVpbmcuIEnigJltIG5v dCBhd2FyZSBvZiBhbnkgYWN0dWFsIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgZS5nLiBhbiBBRm4N CmNsYXNzIGJ5IGFsbCB0aHJlZSBQSEJzLg0KDQpBdCBpbnRlcmNvbm5lY3Rpb24gcG9pbnRzLCBh bnkgdW5leHBlY3RlZCBEU0NQIGlzIGJsZWFjaGVkLiBUaGlzIG11c3QNCmJlIGRvbmUgdG8gcHJv dGVjdCBiYWNrYm9uZSBRb1MgcHJvZHVjdGlvbi4gUW9TIHRyYW5zcG9ydCBjYW4gYmUNCm5lZ290 aWF0ZWQgZm9yIGEgc2V0IG9mIGRlZmluZWQgRFNDUHMuDQoNCkEgc3R1ZHkgb2YgdGhlIEVVIGZv dW5kIERQSSB0byBiZSBtb3JlIGNvbW1vbiBpbiB3aXJlbGVzcyBjb21tdW5pY2F0aW9uIHRoYW4g aW4gd2lyZWQgY29tbXVuaWNhdGlvbi4gSeKAmWQgbm90IGV4cGVjdCB0aGUgUW9TIHBvbGljaWVz IGluIHRoYXQgYXJlYSB0byBiZSBtb3JlIGxpYmVyYWwgdGhhbiBmb3IgZml4ZWQgYWNjZXNzIG5l dHdvcmtzIGZvciB0aGUgdGltZSBiZWluZy4NCg0KUmVnYXJkcywNCg0KUnVlZGlnZXINCg0KDQoN Cg0K --_000_CA7A7C64CC4ADB458B74477EA99DF6F505296744A0HE111643EMEA1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjozLjBjbSAyLjBjbSAzLjBjbSAyLjBjbTt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEwMDUxMjc0NzE7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjExNDc1NTY5ODYgLTI0NTU3NDMy NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjExODM1NDYwNDk7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04MjY4ODIxNjggMTI1Mjc5MjY1OCA2 NzU2NzYxOSA2NzU2NzYyMSA2NzU2NzYxNyA2NzU2NzYxOSA2NzU2NzYyMSA2NzU2NzYxNyA2NzU2 NzYxOSA2NzU2NzYyMTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFu Zz1ERSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5LYXJl biw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqDCoMKg wqDCoCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVM+RmluYWxseSB0aGVyZSB3YXMgYSBjb21t ZW50IGF0IHRoZSB0c3Z3ZyBtZWV0aW5nIHRoYXQgdGhlIHNhbWUgNS10dXBsZSB3aXRoIDxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz7CoMKg wqDCoMKgwqDCoDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPmRpZmZlcmVudCBkaWZmc2VydiBtYXJr aW5ncyB3b3VsZCBub3QgZ2V0PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiA8L3NwYW4+dGhy b3VnaCB0aGUgbmV0d29yayDigJMgaWYgdGhhdCBnZW5lcmFsbHkgPHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqDCoMKgPC9z cGFuPjxzcGFuIGxhbmc9RU4tVVM+aXMgY29ycmVjdCwgJm5ic3A7dGhlbiB0aGUgc29sdXRpb24g aXMgdmVyeSBlYXN5OiBvbmUgTVVTVCB1c2UgZGlmZmVyZW50IGFzc29jaWF0aW9ucyB0byA8c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+wqDC oMKgwqDCoMKgwqA8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz5nZXQgcG9ydCAoNS10dXBsZSkgZGlm ZmVyZW50aWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+wqDCoMKgwqDCoMKgIDwvc3Bhbj48 c3BhbiBsYW5nPUVOLVVTPkkgdGhpbmsgdGhhdCBpZiB0aGlzIGlzIGNvcnJlY3QsIG9uZSBhbHNv IHdhbnRzIHRvIGFzayB3aGF0IGhhcHBlbnMgaWYgdGhlIGRpZmZzZXJ2IGlzIDxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz7CoMKgwqDCoMKg wqDCoDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPmNoYW5nZWQgZm9yIHRoZSBzYW1lIDUtdHVwbGUg 4oCTIGkuZS4sIGlzIHRoZSBuZXR3b3JrIHJvYnVzdCB0byB0aGlzIGNoYW5nZSBldmVuIGlmIDxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz7C oMKgwqDCoMKgwqDCoDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPml0IGlzIG5vdCByb2J1c3QgdG8g Y29uY3VycmVudCB1c2FnZSBvZiBkaWZmZXJlbnQgbWFya2luZ3MgZm9yIHRoZSBzYW1lIDUtdHVw bGUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LVVTPiZuYnNwOzxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xv cjojMUY0OTdEJz5UYWxraW5nIGFib3V0IHRoZSBwb2xpY2llcyBvZiB0aGUgY29tcGFueSBJIHdv cmsgZm9yIG9ubHk6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPlBvc3NpYmlsaXRpZXMgdG8gZW5mb3JjZSBRb1MgcG9saWNpZXMgYXQgYSBwcm92aWRl ciBCUkFTIG9yPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPkJORyB0ZXJtaW5hdGluZyB3aXJlZCA8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz5jb25zdW1lciBhY2Nlc3NlcyBhcmUgbGltaXRlZC4gUW9TIHBvbGljaWVzIGJhc2VkIG9u IGZ1bGwgNSB0dXBsZSBhcmUgdmVyeSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPmNvbnNlcnZhdGl2 ZSBhbmQgaGFyZCB0byBtYWludGFpbi4gSSB3b3VsZG7igJl0IGV4cGVjdCBmdWxsIDUgdHVwbGUg YXMgYmFzaXMgZm9yIGEgUW9TIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+cG9saWN5IHRoZW4uIFRy dXN0IGluIHRoZSBjb3JyZWN0IGluZm9ybWF0aW9uIG9uIHdoaWNoIGEgQlJBUy9CTkcgY2FuIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nY29sb3I6IzFGNDk3RCc+YmFzZSBRb1MgY2xhc3NpZmljYXRpb24gaXMgYW4gaW1wb3J0 YW50IGlzc3VlLiBJbiBhbnkgY2FzZSwgSeKAmWQgbm90IGV4cGVjdCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPm1vcmUgdGhhbiBvbmUgRFNDUCBpcyBhc3NpZ25lZCBiYXNlZCBvbiBzdWNoIGEgcG9s aWN5IGZvciB0aGUgdGltZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPmJlaW5nLiBJ4oCZbSBub3Qg YXdhcmUgb2YgYW55IGFjdHVhbCByZXF1aXJlbWVudCB0byBzdXBwb3J0IGUuZy4gYW4gQUZuIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nY29sb3I6IzFGNDk3RCc+Y2xhc3MgYnkgYWxsIHRocmVlIFBIQnMuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkF0IGludGVyY29ubmVjdGlv biBwb2ludHMsIGFueSB1bmV4cGVjdGVkIERTQ1AgaXMgYmxlYWNoZWQuIFRoaXMgbXVzdCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPmJlIGRvbmUgdG8gcHJvdGVjdCBiYWNrYm9uZSBRb1MgcHJvZHVj dGlvbi4gUW9TIHRyYW5zcG9ydCBjYW4gYmUgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5uZWdvdGlh dGVkIGZvciBhIHNldCBvZiBkZWZpbmVkIERTQ1BzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+QSBzdHVkeSBvZiB0aGUgRVUgZm91bmQgRFBJIHRv IGJlIG1vcmUgY29tbW9uIGluIHdpcmVsZXNzIGNvbW11bmljYXRpb24gdGhhbiBpbiB3aXJlZCBj b21tdW5pY2F0aW9uLiBJ4oCZZCBub3QgZXhwZWN0IHRoZSBRb1MgcG9saWNpZXMgaW4gdGhhdCBh cmVhIHRvIGJlIG1vcmUgbGliZXJhbCB0aGFuIGZvciBmaXhlZCBhY2Nlc3MgbmV0d29ya3MgZm9y IHRoZSB0aW1lIGJlaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xv cjojMUY0OTdEJz5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdj b2xvcjojMUY0OTdEJz5SdWVkaWdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxOC4wcHQnPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_CA7A7C64CC4ADB458B74477EA99DF6F505296744A0HE111643EMEA1_-- From nobody Fri Jul 24 03:08:36 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B5E1A00FF for ; Fri, 24 Jul 2015 01:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id livzeHZmjY2I for ; Fri, 24 Jul 2015 01:27:42 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53931A00A1 for ; Fri, 24 Jul 2015 01:27:41 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so11137542igb.0 for ; Fri, 24 Jul 2015 01:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=7B4SeAnDi1dS5/iqKKSE8YE4tsITs7N/j6Kgp03qzY4=; b=5wIwOGsjNWsAbbcoTjZ1zGzOzphNie/jIyoXIyFLF812i2j62HjhbCZ1d1dZJI++Jv ajgHYoX5G+5VYjRCt6UnR0HRWNZDvItD4WNoa3S1xfw4DZ+JLvuFx1GYCkXBrBI9k3xI aWt2pzMiSKuQABsPfRedgMJGxm7FUkpZHiftg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=7B4SeAnDi1dS5/iqKKSE8YE4tsITs7N/j6Kgp03qzY4=; b=UTtHWiNGRpK/ctKZk+ueqTBHXxS9xWbM2pbyf3j1a+fZbI/soBNH6zteKVKsmCZo4/ FCZ7/H6NBHhOz98g4bjHGMVSHzJ482mU/SRnmuLJjMN8/o59qfGKwuOovtdKHTmGl8MI SU2brEwquFLO+gJ65QGAljY7xisIKjHlX7jyelyBrAnmB2QB1LtSLRJGJH9BSbGaErUP pQSZhTLX4QwfiN3vWvo0fr8lcoh86dNGV0gtSrL0GlPSydssicV3DYqIOnK0nQbqAvHP D240kXEKC8IeAo6AQr/hY8lGO0DFvoRXyKT98MdJYjwm44r5EnOr5S+xGN6ZSh30cDFO aVVA== X-Gm-Message-State: ALoCoQnNcqj6i+oFn2+nJp6R90uq52V4p3mPVNzIjzkLtqq7RSUYNgXocJbYfZ1BE8DIBstgVcTkqyA6TdFcOOa4BWZcnHYRYpfP2wL0oXbwUyWio0+/jMqEg0EXEVMUMvltyQatgwoI X-Received: by 10.107.156.203 with SMTP id f194mr19342122ioe.164.1437726461442; Fri, 24 Jul 2015 01:27:41 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <850ae9384ef867f8e2ec079d1050b60f@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEaCHV5UKgYnYawHYVq9vEiwt/oiAOdfkq0nzrTpCA= Date: Fri, 24 Jul 2015 10:27:41 +0200 Message-ID: <0507e383f41a53bbcda2efe478ad3ce2@mail.gmail.com> To: Ruediger.Geib@telekom.de Content-Type: multipart/alternative; boundary=001a1140cd0004d952051b9ac773 X-DomainID: tieto.com Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 03:08:29 -0700 Cc: rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] diffserv marking for rtcwb data channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 08:27:43 -0000 --001a1140cd0004d952051b9ac773 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ruediger, Thanks a lot. So I think that you=E2=80=99re saying that even if one made sure that diffe= rent diff serv markings were split on different 5-tuples, this setting likely would be bleached at the network. Is that correctly understood ? If so, then (it sounds to me =E2=80=93 not knowing too much about this) tha= t from a coupling congestion control perspective it would be preferable to use SCTP scheduling prioritization (within one and the same association) for fine granular differentiation in between multiple data channels in between the same end-points rather than differentiation by means of diff serv marking. When/if one get a more consistent and forceful ECN operation in AQMs and SCTP end-points, perhaps the coupling congestion principles achieved by means of sctp stream scheduling get to be less important. On the other hand, again as said before, having the one and the same, or multiple, flow control (receiver buffer) contexts may be a strength (simplicity) or a weakness. BR, Karen *From:* Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] *Sent:* Friday, July 24, 2015 10:00 AM *To:* karen.nielsen@tieto.com *Cc:* rtcweb@ietf.org; tsvwg@ietf.org *Subject:* AW: [tsvwg] diffserv marking for rtcwb data channel Karen, Finally there was a comment at the tsvwg meeting that the same 5-tuple with different diffserv markings would not get through the network =E2=80= =93 if that generally is correct, then the solution is very easy: one MUST use different associations to get port (5-tuple) differentiation. I think that if this is correct, one also wants to ask what happens if the diffserv is changed for the same 5-tuple =E2=80=93 i.e., is the network robust t= o this change even if it is not robust to concurrent usage of different markings for the same 5-tuple. Talking about the policies of the company I work for only: Possibilities to enforce QoS policies at a provider BRAS or BNG terminating wired consumer accesses are limited. QoS policies based on full 5 tuple are very conservative and hard to maintain. I wouldn=E2=80=99t expect full 5 tuple a= s basis for a QoS policy then. Trust in the correct information on which a BRAS/BNG can base QoS classification is an important issue. In any case, I=E2=80=99d not= expect more than one DSCP is assigned based on such a policy for the time being. I=E2=80=99m not aware of any actual requirement to support e.g. an A= Fn class by all three PHBs. At interconnection points, any unexpected DSCP is bleached. This must be done to protect backbone QoS production. QoS transport can be negotiated for a set of defined DSCPs. A study of the EU found DPI to be more common in wireless communication than in wired communication. I=E2=80=99d not expect the QoS policies in tha= t area to be more liberal than for fixed access networks for the time being. Regards, Ruediger --001a1140cd0004d952051b9ac773 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Ruediger,

=C2=A0

Tha= nks a lot.

= =C2=A0

So I = think that you=E2=80=99re saying that even if one made sure that different = diff serv markings were

split on different 5-tuples, this setting likely would be bleac= hed at the network.

=C2=A0

Is that correctly understood ?

=C2=A0

If so, then (it sounds to me =E2=80=93 not knowing too m= uch about this) that from a coupling congestion control perspective it

would be prefer= able to=C2=A0 use SCTP scheduling prioritization (within one and the same a= ssociation) for fine granular differentiation in between

multiple data channels in betw= een the same end-points rather than differentiation by means of diff serv m= arking.

=C2= =A0

When/if = one get a more consistent and forceful ECN operation in AQMs and SCTP end-p= oints, perhaps the coupling congestion

principles achieved by means of sctp stream sche= duling get to be less important.

On the other hand, again as said before, having the o= ne and the same, or multiple, flow control (receiver buffer) contexts may b= e

a strength= (simplicity) or a weakness. =C2=A0=C2=A0=C2=A0

=C2=A0

BR, Karen

= =C2=A0

From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
S= ent: Friday, July 24, 2015 10:00 AM
To: karen.nielsen@tieto.com
Cc: rtcweb@ietf.org; tsvwg@ietf.org
Subject: AW: [tsvwg] diffserv marking for = rtcwb data channel

=C2=A0

<= p class=3D"MsoNormal">Karen,

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Finally there was a comment at the tsvwg meeting that the same 5-tu= ple with

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0different diffserv markings would not get <= /span>through the network =E2=80=93 if that generally

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0is correct, =C2=A0then the= solution is very easy: one MUST use different associations to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0get port (5-tuple)= differentiation.

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I think that if this is correct= , one also wants to ask what happens if the diffserv is

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0changed for the same 5-tup= le =E2=80=93 i.e., is the network robust to this change even if

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0it is not robust t= o concurrent usage of different markings for the same 5-tuple.

=C2=A0

Talking about the policies of the c= ompany I work for only:

=C2=A0

Possibilities to enforce QoS policies at a provider BRAS or= =C2=A0BNG terminating wired

consumer accesses are limite= d. QoS policies based on full 5 tuple are very

conservative and hard to maintain. I wo= uldn=E2=80=99t expect full 5 tuple as basis for a QoS

policy then. Trust in the corr= ect information on which a BRAS/BNG can

<= span style=3D"color:#1f497d">base QoS classification is an important issue.= In any case, I=E2=80=99d not expect

more than one DSCP is assigned based on such a po= licy for the time

being. I=E2=80=99m not aware of any actual requirement to support e.= g. an AFn

c= lass by all three PHBs.

=C2=A0

At interconnection points, any unexpected DSCP is bleached. This mus= t

be done t= o protect backbone QoS production. QoS transport can be

negotiated for a set of define= d DSCPs.

= =C2=A0

A stu= dy of the EU found DPI to be more common in wireless communication than in = wired communication. I=E2=80=99d not expect the QoS policies in that area t= o be more liberal than for fixed access networks for the time being.=

=C2=A0

<= p class=3D"MsoNormal">Regards,

=C2=A0

Ruediger

=C2=A0

=C2=A0

=C2=A0

=C2=A0

<= /div>
--001a1140cd0004d952051b9ac773-- From nobody Fri Jul 24 03:08:37 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDC81A8892; Fri, 24 Jul 2015 02:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYPGVP_Od1Ew; Fri, 24 Jul 2015 02:34:13 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587F01A8988; Fri, 24 Jul 2015 02:34:12 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail41.telekom.de with ESMTP; 24 Jul 2015 11:34:09 +0200 X-IronPort-AV: E=Sophos;i="5.15,537,1432591200"; d="scan'208,217";a="712529896" Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 24 Jul 2015 11:32:35 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by he110890 ([10.134.92.131]) with mapi; Fri, 24 Jul 2015 11:32:34 +0200 From: To: Date: Fri, 24 Jul 2015 11:32:33 +0200 Thread-Topic: [tsvwg] diffserv marking for rtcwb data channel Thread-Index: AQEaCHV5UKgYnYawHYVq9vEiwt/oiAOdfkq0nzrTpCCAAAa2kA== Message-ID: References: <850ae9384ef867f8e2ec079d1050b60f@mail.gmail.com> <0507e383f41a53bbcda2efe478ad3ce2@mail.gmail.com> In-Reply-To: <0507e383f41a53bbcda2efe478ad3ce2@mail.gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CA7A7C64CC4ADB458B74477EA99DF6F5052967457EHE111643EMEA1_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 03:08:29 -0700 Cc: rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] diffserv marking for rtcwb data channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 09:34:20 -0000 --_000_CA7A7C64CC4ADB458B74477EA99DF6F5052967457EHE111643EMEA1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2FyZW4sDQoNClFvUyAgbmVlZHMgdG8gYmUgY29tbWVyY2lhbGx5IG5lZ290aWF0ZWQgYXQg aW50ZXJjb25uZWN0aW9uLiBJZiBRb1Mgc2hvdWxkIGJlIGF2YWlsYWJsZSBhdCBhIGNvbnN1bWVy IGFjY2VzcywgdGhlIGNvbnN1bWVyIGRpdmlzaW9uIG9mIGEgY29tcGFueSBtdXN0IGJlIGludm9s dmVkIGluIGFkZGl0aW9uIGFzIHdlbGwgYXMgdGhlIHRlY2huaWNhbCBzdGFmZiBzZXR0aW5nIHVw IGFuZCBtYWludGFpbmluZyB0ZWNobmljYWwgY29uZmlndXJhdGlvbnMuIDExIFBIQnMgZm9yIGEg c2luZ2xlIGNvbnN1bWVyIHNlcnZpY2UgYXJlIGEgY2hhbGxlbmdpbmcgcmVxdWlyZW1lbnQuDQoN CkFsbCBEU0NQcywgd2hpY2ggaGF2ZSBub3QgYmVlbiBuZWdvdGlhdGVkIGJldHdlZW4gYWNjZXNz IGFuZCBpbnRlcmNvbm5lY3Rpb24gYXJlIHBvc3NpYmx5IGJsZWFjaGVkLCBlc3BlY2lhbGx5IGlm IGEgbmV0d29yayBwcm92aWRlciBvcGVyYXRlcyBRb1Mgd2l0aGluIHRoZSBuZXR3b3JrLg0KDQpR b1MgdG8gbWUgbWVhbnMgb3ZlcnByb3Zpc2lvbmluZyB0byBlbnN1cmUgdHJhbnNwb3J0IGZyZWUg b2YgY29uZ2VzdGlvbi4gSWYgSSBzZWUgMTEgUEhCcyBmb3IgYSBzaW5nbGUgZmxvdywgSeKAmW0g bm90IHN1cmUgaWYgdGhpcyBhc3N1bWVzIG1vcmUgdGhhbiBDb1MgKGRyb3AgbWUgbGFzdCkuIEni gJlkIGxpa2UgdG8gcmVhZCBhIGxpdHRsZSBtb3JlIGFib3V0IGhvdyBXRUJydGMgZmlndXJlcyBv dXQgd2hpY2ggUW9TIHJlc291cmNlcyBhcmUgY29uZmlndXJlZCBhbmQgd2hpY2ggb2YgdGhlc2Ug YXJlIGF2YWlsYWJsZSBmb3Igc3VjaCBhIGZsb3cgYXQgYW4gYWNjZXNzIHdoZW4gcmVxdWlyZWQu IEhvdyBhbmQgd2hlcmUgYXJlIHRoZSByZXNvdXJjZXMgY29uc3VtZWQgYnkgZWFjaCBXRVJydGMg UEhCIGNvbnRyb2xsZWQgYW5kIGhvdyBhcmUgdGhlc2UgYWxpZ25lZCB3aXRoIHRoZSBRb1MgcmVz b3VyY2VzIGNvbnN1bWVkIGJ5IG90aGVyIHNlcnZpY2VzPw0KDQpSZWdhcmRzLA0KDQpSdWVkaWdl cg0KDQpWb246IEthcmVuIEVsaXNhYmV0aCBFZ2VkZSBOaWVsc2VuIFttYWlsdG86a2FyZW4ubmll bHNlbkB0aWV0by5jb21dDQpHZXNlbmRldDogRnJlaXRhZywgMjQuIEp1bGkgMjAxNSAxMDoyOA0K QW46IEdlaWIsIFLDvGRpZ2VyDQpDYzogcnRjd2ViQGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9yZzsg TWljaGFlbCBUdWV4ZW47IGZsdWZmeUBpaWkuY2ENCkJldHJlZmY6IFJFOiBbdHN2d2ddIGRpZmZz ZXJ2IG1hcmtpbmcgZm9yIHJ0Y3diIGRhdGEgY2hhbm5lbA0KDQpIaSBSdWVkaWdlciwNCg0KVGhh bmtzIGEgbG90Lg0KDQpTbyBJIHRoaW5rIHRoYXQgeW914oCZcmUgc2F5aW5nIHRoYXQgZXZlbiBp ZiBvbmUgbWFkZSBzdXJlIHRoYXQgZGlmZmVyZW50IGRpZmYgc2VydiBtYXJraW5ncyB3ZXJlDQpz cGxpdCBvbiBkaWZmZXJlbnQgNS10dXBsZXMsIHRoaXMgc2V0dGluZyBsaWtlbHkgd291bGQgYmUg YmxlYWNoZWQgYXQgdGhlIG5ldHdvcmsuDQoNCklzIHRoYXQgY29ycmVjdGx5IHVuZGVyc3Rvb2Qg Pw0KDQpJZiBzbywgdGhlbiAoaXQgc291bmRzIHRvIG1lIOKAkyBub3Qga25vd2luZyB0b28gbXVj aCBhYm91dCB0aGlzKSB0aGF0IGZyb20gYSBjb3VwbGluZyBjb25nZXN0aW9uIGNvbnRyb2wgcGVy c3BlY3RpdmUgaXQNCndvdWxkIGJlIHByZWZlcmFibGUgdG8gIHVzZSBTQ1RQIHNjaGVkdWxpbmcg cHJpb3JpdGl6YXRpb24gKHdpdGhpbiBvbmUgYW5kIHRoZSBzYW1lIGFzc29jaWF0aW9uKSBmb3Ig ZmluZSBncmFudWxhciBkaWZmZXJlbnRpYXRpb24gaW4gYmV0d2Vlbg0KbXVsdGlwbGUgZGF0YSBj aGFubmVscyBpbiBiZXR3ZWVuIHRoZSBzYW1lIGVuZC1wb2ludHMgcmF0aGVyIHRoYW4gZGlmZmVy ZW50aWF0aW9uIGJ5IG1lYW5zIG9mIGRpZmYgc2VydiBtYXJraW5nLg0KDQpXaGVuL2lmIG9uZSBn ZXQgYSBtb3JlIGNvbnNpc3RlbnQgYW5kIGZvcmNlZnVsIEVDTiBvcGVyYXRpb24gaW4gQVFNcyBh bmQgU0NUUCBlbmQtcG9pbnRzLCBwZXJoYXBzIHRoZSBjb3VwbGluZyBjb25nZXN0aW9uDQpwcmlu Y2lwbGVzIGFjaGlldmVkIGJ5IG1lYW5zIG9mIHNjdHAgc3RyZWFtIHNjaGVkdWxpbmcgZ2V0IHRv IGJlIGxlc3MgaW1wb3J0YW50Lg0KT24gdGhlIG90aGVyIGhhbmQsIGFnYWluIGFzIHNhaWQgYmVm b3JlLCBoYXZpbmcgdGhlIG9uZSBhbmQgdGhlIHNhbWUsIG9yIG11bHRpcGxlLCBmbG93IGNvbnRy b2wgKHJlY2VpdmVyIGJ1ZmZlcikgY29udGV4dHMgbWF5IGJlDQphIHN0cmVuZ3RoIChzaW1wbGlj aXR5KSBvciBhIHdlYWtuZXNzLg0KDQpCUiwgS2FyZW4NCg0KRnJvbTogUnVlZGlnZXIuR2VpYkB0 ZWxla29tLmRlPG1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGU+IFttYWlsdG86UnVlZGln ZXIuR2VpYkB0ZWxla29tLmRlPG1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGU+XQ0KU2Vu dDogRnJpZGF5LCBKdWx5IDI0LCAyMDE1IDEwOjAwIEFNDQpUbzoga2FyZW4ubmllbHNlbkB0aWV0 by5jb208bWFpbHRvOmthcmVuLm5pZWxzZW5AdGlldG8uY29tPg0KQ2M6IHJ0Y3dlYkBpZXRmLm9y ZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgdHN2d2dAaWV0Zi5vcmc8bWFpbHRvOnRzdndnQGll dGYub3JnPg0KU3ViamVjdDogQVc6IFt0c3Z3Z10gZGlmZnNlcnYgbWFya2luZyBmb3IgcnRjd2Ig ZGF0YSBjaGFubmVsDQoNCkthcmVuLA0KDQogICAgICBGaW5hbGx5IHRoZXJlIHdhcyBhIGNvbW1l bnQgYXQgdGhlIHRzdndnIG1lZXRpbmcgdGhhdCB0aGUgc2FtZSA1LXR1cGxlIHdpdGgNCiAgICAg ICBkaWZmZXJlbnQgZGlmZnNlcnYgbWFya2luZ3Mgd291bGQgbm90IGdldCB0aHJvdWdoIHRoZSBu ZXR3b3JrIOKAkyBpZiB0aGF0IGdlbmVyYWxseQ0KICAgICAgIGlzIGNvcnJlY3QsICB0aGVuIHRo ZSBzb2x1dGlvbiBpcyB2ZXJ5IGVhc3k6IG9uZSBNVVNUIHVzZSBkaWZmZXJlbnQgYXNzb2NpYXRp b25zIHRvDQogICAgICAgZ2V0IHBvcnQgKDUtdHVwbGUpIGRpZmZlcmVudGlhdGlvbi4NCiAgICAg ICBJIHRoaW5rIHRoYXQgaWYgdGhpcyBpcyBjb3JyZWN0LCBvbmUgYWxzbyB3YW50cyB0byBhc2sg d2hhdCBoYXBwZW5zIGlmIHRoZSBkaWZmc2VydiBpcw0KICAgICAgIGNoYW5nZWQgZm9yIHRoZSBz YW1lIDUtdHVwbGUg4oCTIGkuZS4sIGlzIHRoZSBuZXR3b3JrIHJvYnVzdCB0byB0aGlzIGNoYW5n ZSBldmVuIGlmDQogICAgICAgaXQgaXMgbm90IHJvYnVzdCB0byBjb25jdXJyZW50IHVzYWdlIG9m IGRpZmZlcmVudCBtYXJraW5ncyBmb3IgdGhlIHNhbWUgNS10dXBsZS4NCg0KVGFsa2luZyBhYm91 dCB0aGUgcG9saWNpZXMgb2YgdGhlIGNvbXBhbnkgSSB3b3JrIGZvciBvbmx5Og0KDQpQb3NzaWJp bGl0aWVzIHRvIGVuZm9yY2UgUW9TIHBvbGljaWVzIGF0IGEgcHJvdmlkZXIgQlJBUyBvciBCTkcg dGVybWluYXRpbmcgd2lyZWQNCmNvbnN1bWVyIGFjY2Vzc2VzIGFyZSBsaW1pdGVkLiBRb1MgcG9s aWNpZXMgYmFzZWQgb24gZnVsbCA1IHR1cGxlIGFyZSB2ZXJ5DQpjb25zZXJ2YXRpdmUgYW5kIGhh cmQgdG8gbWFpbnRhaW4uIEkgd291bGRu4oCZdCBleHBlY3QgZnVsbCA1IHR1cGxlIGFzIGJhc2lz IGZvciBhIFFvUw0KcG9saWN5IHRoZW4uIFRydXN0IGluIHRoZSBjb3JyZWN0IGluZm9ybWF0aW9u IG9uIHdoaWNoIGEgQlJBUy9CTkcgY2FuDQpiYXNlIFFvUyBjbGFzc2lmaWNhdGlvbiBpcyBhbiBp bXBvcnRhbnQgaXNzdWUuIEluIGFueSBjYXNlLCBJ4oCZZCBub3QgZXhwZWN0DQptb3JlIHRoYW4g b25lIERTQ1AgaXMgYXNzaWduZWQgYmFzZWQgb24gc3VjaCBhIHBvbGljeSBmb3IgdGhlIHRpbWUN CmJlaW5nLiBJ4oCZbSBub3QgYXdhcmUgb2YgYW55IGFjdHVhbCByZXF1aXJlbWVudCB0byBzdXBw b3J0IGUuZy4gYW4gQUZuDQpjbGFzcyBieSBhbGwgdGhyZWUgUEhCcy4NCg0KQXQgaW50ZXJjb25u ZWN0aW9uIHBvaW50cywgYW55IHVuZXhwZWN0ZWQgRFNDUCBpcyBibGVhY2hlZC4gVGhpcyBtdXN0 DQpiZSBkb25lIHRvIHByb3RlY3QgYmFja2JvbmUgUW9TIHByb2R1Y3Rpb24uIFFvUyB0cmFuc3Bv cnQgY2FuIGJlDQpuZWdvdGlhdGVkIGZvciBhIHNldCBvZiBkZWZpbmVkIERTQ1BzLg0KDQpBIHN0 dWR5IG9mIHRoZSBFVSBmb3VuZCBEUEkgdG8gYmUgbW9yZSBjb21tb24gaW4gd2lyZWxlc3MgY29t bXVuaWNhdGlvbiB0aGFuIGluIHdpcmVkIGNvbW11bmljYXRpb24uIEnigJlkIG5vdCBleHBlY3Qg dGhlIFFvUyBwb2xpY2llcyBpbiB0aGF0IGFyZWEgdG8gYmUgbW9yZSBsaWJlcmFsIHRoYW4gZm9y IGZpeGVkIGFjY2VzcyBuZXR3b3JrcyBmb3IgdGhlIHRpbWUgYmVpbmcuDQoNClJlZ2FyZHMsDQoN ClJ1ZWRpZ2VyDQoNCg0KDQoNCg== --_000_CA7A7C64CC4ADB458B74477EA99DF6F5052967457EHE111643EMEA1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJTcHJlY2hibGFzZW50ZXh0IFpjaG4iOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBo LCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2lu LXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJn aW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkUtTWFpbEZv cm1hdHZvcmxhZ2UxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FLU1haWxG b3JtYXR2b3JsYWdlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRS1NYWlsRm9y bWF0dm9ybGFnZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlNwcmVjaGJsYXNl bnRleHRaY2huDQoJe21zby1zdHlsZS1uYW1lOiJTcHJlY2hibGFzZW50ZXh0IFpjaG4iOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazpTcHJlY2hibGFzZW50ZXh0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZv cmxhZ2UyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjMuMGNtIDIu MGNtIDMuMGNtIDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPjwvaGVhZD48Ym9keSBsYW5nPURFIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFz cz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz5IaSBLYXJlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlFv U8KgIG5lZWRzIHRvIGJlIGNvbW1lcmNpYWxseSBuZWdvdGlhdGVkIGF0IGludGVyY29ubmVjdGlv bi4gSWYgUW9TIHNob3VsZCBiZSBhdmFpbGFibGUgYXQgYSBjb25zdW1lciBhY2Nlc3MsIHRoZSBj b25zdW1lciBkaXZpc2lvbiBvZiBhIGNvbXBhbnkgbXVzdCBiZSBpbnZvbHZlZCBpbiBhZGRpdGlv biBhcyB3ZWxsIGFzIHRoZSB0ZWNobmljYWwgc3RhZmYgc2V0dGluZyB1cCBhbmQgbWFpbnRhaW5p bmcgdGVjaG5pY2FsIGNvbmZpZ3VyYXRpb25zLiAxMSBQSEJzIGZvciBhIHNpbmdsZSBjb25zdW1l ciBzZXJ2aWNlIGFyZSBhIGNoYWxsZW5naW5nIHJlcXVpcmVtZW50LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5BbGwgRFNDUHMsIHdoaWNoIGhhdmUg bm90IGJlZW4gbmVnb3RpYXRlZCBiZXR3ZWVuIGFjY2VzcyBhbmQgaW50ZXJjb25uZWN0aW9uIGFy ZSBwb3NzaWJseSBibGVhY2hlZCwgZXNwZWNpYWxseSBpZiBhIG5ldHdvcmsgcHJvdmlkZXIgb3Bl cmF0ZXMgUW9TIHdpdGhpbiB0aGUgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+UW9TIHRvIG1lIG1lYW5zIG92ZXJwcm92aXNpb25pbmcg dG8gZW5zdXJlIHRyYW5zcG9ydCBmcmVlIG9mIGNvbmdlc3Rpb24uIElmIEkgc2VlIDExIFBIQnMg Zm9yIGEgc2luZ2xlIGZsb3csIEnigJltIG5vdCBzdXJlIGlmIHRoaXMgYXNzdW1lcyBtb3JlIHRo YW4gQ29TIChkcm9wIG1lIGxhc3QpLiBJ4oCZZCBsaWtlIHRvIHJlYWQgYSBsaXR0bGUgbW9yZSBh Ym91dCBob3cgV0VCcnRjIGZpZ3VyZXMgb3V0IHdoaWNoIFFvUyByZXNvdXJjZXMgYXJlIGNvbmZp Z3VyZWQgYW5kIHdoaWNoIG9mIHRoZXNlIGFyZSBhdmFpbGFibGUgZm9yIHN1Y2ggYSBmbG93IGF0 IGFuIGFjY2VzcyB3aGVuIHJlcXVpcmVkLiBIb3cgYW5kIHdoZXJlIGFyZSB0aGUgcmVzb3VyY2Vz IGNvbnN1bWVkIGJ5IGVhY2ggV0VScnRjIFBIQiBjb250cm9sbGVkIGFuZCBob3cgYXJlIHRoZXNl IGFsaWduZWQgd2l0aCB0aGUgUW9TIHJlc291cmNlcyBjb25zdW1lZCBieSBvdGhlciBzZXJ2aWNl cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ UnVlZGlnZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPlZvbjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gS2FyZW4g RWxpc2FiZXRoIEVnZWRlIE5pZWxzZW4gW21haWx0bzprYXJlbi5uaWVsc2VuQHRpZXRvLmNvbV0g PGJyPjxiPkdlc2VuZGV0OjwvYj4gRnJlaXRhZywgMjQuIEp1bGkgMjAxNSAxMDoyODxicj48Yj5B bjo8L2I+IEdlaWIsIDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPlLDvGRpZ2VyPGJyPjxiPkNjOjwvYj4gcnRjd2Vi QGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9yZzsgTWljaGFlbCBUdWV4ZW47IGZsdWZmeUBpaWkuY2E8 YnI+PGI+QmV0cmVmZjo8L2I+IFJFOiBbdHN2d2ddIGRpZmZzZXJ2IG1hcmtpbmcgZm9yIHJ0Y3di IGRhdGEgY2hhbm5lbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkhpIFJ1ZWRpZ2VyLDwvc3Bhbj48c3BhbiBs YW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGFua3MgYSBsb3QuPC9zcGFuPjxzcGFuIGxh bmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1F Ti1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlNvIEkgdGhpbmsgdGhhdCB5b3XigJlyZSBzYXlp bmcgdGhhdCBldmVuIGlmIG9uZSBtYWRlIHN1cmUgdGhhdCBkaWZmZXJlbnQgZGlmZiBzZXJ2IG1h cmtpbmdzIHdlcmU8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PnNwbGl0IG9uIGRpZmZlcmVudCA1LXR1cGxlcywgdGhpcyBzZXR0aW5nIGxpa2VseSB3b3VsZCBi ZSBibGVhY2hlZCBhdCB0aGUgbmV0d29yay48L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29s b3I6IzFGNDk3RCc+SXMgdGhhdCBjb3JyZWN0bHkgdW5kZXJzdG9vZCA/PC9zcGFuPjxzcGFuIGxh bmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1F Ti1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPklmIHNvLCB0aGVuIChpdCBzb3VuZHMgdG8gbWUg 4oCTIG5vdCBrbm93aW5nIHRvbyBtdWNoIGFib3V0IHRoaXMpIHRoYXQgZnJvbSBhIGNvdXBsaW5n IGNvbmdlc3Rpb24gY29udHJvbCBwZXJzcGVjdGl2ZSBpdCA8L3NwYW4+PHNwYW4gbGFuZz1FTi1V Uz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPndvdWxkIGJlIHByZWZlcmFibGUgdG8mbmJzcDsgdXNl IFNDVFAgc2NoZWR1bGluZyBwcmlvcml0aXphdGlvbiAod2l0aGluIG9uZSBhbmQgdGhlIHNhbWUg YXNzb2NpYXRpb24pIGZvciBmaW5lIGdyYW51bGFyIGRpZmZlcmVudGlhdGlvbiBpbiBiZXR3ZWVu PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5tdWx0aXBsZSBk YXRhIGNoYW5uZWxzIGluIGJldHdlZW4gdGhlIHNhbWUgZW5kLXBvaW50cyByYXRoZXIgdGhhbiBk aWZmZXJlbnRpYXRpb24gYnkgbWVhbnMgb2YgZGlmZiBzZXJ2IG1hcmtpbmcuPC9zcGFuPjxzcGFu IGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPldoZW4vaWYgb25lIGdldCBhIG1vcmUgY29u c2lzdGVudCBhbmQgZm9yY2VmdWwgRUNOIG9wZXJhdGlvbiBpbiBBUU1zIGFuZCBTQ1RQIGVuZC1w b2ludHMsIHBlcmhhcHMgdGhlIGNvdXBsaW5nIGNvbmdlc3Rpb248L3NwYW4+PHNwYW4gbGFuZz1F Ti1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPnByaW5jaXBsZXMgYWNoaWV2ZWQgYnkgbWVhbnMg b2Ygc2N0cCBzdHJlYW0gc2NoZWR1bGluZyBnZXQgdG8gYmUgbGVzcyBpbXBvcnRhbnQuIDwvc3Bh bj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+T24gdGhlIG90aGVyIGhh bmQsIGFnYWluIGFzIHNhaWQgYmVmb3JlLCBoYXZpbmcgdGhlIG9uZSBhbmQgdGhlIHNhbWUsIG9y IG11bHRpcGxlLCBmbG93IGNvbnRyb2wgKHJlY2VpdmVyIGJ1ZmZlcikgY29udGV4dHMgbWF5IGJl PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5hIHN0cmVuZ3Ro IChzaW1wbGljaXR5KSBvciBhIHdlYWtuZXNzLiAmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+QlIsIEthcmVuIDwvc3Bhbj48c3BhbiBs YW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWls dG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlIj5SdWVkaWdlci5HZWliQHRlbGVrb20uZGU8L2E+ IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSI+UnVlZGln ZXIuR2VpYkB0ZWxla29tLmRlPC9hPl0gPGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMjQs IDIwMTUgMTA6MDAgQU08YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86a2FyZW4ubmllbHNl bkB0aWV0by5jb20iPmthcmVuLm5pZWxzZW5AdGlldG8uY29tPC9hPjxicj48Yj5DYzo8L2I+IDxh IGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT47IDxhIGhy ZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyI+dHN2d2dAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1Ympl Y3Q6PC9iPiBBVzogW3RzdndnXSBkaWZmc2VydiBtYXJraW5nIGZvciBydGN3YiBkYXRhIGNoYW5u ZWw8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xv cjojMUY0OTdEJz5LYXJlbiw8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1V Uz5GaW5hbGx5IHRoZXJlIHdhcyBhIGNvbW1lbnQgYXQgdGhlIHRzdndnIG1lZXRpbmcgdGhhdCB0 aGUgc2FtZSA1LXR1cGxlIHdpdGggPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz5kaWZm ZXJlbnQgZGlmZnNlcnYgbWFya2luZ3Mgd291bGQgbm90IGdldDxzcGFuIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz4gPC9zcGFuPnRocm91Z2ggdGhlIG5ldHdvcmsg4oCTIGlmIHRoYXQgZ2VuZXJhbGx5 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+aXMgY29ycmVjdCwgJm5ic3A7dGhlbiB0 aGUgc29sdXRpb24gaXMgdmVyeSBlYXN5OiBvbmUgTVVTVCB1c2UgZGlmZmVyZW50IGFzc29jaWF0 aW9ucyB0byA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPmdldCBwb3J0ICg1LXR1cGxl KSBkaWZmZXJlbnRpYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+SSB0aGluayB0aGF0 IGlmIHRoaXMgaXMgY29ycmVjdCwgb25lIGFsc28gd2FudHMgdG8gYXNrIHdoYXQgaGFwcGVucyBp ZiB0aGUgZGlmZnNlcnYgaXMgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz5jaGFuZ2Vk IGZvciB0aGUgc2FtZSA1LXR1cGxlIOKAkyBpLmUuLCBpcyB0aGUgbmV0d29yayByb2J1c3QgdG8g dGhpcyBjaGFuZ2UgZXZlbiBpZiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPml0IGlz IG5vdCByb2J1c3QgdG8gY29uY3VycmVudCB1c2FnZSBvZiBkaWZmZXJlbnQgbWFya2luZ3MgZm9y IHRoZSBzYW1lIDUtdHVwbGUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGFsa2luZyBh Ym91dCB0aGUgcG9saWNpZXMgb2YgdGhlIGNvbXBhbnkgSSB3b3JrIGZvciBvbmx5Ojwvc3Bhbj48 c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5Qb3NzaWJpbGl0aWVzIHRvIGVuZm9y Y2UgUW9TIHBvbGljaWVzIGF0IGEgcHJvdmlkZXIgQlJBUyBvcjwvc3Bhbj48c3BhbiBsYW5nPUVO LVVTPiZuYnNwOzxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5CTkcgdGVybWluYXRpbmcgd2ly ZWQgPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Y29uc3VtZXIgYWNjZXNzZXMgYXJlIGxp bWl0ZWQuIFFvUyBwb2xpY2llcyBiYXNlZCBvbiBmdWxsIDUgdHVwbGUgYXJlIHZlcnkgPC9zcGFu PjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5jb25zZXJ2YXRpdmUgYW5k IGhhcmQgdG8gbWFpbnRhaW4uIEkgd291bGRu4oCZdCBleHBlY3QgZnVsbCA1IHR1cGxlIGFzIGJh c2lzIGZvciBhIFFvUyA8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPnBvbGljeSB0aGVuLiBUcnVzdCBpbiB0aGUgY29ycmVjdCBpbmZvcm1hdGlvbiBvbiB3aGlj aCBhIEJSQVMvQk5HIGNhbiA8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPmJhc2UgUW9TIGNsYXNzaWZpY2F0aW9uIGlzIGFuIGltcG9ydGFudCBpc3N1ZS4gSW4g YW55IGNhc2UsIEnigJlkIG5vdCBleHBlY3QgPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdjb2xvcjojMUY0OTdEJz5tb3JlIHRoYW4gb25lIERTQ1AgaXMgYXNzaWduZWQgYmFzZWQgb24g c3VjaCBhIHBvbGljeSBmb3IgdGhlIHRpbWUgPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdjb2xvcjojMUY0OTdEJz5iZWluZy4gSeKAmW0gbm90IGF3YXJlIG9mIGFueSBhY3R1YWwgcmVx dWlyZW1lbnQgdG8gc3VwcG9ydCBlLmcuIGFuIEFGbiA8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPmNsYXNzIGJ5IGFsbCB0aHJlZSBQSEJzLjwvc3Bhbj48c3Bh biBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5BdCBpbnRlcmNvbm5lY3Rpb24gcG9pbnRz LCBhbnkgdW5leHBlY3RlZCBEU0NQIGlzIGJsZWFjaGVkLiBUaGlzIG11c3QgPC9zcGFuPjxzcGFu IGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5iZSBkb25lIHRvIHByb3RlY3QgYmFj a2JvbmUgUW9TIHByb2R1Y3Rpb24uIFFvUyB0cmFuc3BvcnQgY2FuIGJlIDwvc3Bhbj48c3BhbiBs YW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+bmVnb3RpYXRlZCBmb3IgYSBzZXQgb2Yg ZGVmaW5lZCBEU0NQcy4gPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PkEgc3R1ZHkgb2YgdGhlIEVVIGZvdW5kIERQSSB0byBiZSBtb3JlIGNvbW1vbiBpbiB3aXJlbGVz cyBjb21tdW5pY2F0aW9uIHRoYW4gaW4gd2lyZWQgY29tbXVuaWNhdGlvbi4gSeKAmWQgbm90IGV4 cGVjdCB0aGUgUW9TIHBvbGljaWVzIGluIHRoYXQgYXJlYSB0byBiZSBtb3JlIGxpYmVyYWwgdGhh biBmb3IgZml4ZWQgYWNjZXNzIG5ldHdvcmtzIGZvciB0aGUgdGltZSBiZWluZy48L3NwYW4+PHNw YW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFu Zz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVO LVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+UnVlZGlnZXI8L3NwYW4+PHNwYW4gbGFuZz1FTi1V Uz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTgu MHB0Jz48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_CA7A7C64CC4ADB458B74477EA99DF6F5052967457EHE111643EMEA1_-- From nobody Fri Jul 24 03:12:36 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE36A1A6FFD for ; Fri, 24 Jul 2015 03:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cveOG5ByRLq for ; Fri, 24 Jul 2015 03:12:34 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5D91A219B for ; Fri, 24 Jul 2015 03:12:34 -0700 (PDT) Received: by ietj16 with SMTP id j16so14965012iet.0 for ; Fri, 24 Jul 2015 03:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=jkYHekiqWVGqgq6l49zVjugBCiHpW7Wod7dxGukOEAU=; b=hfRLCRRbW17bDiRrWx7tNknpuyJrTyAdQUBIDQZnJ09EiWp5lzqfUTykmtpnWK1acj sAvojdJod068GzN9E2s0qgwXI3B8o6KjZ3tgKTt/7RSl0V7NnPqsN64jBYr7+C5wvgWi lAqJyNrplDNDebL5A7+/FESAXIGWv8cPjZukX3SjMpH+eOgmvnq77cFenuWW2KJgCa+Z tuX/mpxGfImJ4Pv01Adu85PwzsOEwF+hFkxvRSdWiFF5Wtuc8ltnBorX10PINc2my4ag 8YYVPg2bjjZg0z90IL5QG3vL57OhOkIBul23cnHt0jAYaxtHEuOwYlaBv5ZplhxwoKwF 0Jng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=jkYHekiqWVGqgq6l49zVjugBCiHpW7Wod7dxGukOEAU=; b=MT4bk+qtF5O0q141CxuzX4fet3CD1DBwqKyCrNKZyc3jSDVIVz2d/JNi7vWD87nlNa fZET8Hvk2CDeSQdpuSYrJlJwZTGHBRiyWYWlUh4NcH4+YBZzJtMz8ZeVU4pVDeUKrSva 8v+YoM4ZVrHco0XGO8o4gRlq5nks+TKYOABprRFWaNzfJ/TuPUBmTNq0s//haHynR/ME p5TdvTzUEp4fOvcGcYqXqtgMR52h7qYwX/aIfFJvrgI30W1QdHAVRqctMOK/3NpS6gdJ CS3HIODY3Gl+qx4gZKFW2qqtj8Cd522O3SsGTMQ0LEnRaSj7Ix0O78b4q+j90Rwk2kGW AsxQ== X-Gm-Message-State: ALoCoQnaTjQzHB60JeWeAC6ot0MdaGar9NoEfn7/1h2AcxCmj1KTmVzbxYBHUgEDxKlodXwuol8U X-Received: by 10.50.20.135 with SMTP id n7mr4735316ige.58.1437732754089; Fri, 24 Jul 2015 03:12:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.136.14 with HTTP; Fri, 24 Jul 2015 03:11:54 -0700 (PDT) From: Peter Thatcher Date: Fri, 24 Jul 2015 03:11:54 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7bd76692172299051b9c3ed6 Archived-At: Subject: [rtcweb] Comments on draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:12:35 -0000 --047d7bd76692172299051b9c3ed6 Content-Type: text/plain; charset=UTF-8 In the WG meeting today, we were asked to read draft-nandakumar-rtcweb-sdp. So I read it. Here are my comments: 1. The annotated examples with ASCII art tables are really nice. I like that part. Detailed, readable, and thorough. 2. The diagrams with offer/answer diagrams imply certain models of signalling which might not be in use by WebRTC applications. I think instead they should be modeled as calls to createOffer, createAnswer, setLocalDescription and setRemoteDescription. There are applications already that basically build custom SDP with JS to use it as an API and doesn't send the SDP over the signalling. Developers doing such things would find examples of SDP useful, but the diagrams which assume signalling wouldn't fit. In other words, instead of this document being "Examples of SDP that is signalled", I think it should be "Examples of SDP that can be put into setLocalDescription and setRemoteDescription, and returned by createOffer and createAnswer". I think Harald said something similar in the WG meeting. --047d7bd76692172299051b9c3ed6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the WG meeting today, we were asked to read=C2=A0dra= ft-nandakumar-rtcweb-sdp.=C2=A0 So I read it.=C2=A0 Here are my comments:

1.=C2=A0 The annotated examples with ASCII art tables a= re really nice.=C2=A0 I like that part.=C2=A0 Detailed, readable, and thoro= ugh.=C2=A0

2.=C2=A0 The diagrams with offer/answer dia= grams imply certain models of signalling which might not be in use by WebRT= C applications.=C2=A0 I think instead they should be modeled as calls to cr= eateOffer, createAnswer, setLocalDescription and setRemoteDescription.=C2= =A0 There are applications already that basically build custom SDP with JS = to use it as an API and doesn't send the SDP over the signalling. =C2= =A0 Developers doing such things would find examples of SDP useful, but the= diagrams which assume signalling wouldn't fit. =C2=A0

In other words, instead of this document being "Examples of SDP = that is signalled", I think it should be "Examples of SDP that ca= n be put into setLocalDescription and setRemoteDescription, and returned by= createOffer and createAnswer".

I think Harald sa= id something similar in the WG meeting.
--047d7bd76692172299051b9c3ed6-- From nobody Fri Jul 24 03:13:49 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5971A8884 for ; Fri, 24 Jul 2015 03:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwHOlneBiR5q for ; Fri, 24 Jul 2015 03:13:46 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7425F1A6FFD for ; Fri, 24 Jul 2015 03:13:46 -0700 (PDT) Received: by ykay190 with SMTP id y190so15818914yka.3 for ; Fri, 24 Jul 2015 03:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hcr3IbkW75s1PEs8rBXuGM+fQz8YDG0L46OXau0nKII=; b=cYLw6nQTbQoc7u1OPR6gGOVievZ3qeFCg7WZzR5ElyWRar0BM013ySbnatMQBTMAJX l9FGu4V3BNexXGbKspHjKAbhawu7y6hyYl9xwb1ci1ETBDKCT/O6rchyEkKb3zPlHGmv 0MuibvtDfPyO8am+kUYiK3y5H10BQk+NQhCLvKWfhQ4a6j+PQXurQhCJGuUl1XpTF7LW Dp+/bTNRGr3Q1nbpkWyrF8mooeeiz0MvJrrbVBT2p63AbN5oac213jj4blSdvS0hoNHN ZLaXRVI4YpXX6OylqyZGKsRK+Rz5ofxDIFJlNuLDmDkgx3aB2zQ4IuhDcbYjL+tNlNMg wMRA== MIME-Version: 1.0 X-Received: by 10.129.97.87 with SMTP id v84mr14176429ywb.56.1437732825918; Fri, 24 Jul 2015 03:13:45 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 24 Jul 2015 03:13:45 -0700 (PDT) In-Reply-To: References: <55B1624D.4050908@jesup.org> Date: Fri, 24 Jul 2015 12:13:45 +0200 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Randell Jesup , Cullen Jennings , "rtcweb@ietf.org" , Eric Rescorla Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:13:47 -0000 On 24 July 2015 at 11:50, Justin Uberti wrote: > track = new MediaStreamTrack(); > track.kind = "audio"; > addTrack(track) I would like to keep track.kind readonly. From nobody Fri Jul 24 03:15:54 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757A01A6FFD for ; Fri, 24 Jul 2015 03:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03N6A7D4n3-U for ; Fri, 24 Jul 2015 03:15:52 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056FE1A1B8A for ; Fri, 24 Jul 2015 03:15:51 -0700 (PDT) Received: by ietj16 with SMTP id j16so15020323iet.0 for ; Fri, 24 Jul 2015 03:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PpV8MNhrIbKBfiH/b1K2eQJsQ8OxYmColguT7XePRwQ=; b=fRW0QPyslRKsHQJDe0We7GbNevfmYnkUj2yJm6EWwEwOwds23SSz6bwfPgmtsP+67r RFe6YzJ96bmcV7Artl9gG4noKpb5/D4VecMQqunJUzXu3Env3mFPQd0dImkh0TmH2ced /+b5h8ajMjI02MUpa4ePocxZX0g5Sz4/3RHuyiE4Z5+NvmtQEHRqwQH4DQgm9vTdS3SN GgQctY9coFkpzG95aeAS01lk1mXGMaS81xrWs8kTyL1FbOygMhXlgP4N/o+JMDFaqabh UMPOcQipmrXTb60bH2a7qmXD211ob56fsnxhPExAxYo7PtqTtW04sc9xF/IfMje39cW8 b7LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PpV8MNhrIbKBfiH/b1K2eQJsQ8OxYmColguT7XePRwQ=; b=LsGacbWJjz6ZildVKxd/GsACv4Ps0+24heI9zep/hjGCG5jpCTlPOVCmRgur97dxwy +cQRQ4uc3X1lRGDpDcglbxA7ILXUNs/u+TU0DB6ap1Rd6m/zZvAzHISHxyTYnxP5QqNc XBq8RLS5Q/1PaiTZW8AgNRGl44YdPCBKUtkgbzqFwePvNPO3ZUDv7etFTHAu6+XViFAX VG7CIYzRD9O/s3kRrQkIbx3gJc+EpRSPA2V8OczIcmgKbBfalT0aR0UqMtzLu7zymaZH qPrnhHpxid2v3+qSLsqGplunDYjbOGIuqj1vIqW2JfjdkhOpVdFcr5FGGLNXvdibQJJS qfMg== X-Gm-Message-State: ALoCoQk53i+6zfbsGdXI+MGc4Z8qLcOQibXH09btRT9ItU8dp/kxVW56D1KhjOqEcVCPE5eFg5HQ X-Received: by 10.107.169.213 with SMTP id f82mr20699808ioj.42.1437732951305; Fri, 24 Jul 2015 03:15:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.136.14 with HTTP; Fri, 24 Jul 2015 03:15:11 -0700 (PDT) In-Reply-To: References: <55B1624D.4050908@jesup.org> From: Peter Thatcher Date: Fri, 24 Jul 2015 03:15:11 -0700 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=001a114266aad8697b051b9c4947 Archived-At: Cc: Randell Jesup , Cullen Jennings , "rtcweb@ietf.org" , Eric Rescorla Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:15:53 -0000 --001a114266aad8697b051b9c4947 Content-Type: text/plain; charset=UTF-8 I prefer a blank RtpSender over a blank Track, and thus prefer createRtpSender("audio"), but I could live with "new MediaStreamTrack('audio')". I wouldn't want the second one where you set the kind because there's a time period in which you have a track with no kind, which is strange, even for a fake one. On Fri, Jul 24, 2015 at 2:50 AM, Justin Uberti wrote: > How about: > > track = new MediaStreamTrack("audio") > addTrack(track) > > or > > track = new MediaStreamTrack(); > track.kind = "audio"; > addTrack(track) > > On Fri, Jul 24, 2015 at 11:00 AM, Eric Rescorla wrote: > >> >> On Fri, Jul 24, 2015 at 10:57 AM, Peter Thatcher >> wrote: >> >>> Would you be comfortable with either addTrack("audio") >>> >> >> This seems awful. >> >> >> >>> or createRtpSender("audio")? >>> >> >> This seems OKish >> >> -Ekr >> >> >>> On Fri, Jul 24, 2015 at 12:50 AM, Martin Thomson < >>> martin.thomson@gmail.com> wrote: >>> >>>> On 24 July 2015 at 00:31, Peter Thatcher wrote: >>>> > PeerConnection.addTrack(null) >>>> >>>> I'm not entirely comfortable with the notion that we allow null >>>> arguments. Doing that could be a footgun. Especially since it is >>>> only to support what I consider to be a corner case (even though it >>>> might be an important one). >>>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > --001a114266aad8697b051b9c4947 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I prefer a blank RtpSender over a blank Track, and thus= prefer createRtpSender("audio"), but I could live with "new= MediaStreamTrack('audio')".=C2=A0 I wouldn't want the sec= ond one where you set the kind because there's a time period in which y= ou have a track with no kind, which is strange, even for a fake one.
<= /div>

On Fri, Jul = 24, 2015 at 2:50 AM, Justin Uberti <juberti@google.com> wro= te:
How about:

<= /div>
track =3D new MediaStreamTrack("audio")
addTr= ack(track)

or=C2=A0

track= =3D new MediaStreamTrack();
track.kind =3D "audio";
addTrack(track)

On Fri, Jul 2= 4, 2015 at 11:00 AM, Eric Rescorla <ekr@rtfm.com> wrote:

<= div class=3D"gmail_quote">On Fri, Jul 24, 2015 at 10:57 AM, Peter Tha= tcher <pthatcher@google.com> wrote:
Would you be comfortable with either addTrack("audio")<= /div>

This seems awful.
<= div>
=C2=A0
or createRtpSend= er("audio")?

This see= ms OKish

-Ekr
=C2=A0
On Fri, Jul 24, 2015 at 12:50 AM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 24 July 2015 at 00:31, Peter Thatcher <pthatcher@google.com> wrote:
> PeerConnection.addTrack(null)

I'm not entirely comfortable with the notion that we allow null<= br> arguments.=C2=A0 Doing that could be a footgun.=C2=A0 Especially since it i= s
only to support what I consider to be a corner case (even though it
might be an important one).


_______________________________________________
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



--001a114266aad8697b051b9c4947-- From nobody Fri Jul 24 03:29:31 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2936E1A8A5A for ; Fri, 24 Jul 2015 03:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JV4yyj_FM8f for ; Fri, 24 Jul 2015 03:29:28 -0700 (PDT) Received: from ftx-008-i771.relay.mailchannels.net (ftx-008-i771.relay.mailchannels.net [50.61.143.71]) by ietfa.amsl.com (Postfix) with ESMTP id B001B1A8988 for ; Fri, 24 Jul 2015 03:29:25 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id B96F160C51; Fri, 24 Jul 2015 10:29:22 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Fri, 24 Jul 2015 10:29:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1437733763194:3272345792 X-MC-Ingress-Time: 1437733763194 Received: from pool-108-36-235-74.phlapa.fios.verizon.net ([108.36.235.74]:62420 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZIaEC-0002ns-KT; Fri, 24 Jul 2015 05:29:20 -0500 Message-ID: <55B2138B.8070806@jesup.org> Date: Fri, 24 Jul 2015 06:29:31 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Peter Thatcher , Justin Uberti References: <55B1624D.4050908@jesup.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040001040800040407070308" X-AuthUser: randell@jesup.org Archived-At: Cc: Randell Jesup , Cullen Jennings , "rtcweb@ietf.org" , Eric Rescorla Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:29:29 -0000 This is a multi-part message in MIME format. --------------040001040800040407070308 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 7/24/2015 6:15 AM, Peter Thatcher wrote: > I prefer a blank RtpSender over a blank Track, and thus prefer > createRtpSender("audio"), but I could live with "new > MediaStreamTrack('audio')". I wouldn't want the second one where you > set the kind because there's a time period in which you have a track > with no kind, which is strange, even for a fake one. If you have new MediaStreamTrack("audio"), you need to define what this means for *other* sinks/etc for MediaStreamTracks... media elements, webaudio, combined in MediaStream constructors, etc... which is an argument for createRtpSender("audio"). Note that from JS's point of view, track = new MediaStreamTrack(); track.kind = "audio" is all in the same 'run' between stable states, so it's not really supposed to be "observable". However, what if the JS doesn't do that... you can have a track that's neither audio nor video... > > On Fri, Jul 24, 2015 at 2:50 AM, Justin Uberti > wrote: > > How about: > > track = new MediaStreamTrack("audio") > addTrack(track) > > or > > track = new MediaStreamTrack(); > track.kind = "audio"; > addTrack(track) > > On Fri, Jul 24, 2015 at 11:00 AM, Eric Rescorla > wrote: > > > On Fri, Jul 24, 2015 at 10:57 AM, Peter Thatcher > > wrote: > > Would you be comfortable with either addTrack("audio") > > > This seems awful. > > or createRtpSender("audio")? > > > This seems OKish > > -Ekr > -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much spam --------------040001040800040407070308 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 7/24/2015 6:15 AM, Peter Thatcher wrote:
I prefer a blank RtpSender over a blank Track, and thus prefer createRtpSender("audio"), but I could live with "new MediaStreamTrack('audio')".=A0 I wouldn't want the second one where you set the kind because there's a time period in which you have a track with no kind, which is strange, even for a fake one.

If you have new MediaStreamTrack("audio"), you need to define what this means for *other* sinks/etc for MediaStreamTracks...=A0 media elements, webaudio, combined in MediaStream constructors, etc... which is an argument for createRtpSender("audio").

Note that from JS's point of view, track =3D new MediaStreamTrack(); track.kind =3D "audio" is all in the same 'run' between stable states= , so it's not really supposed to be "observable".=A0 However, what if the JS doesn't do that... you can have a track that's neither audio nor video...


On Fri, Jul 24, 2015 at 2:50 AM, Justi= n Uberti <jubert= i@google.com> wrote:
How about:

track =3D new MediaStreamTrack("audio")
addTrack(track)

or=A0

track =3D new MediaStreamTrack();
track.kind =3D "audio";
addTrack(track)

On Fri, Jul 24, 2015 at 11:0= 0 AM, Eric Rescorla <ek= r@rtfm.com> wrote:

--=20
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too=
 much spam
--------------040001040800040407070308-- From nobody Fri Jul 24 03:31:29 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A354D1A1F04 for ; Mon, 20 Jul 2015 04:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLtgkeXkkZCB for ; Mon, 20 Jul 2015 04:37:22 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ADF51A1B78 for ; Mon, 20 Jul 2015 04:37:21 -0700 (PDT) Received: (qmail 83426 invoked from network); 20 Jul 2015 11:37:19 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 6327 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 20 Jul 2015 11:37:19 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 7660018A1284; Mon, 20 Jul 2015 12:37:16 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 5B9DC18A119C; Mon, 20 Jul 2015 12:37:16 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E1137B76-A6CB-4289-9321-42DF1A31DD08" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Panton In-Reply-To: Date: Mon, 20 Jul 2015 12:37:15 +0100 Message-Id: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.2102) Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 03:31:24 -0700 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:37:26 -0000 --Apple-Mail=_E1137B76-A6CB-4289-9321-42DF1A31DD08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Jul 2015, at 00:41, Martin Thomson > wrote: >=20 >=20 > On Jul 17, 2015 4:35 PM, "I=C3=B1aki Baz Castillo" > wrote: > > What I understand is that the browser should bind on 0.0.0.0 (or = ::0) > > and send the STUN/TURN request, >=20 > That works most of the time, but it is a cheat. What Chrome and = Firefox do - bind to reach local interface separately - is the only = reliable way to do this. If you bind to 0.0.0.0, you can't handle = multiple interfaces correctly, and that reduces the odds of completing = ICE with the best result. >=20 >=20 Gulp. Whilst I mostly see the logic - it is wholly unexpected behaviour = to the average sys admin.=20 Certainly not what I expected. It strikes me that binding to all interfaces might well give a vector = for attackers to map out a company=E2=80=99s internal networks. It also may restrict the user=E2=80=99s ability to manipulate which = medium is used.=20 E.g. I=E2=80=99m at home and my chromebook pixel (or firefox tablet) is = on wifi, but I=E2=80=99ve left LTE enabled. I (or the OS) is configured to prefer wifi wen available - but it = happens that for a specific peer LTE completes first. So now my video call goes over LTE without my say-so and with no hint = this is happening - costing me real money. My only option is to completely disable LTE when I get home (and = lose SMS too) ? Perhaps we should default to binding to 0.0.0.0 and allow a user = config=E2=80=99d preference for more exhaustive searching. Tim. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_E1137B76-A6CB-4289-9321-42DF1A31DD08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 18 Jul 2015, at 00:41, Martin Thomson = <martin.thomson@gmail.com> wrote:


On Jul 17, 2015 4:35 PM, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote:
> What I understand is that the browser should bind on 0.0.0.0 (or = ::0)
> and send the STUN/TURN request,

That = works most of the time, but it is a cheat. What Chrome and Firefox do - = bind to reach local interface separately - is the only reliable way to = do this. If you bind to 0.0.0.0, you can't handle multiple interfaces = correctly, and that reduces the odds of completing ICE with the best = result.



Gulp. Whilst I mostly see the logic - it = is wholly unexpected behaviour to the average sys admin. 
Certainly not what I expected.

It strikes me that binding to all = interfaces might well give a vector for attackers to map out a = company=E2=80=99s internal networks.
It also may = restrict the user=E2=80=99s ability to manipulate which medium is = used. 

E.g.= I=E2=80=99m at home and my chromebook pixel (or firefox tablet) is on = wifi, but I=E2=80=99ve left LTE enabled.
I (or the = OS) is configured to prefer wifi wen available - but it happens that for = a specific peer LTE completes first.
So now my = video call goes over LTE without my say-so and with no hint this is = happening  - costing me real
money. My only = option is to completely disable LTE when I get home  (and lose SMS = too) ?

Perhaps = we should default to binding to 0.0.0.0 and allow a user config=E2=80=99d = preference for more exhaustive searching.

Tim.

_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

Tim Panton - = Web/VoIP consultant and implementor
www.westhawk.co.uk



= --Apple-Mail=_E1137B76-A6CB-4289-9321-42DF1A31DD08-- From nobody Fri Jul 24 03:31:30 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F27B1A6F7A for ; Mon, 20 Jul 2015 04:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqhXxl4VvYmL for ; Mon, 20 Jul 2015 04:54:03 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AA91A6EDC for ; Mon, 20 Jul 2015 04:54:03 -0700 (PDT) Received: (qmail 99061 invoked from network); 20 Jul 2015 11:54:01 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 6980 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 20 Jul 2015 11:54:01 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id C8D4318A22A3; Mon, 20 Jul 2015 12:53:59 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B215718A22A2; Mon, 20 Jul 2015 12:53:59 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4FABBCD0-4254-42BB-BB84-DBFEC1E4DAA7" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Panton In-Reply-To: <20150716084225.GA29652@lo.psyced.org> Date: Mon, 20 Jul 2015 12:53:59 +0100 Message-Id: References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> To: carlo von lynX X-Mailer: Apple Mail (2.2102) Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 03:31:24 -0700 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:54:09 -0000 --Apple-Mail=_4FABBCD0-4254-42BB-BB84-DBFEC1E4DAA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Jul 2015, at 09:42, carlo von lynX = wrote: >=20 > Yes, I dare to speak out of my 25 years of experience on the > Internet even if I didn't have to use much VPN ever. I can > imagine plenty of constellations where the VPN is NOT supposed > to take over all communications on the system but rather offer > a side route into a company's servers or suchlike. Therefore > I worry if the software provider can always come up with a > configuration that still does what the customers expect and > at the same time deals with the new backdoor introduced by WebRTC. > Of course anyone with better understanding can help clear up > these worries. >=20 >> That isn=E2=80=99t what I meant. I expect secure software providers = to keep their >> software abreast of new developments.=20 It turns out that I was completely wrong. The browsers are currently so=20= thorough in their discovery of available interfaces and routes that no amount of changes by the sys admin or VPN supplier will fix this = problem. Sorry about that.=20 >=20 > Uh, not sure if that is an established pattern in the industry. > Usually somebody does whatever fits into their business model > best, then there is a public outcry and possibly some bloodspill, > then all the players look at how they can make a good impression > by reducing the collateral damages.. but if that doesn't work out > cheap and easy.. tant pis. Let's continue with business. >=20 >> I happen to have the (no doubt under informed) opinion that >> this isn=E2=80=99t as simple as it has been made out to be. At least I was right here. - It is even more complex than I believed. >=20 > Well, in case of doubt it is important to pick the conservative > option until the issue is properly analyzed rather than hoping > for the general public to forget about the problem. >=20 >>> Also the "solution" you suggest AFAIU does not work for people >>> who use Tor in a non-NATted environment, for example on a >>> fixed system in a university library with a static IP address. >>=20 >> That is an interesting case. In that instance hiding the local IP = would be=20 >> valuable. I thought however those users would normally run a TOR os = off=20 >> a usb stick in a VM. That would probably mask the local IP. >=20 > Now that this is more clear, have another look at my original mail > that describes how such a dissident would use any Windows OS system > standing around. I doubt anything advanced like TAILS sticks are > out there as merely possessing one could be life-threatening. Here too I find that I was wrong and the current situation not what I = assumed and is unsatisfactory. Most SOCKS proxies don't have support for ICE/STUN nor arbitrary UDP. The current browser implementations (backed by the ICE spec) take the = view that if SOCKS doesn=E2=80=99t do UDP, then they should go directly and send = UDP anyhow. I=E2=80=99m not clear that this is what a user might expect.=20 An alternative might be to detect a proxy config _only_ offer TURN over = TLS=20 candidates (and route the traffic over the proxy) - This would result in poor audio/video but would be more in keeping with the spirit of the = proxy config. (a variant might be to inspect the proxy in detail and use the address = whitelists to filter allowed traffic somehow?)=20 >>=20 >> I totally agree. My solution is imho a better fix, since it >> also protects against many other apps that might get started from >> a browser page (email, dns, ipv6 tunnels, flash, mp3 players etc). Turns out I was wrong - sigh - as I said the browsers are more = aggressive in finding routes than I assumed (or indeed than my ICE implementations = are). > Breaking the proxy principle is neither a Tor nor a VPN problem. > It's just browser vendors breaking a promise given to users that > configured proxies would be respected. >=20 >> I=E2=80=99m SOCKs ignorant. >=20 > So we all have our knowledge deficiencies... > good to be honest about them. >=20 And now that I=E2=80=99ve educated myself somewhat, I=E2=80=99m agreeing = with you. >>> And if local IP information is so super harmless, then why is it >>> an obvious reason for TBB devs to disable the entire thing? >>> I presume for the reasons I stated before. >>=20 >> I have no idea, but I fear it is because no one has split these = issues out. >=20 > So let's dissect some more until we know what we are doing. Which turns out to be the only useful contribution my made. >=20 >> I=E2=80=99m of the view that there are _useful_ instances of P2P = crypto >> in-browser - we will clearly have to disagree about that. >=20 > I think we could improve the user's ability to ensure end-to-end > authentication beyond server-based negotiation. Something like > rendering persistent public keys into QR codes and having people > exchange those QR codes at cocktail parties and hackathons. >=20 > Servers would still be able to provide the signaling code, but users > would be granted a guarantee that the E2E connection is authentic. >=20 https://yopet.us :-)=20 Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_4FABBCD0-4254-42BB-BB84-DBFEC1E4DAA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 16 Jul 2015, at 09:42, carlo von lynX <lynX@i.know.you.are.psyced.org> wrote:

Yes, I dare to speak out of my 25 years of = experience on the
Internet even if I didn't have to use = much VPN ever. I can
imagine plenty of constellations = where the VPN is NOT supposed
to take over all = communications on the system but rather offer
a side route = into a company's servers or suchlike. Therefore
I worry if = the software provider can always come up with a
configuration that still does what the customers expect = and
at the same time deals with the new backdoor = introduced by WebRTC.
Of course anyone with better = understanding can help clear up
these worries.

That = isn=E2=80=99t what I meant. I expect secure software providers to keep = their
software abreast of new developments.

It turns out that I was completely wrong. The = browsers are currently so 
thorough in their discovery of = available interfaces and routes that no
amount of changes by = the sys admin or VPN supplier will fix this problem.

Sorry about that. 


Uh, not sure if that is an established pattern in the = industry.
Usually somebody does whatever fits into their = business model
best, then there is a public outcry and = possibly some bloodspill,
then all the players look at how = they can make a good impression
by reducing the collateral = damages.. but if that doesn't work out
cheap and easy.. = tant pis. Let's continue with business.

I happen to have the (no = doubt under informed) opinion that
this isn=E2=80=99t as = simple as it has been made out to be.

At least I was right here. - It is even more = complex than I believed.


Well, in case of doubt it is = important to pick the conservative
option until the issue = is properly analyzed rather than hoping
for the general = public to forget about the problem.

Also the "solution" you suggest AFAIU does not work for = people
who use Tor in a non-NATted environment, for = example on a
fixed system in a university library with a = static IP address.

That is an = interesting case. In that instance hiding the local IP would be
valuable. I thought however those users would normally run a = TOR os off
a usb stick in a VM. That would probably mask = the local IP.

Now that this is = more clear, have another look at my original mail
that = describes how such a dissident would use any Windows OS system
standing around. I doubt anything advanced like TAILS sticks = are
out there as merely possessing one could be = life-threatening.


Here too I find that I = was wrong and the current situation not what I assumed
and is = unsatisfactory.

Most SOCKS proxies = don't have support for ICE/STUN nor arbitrary UDP.
The current = browser implementations (backed by the ICE spec) take the view = that
if SOCKS doesn=E2=80=99t do UDP, then they should go = directly and send UDP anyhow.

I=E2=80=99= m not clear that this is what a user might expect. 
An = alternative might be to detect a proxy config _only_ offer TURN over = TLS 
candidates (and route the traffic over the proxy) - = This would result in
poor audio/video but would be more in = keeping with the spirit of the proxy config.

(a variant might be to inspect the proxy in detail = and use the address whitelists
to filter allowed traffic = somehow?) 



I totally = agree. My solution is imho a better fix, since it
also = protects against many other apps that might get started from
a browser page (email, dns, ipv6 tunnels, flash, mp3 players = etc).


Turns out I was wrong - = sigh - as I said the browsers are more aggressive
in finding = routes than I assumed (or indeed than my ICE implementations = are).

Breaking the proxy principle is neither a Tor nor a VPN = problem.
It's just browser vendors breaking a promise = given to users that
configured proxies would be = respected.

I=E2=80=99m SOCKs ignorant.

So we all have our knowledge deficiencies...
good= to be honest about them.


And now = that I=E2=80=99ve educated myself somewhat, I=E2=80=99m agreeing with = you.


And if local IP = information is so super harmless, then why is it
an = obvious reason for TBB devs to disable the entire thing?
I = presume for the reasons I stated before.

I have no idea, but I fear it is because no one has split = these issues out.

So let's = dissect some more until we know what we are doing.

Which turns = out to be the only useful contribution my <rant/> = made.



I=E2=80=99m of the view that there are _useful_ = instances of P2P crypto
in-browser - we will clearly have = to disagree about that.

I = think we could improve the user's ability to ensure end-to-end
authentication beyond server-based negotiation. Something = like
rendering persistent public keys into QR codes and = having people
exchange those QR codes at cocktail parties = and hackathons.

Servers would still be able = to provide the signaling code, but users
would be granted = a guarantee that the E2E connection is authentic.



Tim Panton - = Web/VoIP consultant and implementor
www.westhawk.co.uk



= --Apple-Mail=_4FABBCD0-4254-42BB-BB84-DBFEC1E4DAA7-- From nobody Fri Jul 24 03:31:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054AB1A21AF for ; Mon, 20 Jul 2015 04:55:55 -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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwYvxyjE_ma1 for ; Mon, 20 Jul 2015 04:55:52 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FC71A1B89 for ; Mon, 20 Jul 2015 04:55:51 -0700 (PDT) Received: (qmail 83477 invoked from network); 20 Jul 2015 11:55:49 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 7069 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 20 Jul 2015 11:55:49 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id D63DC18A222F; Mon, 20 Jul 2015 12:55:47 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B465418A0ADC; Mon, 20 Jul 2015 12:55:47 +0100 (BST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_6282B1E8-A6F9-4743-9129-C807A72FF543" From: Tim Panton In-Reply-To: <20150716084225.GA29652@lo.psyced.org> Resent-From: Tim Panton Date: Mon, 20 Jul 2015 12:53:59 +0100 Resent-Date: Mon, 20 Jul 2015 12:55:47 +0100 Message-Id: References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> Resent-To: "rtcweb@ietf.org >> rtcweb@ietf.org" , carlo von lynX To: carlo von lynX X-Mailer: Apple Mail (2.2102) Resent-Message-Id: <20150720115547.B465418A0ADC@zimbra003.verygoodemail.com> Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 03:31:24 -0700 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:55:55 -0000 --Apple-Mail=_6282B1E8-A6F9-4743-9129-C807A72FF543 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Jul 2015, at 09:42, carlo von lynX = > = wrote: >=20 > Yes, I dare to speak out of my 25 years of experience on the > Internet even if I didn't have to use much VPN ever. I can > imagine plenty of constellations where the VPN is NOT supposed > to take over all communications on the system but rather offer > a side route into a company's servers or suchlike. Therefore > I worry if the software provider can always come up with a > configuration that still does what the customers expect and > at the same time deals with the new backdoor introduced by WebRTC. > Of course anyone with better understanding can help clear up > these worries. >=20 >> That isn=E2=80=99t what I meant. I expect secure software providers = to keep their >> software abreast of new developments.=20 It turns out that I was completely wrong. The browsers are currently so=20= thorough in their discovery of available interfaces and routes that no amount of changes by the sys admin or VPN supplier will fix this = problem. Sorry about that.=20 >=20 > Uh, not sure if that is an established pattern in the industry. > Usually somebody does whatever fits into their business model > best, then there is a public outcry and possibly some bloodspill, > then all the players look at how they can make a good impression > by reducing the collateral damages.. but if that doesn't work out > cheap and easy.. tant pis. Let's continue with business. >=20 >> I happen to have the (no doubt under informed) opinion that >> this isn=E2=80=99t as simple as it has been made out to be. At least I was right here. - It is even more complex than I believed. >=20 > Well, in case of doubt it is important to pick the conservative > option until the issue is properly analyzed rather than hoping > for the general public to forget about the problem. >=20 >>> Also the "solution" you suggest AFAIU does not work for people >>> who use Tor in a non-NATted environment, for example on a >>> fixed system in a university library with a static IP address. >>=20 >> That is an interesting case. In that instance hiding the local IP = would be=20 >> valuable. I thought however those users would normally run a TOR os = off=20 >> a usb stick in a VM. That would probably mask the local IP. >=20 > Now that this is more clear, have another look at my original mail > that describes how such a dissident would use any Windows OS system > standing around. I doubt anything advanced like TAILS sticks are > out there as merely possessing one could be life-threatening. Here too I find that I was wrong and the current situation not what I = assumed and is unsatisfactory. Most SOCKS proxies don't have support for ICE/STUN nor arbitrary UDP. The current browser implementations (backed by the ICE spec) take the = view that if SOCKS doesn=E2=80=99t do UDP, then they should go directly and send = UDP anyhow. I=E2=80=99m not clear that this is what a user might expect.=20 An alternative might be to detect a proxy config _only_ offer TURN over = TLS=20 candidates (and route the traffic over the proxy) - This would result in poor audio/video but would be more in keeping with the spirit of the = proxy config. (a variant might be to inspect the proxy in detail and use the address = whitelists to filter allowed traffic somehow?)=20 >>=20 >> I totally agree. My solution is imho a better fix, since it >> also protects against many other apps that might get started from >> a browser page (email, dns, ipv6 tunnels, flash, mp3 players etc). Turns out I was wrong - sigh - as I said the browsers are more = aggressive in finding routes than I assumed (or indeed than my ICE implementations = are). > Breaking the proxy principle is neither a Tor nor a VPN problem. > It's just browser vendors breaking a promise given to users that > configured proxies would be respected. >=20 >> I=E2=80=99m SOCKs ignorant. >=20 > So we all have our knowledge deficiencies... > good to be honest about them. >=20 And now that I=E2=80=99ve educated myself somewhat, I=E2=80=99m agreeing = with you. >>> And if local IP information is so super harmless, then why is it >>> an obvious reason for TBB devs to disable the entire thing? >>> I presume for the reasons I stated before. >>=20 >> I have no idea, but I fear it is because no one has split these = issues out. >=20 > So let's dissect some more until we know what we are doing. Which turns out to be the only useful contribution my made. >=20 >> I=E2=80=99m of the view that there are _useful_ instances of P2P = crypto >> in-browser - we will clearly have to disagree about that. >=20 > I think we could improve the user's ability to ensure end-to-end > authentication beyond server-based negotiation. Something like > rendering persistent public keys into QR codes and having people > exchange those QR codes at cocktail parties and hackathons. >=20 > Servers would still be able to provide the signaling code, but users > would be granted a guarantee that the E2E connection is authentic. >=20 https://yopet.us :-)=20 Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_6282B1E8-A6F9-4743-9129-C807A72FF543 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 16 Jul 2015, at 09:42, carlo von lynX = <lynX@i.know.you.are.psyced.org> wrote:

Yes, I dare to speak out of my 25 years of = experience on the
Internet even if I didn't have to use = much VPN ever. I can
imagine plenty of constellations = where the VPN is NOT supposed
to take over all = communications on the system but rather offer
a side route = into a company's servers or suchlike. Therefore
I worry if = the software provider can always come up with a
configuration that still does what the customers expect = and
at the same time deals with the new backdoor = introduced by WebRTC.
Of course anyone with better = understanding can help clear up
these worries.

That = isn=E2=80=99t what I meant. I expect secure software providers to keep = their
software abreast of new developments.

It turns out that I was completely = wrong. The browsers are currently so 
thorough = in their discovery of available interfaces and routes that no
amount of changes by the sys admin or VPN supplier will fix = this problem.

Sorry about that. 


Uh, not sure if = that is an established pattern in the industry.
Usually = somebody does whatever fits into their business model
best, = then there is a public outcry and possibly some bloodspill,
then all the players look at how they can make a good = impression
by reducing the collateral damages.. but if = that doesn't work out
cheap and easy.. tant pis. Let's = continue with business.

I happen to have the (no doubt under informed) = opinion that
this isn=E2=80=99t as simple as it has been = made out to be.

At least I was right = here. - It is even more complex than I believed.


Well, in case of doubt it is important to pick the = conservative
option until the issue is properly analyzed = rather than hoping
for the general public to forget about = the problem.

Also the "solution" you = suggest AFAIU does not work for people
who use Tor in a = non-NATted environment, for example on a
fixed system in a = university library with a static IP address.

That is an interesting case. In = that instance hiding the local IP would be
valuable. I = thought however those users would normally run a TOR os off
a usb stick in a VM. That would probably mask the local = IP.

Now that this is more = clear, have another look at my original mail
that = describes how such a dissident would use any Windows OS system
standing around. I doubt anything advanced like TAILS sticks = are
out there as merely possessing one could be = life-threatening.


Here= too I find that I was wrong and the current situation not what I = assumed
and is unsatisfactory.

Most SOCKS proxies don't = have support for ICE/STUN nor arbitrary UDP.
The = current browser implementations (backed by the ICE spec) take the view = that
if SOCKS doesn=E2=80=99t do UDP, then they = should go directly and send UDP anyhow.

I=E2=80=99m not clear that this is what = a user might expect. 
An alternative might be = to detect a proxy config _only_ offer TURN over TLS 
candidates (and route the traffic over the proxy) - This = would result in
poor audio/video but would be more = in keeping with the spirit of the proxy config.

(a variant might be to inspect the = proxy in detail and use the address whitelists
to = filter allowed traffic somehow?) 



I totally agree. My solution is imho a better = fix, since it
also protects against many other apps that = might get started from
a browser page (email, dns, ipv6 = tunnels, flash, mp3 players etc).


Turns out I was wrong - sigh - as I said the browsers are = more aggressive
in finding routes than I assumed = (or indeed than my ICE implementations are).

Breaking = the proxy principle is neither a Tor nor a VPN problem.
It's= just browser vendors breaking a promise given to users that
configured proxies would be respected.

I=E2=80=99m SOCKs = ignorant.

So we all have our = knowledge deficiencies...
good to be honest about them.


And now that I=E2=80=99ve educated = myself somewhat, I=E2=80=99m agreeing with you.


And if local IP information is so super harmless, then why is = it
an obvious reason for TBB devs to disable the entire = thing?
I presume for the reasons I stated before.

I have no idea, but I fear it is = because no one has split these issues out.

So let's dissect some more until we know what we are = doing.

Which turns out to be the only useful = contribution my <rant/> made.



I=E2=80=99m= of the view that there are _useful_ instances of P2P crypto
in-browser - we will clearly have to disagree about that.

I think we could improve the = user's ability to ensure end-to-end
authentication beyond = server-based negotiation. Something like
rendering = persistent public keys into QR codes and having people
exchange those QR codes at cocktail parties and = hackathons.

Servers would still be able to = provide the signaling code, but users
would be granted a = guarantee that the E2E connection is authentic.


https://yopet.us :-) 

Tim Panton - Web/VoIP consultant and = implementor
www.westhawk.co.uk



= --Apple-Mail=_6282B1E8-A6F9-4743-9129-C807A72FF543-- From nobody Fri Jul 24 03:31:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80171A6EED for ; Mon, 20 Jul 2015 05:06:30 -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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZKfKEyCacVo for ; Mon, 20 Jul 2015 05:06:25 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681BD1A6EE6 for ; Mon, 20 Jul 2015 05:06:24 -0700 (PDT) Received: (qmail 2779 invoked from network); 20 Jul 2015 12:06:23 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 7482 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 20 Jul 2015 12:06:23 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 10ECE18A1E13 for ; Mon, 20 Jul 2015 13:06:22 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id E93A618A1D1F for ; Mon, 20 Jul 2015 13:06:21 +0100 (BST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_2788FB8A-88E5-4452-A3BA-9B612E2E9AFD" From: Tim Panton In-Reply-To: <20150716084225.GA29652@lo.psyced.org> Resent-From: Tim Panton Date: Mon, 20 Jul 2015 12:53:59 +0100 Resent-Date: Mon, 20 Jul 2015 13:06:21 +0100 Message-Id: References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> Resent-To: "rtcweb@ietf.org >> rtcweb@ietf.org" To: carlo von lynX X-Mailer: Apple Mail (2.2102) Resent-Message-Id: <20150720120621.E93A618A1D1F@zimbra003.verygoodemail.com> Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 03:31:24 -0700 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 12:06:31 -0000 --Apple-Mail=_2788FB8A-88E5-4452-A3BA-9B612E2E9AFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Jul 2015, at 09:42, carlo von lynX = > = wrote: >=20 > Yes, I dare to speak out of my 25 years of experience on the > Internet even if I didn't have to use much VPN ever. I can > imagine plenty of constellations where the VPN is NOT supposed > to take over all communications on the system but rather offer > a side route into a company's servers or suchlike. Therefore > I worry if the software provider can always come up with a > configuration that still does what the customers expect and > at the same time deals with the new backdoor introduced by WebRTC. > Of course anyone with better understanding can help clear up > these worries. >=20 >> That isn=E2=80=99t what I meant. I expect secure software providers = to keep their >> software abreast of new developments.=20 It turns out that I was completely wrong. The browsers are currently so=20= thorough in their discovery of available interfaces and routes that no amount of changes by the sys admin or VPN supplier will fix this = problem. Sorry about that.=20 >=20 > Uh, not sure if that is an established pattern in the industry. > Usually somebody does whatever fits into their business model > best, then there is a public outcry and possibly some bloodspill, > then all the players look at how they can make a good impression > by reducing the collateral damages.. but if that doesn't work out > cheap and easy.. tant pis. Let's continue with business. >=20 >> I happen to have the (no doubt under informed) opinion that >> this isn=E2=80=99t as simple as it has been made out to be. At least I was right here. - It is even more complex than I believed. >=20 > Well, in case of doubt it is important to pick the conservative > option until the issue is properly analyzed rather than hoping > for the general public to forget about the problem. >=20 >>> Also the "solution" you suggest AFAIU does not work for people >>> who use Tor in a non-NATted environment, for example on a >>> fixed system in a university library with a static IP address. >>=20 >> That is an interesting case. In that instance hiding the local IP = would be=20 >> valuable. I thought however those users would normally run a TOR os = off=20 >> a usb stick in a VM. That would probably mask the local IP. >=20 > Now that this is more clear, have another look at my original mail > that describes how such a dissident would use any Windows OS system > standing around. I doubt anything advanced like TAILS sticks are > out there as merely possessing one could be life-threatening. Here too I find that I was wrong and the current situation not what I = assumed and is unsatisfactory. Most SOCKS proxies don't have support for ICE/STUN nor arbitrary UDP. The current browser implementations (backed by the ICE spec) take the = view that if SOCKS doesn=E2=80=99t do UDP, then they should go directly and send = UDP anyhow. I=E2=80=99m not clear that this is what a user might expect.=20 An alternative might be to detect a proxy config _only_ offer TURN over = TLS=20 candidates (and route the traffic over the proxy) - This would result in poor audio/video but would be more in keeping with the spirit of the = proxy config. (a variant might be to inspect the proxy in detail and use the address = whitelists to filter allowed traffic somehow?)=20 >>=20 >> I totally agree. My solution is imho a better fix, since it >> also protects against many other apps that might get started from >> a browser page (email, dns, ipv6 tunnels, flash, mp3 players etc). Turns out I was wrong - sigh - as I said the browsers are more = aggressive in finding routes than I assumed (or indeed than my ICE implementations = are). > Breaking the proxy principle is neither a Tor nor a VPN problem. > It's just browser vendors breaking a promise given to users that > configured proxies would be respected. >=20 >> I=E2=80=99m SOCKs ignorant. >=20 > So we all have our knowledge deficiencies... > good to be honest about them. >=20 And now that I=E2=80=99ve educated myself somewhat, I=E2=80=99m agreeing = with you. >>> And if local IP information is so super harmless, then why is it >>> an obvious reason for TBB devs to disable the entire thing? >>> I presume for the reasons I stated before. >>=20 >> I have no idea, but I fear it is because no one has split these = issues out. >=20 > So let's dissect some more until we know what we are doing. Which turns out to be the only useful contribution my made. >=20 >> I=E2=80=99m of the view that there are _useful_ instances of P2P = crypto >> in-browser - we will clearly have to disagree about that. >=20 > I think we could improve the user's ability to ensure end-to-end > authentication beyond server-based negotiation. Something like > rendering persistent public keys into QR codes and having people > exchange those QR codes at cocktail parties and hackathons. >=20 > Servers would still be able to provide the signaling code, but users > would be granted a guarantee that the E2E connection is authentic. >=20 https://yopet.us :-)=20 Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_2788FB8A-88E5-4452-A3BA-9B612E2E9AFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 16 Jul 2015, at 09:42, carlo von lynX = <lynX@i.know.you.are.psyced.org> wrote:

Yes, I dare to speak out of my 25 years of = experience on the
Internet even if I didn't have to use = much VPN ever. I can
imagine plenty of constellations = where the VPN is NOT supposed
to take over all = communications on the system but rather offer
a side route = into a company's servers or suchlike. Therefore
I worry if = the software provider can always come up with a
configuration that still does what the customers expect = and
at the same time deals with the new backdoor = introduced by WebRTC.
Of course anyone with better = understanding can help clear up
these worries.

That = isn=E2=80=99t what I meant. I expect secure software providers to keep = their
software abreast of new developments.

It turns out that I was completely = wrong. The browsers are currently so 
thorough = in their discovery of available interfaces and routes that no
amount of changes by the sys admin or VPN supplier will fix = this problem.

Sorry about that. 


Uh, not sure if = that is an established pattern in the industry.
Usually = somebody does whatever fits into their business model
best, = then there is a public outcry and possibly some bloodspill,
then all the players look at how they can make a good = impression
by reducing the collateral damages.. but if = that doesn't work out
cheap and easy.. tant pis. Let's = continue with business.

I happen to have the (no doubt under informed) = opinion that
this isn=E2=80=99t as simple as it has been = made out to be.

At least I was right = here. - It is even more complex than I believed.


Well, in case of doubt it is important to pick the = conservative
option until the issue is properly analyzed = rather than hoping
for the general public to forget about = the problem.

Also the "solution" you = suggest AFAIU does not work for people
who use Tor in a = non-NATted environment, for example on a
fixed system in a = university library with a static IP address.

That is an interesting case. In = that instance hiding the local IP would be
valuable. I = thought however those users would normally run a TOR os off
a usb stick in a VM. That would probably mask the local = IP.

Now that this is more = clear, have another look at my original mail
that = describes how such a dissident would use any Windows OS system
standing around. I doubt anything advanced like TAILS sticks = are
out there as merely possessing one could be = life-threatening.


Here= too I find that I was wrong and the current situation not what I = assumed
and is unsatisfactory.

Most SOCKS proxies don't = have support for ICE/STUN nor arbitrary UDP.
The = current browser implementations (backed by the ICE spec) take the view = that
if SOCKS doesn=E2=80=99t do UDP, then they = should go directly and send UDP anyhow.

I=E2=80=99m not clear that this is what = a user might expect. 
An alternative might be = to detect a proxy config _only_ offer TURN over TLS 
candidates (and route the traffic over the proxy) - This = would result in
poor audio/video but would be more = in keeping with the spirit of the proxy config.

(a variant might be to inspect the = proxy in detail and use the address whitelists
to = filter allowed traffic somehow?) 



I totally agree. My solution is imho a better = fix, since it
also protects against many other apps that = might get started from
a browser page (email, dns, ipv6 = tunnels, flash, mp3 players etc).


Turns out I was wrong - sigh - as I said the browsers are = more aggressive
in finding routes than I assumed = (or indeed than my ICE implementations are).

Breaking = the proxy principle is neither a Tor nor a VPN problem.
It's= just browser vendors breaking a promise given to users that
configured proxies would be respected.

I=E2=80=99m SOCKs = ignorant.

So we all have our = knowledge deficiencies...
good to be honest about them.


And now that I=E2=80=99ve educated = myself somewhat, I=E2=80=99m agreeing with you.


And if local IP information is so super harmless, then why is = it
an obvious reason for TBB devs to disable the entire = thing?
I presume for the reasons I stated before.

I have no idea, but I fear it is = because no one has split these issues out.

So let's dissect some more until we know what we are = doing.

Which turns out to be the only useful = contribution my <rant/> made.



I=E2=80=99m= of the view that there are _useful_ instances of P2P crypto
in-browser - we will clearly have to disagree about that.

I think we could improve the = user's ability to ensure end-to-end
authentication beyond = server-based negotiation. Something like
rendering = persistent public keys into QR codes and having people
exchange those QR codes at cocktail parties and = hackathons.

Servers would still be able to = provide the signaling code, but users
would be granted a = guarantee that the E2E connection is authentic.


https://yopet.us :-) 

Tim Panton - Web/VoIP consultant and = implementor
www.westhawk.co.uk



= --Apple-Mail=_2788FB8A-88E5-4452-A3BA-9B612E2E9AFD-- From nobody Fri Jul 24 03:31:34 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2941A7034 for ; Mon, 20 Jul 2015 05:15:18 -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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x0qAtsNuoie for ; Mon, 20 Jul 2015 05:15:14 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874551A7D82 for ; Mon, 20 Jul 2015 05:15:02 -0700 (PDT) Received: (qmail 17803 invoked from network); 20 Jul 2015 12:15:01 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 7753 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 20 Jul 2015 12:15:01 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id F084C18A0FBC for ; Mon, 20 Jul 2015 13:14:59 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id D680418A0BC0 for ; Mon, 20 Jul 2015 13:14:59 +0100 (BST) From: Tim Panton new Content-Type: multipart/alternative; boundary="Apple-Mail=_22967C1B-2449-4FEB-AF05-79B520E714E4" Message-Id: <28B9296C-918F-46CD-B189-6D7A1D30B8E8@westhawk.co.uk> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Date: Mon, 20 Jul 2015 13:14:59 +0100 References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> To: "rtcweb@ietf.org >> rtcweb@ietf.org" In-Reply-To: <20150716084225.GA29652@lo.psyced.org> X-Mailer: Apple Mail (2.2102) Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 03:31:25 -0700 Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 12:15:18 -0000 --Apple-Mail=_22967C1B-2449-4FEB-AF05-79B520E714E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Jul 2015, at 09:42, carlo von lynX = > = wrote: >=20 > Yes, I dare to speak out of my 25 years of experience on the > Internet even if I didn't have to use much VPN ever. I can > imagine plenty of constellations where the VPN is NOT supposed > to take over all communications on the system but rather offer > a side route into a company's servers or suchlike. Therefore > I worry if the software provider can always come up with a > configuration that still does what the customers expect and > at the same time deals with the new backdoor introduced by WebRTC. > Of course anyone with better understanding can help clear up > these worries. >=20 >> That isn=E2=80=99t what I meant. I expect secure software providers = to keep their >> software abreast of new developments.=20 It turns out that I was completely wrong. The browsers are currently so=20= thorough in their discovery of available interfaces and routes that no amount of changes by the sys admin or VPN supplier will fix this = problem. Sorry about that.=20 >=20 > Uh, not sure if that is an established pattern in the industry. > Usually somebody does whatever fits into their business model > best, then there is a public outcry and possibly some bloodspill, > then all the players look at how they can make a good impression > by reducing the collateral damages.. but if that doesn't work out > cheap and easy.. tant pis. Let's continue with business. >=20 >> I happen to have the (no doubt under informed) opinion that >> this isn=E2=80=99t as simple as it has been made out to be. At least I was right here. - It is even more complex than I believed. >=20 > Well, in case of doubt it is important to pick the conservative > option until the issue is properly analyzed rather than hoping > for the general public to forget about the problem. >=20 >>> Also the "solution" you suggest AFAIU does not work for people >>> who use Tor in a non-NATted environment, for example on a >>> fixed system in a university library with a static IP address. >>=20 >> That is an interesting case. In that instance hiding the local IP = would be=20 >> valuable. I thought however those users would normally run a TOR os = off=20 >> a usb stick in a VM. That would probably mask the local IP. >=20 > Now that this is more clear, have another look at my original mail > that describes how such a dissident would use any Windows OS system > standing around. I doubt anything advanced like TAILS sticks are > out there as merely possessing one could be life-threatening. Here too I find that I was wrong and the current situation not what I = assumed and is unsatisfactory. Most SOCKS proxies don't have support for ICE/STUN nor arbitrary UDP. The current browser implementations (backed by the ICE spec) take the = view that if SOCKS doesn=E2=80=99t do UDP, then they should go directly and send = UDP anyhow. I=E2=80=99m not clear that this is what a user might expect.=20 An alternative might be to detect a proxy config _only_ offer TURN over = TLS=20 candidates (and route the traffic over the proxy) - This would result in poor audio/video but would be more in keeping with the spirit of the = proxy config. (a variant might be to inspect the proxy in detail and use the address = whitelists to filter allowed traffic somehow?)=20 >>=20 >> I totally agree. My solution is imho a better fix, since it >> also protects against many other apps that might get started from >> a browser page (email, dns, ipv6 tunnels, flash, mp3 players etc). Turns out I was wrong - sigh - as I said the browsers are more = aggressive in finding routes than I assumed (or indeed than my ICE implementations = are). > Breaking the proxy principle is neither a Tor nor a VPN problem. > It's just browser vendors breaking a promise given to users that > configured proxies would be respected. >=20 >> I=E2=80=99m SOCKs ignorant. >=20 > So we all have our knowledge deficiencies... > good to be honest about them. >=20 And now that I=E2=80=99ve educated myself somewhat, I=E2=80=99m agreeing = with you. >>> And if local IP information is so super harmless, then why is it >>> an obvious reason for TBB devs to disable the entire thing? >>> I presume for the reasons I stated before. >>=20 >> I have no idea, but I fear it is because no one has split these = issues out. >=20 > So let's dissect some more until we know what we are doing. Which turns out to be the only useful contribution my made. >=20 >> I=E2=80=99m of the view that there are _useful_ instances of P2P = crypto >> in-browser - we will clearly have to disagree about that. >=20 > I think we could improve the user's ability to ensure end-to-end > authentication beyond server-based negotiation. Something like > rendering persistent public keys into QR codes and having people > exchange those QR codes at cocktail parties and hackathons. >=20 > Servers would still be able to provide the signaling code, but users > would be granted a guarantee that the E2E connection is authentic. >=20 https://yopet.us :-)=20 --Apple-Mail=_22967C1B-2449-4FEB-AF05-79B520E714E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 16 Jul 2015, at 09:42, carlo von lynX = <lynX@i.know.you.are.psyced.org> wrote:

Yes, I dare to speak out of my 25 years of = experience on the
Internet even if I didn't have to use = much VPN ever. I can
imagine plenty of constellations = where the VPN is NOT supposed
to take over all = communications on the system but rather offer
a side route = into a company's servers or suchlike. Therefore
I worry if = the software provider can always come up with a
configuration that still does what the customers expect = and
at the same time deals with the new backdoor = introduced by WebRTC.
Of course anyone with better = understanding can help clear up
these worries.

That = isn=E2=80=99t what I meant. I expect secure software providers to keep = their
software abreast of new developments. 

It turns out that I was completely = wrong. The browsers are currently so 
thorough = in their discovery of available interfaces and routes that no
amount of changes by the sys admin or VPN supplier will fix = this problem.

Sorry about that. 


Uh, not sure if = that is an established pattern in the industry.
Usually = somebody does whatever fits into their business model
best, = then there is a public outcry and possibly some bloodspill,
then all the players look at how they can make a good = impression
by reducing the collateral damages.. but if = that doesn't work out
cheap and easy.. tant pis. Let's = continue with business.

I happen to have the (no doubt under informed) = opinion that
this isn=E2=80=99t as simple as it has been = made out to be.

At least I was right = here. - It is even more complex than I believed.


Well, in case of doubt it is important to pick the = conservative
option until the issue is properly analyzed = rather than hoping
for the general public to forget about = the problem.

Also the "solution" you = suggest AFAIU does not work for people
who use Tor in a = non-NATted environment, for example on a
fixed system in a = university library with a static IP address.

That is an interesting case. In = that instance hiding the local IP would be 
valuable. = I thought however those users would normally run a TOR os off 
a usb stick in a VM. That would probably mask the local = IP.

Now that this is more = clear, have another look at my original mail
that = describes how such a dissident would use any Windows OS system
standing around. I doubt anything advanced like TAILS sticks = are
out there as merely possessing one could be = life-threatening.


Here= too I find that I was wrong and the current situation not what I = assumed
and is unsatisfactory.

Most SOCKS proxies don't = have support for ICE/STUN nor arbitrary UDP.
The = current browser implementations (backed by the ICE spec) take the view = that
if SOCKS doesn=E2=80=99t do UDP, then they = should go directly and send UDP anyhow.

I=E2=80=99m not clear that this is what = a user might expect. 
An alternative might be = to detect a proxy config _only_ offer TURN over TLS 
candidates (and route the traffic over the proxy) - This = would result in
poor audio/video but would be more = in keeping with the spirit of the proxy config.

(a variant might be to inspect the = proxy in detail and use the address whitelists
to = filter allowed traffic somehow?) 



I totally agree. My solution is imho a better = fix, since it
also protects against many other apps that = might get started from
a browser page (email, dns, ipv6 = tunnels, flash, mp3 players etc).


Turns out I was wrong - sigh - as I said the browsers are = more aggressive
in finding routes than I assumed = (or indeed than my ICE implementations are).

Breaking = the proxy principle is neither a Tor nor a VPN problem.
It's= just browser vendors breaking a promise given to users that
configured proxies would be respected.

I=E2=80=99m SOCKs = ignorant.

So we all have our = knowledge deficiencies...
good to be honest about them.


And now that I=E2=80=99ve educated = myself somewhat, I=E2=80=99m agreeing with you.


And if local IP information is so super harmless, then why is = it
an obvious reason for TBB devs to disable the entire = thing?
I presume for the reasons I stated before.

I have no idea, but I fear it is = because no one has split these issues out.

So let's dissect some more until we know what we are = doing.

Which turns out to be the only useful = contribution my <rant/> made.



I=E2=80=99m= of the view that there are _useful_ instances of P2P crypto
in-browser - we will clearly have to disagree about that.

I think we could improve the = user's ability to ensure end-to-end
authentication beyond = server-based negotiation. Something like
rendering = persistent public keys into QR codes and having people
exchange those QR codes at cocktail parties and = hackathons.

Servers would still be able to = provide the signaling code, but users
would be granted a = guarantee that the E2E connection is authentic.


https://yopet.us :-) 

= --Apple-Mail=_22967C1B-2449-4FEB-AF05-79B520E714E4-- From nobody Fri Jul 24 03:52:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E561A8AC0 for ; Fri, 24 Jul 2015 03:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCwjofpMfuzH for ; Fri, 24 Jul 2015 03:52:08 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8AA1A8AB6 for ; Fri, 24 Jul 2015 03:52:08 -0700 (PDT) Received: by igk11 with SMTP id 11so2581313igk.1 for ; Fri, 24 Jul 2015 03:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=JwgJYSXLYM55bHABIqkDjJv4timED78w+s0A48k5jAw=; b=FVv6LREov7b3ZDM6rTsrzZDCWy5Wy+ASaz00biP34J+e+t48AFOWRFVD7mfzWoxCAc aghpy0AzDefQRMWG+DMac6p48Go72iLsB1g1dwMKWk1aRm8nsErlBbuwAs/s0qiTW1t/ kiuV0pzbzQ1cr4zbt3+UOdDFvAnZT6VnOyjxdvdHLmGuKbveXXJiJ7i+H6Ky5o2hgxX4 stjLCQ3ZeU2mre3ACu414zqxdPZKY87o8ADSTGgR5L8XMAmFhyWATCcFoHhivRXfZqNs IA4K2/5gJj9pkHGS6Q3gLfiDyRaUMuBgFMzTQ/hZYRgxoJtr+Ajj0XekMb8cks6Rgc9b s1tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=JwgJYSXLYM55bHABIqkDjJv4timED78w+s0A48k5jAw=; b=Rc69oolWmxp6pkvl4W6pc37NSY27Up3X/F3/ucACsk2QBsWmOFiKL4M4qC1GTiDQdL IrOLOD7ByqO9hOLcqgx9kCDaU/T1V1cv/joPSjPOZBuT7MOFeONEM2Ap14McJcB4iILo Q0BKJtfVXLPU6GJynLoeMNmnCJMfR+Srf2+7KjdsNiluxTl9tjBBiMGWOYehaKAffg53 IT1zfZ/4uuSYsZ9UHvzMLZ/QtFkl1q8f1k7vpFppOwiy2dpHkmxncasScn4WjT+oGdho 8YLNt+w/57pvIDKN9awfxqyQFKTsFV5AXJhPtldQNFB+w6qs8EJnAfD0rmpldMewJyGl 5Slg== X-Gm-Message-State: ALoCoQlW/S/+G42gjP+3mFZM5xS0A5vWb1lvoiwIrZuPEs7ybfsPBk6mr/wg733t574VMNFCzTMN X-Received: by 10.50.72.6 with SMTP id z6mr3939539igu.65.1437735127898; Fri, 24 Jul 2015 03:52:07 -0700 (PDT) MIME-Version: 1.0 References: <55B1624D.4050908@jesup.org> <55B1CA54.9050809@jesup.org> <8C392F53-3FC9-46B7-A8A5-C4D3F584DDED@urjc.es> In-Reply-To: From: Stefan Holmer Date: Fri, 24 Jul 2015 10:51:58 +0000 Message-ID: To: Justin Uberti , =?UTF-8?Q?Luis_L=C3=B3pez_Fern=C3=A1ndez?= Content-Type: multipart/alternative; boundary=047d7bdc189a948ffc051b9ccb09 Archived-At: Cc: Randell Jesup , "" Subject: Re: [rtcweb] Congestion warmup X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:52:11 -0000 --047d7bdc189a948ffc051b9ccb09 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Luis, for what you are talking about there exists a draft in the rmcat working group: https://tools.ietf.org/html/draft-singh-rmcat-adaptive-fec-0= 1 I tend to agree that it may not be a good idea to blast packets to the other end before accepting the call. /Stefan On Fri, Jul 24, 2015 at 11:52 AM Justin Uberti wrote: > I tend to think BWE warmup is out of scope for this discussion. It's not > clear that the callee wants to receive perhaps substantial amounts of > traffic prior to having accepted the call. > > On Fri, Jul 24, 2015 at 11:47 AM, Luis L=C3=B3pez Fern=C3=A1ndez > wrote: > >> This is an interesting possibility. Using some kind of fec as padding >> could make possible to avoid using a fake codec allowing receivers to >> behave normally and without requiring implementing a different behavior = for >> the fake codec data. In addition, this protection of the encoded >> static/black image may avoid PLIs in case of severe packet loss when >> hitting a BW during the probe. This could be even used as a probe mechan= ism >> for BW estimation with the call fully open, but this is another story. >> >> El 24/07/2015, a las 10:54, Peter Thatcher >> escribi=C3=B3: >> >> Could the new flexfec payload type be used for padding? >> >> On Thu, Jul 23, 2015 at 10:17 PM, Randell Jesup >> wrote: >> >>> I'd love to be able to warm up congestion control, and not just DTLS. >>> That requires sending data and allowing it to increase to probe the >>> connection and open the congestion window, and preferably sending in bo= th >>> directions (i.e. a=3Dsendrecv in the warm-up answer). >>> >>> We'd need to find a way to generically pad RTP packets to a target size >>> (since encoding a static/black image won't use enough bytes). The obvi= ous >>> codec-agnostic mechanism would be a header extension. Since they can b= e >>> any 4-byte-multiple size, that would pretty much work up to ~384K (1500 >>> byte packets, 1/frame @30fps). However, we could run the fake video >>> framerate arbitrarily high to hit any bandwidth target we need. >>> >>> Alternatively (and *much* better) we could use a "fake" codec >>> (a=3Drtpmap:111 fake/90000) which doesn't actually include any real dat= a, >>> just padding. Advantages: no CPU code to encode/decode. No dealing wi= th >>> header extensions. Clear indication if the other side wants to do spin= up >>> (they can reject the codec if they don't want to). No encoding/decodin= g >>> CPU use. >>> >>> The offer would include it as a least-preferred codec to indicate warmu= p >>> support. If answerer answers with fake as the accepted codec (and real >>> codecs following), it's a warmup answer. Both sides will send and rece= ive >>> fake data to spin up the congestion windows (and also the jitter buffer= s, >>> etc). On actual answer, the fake codec would be dropped (or dropped to >>> bottom priority). The answerer would start sending in a real codec, w= hich >>> would work since the warmup answer would have included that codec. The >>> offerer would see the incoming real-codec packets, and decode them. W= hen >>> the real answer arrives, it will show the accepted codec has changed, a= nd >>> the offerer will install that answer and thus and start sending (real) >>> media. >>> >>> We still need a way to tell the system at the answerer side "I want to >>> accept but it's a warm-up accept" (and perhaps if we want to spin up >>> congestion control or not while waiting), and a way to say on the offer= er >>> side "I want to offer/use warmups". For those API points see the previ= ous >>> options from myself and Peter - or simply a way to say createAnswer of = a >>> warmup answer, and have that agree to all tracks with fake codecs being >>> primary. >>> >>> I'll note that all of these methods would benefit from a mechanism to >>> indicate the desired bitrate targets for each fake track; for solutions >>> that use some sort of fake video input (canvas.captureStream/etc) it >>> inherently allows the application to define the size and framerate, whi= ch >>> are the primary knobs used by the browser for setting 'max total bitrat= e' >>> for the track. You don't want the application to set the bandwidth >>> directly, you want it to define the parameters of the video stream so t= he >>> system can set "reasonable" limits for that resolution & situation. >>> >>> _______________________________________________ >>> 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 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 > --047d7bdc189a948ffc051b9ccb09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Luis, for what you are talking about there exists a draft = in the rmcat working group:=C2=A0https://tools.ietf.org/html/draft-singh-rmc= at-adaptive-fec-01

I tend to agree that it may not b= e a good idea to blast packets to the other end before accepting the call.<= /div>

/Stefan

On Fri, Jul 24, 2015 at 11:52 AM Jus= tin Uberti <juberti@google.com= > wrote:
I tend= to think BWE warmup is out of scope for this discussion. It's not clea= r that the callee wants to receive perhaps substantial amounts of traffic p= rior to having accepted the call.

On Fri, Jul 24, 2015 at 11:47 AM, Luis L=C3=B3pez Fer= n=C3=A1ndez <luis.lopez@urjc.es> wrote:
This is an interest= ing possibility. Using some kind of fec as padding could make possible to a= void using a fake codec allowing receivers to behave normally and without r= equiring implementing a different behavior for the fake codec data. In addi= tion, this protection of the encoded static/black image may avoid PLIs in c= ase of severe packet loss when hitting a BW during the probe. This could be= even used as a probe mechanism for BW estimation with the call fully open,= but this is another story.

El 24/07/2015, a las 10:54, Peter Thatcher <pthatcher@google.com> es= cribi=C3=B3:

Could t= he new flexfec payload type be used for padding? =C2=A0

On Thu, Jul 23, 2015 at 1= 0:17 PM, Randell Jesup <randell-ietf@jesup.org> wrote:<= br>
I'd love to be able to warm up conges= tion control, and not just DTLS.=C2=A0 That requires sending data and allow= ing it to increase to probe the connection and open the congestion window, = and preferably sending in both directions (i.e. a=3Dsendrecv in the warm-up= answer).

We'd need to find a way to generically pad RTP packets to a target size= (since encoding a static/black image won't use enough bytes).=C2=A0 Th= e obvious codec-agnostic mechanism would be a header extension.=C2=A0 Since= they can be any 4-byte-multiple size, that would pretty much work up to ~3= 84K (1500 byte packets, 1/frame @30fps). However, we could run the fake vid= eo framerate arbitrarily high to hit any bandwidth target we need.

Alternatively (and *much* better) we could use a "fake" codec (a= =3Drtpmap:111 fake/90000) which doesn't actually include any real data,= just padding.=C2=A0 Advantages: no CPU code to encode/decode.=C2=A0 No dea= ling with header extensions.=C2=A0 Clear indication if the other side wants= to do spinup (they can reject the codec if they don't want to).=C2=A0 = No encoding/decoding CPU use.

The offer would include it as a least-preferred codec to indicate warmup su= pport.=C2=A0 If answerer answers with fake as the accepted codec (and real = codecs following), it's a warmup answer.=C2=A0 Both sides will send and= receive fake data to spin up the congestion windows (and also the jitter b= uffers, etc).=C2=A0 On actual answer, the fake codec would be dropped (or d= ropped to bottom priority).=C2=A0 =C2=A0The answerer would start sending in= a real codec, which would work since the warmup answer would have included= that codec.=C2=A0 The offerer would see the incoming real-codec packets, a= nd decode them.=C2=A0 =C2=A0When the real answer arrives, it will show the = accepted codec has changed, and the offerer will install that answer and th= us and start sending (real) media.

We still need a way to tell the system at the answerer side "I want to= accept but it's a warm-up accept" (and perhaps if we want to spin= up congestion control or not while waiting), and a way to say on the offer= er side "I want to offer/use warmups".=C2=A0 For those API points= see the previous options from myself and Peter - or simply a way to say cr= eateAnswer of a warmup answer, and have that agree to all tracks with fake = codecs being primary.

I'll note that all of these methods would benefit from a mechanism to i= ndicate the desired bitrate targets for each fake track; for solutions that= use some sort of fake video input (canvas.captureStream/etc) it inherently= allows the application to define the size and framerate, which are the pri= mary knobs used by the browser for setting 'max total bitrate' for = the track.=C2=A0 =C2=A0You don't want the application to set the bandwi= dth directly, you want it to define the parameters of the video stream so t= he system can set "reasonable" limits for that resolution & s= ituation.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

=

_______________________________________________
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
--047d7bdc189a948ffc051b9ccb09-- From nobody Fri Jul 24 04:05:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8E51A8BB2 for ; Fri, 24 Jul 2015 04:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I2CJ3nyH0St for ; Fri, 24 Jul 2015 04:05:28 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id C6BC61A0461 for ; Fri, 24 Jul 2015 04:05:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0E0B97C3C75 for ; Fri, 24 Jul 2015 13:05:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WpboUcf1tN0 for ; Fri, 24 Jul 2015 13:05:26 +0200 (CEST) Received: from [IPv6:2001:67c:370:176:c5a7:9419:2feb:bfa3] (unknown [IPv6:2001:67c:370:176:c5a7:9419:2feb:bfa3]) by mork.alvestrand.no (Postfix) with ESMTPSA id E2C6C7C3C65 for ; Fri, 24 Jul 2015 13:05:25 +0200 (CEST) Message-ID: <55B21BF4.2050602@alvestrand.no> Date: Fri, 24 Jul 2015 13:05:24 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <55B1624D.4050908@jesup.org> <55B2138B.8070806@jesup.org> In-Reply-To: <55B2138B.8070806@jesup.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 11:05:30 -0000 I have added this bug: https://github.com/w3c/mediacapture-main/issues/221 to the W3C github in order to track creating "naked" MediaStreamTracks. Please comment there, or on public-mediacapture@w3.org. From nobody Fri Jul 24 04:20:45 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC821A903B for ; Fri, 24 Jul 2015 04:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOJM_4nfByu1 for ; Fri, 24 Jul 2015 04:20:38 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161A11A8A11 for ; Fri, 24 Jul 2015 04:20:38 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so13043404lbb.3 for ; Fri, 24 Jul 2015 04:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yVg0aVobtOnXzCUQwhmiuOy3to3LfF4ix/zZATrsRzg=; b=gA3s8gVXkhkT9BpBDX1DH7vaPEHAt/aPaoWRp4hl13M8CSrTUgCBIRnyT83Eq5oazL DKIq2wfCI+KhB0W68HVnWOYuRRgl1HNESKrgqf5+x8t9oA3/PYZJ8SmTT9cxU16pZzLw irockgoDEKT3I2NBaFICXVvtgfBwUk7J4FnQ7bvciNhfADbbO7S94sfTv97g8VdeBnif n+vXDlQsiCLC63z8KAx7DSZCLmWtluzB3BpBMuXcCsbiQFZwSPqlDfjUoEViNktc77bx ewoLZ1aLpkiwoJw+STbbaMI6ZyiNMQ6bKTFNVIuTU/MMX/Y+Mn/3CGQ01osJayE0Pe/s QVhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yVg0aVobtOnXzCUQwhmiuOy3to3LfF4ix/zZATrsRzg=; b=QweUoMN6GbLXzjIBkDE62SSDE44nRic297zXm39zd6YdH2whyG5r2V7SmbvPZnv7Np +p2gKG3CqvGaBQDB0sIHjh6UaTIbHLlFu5BW7Zd65DO+3LmbJZ/2RkxShttrGO0eJCj0 crSfR2Kngd+YtKbM+FKFmgIsX2H36wp336dbvONfhyVwSu1734Cq3r68uq8TqGybKq3N Nlxyy45H+/bKfpTGUTJHQG8+FK81ZWMZw+CKwbO2W2yxsYr5FRgPOpKxFXGvMQXrdymI Bd1kESG4LqDKu8iykPxS0IxuJjVgXSRzpawH2uSrsUx7RqfI2m3M1dAyJL8+xc2vI/mp Ncmg== X-Gm-Message-State: ALoCoQmmN+Bt5F9NGMsC198KWQ0rrr5j2yNNiGk79eatAFLPu8hcSPXH6fDyVYup0OwpiVdmPWYk X-Received: by 10.112.180.201 with SMTP id dq9mr13440641lbc.78.1437736836476; Fri, 24 Jul 2015 04:20:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.91.135 with HTTP; Fri, 24 Jul 2015 04:19:56 -0700 (PDT) In-Reply-To: <55B21BF4.2050602@alvestrand.no> References: <55B1624D.4050908@jesup.org> <55B2138B.8070806@jesup.org> <55B21BF4.2050602@alvestrand.no> From: Peter Thatcher Date: Fri, 24 Jul 2015 04:19:56 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11c345c06b69ca051b9d31ed Archived-At: Cc: "" Subject: Re: [rtcweb] Options for DTLS warmup and directionality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 11:20:39 -0000 --001a11c345c06b69ca051b9d31ed Content-Type: text/plain; charset=UTF-8 I sent an email to the W3C list initiating discussion about what API points we need. I think we should continue all discussion there. And I think the bug is more than just "Add naked tracks", and that title is already assuming a particular solution to the problem. On Fri, Jul 24, 2015 at 4:05 AM, Harald Alvestrand wrote: > I have added this bug: > > https://github.com/w3c/mediacapture-main/issues/221 > > to the W3C github in order to track creating "naked" MediaStreamTracks. > Please comment there, or on public-mediacapture@w3.org. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c345c06b69ca051b9d31ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I sent an email to the W3C list initiating discussion a= bout what API points we need.=C2=A0 I think we should continue all discussi= on there. =C2=A0

And I think the bug is more than just= "Add naked tracks", and that title is already assuming a particu= lar solution to the problem.

On Fri, Jul 24, 2015 at 4:05 AM, Harald Alvestrand <= span dir=3D"ltr"><harald@alvestrand.no> wrote:
I have added this bug:

https://github.com/w3c/mediacapture-main/issues/2= 21

to the W3C github in order to track creating "naked" MediaStreamT= racks.
Please comment there, or on p= ublic-mediacapture@w3.org.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a11c345c06b69ca051b9d31ed-- From nobody Fri Jul 24 05:29:41 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF4E1A00DF; Fri, 24 Jul 2015 05:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8qjaInqJbeQ; Fri, 24 Jul 2015 05:29:34 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126701A00F0; Fri, 24 Jul 2015 05:29:33 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t6OCTOBt005283 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Jul 2015 08:29:31 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t6OCTOBt005283 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1437740972; bh=x/ByLfSyh98yQuGiiPwmNOM2cZE=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=F9C8pvFxyUEIOkEyd0NdSqnQrbUGpIPutH9ZzAWYBF3tODkKOO9/c90DH/cQRkEoe gOWSua0N2jSIHHpvOnDQsME8SE9ZdEZPK6kTHzHCx3isskjSVEASTqE6KFsLjjQzi3 MN0i2y2K+0UHhLrnkI3PKz/ndkhkScirE7z36pfI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t6OCTOBt005283 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd55.lss.emc.com (RSA Interceptor); Fri, 24 Jul 2015 08:28:39 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t6OCT5Ms027856 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jul 2015 08:29:06 -0400 Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub05.corp.emc.com (128.222.70.202) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 24 Jul 2015 08:29:05 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.107]) by MXHUB206.corp.emc.com ([10.253.68.32]) with mapi id 14.03.0224.002; Fri, 24 Jul 2015 08:29:05 -0400 From: "Black, David" To: "Ruediger.Geib@telekom.de" , "karen.nielsen@tieto.com" Thread-Topic: [tsvwg] diffserv marking for rtcweb data channel Thread-Index: AdDGDE8nHxnEQ3oDRFOpcaYiGvd36g== Date: Fri, 24 Jul 2015 12:29:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.76.190.9] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936140151C2MX104CL02corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 12:29:40 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936140151C2MX104CL02corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PFdHIGNoYWlyIGhhdCBPRkY+DQoNCj4gQWxsIERTQ1BzLCB3aGljaCBoYXZlIG5vdCBiZWVuIG5l Z290aWF0ZWQgYmV0d2VlbiBhY2Nlc3MgYW5kIGludGVyY29ubmVjdGlvbiBhcmUgcG9zc2libHkg YmxlYWNoZWQsIGVzcGVjaWFsbHkgaWYgYSBuZXR3b3JrDQo+IHByb3ZpZGVyIG9wZXJhdGVzIFFv UyB3aXRoaW4gdGhlIG5ldHdvcmsuDQoNCuKAnHBvc3NpYmx54oCdIC0+IOKAnHByb2JhYmx54oCd IC0+IOKAnGFsbW9zdCBjZXJ0YWlubHnigJ0gZGVwZW5kaW5nIG9uIHRoZSBuZXR3b3JrIChZTU1W KS4NCg0KPiBJ4oCZZCBsaWtlIHRvIHJlYWQgYSBsaXR0bGUgbW9yZSBhYm91dCBob3cgV0VCcnRj IGZpZ3VyZXMgb3V0IHdoaWNoIFFvUyByZXNvdXJjZXMgYXJlIGNvbmZpZ3VyZWQgYW5kIHdoaWNo IG9mIHRoZXNlIGFyZSBhdmFpbGFibGUNCj4gZm9yIHN1Y2ggYSBmbG93IGF0IGFuIGFjY2VzcyB3 aGVuIHJlcXVpcmVkLiBIb3cgYW5kIHdoZXJlIGFyZSB0aGUgcmVzb3VyY2VzIGNvbnN1bWVkIGJ5 IGVhY2ggV0VScnRjIFBIQiBjb250cm9sbGVkIGFuZA0KPiBob3cgYXJlIHRoZXNlIGFsaWduZWQg d2l0aCB0aGUgUW9TIHJlc291cmNlcyBjb25zdW1lZCBieSBvdGhlciBzZXJ2aWNlcz8NCg0KVGhl IHNob3J0IFdlYiBSVEMgYW5zd2VyIHRvIGFsbCBvZiB0aGUgYWJvdmUg4oCcaXQgZG9lc27igJl0 IGRvIHRoYXTigJ0uICBUaGUgRFNDUHMgYXJlIGluIGVmZmVjdCBRb1Mgc2VydmljZSByZXF1ZXN0 cyB0aGF0IHRoZSB2YXJpb3VzIG5ldHdvcmtzIGludm9sdmVkIG1heSBkZWFsIHdpdGggYXMgdGhl eSB3aXNoLiAgQmxlYWNoaW5nIGlzIG9uZSBwb3NzaWJpbGl0eSAoaW4gZWZmZWN0IGFuIOKAnEkg ZG9u4oCZdCBkbyB0aGF04oCdIHJlc3BvbnNlIHRvIHRoZSByZXF1ZXN0KS4gIEV2ZW4gaW4gdGhh dCBjYXNlLCB0aGVyZSBtYXkgYmUgdmFsdWUgaW4gRFNDUCB1c2FnZSBmb3IgZm9yd2FyZGluZyBi eSBlcXVpcG1lbnQgYmV0d2VlbiB0aGUgYnJvd3NlciBhbmQgdGhlIGludGVyZmFjZSB0byB0aGUg SVNQ4oCZcyBuZXR3b3JrIChlLmcuLCByZXNpZGVudGlhbCByb3V0ZXIvTkFUL0FQIGJveCkuDQoN CkluIHNwaXRlIG9mIGFsbCBvZiB0aGUgYWJvdmUsIEkgaGF2ZSBiZWVuIHRvbGQgb2YgZ29vZCBl eHBlcmllbmNlcyB3aXRoIHVzZSBvZiBDUzIgZm9yIGdhbWluZyBhbmQgQ1MxIGZvciBsb3dlciBl ZmZvcnQgKGxlc3MgdGhhbiBiZXN0IGVmZm9ydCksIHBsdXMgRUYgdXNlIGZvciBnYW1pbmcgd2Fz IG1lbnRpb25lZCBpbiB0aGUgdHN2d2cgbWVldGluZyB5ZXN0ZXJkYXkuDQoNClRoaXMgaXMgbm90 IHRoZSBmaXJzdCB0aW1lIEnigJl2ZSBoZWFyZCBhIHJlcXVlc3QgZm9yIGEg4oCcd2hhdCBRb1Mg c2VydmljZXMgYXJlIGF2YWlsYWJsZSB2aWEgd2hpY2ggRFNDUHM/4oCdIGludGVyZmFjZS9wcm90 b2NvbC4gIEkgZG9u4oCZdCBrbm93IG9mIG9uZSwgYW5kIEnigJltIG5vdCBzdXJlIGhvdyB0byBp bmNlbnRpdml6ZSBkZXBsb3ltZW50IGlmIHdlIGRlc2lnbmVkIG9uZS4NCg0KV2hhdCBpcyBsaWtl bHkgdG8gaGFwcGVuIGlzIHRoYXQgaWYgY2VydGFpbiB0eXBlcyBvZiB0cmFmZmljIGZhdm9yIHNw ZWNpZmljIERTQ1BzLCB0aGVuIG9wZXJhdG9ycyB3aG8gd2FudCB0byBpbXByb3ZlIHRoZSB1c2Vy IGV4cGVyaWVuY2Ugb2YgdGhvc2Ugd2hvIHNlbmQvcmVjZWl2ZSBzdWNoIHRyYWZmaWMgbWF5IHB1 dCBpbiBRb1MgbWVjaGFuaXNtcyBmb3Igc3VjaCB0cmFmZmljIGtleWVkIGJ5IHRob3NlIERTQ1Bz IGF0IG5ldHdvcmsgaW5ncmVzcy4gIE9UT0gsIGEg4oCcdHJhZ2VkeSBvZiB0aGUgY29tbW9uc+KA nSBpcyBwb3NzaWJsZSBoZXJlLCBlLmcuLCB0aGUgc3RvcnkgaW4gdHN2d2cgYWJvdXQgaG93IGEg bG90IG9mIG5vbi12b2ljZSB0cmFmZmljIHNob3dpbmcgdXAgbWFya2VkIGFzIGlmIGl0IHdlcmUg dm9pY2UgcmVzdWx0ZWQgaW4gdGhlIG5ldHdvcmsgb3BlcmF0b3IgcmVtb3ZpbmcgdGhhdCBzcGVj aWFsIHRyZWF0bWVudCBvZiAocmVzaWRlbnRpYWwsIEkgcHJlc3VtZSkgdm9pY2UgdHJhZmZpYy4N Cg0KPC9XRyBjaGFpciBoYXQgT0ZGPg0KDQpUaGFua3MsDQotLURhdmlkDQoNCkZyb206IHRzdndn IFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJ1ZWRpZ2VyLkdl aWJAdGVsZWtvbS5kZQ0KU2VudDogRnJpZGF5LCBKdWx5IDI0LCAyMDE1IDU6MzMgQU0NClRvOiBr YXJlbi5uaWVsc2VuQHRpZXRvLmNvbQ0KQ2M6IE1pY2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2Vu LmRlOyBydGN3ZWJAaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnOyBmbHVmZnlAaWlpLmNhDQpTdWJq ZWN0OiBSZTogW3RzdndnXSBkaWZmc2VydiBtYXJraW5nIGZvciBydGN3YiBkYXRhIGNoYW5uZWwN Cg0KSGkgS2FyZW4sDQoNClFvUyAgbmVlZHMgdG8gYmUgY29tbWVyY2lhbGx5IG5lZ290aWF0ZWQg YXQgaW50ZXJjb25uZWN0aW9uLiBJZiBRb1Mgc2hvdWxkIGJlIGF2YWlsYWJsZSBhdCBhIGNvbnN1 bWVyIGFjY2VzcywgdGhlIGNvbnN1bWVyIGRpdmlzaW9uIG9mIGEgY29tcGFueSBtdXN0IGJlIGlu dm9sdmVkIGluIGFkZGl0aW9uIGFzIHdlbGwgYXMgdGhlIHRlY2huaWNhbCBzdGFmZiBzZXR0aW5n IHVwIGFuZCBtYWludGFpbmluZyB0ZWNobmljYWwgY29uZmlndXJhdGlvbnMuIDExIFBIQnMgZm9y IGEgc2luZ2xlIGNvbnN1bWVyIHNlcnZpY2UgYXJlIGEgY2hhbGxlbmdpbmcgcmVxdWlyZW1lbnQu DQoNCkFsbCBEU0NQcywgd2hpY2ggaGF2ZSBub3QgYmVlbiBuZWdvdGlhdGVkIGJldHdlZW4gYWNj ZXNzIGFuZCBpbnRlcmNvbm5lY3Rpb24gYXJlIHBvc3NpYmx5IGJsZWFjaGVkLCBlc3BlY2lhbGx5 IGlmIGEgbmV0d29yayBwcm92aWRlciBvcGVyYXRlcyBRb1Mgd2l0aGluIHRoZSBuZXR3b3JrLg0K DQpRb1MgdG8gbWUgbWVhbnMgb3ZlcnByb3Zpc2lvbmluZyB0byBlbnN1cmUgdHJhbnNwb3J0IGZy ZWUgb2YgY29uZ2VzdGlvbi4gSWYgSSBzZWUgMTEgUEhCcyBmb3IgYSBzaW5nbGUgZmxvdywgSeKA mW0gbm90IHN1cmUgaWYgdGhpcyBhc3N1bWVzIG1vcmUgdGhhbiBDb1MgKGRyb3AgbWUgbGFzdCku IEnigJlkIGxpa2UgdG8gcmVhZCBhIGxpdHRsZSBtb3JlIGFib3V0IGhvdyBXRUJydGMgZmlndXJl cyBvdXQgd2hpY2ggUW9TIHJlc291cmNlcyBhcmUgY29uZmlndXJlZCBhbmQgd2hpY2ggb2YgdGhl c2UgYXJlIGF2YWlsYWJsZSBmb3Igc3VjaCBhIGZsb3cgYXQgYW4gYWNjZXNzIHdoZW4gcmVxdWly ZWQuIEhvdyBhbmQgd2hlcmUgYXJlIHRoZSByZXNvdXJjZXMgY29uc3VtZWQgYnkgZWFjaCBXRVJy dGMgUEhCIGNvbnRyb2xsZWQgYW5kIGhvdyBhcmUgdGhlc2UgYWxpZ25lZCB3aXRoIHRoZSBRb1Mg cmVzb3VyY2VzIGNvbnN1bWVkIGJ5IG90aGVyIHNlcnZpY2VzPw0KDQpSZWdhcmRzLA0KDQpSdWVk aWdlcg0KDQpWb246IEthcmVuIEVsaXNhYmV0aCBFZ2VkZSBOaWVsc2VuIFttYWlsdG86a2FyZW4u bmllbHNlbkB0aWV0by5jb21dDQpHZXNlbmRldDogRnJlaXRhZywgMjQuIEp1bGkgMjAxNSAxMDoy OA0KQW46IEdlaWIsIFLDvGRpZ2VyDQpDYzogcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJA aWV0Zi5vcmc+OyB0c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+OyBNaWNoYWVs IFR1ZXhlbjsgZmx1ZmZ5QGlpaS5jYTxtYWlsdG86Zmx1ZmZ5QGlpaS5jYT4NCkJldHJlZmY6IFJF OiBbdHN2d2ddIGRpZmZzZXJ2IG1hcmtpbmcgZm9yIHJ0Y3diIGRhdGEgY2hhbm5lbA0KDQpIaSBS dWVkaWdlciwNCg0KVGhhbmtzIGEgbG90Lg0KDQpTbyBJIHRoaW5rIHRoYXQgeW914oCZcmUgc2F5 aW5nIHRoYXQgZXZlbiBpZiBvbmUgbWFkZSBzdXJlIHRoYXQgZGlmZmVyZW50IGRpZmYgc2VydiBt YXJraW5ncyB3ZXJlDQpzcGxpdCBvbiBkaWZmZXJlbnQgNS10dXBsZXMsIHRoaXMgc2V0dGluZyBs aWtlbHkgd291bGQgYmUgYmxlYWNoZWQgYXQgdGhlIG5ldHdvcmsuDQoNCklzIHRoYXQgY29ycmVj dGx5IHVuZGVyc3Rvb2QgPw0KDQpJZiBzbywgdGhlbiAoaXQgc291bmRzIHRvIG1lIOKAkyBub3Qg a25vd2luZyB0b28gbXVjaCBhYm91dCB0aGlzKSB0aGF0IGZyb20gYSBjb3VwbGluZyBjb25nZXN0 aW9uIGNvbnRyb2wgcGVyc3BlY3RpdmUgaXQNCndvdWxkIGJlIHByZWZlcmFibGUgdG8gIHVzZSBT Q1RQIHNjaGVkdWxpbmcgcHJpb3JpdGl6YXRpb24gKHdpdGhpbiBvbmUgYW5kIHRoZSBzYW1lIGFz c29jaWF0aW9uKSBmb3IgZmluZSBncmFudWxhciBkaWZmZXJlbnRpYXRpb24gaW4gYmV0d2Vlbg0K bXVsdGlwbGUgZGF0YSBjaGFubmVscyBpbiBiZXR3ZWVuIHRoZSBzYW1lIGVuZC1wb2ludHMgcmF0 aGVyIHRoYW4gZGlmZmVyZW50aWF0aW9uIGJ5IG1lYW5zIG9mIGRpZmYgc2VydiBtYXJraW5nLg0K DQpXaGVuL2lmIG9uZSBnZXQgYSBtb3JlIGNvbnNpc3RlbnQgYW5kIGZvcmNlZnVsIEVDTiBvcGVy YXRpb24gaW4gQVFNcyBhbmQgU0NUUCBlbmQtcG9pbnRzLCBwZXJoYXBzIHRoZSBjb3VwbGluZyBj b25nZXN0aW9uDQpwcmluY2lwbGVzIGFjaGlldmVkIGJ5IG1lYW5zIG9mIHNjdHAgc3RyZWFtIHNj aGVkdWxpbmcgZ2V0IHRvIGJlIGxlc3MgaW1wb3J0YW50Lg0KT24gdGhlIG90aGVyIGhhbmQsIGFn YWluIGFzIHNhaWQgYmVmb3JlLCBoYXZpbmcgdGhlIG9uZSBhbmQgdGhlIHNhbWUsIG9yIG11bHRp cGxlLCBmbG93IGNvbnRyb2wgKHJlY2VpdmVyIGJ1ZmZlcikgY29udGV4dHMgbWF5IGJlDQphIHN0 cmVuZ3RoIChzaW1wbGljaXR5KSBvciBhIHdlYWtuZXNzLg0KDQpCUiwgS2FyZW4NCg0KRnJvbTog UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPG1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGU+ IFttYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPG1haWx0bzpSdWVkaWdlci5HZWliQHRl bGVrb20uZGU+XQ0KU2VudDogRnJpZGF5LCBKdWx5IDI0LCAyMDE1IDEwOjAwIEFNDQpUbzoga2Fy ZW4ubmllbHNlbkB0aWV0by5jb208bWFpbHRvOmthcmVuLm5pZWxzZW5AdGlldG8uY29tPg0KQ2M6 IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgdHN2d2dAaWV0Zi5vcmc8 bWFpbHRvOnRzdndnQGlldGYub3JnPg0KU3ViamVjdDogQVc6IFt0c3Z3Z10gZGlmZnNlcnYgbWFy a2luZyBmb3IgcnRjd2IgZGF0YSBjaGFubmVsDQoNCkthcmVuLA0KDQogICAgICBGaW5hbGx5IHRo ZXJlIHdhcyBhIGNvbW1lbnQgYXQgdGhlIHRzdndnIG1lZXRpbmcgdGhhdCB0aGUgc2FtZSA1LXR1 cGxlIHdpdGgNCiAgICAgICBkaWZmZXJlbnQgZGlmZnNlcnYgbWFya2luZ3Mgd291bGQgbm90IGdl dCB0aHJvdWdoIHRoZSBuZXR3b3JrIOKAkyBpZiB0aGF0IGdlbmVyYWxseQ0KICAgICAgIGlzIGNv cnJlY3QsICB0aGVuIHRoZSBzb2x1dGlvbiBpcyB2ZXJ5IGVhc3k6IG9uZSBNVVNUIHVzZSBkaWZm ZXJlbnQgYXNzb2NpYXRpb25zIHRvDQogICAgICAgZ2V0IHBvcnQgKDUtdHVwbGUpIGRpZmZlcmVu dGlhdGlvbi4NCiAgICAgICBJIHRoaW5rIHRoYXQgaWYgdGhpcyBpcyBjb3JyZWN0LCBvbmUgYWxz byB3YW50cyB0byBhc2sgd2hhdCBoYXBwZW5zIGlmIHRoZSBkaWZmc2VydiBpcw0KICAgICAgIGNo YW5nZWQgZm9yIHRoZSBzYW1lIDUtdHVwbGUg4oCTIGkuZS4sIGlzIHRoZSBuZXR3b3JrIHJvYnVz dCB0byB0aGlzIGNoYW5nZSBldmVuIGlmDQogICAgICAgaXQgaXMgbm90IHJvYnVzdCB0byBjb25j dXJyZW50IHVzYWdlIG9mIGRpZmZlcmVudCBtYXJraW5ncyBmb3IgdGhlIHNhbWUgNS10dXBsZS4N Cg0KVGFsa2luZyBhYm91dCB0aGUgcG9saWNpZXMgb2YgdGhlIGNvbXBhbnkgSSB3b3JrIGZvciBv bmx5Og0KDQpQb3NzaWJpbGl0aWVzIHRvIGVuZm9yY2UgUW9TIHBvbGljaWVzIGF0IGEgcHJvdmlk ZXIgQlJBUyBvciBCTkcgdGVybWluYXRpbmcgd2lyZWQNCmNvbnN1bWVyIGFjY2Vzc2VzIGFyZSBs aW1pdGVkLiBRb1MgcG9saWNpZXMgYmFzZWQgb24gZnVsbCA1IHR1cGxlIGFyZSB2ZXJ5DQpjb25z ZXJ2YXRpdmUgYW5kIGhhcmQgdG8gbWFpbnRhaW4uIEkgd291bGRu4oCZdCBleHBlY3QgZnVsbCA1 IHR1cGxlIGFzIGJhc2lzIGZvciBhIFFvUw0KcG9saWN5IHRoZW4uIFRydXN0IGluIHRoZSBjb3Jy ZWN0IGluZm9ybWF0aW9uIG9uIHdoaWNoIGEgQlJBUy9CTkcgY2FuDQpiYXNlIFFvUyBjbGFzc2lm aWNhdGlvbiBpcyBhbiBpbXBvcnRhbnQgaXNzdWUuIEluIGFueSBjYXNlLCBJ4oCZZCBub3QgZXhw ZWN0DQptb3JlIHRoYW4gb25lIERTQ1AgaXMgYXNzaWduZWQgYmFzZWQgb24gc3VjaCBhIHBvbGlj eSBmb3IgdGhlIHRpbWUNCmJlaW5nLiBJ4oCZbSBub3QgYXdhcmUgb2YgYW55IGFjdHVhbCByZXF1 aXJlbWVudCB0byBzdXBwb3J0IGUuZy4gYW4gQUZuDQpjbGFzcyBieSBhbGwgdGhyZWUgUEhCcy4N Cg0KQXQgaW50ZXJjb25uZWN0aW9uIHBvaW50cywgYW55IHVuZXhwZWN0ZWQgRFNDUCBpcyBibGVh Y2hlZC4gVGhpcyBtdXN0DQpiZSBkb25lIHRvIHByb3RlY3QgYmFja2JvbmUgUW9TIHByb2R1Y3Rp b24uIFFvUyB0cmFuc3BvcnQgY2FuIGJlDQpuZWdvdGlhdGVkIGZvciBhIHNldCBvZiBkZWZpbmVk IERTQ1BzLg0KDQpBIHN0dWR5IG9mIHRoZSBFVSBmb3VuZCBEUEkgdG8gYmUgbW9yZSBjb21tb24g aW4gd2lyZWxlc3MgY29tbXVuaWNhdGlvbiB0aGFuIGluIHdpcmVkIGNvbW11bmljYXRpb24uIEni gJlkIG5vdCBleHBlY3QgdGhlIFFvUyBwb2xpY2llcyBpbiB0aGF0IGFyZWEgdG8gYmUgbW9yZSBs aWJlcmFsIHRoYW4gZm9yIGZpeGVkIGFjY2VzcyBuZXR3b3JrcyBmb3IgdGhlIHRpbWUgYmVpbmcu DQoNClJlZ2FyZHMsDQoNClJ1ZWRpZ2VyDQoNCg0KDQoNCg== --_000_CE03DB3D7B45C245BCA0D24327794936140151C2MX104CL02corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpwLlNwcmVjaGJsYXNl bnRleHQsIGxpLlNwcmVjaGJsYXNlbnRleHQsIGRpdi5TcHJlY2hibGFzZW50ZXh0DQoJe21zby1z dHlsZS1uYW1lOlNwcmVjaGJsYXNlbnRleHQ7DQoJbXNvLXN0eWxlLWxpbms6IlNwcmVjaGJsYXNl bnRleHQgWmNobiI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNw YW4uU3ByZWNoYmxhc2VudGV4dFpjaG4NCgl7bXNvLXN0eWxlLW5hbWU6IlNwcmVjaGJsYXNlbnRl eHQgWmNobiI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOlNwcmVj aGJsYXNlbnRleHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u RW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Ng0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxl Om5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo4NS4wNXB0IDU2Ljdw dCA4NS4wNXB0IDU2LjdwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jmx0O1dHIGNoYWlyIGhhdCBPRkYmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mZ3Q7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFs bCBEU0NQcywgd2hpY2ggaGF2ZSBub3QgYmVlbiBuZWdvdGlhdGVkIGJldHdlZW4gYWNjZXNzIGFu ZCBpbnRlcmNvbm5lY3Rpb24gYXJlIHBvc3NpYmx5IGJsZWFjaGVkLCBlc3BlY2lhbGx5IGlmIGEg bmV0d29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7IHByb3ZpZGVyIG9wZXJhdGVzIFFvUyB3aXRoaW4g dGhlIG5ldHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj7igJxwb3NzaWJseeKAnSAtJmd0 OyDigJxwcm9iYWJseeKAnSAtJmd0OyDigJxhbG1vc3QgY2VydGFpbmx54oCdIGRlcGVuZGluZyBv biB0aGUgbmV0d29yayAoWU1NVikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4gSeKAmWQgbGlrZSB0byByZWFkIGEgbGl0dGxl IG1vcmUgYWJvdXQgaG93IFdFQnJ0YyBmaWd1cmVzIG91dCB3aGljaCBRb1MgcmVzb3VyY2VzIGFy ZSBjb25maWd1cmVkIGFuZCB3aGljaCBvZiB0aGVzZSBhcmUgYXZhaWxhYmxlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZndDsgZm9yIHN1Y2ggYSBmbG93IGF0IGFuIGFjY2VzcyB3aGVuIHJlcXVpcmVkLiBIb3cg YW5kIHdoZXJlIGFyZSB0aGUgcmVzb3VyY2VzIGNvbnN1bWVkIGJ5IGVhY2ggV0VScnRjIFBIQiBj b250cm9sbGVkIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7IGhvdyBhcmUgdGhlc2UgYWxpZ25lZCB3 aXRoIHRoZSBRb1MgcmVzb3VyY2VzIGNvbnN1bWVkIGJ5IG90aGVyIHNlcnZpY2VzPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+VGhlIHNob3J0IFdlYiBSVEMgYW5zd2VyIHRvIGFsbCBvZiB0aGUg YWJvdmUg4oCcaXQgZG9lc27igJl0IGRvIHRoYXTigJ0uJm5ic3A7IFRoZSBEU0NQcyBhcmUgaW4g ZWZmZWN0IFFvUyBzZXJ2aWNlIHJlcXVlc3RzIHRoYXQgdGhlIHZhcmlvdXMgbmV0d29ya3MgaW52 b2x2ZWQgbWF5IGRlYWwgd2l0aCBhcyB0aGV5DQogd2lzaC4mbmJzcDsgQmxlYWNoaW5nIGlzIG9u ZSBwb3NzaWJpbGl0eSAoaW4gZWZmZWN0IGFuIOKAnEkgZG9u4oCZdCBkbyB0aGF04oCdIHJlc3Bv bnNlIHRvIHRoZSByZXF1ZXN0KS4mbmJzcDsgRXZlbiBpbiB0aGF0IGNhc2UsIHRoZXJlIG1heSBi ZSB2YWx1ZSBpbiBEU0NQIHVzYWdlIGZvciBmb3J3YXJkaW5nIGJ5IGVxdWlwbWVudCBiZXR3ZWVu IHRoZSBicm93c2VyIGFuZCB0aGUgaW50ZXJmYWNlIHRvIHRoZSBJU1DigJlzIG5ldHdvcmsgKGUu Zy4sIHJlc2lkZW50aWFsIHJvdXRlci9OQVQvQVANCiBib3gpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+SW4gc3BpdGUgb2YgYWxsIG9mIHRoZSBhYm92ZSwgSSBoYXZlIGJlZW4gdG9sZCBvZiBn b29kIGV4cGVyaWVuY2VzIHdpdGggdXNlIG9mIENTMiBmb3IgZ2FtaW5nIGFuZCBDUzEgZm9yIGxv d2VyIGVmZm9ydCAobGVzcyB0aGFuIGJlc3QgZWZmb3J0KSwgcGx1cyBFRiB1c2UgZm9yIGdhbWlu Zw0KIHdhcyBtZW50aW9uZWQgaW4gdGhlIHRzdndnIG1lZXRpbmcgeWVzdGVyZGF5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+VGhpcyBpcyBub3QgdGhlIGZpcnN0IHRpbWUgSeKAmXZlIGhlYXJk IGEgcmVxdWVzdCBmb3IgYSDigJx3aGF0IFFvUyBzZXJ2aWNlcyBhcmUgYXZhaWxhYmxlIHZpYSB3 aGljaCBEU0NQcz/igJ0gaW50ZXJmYWNlL3Byb3RvY29sLiZuYnNwOyBJIGRvbuKAmXQga25vdyBv ZiBvbmUsIGFuZCBJ4oCZbSBub3Qgc3VyZSBob3cNCiB0byBpbmNlbnRpdml6ZSBkZXBsb3ltZW50 IGlmIHdlIGRlc2lnbmVkIG9uZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPldoYXQgaXMgbGlr ZWx5IHRvIGhhcHBlbiBpcyB0aGF0IGlmIGNlcnRhaW4gdHlwZXMgb2YgdHJhZmZpYyBmYXZvciBz cGVjaWZpYyBEU0NQcywgdGhlbiBvcGVyYXRvcnMgd2hvIHdhbnQgdG8gaW1wcm92ZSB0aGUgdXNl ciBleHBlcmllbmNlIG9mIHRob3NlIHdobyBzZW5kL3JlY2VpdmUgc3VjaA0KIHRyYWZmaWMgbWF5 IHB1dCBpbiBRb1MgbWVjaGFuaXNtcyBmb3Igc3VjaCB0cmFmZmljIGtleWVkIGJ5IHRob3NlIERT Q1BzIGF0IG5ldHdvcmsgaW5ncmVzcy4mbmJzcDsgT1RPSCwgYSDigJx0cmFnZWR5IG9mIHRoZSBj b21tb25z4oCdIGlzIHBvc3NpYmxlIGhlcmUsIGUuZy4sIHRoZSBzdG9yeSBpbiB0c3Z3ZyBhYm91 dCBob3cgYSBsb3Qgb2Ygbm9uLXZvaWNlIHRyYWZmaWMgc2hvd2luZyB1cCBtYXJrZWQgYXMgaWYg aXQgd2VyZSB2b2ljZSByZXN1bHRlZCBpbg0KIHRoZSBuZXR3b3JrIG9wZXJhdG9yIHJlbW92aW5n IHRoYXQgc3BlY2lhbCB0cmVhdG1lbnQgb2YgKHJlc2lkZW50aWFsLCBJIHByZXN1bWUpIHZvaWNl IHRyYWZmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbHQ7L1dHIGNoYWlyIGhhdCBPRkYm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8YnI+DQot LURhdmlkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1 bHkgMjQsIDIwMTUgNTozMyBBTTxicj4NCjxiPlRvOjwvYj4ga2FyZW4ubmllbHNlbkB0aWV0by5j b208YnI+DQo8Yj5DYzo8L2I+IE1pY2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2VuLmRlOyBydGN3 ZWJAaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnOyBmbHVmZnlAaWlpLmNhPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdHN2d2ddIGRpZmZzZXJ2IG1hcmtpbmcgZm9yIHJ0Y3diIGRhdGEgY2hhbm5l bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkRFIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgS2FyZW4sPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UW9TJm5ic3A7IG5lZWRzIHRvIGJlIGNvbW1l cmNpYWxseSBuZWdvdGlhdGVkIGF0IGludGVyY29ubmVjdGlvbi4gSWYgUW9TIHNob3VsZCBiZSBh dmFpbGFibGUgYXQgYSBjb25zdW1lciBhY2Nlc3MsIHRoZSBjb25zdW1lciBkaXZpc2lvbiBvZiBh IGNvbXBhbnkgbXVzdCBiZSBpbnZvbHZlZCBpbiBhZGRpdGlvbiBhcyB3ZWxsIGFzIHRoZSB0ZWNo bmljYWwgc3RhZmYgc2V0dGluZw0KIHVwIGFuZCBtYWludGFpbmluZyB0ZWNobmljYWwgY29uZmln dXJhdGlvbnMuIDExIFBIQnMgZm9yIGEgc2luZ2xlIGNvbnN1bWVyIHNlcnZpY2UgYXJlIGEgY2hh bGxlbmdpbmcgcmVxdWlyZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5BbGwgRFNDUHMsIHdoaWNoIGhhdmUgbm90IGJlZW4gbmVnb3RpYXRlZCBiZXR3ZWVuIGFjY2Vz cyBhbmQgaW50ZXJjb25uZWN0aW9uIGFyZSBwb3NzaWJseSBibGVhY2hlZCwgZXNwZWNpYWxseSBp ZiBhIG5ldHdvcmsgcHJvdmlkZXIgb3BlcmF0ZXMgUW9TIHdpdGhpbiB0aGUgbmV0d29yay48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlFvUyB0byBtZSBtZWFucyBvdmVycHJv dmlzaW9uaW5nIHRvIGVuc3VyZSB0cmFuc3BvcnQgZnJlZSBvZiBjb25nZXN0aW9uLiBJZiBJIHNl ZSAxMSBQSEJzIGZvciBhIHNpbmdsZSBmbG93LCBJ4oCZbSBub3Qgc3VyZSBpZiB0aGlzIGFzc3Vt ZXMgbW9yZSB0aGFuIENvUyAoZHJvcCBtZSBsYXN0KS4gSeKAmWQgbGlrZSB0byByZWFkIGEgbGl0 dGxlIG1vcmUgYWJvdXQgaG93DQogV0VCcnRjIGZpZ3VyZXMgb3V0IHdoaWNoIFFvUyByZXNvdXJj ZXMgYXJlIGNvbmZpZ3VyZWQgYW5kIHdoaWNoIG9mIHRoZXNlIGFyZSBhdmFpbGFibGUgZm9yIHN1 Y2ggYSBmbG93IGF0IGFuIGFjY2VzcyB3aGVuIHJlcXVpcmVkLiBIb3cgYW5kIHdoZXJlIGFyZSB0 aGUgcmVzb3VyY2VzIGNvbnN1bWVkIGJ5IGVhY2ggV0VScnRjIFBIQiBjb250cm9sbGVkIGFuZCBo b3cgYXJlIHRoZXNlIGFsaWduZWQgd2l0aCB0aGUgUW9TIHJlc291cmNlcyBjb25zdW1lZA0KIGJ5 IG90aGVyIHNlcnZpY2VzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJ1ZWRpZ2VyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Vm9uOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBL YXJlbiBFbGlzYWJldGggRWdlZGUgTmllbHNlbiBbPGEgaHJlZj0ibWFpbHRvOmthcmVuLm5pZWxz ZW5AdGlldG8uY29tIj5tYWlsdG86a2FyZW4ubmllbHNlbkB0aWV0by5jb208L2E+XQ0KPGJyPg0K PGI+R2VzZW5kZXQ6PC9iPiBGcmVpdGFnLCAyNC4gSnVsaSAyMDE1IDEwOjI4PGJyPg0KPGI+QW46 PC9iPiBHZWliLCA8L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5S w7xkaWdlcjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+ cnRjd2ViQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnRzdndnQGlldGYub3JnIj4NCnRz dndnQGlldGYub3JnPC9hPjsgTWljaGFlbCBUdWV4ZW47IDxhIGhyZWY9Im1haWx0bzpmbHVmZnlA aWlpLmNhIj5mbHVmZnlAaWlpLmNhPC9hPjxicj4NCjxiPkJldHJlZmY6PC9iPiBSRTogW3Rzdndn XSBkaWZmc2VydiBtYXJraW5nIGZvciBydGN3YiBkYXRhIGNoYW5uZWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i REUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBSdWVkaWdlciw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyBhIGxvdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlNvIEkgdGhpbmsgdGhhdCB5b3XigJlyZSBzYXlpbmcgdGhhdCBldmVuIGlm IG9uZSBtYWRlIHN1cmUgdGhhdCBkaWZmZXJlbnQgZGlmZiBzZXJ2IG1hcmtpbmdzIHdlcmU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+c3BsaXQgb24gZGlmZmVyZW50IDUtdHVwbGVzLCB0aGlzIHNldHRpbmcgbGlr ZWx5IHdvdWxkIGJlIGJsZWFjaGVkIGF0IHRoZSBuZXR3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SXMgdGhhdCBjb3JyZWN0bHkgdW5kZXJzdG9vZCA/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZiBzbywgdGhlbiAoaXQgc291bmRzIHRvIG1l IOKAkyBub3Qga25vd2luZyB0b28gbXVjaCBhYm91dCB0aGlzKSB0aGF0IGZyb20gYSBjb3VwbGlu ZyBjb25nZXN0aW9uIGNvbnRyb2wgcGVyc3BlY3RpdmUgaXQNCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj53b3Vs ZCBiZSBwcmVmZXJhYmxlIHRvJm5ic3A7IHVzZSBTQ1RQIHNjaGVkdWxpbmcgcHJpb3JpdGl6YXRp b24gKHdpdGhpbiBvbmUgYW5kIHRoZSBzYW1lIGFzc29jaWF0aW9uKSBmb3IgZmluZSBncmFudWxh ciBkaWZmZXJlbnRpYXRpb24gaW4gYmV0d2Vlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5tdWx0aXBsZSBkYXRh IGNoYW5uZWxzIGluIGJldHdlZW4gdGhlIHNhbWUgZW5kLXBvaW50cyByYXRoZXIgdGhhbiBkaWZm ZXJlbnRpYXRpb24gYnkgbWVhbnMgb2YgZGlmZiBzZXJ2IG1hcmtpbmcuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XaGVuL2lmIG9uZSBnZXQgYSBtb3JlIGNvbnNpc3RlbnQg YW5kIGZvcmNlZnVsIEVDTiBvcGVyYXRpb24gaW4gQVFNcyBhbmQgU0NUUCBlbmQtcG9pbnRzLCBw ZXJoYXBzIHRoZSBjb3VwbGluZyBjb25nZXN0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPnByaW5jaXBsZXMg YWNoaWV2ZWQgYnkgbWVhbnMgb2Ygc2N0cCBzdHJlYW0gc2NoZWR1bGluZyBnZXQgdG8gYmUgbGVz cyBpbXBvcnRhbnQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+T24gdGhlIG90aGVyIGhhbmQsIGFnYWluIGFz IHNhaWQgYmVmb3JlLCBoYXZpbmcgdGhlIG9uZSBhbmQgdGhlIHNhbWUsIG9yIG11bHRpcGxlLCBm bG93IGNvbnRyb2wgKHJlY2VpdmVyIGJ1ZmZlcikgY29udGV4dHMgbWF5IGJlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPmEgc3RyZW5ndGggKHNpbXBsaWNpdHkpIG9yIGEgd2Vha25lc3MuICZuYnNwOyZuYnNwOyZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QlIsIEthcmVuIDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOlJ1ZWRpZ2VyLkdlaWJA dGVsZWtvbS5kZSI+UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPC9hPiBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGUiPlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5k ZTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDI0LCAyMDE1IDEwOjAwIEFN PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86a2FyZW4ubmllbHNlbkB0aWV0by5jb20i PmthcmVuLm5pZWxzZW5AdGlldG8uY29tPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRv OnRzdndnQGlldGYub3JnIj4NCnRzdndnQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBBVzogW3RzdndnXSBkaWZmc2VydiBtYXJraW5nIGZvciBydGN3YiBkYXRhIGNoYW5uZWw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+S2FyZW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjwvYj5GaW5hbGx5IHRoZXJlIHdhcyBhIGNvbW1lbnQgYXQgdGhlIHRzdndnIG1lZXRpbmcgdGhh dCB0aGUgc2FtZSA1LXR1cGxlIHdpdGgNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj5kaWZmZXJlbnQgZGlmZnNlcnYgbWFya2luZ3Mgd291 bGQgbm90IGdldDxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj50aHJvdWdoIHRo ZSBuZXR3b3JrIOKAkyBpZiB0aGF0IGdlbmVyYWxseSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+aXMgY29ycmVjdCwgJm5ic3A7dGhlbiB0 aGUgc29sdXRpb24gaXMgdmVyeSBlYXN5OiBvbmUgTVVTVCB1c2UgZGlmZmVyZW50IGFzc29jaWF0 aW9ucyB0bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PC9zcGFuPmdldCBwb3J0ICg1LXR1cGxlKSBkaWZmZXJlbnRpYXRpb24uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5JIHRoaW5rIHRoYXQgaWYg dGhpcyBpcyBjb3JyZWN0LCBvbmUgYWxzbyB3YW50cyB0byBhc2sgd2hhdCBoYXBwZW5zIGlmIHRo ZSBkaWZmc2VydiBpcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PC9zcGFuPmNoYW5nZWQgZm9yIHRoZSBzYW1lIDUtdHVwbGUg4oCTIGkuZS4sIGlz IHRoZSBuZXR3b3JrIHJvYnVzdCB0byB0aGlzIGNoYW5nZSBldmVuIGlmDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+aXQgaXMgbm90IHJv YnVzdCB0byBjb25jdXJyZW50IHVzYWdlIG9mIGRpZmZlcmVudCBtYXJraW5ncyBmb3IgdGhlIHNh bWUgNS10dXBsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPlRhbGtpbmcgYWJvdXQgdGhlIHBvbGljaWVzIG9mIHRoZSBjb21wYW55IEkgd29yayBm b3Igb25seTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlBvc3NpYmlsaXRp ZXMgdG8gZW5mb3JjZSBRb1MgcG9saWNpZXMgYXQgYSBwcm92aWRlciBCUkFTIG9yPC9zcGFuPiZu YnNwOzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CTkcgdGVybWluYXRpbmcgd2lyZWQNCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5jb25zdW1lciBhY2Nlc3NlcyBhcmUgbGltaXRlZC4gUW9TIHBvbGljaWVz IGJhc2VkIG9uIGZ1bGwgNSB0dXBsZSBhcmUgdmVyeQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmNvbnNlcnZh dGl2ZSBhbmQgaGFyZCB0byBtYWludGFpbi4gSSB3b3VsZG7igJl0IGV4cGVjdCBmdWxsIDUgdHVw bGUgYXMgYmFzaXMgZm9yIGEgUW9TDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+cG9saWN5IHRoZW4uIFRydXN0 IGluIHRoZSBjb3JyZWN0IGluZm9ybWF0aW9uIG9uIHdoaWNoIGEgQlJBUy9CTkcgY2FuDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+YmFzZSBRb1MgY2xhc3NpZmljYXRpb24gaXMgYW4gaW1wb3J0YW50IGlzc3Vl LiBJbiBhbnkgY2FzZSwgSeKAmWQgbm90IGV4cGVjdA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPm1vcmUgdGhh biBvbmUgRFNDUCBpcyBhc3NpZ25lZCBiYXNlZCBvbiBzdWNoIGEgcG9saWN5IGZvciB0aGUgdGlt ZQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPmJlaW5nLiBJ4oCZbSBub3QgYXdhcmUgb2YgYW55IGFjdHVhbCBy ZXF1aXJlbWVudCB0byBzdXBwb3J0IGUuZy4gYW4gQUZuDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Y2xhc3Mg YnkgYWxsIHRocmVlIFBIQnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5B dCBpbnRlcmNvbm5lY3Rpb24gcG9pbnRzLCBhbnkgdW5leHBlY3RlZCBEU0NQIGlzIGJsZWFjaGVk LiBUaGlzIG11c3QNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5iZSBkb25lIHRvIHByb3RlY3QgYmFja2JvbmUg UW9TIHByb2R1Y3Rpb24uIFFvUyB0cmFuc3BvcnQgY2FuIGJlDQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+bmVn b3RpYXRlZCBmb3IgYSBzZXQgb2YgZGVmaW5lZCBEU0NQcy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+QSBzdHVkeSBvZiB0aGUgRVUgZm91bmQgRFBJIHRvIGJlIG1vcmUg Y29tbW9uIGluIHdpcmVsZXNzIGNvbW11bmljYXRpb24gdGhhbiBpbiB3aXJlZCBjb21tdW5pY2F0 aW9uLiBJ4oCZZCBub3QgZXhwZWN0IHRoZSBRb1MgcG9saWNpZXMgaW4gdGhhdCBhcmVhIHRvIGJl IG1vcmUgbGliZXJhbCB0aGFuIGZvciBmaXhlZCBhY2Nlc3MgbmV0d29ya3MgZm9yIHRoZSB0aW1l DQogYmVpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UnVlZGlnZXI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CE03DB3D7B45C245BCA0D24327794936140151C2MX104CL02corpem_-- From nobody Fri Jul 24 06:12:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAB11A88A3 for ; Fri, 24 Jul 2015 06:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhunLQgqSUIc for ; Fri, 24 Jul 2015 06:12:40 -0700 (PDT) Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com [209.85.160.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2613A1A8984 for ; Fri, 24 Jul 2015 06:12:39 -0700 (PDT) Received: by ykay190 with SMTP id y190so18989311yka.3 for ; Fri, 24 Jul 2015 06:12:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=CMjT3A3yiuOll5dGuxsCC0raOBPQwUT04XvbxHYQ30s=; b=meiM5oqCkPycQ4wXGG0N+/oqRydkeEkhNp7aTAx3IL4CCWysVfWb4cyDhoH/ArDBA4 0NQJpIdaEqodqzngWYS6W7L6V9uZqNrNeLGhxvAtM4V4EbS3Wl+rRHW5s/tFL007R/id gKh8CjcdTfUK1o91TPw2nVDd5VSXg0gXoVTQAddbmOzTM/iWibmdRAorNfBXRtRKmq7m G/qkjjCuUdmDSNgP9Lwyu82h79Way9bf1eq6g3xs+72tTy0Z8+ede6h8IkZZWGlsHiKf +oMN6mOPvIcwia58fnuxbAZJkAwe7pPrdie/VadMhSXpXdwbJpupYvSXhUio7RO52GIc 3FZg== X-Gm-Message-State: ALoCoQlZnXfgwyZfx0hoAzhOjjwzxsxv/J6/PYCnKAuSDh6PUnFEBKwRmrk1rQDGdKzQu/PxJdYN X-Received: by 10.13.247.3 with SMTP id h3mr15400774ywf.142.1437743558445; Fri, 24 Jul 2015 06:12:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.206 with HTTP; Fri, 24 Jul 2015 06:12:19 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 24 Jul 2015 15:12:19 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [rtcweb] Comments on draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 13:12:41 -0000 2015-07-24 12:11 GMT+02:00 Peter Thatcher : > There are applications already that basically build custom SDP with JS to > use it as an API and doesn't send the SDP over the signalling. The fact that developers are capable of building SDP monsters for local use based on custom signaled data, and still must feed the RTCPeerConnection with them, makes me unhappy. Typically the JS app parses data sent by the peer/server via HTTP or WebSocket, but when it comes to WebRTC 1.0 the JS app must re-build a blob for the browser to parse it. The more I think about it the less sense it has. > instead of this document being "Examples of SDP that is signalled", I th= ink it should be "Examples of SDP that can be put into setLocalDescription = and setRemoteDescription, and returned by createOffer and createAnswer". If the draft was about inputs for setLocalDescription, etc, it should be part of the W3C WebRTC specification, am I wrong? Said that, the draft looks very well (given what we have: the SDP). --=20 I=C3=B1aki Baz Castillo From nobody Fri Jul 24 23:01:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C401B2CAF; Fri, 24 Jul 2015 23:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZXV4qPHzAKA; Fri, 24 Jul 2015 23:01:17 -0700 (PDT) Received: from mail4.kpnnet.org (mail4.kpnnet.org [192.58.226.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DB91A1A7E; Fri, 24 Jul 2015 23:01:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,542,1432591200"; d="scan'208,217";a="153826686" Received: from w2006.kpnnl.local ([10.75.81.4]) by mail4.kpnnet.org with ESMTP; 25 Jul 2015 08:01:11 +0200 Received: from W3012.kpnnl.local (158.67.247.21) by W2006.kpnnl.local (10.75.81.4) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sat, 25 Jul 2015 08:01:10 +0200 Received: from W3018.kpnnl.local ([fe80::901f:81cf:ea70:9e75]) by W3012.kpnnl.local ([169.254.2.154]) with mapi id 14.03.0235.001; Sat, 25 Jul 2015 08:01:09 +0200 From: To: Thread-Topic: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel Thread-Index: AQHQxp9NpXXrCvhxn0aB/GaSr+KRfg== Date: Sat, 25 Jul 2015 06:01:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E4FD72E43B1C46B9B4E4624BDC4085ECkpncom_" MIME-Version: 1.0 Archived-At: Cc: karen.nielsen@tieto.com, Ruediger.Geib@telekom.de, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 06:01:21 -0000 --_000_E4FD72E43B1C46B9B4E4624BDC4085ECkpncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sometimes legislation prohibits the QoS model over open internet, all traff= ic must be treated the same. A VPN may be a solution, based on a SPs services model like Voice. Setting = up a VPN on the fly once the connection is established may suit the needs o= f a developer. Richard Op 24 jul. 2015 om 14:29 heeft Black, David > het volgende geschreven: > All DSCPs, which have not been negotiated between access and interconnect= ion are possibly bleached, especially if a network > provider operates QoS within the network. =93possibly=94 -> =93probably=94 -> =93almost certainly=94 depending on the= network (YMMV). > I=92d like to read a little more about how WEBrtc figures out which QoS r= esources are configured and which of these are available > for such a flow at an access when required. How and where are the resourc= es consumed by each WERrtc PHB controlled and > how are these aligned with the QoS resources consumed by other services? The short Web RTC answer to all of the above =93it doesn=92t do that=94. T= he DSCPs are in effect QoS service requests that the various networks invol= ved may deal with as they wish. Bleaching is one possibility (in effect an= =93I don=92t do that=94 response to the request). Even in that case, ther= e may be value in DSCP usage for forwarding by equipment between the browse= r and the interface to the ISP=92s network (e.g., residential router/NAT/AP= box). In spite of all of the above, I have been told of good experiences with use= of CS2 for gaming and CS1 for lower effort (less than best effort), plus E= F use for gaming was mentioned in the tsvwg meeting yesterday. This is not the first time I=92ve heard a request for a =93what QoS service= s are available via which DSCPs?=94 interface/protocol. I don=92t know of = one, and I=92m not sure how to incentivize deployment if we designed one. What is likely to happen is that if certain types of traffic favor specific= DSCPs, then operators who want to improve the user experience of those who= send/receive such traffic may put in QoS mechanisms for such traffic keyed= by those DSCPs at network ingress. OTOH, a =93tragedy of the commons=94 i= s possible here, e.g., the story in tsvwg about how a lot of non-voice traf= fic showing up marked as if it were voice resulted in the network operator = removing that special treatment of (residential, I presume) voice traffic. Thanks, --David From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Ruediger.Geib@tele= kom.de Sent: Friday, July 24, 2015 5:33 AM To: karen.nielsen@tieto.com Cc: Michael.Tuexen@lurchi.franken.de; rtcweb@ietf.org; tsvwg@ietf.org; fluffy@iii.ca Subject: Re: [tsvwg] diffserv marking for rtcwb data channel Hi Karen, QoS needs to be commercially negotiated at interconnection. If QoS should = be available at a consumer access, the consumer division of a company must = be involved in addition as well as the technical staff setting up and maint= aining technical configurations. 11 PHBs for a single consumer service are = a challenging requirement. All DSCPs, which have not been negotiated between access and interconnectio= n are possibly bleached, especially if a network provider operates QoS with= in the network. QoS to me means overprovisioning to ensure transport free of congestion. If= I see 11 PHBs for a single flow, I=92m not sure if this assumes more than = CoS (drop me last). I=92d like to read a little more about how WEBrtc figur= es out which QoS resources are configured and which of these are available = for such a flow at an access when required. How and where are the resources= consumed by each WERrtc PHB controlled and how are these aligned with the = QoS resources consumed by other services? Regards, Ruediger Von: Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com] Gesendet: Freitag, 24. Juli 2015 10:28 An: Geib, R=FCdiger Cc: rtcweb@ietf.org; tsvwg@ietf.org; Michael Tuexen; fluffy@iii.ca Betreff: RE: [tsvwg] diffserv marking for rtcwb data channel Hi Ruediger, Thanks a lot. So I think that you=92re saying that even if one made sure that different d= iff serv markings were split on different 5-tuples, this setting likely would be bleached at the n= etwork. Is that correctly understood ? If so, then (it sounds to me =96 not knowing too much about this) that from= a coupling congestion control perspective it would be preferable to use SCTP scheduling prioritization (within one and = the same association) for fine granular differentiation in between multiple data channels in between the same end-points rather than different= iation by means of diff serv marking. When/if one get a more consistent and forceful ECN operation in AQMs and SC= TP end-points, perhaps the coupling congestion principles achieved by means of sctp stream scheduling get to be less impor= tant. On the other hand, again as said before, having the one and the same, or mu= ltiple, flow control (receiver buffer) contexts may be a strength (simplicity) or a weakness. BR, Karen From: Ruediger.Geib@telekom.de [mailto:Rue= diger.Geib@telekom.de] Sent: Friday, July 24, 2015 10:00 AM To: karen.nielsen@tieto.com Cc: rtcweb@ietf.org; tsvwg@ietf.org Subject: AW: [tsvwg] diffserv marking for rtcwb data channel Karen, Finally there was a comment at the tsvwg meeting that the same 5-tupl= e with different diffserv markings would not get through the network =96 if= that generally is correct, then the solution is very easy: one MUST use different = associations to get port (5-tuple) differentiation. I think that if this is correct, one also wants to ask what happens = if the diffserv is changed for the same 5-tuple =96 i.e., is the network robust to this= change even if it is not robust to concurrent usage of different markings for the s= ame 5-tuple. Talking about the policies of the company I work for only: Possibilities to enforce QoS policies at a provider BRAS or BNG terminating= wired consumer accesses are limited. QoS policies based on full 5 tuple are very conservative and hard to maintain. I wouldn=92t expect full 5 tuple as basi= s for a QoS policy then. Trust in the correct information on which a BRAS/BNG can base QoS classification is an important issue. In any case, I=92d not expec= t more than one DSCP is assigned based on such a policy for the time being. I=92m not aware of any actual requirement to support e.g. an AFn class by all three PHBs. At interconnection points, any unexpected DSCP is bleached. This must be done to protect backbone QoS production. QoS transport can be negotiated for a set of defined DSCPs. A study of the EU found DPI to be more common in wireless communication tha= n in wired communication. I=92d not expect the QoS policies in that area to= be more liberal than for fixed access networks for the time being. Regards, Ruediger _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_E4FD72E43B1C46B9B4E4624BDC4085ECkpncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Sometimes legislation prohibits the QoS model over open internet, all = traffic must be treated the same.

A VPN may be a solution, based on a SPs services model like Voice. Setting = up a VPN on the fly once the connection is established may suit the needs o= f a developer.

Richard

Op 24 jul. 2015 om 14:29 heeft Black, David <david.black@emc.com> het volgende geschreven:

<WG chair hat OFF>

 

> All DSCPs, which have not been negotia= ted between access and interconnection are possibly bleached, especially if= a network

> provider operates= QoS within the network.

 

=93possibly=94 -> =93probably=94 -> =93a= lmost certainly=94 depending on the network (YMMV).

 

> I=92= d like to read a little more about how WEBrtc figures out which QoS resourc= es are configured and which of these are available

> for such a flow a= t an access when required. How and where are the resources consumed by each= WERrtc PHB controlled and

> how are these ali= gned with the QoS resources consumed by other services?

 

The short Web RTC answer to all of the above = =93it doesn=92t do that=94.  The DSCPs are in effect QoS service reque= sts that the various networks involved may deal with as they wish.  Bleaching is one possibility (in effect an =93I don=92t do tha= t=94 response to the request).  Even in that case, there may be value = in DSCP usage for forwarding by equipment between the browser and the inter= face to the ISP=92s network (e.g., residential router/NAT/AP box).

 

In spite of all of the above, I have been told= of good experiences with use of CS2 for gaming and CS1 for lower effort (l= ess than best effort), plus EF use for gaming was mentioned in the tsvwg meeting yesterday.

 

This is not the first time I=92ve heard a requ= est for a =93what QoS services are available via which DSCPs?=94 interface/= protocol.  I don=92t know of one, and I=92m not sure how to incentivize deployment if we designed one.

 

What is likely to happen is that if certain ty= pes of traffic favor specific DSCPs, then operators who want to improve the= user experience of those who send/receive such traffic may put in QoS mechanisms for such traffic keyed by those DSCPs at= network ingress.  OTOH, a =93tragedy of the commons=94 is possible he= re, e.g., the story in tsvwg about how a lot of non-voice traffic showing u= p marked as if it were voice resulted in the network operator removing that special treatment of (residential, I pr= esume) voice traffic.

 

</WG chair hat OFF>

 

Thanks,
--David

 

From: tsvwg [<= a href=3D"mailto:tsvwg-bounces@ietf.org">mailto:tsvwg-bounces@ietf.org] On Behalf Of Ruediger.Ge= ib@telekom.de
Sent: Friday, July 24, 2015 5:33 AM
To: karen.nielsen@tieto.c= om
Cc: Michael.Tuex= en@lurchi.franken.de; rtcweb@ietf.org; tsvwg@ietf.org; fluffy@iii.ca
Subject: Re: [tsvwg] diffserv marking for rtcwb data channel

 

Hi Karen,<= o:p>

 = ;

QoS  needs to be = commercially negotiated at interconnection. If QoS should be available at a= consumer access, the consumer division of a company must be involved in ad= dition as well as the technical staff setting up and maintaining technical configurations. 11 PHBs for a single consumer= service are a challenging requirement.

 

All DSCPs, which have = not been negotiated between access and interconnection are possibly bleache= d, especially if a network provider operates QoS within the network.

 

QoS to me means overpr= ovisioning to ensure transport free of congestion. If I see 11 PHBs for a s= ingle flow, I=92m not sure if this assumes more than CoS (drop me last). I= =92d like to read a little more about how WEBrtc figures out which QoS resources are configured and which of these a= re available for such a flow at an access when required. How and where are = the resources consumed by each WERrtc PHB controlled and how are these alig= ned with the QoS resources consumed by other services?

 

Regards,

 

Ruediger

 

Von: Karen Eli= sabeth Egede Nielsen [mailto:kar= en.nielsen@tieto.com]
Gesendet: Freitag, 24. Juli 2015 10:28
An: Geib, R=FCdiger
Cc: rtcweb@ietf.org; tsvwg@ietf.org; Michael Tuexen; fluffy= @iii.ca
Betreff: RE: [tsvwg] diffserv marking for rtcwb data channel

 

Hi Ruediger,

 

Thanks a lot.

 

So I think that you=92= re saying that even if one made sure that different diff serv markings were=

split on different 5-t= uples, this setting likely would be bleached at the network.

 

Is that correctly unde= rstood ?

 

If so, then (it sounds= to me =96 not knowing too much about this) that from a coupling congestion= control perspective it

would be preferable to=   use SCTP scheduling prioritization (within one and the same associat= ion) for fine granular differentiation in between

multiple data channels= in between the same end-points rather than differentiation by means of dif= f serv marking.

 

When/if one get a more= consistent and forceful ECN operation in AQMs and SCTP end-points, perhaps= the coupling congestion

principles achieved by= means of sctp stream scheduling get to be less important.

On the other hand, aga= in as said before, having the one and the same, or multiple, flow control (= receiver buffer) contexts may be

a strength (simplicity= ) or a weakness.    

 

BR, Karen =

 

 

Karen,

 

    = ;  Finally there was a comment at the tsvwg meeting that the same 5= -tuple with

   &nbs= p;   different diffserv markings would not get through the network =96 if that generally

   &nbs= p;   is correct,  then the solution is very easy= : one MUST use different associations to

   &nbs= p;   get port (5-tuple) differentiation.

   &nbs= p;   I think that if this is correct, one also wants to as= k what happens if the diffserv is

   &nbs= p;   changed for the same 5-tuple =96 i.e., is the ne= twork robust to this change even if

   &nbs= p;   it is not robust to concurrent usage of differen= t markings for the same 5-tuple.

 

Talking about the poli= cies of the company I work for only:

 

Possibilities to enfor= ce QoS policies at a provider BRAS or BNG terminating wired

consumer accesses are = limited. QoS policies based on full 5 tuple are very

conservative and hard = to maintain. I wouldn=92t expect full 5 tuple as basis for a QoS

policy then. Trust in = the correct information on which a BRAS/BNG can

base QoS classificatio= n is an important issue. In any case, I=92d not expect

more than one DSCP is = assigned based on such a policy for the time

being. I=92m not aware= of any actual requirement to support e.g. an AFn

class by all three PHB= s.

 

At interconnection poi= nts, any unexpected DSCP is bleached. This must

be done to protect bac= kbone QoS production. QoS transport can be

negotiated for a set o= f defined DSCPs.

 

A study of the EU foun= d DPI to be more common in wireless communication than in wired communicati= on. I=92d not expect the QoS policies in that area to be more liberal than = for fixed access networks for the time being.

 

Regards,

 

Ruediger

 

 

 

 

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_E4FD72E43B1C46B9B4E4624BDC4085ECkpncom_-- From nobody Sat Jul 25 06:56:38 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7431B3024; Sat, 25 Jul 2015 06:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id He5slN35V1yq; Sat, 25 Jul 2015 06:56:32 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D5F1B301F; Sat, 25 Jul 2015 06:56:30 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-dd-55b3958de6aa Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 37.C7.29223.D8593B55; Sat, 25 Jul 2015 15:56:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0210.002; Sat, 25 Jul 2015 15:56:28 +0200 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: "richard.vandet@kpn.com" , "david.black@emc.com" Thread-Topic: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel Thread-Index: AdDGDE8nHxnEQ3oDRFOpcaYiGvd36gAgjpyAABTKZoA= Date: Sat, 25 Jul 2015 13:56:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM+JvjW7v1M2hBrv65Sy2Hl7LbnGodSaL xcn155ks1v5rZ7f4MI3D4tibu2wObB5Hjsxm8Viy5CeTx6s3f5k92l4qeBx6HhTAGsVlk5Ka k1mWWqRvl8CVseDXTZaCE8EVf1fcZ25g3BLYxcjJISFgIrF1+T1mCFtM4sK99WxdjFwcQgJH GSWW/rnKDuEsZpR4+mceI0gVm4C3RFvLYRYQW0QgReLG73WsIDazwDZGiQuzUkBsYQE3iWPf ZrFC1LhL7Hi6lRHCtpI4NvkKO4jNIqAqsWbjFrA4r4C1xJl7H4Gu4ABaViexb3cMSJgTKNz0 9SAbiM0oICtx//s9FohV4hK3nsxngjhaQGLJnvNQD4hKvHz8D2ytqICexKcTH1kg4koSaw9v ZwEZzyygKbF+lz7EGGuJvr+NbBC2osSU7ofsENcISpyc+YRlAqPELCTbZiF0z0LSPQtJ9ywk 3QsYWVcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbwwS2/DXYwvnzueIhRgINRiYf3germ UCHWxLLiytxDjNIcLErivDM254UKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYDT/5SjAsEt+ E/dbkQdTJ20Sls071ndGYsaFurfa2cqeK/tuLbtt//d7y5QHnIKvdlmtU2ddWxB1XkToRbDL 25nLb5mm56V/+pB9MF2Z8fSlbKfNc3SlX9+carK28dzpno6vuew6P5emnTFryt12//ITtqpp bvV31se2+wT892S/GnDIfFqXsZgSS3FGoqEWc1FxIgBhp6RqwgIAAA== Archived-At: Cc: "Karen E. E. Nielsen" , "Ruediger.Geib@telekom.de" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 13:56:35 -0000 DQoNCj5Tb21ldGltZXMgbGVnaXNsYXRpb24gcHJvaGliaXRzIHRoZSBRb1MgbW9kZWwgb3ZlciBv cGVuIGludGVybmV0LCBhbGwNCj50cmFmZmljIG11c3QgYmUgdHJlYXRlZCB0aGUgc2FtZS4NCj4N Cj5BIFZQTiBtYXkgYmUgYSBzb2x1dGlvbiwgYmFzZWQgb24gYSBTUHMgc2VydmljZXMgbW9kZWwg bGlrZSBWb2ljZS4NCj5TZXR0aW5nIHVwIGEgVlBOIG9uIHRoZSBmbHkgb25jZSB0aGUgY29ubmVj dGlvbiBpcyBlc3RhYmxpc2hlZCBtYXkgc3VpdA0KPnRoZSBuZWVkcyBvZiBhIGRldmVsb3Blci4N Cg0KWW91IG1lYW4gYSDigJxzcGVjaWFsaXNlZCBzZXJ2aWNl4oCdIGluIHRoZSBFVSBuZXQgbmV1 dHJhbGl0eSB0ZXJtaW5vbG9neT8NCg0KQSDigJxWUE7igJ0gY2FuIGhhdmUgbWFueSBzaGFwZXMg YW5kIGZvcm1zLSBhIGNsb3NlZCB1c2VyIGdyb3VwIGFuZCBIVFRQUw0Kd291bGQgYmUgc3VmZmlj aWVudCwgcmlnaHQ/DQoNCk9yPw0KDQo+DQo+DQo+UmljaGFyZA0KPg0KPg0KPk9wIDI0IGp1bC4g MjAxNSBvbSAxNDoyOSBoZWVmdCBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb20+IGhl dA0KPnZvbGdlbmRlIGdlc2NocmV2ZW46DQo+DQo+DQo+DQo+PFdHIGNoYWlyIGhhdCBPRkY+DQo+ IA0KPj4NCj5BbGwgRFNDUHMsIHdoaWNoIGhhdmUgbm90IGJlZW4gbmVnb3RpYXRlZCBiZXR3ZWVu IGFjY2VzcyBhbmQNCj5pbnRlcmNvbm5lY3Rpb24gYXJlIHBvc3NpYmx5IGJsZWFjaGVkLCBlc3Bl Y2lhbGx5IGlmIGEgbmV0d29yaw0KPj4gcHJvdmlkZXIgb3BlcmF0ZXMgUW9TIHdpdGhpbiB0aGUg bmV0d29yay4NCj4gDQo+4oCccG9zc2libHnigJ0gLT4g4oCccHJvYmFibHnigJ0gLT4g4oCcYWxt b3N0IGNlcnRhaW5seeKAnSBkZXBlbmRpbmcgb24gdGhlIG5ldHdvcmsNCj4oWU1NVikuDQo+IA0K Pj4gSeKAmWQgbGlrZSB0byByZWFkIGEgbGl0dGxlIG1vcmUgYWJvdXQgaG93IFdFQnJ0YyBmaWd1 cmVzIG91dCB3aGljaCBRb1MNCj4+cmVzb3VyY2VzIGFyZSBjb25maWd1cmVkIGFuZCB3aGljaCBv ZiB0aGVzZSBhcmUgYXZhaWxhYmxlDQo+PiBmb3Igc3VjaCBhIGZsb3cgYXQgYW4gYWNjZXNzIHdo ZW4gcmVxdWlyZWQuIEhvdyBhbmQgd2hlcmUgYXJlIHRoZQ0KPj5yZXNvdXJjZXMgY29uc3VtZWQg YnkgZWFjaCBXRVJydGMgUEhCIGNvbnRyb2xsZWQgYW5kDQo+PiBob3cgYXJlIHRoZXNlIGFsaWdu ZWQgd2l0aCB0aGUgUW9TIHJlc291cmNlcyBjb25zdW1lZCBieSBvdGhlciBzZXJ2aWNlcz8NCj4g DQo+VGhlIHNob3J0IFdlYiBSVEMgYW5zd2VyIHRvIGFsbCBvZiB0aGUgYWJvdmUg4oCcaXQgZG9l c27igJl0IGRvIHRoYXTigJ0uICBUaGUNCj5EU0NQcyBhcmUgaW4gZWZmZWN0IFFvUyBzZXJ2aWNl IHJlcXVlc3RzIHRoYXQgdGhlIHZhcmlvdXMgbmV0d29ya3MNCj5pbnZvbHZlZCBtYXkgZGVhbCB3 aXRoIGFzIHRoZXkNCj4gd2lzaC4gIEJsZWFjaGluZyBpcyBvbmUgcG9zc2liaWxpdHkgKGluIGVm ZmVjdCBhbiDigJxJIGRvbuKAmXQgZG8gdGhhdOKAnQ0KPnJlc3BvbnNlIHRvIHRoZSByZXF1ZXN0 KS4gIEV2ZW4gaW4gdGhhdCBjYXNlLCB0aGVyZSBtYXkgYmUgdmFsdWUgaW4gRFNDUA0KPnVzYWdl IGZvciBmb3J3YXJkaW5nIGJ5IGVxdWlwbWVudCBiZXR3ZWVuIHRoZSBicm93c2VyIGFuZCB0aGUg aW50ZXJmYWNlDQo+dG8gdGhlIElTUOKAmXMgbmV0d29yayAoZS5nLiwgcmVzaWRlbnRpYWwgcm91 dGVyL05BVC9BUA0KPiBib3gpLg0KPiANCj5JbiBzcGl0ZSBvZiBhbGwgb2YgdGhlIGFib3ZlLCBJ IGhhdmUgYmVlbiB0b2xkIG9mIGdvb2QgZXhwZXJpZW5jZXMgd2l0aA0KPnVzZSBvZiBDUzIgZm9y IGdhbWluZyBhbmQgQ1MxIGZvciBsb3dlciBlZmZvcnQgKGxlc3MgdGhhbiBiZXN0IGVmZm9ydCks DQo+cGx1cyBFRiB1c2UgZm9yIGdhbWluZw0KPiB3YXMgbWVudGlvbmVkIGluIHRoZSB0c3Z3ZyBt ZWV0aW5nIHllc3RlcmRheS4NCj4gDQo+VGhpcyBpcyBub3QgdGhlIGZpcnN0IHRpbWUgSeKAmXZl IGhlYXJkIGEgcmVxdWVzdCBmb3IgYSDigJx3aGF0IFFvUyBzZXJ2aWNlcw0KPmFyZSBhdmFpbGFi bGUgdmlhIHdoaWNoIERTQ1BzP+KAnSBpbnRlcmZhY2UvcHJvdG9jb2wuICBJIGRvbuKAmXQga25v dyBvZiBvbmUsDQo+YW5kIEnigJltIG5vdCBzdXJlIGhvdw0KPiB0byBpbmNlbnRpdml6ZSBkZXBs b3ltZW50IGlmIHdlIGRlc2lnbmVkIG9uZS4NCj4gDQo+V2hhdCBpcyBsaWtlbHkgdG8gaGFwcGVu IGlzIHRoYXQgaWYgY2VydGFpbiB0eXBlcyBvZiB0cmFmZmljIGZhdm9yDQo+c3BlY2lmaWMgRFND UHMsIHRoZW4gb3BlcmF0b3JzIHdobyB3YW50IHRvIGltcHJvdmUgdGhlIHVzZXIgZXhwZXJpZW5j ZSBvZg0KPnRob3NlIHdobyBzZW5kL3JlY2VpdmUgc3VjaA0KPiB0cmFmZmljIG1heSBwdXQgaW4g UW9TIG1lY2hhbmlzbXMgZm9yIHN1Y2ggdHJhZmZpYyBrZXllZCBieSB0aG9zZSBEU0NQcw0KPmF0 IG5ldHdvcmsgaW5ncmVzcy4gIE9UT0gsIGEg4oCcdHJhZ2VkeSBvZiB0aGUgY29tbW9uc+KAnSBp cyBwb3NzaWJsZSBoZXJlLA0KPmUuZy4sIHRoZSBzdG9yeSBpbiB0c3Z3ZyBhYm91dCBob3cgYSBs b3Qgb2Ygbm9uLXZvaWNlIHRyYWZmaWMgc2hvd2luZyB1cA0KPm1hcmtlZCBhcyBpZiBpdCB3ZXJl IHZvaWNlIHJlc3VsdGVkIGluDQo+IHRoZSBuZXR3b3JrIG9wZXJhdG9yIHJlbW92aW5nIHRoYXQg c3BlY2lhbCB0cmVhdG1lbnQgb2YgKHJlc2lkZW50aWFsLCBJDQo+cHJlc3VtZSkgdm9pY2UgdHJh ZmZpYy4NCj4gDQo+PC9XRyBjaGFpciBoYXQgT0ZGPg0KPiANCj5UaGFua3MsDQo+LS1EYXZpZA0K Pg0KPg0KPiANCj5Gcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddDQo+ T24gQmVoYWxmIE9mIFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZQ0KPlNlbnQ6IEZyaWRheSwgSnVs eSAyNCwgMjAxNSA1OjMzIEFNDQo+VG86IGthcmVuLm5pZWxzZW5AdGlldG8uY29tDQo+Q2M6IE1p Y2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2VuLmRlOw0KPnJ0Y3dlYkBpZXRmLm9yZzsgDQo+dHN2 d2dAaWV0Zi5vcmcgPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz47IGZsdWZmeUBpaWkuY2ENCj5TdWJq ZWN0OiBSZTogW3RzdndnXSBkaWZmc2VydiBtYXJraW5nIGZvciBydGN3YiBkYXRhIGNoYW5uZWwN Cj4NCj4NCj4gDQo+SGkgS2FyZW4sDQo+IA0KPlFvUyAgbmVlZHMgdG8gYmUgY29tbWVyY2lhbGx5 IG5lZ290aWF0ZWQgYXQgaW50ZXJjb25uZWN0aW9uLiBJZiBRb1MNCj5zaG91bGQgYmUgYXZhaWxh YmxlIGF0IGEgY29uc3VtZXIgYWNjZXNzLCB0aGUgY29uc3VtZXIgZGl2aXNpb24gb2YgYQ0KPmNv bXBhbnkgbXVzdCBiZSBpbnZvbHZlZCBpbiBhZGRpdGlvbiBhcyB3ZWxsIGFzIHRoZSB0ZWNobmlj YWwgc3RhZmYNCj5zZXR0aW5nDQo+IHVwIGFuZCBtYWludGFpbmluZyB0ZWNobmljYWwgY29uZmln dXJhdGlvbnMuIDExIFBIQnMgZm9yIGEgc2luZ2xlDQo+Y29uc3VtZXIgc2VydmljZSBhcmUgYSBj aGFsbGVuZ2luZyByZXF1aXJlbWVudC4NCj4gDQo+QWxsIERTQ1BzLCB3aGljaCBoYXZlIG5vdCBi ZWVuIG5lZ290aWF0ZWQgYmV0d2VlbiBhY2Nlc3MgYW5kDQo+aW50ZXJjb25uZWN0aW9uIGFyZSBw b3NzaWJseSBibGVhY2hlZCwgZXNwZWNpYWxseSBpZiBhIG5ldHdvcmsgcHJvdmlkZXINCj5vcGVy YXRlcyBRb1Mgd2l0aGluIHRoZSBuZXR3b3JrLg0KPiANCj5Rb1MgdG8gbWUgbWVhbnMgb3ZlcnBy b3Zpc2lvbmluZyB0byBlbnN1cmUgdHJhbnNwb3J0IGZyZWUgb2YgY29uZ2VzdGlvbi4NCj5JZiBJ IHNlZSAxMSBQSEJzIGZvciBhIHNpbmdsZSBmbG93LCBJ4oCZbSBub3Qgc3VyZSBpZiB0aGlzIGFz c3VtZXMgbW9yZQ0KPnRoYW4gQ29TIChkcm9wIG1lIGxhc3QpLiBJ4oCZZCBsaWtlIHRvIHJlYWQg YSBsaXR0bGUgbW9yZSBhYm91dCBob3cNCj4gV0VCcnRjIGZpZ3VyZXMgb3V0IHdoaWNoIFFvUyBy ZXNvdXJjZXMgYXJlIGNvbmZpZ3VyZWQgYW5kIHdoaWNoIG9mIHRoZXNlDQo+YXJlIGF2YWlsYWJs ZSBmb3Igc3VjaCBhIGZsb3cgYXQgYW4gYWNjZXNzIHdoZW4gcmVxdWlyZWQuIEhvdyBhbmQgd2hl cmUNCj5hcmUgdGhlIHJlc291cmNlcyBjb25zdW1lZCBieSBlYWNoIFdFUnJ0YyBQSEIgY29udHJv bGxlZCBhbmQgaG93IGFyZQ0KPnRoZXNlIGFsaWduZWQgd2l0aCB0aGUgUW9TIHJlc291cmNlcyBj b25zdW1lZA0KPiBieSBvdGhlciBzZXJ2aWNlcz8NCj4gDQo+UmVnYXJkcywNCj4gDQo+UnVlZGln ZXINCj4gDQo+Vm9uOiBLYXJlbiBFbGlzYWJldGggRWdlZGUgTmllbHNlbiBbbWFpbHRvOmthcmVu Lm5pZWxzZW5AdGlldG8uY29tXQ0KPg0KPkdlc2VuZGV0OiBGcmVpdGFnLCAyNC4gSnVsaSAyMDE1 IDEwOjI4DQo+QW46IEdlaWIsIFLDvGRpZ2VyDQo+Q2M6IHJ0Y3dlYkBpZXRmLm9yZzsNCj50c3Z3 Z0BpZXRmLm9yZyA8bWFpbHRvOnRzdndnQGlldGYub3JnPjsgTWljaGFlbCBUdWV4ZW47IGZsdWZm eUBpaWkuY2ENCj5CZXRyZWZmOiBSRTogW3RzdndnXSBkaWZmc2VydiBtYXJraW5nIGZvciBydGN3 YiBkYXRhIGNoYW5uZWwNCj4NCj4NCj4gDQo+SGkgUnVlZGlnZXIsDQo+IA0KPlRoYW5rcyBhIGxv dC4NCj4gDQo+U28gSSB0aGluayB0aGF0IHlvdeKAmXJlIHNheWluZyB0aGF0IGV2ZW4gaWYgb25l IG1hZGUgc3VyZSB0aGF0IGRpZmZlcmVudA0KPmRpZmYgc2VydiBtYXJraW5ncyB3ZXJlDQo+c3Bs aXQgb24gZGlmZmVyZW50IDUtdHVwbGVzLCB0aGlzIHNldHRpbmcgbGlrZWx5IHdvdWxkIGJlIGJs ZWFjaGVkIGF0IHRoZQ0KPm5ldHdvcmsuDQo+IA0KPklzIHRoYXQgY29ycmVjdGx5IHVuZGVyc3Rv b2QgPw0KPiANCj5JZiBzbywgdGhlbiAoaXQgc291bmRzIHRvIG1lIOKAkyBub3Qga25vd2luZyB0 b28gbXVjaCBhYm91dCB0aGlzKSB0aGF0IGZyb20NCj5hIGNvdXBsaW5nIGNvbmdlc3Rpb24gY29u dHJvbCBwZXJzcGVjdGl2ZSBpdA0KPg0KPndvdWxkIGJlIHByZWZlcmFibGUgdG8gIHVzZSBTQ1RQ IHNjaGVkdWxpbmcgcHJpb3JpdGl6YXRpb24gKHdpdGhpbiBvbmUNCj5hbmQgdGhlIHNhbWUgYXNz b2NpYXRpb24pIGZvciBmaW5lIGdyYW51bGFyIGRpZmZlcmVudGlhdGlvbiBpbiBiZXR3ZWVuDQo+ bXVsdGlwbGUgZGF0YSBjaGFubmVscyBpbiBiZXR3ZWVuIHRoZSBzYW1lIGVuZC1wb2ludHMgcmF0 aGVyIHRoYW4NCj5kaWZmZXJlbnRpYXRpb24gYnkgbWVhbnMgb2YgZGlmZiBzZXJ2IG1hcmtpbmcu DQo+IA0KPldoZW4vaWYgb25lIGdldCBhIG1vcmUgY29uc2lzdGVudCBhbmQgZm9yY2VmdWwgRUNO IG9wZXJhdGlvbiBpbiBBUU1zIGFuZA0KPlNDVFAgZW5kLXBvaW50cywgcGVyaGFwcyB0aGUgY291 cGxpbmcgY29uZ2VzdGlvbg0KPnByaW5jaXBsZXMgYWNoaWV2ZWQgYnkgbWVhbnMgb2Ygc2N0cCBz dHJlYW0gc2NoZWR1bGluZyBnZXQgdG8gYmUgbGVzcw0KPmltcG9ydGFudC4NCj4NCj5PbiB0aGUg b3RoZXIgaGFuZCwgYWdhaW4gYXMgc2FpZCBiZWZvcmUsIGhhdmluZyB0aGUgb25lIGFuZCB0aGUg c2FtZSwgb3INCj5tdWx0aXBsZSwgZmxvdyBjb250cm9sIChyZWNlaXZlciBidWZmZXIpIGNvbnRl eHRzIG1heSBiZQ0KPmEgc3RyZW5ndGggKHNpbXBsaWNpdHkpIG9yIGEgd2Vha25lc3MuDQo+IA0K PkJSLCBLYXJlbiANCj4gDQo+RnJvbTpSdWVkaWdlci5HZWliQHRlbGVrb20uZGUgW21haWx0bzpS dWVkaWdlci5HZWliQHRlbGVrb20uZGVdDQo+DQo+U2VudDogRnJpZGF5LCBKdWx5IDI0LCAyMDE1 IDEwOjAwIEFNDQo+VG86IGthcmVuLm5pZWxzZW5AdGlldG8uY29tDQo+Q2M6IHJ0Y3dlYkBpZXRm Lm9yZzsNCj50c3Z3Z0BpZXRmLm9yZyA8bWFpbHRvOnRzdndnQGlldGYub3JnPg0KPlN1YmplY3Q6 IEFXOiBbdHN2d2ddIGRpZmZzZXJ2IG1hcmtpbmcgZm9yIHJ0Y3diIGRhdGEgY2hhbm5lbA0KPg0K Pg0KPiANCj5LYXJlbiwNCj4gDQo+ICAgICANCj5GaW5hbGx5IHRoZXJlIHdhcyBhIGNvbW1lbnQg YXQgdGhlIHRzdndnIG1lZXRpbmcgdGhhdCB0aGUgc2FtZSA1LXR1cGxlDQo+d2l0aA0KPg0KPiAg ICAgICBkaWZmZXJlbnQgZGlmZnNlcnYgbWFya2luZ3Mgd291bGQgbm90IGdldHRocm91Z2ggdGhl IG5ldHdvcmsg4oCTIGlmDQo+dGhhdCBnZW5lcmFsbHkgDQo+ICAgICAgIGlzIGNvcnJlY3QsICB0 aGVuIHRoZSBzb2x1dGlvbiBpcyB2ZXJ5IGVhc3k6IG9uZSBNVVNUIHVzZQ0KPmRpZmZlcmVudCBh c3NvY2lhdGlvbnMgdG8NCj4NCj4gICAgICAgZ2V0IHBvcnQgKDUtdHVwbGUpIGRpZmZlcmVudGlh dGlvbi4NCj4gICAgICAgSSB0aGluayB0aGF0IGlmIHRoaXMgaXMgY29ycmVjdCwgb25lIGFsc28g d2FudHMgdG8gYXNrIHdoYXQNCj5oYXBwZW5zIGlmIHRoZSBkaWZmc2VydiBpcw0KPg0KPiAgICAg ICBjaGFuZ2VkIGZvciB0aGUgc2FtZSA1LXR1cGxlIOKAkyBpLmUuLCBpcyB0aGUgbmV0d29yayBy b2J1c3QgdG8gdGhpcw0KPmNoYW5nZSBldmVuIGlmDQo+DQo+ICAgICAgIGl0IGlzIG5vdCByb2J1 c3QgdG8gY29uY3VycmVudCB1c2FnZSBvZiBkaWZmZXJlbnQgbWFya2luZ3MgZm9yIHRoZQ0KPnNh bWUgNS10dXBsZS4NCj4gDQo+VGFsa2luZyBhYm91dCB0aGUgcG9saWNpZXMgb2YgdGhlIGNvbXBh bnkgSSB3b3JrIGZvciBvbmx5Og0KPiANCj5Qb3NzaWJpbGl0aWVzIHRvIGVuZm9yY2UgUW9TIHBv bGljaWVzIGF0IGEgcHJvdmlkZXIgQlJBUyBvciBCTkcNCj50ZXJtaW5hdGluZyB3aXJlZA0KPg0K PmNvbnN1bWVyIGFjY2Vzc2VzIGFyZSBsaW1pdGVkLiBRb1MgcG9saWNpZXMgYmFzZWQgb24gZnVs bCA1IHR1cGxlIGFyZSB2ZXJ5DQo+DQo+Y29uc2VydmF0aXZlIGFuZCBoYXJkIHRvIG1haW50YWlu LiBJIHdvdWxkbuKAmXQgZXhwZWN0IGZ1bGwgNSB0dXBsZSBhcw0KPmJhc2lzIGZvciBhIFFvUw0K Pg0KPnBvbGljeSB0aGVuLiBUcnVzdCBpbiB0aGUgY29ycmVjdCBpbmZvcm1hdGlvbiBvbiB3aGlj aCBhIEJSQVMvQk5HIGNhbg0KPg0KPmJhc2UgUW9TIGNsYXNzaWZpY2F0aW9uIGlzIGFuIGltcG9y dGFudCBpc3N1ZS4gSW4gYW55IGNhc2UsIEnigJlkIG5vdCBleHBlY3QNCj4NCj5tb3JlIHRoYW4g b25lIERTQ1AgaXMgYXNzaWduZWQgYmFzZWQgb24gc3VjaCBhIHBvbGljeSBmb3IgdGhlIHRpbWUN Cj4NCj5iZWluZy4gSeKAmW0gbm90IGF3YXJlIG9mIGFueSBhY3R1YWwgcmVxdWlyZW1lbnQgdG8g c3VwcG9ydCBlLmcuIGFuIEFGbg0KPg0KPmNsYXNzIGJ5IGFsbCB0aHJlZSBQSEJzLg0KPiANCj5B dCBpbnRlcmNvbm5lY3Rpb24gcG9pbnRzLCBhbnkgdW5leHBlY3RlZCBEU0NQIGlzIGJsZWFjaGVk LiBUaGlzIG11c3QNCj4NCj5iZSBkb25lIHRvIHByb3RlY3QgYmFja2JvbmUgUW9TIHByb2R1Y3Rp b24uIFFvUyB0cmFuc3BvcnQgY2FuIGJlDQo+DQo+bmVnb3RpYXRlZCBmb3IgYSBzZXQgb2YgZGVm aW5lZCBEU0NQcy4NCj4NCj4gDQo+QSBzdHVkeSBvZiB0aGUgRVUgZm91bmQgRFBJIHRvIGJlIG1v cmUgY29tbW9uIGluIHdpcmVsZXNzIGNvbW11bmljYXRpb24NCj50aGFuIGluIHdpcmVkIGNvbW11 bmljYXRpb24uIEnigJlkIG5vdCBleHBlY3QgdGhlIFFvUyBwb2xpY2llcyBpbiB0aGF0IGFyZWEN Cj50byBiZSBtb3JlIGxpYmVyYWwgdGhhbiBmb3IgZml4ZWQgYWNjZXNzIG5ldHdvcmtzIGZvciB0 aGUgdGltZQ0KPiBiZWluZy4NCj4gDQo+UmVnYXJkcywNCj4gDQo+UnVlZGlnZXINCj4gDQo+IA0K PiANCj4gDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5ydGN3ZWIgbWFpbGluZyBsaXN0DQo+cnRjd2ViQGlldGYu b3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4NCj4N Cj4NCg0K From nobody Sat Jul 25 10:16:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB531A0233; Sat, 25 Jul 2015 10:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPjig2mmV6Pg; Sat, 25 Jul 2015 10:16:24 -0700 (PDT) Received: from mail1.kpnnet.org (mail1.kpnnet.org [192.58.226.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7BA1A1B82; Sat, 25 Jul 2015 10:16:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,542,1432591200"; d="scan'208";a="79566475" Received: from w2006.kpnnl.local ([10.75.81.4]) by mail1.kpnnet.org with ESMTP; 25 Jul 2015 19:16:20 +0200 Received: from W3011.kpnnl.local (158.67.247.20) by W2006.kpnnl.local (10.75.81.4) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sat, 25 Jul 2015 19:16:20 +0200 Received: from W3018.kpnnl.local ([fe80::901f:81cf:ea70:9e75]) by W3011.kpnnl.local ([169.254.1.165]) with mapi id 14.03.0235.001; Sat, 25 Jul 2015 19:16:14 +0200 From: To: Thread-Topic: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel Thread-Index: AQHQxp9NpXXrCvhxn0aB/GaSr+KRfp3sFKCAgABZWK0= Date: Sat, 25 Jul 2015 17:16:13 +0000 Message-ID: <403FC848-7375-45A2-A1F1-442BC8B461FC@kpn.com> References: , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: karen.nielsen@tieto.com, david.black@emc.com, rtcweb@ietf.org, Ruediger.Geib@telekom.de, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 17:16:27 -0000 > Op 25 jul. 2015 om 15:56 heeft G=F6ran Eriksson AP het volgende geschreven: >=20 >=20 >=20 >> Sometimes legislation prohibits the QoS model over open internet, all >> traffic must be treated the same. >>=20 >> A VPN may be a solution, based on a SPs services model like Voice. >> Setting up a VPN on the fly once the connection is established may suit >> the needs of a developer. >=20 > You mean a =93specialised service=94 in the EU net neutrality terminology= ? >=20 Indeed Net neutrality.=20 > A =93VPN=94 can have many shapes and forms- a closed user group and HTTPS > would be sufficient, right? >=20 Something like bandwith reservaties: a temporarily tunnel to the centralize= d WebRTC server. Especially when using Voice and video.=20 > Or? >=20 >>=20 >>=20 >> Richard >>=20 >>=20 >> Op 24 jul. 2015 om 14:29 heeft Black, David het >> volgende geschreven: >>=20 >>=20 >>=20 >> >>=20 >> All DSCPs, which have not been negotiated between access and >> interconnection are possibly bleached, especially if a network >>> provider operates QoS within the network. >>=20 >> =93possibly=94 -> =93probably=94 -> =93almost certainly=94 depending on = the network >> (YMMV). >>=20 >>> I=92d like to read a little more about how WEBrtc figures out which QoS >>> resources are configured and which of these are available >>> for such a flow at an access when required. How and where are the >>> resources consumed by each WERrtc PHB controlled and >>> how are these aligned with the QoS resources consumed by other services= ? >>=20 >> The short Web RTC answer to all of the above =93it doesn=92t do that=94.= The >> DSCPs are in effect QoS service requests that the various networks >> involved may deal with as they >> wish. Bleaching is one possibility (in effect an =93I don=92t do that= =94 >> response to the request). Even in that case, there may be value in DSCP >> usage for forwarding by equipment between the browser and the interface >> to the ISP=92s network (e.g., residential router/NAT/AP >> box). >>=20 >> In spite of all of the above, I have been told of good experiences with >> use of CS2 for gaming and CS1 for lower effort (less than best effort), >> plus EF use for gaming >> was mentioned in the tsvwg meeting yesterday. >>=20 >> This is not the first time I=92ve heard a request for a =93what QoS serv= ices >> are available via which DSCPs?=94 interface/protocol. I don=92t know of= one, >> and I=92m not sure how >> to incentivize deployment if we designed one. >>=20 >> What is likely to happen is that if certain types of traffic favor >> specific DSCPs, then operators who want to improve the user experience o= f >> those who send/receive such >> traffic may put in QoS mechanisms for such traffic keyed by those DSCPs >> at network ingress. OTOH, a =93tragedy of the commons=94 is possible he= re, >> e.g., the story in tsvwg about how a lot of non-voice traffic showing up >> marked as if it were voice resulted in >> the network operator removing that special treatment of (residential, I >> presume) voice traffic. >>=20 >> >>=20 >> Thanks, >> --David >>=20 >>=20 >>=20 >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] >> On Behalf Of Ruediger.Geib@telekom.de >> Sent: Friday, July 24, 2015 5:33 AM >> To: karen.nielsen@tieto.com >> Cc: Michael.Tuexen@lurchi.franken.de; >> rtcweb@ietf.org;=20 >> tsvwg@ietf.org ; fluffy@iii.ca >> Subject: Re: [tsvwg] diffserv marking for rtcwb data channel >>=20 >>=20 >>=20 >> Hi Karen, >>=20 >> QoS needs to be commercially negotiated at interconnection. If QoS >> should be available at a consumer access, the consumer division of a >> company must be involved in addition as well as the technical staff >> setting >> up and maintaining technical configurations. 11 PHBs for a single >> consumer service are a challenging requirement. >>=20 >> All DSCPs, which have not been negotiated between access and >> interconnection are possibly bleached, especially if a network provider >> operates QoS within the network. >>=20 >> QoS to me means overprovisioning to ensure transport free of congestion. >> If I see 11 PHBs for a single flow, I=92m not sure if this assumes more >> than CoS (drop me last). I=92d like to read a little more about how >> WEBrtc figures out which QoS resources are configured and which of these >> are available for such a flow at an access when required. How and where >> are the resources consumed by each WERrtc PHB controlled and how are >> these aligned with the QoS resources consumed >> by other services? >>=20 >> Regards, >>=20 >> Ruediger >>=20 >> Von: Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com] >>=20 >> Gesendet: Freitag, 24. Juli 2015 10:28 >> An: Geib, R=FCdiger >> Cc: rtcweb@ietf.org; >> tsvwg@ietf.org ; Michael Tuexen; fluffy@iii.ca >> Betreff: RE: [tsvwg] diffserv marking for rtcwb data channel >>=20 >>=20 >>=20 >> Hi Ruediger, >>=20 >> Thanks a lot. >>=20 >> So I think that you=92re saying that even if one made sure that differen= t >> diff serv markings were >> split on different 5-tuples, this setting likely would be bleached at th= e >> network. >>=20 >> Is that correctly understood ? >>=20 >> If so, then (it sounds to me =96 not knowing too much about this) that f= rom >> a coupling congestion control perspective it >>=20 >> would be preferable to use SCTP scheduling prioritization (within one >> and the same association) for fine granular differentiation in between >> multiple data channels in between the same end-points rather than >> differentiation by means of diff serv marking. >>=20 >> When/if one get a more consistent and forceful ECN operation in AQMs and >> SCTP end-points, perhaps the coupling congestion >> principles achieved by means of sctp stream scheduling get to be less >> important. >>=20 >> On the other hand, again as said before, having the one and the same, or >> multiple, flow control (receiver buffer) contexts may be >> a strength (simplicity) or a weakness. >>=20 >> BR, Karen=20 >>=20 >> From:Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] >>=20 >> Sent: Friday, July 24, 2015 10:00 AM >> To: karen.nielsen@tieto.com >> Cc: rtcweb@ietf.org; >> tsvwg@ietf.org >> Subject: AW: [tsvwg] diffserv marking for rtcwb data channel >>=20 >>=20 >>=20 >> Karen, >>=20 >>=20 >> Finally there was a comment at the tsvwg meeting that the same 5-tuple >> with >>=20 >> different diffserv markings would not getthrough the network =96 if >> that generally=20 >> is correct, then the solution is very easy: one MUST use >> different associations to >>=20 >> get port (5-tuple) differentiation. >> I think that if this is correct, one also wants to ask what >> happens if the diffserv is >>=20 >> changed for the same 5-tuple =96 i.e., is the network robust to thi= s >> change even if >>=20 >> it is not robust to concurrent usage of different markings for the >> same 5-tuple. >>=20 >> Talking about the policies of the company I work for only: >>=20 >> Possibilities to enforce QoS policies at a provider BRAS or BNG >> terminating wired >>=20 >> consumer accesses are limited. QoS policies based on full 5 tuple are ve= ry >>=20 >> conservative and hard to maintain. I wouldn=92t expect full 5 tuple as >> basis for a QoS >>=20 >> policy then. Trust in the correct information on which a BRAS/BNG can >>=20 >> base QoS classification is an important issue. In any case, I=92d not ex= pect >>=20 >> more than one DSCP is assigned based on such a policy for the time >>=20 >> being. I=92m not aware of any actual requirement to support e.g. an AFn >>=20 >> class by all three PHBs. >>=20 >> At interconnection points, any unexpected DSCP is bleached. This must >>=20 >> be done to protect backbone QoS production. QoS transport can be >>=20 >> negotiated for a set of defined DSCPs. >>=20 >>=20 >> A study of the EU found DPI to be more common in wireless communication >> than in wired communication. I=92d not expect the QoS policies in that a= rea >> to be more liberal than for fixed access networks for the time >> being. >>=20 >> Regards, >>=20 >> Ruediger >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Jul 27 06:59:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0D01B2DD4 for ; Mon, 27 Jul 2015 06:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjXrbPObY1Sv for ; Mon, 27 Jul 2015 06:59:28 -0700 (PDT) Received: from gateway23.websitewelcome.com (gateway23.websitewelcome.com [192.185.49.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E60E1B2D8B for ; Mon, 27 Jul 2015 06:59:28 -0700 (PDT) Received: by gateway23.websitewelcome.com (Postfix, from userid 500) id EC6849B7E4CC4; Mon, 27 Jul 2015 08:59:27 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway23.websitewelcome.com (Postfix) with ESMTP id D7B6A9B7E4C73 for ; Mon, 27 Jul 2015 08:59:27 -0500 (CDT) Received: from [96.231.221.219] (port=54730 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZJiwB-0003Pg-5j for rtcweb@ietf.org; Mon, 27 Jul 2015 08:59:27 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <199D47C7-9ABC-4FBF-A9CB-9F8ABF5A4DB0@ieca.com> Date: Mon, 27 Jul 2015 09:59:24 -0400 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.221.219 X-Exim-ID: 1ZJiwB-0003Pg-5j X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.221.219]:54730 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [rtcweb] codec's MISREF X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 13:59:30 -0000 All, The chairs have been in discussions with some IESG members to try to = resolve a MISREF in the video codec draft [1]; the normative reference = to the overview draft should have been made an informative reference see = this thread circa Aug =9213 = (http://www.ietf.org/mail-archive/web/rtcweb/current/msg08624.html). = What we=92ve come up with is a) remove the 1st paragraph of s5 from the = codec draft, b) copy the definitions from the overview draft (and note = the definitions are also in the overview drat), and c) move the = reference to an informative reference. You can see all of this in an = RFC editor that Alissa has kind crafted here = http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/writeup/. spt (as the doc shepherd) [1] http://www.rfc-editor.org/cluster_info.php?cid=3DC238= From nobody Mon Jul 27 07:24:15 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04F01B2E46 for ; Mon, 27 Jul 2015 07:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ag7MI5uoXcmx for ; Mon, 27 Jul 2015 07:24:11 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDC51B2E34 for ; Mon, 27 Jul 2015 07:24:10 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so114829248wic.1 for ; Mon, 27 Jul 2015 07:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=E9sIvcXssQ4WfFNHWTTokaLEzdq5Z/WxPIoCDL3whWc=; b=xaJ7Np1n4mURI2PTHKc5nFcqTBaFmIi91rMnApQSuaUdSeG0dXO4YHFFxP8r7wAdhx bR+g1xzaRNmcfX0BxjZzfePAEOc07e62jAnGrW3RH64O3J9qHikgiaEOCWZuwm9g1rMk NSYaADrjjJGSIu4MxcFfnM4QYe99O56M3ZDZA1PHm9+5SzsoMt3Z2eq+h+zqzEsCOlFa 4UBI7fZRppv3UYJMji6UFpUGDDiHjfTxnfByz5XePslTDSmUDp7X30N1noBIjY8G4vgl R5H2GjVk5Y6QoyxAxZHUpN65uV2Af57aPjzFBo8vf7phnkwWGKjUUoRIIauol6HO6/HE crxw== MIME-Version: 1.0 X-Received: by 10.194.78.84 with SMTP id z20mr58966574wjw.141.1438007048613; Mon, 27 Jul 2015 07:24:08 -0700 (PDT) Received: by 10.28.16.14 with HTTP; Mon, 27 Jul 2015 07:24:08 -0700 (PDT) In-Reply-To: <1437985505.2655.19.camel@w3.org> References: <1437985505.2655.19.camel@w3.org> Date: Mon, 27 Jul 2015 16:24:08 +0200 Message-ID: From: Victor Pascual Avila To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0c59c514c29051bdc1bff Archived-At: Subject: [rtcweb] Fwd: New WebRTC WG charter officially approved X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 14:24:13 -0000 --047d7bf0c59c514c29051bdc1bff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI ---------- Forwarded message ---------- From: Vivien Lacourba Date: Mon, Jul 27, 2015 at 10:25 AM Subject: New WebRTC WG charter officially approved To: WebRTC WG Hi all, Great news, the new W3C WebRTC Working Group charter [1] has been officially approved by the W3C Director [2]. The revised charter adds a deliverable for the next version of WebRTC, has an updated list of deliverables based on the work started under the previous charter, clarifies its decision policy, and extends the group until March 2018. The charter of this Working Group includes a new deliverable that require W3C Patent Policy licensing commitments from all Participants. Consequently, all Participants must join or re-join the group, which involves agreeing to participate under the terms of the revised charter and the W3C Patent Policy. Current Participants may continue to attend meetings (teleconferences and face-to-face meetings) for 45 days after this announcement, even if they have not yet re-joined the group. After 45 days (ie. September 10, 2015), ongoing participation (including meeting attendance and voting) is only permitted for those who have re-joined the group. Use this form to (re)join: https://www.w3.org/2004/01/pp-impl/47318/join Instructions to join the group are available at: http://www.w3.org/2004/01/pp-impl/47318/instructions Thanks, Vivien on behalf of the WebRTC WG Chairs and Staff contacts [1] http://www.w3.org/2015/07/webrtc-charter.html [2] https://lists.w3.org/Archives/Member/w3c-ac-members/2015JulSep/0024.html -- Vivien Lacourba World Wide Web Consortium vivien@w3.org http://www.w3.org http://www.w3.org/People/Vivien Tel: +33.4.92.38.78.89 --=20 Victor Pascual =C3=81vila --047d7bf0c59c514c29051bdc1bff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI

---------- Forwarde= d message ----------
From: Vivien Lacourba= <vivien@w3.org>
Date: Mon, Jul 27, 2015 at 10:25 AM
Subject: New WebRTC= WG charter officially approved
To: WebRTC WG <public-webrtc@w3.org>


Hi all,

Great news, the new W3C WebRTC Working Group charter [1] has been
officially approved by the W3C Director [2].

The revised charter adds a deliverable for the next version of WebRTC,
has an updated list of deliverables based on the work started under the
previous charter, clarifies its decision policy, and extends the group
until March 2018.

The charter of this Working Group includes a new deliverable that
require W3C Patent Policy licensing commitments from all Participants.

Consequently, all Participants must join or re-join the group, which
involves agreeing to participate under the terms of the revised charter
and the W3C Patent Policy. Current Participants may continue to attend
meetings (teleconferences and face-to-face meetings) for 45 days after
this announcement, even if they have not yet re-joined the group. After
45 days (ie. September 10, 2015), ongoing participation (including
meeting attendance and voting) is only permitted for those who have
re-joined the group.

Use this form to (re)join:
=C2=A0 =C2=A0https://www.w3.org/2004/01/pp-impl/47318/= join

Instructions to join the group are available at:
=C2=A0 http://www.w3.org/2004/01/pp-impl/47318/i= nstructions

Thanks,
Vivien on behalf of the WebRTC WG Chairs and Staff contacts

[1] http://www.w3.org/2015/07/webrtc-charter.html [2]
https://lists.w3.org/Archive= s/Member/w3c-ac-members/2015JulSep/0024.html

--
Vivien Lacourba=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 World Wide Web Consortium
vivien@w3.org=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.w3.org http://www.w3.org/People/Vivien=C2=A0 =C2=A0 =C2=A0 Tel: +33.4.92.38.78.89




--
Victor Pascual =C3=81vila
--047d7bf0c59c514c29051bdc1bff-- From nobody Mon Jul 27 11:54:58 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D401ACD09; Sat, 25 Jul 2015 12:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyQkSR2p9OtE; Sat, 25 Jul 2015 12:57:54 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC5C1ACD44; Sat, 25 Jul 2015 12:57:53 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so65084425wic.1; Sat, 25 Jul 2015 12:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jMmGnAF1G1vfjaQLE/Xy5nW4zEo1x8J4L8QgDIW9+Dc=; b=RSz3Sq+L/KzoPgwrmeV0RmUATMQBM4iVHuSc8Dm4UfFxdRge0tkIIW631dMqoXr/iH tMNZCHfvNRZOqAYpFcucqHTf4Oja6/qC+daCNtiDC5bhnrpQWvewGwCOGdctB20m/HOC idBH9pDqva+qmrRi8YPUX0N64mnBGA0sYx5tSlTt1x1H9Cs664/CQWukBfkgjh0xmKR0 Qn2JTdpbEFAXF7TbTUpFS2T5ppCxN0Nc7zabB1LgpADlwd5TQamQxZhFncODplqfFEwr rc81fMohbD496oxfsIJYA7WcoJkNkPk1Y3nbRXC0XYA13wl7+okcxOCwAME9DY7hPGfJ 9TzQ== X-Received: by 10.194.175.233 with SMTP id cd9mr39142466wjc.68.1437854272462; Sat, 25 Jul 2015 12:57:52 -0700 (PDT) Received: from [192.168.0.4] (cpc11-brig18-2-0-cust561.3-3.cable.virginm.net. [81.100.118.50]) by smtp.gmail.com with ESMTPSA id ev2sm4715691wib.21.2015.07.25.12.57.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Jul 2015 12:57:51 -0700 (PDT) Message-ID: <55B3EA3E.1030909@gmail.com> Date: Sun, 26 Jul 2015 07:57:50 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: richard.vandet@kpn.com, david.black@emc.com References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Mon, 27 Jul 2015 11:54:45 -0700 Cc: karen.nielsen@tieto.com, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 19:57:57 -0000 X-List-Received-Date: Sat, 25 Jul 2015 19:57:57 -0000 On 25/07/2015 18:01, richard.vandet@kpn.com wrote: > Sometimes legislation prohibits the QoS model over open internet, all t= raffic must be treated the same. That is a problem for operators (and their lawyers). Actually I don't thi= nk that either the EU regulations or the FCC rules prevent diffserv, as long as i= t isn't used to discriminate against individual content providers. But as far as = the IETF is concerned, I believe we should ignore this completely. It's our job to= define technical methods to support QoS. It's not our job to decide who uses tho= se methods. Brian >=20 > A VPN may be a solution, based on a SPs services model like Voice. Sett= ing up a VPN on the fly once the connection is established may suit the n= eeds of a developer. >=20 > Richard >=20 > Op 24 jul. 2015 om 14:29 heeft Black, David > het volgende geschreven: >=20 > >=20 >> All DSCPs, which have not been negotiated between access and interconn= ection are possibly bleached, especially if a network >> provider operates QoS within the network. >=20 > =E2=80=9Cpossibly=E2=80=9D -> =E2=80=9Cprobably=E2=80=9D -> =E2=80=9Cal= most certainly=E2=80=9D depending on the network (YMMV). >=20 >> I=E2=80=99d like to read a little more about how WEBrtc figures out wh= ich QoS resources are configured and which of these are available >> for such a flow at an access when required. How and where are the reso= urces consumed by each WERrtc PHB controlled and >> how are these aligned with the QoS resources consumed by other service= s? >=20 > The short Web RTC answer to all of the above =E2=80=9Cit doesn=E2=80=99= t do that=E2=80=9D. The DSCPs are in effect QoS service requests that th= e various networks involved may deal with as they wish. Bleaching is one= possibility (in effect an =E2=80=9CI don=E2=80=99t do that=E2=80=9D resp= onse to the request). Even in that case, there may be value in DSCP usag= e for forwarding by equipment between the browser and the interface to th= e ISP=E2=80=99s network (e.g., residential router/NAT/AP box). >=20 > In spite of all of the above, I have been told of good experiences with= use of CS2 for gaming and CS1 for lower effort (less than best effort), = plus EF use for gaming was mentioned in the tsvwg meeting yesterday. >=20 > This is not the first time I=E2=80=99ve heard a request for a =E2=80=9C= what QoS services are available via which DSCPs?=E2=80=9D interface/proto= col. I don=E2=80=99t know of one, and I=E2=80=99m not sure how to incent= ivize deployment if we designed one. >=20 > What is likely to happen is that if certain types of traffic favor spec= ific DSCPs, then operators who want to improve the user experience of tho= se who send/receive such traffic may put in QoS mechanisms for such traff= ic keyed by those DSCPs at network ingress. OTOH, a =E2=80=9Ctragedy of = the commons=E2=80=9D is possible here, e.g., the story in tsvwg about how= a lot of non-voice traffic showing up marked as if it were voice resulte= d in the network operator removing that special treatment of (residential= , I presume) voice traffic. >=20 > >=20 > Thanks, > --David >=20 > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Ruediger.Geib@= telekom.de > Sent: Friday, July 24, 2015 5:33 AM > To: karen.nielsen@tieto.com > Cc: Michael.Tuexen@lurchi.franken.de; rtcweb@ietf.org; tsvwg@ietf.org; fluffy@iii.ca > Subject: Re: [tsvwg] diffserv marking for rtcwb data channel >=20 > Hi Karen, >=20 > QoS needs to be commercially negotiated at interconnection. If QoS sho= uld be available at a consumer access, the consumer division of a company= must be involved in addition as well as the technical staff setting up a= nd maintaining technical configurations. 11 PHBs for a single consumer se= rvice are a challenging requirement. >=20 > All DSCPs, which have not been negotiated between access and interconne= ction are possibly bleached, especially if a network provider operates Qo= S within the network. >=20 > QoS to me means overprovisioning to ensure transport free of congestion= =2E If I see 11 PHBs for a single flow, I=E2=80=99m not sure if this assu= mes more than CoS (drop me last). I=E2=80=99d like to read a little more = about how WEBrtc figures out which QoS resources are configured and which= of these are available for such a flow at an access when required. How a= nd where are the resources consumed by each WERrtc PHB controlled and how= are these aligned with the QoS resources consumed by other services? >=20 > Regards, >=20 > Ruediger >=20 > Von: Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com] > Gesendet: Freitag, 24. Juli 2015 10:28 > An: Geib, R=C3=BCdiger > Cc: rtcweb@ietf.org; tsvwg@ietf.org; Michael Tuexen; fluffy@iii.ca > Betreff: RE: [tsvwg] diffserv marking for rtcwb data channel >=20 > Hi Ruediger, >=20 > Thanks a lot. >=20 > So I think that you=E2=80=99re saying that even if one made sure that d= ifferent diff serv markings were > split on different 5-tuples, this setting likely would be bleached at t= he network. >=20 > Is that correctly understood ? >=20 > If so, then (it sounds to me =E2=80=93 not knowing too much about this)= that from a coupling congestion control perspective it > would be preferable to use SCTP scheduling prioritization (within one = and the same association) for fine granular differentiation in between > multiple data channels in between the same end-points rather than diffe= rentiation by means of diff serv marking. >=20 > When/if one get a more consistent and forceful ECN operation in AQMs an= d SCTP end-points, perhaps the coupling congestion > principles achieved by means of sctp stream scheduling get to be less i= mportant. > On the other hand, again as said before, having the one and the same, o= r multiple, flow control (receiver buffer) contexts may be > a strength (simplicity) or a weakness. >=20 > BR, Karen >=20 > From: Ruediger.Geib@telekom.de [mailto= :Ruediger.Geib@telekom.de] > Sent: Friday, July 24, 2015 10:00 AM > To: karen.nielsen@tieto.com > Cc: rtcweb@ietf.org; tsvwg@ietf.org > Subject: AW: [tsvwg] diffserv marking for rtcwb data channel >=20 > Karen, >=20 > Finally there was a comment at the tsvwg meeting that the same 5-= tuple with > different diffserv markings would not get through the network =E2= =80=93 if that generally > is correct, then the solution is very easy: one MUST use differ= ent associations to > get port (5-tuple) differentiation. > I think that if this is correct, one also wants to ask what happ= ens if the diffserv is > changed for the same 5-tuple =E2=80=93 i.e., is the network robu= st to this change even if > it is not robust to concurrent usage of different markings for t= he same 5-tuple. >=20 > Talking about the policies of the company I work for only: >=20 > Possibilities to enforce QoS policies at a provider BRAS or BNG termina= ting wired > consumer accesses are limited. QoS policies based on full 5 tuple are v= ery > conservative and hard to maintain. I wouldn=E2=80=99t expect full 5 tup= le as basis for a QoS > policy then. Trust in the correct information on which a BRAS/BNG can > base QoS classification is an important issue. In any case, I=E2=80=99d= not expect > more than one DSCP is assigned based on such a policy for the time > being. I=E2=80=99m not aware of any actual requirement to support e.g. = an AFn > class by all three PHBs. >=20 > At interconnection points, any unexpected DSCP is bleached. This must > be done to protect backbone QoS production. QoS transport can be > negotiated for a set of defined DSCPs. >=20 > A study of the EU found DPI to be more common in wireless communication= than in wired communication. I=E2=80=99d not expect the QoS policies in = that area to be more liberal than for fixed access networks for the time = being. >=20 > Regards, >=20 > Ruediger >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Jul 27 11:54:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6841ACEC0; Mon, 27 Jul 2015 00:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaPl8vsMDE9V; Mon, 27 Jul 2015 00:46:46 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E03F1ACED8; Mon, 27 Jul 2015 00:46:44 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail31.telekom.de with ESMTP; 27 Jul 2015 09:46:43 +0200 X-IronPort-AV: E=Sophos;i="5.15,551,1432591200"; d="scan'208,217";a="878847795" Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 27 Jul 2015 09:46:26 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by he110890 ([10.134.92.131]) with mapi; Mon, 27 Jul 2015 09:46:26 +0200 From: To: , Date: Mon, 27 Jul 2015 09:46:25 +0200 Thread-Topic: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel Thread-Index: AQHQxp9NpXXrCvhxn0aB/GaSr+KRfp3u7D3Q Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CA7A7C64CC4ADB458B74477EA99DF6F50529674941HE111643EMEA1_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 27 Jul 2015 11:54:43 -0700 Cc: karen.nielsen@tieto.com, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 07:46:54 -0000 --_000_CA7A7C64CC4ADB458B74477EA99DF6F50529674941HE111643EMEA1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard, David, on the last mile of a consumer access, Deutsche Telekom operates QoS. To pr= oduce QoS with flows having a high bandwidth as compared to the available r= esources of a class, admission control is required. That means control plan= e interaction with a service platform for all streams consuming QoS resourc= es. This includes awareness of the access resources available per QoS class= . QoS interconnection with Deutsche Telekom's Voice platform is offered and o= perational. A VPN is used. Available PHBs and DSCPs are specified. Also the= per flow signaling and payload properties are specified to some extent. A VPN or an outer tunnel CoS / inner tunnel CoS scheme is useful if - no admission control or "live and let live" cooperation respecti= vely between flows requesting QoS support in the last mile is intended. - the outer tunnel QoS may be Best Effort or another CoS like solu= tion (a don't drop me first, but drop me before any QoS traffic gets droppe= d approach). - Then the inner tunnel can carry any DSCP desired and the outer t= unnel may consist of one or two markings. The latter may have a chance to b= e carried end-to-end. Another option may be to mark admission controlled traffic by DSCP a and pr= oduce WebRTC with DSCP b and c in the same queue, however making sure that= during congestion in that class all traffic without admission control (Web= RTC) gets dropped before traffic with admission control is dropped. Regards, Ruediger Von: richard.vandet@kpn.com [mailto:richard.vandet@kpn.com] Gesendet: Samstag, 25. Juli 2015 08:01 An: david.black@emc.com Cc: Geib, R=FCdiger; karen.nielsen@tieto.com; rtcweb@ietf.org; tsvwg@ietf.o= rg Betreff: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel Sometimes legislation prohibits the QoS model over open internet, all traff= ic must be treated the same. A VPN may be a solution, based on a SPs services model like Voice. Setting = up a VPN on the fly once the connection is established may suit the needs o= f a developer. Richard Op 24 jul. 2015 om 14:29 heeft Black, David > het volgende geschreven: > All DSCPs, which have not been negotiated between access and interconnect= ion are possibly bleached, especially if a network > provider operates QoS within the network. "possibly" -> "probably" -> "almost certainly" depending on the network (YM= MV). > I'd like to read a little more about how WEBrtc figures out which QoS res= ources are configured and which of these are available > for such a flow at an access when required. How and where are the resourc= es consumed by each WERrtc PHB controlled and > how are these aligned with the QoS resources consumed by other services? The short Web RTC answer to all of the above "it doesn't do that". The DSC= Ps are in effect QoS service requests that the various networks involved ma= y deal with as they wish. Bleaching is one possibility (in effect an "I do= n't do that" response to the request). Even in that case, there may be val= ue in DSCP usage for forwarding by equipment between the browser and the in= terface to the ISP's network (e.g., residential router/NAT/AP box). In spite of all of the above, I have been told of good experiences with use= of CS2 for gaming and CS1 for lower effort (less than best effort), plus E= F use for gaming was mentioned in the tsvwg meeting yesterday. This is not the first time I've heard a request for a "what QoS services ar= e available via which DSCPs?" interface/protocol. I don't know of one, and= I'm not sure how to incentivize deployment if we designed one. What is likely to happen is that if certain types of traffic favor specific= DSCPs, then operators who want to improve the user experience of those who= send/receive such traffic may put in QoS mechanisms for such traffic keyed= by those DSCPs at network ingress. OTOH, a "tragedy of the commons" is po= ssible here, e.g., the story in tsvwg about how a lot of non-voice traffic = showing up marked as if it were voice resulted in the network operator remo= ving that special treatment of (residential, I presume) voice traffic. Thanks, --David From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Ruediger.Geib@tele= kom.de Sent: Friday, July 24, 2015 5:33 AM To: karen.nielsen@tieto.com Cc: Michael.Tuexen@lurchi.franken.de; rtcweb@ietf.org; tsvwg@ietf.org; fluffy@iii.ca Subject: Re: [tsvwg] diffserv marking for rtcwb data channel Hi Karen, QoS needs to be commercially negotiated at interconnection. If QoS should = be available at a consumer access, the consumer division of a company must = be involved in addition as well as the technical staff setting up and maint= aining technical configurations. 11 PHBs for a single consumer service are = a challenging requirement. All DSCPs, which have not been negotiated between access and interconnectio= n are possibly bleached, especially if a network provider operates QoS with= in the network. QoS to me means overprovisioning to ensure transport free of congestion. If= I see 11 PHBs for a single flow, I'm not sure if this assumes more than Co= S (drop me last). I'd like to read a little more about how WEBrtc figures o= ut which QoS resources are configured and which of these are available for = such a flow at an access when required. How and where are the resources con= sumed by each WERrtc PHB controlled and how are these aligned with the QoS = resources consumed by other services? Regards, Ruediger Von: Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com] Gesendet: Freitag, 24. Juli 2015 10:28 An: Geib, R=FCdiger Cc: rtcweb@ietf.org; tsvwg@ietf.org; Michael Tuexen; fluffy@iii.ca Betreff: RE: [tsvwg] diffserv marking for rtcwb data channel Hi Ruediger, Thanks a lot. So I think that you're saying that even if one made sure that different dif= f serv markings were split on different 5-tuples, this setting likely would be bleached at the n= etwork. Is that correctly understood ? If so, then (it sounds to me - not knowing too much about this) that from a= coupling congestion control perspective it would be preferable to use SCTP scheduling prioritization (within one and = the same association) for fine granular differentiation in between multiple data channels in between the same end-points rather than different= iation by means of diff serv marking. When/if one get a more consistent and forceful ECN operation in AQMs and SC= TP end-points, perhaps the coupling congestion principles achieved by means of sctp stream scheduling get to be less impor= tant. On the other hand, again as said before, having the one and the same, or mu= ltiple, flow control (receiver buffer) contexts may be a strength (simplicity) or a weakness. BR, Karen From: Ruediger.Geib@telekom.de [mailto:Rue= diger.Geib@telekom.de] Sent: Friday, July 24, 2015 10:00 AM To: karen.nielsen@tieto.com Cc: rtcweb@ietf.org; tsvwg@ietf.org Subject: AW: [tsvwg] diffserv marking for rtcwb data channel Karen, Finally there was a comment at the tsvwg meeting that the same 5-tupl= e with different diffserv markings would not get through the network - if t= hat generally is correct, then the solution is very easy: one MUST use different = associations to get port (5-tuple) differentiation. I think that if this is correct, one also wants to ask what happens = if the diffserv is changed for the same 5-tuple - i.e., is the network robust to this c= hange even if it is not robust to concurrent usage of different markings for the s= ame 5-tuple. Talking about the policies of the company I work for only: Possibilities to enforce QoS policies at a provider BRAS or BNG terminating= wired consumer accesses are limited. QoS policies based on full 5 tuple are very conservative and hard to maintain. I wouldn't expect full 5 tuple as basis = for a QoS policy then. Trust in the correct information on which a BRAS/BNG can base QoS classification is an important issue. In any case, I'd not expect more than one DSCP is assigned based on such a policy for the time being. I'm not aware of any actual requirement to support e.g. an AFn class by all three PHBs. At interconnection points, any unexpected DSCP is bleached. This must be done to protect backbone QoS production. QoS transport can be negotiated for a set of defined DSCPs. A study of the EU found DPI to be more common in wireless communication tha= n in wired communication. I'd not expect the QoS policies in that area to b= e more liberal than for fixed access networks for the time being. Regards, Ruediger _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CA7A7C64CC4ADB458B74477EA99DF6F50529674941HE111643EMEA1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --047d7bb03a921b3056051bdffddb-- From nobody Mon Jul 27 12:10:03 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDF81B3265 for ; Mon, 27 Jul 2015 12:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awiFbYQMyvzT for ; Mon, 27 Jul 2015 12:10:00 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750F71B32A4 for ; Mon, 27 Jul 2015 12:09:33 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so105745307igb.0 for ; Mon, 27 Jul 2015 12:09:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dzX3hS1KCAYE8DN0/GbLOEo3uC6Yq9LxAmZ94pNOj+g=; b=ldPsJF1Ijg0kVRr6ysq/eOv4UaFmvC2FAUFxi355F1IubHBut3rb8H0SWh3liP6Jdg 8GibEj/2ru4380R5CNkdhgd74ybaH6WK6wc72KQkLqzd12JMuCIuKVHCq3HVRsMF9WQC QTQKuvYhK+i57iEUfTe3QOMgR0Oxj+zrR6eTwokZS4fkmTM5jcxUP0mi6GPvurN+0HZG pTLUONOVCHArgGs0RR/anocCOwXWAxFu9YhkjrW4UB79Nr+IJwb2jfIs6YlCXqoo5s4b S23L4Av7f0Xt2em9qpE5W8uJ04dTbKdl1/n44XkV68sMuxcqV8fwBKmiQglnibYLcW8j Tt9Q== X-Gm-Message-State: ALoCoQmtfGA8Eiz/oKh4jimn0phWXQ6tOA05WRjtHttlkYZG36NvwFMmjQlGikiO/efxxRFhfsfo X-Received: by 10.50.43.137 with SMTP id w9mr20306082igl.30.1438024172867; Mon, 27 Jul 2015 12:09:32 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com. [209.85.213.178]) by smtp.gmail.com with ESMTPSA id j2sm12503745ioo.43.2015.07.27.12.09.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2015 12:09:31 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so105743805igb.0 for ; Mon, 27 Jul 2015 12:09:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.7.214 with SMTP id g83mr49994476ioi.28.1438024170655; Mon, 27 Jul 2015 12:09:30 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Mon, 27 Jul 2015 12:09:30 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> Date: Mon, 27 Jul 2015 15:09:30 -0400 Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=001a113f911cded4f5051be01709 Archived-At: Cc: "rtcweb@ietf.org" , Tim Panton Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 19:10:01 -0000 --001a113f911cded4f5051be01709 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 27, 2015 at 3:02 PM, Ted Hardie wrote: > =E2=80=8BSo, the work of MIF got mentioned during the IETF WG meeting, bu= t I'm not > sure that folks have its coordinates; just in case, the documents are all > here: > > http://datatracker.ietf.org/wg/mif/documents/ > > It's the right IETF venue to discuss the general question of how to manag= e > multiple interfaces. > > Is this the right venue to discuss how ICE should handle multiple interfaces as well? _____________ Roman Shpount --001a113f911cded4f5051be01709 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 27, 2015 at 3:02 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
=E2=80=8BSo, the= work of MIF got mentioned during the IETF WG meeting, but I'm not sure= that folks have its coordinates; just in case, the documents are all here:=

http://datatracker.ietf.org/wg/mif/documents/

It's the righ= t IETF venue to discuss the general question of how to manage multiple inte= rfaces.


Is this the right venue to discuss how ICE should handle mult= iple interfaces as well?
_____________<= br>Roman Shpount
=C2=A0
--001a113f911cded4f5051be01709-- From nobody Mon Jul 27 12:27:11 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BF71B32E8 for ; Mon, 27 Jul 2015 12:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LC7GFedjGfY for ; Mon, 27 Jul 2015 12:27:09 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FEE1B32EE for ; Mon, 27 Jul 2015 12:27:08 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so126264662wic.1 for ; Mon, 27 Jul 2015 12:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NZpgBHRcMFP0OOXDzp1cb5sG1GbAbUxBnBv9zkjh+8g=; b=qTSCfvxmZZyjlMCSu1BK697s1cUlI6nfNMPv7UDUTgjocOdQGWkj5IUJPWmydWpmrN feTsxGedx9SJX/l8BMWaRSs/GyY2DB9VQjZpshgGg7m26h8I2QFYyFKBVS2tvzueRYmV dbA5tnIg7W6MkGgvYRsywXPH1CvUOiX8+5bVsAc2NNQu5xxVSi6Q7YEANQpJ3tGhsfV3 W3zmAEgn5LxkMj/xAaEsYjKgN/or4bE7H/ArpBAj8BU6+Kg9iXKBcs+IV81/RjqtktMp mxySHOmFuZ68lJyIzUusRoVtbuSFjBxIsERT3jERZIQn1NDsOgA/WcCEHq9xc3NEdy3j 4GYw== MIME-Version: 1.0 X-Received: by 10.194.187.170 with SMTP id ft10mr57314231wjc.26.1438025226836; Mon, 27 Jul 2015 12:27:06 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Mon, 27 Jul 2015 12:27:06 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> Date: Mon, 27 Jul 2015 12:27:06 -0700 Message-ID: From: Ted Hardie To: Roman Shpount Content-Type: multipart/alternative; boundary=047d7bb03a92d2e0fa051be0568d Archived-At: Cc: "rtcweb@ietf.org" , Tim Panton Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 19:27:10 -0000 --047d7bb03a92d2e0fa051be0568d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 27, 2015 at 12:09 PM, Roman Shpount wrote: > On Mon, Jul 27, 2015 at 3:02 PM, Ted Hardie wrote: > >> =E2=80=8BSo, the work of MIF got mentioned during the IETF WG meeting, b= ut I'm >> not sure that folks have its coordinates; just in case, the documents ar= e >> all here: >> >> http://datatracker.ietf.org/wg/mif/documents/ >> >> It's the right IETF venue to discuss the general question of how to >> manage multiple interfaces. >> >> > Is this the right venue to discuss how ICE should handle multiple > interfaces as well? > =E2=80=8B I don't think that question has enough detail to answer. For ICE, the current theory is questions on what ICE does with the interface information it has go to MMUSIC, though that may get updated to a dedicated group. MIF would be for discussing what interface states get surfaced and when. (Other views of this are possible, of course, and your mileage may vary when posting). Ted --047d7bb03a92d2e0fa051be0568d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 27, 2015 at 12:09 P= M, Roman Shpount <roman@telurix.com> wrote:
On Mon, Jul 27, 2= 015 at 3:02 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
=E2=80=8BSo, the work of MIF = got mentioned during the IETF WG meeting, but I'm not sure that folks h= ave its coordinates; just in case, the documents are all here:

http= ://datatracker.ietf.org/wg/mif/documents/

It's the right IETF venue = to discuss the general question of how to manage multiple interfaces.

=

Is this the right = venue to discuss how ICE should handle multiple interfaces as well?
=E2=80=8B
I don't think that question has enough detail to answer.=C2=A0 For= ICE, the current theory is questions on what ICE does with the interface i= nformation it has go to MMUSIC, though that may get updated to a dedicated = group.=C2=A0 MIF would be for discussing what interface states get surfaced= and when.


(Other views of this are possible, of= course, and your mileage may vary when posting).

Ted
=C2=A0
--047d7bb03a92d2e0fa051be0568d-- From nobody Tue Jul 28 05:35:19 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFB71A8A5E; Tue, 28 Jul 2015 05:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2pVRtZEbGMk; Tue, 28 Jul 2015 05:35:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9DC1A8A90; Tue, 28 Jul 2015 05:35:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.2.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150728123512.3082.72636.idtracker@ietfa.amsl.com> Date: Tue, 28 Jul 2015 05:35:12 -0700 Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org Subject: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jul 2015 12:35:18 -0000 Barry Leiba has entered the following ballot position for draft-ietf-rtcweb-stun-consent-freshness-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple of very minor comments only: FWIW, I think rtcweb-security-arch need only be an informative reference; it seems only explanatory. I also think that about RFC 6263. -- Section 5.1 -- A full ICE implementation obtains consent to send using ICE. After ICE concludes on a particular candidate pair and whenever the endpoint sends application data on that pair consent MUST be maintained following the procedure described in this document. I don't understand the "MUST" here, given that Section 4 says this is "an optional extension". Why "MUST", then, rather than "can be"? From nobody Tue Jul 28 06:04:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C958F1A8AB5; Tue, 28 Jul 2015 06:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fcxt0vdNHtDP; Tue, 28 Jul 2015 06:04:21 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ACB11A8AB8; Tue, 28 Jul 2015 06:04:14 -0700 (PDT) Received: by lagw2 with SMTP id w2so68071584lag.3; Tue, 28 Jul 2015 06:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jWliR1JNd/u0DFW/iYsFZHWuOjZNkrXJxhp59CDX7Gk=; b=gDi5sDxmNiomLN9XBAXe7kwq89Ofx2ml890A4gZ7dkh4rX0pml6o4n6LajNhFbqkzO PsykoGwaZx1d/AHH03bDt21tsglUBynBGdhvOFW+yaD2j4RfS1k7tB2f+yX4hmMtguQ6 8mqjXqh1WIR+dXGpI4QSoJVGEF60fubRHeGZVYnWQUh792CwGXhYcFkc+2UZj95Kt6YL sln99YeZVbddmCielJRgk8gaFCvyJa7j3n4FMRzReU+8lGb+mSKa2CZlDd/LmQ2mrRzU gPm7MpIcaMDsV2/jW+BAYSCKrPrGct3c4TulVXMOEWid2MoqLWhOMPVvmd5ybxkZEYsQ 7/UQ== MIME-Version: 1.0 X-Received: by 10.112.72.8 with SMTP id z8mr32243927lbu.24.1438088653164; Tue, 28 Jul 2015 06:04:13 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Tue, 28 Jul 2015 06:04:13 -0700 (PDT) In-Reply-To: <20150728123512.3082.72636.idtracker@ietfa.amsl.com> References: <20150728123512.3082.72636.idtracker@ietfa.amsl.com> Date: Tue, 28 Jul 2015 15:04:13 +0200 Message-ID: From: Martin Thomson To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, "rtcweb@ietf.org" , The IESG , draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org Subject: Re: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 13:04:23 -0000 On 28 July 2015 at 14:35, Barry Leiba wrote: > FWIW, I think rtcweb-security-arch need only be an informative reference; > it seems only explanatory. I also think that about RFC 6263. > > -- Section 5.1 -- > > A full ICE implementation obtains consent to send using ICE. After > ICE concludes on a particular candidate pair and whenever the > endpoint sends application data on that pair consent MUST be > maintained following the procedure described in this document. > > I don't understand the "MUST" here, given that Section 4 says this is "an > optional extension". Why "MUST", then, rather than "can be"? The extension might be optional, but we need to be clear about what is mandatory and not within the mechanism itself. Note that this *won't* be optional for WebRTC implementations (browsers, certainly, maybe other classes of implementation too). From nobody Tue Jul 28 06:07:49 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183C01A8AB8; Tue, 28 Jul 2015 06:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFGuf-Scz70R; Tue, 28 Jul 2015 06:07:47 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60BAE1A8AC4; Tue, 28 Jul 2015 06:07:41 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so159891446wib.1; Tue, 28 Jul 2015 06:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zOgRuEVWot0TNGQy+88iu+1VQs0V8sdBn1rKNlz69WM=; b=b1J6vDeuwnzlDC8USWN3WpZRv/mlaSUfLMAnzTUMz9xm2DzbpzhwCWaBMz0SFUlVcc d3tJZUn3sz5Q3O4EUJh6FDbPfPh67htXZTz3qTqiHi63qAP8d+6ONwgvv1hpa3cZMZ3x KZvgvxYY5Y9mvLAJ1dSGcxn0jIldOFGj65HifHOkr9V1lMgKYuI9m12h6X9R3+e2g4W6 uT05iq6JkarS09Bj9rcNIpT1NAFxFWHuva/7crmMBdo7zsbYdCNb6Dxn8DQ1Pbe2ovXe lpWhmbBXwQ5bPg+pO5EWjon4RRbeluZgjnLmHRBK6DjFZpTbVmpvyK3wIfWVvuWoM6bM 02Mw== MIME-Version: 1.0 X-Received: by 10.194.2.51 with SMTP id 19mr70039659wjr.40.1438088860169; Tue, 28 Jul 2015 06:07:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.28.1.79 with HTTP; Tue, 28 Jul 2015 06:07:40 -0700 (PDT) In-Reply-To: References: <20150728123512.3082.72636.idtracker@ietfa.amsl.com> Date: Tue, 28 Jul 2015 15:07:40 +0200 X-Google-Sender-Auth: rg8xrbbocq5pAf-eJD_VX36XaZA Message-ID: From: Barry Leiba To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, "rtcweb@ietf.org" , The IESG , draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org Subject: Re: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 13:07:48 -0000 >> A full ICE implementation obtains consent to send using ICE. After >> ICE concludes on a particular candidate pair and whenever the >> endpoint sends application data on that pair consent MUST be >> maintained following the procedure described in this document. >> >> I don't understand the "MUST" here, given that Section 4 says this is "an >> optional extension". Why "MUST", then, rather than "can be"? > > The extension might be optional, but we need to be clear about what is > mandatory and not within the mechanism itself. That's why I think the *other* MUSTs and SHOULDs are fine. But *this* one says "MUST use the procedure in this document", which doesn't seem right. (But, as I said, a minor comment.) > Note that this *won't* be optional for WebRTC implementations > (browsers, certainly, maybe other classes of implementation too). Sure, but then those should say "MUST use ". Barry From nobody Tue Jul 28 06:22:09 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0D31A8BB6; Tue, 28 Jul 2015 06:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtDxLqMcZogq; Tue, 28 Jul 2015 06:22:01 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80AC01A8BB3; Tue, 28 Jul 2015 06:22:01 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so74517488lbb.0; Tue, 28 Jul 2015 06:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AuRYX2SLz6HDMwl5pooRexYXfcGptk/UhXkAyfjKt9Q=; b=DajDu+L+odx5YS7Ft3OKa7idcaRDqSsuDQos81RPJbHuuBMBgtk8DtUeA9UrzABdaI J1vwBkWmhPatWsvxUGDJGFtTBCM5402JoVDFRT1mGut/x9sEe/qh8Dkoy5HKGpL3R3Fp lVSy7GNBTuwFXN0k1xEWspufaci/tQ/FnhbAqUNt3kF7bOdQwND6++MRE5U4pDnTYYYx 8wKNvBWVxZhF+fn+yVX0TGdwT7Tr6QnKxRh+YzxPNL39O0vfdHRQCU+Cev73GkG5Qnkm AAWe6SmPLWLB8AGlIIowGiOifPhgKw/BAdxLMQYeUXZtHTZTcrXwkVUQqpGljZhi7jTK A9kA== MIME-Version: 1.0 X-Received: by 10.112.72.8 with SMTP id z8mr32358329lbu.24.1438089720073; Tue, 28 Jul 2015 06:22:00 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Tue, 28 Jul 2015 06:22:00 -0700 (PDT) In-Reply-To: References: <20150728123512.3082.72636.idtracker@ietfa.amsl.com> Date: Tue, 28 Jul 2015 15:22:00 +0200 Message-ID: From: Martin Thomson To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, "rtcweb@ietf.org" , The IESG , draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org Subject: Re: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 13:22:08 -0000 On 28 July 2015 at 15:07, Barry Leiba wrote: > That's why I think the *other* MUSTs and SHOULDs are fine. But *this* > one says "MUST use the procedure in this document", which doesn't seem > right. (But, as I said, a minor comment.) I don't think that we lose anything by changing the "MUST be" to "is": > A full ICE implementation obtains consent to send using ICE. After > ICE concludes on a particular candidate pair and whenever the > endpoint sends application data on that pair consent is > maintained following the procedure described in this document. Axiomatic wins against prescriptive generally for me. From nobody Wed Jul 29 23:33:03 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEEA1A7008 for ; Wed, 29 Jul 2015 23:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGfaL9KY2ATm for ; Wed, 29 Jul 2015 23:33:00 -0700 (PDT) Received: from ar-005-i191.relay.mailchannels.net (ar-005-i191.relay.mailchannels.net [162.253.144.73]) by ietfa.amsl.com (Postfix) with ESMTP id AA67C1A7005 for ; Wed, 29 Jul 2015 23:32:59 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id 752DD120947 for ; Thu, 30 Jul 2015 06:32:57 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.251.34.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Thu, 30 Jul 2015 06:32:57 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1438237977668:1014322427 X-MC-Ingress-Time: 1438237977668 Received: from pool-108-36-235-74.phlapa.fios.verizon.net ([108.36.235.74]:63010 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZKhOh-0004dh-7T for rtcweb@ietf.org; Thu, 30 Jul 2015 01:32:55 -0500 Message-ID: <55B9C503.4050807@jesup.org> Date: Thu, 30 Jul 2015 02:32:35 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 06:33:02 -0000 Note: responding to an older message. Also, Mozilla is planning to land a number of optional controls for ICE candidate generation and TURN server use. We also plan to add hooks that extensions can use to prompt (depending on circumstance) or monitor 'background' use of PeerConnections (without user-granted permission). On 7/11/2015 12:42 PM, Daniel Roesler wrote: > One of the items in the new proposal was "WebRTC already requires > permission to access getUserMedia. Why not use that permission to > control interface enumeration?" That item didn't really get discussed > much in the thread, but I think it's one of the most important issues. In addition to Kaufman's answer, I'll add that this would effectively make WebRTC unusable for users - and/or would destroy the utility of camera access requests (and WebRTC), due to user request-fatigue. (If you ask a user for permission too many times, especially for something they asked to do and the question is about something they don't really understand, they either a) always hit yes regardless of the question, or b) stop using the feature entirely, because it's too annoying.) Even camera-access requests are arguably a problem - but the alternative (granting permanent permission by default) is itself problematic. > Why? There is now a documented case where a third party on nytimes.com > is using a fake webRTC datachannel to silently gather user local (and > potentially "real" ISP) IP addresses. Sure, and gathering those for normal users is already trivially possible *without* webrtc - external IP's are trivial: whatismyipaddress.com, and for LAN addresses you can infer the LAN address with high probability by trying to load images from likely gateway addresses (192.168.0.1/192.168.1.1/10.0.0.1/etc) to find the likely subnet, and then scan the subnet using the same trick, recording the time-to-fail for each. That will map the entire list of devices on the LAN, and you may be able to infer from it which address is yours (probably the fastest failure). Note the LAN map itself is often a larger fingerprint reveal than the LAN IP address alone. And yes, I've seen real examples of these tricks. The case this doesn't directly cover fully is the "partial VPN" case, where someone has a VPN, but *also* still allows routing out directly without going through the VPN. This is already hugely risky if you're trying to maintain anonymity - it's a false sense of security. However it is at least a real concern, as is the "hiding at a shelter" case discussed a long time ago, where the issue is exposing external IP's to a remote caller (not to the service provider or STUN/TURN server). I will note that there are many ways someone can find your external IP address unless you're very paranoid and careful (never load images in email, etc). > So I'd like to voice my support for adding a consent requirement that > would prevent this type of silent behavior. A user that is > purposefully visiting a site that has a legitimate reason for using a > webRTC data channel will have the necessary context to give consent, > just like they have to get consent on getUserMedia. You could disable DataChannels and have the same problem, note - this would have to apply to all PeerConnections (think of a call with offerToReceiveAudio - no gUM request would be made). > I'm really unclear on why it's so important to have the silent webRTC > data channel behavior. P2P data connections should be held to the same > consent requirements just like P2P video and voice connections. They are. > In addition to the silent third party local IP tracking, a silent P2P > data channel opens up users to silently becoming nodes in a web-based > file sharing network. For example, webtorrent[2] can be silently > embedded on a website so that all of the users to that website start > seeding content they don't know they are seeding. Note we don't require permissions to open WebSockets either. While those don't allow P2P access, downloaded JS can use your CPU for bitcoin mining (though not efficiently yet), SETI searches, can store data and serve it back to the same (or other) servers, etc. > 1. Require user consent before calling the callback on createOffer(). > 2. If the user has already given consent via getUserMedia, the user > consent requirement is satisfied. > 3. If there's no previous gUM consent, then ask the user for consent. This could be done technically, and would cover the offerToReceiveAudio/Video case. And there are still ways this could be abused, though not as easily. It would cause people using WebRTC for the advantages DataChannels has over WebSockets to be annoyed (such as games). Anything that benefits from UDP-like semantics has cause to use WebRTC/DataChannels, even if it's just talking directly to the server, and this would put a huge roadblock in the face of such utility. Web-based games are starting to make use of DataChannels, and this would be a real problem for them. Working around this for access back to the server would require some variant of CORS (to bypass the request if it's back to the same origin you loaded the page from - and that means you'd make it trivial again for the site to find your IPs, which was the reason this was brought up). So that's not really useful. One thing that *could* be done is to create an option to force such requests; we can debate what the visibility of such an option should be, and what the defaults should be - but a designed-in option opens the door for trivial extensions to change the or to provide UI to expose it (either in prefs or in main browser chrome or in a modal popup). We could also flip the pref by default in private browsing mode, though that might require in-browser UI since random sites may trigger it. Speaking to the non-fingerprinting aspects of this which had previously been discussed: I understand your concerns, however the IP address exposure and LAN exposure is a red herring (and even more so in IPV6 world), except for the "I'm hiding" cases (poorly-configured VPN hiding or hiding from another user of the service). We do surface the ability to not only know what PeerConnections are in use, but also that have been in use, so you can vet if sites are actually making connections. Right now it doesn't list unconnected PeerConnections (used for IP address harvesting), but it could. One could also provide some sort of semi-persistent indicator of such background usage without requiring the user to interact with it. (See the hooks I mention at the top of this post.) -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't emailrandell-ietf@jesup.org! Way too much spam From nobody Thu Jul 30 10:43:06 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8451ACD2F for ; Thu, 30 Jul 2015 10:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INIF_n770cta for ; Thu, 30 Jul 2015 10:43:04 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820C01ACD03 for ; Thu, 30 Jul 2015 10:43:03 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so1757523wib.0 for ; Thu, 30 Jul 2015 10:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EeNktLWEQ5cNaK4ujEl6HbaHHA1lY9gJ6cm+O0Eym1c=; b=j8FhYZ3M7kEcuK5paa7P0Hj2DQtRpqU+lWV/5mN9eEba5vAK1h9pq6AdOVzjKTDN1n CxCwVAMD96bopOpCOnCIowdzytgRlWmg03ybOMADGNtIxRrC4yQh0maxhQcYHv/Pddvs 75c5fJZ8HrjOE8aqbiWHbQowi9t3kwyxYMIxH7J68x3P7PbtQD8qrdlTNq9mp2BHNvPh Un0NfM6cKqeBQubcmbYgTVhwKJOnnZMGAJRapS9tegKCKW7u0Nnl77NwJP9FoZgdJBu5 o8sVN2936pxV2gyXnfwRldn6UIMuK79h0LwR98Vx9V/ZSccREeaxY2VDltNKbccnWoi1 Z4MQ== MIME-Version: 1.0 X-Received: by 10.180.74.115 with SMTP id s19mr8299271wiv.18.1438278182304; Thu, 30 Jul 2015 10:43:02 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Thu, 30 Jul 2015 10:43:02 -0700 (PDT) Date: Thu, 30 Jul 2015 10:43:02 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Ted Hardie , Cullen Jennings Content-Type: multipart/alternative; boundary=f46d043c825a2502c0051c1b3c7d Archived-At: Subject: [rtcweb] Interim discussion? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 17:43:05 -0000 --f46d043c825a2502c0051c1b3c7d Content-Type: text/plain; charset=UTF-8 The chairs have discussed how to make progress between now and Yokohama, and it seems like another focused 2-3 hour meeting would be useful. That might be a completely virtual interim or one associated with the WebRTC interim, but with a remote participation component. If you have thoughts on that, please share them between now and August 7th, 2015. thanks, Ted, Cullen, Sean --f46d043c825a2502c0051c1b3c7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The chairs have discussed how to make progress b= etween now and Yokohama, and it seems like another focused 2-3 hour meeting= would be useful.=C2=A0 That might be a completely virtual interim or one a= ssociated with the WebRTC interim, but with a remote participation componen= t.=C2=A0

If you have thoughts on that, please share= them between now and August 7th, 2015.

thanks,
<= br>
Ted, Cullen, Sean
--f46d043c825a2502c0051c1b3c7d-- From nobody Thu Jul 30 11:54:25 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BA31A8BC0 for ; Thu, 30 Jul 2015 11:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIS-fwM3FCcx for ; Thu, 30 Jul 2015 11:54:23 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845C81A8BB0 for ; Thu, 30 Jul 2015 11:54:23 -0700 (PDT) Received: by obre1 with SMTP id e1so37671526obr.1 for ; Thu, 30 Jul 2015 11:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p7MEq7XPRruuld+OWiogZrnsSZYK0sN9mO/9rZQgvpU=; b=Z04+A7ALkaHVKdigYsxsHHs1sCC30A1gn3DZLyQhrs32WhgO/H1KSmV4yAr1AT51uM v8SOXAV5KlaYjS+kTR6i19aDqIVgl+3rURPtz1Gpq8K9Sxa5f8i0SnncMqmR6Haqps0e JgfTfo11I2yxYBtUoVk9PP3pkZ0sUrW2ByarNhvthDHcAsqhpOGhX0AiFEy4LMSgDdQn bJTYphfMc5x8AWcSijV+aAjKL0cfqRi9clLIDqXeXiuOdw6UkX1y5kb25vmrCM4WbkDw BlUb86KLp7BI6J4vwnu9OkKFpLe970wvwqVHngyqYnGA3iYj7Uz4opT7LdfBe5nyAfa8 AxYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p7MEq7XPRruuld+OWiogZrnsSZYK0sN9mO/9rZQgvpU=; b=OWQgxDALR+6uLILw6JJ6ZEuzOPCncbtwbsHDkIiFHlogzHT2ROW2ia91vLQby53QMA t12RWZ628wop7KQC6QC0tliwRqFiR3k0g37st+ejBOlh3uxaB/3PVoxUo0SCnhUX7vm5 yrquCz/8Wt+yaHuo1HwlNamOHFFCU1t4DIn7XxRSQc/mNPdEJ0nF2NLzdiPDCq2fwe8/ 5aEYiBAHxsEUlDACSy+7CaUdd8G0F7cJaC04wlVNivjxApDtVsbwpLIyx0/WN6BUGIO1 MAuRgw6LNTNFP7sGk5Ts8Z0/REkJzLErJNKKbM0n9wRNhSI/WMKJtwZDn6agd+zi/xwq CqcA== X-Gm-Message-State: ALoCoQkTwz61kAEOn5zow3zSzaGSt18BTtMko5VcpPRpTYSO6WHoAQY3T1E5eDDwtJTBzGqA5pIo X-Received: by 10.182.71.49 with SMTP id r17mr46357084obu.77.1438282462942; Thu, 30 Jul 2015 11:54:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.171.233 with HTTP; Thu, 30 Jul 2015 11:53:43 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Thu, 30 Jul 2015 11:53:43 -0700 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=e89a8fb1fa764a901e051c1c3b30 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Interim discussion? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 18:54:24 -0000 --e89a8fb1fa764a901e051c1c3b30 Content-Type: text/plain; charset=UTF-8 Making it a part of the W3C interim sounds like a good idea to me. We've done both IETF and W3C at interims in the past, and they have been productive (perhaps more productive than the non-interim meetings). On Thu, Jul 30, 2015 at 10:43 AM, Ted Hardie wrote: > The chairs have discussed how to make progress between now and Yokohama, > and it seems like another focused 2-3 hour meeting would be useful. That > might be a completely virtual interim or one associated with the WebRTC > interim, but with a remote participation component. > > If you have thoughts on that, please share them between now and August > 7th, 2015. > > thanks, > > Ted, Cullen, Sean > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --e89a8fb1fa764a901e051c1c3b30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Making it a part of the W3C interim sounds like a good = idea to me.=C2=A0 We've done both IETF and W3C at interims in the past,= and they have been productive (perhaps more productive than the non-interi= m meetings).

On Thu, Jul 30, 2015 at 10:43 AM, Ted Hardie <ted.ietf@gmail.com>= wrote:
The chairs have discussed how to make progress between now and Yokohama, a= nd it seems like another focused 2-3 hour meeting would be useful.=C2=A0 Th= at might be a completely virtual interim or one associated with the WebRTC = interim, but with a remote participation component.=C2=A0

If you have thoughts on that, please share them between now and Augu= st 7th, 2015.

thanks,

Ted, Cu= llen, Sean

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb


--e89a8fb1fa764a901e051c1c3b30-- From nobody Thu Jul 30 12:05:24 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727A81B2F8B for ; Thu, 30 Jul 2015 12:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw9dMRR1_Rse for ; Thu, 30 Jul 2015 12:05:21 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1F11B2F86 for ; Thu, 30 Jul 2015 12:05:21 -0700 (PDT) Received: by ioeg141 with SMTP id g141so63565150ioe.3 for ; Thu, 30 Jul 2015 12:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hRh5CPL+UsmdHhdSO1Dgkp8t7GkjmOmDBHAm78w1gBo=; b=xyJzctM6BkppC1lFL/VIXsTRCrYRy0yNi5pNGFKN//vrWsqSn9Jug4+0FhvdNBVvJX D/Vq+OMqFPeXE/87J/fTWqOnZZDTy3BI5XIAVIq9F23avUt4VX2qSWfzbG0Qcuf9zCMw A2gP5MYBgyJviv5Zi7UjQmypw+/TcEeHsmV8NR9LevNXExM4cdf//qGIClfMKspxkBzm SvjdNNRDz3D9YFy8qGCEAxN5RSUrN6EsV0N/0gzv6T3u2OsQQmMtLDuSIiYCYtMdTTHw 6wHezb6ETJhhICS2MlUFrzd15OAecPkFol3li0wMnBu51UK4x7MLADBesuvqe3/ITKRX JnEA== MIME-Version: 1.0 X-Received: by 10.107.30.209 with SMTP id e200mr13118972ioe.57.1438283120742; Thu, 30 Jul 2015 12:05:20 -0700 (PDT) Received: by 10.79.107.74 with HTTP; Thu, 30 Jul 2015 12:05:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 12:05:20 -0700 Message-ID: From: Suhas Nandakumar To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a1140c18a7f973e051c1c6255 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Interim discussion? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:05:23 -0000 --001a1140c18a7f973e051c1c6255 Content-Type: text/plain; charset=UTF-8 +1 On Thu, Jul 30, 2015 at 11:53 AM, Peter Thatcher wrote: > Making it a part of the W3C interim sounds like a good idea to me. We've > done both IETF and W3C at interims in the past, and they have been > productive (perhaps more productive than the non-interim meetings). > > On Thu, Jul 30, 2015 at 10:43 AM, Ted Hardie wrote: > >> The chairs have discussed how to make progress between now and Yokohama, >> and it seems like another focused 2-3 hour meeting would be useful. That >> might be a completely virtual interim or one associated with the WebRTC >> interim, but with a remote participation component. >> >> If you have thoughts on that, please share them between now and August >> 7th, 2015. >> >> thanks, >> >> Ted, Cullen, Sean >> >> _______________________________________________ >> 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 > > --001a1140c18a7f973e051c1c6255 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Thu, Jul 30, 2015 at 11:53 AM, Peter Thatcher = <pthatcher@goo= gle.com> wrote:
Making it a part of the W3C interim sounds like a good idea to me.= =C2=A0 We've done both IETF and W3C at interims in the past, and they h= ave been productive (perhaps more productive than the non-interim meetings)= .

On Thu, Jul 30, 2015 at 10:43 AM, Ted Hardie <ted.ietf@gmail= .com> wrote:
The chairs have discussed h= ow to make progress between now and Yokohama, and it seems like another foc= used 2-3 hour meeting would be useful.=C2=A0 That might be a completely vir= tual interim or one associated with the WebRTC interim, but with a remote p= articipation component.=C2=A0

If you have thoughts = on that, please share them between now and August 7th, 2015.

<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-siz= e:small">thanks,

Ted, Cullen, Sean

_______________________________________________
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


--001a1140c18a7f973e051c1c6255-- From nobody Thu Jul 30 12:18:11 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937831AC3D0 for ; Thu, 30 Jul 2015 12:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBXm3UlQWb0Q for ; Thu, 30 Jul 2015 12:18:08 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E851A92BA for ; Thu, 30 Jul 2015 12:18:08 -0700 (PDT) Received: by oigh16 with SMTP id h16so492543oig.0 for ; Thu, 30 Jul 2015 12:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=m92BRq3EHcpUSdl5e466wSCRJdh7z6VfHjIUyALr548=; b=eZqi3xV99TD4TbNa354ITF085REZh64z3ipoNwF3hJ03IgbSA38zpCm+suyt3qn3S2 Y5zGq4RsEWH9mvQHzbRFp6e8D5ajQA5cC5GDGQt13TfRFpTXm21moNiQ1KdcT9JLhg4q WnJTdmuP8N8cJLPaTexhKtsoZSOJm/e59NeezMg6MgGHUH/WXrMdmAGF9JPsQc07pZbw g6udTbLR4MC/+m55gUBwl1EiY5iOWcCosplEjtl2hOgAjoxh72uglth/oH52vvr9oGSa eMGb5tQPRkJnL0PEEupOqKN/4FpasD0JQ3bz8j5kfYnjdusMTT6nZiqC4TrZhjtsLMaw E4iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=m92BRq3EHcpUSdl5e466wSCRJdh7z6VfHjIUyALr548=; b=e+Mps/ExJoP3IC2dMtdXPT2w/WNUsffGNQstBmkXmghzFpVhH2vJUBLjJM5V0R32+V sIWJJZUvwQkOCQ+9cLsjhGj+ld9ep/R/979DI2NzX2KxZl4SVw+BqWhjmfz11H2vctA/ aZf5bknpZ6qPlDjoodZ7mu/ke+baJ50IUePm0zbNHo8reEvbav5bHcLTv3Q9MWMwZGNO MaVd54fMeYLYW346vNqMkdPL5sb6Q6jQ7SZFd9/KGYm4OSDXMX4UVyjZI9oSU1jD9oad 5RGRn/+UZAkcNVuOWNJz3AnJXeS+1Lxk5oc0dfPErW7PvVkGiXnxEFO2Noqhq7X9MVo/ YBjw== X-Gm-Message-State: ALoCoQlbaa2GTyjzXcsXPJZdTmQSjWEc9Fya2DuwidJvriBLsBfXDgnULeOgzvPMPksw6+zHAa9t X-Received: by 10.202.195.200 with SMTP id t191mr45139572oif.117.1438283887529; Thu, 30 Jul 2015 12:18:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.171.233 with HTTP; Thu, 30 Jul 2015 12:17:28 -0700 (PDT) From: Peter Thatcher Date: Thu, 30 Jul 2015 12:17:28 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a1134fd4033feb8051c1c90bd Archived-At: Subject: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:18:10 -0000 --001a1134fd4033feb8051c1c90bd Content-Type: text/plain; charset=UTF-8 At IETF 93 last week, Cullen pointed out that he looked into ICE endpoints and found that all of them support rtcp-mux. Inspired by that, I went around and asked about a dozen people "would you be OK if we removed support for non-muxed RTCP?" The range of responses went from "I'm OK with it if Cullen is" to "yeah, that would be great". No one said no. Cullen said yes. For me, removing support for non-muxed RTCP would be like Christmas in July. The amount of gross code in our implementation just to support this case is very large, especially considering the very small benefit it gives us. Talking to the developers at Mozilla, it sounds like they have a similar cost in code complexity. I'm guessing every ICE stack does. We could clean up a lot of code complexity in a lot of code bases by requiring rtcp-mux. So here's my proposal: make RtcpMuxPolicy == "required" be not only the default, but the only RtcpMuxPolicy available. All rtcweb endpoints must support rtcp-mux. An rtcweb endpoint would be free to fail if the remote endpoint does not support rtcp-mux. The whole reason we didn't do this before was because we wanted to work with legacy equipment. But Cullen's claim is that there is no legacy equipment that can speak ICE (and DTLS) but not rtcp-mux. So is there any remaining reason that we cannot require rtcp-mux? --001a1134fd4033feb8051c1c90bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At IETF 93 last week, =C2=A0Cullen pointed out that he = looked into ICE endpoints and found that all of them support rtcp-mux.=C2= =A0 Inspired by that, I went around and asked about a dozen people "wo= uld you be OK if we removed support for non-muxed RTCP?" =C2=A0The ran= ge of responses went from "I'm OK with it if Cullen is" to &q= uot;yeah, that would be great".=C2=A0 No one said no.=C2=A0 Cullen sai= d yes. =C2=A0

For me, removing support for non-muxed R= TCP would be like Christmas in July.=C2=A0 The amount of gross code in our = implementation just to support this case is very large, especially consider= ing the very small benefit it gives us.=C2=A0 Talking to the developers at = Mozilla, it sounds like they have a similar cost in code complexity.=C2=A0 = I'm guessing every ICE stack does.=C2=A0 We could clean up a lot of cod= e complexity in a lot of code bases by requiring rtcp-mux. =C2=A0
<= br>

So here's my proposal: =C2=A0make RtcpMuxPolic= y =3D=3D "required" be not only the default, but the only RtcpMux= Policy available. =C2=A0 All rtcweb endpoints must support rtcp-mux. =C2=A0= An rtcweb endpoint would be free to fail if the remote endpoint does not s= upport rtcp-mux.



The whole r= eason we didn't do this before was because we wanted to work with legac= y equipment.=C2=A0 But Cullen's claim is that there is no legacy equipm= ent that can speak ICE (and DTLS) but not rtcp-mux.=C2=A0

So is there any remaining reason that we cannot require rtcp-mux?



--001a1134fd4033feb8051c1c90bd-- From nobody Thu Jul 30 12:26:53 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA011ACC91 for ; Thu, 30 Jul 2015 12:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diEEAYlSeb0I for ; Thu, 30 Jul 2015 12:26:50 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA3B1ACCF2 for ; Thu, 30 Jul 2015 12:26:47 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so17749128igb.0 for ; Thu, 30 Jul 2015 12:26:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3C0KQ2zfMVgov/UmpzzWVRv+CRkb8dcYHgJyC4IqYgA=; b=U4PMWf8AlTzSmwtKNm8v9bBe6pez/twaHtppifEq4glo9PB08TF0S+Av1alBGod8Fa 4cKEBIUutgnEF3uduYXjcBpiONt89X6BQGXeFurALxkk4KciJowVRMF2pWN8pLU1HtD7 YCm9mQVwwoHgY4u3kzXH82Xd5Z093vF2YHYpPT+CYMSfzZij/ewATKnz/L/BCbm/oSUP 6m28EpO+hjejdx7EbPcwQJKZ3Mrlp9lwcnDy2ICHtwYB7QPFHWSUL9cBQN3824WPGFEa KfqAo5cYeY93jmEWCrVQwwF47GgA3IvK7jRHntZVxh353lb15nNCp6Gp6PyPwZi0UsG7 iERg== X-Gm-Message-State: ALoCoQmspRs5A+j0HCwDfwKiHgnbbQ3y4zauMn3qT0uRnl8nfuyBGAq+Wz06NCHbrBLsWihAIh/f X-Received: by 10.50.40.39 with SMTP id u7mr7578324igk.71.1438284407197; Thu, 30 Jul 2015 12:26:47 -0700 (PDT) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com. [209.85.223.176]) by smtp.gmail.com with ESMTPSA id q12sm1968529igr.2.2015.07.30.12.26.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 12:26:45 -0700 (PDT) Received: by ioea135 with SMTP id a135so63962253ioe.1 for ; Thu, 30 Jul 2015 12:26:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.152.81 with SMTP id a78mr13393462ioe.145.1438284404730; Thu, 30 Jul 2015 12:26:44 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Thu, 30 Jul 2015 12:26:44 -0700 (PDT) In-Reply-To: <55B9C503.4050807@jesup.org> References: <55B9C503.4050807@jesup.org> Date: Thu, 30 Jul 2015 15:26:44 -0400 Message-ID: From: Roman Shpount To: Randell Jesup Content-Type: multipart/alternative; boundary=001a114043c607b567051c1cafcb Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:26:52 -0000 --001a114043c607b567051c1cafcb Content-Type: text/plain; charset=UTF-8 Hi Randell, I do agree with most of your argument regarding fingerprinting and gUM. I also agree that this is not just the data channel issue and similar exploits can be created using audio or video connections. Furthermore, these usage patterns are very difficult to distinguish from legitimate applications. On the other hand I would argue that all of this exploits do not matter, since you can get the same information using non webrtc related HTML functionality. One thing that I do not agree with is that PeerConnection introduced a significant new behavior -- routing data over the non-default network interface. This is something that was not possible before. There is no way to overwrite default routing with HTTP request or anything similar generated by the browser. Overwriting default routing would allow creation of a whole new class of exploits, from determining user other IP addresses to forcing traffic over unexpected networks and generating expenses for the user. My suggestion is that until system wide preferences are exposed via some other mechanism defined by MIF, web browser should follow the local policy and do not overwrite local routing metrics by sending ICE requests over specific interfaces. At the very least, this should only be enabled via some sort of configuration option which should be disabled by default. I understand that using only default routes can decrease the chances of connection, but from my experience* we are talking about less then 0.1% of all the users. Also, please note that a lot of software VPNs do allow routing over secondary gateways. There is nothing fake or unusual about them. For instance Microsoft default PPTP VPN simply creates a virtual adapter for the VPN connection and creates a route with lower metric. This virtual adapter, on the other hand is using the previous default route for PPTP connection. * We have deployed a VoIP system with 500K users that used ICE in combination with TURNs over default route with HTTP connect option. Total number of users who could not place a call even though they could connect to the web server was less then 0.1%. _____________ Roman Shpount --001a114043c607b567051c1cafcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Randell,

I do agree with most of y= our argument regarding fingerprinting and gUM. I also agree that this is no= t just the data channel issue and similar exploits can be created using aud= io or video connections. Furthermore, these usage patterns are very difficu= lt to distinguish from legitimate applications. On the other hand I would a= rgue that all of this exploits do not matter, since you can get the same in= formation using non webrtc related HTML functionality.

One thing that I do not ag= ree with is that PeerConnection introduced a significant new behavior -- ro= uting data over the non-default network interface. This is something that w= as not possible before. There is no way to overwrite default routing with H= TTP request or anything similar generated by the browser. Overwriting defau= lt routing would allow creation of a whole new class of exploits, from dete= rmining user other IP addresses to forcing traffic over unexpected networks= and generating expenses for the =C2=A0user. My suggestion is that until sy= stem wide preferences are exposed via some other mechanism defined by MIF, = web browser should follow the local policy and do not overwrite local routi= ng metrics by sending ICE requests over specific interfaces. At the very le= ast, this should only be enabled via some sort of configuration option whic= h should be disabled by default. I understand that using only default route= s can decrease the chances of connection, but from my experience* we are ta= lking about less then 0.1% of all the users.

Also, please note that a lot of soft= ware VPNs do allow routing over secondary gateways. There is nothing fake o= r unusual about them. For instance Microsoft default PPTP VPN simply create= s a virtual adapter for the VPN connection and creates a route with lower m= etric. This virtual adapter, on the other hand is using the previous defaul= t route for PPTP connection.

*=C2=A0We have deployed a VoIP system with 500K user= s that used ICE in combination with TURNs over default route with HTTP conn= ect option. Total number of users who could not place a call even though th= ey could connect to the web server was less then 0.1%.
_____________
Roman Shpount

--001a114043c607b567051c1cafcb-- From nobody Thu Jul 30 12:28:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6657C1A01E2 for ; Thu, 30 Jul 2015 12:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9N5JZaahW2u for ; Thu, 30 Jul 2015 12:28:25 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132B91A014B for ; Thu, 30 Jul 2015 12:28:25 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so5061996wic.1 for ; Thu, 30 Jul 2015 12:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=D66qLm3k114SX1rRqbDQkEGSen1QTObCpJ4nqBrmxhk=; b=AUF3ajH2KH17oYDi1Ba20sl/X4y7raFNnw24oglOpqHafobetEHjCgbZzVP4CJ0tke bGjQd9/o/MCzW4CnZo4EfYL+dXNyvU8yZLBpGnSlI1DJaXa1fFLY3pZr0UbonB25vQAG YiYyWF7ooqbJ3HsIGu9CXExcBvrDew5FBpJSMKYsa97EgK1mFkY94EM1+f/YwAcASkk/ u76RzGyEu0Zj4UEAk9gksTKVryCrMRJuqbGKigvffWQW2lId6GSJ7b6Kgz5TlrEN5zNv JgZONnfrUKPkyEPGqv0FOORsz59N/XwQREe9/BMOrRUY0pBMAUmW8SQhwuzco+v9r+NE c6cg== X-Received: by 10.180.187.139 with SMTP id fs11mr8847271wic.48.1438284503822; Thu, 30 Jul 2015 12:28:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.24.88 with HTTP; Thu, 30 Jul 2015 12:28:04 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 30 Jul 2015 12:28:04 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a11c37d22efb86b051c1cb473 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:28:27 -0000 --001a11c37d22efb86b051c1cb473 Content-Type: text/plain; charset=UTF-8 Peter said: "So is there any remaining reason that we cannot require rtcp-mux?" [BA] To be clear, you are talking about making RTP/RTCP multiplexing mandatory-to-use? The RTP-Usage document already mandates support for RFC 5761. From Section 4.5: implementations are REQUIRED to support multiplexing RTP data packets and RTCP control packets on a single transport-layer flow [RFC5761 ]. On Thu, Jul 30, 2015 at 12:17 PM, Peter Thatcher wrote: > At IETF 93 last week, Cullen pointed out that he looked into ICE > endpoints and found that all of them support rtcp-mux. Inspired by that, I > went around and asked about a dozen people "would you be OK if we removed > support for non-muxed RTCP?" The range of responses went from "I'm OK with > it if Cullen is" to "yeah, that would be great". No one said no. Cullen > said yes. > > For me, removing support for non-muxed RTCP would be like Christmas in > July. The amount of gross code in our implementation just to support this > case is very large, especially considering the very small benefit it gives > us. Talking to the developers at Mozilla, it sounds like they have a > similar cost in code complexity. I'm guessing every ICE stack does. We > could clean up a lot of code complexity in a lot of code bases by requiring > rtcp-mux. > > > So here's my proposal: make RtcpMuxPolicy == "required" be not only the > default, but the only RtcpMuxPolicy available. All rtcweb endpoints must > support rtcp-mux. An rtcweb endpoint would be free to fail if the remote > endpoint does not support rtcp-mux. > > > > The whole reason we didn't do this before was because we wanted to work > with legacy equipment. But Cullen's claim is that there is no legacy > equipment that can speak ICE (and DTLS) but not rtcp-mux. > > So is there any remaining reason that we cannot require rtcp-mux? > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c37d22efb86b051c1cb473 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter said:

"So is the= re any remaining reason that we cannot require rtcp-mux?"
[BA] To be clear, you are talking about making RTP/RTCP multip= lexing=C2=A0mandatory-to-use?

The RTP-Usage docum= ent already=C2=A0mandates support for RFC 5761.=C2=A0 From Section 4.5:

=C2=A0=C2=A0 implementations are REQUIRED to support= multiplexing RTP data packets
=C2=A0=C2=A0 and RTCP control packets on = a single transport-layer flow [RFC5761].

On Thu, Jul 30, 2015 at 12= :17 PM, Peter Thatcher <pthatcher@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
At IETF 93 last week, =C2= =A0Cullen pointed out that he looked into ICE endpoints and found that all = of them support rtcp-mux.=C2=A0 Inspired by that, I went around and asked a= bout a dozen people "would you be OK if we removed support for non-mux= ed RTCP?" =C2=A0The range of responses went from "I'm OK with= it if Cullen is" to "yeah, that would be great".=C2=A0 No o= ne said no.=C2=A0 Cullen said yes. =C2=A0

For me, remo= ving support for non-muxed RTCP would be like Christmas in July.=C2=A0 The = amount of gross code in our implementation just to support this case is ver= y large, especially considering the very small benefit it gives us.=C2=A0 T= alking to the developers at Mozilla, it sounds like they have a similar cos= t in code complexity.=C2=A0 I'm guessing every ICE stack does.=C2=A0 We= could clean up a lot of code complexity in a lot of code bases by requirin= g rtcp-mux. =C2=A0


So here's my propo= sal: =C2=A0make RtcpMuxPolicy =3D=3D "required" be not only the d= efault, but the only RtcpMuxPolicy available. =C2=A0 All rtcweb endpoints m= ust support rtcp-mux. =C2=A0 An rtcweb endpoint would be free to fail if th= e remote endpoint does not support rtcp-mux.



The whole reason we didn't do this before was becaus= e we wanted to work with legacy equipment.=C2=A0 But Cullen's claim is = that there is no legacy equipment that can speak ICE (and DTLS) but not rtc= p-mux.=C2=A0

So is there any remaining reason that we = cannot require rtcp-mux?




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--001a11c37d22efb86b051c1cb473-- From nobody Thu Jul 30 12:29:50 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C2E1A905C for ; Thu, 30 Jul 2015 12:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REDt0vKtRqOy for ; Thu, 30 Jul 2015 12:29:47 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390C91A0233 for ; Thu, 30 Jul 2015 12:29:47 -0700 (PDT) Received: by igr7 with SMTP id 7so2811863igr.0 for ; Thu, 30 Jul 2015 12:29:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eyZrYS6g5m1/1x9+KQ2HUJNLuKPSPFRzQ8xg4jW/WtE=; b=ChSgiD3p6JFUMgetP+W0CeHenEcPijGipFmECShL0hjeQ61UAEL+b0ZIYD5GoKuOxg QSm74sFZYB5QZglTtUql5mFYc+d2USx2zC7yz1KIczODkDe4pcdL3/4SAHxs0volNrHe 4qMoI63kHlugoqVpwrK/Ii0AFfORbyg0koatP507VrSYx/MQ6ier2r1FgpGGwDgqDQU4 C4pLB+XbhI7ryOwWcYmA3Fl3C7kGU6lwtxX5xYgWm/1cq9uYi1YnDuO42V1bDeIJ8Rdx qXsVx6fiZg49Tmtjou9ma9a/3I9MlvKieWDtLVeA0Hq3APcErvZu46ZnWdw2WSev2kUX Zgag== X-Gm-Message-State: ALoCoQlrE+KbJr6nM1w9NHp1OE4gHuPGoOZO2s+d1NoxOXbce6OswFUCfQMA2HzFjVfhjnWLMEsl X-Received: by 10.50.138.73 with SMTP id qo9mr7619240igb.64.1438284586779; Thu, 30 Jul 2015 12:29:46 -0700 (PDT) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com. [209.85.223.175]) by smtp.gmail.com with ESMTPSA id bf10sm341189igb.12.2015.07.30.12.29.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 12:29:45 -0700 (PDT) Received: by iodd187 with SMTP id d187so63972969iod.2 for ; Thu, 30 Jul 2015 12:29:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.150.141 with SMTP id y135mr12686369iod.38.1438284585066; Thu, 30 Jul 2015 12:29:45 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Thu, 30 Jul 2015 12:29:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 15:29:45 -0400 Message-ID: From: Roman Shpount To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a11403fd4c76d9e051c1cb961 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:29:48 -0000 --001a11403fd4c76d9e051c1cb961 Content-Type: text/plain; charset=UTF-8 Please, please, please make rtcp-mux mandatory to use! For me this would be Christmas, Hanukkah and Kwanzaa rolled into one. _____________ Roman Shpount --001a11403fd4c76d9e051c1cb961 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please, please, please make rtcp-mux mandatory to use! For= me this would be Christmas, Hanukkah and Kwanzaa rolled into one.=C2=A0

_____________
Roman Shpount

--001a11403fd4c76d9e051c1cb961-- From nobody Thu Jul 30 12:36:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E69C1ACD6D for ; Thu, 30 Jul 2015 12:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnbUDbkHLf7P for ; Thu, 30 Jul 2015 12:35:57 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B651AC42E for ; Thu, 30 Jul 2015 12:35:57 -0700 (PDT) Received: by obdeg2 with SMTP id eg2so38457838obd.0 for ; Thu, 30 Jul 2015 12:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5WwVDvL/a8F5H6oZtgZgLTunyiZf8WM0CbLIui7oilM=; b=m13v/js6fkl/2YCfVJnGxTz9cY9e0jttiWmhwC6yVbmrJlU+to6N0cR4KAlE0Fqkck muyk1YcTIdFVApl6aVsDj6t1ER3X24snr7dI1O/YwJQXoBjHO9FV9lhfi0TST1cj8uQD WfAJfJGT1eH59NjTScE7TUGjGU+Wh6jjCQAY/+ZSI/cN9LPOW7BuylW6EgNNOds2e1JJ 6h5XdqzkWSRlbFQtKZTWCzUlejS/MDk5TSAlBYNgwf+zo/5+t140eeNB0yC00ea8O2GS GXT2XiwDLXlNXHv9RFzV185EJ2QpOFU0xJw+1UWWwD0X3UUzepD564dUv+zjD93cMUR4 kheg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5WwVDvL/a8F5H6oZtgZgLTunyiZf8WM0CbLIui7oilM=; b=XjfW03Tjx6RO3MxtjMiTmOV0F9oh0hCj16FEB92E/AMMWWvMdium1a871K0DpBdpDn cWl6jCMB39iuwR9zKbm4dFxtlH5o3gG+HG/kaFEVFOjBfUXbWx1yW91+ep5/vycT3NsH dYRojnaV4NH3RYO9+YD2q+2B7qEJd2XMnHsP4BZF+6yG9cCUckPFA166ovBV1hsqJGLn vGHAsZ9p8HeqyzoJyH1v52GMqYwf1vN9la5nIDd2et6WapMyzRZmpnkPvAR3RdRpy4cz 13E4O8vMWkdXhmwGDtJFRk+4UEYJxJx10XeE0Gmi13WKROfyObaKJ6AFV/nHDrzw4BdO PfHQ== X-Gm-Message-State: ALoCoQm53VTyupaRX7jk4LHam493TJLzQwjCILRcHB00CO9I4EQC0hRCRWRUHpfYU30nx8Lf+LYf X-Received: by 10.182.230.70 with SMTP id sw6mr47447498obc.48.1438284956947; Thu, 30 Jul 2015 12:35:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.171.233 with HTTP; Thu, 30 Jul 2015 12:35:17 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Thu, 30 Jul 2015 12:35:17 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a1134c24af1f83c051c1ccfda Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:35:59 -0000 --001a1134c24af1f83c051c1ccfda Content-Type: text/plain; charset=UTF-8 I didn't quite mean mandatory-to-use. If an rtcweb endpoint wants to use non-muxed RTCP, it could go ahead and do that, so it's not quite mandatory-to-use-rtcp-mux, but instead free-to-not-support-non-muxed-rtcp. Perhaps my proposal should instead be: rtcweb endpoints MAY make RtcpMuxPolicy == "required" the default and MAY remove support for RtcpMuxPolicy == "negotiate". That would leave the door open to endpoints that want to support non-muxed RTCP, which mandatory-to-use would not. But it would also leave the door open to endpoints not having to support non-muxed RTCP. On Thu, Jul 30, 2015 at 12:28 PM, Bernard Aboba wrote: > Peter said: > > "So is there any remaining reason that we cannot require rtcp-mux?" > > [BA] To be clear, you are talking about making RTP/RTCP > multiplexing mandatory-to-use? > > The RTP-Usage document already mandates support for RFC 5761. From > Section 4.5: > > implementations are REQUIRED to support multiplexing RTP data packets > and RTCP control packets on a single transport-layer flow [RFC5761 > ]. > > On Thu, Jul 30, 2015 at 12:17 PM, Peter Thatcher > wrote: > >> At IETF 93 last week, Cullen pointed out that he looked into ICE >> endpoints and found that all of them support rtcp-mux. Inspired by that, I >> went around and asked about a dozen people "would you be OK if we removed >> support for non-muxed RTCP?" The range of responses went from "I'm OK with >> it if Cullen is" to "yeah, that would be great". No one said no. Cullen >> said yes. >> >> For me, removing support for non-muxed RTCP would be like Christmas in >> July. The amount of gross code in our implementation just to support this >> case is very large, especially considering the very small benefit it gives >> us. Talking to the developers at Mozilla, it sounds like they have a >> similar cost in code complexity. I'm guessing every ICE stack does. We >> could clean up a lot of code complexity in a lot of code bases by requiring >> rtcp-mux. >> >> >> So here's my proposal: make RtcpMuxPolicy == "required" be not only the >> default, but the only RtcpMuxPolicy available. All rtcweb endpoints must >> support rtcp-mux. An rtcweb endpoint would be free to fail if the remote >> endpoint does not support rtcp-mux. >> >> >> >> The whole reason we didn't do this before was because we wanted to work >> with legacy equipment. But Cullen's claim is that there is no legacy >> equipment that can speak ICE (and DTLS) but not rtcp-mux. >> >> So is there any remaining reason that we cannot require rtcp-mux? >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --001a1134c24af1f83c051c1ccfda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I didn't quite mean mandatory-to-use.=C2=A0 If an r= tcweb endpoint wants to use non-muxed RTCP, it could go ahead and do that, = so it's not quite mandatory-to-use-rtcp-mux, but instead free-to-not-su= pport-non-muxed-rtcp.

Perhaps my proposal should inst= ead be: =C2=A0rtcweb endpoints MAY make=C2= =A0RtcpMuxPolicy =3D=3D "required" the default and MAY remove sup= port for RtcpMuxPolicy =3D=3D "negotiate".

That would leave the door open to endpoints that want to support non-mu= xed RTCP, which mandatory-to-use would not.=C2=A0 But it would also leave t= he door open to endpoints not having to support non-muxed RTCP.



On Thu, Jul 30, 2015 at 12:28 PM, Bernard Aboba <bernard.a= boba@gmail.com> wrote:
Peter said:

"So is t= here any remaining reason that we cannot require rtcp-mux?"
=
[BA] To be clear, you are talking about making RTP/RT= CP multiplexing=C2=A0mandatory-to-use?

The RTP-Us= age document already=C2=A0mandates support for RFC 5761.=C2=A0 From Section= 4.5:

=C2=A0=C2=A0 implementations are REQUIRED t= o support multiplexing RTP data packets
=C2=A0=C2=A0 and RTCP control pa= ckets on a single transport-layer flow [RFC5761= ].

On Thu, Jul 30, 2015 at 12:17 PM, Peter Thatcher <pthatcher@= google.com> wrote:
At IETF 93 last week, =C2=A0Cullen pointed out that he looked int= o ICE endpoints and found that all of them support rtcp-mux.=C2=A0 Inspired= by that, I went around and asked about a dozen people "would you be O= K if we removed support for non-muxed RTCP?" =C2=A0The range of respon= ses went from "I'm OK with it if Cullen is" to "yeah, th= at would be great".=C2=A0 No one said no.=C2=A0 Cullen said yes. =C2= =A0

For me, removing suppor= t for non-muxed RTCP would be like Christmas in July.=C2=A0 The amount of g= ross code in our implementation just to support this case is very large, es= pecially considering the very small benefit it gives us.=C2=A0 Talking to t= he developers at Mozilla, it sounds like they have a similar cost in code c= omplexity.=C2=A0 I'm guessing every ICE stack does.=C2=A0 We could clea= n up a lot of code complexity in a lot of code bases by requiring rtcp-mux.= =C2=A0


So here's my proposal: =C2= =A0make RtcpMuxPolicy =3D=3D "required" be not only the default, = but the only RtcpMuxPolicy available. =C2=A0 All rtcweb endpoints must supp= ort rtcp-mux. =C2=A0 An rtcweb endpoint would be free to fail if the remote= endpoint does not support rtcp-mux.


<= br>
The whole re= ason we didn't do this before was because we wanted to work with legacy= equipment.=C2=A0 But Cullen's claim is that there is no legacy equipme= nt that can speak ICE (and DTLS) but not rtcp-mux.=C2=A0

So is there any remaining reason that we cann= ot require rtcp-mux?




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb



--001a1134c24af1f83c051c1ccfda-- From nobody Thu Jul 30 12:38:07 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CA91ACCF2 for ; Thu, 30 Jul 2015 12:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1AEgkKx6pJf for ; Thu, 30 Jul 2015 12:38:05 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0411A905C for ; Thu, 30 Jul 2015 12:38:05 -0700 (PDT) Received: by qgeh16 with SMTP id h16so31542317qge.3 for ; Thu, 30 Jul 2015 12:38:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WI8i7Im3phHnJCLqEj/aQ2pTg81WXKtoLAMzVqg+BG4=; b=FUYQ16tH3cEjz2U09Da2FKgWiNaw2lOTHp3vb9dk9nz5fSHw9x/2RsYMXdb3knpxpV f+IGarBHFbRU05cCKm2dmOK8WtnBDaia6frR4FhLfsrBm4jGCg0x13v3506P1rUSQWtV XbVd45bXJ0qck0j1mB+dhHlmbPqhBiIJr8NIAAd1bbJ74nLFSQF7oGprBFYSFFvKUOgh /Or+sVmhJJ64SXjK0xrLfNrzGEZ0qpYcO0KC/T7EauqppKy9tejrdkwPHTxkmSMHJZEa EYqCwcPy9vlUuwVs8ozXkni/yuPOpE1TWs/pU2mgUhgRFJFGzAQ45GXls4amV5OY0wjf Ra6w== X-Gm-Message-State: ALoCoQn16LgeIdmS82DAbyJWfQZCWTRqPGDS0NorrxorOmOi7foaCj4HcX0KglZfMNUiRZCl5mnW X-Received: by 10.140.131.146 with SMTP id 140mr8583343qhd.90.1438285084300; Thu, 30 Jul 2015 12:38:04 -0700 (PDT) Received: from ?IPv6:2607:fa48:6eca:f820:280a:4820:9c6a:c92b? ([2607:fa48:6eca:f820:280a:4820:9c6a:c92b]) by smtp.googlemail.com with ESMTPSA id 2sm974438qhw.10.2015.07.30.12.38.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 12:38:03 -0700 (PDT) Message-ID: <55BA7D19.3020202@jive.com> Date: Thu, 30 Jul 2015 15:38:01 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Roman Shpount , Peter Thatcher References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:38:06 -0000 Le 2015-07-30 15:29, Roman Shpount a écrit : > Please, please, please make rtcp-mux mandatory to use! For me this would > be Christmas, Hanukkah and Kwanzaa rolled into one. +1 I prefer mandatory-to-use to free-to-not-support-non-muxed-rtcp. Simon From nobody Thu Jul 30 12:39:14 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F081ACD6D for ; Thu, 30 Jul 2015 12:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKP3Bb6Zb21h for ; Thu, 30 Jul 2015 12:39:10 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C2F1ACDED for ; Thu, 30 Jul 2015 12:39:10 -0700 (PDT) Received: by oihq81 with SMTP id q81so27502413oih.2 for ; Thu, 30 Jul 2015 12:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xelvhtl/KYHG4rtZedM7rG6jiHH2xQ++OK5eJ6QDZPQ=; b=GH3REfqhrsnLBZb1jUumEHsF8z0Tm28kuDNb8oBj0SWMSsAUGiaACp5gsW2PMDZIyq M6FeJuuij4S/yRTLWWy4+9xS9cEnjjUC9RJTgr1Dwf1MC+wNkz/hwt4iLTf62Zwaexs+ gPvJCa2CxMwxls/rgoAeJ3kWJNQhu+qOxcVY+G08uZFET46CUyocDOKPhTqpr072j4Hb /nQtEsYPvhkUVc1ALZUV5iwZ7qp16O1TAWNijKbOnVHrAB09/YE8wjKNE1ooJ4tfI7d+ v+U3+6+uFVEivSoCNFlY7LOm/XpSBg5AAzPD5DH1u2yIyIDAh7QTQgGweCR4dBI/fWUb CmVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xelvhtl/KYHG4rtZedM7rG6jiHH2xQ++OK5eJ6QDZPQ=; b=hyusgZ3hni7EQHZtLDG3ETLXhVLot3izhSYofIniXi8FRwQjJYNkuqQkuKSpwLZdPS pon0FfH0ffblEKoTcMA2QvnEYfjc0PzugzjByhpFrb00lJuJvXSRA7CJc1+6fLqYf8Ek g38nBHz4cPasNm+r6at1tpx3BnZAaBDLS13waiDguz4DfITPneEpCPUMsPvmZzRgmyQL IjI2Io6uEbpe7UOTGv7Hv5/ukcni5rx6tGuBwqCZtjNTQbbpkYtuSALueaHdtjk37Pvg bDJ7IyOGTG5AxNzNmNtBhckQH37giGJajSpmP/M9d+cM4X00RxraqLLXblxUuQ0QoFu7 fwXQ== X-Gm-Message-State: ALoCoQmO+mlw5dTgO8biuF98IvIwZ4iomtn6jLP/s4Zc/xceezm6L9R4bJq8z/aq5AyAyT+q7CDm X-Received: by 10.202.95.138 with SMTP id t132mr45321410oib.55.1438285149770; Thu, 30 Jul 2015 12:39:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.171.233 with HTTP; Thu, 30 Jul 2015 12:38:30 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Thu, 30 Jul 2015 12:38:30 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=001a113cd41a704424051c1cdb43 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:39:11 -0000 --001a113cd41a704424051c1cdb43 Content-Type: text/plain; charset=UTF-8 I guess I should have said "Winter Break in July". On Thu, Jul 30, 2015 at 12:29 PM, Roman Shpount wrote: > Please, please, please make rtcp-mux mandatory to use! For me this would > be Christmas, Hanukkah and Kwanzaa rolled into one. > > _____________ > Roman Shpount > > --001a113cd41a704424051c1cdb43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess I should have said "Winter Break in July&q= uot;. =C2=A0

On Thu, Jul 30, 2015 at 12:29 PM, Roman Shpount &l= t;roman@telurix.com<= /a>> wrote:
Pl= ease, please, please make rtcp-mux mandatory to use! For me this would be C= hristmas, Hanukkah and Kwanzaa rolled into one.=C2=A0

_____________
Roman Shpount


--001a113cd41a704424051c1cdb43-- From nobody Thu Jul 30 12:46:20 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBC31ACDED for ; Thu, 30 Jul 2015 12:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRA0G7BySlgJ for ; Thu, 30 Jul 2015 12:46:16 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8C31ACE0A for ; Thu, 30 Jul 2015 12:46:15 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so5605777wic.1 for ; Thu, 30 Jul 2015 12:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uzpagnr3l2UYY0ArYxobt1eluHW+fm0mPdDVjXp4b50=; b=x2juhvRLK8d9XvoY9+5KcmqnOamYVEL9M8PwzAuqezIKJa+fz4VqblibTgC4f/pRtN 0UJdLbonUY3dLxrqcyIsNND/ojTk1yJSKmCkfp+hfWFvSU1LqRAalxymflVk+X4riFAa BAEOIoe4hoKzrEbxeFF9XqOzeeymUMVgpDGeAQTFq78zQs7V3jfwpkZjLG9Qfr1wH/gR OzYCeutUhP/PpaLBYpVD5hfy/Z0R0bbcpSfbJrpjpmN5PR7e+4rNJO/2vs9gOlryxn3i ahKkZzqOyKloTvyWcAEzqkVkut8n40ipq/QKUyitCalcePHryV9xYrEry2LZQAiLZIRA tryw== X-Received: by 10.194.87.102 with SMTP id w6mr88151322wjz.111.1438285574510; Thu, 30 Jul 2015 12:46:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.24.88 with HTTP; Thu, 30 Jul 2015 12:45:55 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 30 Jul 2015 12:45:55 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=047d7bf19850c11f07051c1cf42b Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:46:18 -0000 --047d7bf19850c11f07051c1cf42b Content-Type: text/plain; charset=UTF-8 "free-to-not-support-non-muxed-rtcp." [BA] OK. This would involve changing "are also REQUIRED to" to "MAY" in the following sentence within RTP-Usage Section 4.5: For backwards compatibility, implementations are also REQUIRED to support RTP and RTCP sent on separate transport-layer flows. On Thu, Jul 30, 2015 at 12:35 PM, Peter Thatcher wrote: > I didn't quite mean mandatory-to-use. If an rtcweb endpoint wants to use > non-muxed RTCP, it could go ahead and do that, so it's not quite > mandatory-to-use-rtcp-mux, but instead free-to-not-support-non-muxed-rtcp. > > Perhaps my proposal should instead be: rtcweb endpoints MAY make RtcpMuxPolicy > == "required" the default and MAY remove support for RtcpMuxPolicy == > "negotiate". > > That would leave the door open to endpoints that want to support non-muxed > RTCP, which mandatory-to-use would not. But it would also leave the door > open to endpoints not having to support non-muxed RTCP. > > > > On Thu, Jul 30, 2015 at 12:28 PM, Bernard Aboba > wrote: > >> Peter said: >> >> "So is there any remaining reason that we cannot require rtcp-mux?" >> >> [BA] To be clear, you are talking about making RTP/RTCP >> multiplexing mandatory-to-use? >> >> The RTP-Usage document already mandates support for RFC 5761. From >> Section 4.5: >> >> implementations are REQUIRED to support multiplexing RTP data packets >> and RTCP control packets on a single transport-layer flow [RFC5761 >> ]. >> >> On Thu, Jul 30, 2015 at 12:17 PM, Peter Thatcher >> wrote: >> >>> At IETF 93 last week, Cullen pointed out that he looked into ICE >>> endpoints and found that all of them support rtcp-mux. Inspired by that, I >>> went around and asked about a dozen people "would you be OK if we removed >>> support for non-muxed RTCP?" The range of responses went from "I'm OK with >>> it if Cullen is" to "yeah, that would be great". No one said no. Cullen >>> said yes. >>> >>> For me, removing support for non-muxed RTCP would be like Christmas in >>> July. The amount of gross code in our implementation just to support this >>> case is very large, especially considering the very small benefit it gives >>> us. Talking to the developers at Mozilla, it sounds like they have a >>> similar cost in code complexity. I'm guessing every ICE stack does. We >>> could clean up a lot of code complexity in a lot of code bases by requiring >>> rtcp-mux. >>> >>> >>> So here's my proposal: make RtcpMuxPolicy == "required" be not only the >>> default, but the only RtcpMuxPolicy available. All rtcweb endpoints must >>> support rtcp-mux. An rtcweb endpoint would be free to fail if the remote >>> endpoint does not support rtcp-mux. >>> >>> >>> >>> The whole reason we didn't do this before was because we wanted to work >>> with legacy equipment. But Cullen's claim is that there is no legacy >>> equipment that can speak ICE (and DTLS) but not rtcp-mux. >>> >>> So is there any remaining reason that we cannot require rtcp-mux? >>> >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> > --047d7bf19850c11f07051c1cf42b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"free-to-not-support-non-muxed-rtcp."
[BA] OK. =C2=A0 This would involve changing "are also= REQUIRED to" to "MAY" in the following sentence within RTP-= Usage Section 4.5:=C2=A0

  =
 For backwards compatibility, implementations are also REQUIRED to support
   RTP and RTCP sent on separate transport-layer flows.

On Thu, Jul 30, 2015 at 12:35 PM, Peter Thatcher <pthatcher@google.com= > wrote:
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">I didn't quite mean mandatory-to-use.=C2=A0 If an rtcweb endpoint wan= ts to use non-muxed RTCP, it could go ahead and do that, so it's not qu= ite mandatory-to-use-rtcp-mux, but instead free-to-not-support-non-muxed-rt= cp.

Perhaps my proposal should instead be: =C2=A0rtcwe= b endpoints MAY make=C2=A0RtcpMuxPolicy = =3D=3D "required" the default and MAY remove support for RtcpMuxP= olicy =3D=3D "negotiate".

That would le= ave the door open to endpoints that want to support non-muxed RTCP, which m= andatory-to-use would not.=C2=A0 But it would also leave the door open to e= ndpoints not having to support non-muxed RTCP.



On Thu, Jul 30, 2015 at 12:28 PM, Bernard Aboba <b= ernard.aboba@gmail.com> wrote:
Peter said:

"= ;So is there any remaining reason that we cannot require rtcp-mux?"

[BA] To be clear, you are talking about makin= g RTP/RTCP multiplexing=C2=A0mandatory-to-use?

Th= e RTP-Usage document already=C2=A0mandates support for RFC 5761.=C2=A0 From= Section 4.5:

=C2=A0=C2=A0 implementations are RE= QUIRED to support multiplexing RTP data packets
=C2=A0=C2=A0 and RTCP co= ntrol packets on a single transport-layer flow [RFC576= 1].

On Thu, Jul 30, 2015 at 12:17 PM, Peter Thatcher <pt= hatcher@google.com> wrote:
At IETF 93 last week, =C2=A0Cullen pointed out that he = looked into ICE endpoints and found that all of them support rtcp-mux.=C2= =A0 Inspired by that, I went around and asked about a dozen people "wo= uld you be OK if we removed support for non-muxed RTCP?" =C2=A0The ran= ge of responses went from "I'm OK with it if Cullen is" to &q= uot;yeah, that would be great".=C2=A0 No one said no.=C2=A0 Cullen sai= d yes. =C2=A0
For me, remov= ing support for non-muxed RTCP would be like Christmas in July.=C2=A0 The a= mount of gross code in our implementation just to support this case is very= large, especially considering the very small benefit it gives us.=C2=A0 Ta= lking to the developers at Mozilla, it sounds like they have a similar cost= in code complexity.=C2=A0 I'm guessing every ICE stack does.=C2=A0 We = could clean up a lot of code complexity in a lot of code bases by requiring= rtcp-mux. =C2=A0


So here's my pro= posal: =C2=A0make RtcpMuxPolicy =3D=3D "required" be not only the= default, but the only RtcpMuxPolicy available. =C2=A0 All rtcweb endpoints= must support rtcp-mux. =C2=A0 An rtcweb endpoint would be free to fail if = the remote endpoint does not support rtcp-mux.



Th= e whole reason we didn't do this before was because we wanted to work w= ith legacy equipment.=C2=A0 But Cullen's claim is that there is no lega= cy equipment that can speak ICE (and DTLS) but not rtcp-mux.=C2=A0

So is there any remaining reason th= at we cannot require rtcp-mux?




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb




--047d7bf19850c11f07051c1cf42b-- From nobody Thu Jul 30 12:56:35 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1A71AC435 for ; Thu, 30 Jul 2015 12:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCwv6bFb435D for ; Thu, 30 Jul 2015 12:56:32 -0700 (PDT) Received: from ftx-008-i771.relay.mailchannels.net (ftx-008-i771.relay.mailchannels.net [50.61.143.71]) by ietfa.amsl.com (Postfix) with ESMTP id 05A0E1A923D for ; Thu, 30 Jul 2015 12:56:31 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id 6CE79407A; Thu, 30 Jul 2015 19:56:28 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Thu, 30 Jul 2015 19:56:29 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1438286188730:2052814951 X-MC-Ingress-Time: 1438286188730 Received: from pool-108-36-235-74.phlapa.fios.verizon.net ([108.36.235.74]:52376 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZKtwJ-0006II-0N; Thu, 30 Jul 2015 14:56:27 -0500 Message-ID: <55BA8159.5050606@jesup.org> Date: Thu, 30 Jul 2015 15:56:09 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080002010802050801070102" X-AuthUser: randell@jesup.org Archived-At: Cc: Colin Perkins Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:56:34 -0000 This is a multi-part message in MIME format. --------------080002010802050801070102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 7/30/2015 3:17 PM, Peter Thatcher wrote: > So here's my proposal: make RtcpMuxPolicy == "required" be not only > the default, but the only RtcpMuxPolicy available. All rtcweb > endpoints must support rtcp-mux. An rtcweb endpoint would be free to > fail if the remote endpoint does not support rtcp-mux. > > > > The whole reason we didn't do this before was because we wanted to > work with legacy equipment. But Cullen's claim is that there is no > legacy equipment that can speak ICE (and DTLS) but not rtcp-mux. > > So is there any remaining reason that we cannot require rtcp-mux? I agree it would clean up code considerably, and simplify candidate gathering, etc. This means any gateways from WebRTC/ICE/etc to legacy RTP devices (PSTN gateways, whatever) will need to be able to do rtcp-mux on one side, and non-muxed on the other, and deal with possible payload rewriting to avoid conflicts. Or punt. I just want to make that clear; I am ok with this restriction (to require use of (not just support of) RTCP-mux in WebRTC). Cc: Colin -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much spam --------------080002010802050801070102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 7/30/2015 3:17 PM, Peter Thatcher wrote:
So here's my proposal: =A0make RtcpMuxPolicy =3D=3D "required" be not only the default, but the only RtcpMuxPolicy available. =A0 All rtcweb endpoints must support rtcp-mux. =A0 An rtcweb endpoint would be free to fail if the remote endpoint does not support rtcp-mux.



The whole reason we didn't do this before was because we wanted to work with legacy equipment.=A0 But Cullen's claim is that there is n= o legacy equipment that can speak ICE (and DTLS) but not rtcp-mux.=A0

So is there an= y remaining reason that we cannot require rtcp-mux?

I agree it would clean up code considerably, and simplify candidate gathering, etc.=A0

This means any gateways from WebRTC/ICE/etc to legacy RTP devices (PSTN gateways, whatever) will need to be able to do rtcp-mux on one side, and non-muxed on the other, and deal with possible payload rewriting to avoid conflicts.=A0 Or punt.=A0 I just want to make that clear; I am ok with this restriction (to require use of (not just support of) RTCP-mux in WebRTC).

Cc: Colin
--=20
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too=
 much spam
--------------080002010802050801070102-- From nobody Thu Jul 30 13:00:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463611ACE22 for ; Thu, 30 Jul 2015 13:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hR9X4ORe3yg for ; Thu, 30 Jul 2015 13:00:37 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6871A923D for ; Thu, 30 Jul 2015 13:00:37 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so33842459wic.0 for ; Thu, 30 Jul 2015 13:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dyBPGsAs5Zv/Z6uZzX0bUMKDy59Rss28B14c9VUS1dI=; b=ZAKYWwfccnJZuL/UL1Yu3JB71QkwHoC3v/fUMgm+KBv5pFMab8nf+njzD0iaRaeST0 dppBk56n9w+QHRUIiWbalpAUkZ3pVuux2KSXVvkUD4rPFHVorxyvvj/5obhlMEaBUxA8 OLvLFTGIDVvlAeJJaHt7h71B6tbUXCoH7EZVhRMlfNGicvQ+q2APbzkShWK9pFY0HSF5 zToYJR+31SsC69QV3baHXnzzdN5K1sd7/c3HOF91+OWMhe4zFeGHM9psNARjXkkVyqcZ FX2vYE8d1QHUpYTIk06n1uN3WjMOJwnyIKYAGPeITChaD4ziINgEYagMFwLz6YXKFYeG yRWw== X-Received: by 10.180.86.73 with SMTP id n9mr9420643wiz.78.1438286435998; Thu, 30 Jul 2015 13:00:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.24.88 with HTTP; Thu, 30 Jul 2015 13:00:16 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 30 Jul 2015 13:00:16 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=f46d0442806e1a6153051c1d28b5 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Interim discussion? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 20:00:39 -0000 --f46d0442806e1a6153051c1d28b5 Content-Type: text/plain; charset=UTF-8 Peter said: "Making it a part of the W3C interim sounds like a good idea to me. We've done both IETF and W3C at interims in the past, and they have been productive (perhaps more productive than the non-interim meetings)." [BA] That could be made to work, though to piggyback on the WEBRTC WG interim in September, it would be necessary to quickly understand the schedule/attendance impact on the existing plans (e.g. impact on the estimated attendance, whether the existing dates would stay the same or would need extending, etc.). On Thu, Jul 30, 2015 at 11:53 AM, Peter Thatcher wrote: > Making it a part of the W3C interim sounds like a good idea to me. We've > done both IETF and W3C at interims in the past, and they have been > productive (perhaps more productive than the non-interim meetings). > > On Thu, Jul 30, 2015 at 10:43 AM, Ted Hardie wrote: > >> The chairs have discussed how to make progress between now and Yokohama, >> and it seems like another focused 2-3 hour meeting would be useful. That >> might be a completely virtual interim or one associated with the WebRTC >> interim, but with a remote participation component. >> >> If you have thoughts on that, please share them between now and August >> 7th, 2015. >> >> thanks, >> >> Ted, Cullen, Sean >> >> _______________________________________________ >> 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 > > --f46d0442806e1a6153051c1d28b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter said:=C2=A0

"Making it a part o= f the W3C interim sounds like a good idea to me.=C2=A0 We've done both = IETF and W3C at interims in the past, and they have been productive (perhap= s more productive than the non-interim meetings)."
[BA] That could be made to work, though to piggyback on the WE= BRTC WG interim in September, it would be necessary to quickly understand t= he schedule/attendance impact on the existing plans (e.g. impact on the est= imated attendance, whether the existing dates would stay the same or would = need extending, etc.).=C2=A0

On Thu, Jul 30, 2015 at 11:53 AM, Peter Thatcher <pthatcher@google.com> wrote:
Making it a part of the W3C interim sounds like a g= ood idea to me.=C2=A0 We've done both IETF and W3C at interims in the p= ast, and they have been productive (perhaps more productive than the non-in= terim meetings).

On Thu, Jul 30, 2015 at 10:43 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
The chairs = have discussed how to make progress between now and Yokohama, and it seems = like another focused 2-3 hour meeting would be useful.=C2=A0 That might be = a completely virtual interim or one associated with the WebRTC interim, but= with a remote participation component.=C2=A0

If yo= u have thoughts on that, please share them between now and August 7th, 2015= .

thanks,

Ted, Cullen, Sean

_______________________________________________
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


--f46d0442806e1a6153051c1d28b5-- From nobody Thu Jul 30 13:23:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC631ACE7A for ; Thu, 30 Jul 2015 13:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k5HfkGFQ25B for ; Thu, 30 Jul 2015 13:23:21 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782611ACE67 for ; Thu, 30 Jul 2015 13:23:21 -0700 (PDT) Received: by wibud3 with SMTP id ud3so6536095wib.0 for ; Thu, 30 Jul 2015 13:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fg49MQBd3ZI/9IrRklIQI3Y1qhat7HQPTFE/acsYpdM=; b=QyXpMkCNOEIGBW15dUMKnzyeIsMHZFww16xuf33W0JAGhAFddlTy9UZbSxYMeMylhR p9rlXRcw/3GWtS82wEVaedsmpS36l7s1eIvZl7OdZGt8S991vN9vLiGVKrEEfx9zC5sd NPkNY3+CVJalpW/LeD7SgLqbwkvAOTiH7JI1dKDRQm30NLoA99VffPlM2vGdQ5zEPzSb gQ/mi3gPtROeoMCEXyT6EzMangvcjMFSQU5weimccYDb2hBOjQoqJw/sB5t8gTMOc4gA 8VwL3yi4ChREHeMxt2ZAEOrmwZ6tB4UQMK9wjcb3x0K6UK2RAdayOKtcE0PUz0NjoQIw R4yg== MIME-Version: 1.0 X-Received: by 10.180.74.115 with SMTP id s19mr9395175wiv.18.1438287800263; Thu, 30 Jul 2015 13:23:20 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Thu, 30 Jul 2015 13:23:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 13:23:20 -0700 Message-ID: From: Ted Hardie To: Bernard Aboba Content-Type: multipart/alternative; boundary=f46d043c825a6b6ab6051c1d79a1 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Interim discussion? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 20:23:23 -0000 --f46d043c825a6b6ab6051c1d79a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 30, 2015 at 1:00 PM, Bernard Aboba wrote > > [BA] That could be made to work, though to piggyback on the WEBRTC WG > interim in September, it would be necessary to quickly understand the > schedule/attendance impact on the existing plans (e.g. impact on the > estimated attendance, whether the existing dates would stay the same or > would need extending, etc.). > > =E2=80=8BOne option here would be to make it a virtual interim within the u= sual terms (conference-based call), but understand that lots of attendees might happen to be in the same place. That would be particularly useful if we could do the virtual one at some mid-point of the W3C f2f interim, since we seem to run into issue passing a fair amount during these meetings. We could add a physical interim on one side or the other (maybe nearby, if Microsoft could no host both), but it is close timing to do so. Ted=E2=80=8B --f46d043c825a6b6ab6051c1d79a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 30, 2015 at 1:00 PM= , Bernard Aboba <bernard.aboba@gmail.com> wrote

[BA] That could be made to work, thoug= h to piggyback on the WEBRTC WG interim in September, it would be necessary= to quickly understand the schedule/attendance impact on the existing plans= (e.g. impact on the estimated attendance, whether the existing dates would= stay the same or would need extending, etc.).=C2=A0


=E2=80=8BOne option here would be to make it a vi= rtual interim within the usual terms (conference-based call), but understan= d that lots of attendees might happen to be in the same place.=C2=A0 That w= ould be particularly useful if we could do the virtual one at some mid-poin= t of the W3C f2f interim, since we seem to run into issue passing a fair am= ount during these meetings.=C2=A0 We could add a physical interim on one si= de or the other (maybe nearby, if Microsoft could no host both), but it is = close timing to do so.

Ted=E2=80=8B

<= /div> --f46d043c825a6b6ab6051c1d79a1-- From nobody Thu Jul 30 14:11:11 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09B71A9300 for ; Thu, 30 Jul 2015 14:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLDim7yRjx7g for ; Thu, 30 Jul 2015 14:11:08 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD721A90C6 for ; Thu, 30 Jul 2015 14:11:08 -0700 (PDT) Received: by ioea135 with SMTP id a135so66644697ioe.1 for ; Thu, 30 Jul 2015 14:11:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ABbT9aU6EIn4q+z5fFJH2lgMiQ5qGoCsbJUGOf5yKq4=; b=bY4w9fllc16gxqHHIT3jaei1Oz0rE0rswOZQsdO26QsboSto2k+xr6EoAru1UNRX+G L0dbeXHZLw76cCp3uFN3nEakM5koGH+qciGWDyQOU/MgW3PVqLLxFr28JhpybPbrqf4P FRHiq5Lj/pY6vpn5IQ0utW1SjItJ8UDy7WOgVawUDor4sgASIkrCx62Y0SjkfyKgQFG+ +g3m5aYi/GDmH/ZkY/+egdHj1vrT4BNwQdXVc8mXRaoZXWqY7b24MJKi+AMlAnoSkzgC MN/R3gzhAUs2KmGTdVwKNh0BzYn2UMJA5RaXb3f5rJn8AvpyUvYwysgqCHB453SLXVoX EIPA== X-Gm-Message-State: ALoCoQnegYTWckT7kiEr6y/ZsppWfOfRHsApqIXrgJPXatPoZSrH7QqkPuoQGCKrKM59gdi9sNMI X-Received: by 10.107.157.4 with SMTP id g4mr13594245ioe.66.1438290668007; Thu, 30 Jul 2015 14:11:08 -0700 (PDT) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com. [209.85.223.177]) by smtp.gmail.com with ESMTPSA id u35sm1558442iou.7.2015.07.30.14.11.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 14:11:06 -0700 (PDT) Received: by ioea135 with SMTP id a135so66643833ioe.1 for ; Thu, 30 Jul 2015 14:11:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.150.141 with SMTP id y135mr13254412iod.38.1438290665950; Thu, 30 Jul 2015 14:11:05 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Thu, 30 Jul 2015 14:11:05 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 17:11:05 -0400 Message-ID: From: Roman Shpount To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a11403fd43a5fbc051c1e2404 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 21:11:10 -0000 --001a11403fd43a5fbc051c1e2404 Content-Type: text/plain; charset=UTF-8 As long as webrtc compliant end point MUST offer rtcp-mux and MUST always accepted if offered by the remote end point I am ok with this. Compliant end points MAY offer additional candidates for RTCP and accept offers and answers without rtcp-mux. _____________ Roman Shpount On Thu, Jul 30, 2015 at 3:35 PM, Peter Thatcher wrote: > I didn't quite mean mandatory-to-use. If an rtcweb endpoint wants to use > non-muxed RTCP, it could go ahead and do that, so it's not quite > mandatory-to-use-rtcp-mux, but instead free-to-not-support-non-muxed-rtcp. > > Perhaps my proposal should instead be: rtcweb endpoints MAY make RtcpMuxPolicy > == "required" the default and MAY remove support for RtcpMuxPolicy == > "negotiate". > > That would leave the door open to endpoints that want to support non-muxed > RTCP, which mandatory-to-use would not. But it would also leave the door > open to endpoints not having to support non-muxed RTCP. > > --001a11403fd43a5fbc051c1e2404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As long as webrtc compliant end point MUST offer rtcp-mux = and MUST always accepted if offered by the remote end point I am ok with th= is.

Compliant end points MAY offer additional candidates= for RTCP and accept offers and answers without rtcp-mux.
_____________
Roman Shpount=

On Thu, Jul 30, 2015 at 3:35 PM, Peter Thatc= her <pthatcher@google.com> wrote:
I didn't quite mean mandatory-to-use.=C2=A0 If an rtcweb endpoin= t wants to use non-muxed RTCP, it could go ahead and do that, so it's n= ot quite mandatory-to-use-rtcp-mux, but instead free-to-not-support-non-mux= ed-rtcp.

Perhaps my proposa= l should instead be: =C2=A0rtcweb endpoints MAY make=C2=A0RtcpMuxPolicy =3D=3D "required" the default and M= AY remove support for RtcpMuxPolicy =3D=3D "negotiate".

That would leave the door open = to endpoints that want to support non-muxed RTCP, which mandatory-to-use wo= uld not.=C2=A0 But it would also leave the door open to endpoints not havin= g to support non-muxed RTCP.

--001a11403fd43a5fbc051c1e2404-- From nobody Thu Jul 30 20:05:03 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1201B3015 for ; Thu, 30 Jul 2015 20:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2gAyc4xC4lj for ; Thu, 30 Jul 2015 20:05:00 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12501B3012 for ; Thu, 30 Jul 2015 20:04:59 -0700 (PDT) Received: by wibud3 with SMTP id ud3so14641160wib.0 for ; Thu, 30 Jul 2015 20:04:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qWKnvs8RSEgHBM5+sxso75PLseqoWfNKp4P4GU/l2cU=; b=Ev7Xm0LZrs8pvcAeLA9NAaqzLgwa/yI5J4Zox3WMdmKa/YE4tn7NO8kLJoBtn/yF3p WNml4t6Hqxk6ivzJgMjlnQsiM8mXIxIb27fbaQOLFcwxXuAMTzqPJufAj6inG7gugUhA hMT6qTeXJNxMjZVuwMpAIbdD9kbUP5BgMhRR52Bogt31F/GOEJuNHsbv71EtY2TcT+x/ htkZqEeqAFwm7J1a13gvJHiC+F73Pe3nAugtorTTgCKVJoLngxlF3Xhs9moW7deze0QB g92aF1NkizwwAgm4nxdyNO7IgGrt37Rsbr3FyRD+NTEq1BM11MFGsA0FQZl3+KpJw5xs H7Xg== X-Gm-Message-State: ALoCoQnc+xrbJB9DKotcMsItYxr5xW77Fo5j+e26vxyTkWMnsznUDCsiFYj0zaijJRm2qJ+P7G/b X-Received: by 10.194.79.225 with SMTP id m1mr1086261wjx.8.1438311898326; Thu, 30 Jul 2015 20:04:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Thu, 30 Jul 2015 20:04:18 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 31 Jul 2015 05:04:18 +0200 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=047d7b10c903c6d911051c231529 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 03:05:02 -0000 --047d7b10c903c6d911051c231529 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher wrote: > At IETF 93 last week, Cullen pointed out that he looked into ICE > endpoints and found that all of them support rtcp-mux. Inspired by that, I > went around and asked about a dozen people "would you be OK if we removed > support for non-muxed RTCP?" The range of responses went from "I'm OK with > it if Cullen is" to "yeah, that would be great". No one said no. Cullen > said yes. > > For me, removing support for non-muxed RTCP would be like Christmas in > July. > Realistically, August at this point. So here's my proposal: make RtcpMuxPolicy == "required" be not only the > default, but the only RtcpMuxPolicy available. All rtcweb endpoints must > support rtcp-mux. > This seems reasonable. > An rtcweb endpoint would be free to fail if the remote endpoint does not > support rtcp-mux. > Given the current specification, I believe this would need to be strong. I.e., an rtcweb endpoint *must* fail if the remote endpoint does not support rtcp-mux. As should be obvious, this only applies when the rtcweb endpoint is an answerer since with the above setting, you will not provide an offer that the other side can accept, but the spec says: "When acting as answerer, the browser will reject any m= section that does not provide an "a=rtcp-mux" attribute." The reason for that is to avoid asymmetrical situations in which endpoint NM (non-mux) makes an offer to endpoint M (mux) which is accepted, but then re-offers from NM to M fail. So I believe the best version of this proposal is simply requiring rtcp-mux entirely. -Ekr > The whole reason we didn't do this before was because we wanted to work > with legacy equipment. But Cullen's claim is that there is no legacy > equipment that can speak ICE (and DTLS) but not rtcp-mux. > > So is there any remaining reason that we cannot require rtcp-mux? > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b10c903c6d911051c231529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher <<= a href=3D"mailto:pthatcher@google.com" target=3D"_blank">pthatcher@google.c= om> wrote:
At IETF 93 last week= , =C2=A0Cullen pointed out that he looked into ICE endpoints and found that= all of them support rtcp-mux.=C2=A0 Inspired by that, I went around and as= ked about a dozen people "would you be OK if we removed support for no= n-muxed RTCP?" =C2=A0The range of responses went from "I'm OK= with it if Cullen is" to "yeah, that would be great".=C2=A0= No one said no.=C2=A0 Cullen said yes. =C2=A0

For me, removing support for non-muxed RTCP would be li= ke Christmas in July.

Realistic= ally, August at this point.


So here's my proposal: =C2=A0make RtcpMuxPolicy =3D=3D &= quot;required" be not only the default, but the only RtcpMuxPolicy ava= ilable. =C2=A0 All rtcweb endpoints must support rtcp-mux. =C2=A0

This seems reasonable.

=C2=A0
An rtcweb endpoint would be= free to fail if the remote endpoint does not support rtcp-mux.
=

Given the current specification, I believe= this would need to be strong. I.e., an rtcweb
endpoint *must* fa= il if the remote endpoint does not support rtcp-mux. As should=C2=A0
<= div>be obvious, this only applies when the rtcweb endpoint is an answerer s= ince with
the above setting, you will not provide an offer that t= he other side can accept, but
the spec says:

=
"When acting as answerer, the browser will reject any m=3D sectio= n that does not provide an "a=3Drtcp-mux" attribute."
<= div>
The reason for that is to avoid asymmetrical situations = in which endpoint NM
(non-mux) makes an offer to endpoint M (mux)= which is accepted, but then
re-offers from NM to M fail.

So I believe the best version of this proposal is simply = requiring rtcp-mux
entirely.

-Ekr
<= div>
=C2=A0
The whole reason we didn't = do this before was because we wanted to work with legacy equipment.=C2=A0 B= ut Cullen's claim is that there is no legacy equipment that can speak I= CE (and DTLS) but not rtcp-mux.=C2=A0

So is there any remaining reason that we cannot require rtcp-mux= ?




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b10c903c6d911051c231529-- From nobody Thu Jul 30 21:01:57 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9571B303F for ; Thu, 30 Jul 2015 21:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLePByEShPRw for ; Thu, 30 Jul 2015 21:01:55 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB7B1B303C for ; Thu, 30 Jul 2015 21:01:55 -0700 (PDT) Received: by obnw1 with SMTP id w1so45451476obn.3 for ; Thu, 30 Jul 2015 21:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2cNvU2oWa4w49kUu6O8zGYsyO1khbKKtHw5RRPgDx8I=; b=Q7MnPosihNHbhX16B8IRYCgEBFxQ+SKBPQFk23VaTrOcj3zJm1+w3DNsqn2plSSK7B sLkCEk//NIrkd/LAYrqUbxDG3NaIeWuiUSXxqpY1xdUYBhqx9yC2WQ84FWd66hruGivD vWwayTt0Hl2Le4M66MS6qnaWZgjUEoKn16/WtS+ZWPN7oTuciwqU0mfSY+KOBNtqCh/P NX7NhjtVdv8aQ8fb5ay5Nil3CDyBhfdiQU0X7ePmzH0aXBsTTXj5gyojbrZXRilyzj7L y92mpTRNlcOR8NnnXbjsf2ciWnSTfyH4PcwZutNZidRqhjuoQfqLM+GdiPvHgBJ88kYz kjRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2cNvU2oWa4w49kUu6O8zGYsyO1khbKKtHw5RRPgDx8I=; b=nMTt7sH52CUgfWagQT5qiVuB/29q48QqlpWHnlE5B2QBEDcqd7UKPbUqQD3otwWp7B D4OSMw9dVcArEde9ky/RLUNt4gE8c4QX2x3vmcuDp8vQRdAtnvhzevpr6e66vuxEpYYt eNh4yyQthaNWy1hw02pO8a0/faUcZUkj1ruO7rvj8jfiDND0m9QbcnevluZVf+nuZJhC zYdAmcYrbm9ru3jJ28OVJRcGL8TLNv5SO3FjYjnEa4ruZmCgf1dqijMYESwCkfw9GXIC eMXnrisN3BWbheto53R22MywulLfO1dq0UNR+nbsh+U9ssbkx1IC++9cECEFhJbOCYxW /bTQ== X-Gm-Message-State: ALoCoQkHQnHEb0LHMem7ua1isQuwJSXngU6gEneHZguv0vMR5y5UHXls6fzZYqJF/1l2zUj+cQ83 X-Received: by 10.60.76.4 with SMTP id g4mr664490oew.81.1438315314476; Thu, 30 Jul 2015 21:01:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.171.233 with HTTP; Thu, 30 Jul 2015 21:01:15 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Thu, 30 Jul 2015 21:01:15 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b33d4aa653b37051c23e117 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 04:01:57 -0000 --047d7b33d4aa653b37051c23e117 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 30, 2015 at 8:04 PM, Eric Rescorla wrote: > > > On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher > wrote: > >> At IETF 93 last week, Cullen pointed out that he looked into ICE >> endpoints and found that all of them support rtcp-mux. Inspired by that= , I >> went around and asked about a dozen people "would you be OK if we remove= d >> support for non-muxed RTCP?" The range of responses went from "I'm OK w= ith >> it if Cullen is" to "yeah, that would be great". No one said no. Culle= n >> said yes. >> >> For me, removing support for non-muxed RTCP would be like Christmas in >> July. >> > > Realistically, August at this point. > =E2=80=8BClose enough :) =E2=80=8B > > > So here's my proposal: make RtcpMuxPolicy =3D=3D "required" be not only = the >> default, but the only RtcpMuxPolicy available. All rtcweb endpoints mu= st >> support rtcp-mux. >> > > This seems reasonable. > > > >> An rtcweb endpoint would be free to fail if the remote endpoint does not >> support rtcp-mux. >> > > Given the current specification, I believe this would need to be strong. > I.e., an rtcweb > endpoint *must* fail if the remote endpoint does not support rtcp-mux. As > should > be obvious, this only applies when the rtcweb endpoint is an answerer > since with > the above setting, you will not provide an offer that the other side can > accept, but > the spec says: > > "When acting as answerer, the browser will reject any m=3D section that d= oes > not provide an "a=3Drtcp-mux" attribute." > > The reason for that is to avoid asymmetrical situations in which endpoint > NM > (non-mux) makes an offer to endpoint M (mux) which is accepted, but then > re-offers from NM to M fail. > > So I believe the best version of this proposal is simply requiring rtcp-m= ux > entirely. > =E2=80=8BThat makes sense, and I would be happy with "reject any m=3D secti= on without a=3Drtcp-mux".=E2=80=8B > > -Ekr > > > >> The whole reason we didn't do this before was because we wanted to work >> with legacy equipment. But Cullen's claim is that there is no legacy >> equipment that can speak ICE (and DTLS) but not rtcp-mux. >> >> So is there any remaining reason that we cannot require rtcp-mux? >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --047d7b33d4aa653b37051c23e117 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 30, 2015 at 8:04 PM, Eric Rescorla <ekr@rtfm.com&g= t; wrote:


On = Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher <pthatcher@google.com= > wrote:
At IETF 93 last week, =C2= =A0Cullen pointed out that he looked into ICE endpoints and found that all = of them support rtcp-mux.=C2=A0 Inspired by that, I went around and asked a= bout a dozen people "would you be OK if we removed support for non-mux= ed RTCP?" =C2=A0The range of responses went from "I'm OK with= it if Cullen is" to "yeah, that would be great".=C2=A0 No o= ne said no.=C2=A0 Cullen said yes. =C2=A0

For me, removing support for non-muxed RTCP would be like Ch= ristmas in July.

Realist= ically, August at this point.

=
=E2=80=8BClose enough :)
=E2=80=8B
=C2=A0


So here&#= 39;s my proposal: =C2=A0make RtcpMuxPolicy =3D=3D "required" be n= ot only the default, but the only RtcpMuxPolicy available. =C2=A0 All rtcwe= b endpoints must support rtcp-mux. =C2=A0

=
This seems reasonable.

=C2=A0
An rtcweb endpoint would be= free to fail if the remote endpoint does not support rtcp-mux.
=

Given the current specification, I = believe this would need to be strong. I.e., an rtcweb
endpoint *m= ust* fail if the remote endpoint does not support rtcp-mux. As should=C2=A0=
be obvious, this only applies when the rtcweb endpoint is an ans= werer since with
the above setting, you will not provide an offer= that the other side can accept, but
the spec says:
"When acting as answerer, the browser will reject any m=3D= section that does not provide an "a=3Drtcp-mux" attribute."=

The reason for that is to avoid asymmetrical situ= ations in which endpoint NM
(non-mux) makes an offer to endpoint = M (mux) which is accepted, but then
re-offers from NM to M fail.<= /div>

So I believe the best version of this proposal is = simply requiring rtcp-mux
entirely.

=E2=80=8BThat makes sense, and I would be hap= py with "reject any m=3D section without a=3Drtcp-mux".=E2=80=8B<= /div>
=C2=A0

<= div>-Ekr

=C2=A0
= The whole reason we didn't do this before was because we wanted to work= with legacy equipment.=C2=A0 But Cullen's claim is that there is no le= gacy equipment that can speak ICE (and DTLS) but not rtcp-mux.=C2=A0
<= div style=3D"font-family:arial,helvetica,sans-serif">
So is there any remaining reaso= n that we cannot require rtcp-mux?



_______________________________________________=
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb



--047d7b33d4aa653b37051c23e117-- From nobody Fri Jul 31 03:19:05 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778C91A00EC for ; Fri, 31 Jul 2015 03:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kI-2ZY5pKPs5 for ; Fri, 31 Jul 2015 03:19:01 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0053.outbound.protection.outlook.com [65.55.169.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E218C1A00E8 for ; Fri, 31 Jul 2015 03:19:00 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 31 Jul 2015 10:18:58 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Fri, 31 Jul 2015 10:18:58 +0000 From: "Asveren, Tolga" To: Eric Rescorla , Peter Thatcher Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyz2WarP6bihqdUKrjE+AJblPlJ31XJYc Date: Fri, 31 Jul 2015 10:18:57 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:rhhEAMoYzt1KwGImMp6qefhEs+ltNCL+AGtbfX64Xhi8xN7BoaK+auxOBVbe5xT5Xv2/tywm8dliFFvShXR+RX0TbU5Jh0aEy69lwWk0rVjN1nhdSx9fpmCVqyi1TD6V8LZxWVOzAS+6W92NVd/nhA==; 24:08gBbDJDhALBNL2yevlf3EkRn7NUC/rQosB16AOiYzLz4v89Yw4SgbjBfhoIOwi6OW3993v8jWu3ueWgEvtbVVgTWxoWa1+p9HOTLNq6YyE=; 20:+wtzmsqfW3J2lYLKv0whE7WDPnPB4cm5lqsLVTzMxg1HcK9/LFjJ6KdqAWB1IpZ8hgDOiQqTujFcC0EpsZ2KJw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; sn1pr0301mb1549: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(164054003)(62966003)(2656002)(2950100001)(19580395003)(74316001)(19580405001)(16236675004)(40100003)(66066001)(46102003)(92566002)(87936001)(19617315012)(189998001)(5002640100001)(76176999)(15975445007)(54356999)(50986999)(5003600100002)(99286002)(76576001)(86362001)(5001960100002)(77156002)(102836002)(77096005)(122556002)(106116001)(33656002)(5001770100001)(561944003)(2900100001)(19625215002)(19627405001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551E28A489A90A93FA2F8BDB28A0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 10:18:57.9981 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 10:19:03 -0000 --_000_SN1PR0301MB1551E28A489A90A93FA2F8BDB28A0SN1PR0301MB1551_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "The whole reason we didn't do this before was because we wanted to work wi= th legacy equipment. But Cullen's claim is that there is no legacy equipme= nt that can speak ICE (and DTLS) but not rtcp-mux." I am not sure whether this is entirely true, especially on GW front. It cou= ld be a better idea to be lenient for enhanced interoperability and making = RTCWeb more deployable in practice. Can't the decision of being firm on usi= ng rtcp-mux left to the WebRTC endpoint with signaling aspects supporting n= egotiation of the capability? Thanks, Tolga ________________________________ From: rtcweb on behalf of Eric Rescorla Sent: Thursday, July 30, 2015 11:04 PM To: Peter Thatcher Cc: Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it= would be Christmas in July!) On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher > wrote: At IETF 93 last week, Cullen pointed out that he looked into ICE endpoints= and found that all of them support rtcp-mux. Inspired by that, I went aro= und and asked about a dozen people "would you be OK if we removed support f= or non-muxed RTCP?" The range of responses went from "I'm OK with it if Cu= llen is" to "yeah, that would be great". No one said no. Cullen said yes. For me, removing support for non-muxed RTCP would be like Christmas in July= . Realistically, August at this point. So here's my proposal: make RtcpMuxPolicy =3D=3D "required" be not only th= e default, but the only RtcpMuxPolicy available. All rtcweb endpoints mus= t support rtcp-mux. This seems reasonable. An rtcweb endpoint would be free to fail if the remote endpoint does not su= pport rtcp-mux. Given the current specification, I believe this would need to be strong. I.= e., an rtcweb endpoint *must* fail if the remote endpoint does not support rtcp-mux. As s= hould be obvious, this only applies when the rtcweb endpoint is an answerer since= with the above setting, you will not provide an offer that the other side can ac= cept, but the spec says: "When acting as answerer, the browser will reject any m=3D section that doe= s not provide an "a=3Drtcp-mux" attribute." The reason for that is to avoid asymmetrical situations in which endpoint N= M (non-mux) makes an offer to endpoint M (mux) which is accepted, but then re-offers from NM to M fail. So I believe the best version of this proposal is simply requiring rtcp-mux entirely. -Ekr The whole reason we didn't do this before was because we wanted to work wit= h legacy equipment. But Cullen's claim is that there is no legacy equipmen= t that can speak ICE (and DTLS) but not rtcp-mux. So is there any remaining reason that we cannot require rtcp-mux? _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_SN1PR0301MB1551E28A489A90A93FA2F8BDB28A0SN1PR0301MB1551_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

"The whole reason we didn't do this before= was because we wanted to work with legacy equipment.  But Cullen's cl= aim is that there is no legacy equipment that can speak ICE (and DTLS) but not rtcp-mux."


I am not sure whether this is entirely true, especia= lly on GW front. It could be a better idea to be lenient for enhanced inter= operability and making RTCWeb more deployable in practice. Can't the decision of being firm on using rtcp-mux left to th= e WebRTC endpoint with signaling aspects supporting negotiation of the capa= bility?


Thanks,

Tolga



From: rtcweb <rtcweb-bou= nces@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Thursday, July 30, 2015 11:04 PM
To: Peter Thatcher
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed R= TCP; it would be Christmas in July!)
 


On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher = <pthatcher@goo= gle.com> wrote:
At IETF 93 last week,=  Cullen pointed out that he looked into ICE endpoints and found that = all of them support rtcp-mux.  Inspired by that, I went around and ask= ed about a dozen people "would you be OK if we removed support for non-muxed RTCP?"  The range of responses = went from "I'm OK with it if Cullen is" to "yeah, that would= be great".  No one said no.  Cullen said yes.  

For me, removing supp= ort for non-muxed RTCP would be like Christmas in July.

Realistically, August at this point.


So here's my proposal= :  make RtcpMuxPolicy =3D=3D "required" be not only the defa= ult, but the only RtcpMuxPolicy available.   All rtcweb endpoints must= support rtcp-mux.  

This seems reasonable.

 
An rtcweb endpoint wo= uld be free to fail if the remote endpoint does not support rtcp-mux.

Given the current specification, I believe this would need to be stron= g. I.e., an rtcweb
endpoint *must* fail if the remote endpoint does not support rtcp-mux.= As should 
be obvious, this only applies when the rtcweb endpoint is an answerer = since with
the above setting, you will not provide an offer that the other side c= an accept, but
the spec says:

"When acting as answerer, the browser will reject any m=3D sectio= n that does not provide an "a=3Drtcp-mux" attribute."

The reason for that is to avoid asymmetrical situations in which endpo= int NM
(non-mux) makes an offer to endpoint M (mux) which is accepted, but th= en
re-offers from NM to M fail.

So I believe the best version of this proposal is simply requiring rtc= p-mux
entirely.

-Ekr

 
The whole reason we d= idn't do this before was because we wanted to work with legacy equipment.&n= bsp; But Cullen's claim is that there is no legacy equipment that can speak= ICE (and DTLS) but not rtcp-mux. 

So is there any remai= ning reason that we cannot require rtcp-mux?




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--_000_SN1PR0301MB1551E28A489A90A93FA2F8BDB28A0SN1PR0301MB1551_-- From nobody Fri Jul 31 03:47:15 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527D11A0119 for ; Fri, 31 Jul 2015 03:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhoDUSNKRB6O for ; Fri, 31 Jul 2015 03:47:10 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F55B1A014D for ; Fri, 31 Jul 2015 03:47:09 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t6VAlCcX009046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Jul 2015 12:47:13 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t6VAlCrh009045 for rtcweb@ietf.org; Fri, 31 Jul 2015 12:47:12 +0200 Date: Fri, 31 Jul 2015 12:47:12 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150731104712.GA5228@lo.psyced.org> References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 10:47:13 -0000 Alright, thanks Tim for digging deeper and confirming that we have a serious problem here. Unfortunately everybody else is talking of other things and giving the impression we are having just a side discussion.. and the problem remains: WebRTC threatens lives of dissidents. If we can't publish news that rtcweb has fixed the problem then the logical consequence is to publish that n months have passed and rtcweb is still not willing to fix the issue.... which can be interpreted as a political news all on its own - how industry does not care about collateral damages. Certainly we can't just keep quiet and let this become a working strategy to ignore issues. So, dear folks, this is your chance to keep the next shitstorm from coming your way. Do something! On Mon, Jul 20, 2015 at 01:23:08PM +0100, Tim Panton wrote: > > > On 16 Jul 2015, at 09:42, carlo von lynX > wrote: > > > > Yes, I dare to speak out of my 25 years of experience on the > > Internet even if I didn't have to use much VPN ever. I can > > imagine plenty of constellations where the VPN is NOT supposed > > to take over all communications on the system but rather offer > > a side route into a company's servers or suchlike. Therefore > > I worry if the software provider can always come up with a > > configuration that still does what the customers expect and > > at the same time deals with the new backdoor introduced by WebRTC. > > Of course anyone with better understanding can help clear up > > these worries. > > > >> That isn’t what I meant. I expect secure software providers to keep their > >> software abreast of new developments. > > It turns out that I was completely wrong. The browsers are currently so > thorough in their discovery of available interfaces and routes that no > amount of changes by the sys admin or VPN supplier will fix this problem. > > Sorry about that. > > > > > Uh, not sure if that is an established pattern in the industry. > > Usually somebody does whatever fits into their business model > > best, then there is a public outcry and possibly some bloodspill, > > then all the players look at how they can make a good impression > > by reducing the collateral damages.. but if that doesn't work out > > cheap and easy.. tant pis. Let's continue with business. > > > >> I happen to have the (no doubt under informed) opinion that > >> this isn’t as simple as it has been made out to be. > > At least I was right here. - It is even more complex than I believed. > > > > > Well, in case of doubt it is important to pick the conservative > > option until the issue is properly analyzed rather than hoping > > for the general public to forget about the problem. > > > >>> Also the "solution" you suggest AFAIU does not work for people > >>> who use Tor in a non-NATted environment, for example on a > >>> fixed system in a university library with a static IP address. > >> > >> That is an interesting case. In that instance hiding the local IP would be > >> valuable. I thought however those users would normally run a TOR os off > >> a usb stick in a VM. That would probably mask the local IP. > > > > Now that this is more clear, have another look at my original mail > > that describes how such a dissident would use any Windows OS system > > standing around. I doubt anything advanced like TAILS sticks are > > out there as merely possessing one could be life-threatening. > > > Here too I find that I was wrong and the current situation not what I assumed > and is unsatisfactory. > > Most SOCKS proxies don't have support for ICE/STUN nor arbitrary UDP. > The current browser implementations (backed by the ICE spec) take the view that > if SOCKS doesn’t do UDP, then they should go directly and send UDP anyhow. > > I’m not clear that this is what a user might expect. > An alternative might be to detect a proxy config _only_ offer TURN over TLS > candidates (and route the traffic over the proxy) - This would result in > poor audio/video but would be more in keeping with the spirit of the proxy config. > > (a variant might be to inspect the proxy in detail and use the address whitelists > to filter allowed traffic somehow?) > > > >> > >> I totally agree. My solution is imho a better fix, since it > >> also protects against many other apps that might get started from > >> a browser page (email, dns, ipv6 tunnels, flash, mp3 players etc). > > > Turns out I was wrong - sigh - as I said the browsers are more aggressive > in finding routes than I assumed (or indeed than my ICE implementations are). > > > Breaking the proxy principle is neither a Tor nor a VPN problem. > > It's just browser vendors breaking a promise given to users that > > configured proxies would be respected. > > > >> I’m SOCKs ignorant. > > > > So we all have our knowledge deficiencies... > > good to be honest about them. > > > > And now that I’ve educated myself somewhat, I’m agreeing with you. > > > >>> And if local IP information is so super harmless, then why is it > >>> an obvious reason for TBB devs to disable the entire thing? > >>> I presume for the reasons I stated before. > >> > >> I have no idea, but I fear it is because no one has split these issues out. > > > > So let's dissect some more until we know what we are doing. > > Which turns out to be the only useful contribution my made. > > > > > >> I’m of the view that there are _useful_ instances of P2P crypto > >> in-browser - we will clearly have to disagree about that. > > > > I think we could improve the user's ability to ensure end-to-end > > authentication beyond server-based negotiation. Something like > > rendering persistent public keys into QR codes and having people > > exchange those QR codes at cocktail parties and hackathons. > > > > Servers would still be able to provide the signaling code, but users > > would be granted a guarantee that the E2E connection is authentic. > > > > https://yopet.us :-) > > Tim. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Fri Jul 31 03:52:47 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146131A019B for ; Fri, 31 Jul 2015 03:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ntuzxXOy5Nl for ; Fri, 31 Jul 2015 03:52:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0631.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:631]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E597B1A0092 for ; Fri, 31 Jul 2015 03:52:42 -0700 (PDT) Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (10.161.161.153) by CY1PR0501MB1580.namprd05.prod.outlook.com (10.161.161.154) with Microsoft SMTP Server (TLS) id 15.1.219.17; Fri, 31 Jul 2015 10:52:38 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([10.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([10.161.161.153]) with mapi id 15.01.0225.018; Fri, 31 Jul 2015 10:52:38 +0000 From: "Wyss, Felix" To: "Asveren, Tolga" , Eric Rescorla , Peter Thatcher Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyvx9GhmG1ErIx0u8s3b6H73Snp305TQAgAB5cYCAAAMAeg== Date: Fri, 31 Jul 2015 10:52:38 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [89.217.139.158] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1580; 5:iUKoRuZljqBFTBbR9YZiGqp9gUJjKsQ1ttcBbCL3C2KiU+gosr+4++AvVPdSFq7hxBK/R62W0vpjD1LrnaobsBC+oK5N2XuLVGWTqsonJXQIC3eVaePz+YxMLIHmIh3jynVW8SC3MRMJSt+RdjHkEA==; 24:/pywLNK8AsZVaJl18z9cCw8YoC4ap7xT9Bhyd9rD5GVvWvuPyltt8yr2dDoa7F/GaFfILAMk6O75MWmITBIH96IzaF+rysYBBZv7IHy/ya4=; 20:0rHcauCQL4LmsFRYSNEukexpDKFMbhPESznAE21UGfuGm4tT2J+mmsfJKqq9w1cydtezs+DcvBfaHr/AQ3v2cw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1580; inin-custom-wld: WL-D x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR0501MB1580; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1580; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(377454003)(24454002)(561944003)(19627405001)(102836002)(77096005)(19580405001)(33656002)(189998001)(77156002)(86362001)(46102003)(19580395003)(122556002)(74316001)(2950100001)(40100003)(62966003)(92566002)(15975445007)(19625215002)(87936001)(66066001)(19617315012)(5001770100001)(16236675004)(106116001)(99286002)(2656002)(5001960100002)(76176999)(5001920100001)(5003600100002)(54356999)(50986999)(2900100001)(5002640100001)(76576001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1580; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB1579BC38B75CBC58744A970FEB8A0CY1PR0501MB1579_" MIME-Version: 1.0 X-OriginatorOrg: inin.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 10:52:38.3645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8d07eb62-a903-4bae-bcc2-66c244e76b27 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1580 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 10:52:46 -0000 --_000_CY1PR0501MB1579BC38B75CBC58744A970FEB8A0CY1PR0501MB1579_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As somebody who has to interoperate between WebRTC and legacy VoIP, I whole= heartedly support making RTP/RTCP muxing mandatory. Having just one "pipe"= for everything is IMHO an incredibly compelling feature of WebRTC. Furthe= rmore, the fewer RECOMMENDED vs. MUST we have in the specification, the mor= e likely the WebRTC endpoints from different vendors will be interoperable = without hacks or workarounds. --Felix ________________________________ From: rtcweb on behalf of Asveren, Tolga Sent: Friday, July 31, 2015 06:18 To: Eric Rescorla; Peter Thatcher Cc: Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it= would be Christmas in July!) "The whole reason we didn't do this before was because we wanted to work wi= th legacy equipment. But Cullen's claim is that there is no legacy equipme= nt that can speak ICE (and DTLS) but not rtcp-mux." I am not sure whether this is entirely true, especially on GW front. It cou= ld be a better idea to be lenient for enhanced interoperability and making = RTCWeb more deployable in practice. Can't the decision of being firm on usi= ng rtcp-mux left to the WebRTC endpoint with signaling aspects supporting n= egotiation of the capability? Thanks, Tolga ________________________________ From: rtcweb on behalf of Eric Rescorla Sent: Thursday, July 30, 2015 11:04 PM To: Peter Thatcher Cc: Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it= would be Christmas in July!) On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher > wrote: At IETF 93 last week, Cullen pointed out that he looked into ICE endpoints= and found that all of them support rtcp-mux. Inspired by that, I went aro= und and asked about a dozen people "would you be OK if we removed support f= or non-muxed RTCP?" The range of responses went from "I'm OK with it if Cu= llen is" to "yeah, that would be great". No one said no. Cullen said yes. For me, removing support for non-muxed RTCP would be like Christmas in July= . Realistically, August at this point. So here's my proposal: make RtcpMuxPolicy =3D=3D "required" be not only th= e default, but the only RtcpMuxPolicy available. All rtcweb endpoints mus= t support rtcp-mux. This seems reasonable. An rtcweb endpoint would be free to fail if the remote endpoint does not su= pport rtcp-mux. Given the current specification, I believe this would need to be strong. I.= e., an rtcweb endpoint *must* fail if the remote endpoint does not support rtcp-mux. As s= hould be obvious, this only applies when the rtcweb endpoint is an answerer since= with the above setting, you will not provide an offer that the other side can ac= cept, but the spec says: "When acting as answerer, the browser will reject any m=3D section that doe= s not provide an "a=3Drtcp-mux" attribute." The reason for that is to avoid asymmetrical situations in which endpoint N= M (non-mux) makes an offer to endpoint M (mux) which is accepted, but then re-offers from NM to M fail. So I believe the best version of this proposal is simply requiring rtcp-mux entirely. -Ekr The whole reason we didn't do this before was because we wanted to work wit= h legacy equipment. But Cullen's claim is that there is no legacy equipmen= t that can speak ICE (and DTLS) but not rtcp-mux. So is there any remaining reason that we cannot require rtcp-mux? _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CY1PR0501MB1579BC38B75CBC58744A970FEB8A0CY1PR0501MB1579_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

As somebody who has to interoperate between WebRTC and legacy VoIP, I wh= oleheartedly support making RTP/RTCP muxing mandatory.  Having just on= e "pipe" for everything is IMHO an incredibly compelling feature = of WebRTC.  Furthermore, the fewer RECOMMENDED vs. MUST we have in the specification, the more likely the WebRTC endpoint= s from different vendors will be interoperable without hacks or workarounds= .  


--Felix

From: rtcweb <rtcweb-b= ounces@ietf.org> on behalf of Asveren, Tolga <tasveren@sonusnet.com&g= t;
Sent: Friday, July 31, 2015 06:18
To: Eric Rescorla; Peter Thatcher
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed R= TCP; it would be Christmas in July!)
 

"The whole reason we didn't do this before was bec= ause we wanted to work with legacy equipment.  But Cullen's claim is t= hat there is no legacy equipment that can speak ICE (and DTLS) but not rtcp-mux."


I am not sure whether this is entirely true, especiall= y on GW front. It could be a better idea to be lenient for enhanced interop= erability and making RTCWeb more deployable in practice. Can't the decision of being firm on using rtcp-mux left to th= e WebRTC endpoint with signaling aspects supporting negotiation of the capa= bility?


Thanks,

Tolga



From: rtcweb <rtcweb-b= ounces@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Thursday, July 30, 2015 11:04 PM
To: Peter Thatcher
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed R= TCP; it would be Christmas in July!)
 


On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher = <pthatcher@goo= gle.com> wrote:
At IETF 93 last week,=  Cullen pointed out that he looked into ICE endpoints and found that = all of them support rtcp-mux.  Inspired by that, I went around and ask= ed about a dozen people "would you be OK if we removed support for non-muxed RTCP?"  The range of responses = went from "I'm OK with it if Cullen is" to "yeah, that would= be great".  No one said no.  Cullen said yes.  

For me, removing supp= ort for non-muxed RTCP would be like Christmas in July.

Realistically, August at this point.


So here's my proposal= :  make RtcpMuxPolicy =3D=3D "required" be not only the defa= ult, but the only RtcpMuxPolicy available.   All rtcweb endpoints must= support rtcp-mux.  

This seems reasonable.

 
An rtcweb endpoint wo= uld be free to fail if the remote endpoint does not support rtcp-mux.

Given the current specification, I believe this would need to be stron= g. I.e., an rtcweb
endpoint *must* fail if the remote endpoint does not support rtcp-mux.= As should 
be obvious, this only applies when the rtcweb endpoint is an answerer = since with
the above setting, you will not provide an offer that the other side c= an accept, but
the spec says:

"When acting as answerer, the browser will reject any m=3D sectio= n that does not provide an "a=3Drtcp-mux" attribute."

The reason for that is to avoid asymmetrical situations in which endpo= int NM
(non-mux) makes an offer to endpoint M (mux) which is accepted, but th= en
re-offers from NM to M fail.

So I believe the best version of this proposal is simply requiring rtc= p-mux
entirely.

-Ekr

 
The whole reason we d= idn't do this before was because we wanted to work with legacy equipment.&n= bsp; But Cullen's claim is that there is no legacy equipment that can speak= ICE (and DTLS) but not rtcp-mux. 

So is there any remai= ning reason that we cannot require rtcp-mux?




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--_000_CY1PR0501MB1579BC38B75CBC58744A970FEB8A0CY1PR0501MB1579_-- From nobody Fri Jul 31 04:58:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1331A1A2E for ; Fri, 31 Jul 2015 04:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77JvZQDNwteJ for ; Fri, 31 Jul 2015 04:58:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0665.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:665]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB721A1A2F for ; Fri, 31 Jul 2015 04:58:21 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1552.namprd03.prod.outlook.com (10.162.129.158) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 31 Jul 2015 11:58:02 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Fri, 31 Jul 2015 11:58:02 +0000 From: "Asveren, Tolga" To: "Wyss, Felix" , Eric Rescorla , "Peter Thatcher" Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyz2WarP6bihqdUKrjE+AJblPlJ31XJYcgAAK9gCAABGjIA== Date: Fri, 31 Jul 2015 11:58:02 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: inin.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1552; 5:lxtCCgMh6U5xboedxHFlEdO9xtxw/mTyCeL0xsLAHIlVXDG3zLMAdQkn6uL51sNbYyaDFjyx9/9J0AB7q9LCn/DY1ozOAnmLJm8wYCbfgQZo1nHA3zxOHIMIFf1BV52DUH3L8mCl16kG9nwJlduOKg==; 24:S1pn59RSZubumTu3uvc6+xu3ztKNH2nNG/9/TwjMP0pqnLaNE7xZqNEl393IonliTs4yKxxyZG7I+qpA9Ky0g7jIzUaaxl6XDWBFlwjv1CM=; 20:mEGwntJmArftm+53bKla9C0U5Vsixi/xjYfX2cqOMl6gjvYedBuph2WhNxcr/0yTA4ZIZJS24Ps6ISIBP8o6yg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1552; sn1pr0301mb1552: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1552; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1552; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(377454003)(50986999)(19609705001)(5002640100001)(2900100001)(86362001)(76176999)(5003600100002)(19625215002)(5001960100002)(66066001)(92566002)(99286002)(102836002)(77096005)(87936001)(19580405001)(2656002)(15975445007)(189998001)(106116001)(561944003)(46102003)(62966003)(74316001)(93886004)(122556002)(19617315012)(76576001)(40100003)(5001770100001)(77156002)(16236675004)(2950100001)(33656002)(19300405004)(19580395003)(54356999)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1552; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15518198D375F21B973C091DB28A0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 11:58:02.0835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1552 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 11:58:27 -0000 --_000_SN1PR0301MB15518198D375F21B973C091DB28A0SN1PR0301MB1551_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is not really about "what is technically better" (and event there, the b= eauty is in the eye of the beholder depending on the deployment scenario) b= ut more wider interoperability. As long as there is a negotiation mechanism= /freedom to reject, I don't see any harm of allowing not to mandate rtcp-mu= x. You still can mandate its use in a specific implementation. Thanks, Tolga From: Wyss, Felix [mailto:Felix.Wyss@inin.com] Sent: Friday, July 31, 2015 6:53 AM To: Asveren, Tolga ; Eric Rescorla ; P= eter Thatcher Cc: Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it= would be Christmas in July!) As somebody who has to interoperate between WebRTC and legacy VoIP, I whole= heartedly support making RTP/RTCP muxing mandatory. Having just one "pipe"= for everything is IMHO an incredibly compelling feature of WebRTC. Furthe= rmore, the fewer RECOMMENDED vs. MUST we have in the specification, the mor= e likely the WebRTC endpoints from different vendors will be interoperable = without hacks or workarounds. --Felix ________________________________ From: rtcweb > on b= ehalf of Asveren, Tolga > Sent: Friday, July 31, 2015 06:18 To: Eric Rescorla; Peter Thatcher Cc: > Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it= would be Christmas in July!) "The whole reason we didn't do this before was because we wanted to work wi= th legacy equipment. But Cullen's claim is that there is no legacy equipme= nt that can speak ICE (and DTLS) but not rtcp-mux." I am not sure whether this is entirely true, especially on GW front. It cou= ld be a better idea to be lenient for enhanced interoperability and making = RTCWeb more deployable in practice. Can't the decision of being firm on usi= ng rtcp-mux left to the WebRTC endpoint with signaling aspects supporting n= egotiation of the capability? Thanks, Tolga ________________________________ From: rtcweb > on b= ehalf of Eric Rescorla > Sent: Thursday, July 30, 2015 11:04 PM To: Peter Thatcher Cc: > Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it= would be Christmas in July!) On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher > wrote: At IETF 93 last week, Cullen pointed out that he looked into ICE endpoints= and found that all of them support rtcp-mux. Inspired by that, I went aro= und and asked about a dozen people "would you be OK if we removed support f= or non-muxed RTCP?" The range of responses went from "I'm OK with it if Cu= llen is" to "yeah, that would be great". No one said no. Cullen said yes. For me, removing support for non-muxed RTCP would be like Christmas in July= . Realistically, August at this point. So here's my proposal: make RtcpMuxPolicy =3D=3D "required" be not only th= e default, but the only RtcpMuxPolicy available. All rtcweb endpoints mus= t support rtcp-mux. This seems reasonable. An rtcweb endpoint would be free to fail if the remote endpoint does not su= pport rtcp-mux. Given the current specification, I believe this would need to be strong. I.= e., an rtcweb endpoint *must* fail if the remote endpoint does not support rtcp-mux. As s= hould be obvious, this only applies when the rtcweb endpoint is an answerer since= with the above setting, you will not provide an offer that the other side can ac= cept, but the spec says: "When acting as answerer, the browser will reject any m=3D section that doe= s not provide an "a=3Drtcp-mux" attribute." The reason for that is to avoid asymmetrical situations in which endpoint N= M (non-mux) makes an offer to endpoint M (mux) which is accepted, but then re-offers from NM to M fail. So I believe the best version of this proposal is simply requiring rtcp-mux entirely. -Ekr The whole reason we didn't do this before was because we wanted to work wit= h legacy equipment. But Cullen's claim is that there is no legacy equipmen= t that can speak ICE (and DTLS) but not rtcp-mux. So is there any remaining reason that we cannot require rtcp-mux? _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_SN1PR0301MB15518198D375F21B973C091DB28A0SN1PR0301MB1551_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is not really about “what is= technically better” (and event there, the beauty is in the eye of th= e beholder depending on the deployment scenario) but more wider interoperability. As long as there is a negotiation mechanism/freedo= m to reject, I don’t see any harm of allowing not to mandate rtcp-mux= . You still can mandate its use in a specific implementation.

 

Thanks,

Tolga

 

From: Wyss, Felix [mailto:Felix.Wyss= @inin.com]
Sent: Friday, July 31, 2015 6:53 AM
To: Asveren, Tolga <tasveren@sonusnet.com>; Eric Rescorla <= ekr@rtfm.com>; Peter Thatcher <pthatcher@google.com>
Cc: <rtcweb@ietf.org> <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed R= TCP; it would be Christmas in July!)

 

As somebody who has to interoperate between WebRT= C and legacy VoIP, I wholeheartedly support making RTP/RTCP muxing mandator= y.  Having just one "pipe" for everything is IMHO an incredibly compelling feature of WebRTC.  Furthermore, the fewer R= ECOMMENDED vs. MUST we have in the specification, the more likely the WebRT= C endpoints from different vendors will be interoperable without hacks or w= orkarounds.  


--Felix

From: rtcweb <= rtcweb-bounces@ietf.org> on behalf of Asveren, Tolga <t= asveren@sonusnet.com>
Sent: Friday, July 31, 2015 06:18
To: Eric Rescorla; Peter Thatcher
Cc: <rtcweb@ietf.org> Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed R= TCP; it would be Christmas in July!)

 

"The whole reason we didn't= do this before was because we wanted to work with legacy equipment.  = But Cullen's claim is that there is no legacy equipment that can speak ICE (and DTLS) but not rtcp-mux."=

 

I am not sure whether this is en= tirely true, especially on GW front. It could be a better idea to be lenien= t for enhanced interoperability and making RTCWeb more deployable in practice. Can't the decision of being firm on usin= g rtcp-mux left to the WebRTC endpoint with signaling aspects supporting ne= gotiation of the capability?

 

Thanks,

Tolga

&nb= sp;

From: rtcweb <= rtcweb-bounces@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.co= m>
Sent: Thursday, July 30, 2015 11:04 PM
To: Peter Thatcher
Cc: <rtcweb@ietf.org> Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed R= TCP; it would be Christmas in July!)

 

 

 

On Thu, Jul 30, 2015 at 9:17 = PM, Peter Thatcher <pthatcher@google.com> wrote:

At IETF 93 last week,  Cul= len pointed out that he looked into ICE endpoints and found that all of the= m support rtcp-mux.  Inspired by that, I went around and asked about a dozen people "would you be OK if we removed support= for non-muxed RTCP?"  The range of responses went from "I'm= OK with it if Cullen is" to "yeah, that would be great".&nb= sp; No one said no.  Cullen said yes.  

 

For me, removing support for no= n-muxed RTCP would be like Christmas in July.

 

Realistically, August at this= point.

 

 

So here's my proposal:  ma= ke RtcpMuxPolicy =3D=3D "required" be not only the default, but t= he only RtcpMuxPolicy available.   All rtcweb endpoints must support rtcp-mux.  

 

This seems reasonable.

 

 

An rtcweb endpoint would be fre= e to fail if the remote endpoint does not support rtcp-mux.

 

Given the current specificati= on, I believe this would need to be strong. I.e., an rtcweb

endpoint *must* fail if the r= emote endpoint does not support rtcp-mux. As should =

be obvious, this only applies= when the rtcweb endpoint is an answerer since with

the above setting, you will n= ot provide an offer that the other side can accept, but

the spec says:

 

"When acting as answerer= , the browser will reject any m=3D section that does not provide an "a= =3Drtcp-mux" attribute."

 

The reason for that is to avo= id asymmetrical situations in which endpoint NM

(non-mux) makes an offer to e= ndpoint M (mux) which is accepted, but then

re-offers from NM to M fail.<= o:p>

 

So I believe the best version= of this proposal is simply requiring rtcp-mux

entirely.

 

-Ekr

 

 

The whole reason we didn't do t= his before was because we wanted to work with legacy equipment.  But C= ullen's claim is that there is no legacy equipment that can speak ICE (and DTLS) but not rtcp-mux. 

 

So is there any remaining reaso= n that we cannot require rtcp-mux?

 

 

 


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

 

--_000_SN1PR0301MB15518198D375F21B973C091DB28A0SN1PR0301MB1551_-- From nobody Fri Jul 31 06:45:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE191A8859 for ; Fri, 31 Jul 2015 06:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSzJOTaKd_O4 for ; Fri, 31 Jul 2015 06:45:25 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9821A8855 for ; Fri, 31 Jul 2015 06:45:25 -0700 (PDT) Received: by igr7 with SMTP id 7so16637503igr.0 for ; Fri, 31 Jul 2015 06:45:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TDcCbCEUs25LImtQ6jjYmLy313M+ly0C1XORpkvTd04=; b=MUZG7z/fLyazC33B3Yg9ApZskUcKhccGssUm5xZwZ/cG4ScCM/nog+g8FC3tfGdEnV 0/WyTF5XCXRYMtSl01wXFpCIeCGLSjoFSjygVAtitB65TaNUb687GkR0JDPYdy2dNGUE nqHRpSLQf5OjaxXrAQsw+mvyJIyleZOyvdDYMWVAiNBcCdzFwu8s3zBgq8VTWqnlTeR9 Dc8TE+mfhTBd1hVFwg7VHyv3Aw6oUdb4BayTG8UKr/5f8qH350N4rrnCBCGcyKd7HL4f vqrzWPtOth/iwU7LUVsYkT104vEZz/7VojYNPqbS7ntPSI4otV0Nm9JRDq0DDDiUnRm7 nrmQ== X-Gm-Message-State: ALoCoQloukQsc427zq1h99SZiKVMYFH26VhWC94Ed6ltVDo+4azl7BmCXjuXcUJ5z+VYOsXZjTi2 X-Received: by 10.50.59.242 with SMTP id c18mr6058984igr.66.1438350325275; Fri, 31 Jul 2015 06:45:25 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by smtp.gmail.com with ESMTPSA id m1sm2243432igv.8.2015.07.31.06.45.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 06:45:23 -0700 (PDT) Received: by igr7 with SMTP id 7so16636652igr.0 for ; Fri, 31 Jul 2015 06:45:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.88.6 with SMTP id bc6mr5637414igb.24.1438350322723; Fri, 31 Jul 2015 06:45:22 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Fri, 31 Jul 2015 06:45:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 31 Jul 2015 09:45:22 -0400 Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=089e0111c0a40c72c0051c2c0851 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 13:45:27 -0000 --089e0111c0a40c72c0051c2c0851 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 31, 2015 at 7:58 AM, Asveren, Tolga wrote: > It is not really about =E2=80=9Cwhat is technically better=E2=80=9D (and = event there, the > beauty is in the eye of the beholder depending on the deployment scenario= ) > but more wider interoperability. As long as there is a negotiation > mechanism/freedom to reject, I don=E2=80=99t see any harm of allowing not= to > mandate rtcp-mux. You still can mandate its use in a specific > implementation. > > > Is there a WebRTC gateway or some other device that you have in mind that supports DTLS-SRTP and does not support rtcp-mux? The whole point of this discussion is to remove the negotiation for rtcp-mux. If there are no devices that WebRTC endpoint can communicate with (which now means devices supporting required DTLS-SRTP) which do not support rtcp-mux, it would be better to reduce the code size by removing rtcp-mux negotiation and all the code related to collecting second set of candidates for RTCP connection, supporting second component per media stream, negotiating second DTLS-SRTP for RTCP connection, etc. This is a non-trivial amount of code, which is not being actively tested right now. Most of the open source webrtc gateways I looked at have it broken. Maintaining this code without a compelling use case is too much of the burden this is why I strongly suggest rtcp-mux must be supported. Regards, _____________ Roman Shpount --089e0111c0a40c72c0051c2c0851 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 31, 2015 at 7:5= 8 AM, Asveren, Tolga <tasveren@sonusnet.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

It is not really about =E2=80=9Cwhat = is technically better=E2=80=9D (and event there, the beauty is in the eye o= f the beholder depending on the deployment scenario) but more wider interoperability. As long as there is a negotiation mechanism/freedo= m to reject, I don=E2=80=99t see any harm of allowing not to mandate rtcp-m= ux. You still can mandate its use in a specific implementation.



Is there a WebRTC gateway or some other device that you have in mind that = supports DTLS-SRTP and does not support rtcp-mux?

= The whole point of this discussion is to remove the negotiation for rtcp-mu= x. If there are no devices that WebRTC endpoint can communicate with (which= now means devices supporting required DTLS-SRTP) which do not support rtcp= -mux, it would be better to reduce the code size by removing rtcp-mux negot= iation and all the code related to collecting second set of candidates for = RTCP connection, supporting second component per media stream, negotiating = second DTLS-SRTP for RTCP connection, etc. This is a non-trivial amount of = code, which is not being actively tested right now. Most of the open source= webrtc gateways I looked at have it broken. Maintaining this code without = a compelling use case is too much of the burden this is why I strongly sugg= est rtcp-mux must be supported.

Regards,
_____________
Roman Shpount
<= div>=C2=A0
--089e0111c0a40c72c0051c2c0851-- From nobody Fri Jul 31 06:53:15 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040431A886D for ; Fri, 31 Jul 2015 06:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GIDXbYi_YW0 for ; Fri, 31 Jul 2015 06:53:12 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0003C1A8869 for ; Fri, 31 Jul 2015 06:53:11 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so17215595igb.0 for ; Fri, 31 Jul 2015 06:53:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=poYjwgJ3nKXI1YTocnm+mZWewDaKM4QZllDredjP+EE=; b=KUbB3+LUSvvSrBbQprJhSOaj8VuYa1ocgciBHAebVRGNUN58yFDZ/ISRw4EouWmeSc 6jE+vrdniGPhcZo3PP54znoe9J7Jirq6xYViBo9FBZUwXjYqhL5mXh9EdIIiIT3Qt4C3 7anefKzlrT/h5CXtPmSs0cf8ZS9R5wMBu7lcXzDAXD0JxGj8DG5kAN9RL0+Hdqe4xmqZ IDAkblRDgos9PP844HKIDh67iTAJvM1bWkqj8aQ1ewk4c+1eGeU86bNHEbh4MFc54WKB kaGqoVT2ob81aouJ8KBvt1A9yZkuL7djG2f3CpROqgbwb2LHzXufWMj4Hw9g6cPjj98M 8xMA== X-Gm-Message-State: ALoCoQlbw4GwMWFMPS9XIQXHGMk89qVGZM5779XheT6lsW3OsnAMjh1o4Y+s8TfFEZr1sjbLRD2M X-Received: by 10.50.225.65 with SMTP id ri1mr5736439igc.47.1438350791475; Fri, 31 Jul 2015 06:53:11 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com. [209.85.213.178]) by smtp.gmail.com with ESMTPSA id p79sm3261523iop.15.2015.07.31.06.53.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 06:53:10 -0700 (PDT) Received: by igr7 with SMTP id 7so16781098igr.0 for ; Fri, 31 Jul 2015 06:53:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.138.193 with SMTP id qs1mr5781662igb.2.1438350789312; Fri, 31 Jul 2015 06:53:09 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Fri, 31 Jul 2015 06:53:09 -0700 (PDT) In-Reply-To: <20150731104712.GA5228@lo.psyced.org> References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> Date: Fri, 31 Jul 2015 09:53:09 -0400 Message-ID: From: Roman Shpount To: carlo von lynX Content-Type: multipart/alternative; boundary=089e0122a5b8dc0843051c2c23ab Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 13:53:14 -0000 --089e0122a5b8dc0843051c2c23ab Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 6:47 AM, carlo von lynX < lynX@i.know.you.are.psyced.org> wrote: > Alright, thanks Tim for digging deeper and confirming that > we have a serious problem here. Unfortunately everybody > else is talking of other things and giving the impression > we are having just a side discussion.. and the problem > remains: WebRTC threatens lives of dissidents. If we can't > publish news that rtcweb has fixed the problem then the > logical consequence is to publish that n months have passed > and rtcweb is still not willing to fix the issue.... which > can be interpreted as a political news all on its own - how > industry does not care about collateral damages. Certainly > we can't just keep quiet and let this become a working > strategy to ignore issues. > > So, dear folks, this is your chance to keep the next > shitstorm from coming your way. Do something! > > In IETF we typically discuss technical issues and not political PR. So, the other discussions that you so blatantly ignore are actually about the actual technical implications of webrtc on user privacy and possible ways to improve it. If you have a particular technical solution that you want propose then please do so. Screaming that industry needs to do something or else the puppy will die is not helpful. Regards, _____________ Roman Shpount --089e0122a5b8dc0843051c2c23ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 31, 2015 at 6:47 AM, carlo von lynX <lynX@i.know.yo= u.are.psyced.org> wrote:
Al= right, thanks Tim for digging deeper and confirming that
we have a serious problem here. Unfortunately everybody
else is talking of other things and giving the impression
we are having just a side discussion.. and the problem
remains: WebRTC threatens lives of dissidents. If we can't
publish news that rtcweb has fixed the problem then the
logical consequence is to publish that n months have passed
and rtcweb is still not willing to fix the issue.... which
can be interpreted as a political news all on its own - how
industry does not care about collateral damages. Certainly
we can't just keep quiet and let this become a working
strategy to ignore issues.

So, dear folks, this is your chance to keep the next
shitstorm from coming your way. Do something!


In IETF we typically discuss technical issu= es and not political PR. So, the other discussions that you so blatantly ig= nore are actually about the actual technical implications of webrtc on user= privacy and possible ways to improve it. If you have a particular technica= l solution that you want propose then please do so. Screaming that industry= needs to do something or else the puppy will die is not helpful.

Regards,
_____________
Roman Shpount=
=C2=A0
--089e0122a5b8dc0843051c2c23ab-- From nobody Fri Jul 31 06:57:03 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002C41A8865 for ; Fri, 31 Jul 2015 06:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kqBQonRelu4 for ; Fri, 31 Jul 2015 06:56:57 -0700 (PDT) Received: from mail2.kpnnet.org (mail2.kpnnet.org [192.58.226.66]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA241A886D for ; Fri, 31 Jul 2015 06:56:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,584,1432591200"; d="scan'208,217";a="2171711" Received: from w2006.kpnnl.local ([10.75.81.4]) by mail2.kpnnet.org with ESMTP; 31 Jul 2015 15:56:54 +0200 Received: from W2306.kpnnl.local (10.75.80.80) by W2006.kpnnl.local (10.75.81.4) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 31 Jul 2015 15:56:54 +0200 Received: from W3013.kpnnl.local (158.67.247.22) by W2306.kpnnl.local (10.75.80.80) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 31 Jul 2015 15:56:54 +0200 Received: from W3018.kpnnl.local ([fe80::901f:81cf:ea70:9e75]) by W3013.kpnnl.local ([169.254.3.88]) with mapi id 14.03.0235.001; Fri, 31 Jul 2015 15:56:53 +0200 From: To: Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyvx8tGyfD9kDSky8j5YMyGSqOZ30w60AgAB5cYCAAAlpAIAAVQKP Date: Fri, 31 Jul 2015 13:56:52 +0000 Message-ID: <4DE3D9E8-8B36-4EC3-A2D9-5A7C9BD01922@kpn.com> References: , , , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4DE3D9E88B364EC3A2D95A7C9BD01922kpncom_" MIME-Version: 1.0 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 13:57:00 -0000 --_000_4DE3D9E88B364EC3A2D95A7C9BD01922kpncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 M.vr.gr., Richard van Det 06 2054 7291 Op 31 jul. 2015 om 12:52 heeft Wyss, Felix > het volgende geschreven: As somebody who has to interoperate between WebRTC and legacy VoIP, I whole= heartedly support making RTP/RTCP muxing mandatory. Having just one "pipe"= for everything is IMHO an incredibly compelling feature of WebRTC. Furthe= rmore, the fewer RECOMMENDED vs. MUST we have in the specification, the mor= e likely the WebRTC endpoints from different vendors will be interoperable = without hacks or workarounds. --Felix ________________________________ From: rtcweb > on b= ehalf of Asveren, Tolga > Sent: Friday, July 31, 2015 06:18 To: Eric Rescorla; Peter Thatcher Cc: > Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it= would be Christmas in July!) "The whole reason we didn't do this before was because we wanted to work wi= th legacy equipment. But Cullen's claim is that there is no legacy equipme= nt that can speak ICE (and DTLS) but not rtcp-mux." I am not sure whether this is entirely true, especially on GW front. It cou= ld be a better idea to be lenient for enhanced interoperability and making = RTCWeb more deployable in practice. Can't the decision of being firm on usi= ng rtcp-mux left to the WebRTC endpoint with signaling aspects supporting n= egotiation of the capability? Thanks, Tolga ________________________________ From: rtcweb > on b= ehalf of Eric Rescorla > Sent: Thursday, July 30, 2015 11:04 PM To: Peter Thatcher Cc: > Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it= would be Christmas in July!) On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher > wrote: At IETF 93 last week, Cullen pointed out that he looked into ICE endpoints= and found that all of them support rtcp-mux. Inspired by that, I went aro= und and asked about a dozen people "would you be OK if we removed support f= or non-muxed RTCP?" The range of responses went from "I'm OK with it if Cu= llen is" to "yeah, that would be great". No one said no. Cullen said yes. For me, removing support for non-muxed RTCP would be like Christmas in July= . Realistically, August at this point. So here's my proposal: make RtcpMuxPolicy =3D=3D "required" be not only th= e default, but the only RtcpMuxPolicy available. All rtcweb endpoints mus= t support rtcp-mux. This seems reasonable. An rtcweb endpoint would be free to fail if the remote endpoint does not su= pport rtcp-mux. Given the current specification, I believe this would need to be strong. I.= e., an rtcweb endpoint *must* fail if the remote endpoint does not support rtcp-mux. As s= hould be obvious, this only applies when the rtcweb endpoint is an answerer since= with the above setting, you will not provide an offer that the other side can ac= cept, but the spec says: "When acting as answerer, the browser will reject any m=3D section that doe= s not provide an "a=3Drtcp-mux" attribute." The reason for that is to avoid asymmetrical situations in which endpoint N= M (non-mux) makes an offer to endpoint M (mux) which is accepted, but then re-offers from NM to M fail. So I believe the best version of this proposal is simply requiring rtcp-mux entirely. -Ekr The whole reason we didn't do this before was because we wanted to work wit= h legacy equipment. But Cullen's claim is that there is no legacy equipmen= t that can speak ICE (and DTLS) but not rtcp-mux. So is there any remaining reason that we cannot require rtcp-mux? _______________________________________________ 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 --_000_4DE3D9E88B364EC3A2D95A7C9BD01922kpncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1

M.vr.gr.,

Richard van Det
06 2054 7291

Op 31 jul. 2015 om 12:52 heeft Wyss, Felix <Felix.Wyss@inin.com> het volgende geschreven:

As somebody who has to interoperate between WebRTC and legacy VoIP, I wh= oleheartedly support making RTP/RTCP muxing mandatory.  Having just on= e "pipe" for everything is IMHO an incredibly compelling feature = of WebRTC.  Furthermore, the fewer RECOMMENDED vs. MUST we have in the specification, the more likely the WebRTC endpoint= s from different vendors will be interoperable without hacks or workarounds= .  


--Felix

From: rtcweb <rtcweb-bounces@ietf.org> on beha= lf of Asveren, Tolga <tasveren@= sonusnet.com>
Sent: Friday, July 31, 2015 06:18
To: Eric Rescorla; Peter Thatcher
Cc: <rtcweb@ietf.org> Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed R= TCP; it would be Christmas in July!)
 

"The whole reason we didn't do this before was bec= ause we wanted to work with legacy equipment.  But Cullen's claim is t= hat there is no legacy equipment that can speak ICE (and DTLS) but not rtcp-mux."


I am not sure whether this is entirely true, especiall= y on GW front. It could be a better idea to be lenient for enhanced interop= erability and making RTCWeb more deployable in practice. Can't the decision of being firm on using rtcp-mux left to th= e WebRTC endpoint with signaling aspects supporting negotiation of the capa= bility?


Thanks,

Tolga



From: rtcweb <rtcweb-bounces@ietf.org> on beha= lf of Eric Rescorla <ekr@rtfm.com>= ;
Sent: Thursday, July 30, 2015 11:04 PM
To: Peter Thatcher
Cc: <rtcweb@ietf.org> Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed R= TCP; it would be Christmas in July!)
 


On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher = <pthatcher@goo= gle.com> wrote:
At IETF 93 last week,=  Cullen pointed out that he looked into ICE endpoints and found that = all of them support rtcp-mux.  Inspired by that, I went around and ask= ed about a dozen people "would you be OK if we removed support for non-muxed RTCP?"  The range of responses = went from "I'm OK with it if Cullen is" to "yeah, that would= be great".  No one said no.  Cullen said yes.  

For me, removing supp= ort for non-muxed RTCP would be like Christmas in July.

Realistically, August at this point.


So here's my proposal= :  make RtcpMuxPolicy =3D=3D "required" be not only the defa= ult, but the only RtcpMuxPolicy available.   All rtcweb endpoints must= support rtcp-mux.  

This seems reasonable.

 
An rtcweb endpoint wo= uld be free to fail if the remote endpoint does not support rtcp-mux.

Given the current specification, I believe this would need to be stron= g. I.e., an rtcweb
endpoint *must* fail if the remote endpoint does not support rtcp-mux.= As should 
be obvious, this only applies when the rtcweb endpoint is an answerer = since with
the above setting, you will not provide an offer that the other side c= an accept, but
the spec says:

"When acting as answerer, the browser will reject any m=3D sectio= n that does not provide an "a=3Drtcp-mux" attribute."

The reason for that is to avoid asymmetrical situations in which endpo= int NM
(non-mux) makes an offer to endpoint M (mux) which is accepted, but th= en
re-offers from NM to M fail.

So I believe the best version of this proposal is simply requiring rtc= p-mux
entirely.

-Ekr

 
The whole reason we d= idn't do this before was because we wanted to work with legacy equipment.&n= bsp; But Cullen's claim is that there is no legacy equipment that can speak= ICE (and DTLS) but not rtcp-mux. 

So is there any remai= ning reason that we cannot require rtcp-mux?




_______________________________________________
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
--_000_4DE3D9E88B364EC3A2D95A7C9BD01922kpncom_-- From nobody Fri Jul 31 07:12:34 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776501A88A5 for ; Fri, 31 Jul 2015 07:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPPba7XfwM5k for ; Fri, 31 Jul 2015 07:12:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0634.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D13C1A8865 for ; Fri, 31 Jul 2015 07:12:29 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 31 Jul 2015 14:12:14 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Fri, 31 Jul 2015 14:12:14 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyz2WarP6bihqdUKrjE+AJblPlJ31XJYcgAAK9gCAABGjIIAAHqAAgAAFXiA= Date: Fri, 31 Jul 2015 14:12:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: telurix.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:ZFYLnQFF1dvwuYeKulMG5gH/uhz5+NT1vtLYOFvBIeQQ4JGvoV06FGx1TJoK9NCZP+cR7Zqy3y8PgCkzGvvAHcvbS/Tc9FdP6F9UdaKdn7X7qPQ7PQALuF+WLDtcQEQdZL9DMdRdk0zLbjq/Hd7+VQ==; 24:bLDtpEpO72xQBGdj6DT2HWAJbD/ex1SIjOMAdLbns8nC55npqmSJY7caOFoyuCg8jhfK1vHWtap6b7PsTfwfWYzT/4Q1aUJn6lqJhdhUt2Y=; 20:RSzDO8p61aE0cQAN9c1nYS4Uw5Ar0qZYqBZ2zVH2fvlO36ynmVtXkcSWY7XGhMfDCx0984J9Csor8JrhD+t9Pw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; sn1pr0301mb1551: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(164054003)(24454002)(5001960100002)(561944003)(19580395003)(46102003)(33656002)(122556002)(77156002)(5003600100002)(19609705001)(19300405004)(189998001)(16236675004)(19625215002)(19580405001)(110136002)(2656002)(74316001)(87936001)(86362001)(2900100001)(76576001)(66066001)(5002640100001)(93886004)(76176999)(15975445007)(54356999)(2950100001)(99286002)(50986999)(102836002)(92566002)(62966003)(40100003)(106116001)(77096005)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551CBD951E5BA9CA60B6C6AB28A0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 14:12:13.3748 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 14:12:32 -0000 --_000_SN1PR0301MB1551CBD951E5BA9CA60B6C6AB28A0SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgZm9sbG93aW5nIHRoZSBsb2dpYyB5b3UgcHJlc2VudGVkLCBsb3RzIG9mIG90aGVyIG9wdGlv bmFsL25lZ290aWFibGUgcHJvY2VkdXJlcy9mdW5jdGlvbmFsaXR5IGZvciBldmVyeSBwcm90b2Nv bCwgaW5jbHVkaW5nIFJUQ1dlYiwgY291bGQgYmUgbGVmdCBvdXQgYnkgZGVjbGFyaW5nIHRoYXQg dGhlcmUgaXMgb25seSBhIHNpbmdsZSB3YXkgb2YgZG9pbmcgdGhpbmdzLiBUaGF0IGNlcnRhaW5s eSB3b3VsZCBtYWtlIGltcGxlbWVudGF0aW9uIGVhc2llciBidXQgbm90IG5lY2Vzc2FyaWx5IGF0 dHJhY3RpdmUgdG8gY2F0ZXIgZGlmZmVyZW50IGRlcGxveW1lbnQgbW9kZWxzL3Byb2R1Y3QgY2F0 ZWdvcmllcy4NCg0KT25lIGNhbiBjb2RlIHNvIHRoYXQgdGhlIHByb2R1Y3Qgc3VwcG9ydHMgb25s eSBydGNwLW11eCB3aXRob3V0IGFsbCB0aGUgY29tcGxleGl0aWVzIHlvdSBtZW50aW9uZWQgYmVs b3cuIFRoaXMganVzdCB3b3VsZCBtZWFuIHRoYXQgc3VjaCBhIHByb2R1Y3Qgd291bGRu4oCZdCBp bnRlcm9wZXJhdGUgd2l0aCBlbGVtZW50cyBub3Qgc3VwcG9ydGluZyBydGNwLW11eCAoYW5kIHRo YXQgc2hvdWxkbuKAmXQgYmUgYSBwcm9ibGVtIGFzIGxvbmcgYXMgdGhlIHByb2R1Y3Qgb3duZXIg dGhpbmtzIHRoYXQgdGhlcmUgYXJlIG5vIGVsZW1lbnRzIHN1cHBvcnRpbmcgRFRMUy1TUlRQIGJ1 dCBub3QgcnRjcC1tdXggb3IgZG9lcyBub3QgY2FyIGFib3V0IGludGVyb3BlcmF0aW5nIHdpdGgg c3VjaCBkZXZpY2VzKS4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogUm9tYW4gU2hwb3VudCBb bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogRnJpZGF5LCBKdWx5IDMxLCAyMDE1IDk6 NDUgQU0NClRvOiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0KQ2M6IFd5 c3MsIEZlbGl4IDxGZWxpeC5XeXNzQGluaW4uY29tPjsgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0u Y29tPjsgUGV0ZXIgVGhhdGNoZXIgPHB0aGF0Y2hlckBnb29nbGUuY29tPjsgPHJ0Y3dlYkBpZXRm Lm9yZz4gPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBQcm9wb3NhbDog cmVxdWlyZSBydGNwLW11eCAocmVtb3ZlIG5vbi1tdXhlZCBSVENQOyBpdCB3b3VsZCBiZSBDaHJp c3RtYXMgaW4gSnVseSEpDQoNCg0KT24gRnJpLCBKdWwgMzEsIDIwMTUgYXQgNzo1OCBBTSwgQXN2 ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNu ZXQuY29tPj4gd3JvdGU6DQpJdCBpcyBub3QgcmVhbGx5IGFib3V0IOKAnHdoYXQgaXMgdGVjaG5p Y2FsbHkgYmV0dGVy4oCdIChhbmQgZXZlbnQgdGhlcmUsIHRoZSBiZWF1dHkgaXMgaW4gdGhlIGV5 ZSBvZiB0aGUgYmVob2xkZXIgZGVwZW5kaW5nIG9uIHRoZSBkZXBsb3ltZW50IHNjZW5hcmlvKSBi dXQgbW9yZSB3aWRlciBpbnRlcm9wZXJhYmlsaXR5LiBBcyBsb25nIGFzIHRoZXJlIGlzIGEgbmVn b3RpYXRpb24gbWVjaGFuaXNtL2ZyZWVkb20gdG8gcmVqZWN0LCBJIGRvbuKAmXQgc2VlIGFueSBo YXJtIG9mIGFsbG93aW5nIG5vdCB0byBtYW5kYXRlIHJ0Y3AtbXV4LiBZb3Ugc3RpbGwgY2FuIG1h bmRhdGUgaXRzIHVzZSBpbiBhIHNwZWNpZmljIGltcGxlbWVudGF0aW9uLg0KDQoNCklzIHRoZXJl IGEgV2ViUlRDIGdhdGV3YXkgb3Igc29tZSBvdGhlciBkZXZpY2UgdGhhdCB5b3UgaGF2ZSBpbiBt aW5kIHRoYXQgc3VwcG9ydHMgRFRMUy1TUlRQIGFuZCBkb2VzIG5vdCBzdXBwb3J0IHJ0Y3AtbXV4 Pw0KDQpUaGUgd2hvbGUgcG9pbnQgb2YgdGhpcyBkaXNjdXNzaW9uIGlzIHRvIHJlbW92ZSB0aGUg bmVnb3RpYXRpb24gZm9yIHJ0Y3AtbXV4LiBJZiB0aGVyZSBhcmUgbm8gZGV2aWNlcyB0aGF0IFdl YlJUQyBlbmRwb2ludCBjYW4gY29tbXVuaWNhdGUgd2l0aCAod2hpY2ggbm93IG1lYW5zIGRldmlj ZXMgc3VwcG9ydGluZyByZXF1aXJlZCBEVExTLVNSVFApIHdoaWNoIGRvIG5vdCBzdXBwb3J0IHJ0 Y3AtbXV4LCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gcmVkdWNlIHRoZSBjb2RlIHNpemUgYnkgcmVt b3ZpbmcgcnRjcC1tdXggbmVnb3RpYXRpb24gYW5kIGFsbCB0aGUgY29kZSByZWxhdGVkIHRvIGNv bGxlY3Rpbmcgc2Vjb25kIHNldCBvZiBjYW5kaWRhdGVzIGZvciBSVENQIGNvbm5lY3Rpb24sIHN1 cHBvcnRpbmcgc2Vjb25kIGNvbXBvbmVudCBwZXIgbWVkaWEgc3RyZWFtLCBuZWdvdGlhdGluZyBz ZWNvbmQgRFRMUy1TUlRQIGZvciBSVENQIGNvbm5lY3Rpb24sIGV0Yy4gVGhpcyBpcyBhIG5vbi10 cml2aWFsIGFtb3VudCBvZiBjb2RlLCB3aGljaCBpcyBub3QgYmVpbmcgYWN0aXZlbHkgdGVzdGVk IHJpZ2h0IG5vdy4gTW9zdCBvZiB0aGUgb3BlbiBzb3VyY2Ugd2VicnRjIGdhdGV3YXlzIEkgbG9v a2VkIGF0IGhhdmUgaXQgYnJva2VuLiBNYWludGFpbmluZyB0aGlzIGNvZGUgd2l0aG91dCBhIGNv bXBlbGxpbmcgdXNlIGNhc2UgaXMgdG9vIG11Y2ggb2YgdGhlIGJ1cmRlbiB0aGlzIGlzIHdoeSBJ IHN0cm9uZ2x5IHN1Z2dlc3QgcnRjcC1tdXggbXVzdCBiZSBzdXBwb3J0ZWQuDQoNClJlZ2FyZHMs DQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_SN1PR0301MB1551CBD951E5BA9CA60B6C6AB28A0SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIGZvbGxvd2luZyB0aGUgbG9naWMgeW91 IHByZXNlbnRlZCwgbG90cyBvZiBvdGhlciBvcHRpb25hbC9uZWdvdGlhYmxlIHByb2NlZHVyZXMv ZnVuY3Rpb25hbGl0eSBmb3IgZXZlcnkgcHJvdG9jb2wsIGluY2x1ZGluZyBSVENXZWIsIGNvdWxk IGJlIGxlZnQgb3V0IGJ5IGRlY2xhcmluZw0KIHRoYXQgdGhlcmUgaXMgb25seSBhIHNpbmdsZSB3 YXkgb2YgZG9pbmcgdGhpbmdzLiBUaGF0IGNlcnRhaW5seSB3b3VsZCBtYWtlIGltcGxlbWVudGF0 aW9uIGVhc2llciBidXQgbm90IG5lY2Vzc2FyaWx5IGF0dHJhY3RpdmUgdG8gY2F0ZXIgZGlmZmVy ZW50IGRlcGxveW1lbnQgbW9kZWxzL3Byb2R1Y3QgY2F0ZWdvcmllcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9uZSBjYW4gY29kZSBzbyB0aGF0IHRoZSBwcm9k dWN0IHN1cHBvcnRzIG9ubHkgcnRjcC1tdXggd2l0aG91dCBhbGwgdGhlIGNvbXBsZXhpdGllcyB5 b3UgbWVudGlvbmVkIGJlbG93LiBUaGlzIGp1c3Qgd291bGQgbWVhbiB0aGF0IHN1Y2ggYSBwcm9k dWN0IHdvdWxkbuKAmXQgaW50ZXJvcGVyYXRlDQogd2l0aCBlbGVtZW50cyBub3Qgc3VwcG9ydGlu ZyBydGNwLW11eCAoYW5kIHRoYXQgc2hvdWxkbuKAmXQgYmUgYSBwcm9ibGVtIGFzIGxvbmcgYXMg dGhlIHByb2R1Y3Qgb3duZXIgdGhpbmtzIHRoYXQgdGhlcmUgYXJlIG5vIGVsZW1lbnRzIHN1cHBv cnRpbmcgRFRMUy1TUlRQIGJ1dCBub3QgcnRjcC1tdXggb3IgZG9lcyBub3QgY2FyIGFib3V0IGlu dGVyb3BlcmF0aW5nIHdpdGggc3VjaCBkZXZpY2VzKS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ub2xnYTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMzEsIDIwMTUgOTo0NSBBTTxicj4NCjxiPlRvOjwvYj4g QXN2ZXJlbiwgVG9sZ2EgJmx0O3Rhc3ZlcmVuQHNvbnVzbmV0LmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IFd5c3MsIEZlbGl4ICZsdDtGZWxpeC5XeXNzQGluaW4uY29tJmd0OzsgRXJpYyBSZXNjb3Js YSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0OzsgUGV0ZXIgVGhhdGNoZXIgJmx0O3B0aGF0Y2hlckBnb29n bGUuY29tJmd0OzsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFByb3Bvc2FsOiByZXF1aXJlIHJ0 Y3AtbXV4IChyZW1vdmUgbm9uLW11eGVkIFJUQ1A7IGl0IHdvdWxkIGJlIENocmlzdG1hcyBpbiBK dWx5ISk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVsIDMxLCAyMDE1IGF0 IDc6NTggQU0sIEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29u dXNuZXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdCBpcyBub3Qg cmVhbGx5IGFib3V0IOKAnHdoYXQgaXMgdGVjaG5pY2FsbHkgYmV0dGVy4oCdIChhbmQgZXZlbnQg dGhlcmUsIHRoZSBiZWF1dHkgaXMgaW4gdGhlIGV5ZSBvZiB0aGUNCiBiZWhvbGRlciBkZXBlbmRp bmcgb24gdGhlIGRlcGxveW1lbnQgc2NlbmFyaW8pIGJ1dCBtb3JlIHdpZGVyIGludGVyb3BlcmFi aWxpdHkuIEFzIGxvbmcgYXMgdGhlcmUgaXMgYSBuZWdvdGlhdGlvbiBtZWNoYW5pc20vZnJlZWRv bSB0byByZWplY3QsIEkgZG9u4oCZdCBzZWUgYW55IGhhcm0gb2YgYWxsb3dpbmcgbm90IHRvIG1h bmRhdGUgcnRjcC1tdXguIFlvdSBzdGlsbCBjYW4gbWFuZGF0ZSBpdHMgdXNlIGluIGEgc3BlY2lm aWMgaW1wbGVtZW50YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0aGVyZSBhIFdlYlJUQyBnYXRl d2F5IG9yIHNvbWUgb3RoZXIgZGV2aWNlIHRoYXQgeW91IGhhdmUgaW4gbWluZCB0aGF0IHN1cHBv cnRzIERUTFMtU1JUUCBhbmQgZG9lcyBub3Qgc3VwcG9ydCBydGNwLW11eD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHdob2xlIHBvaW50 IG9mIHRoaXMgZGlzY3Vzc2lvbiBpcyB0byByZW1vdmUgdGhlIG5lZ290aWF0aW9uIGZvciBydGNw LW11eC4gSWYgdGhlcmUgYXJlIG5vIGRldmljZXMgdGhhdCBXZWJSVEMgZW5kcG9pbnQgY2FuIGNv bW11bmljYXRlIHdpdGggKHdoaWNoIG5vdyBtZWFucyBkZXZpY2VzIHN1cHBvcnRpbmcgcmVxdWly ZWQgRFRMUy1TUlRQKSB3aGljaCBkbyBub3Qgc3VwcG9ydCBydGNwLW11eCwgaXQgd291bGQNCiBi ZSBiZXR0ZXIgdG8gcmVkdWNlIHRoZSBjb2RlIHNpemUgYnkgcmVtb3ZpbmcgcnRjcC1tdXggbmVn b3RpYXRpb24gYW5kIGFsbCB0aGUgY29kZSByZWxhdGVkIHRvIGNvbGxlY3Rpbmcgc2Vjb25kIHNl dCBvZiBjYW5kaWRhdGVzIGZvciBSVENQIGNvbm5lY3Rpb24sIHN1cHBvcnRpbmcgc2Vjb25kIGNv bXBvbmVudCBwZXIgbWVkaWEgc3RyZWFtLCBuZWdvdGlhdGluZyBzZWNvbmQgRFRMUy1TUlRQIGZv ciBSVENQIGNvbm5lY3Rpb24sIGV0Yy4gVGhpcw0KIGlzIGEgbm9uLXRyaXZpYWwgYW1vdW50IG9m IGNvZGUsIHdoaWNoIGlzIG5vdCBiZWluZyBhY3RpdmVseSB0ZXN0ZWQgcmlnaHQgbm93LiBNb3N0 IG9mIHRoZSBvcGVuIHNvdXJjZSB3ZWJydGMgZ2F0ZXdheXMgSSBsb29rZWQgYXQgaGF2ZSBpdCBi cm9rZW4uIE1haW50YWluaW5nIHRoaXMgY29kZSB3aXRob3V0IGEgY29tcGVsbGluZyB1c2UgY2Fz ZSBpcyB0b28gbXVjaCBvZiB0aGUgYnVyZGVuIHRoaXMgaXMgd2h5IEkgc3Ryb25nbHkgc3VnZ2Vz dA0KIHJ0Y3AtbXV4IG11c3QgYmUgc3VwcG9ydGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+ DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB1551CBD951E5BA9CA60B6C6AB28A0SN1PR0301MB1551_-- From nobody Fri Jul 31 09:20:09 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2261B2D68 for ; Fri, 31 Jul 2015 09:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrtiC32mC-rO for ; Fri, 31 Jul 2015 09:20:06 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0D11A87D9 for ; Fri, 31 Jul 2015 09:20:06 -0700 (PDT) Received: by pacan13 with SMTP id an13so44033518pac.1 for ; Fri, 31 Jul 2015 09:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u0my2zZBuWw5Hq0xGBPGflCeknF7m0U12jc4zuXBsro=; b=YWMQazlJ6fkzUCgrurVOWwQUyraI53yW2KcbOmBAqafZJTnRjHIK44DecTZ31MP4dQ lmW+RSrO6yXhTi4HEqA8sq2DoZKGbf0uPoqL2c+5qktMNYXq+TnxNbKsyqYtvE+jgDBL SToJEm8j/Z320WFzsdbTjXHjnbgTU4sZ4rnpYwhSOK8o9V8DftYldXyEQaff+lXnWuPY z1LyOV+v7beK7yf+l/xXxYK4pOc1IhYiMKNrLyjbFAbTkYs3t/E7Vnyn9N1DGji5/jnH 3R7/yfUpcmS+iDhS4FAlqyUVjiku9uHzaVY4UihauDmT65gJ+mScXoLip+Sd1ogpeVA0 1UmA== X-Received: by 10.66.141.74 with SMTP id rm10mr8453928pab.96.1438359606039; Fri, 31 Jul 2015 09:20:06 -0700 (PDT) Received: from [192.168.1.110] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id oi17sm8486006pdb.74.2015.07.31.09.20.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jul 2015 09:20:04 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3DF1E498-1073-4844-B51A-0D86D84BA395 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12H143) In-Reply-To: Date: Fri, 31 Jul 2015 09:20:03 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Roman Shpount Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 16:20:08 -0000 --Apple-Mail-3DF1E498-1073-4844-B51A-0D86D84BA395 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Jul 31, 2015, at 06:45, Roman Shpount wrote: >=20 > The whole point of this discussion is to remove the negotiation for rtcp-m= ux. [BA] I support removing the mandate for RTP/RTCP non-mux but do not support r= emoving the ability to negotiate it. If an implementation supports it, why= shouldn't it be possible to negotiate its use? > It would be better to reduce the code size by removing rtcp-mux negotiatio= n and all the code related to collecting second set of candidates for RTCP c= onnection, supporting second component per media stream, negotiating second D= TLS-SRTP for RTCP connection, etc.This is a non-trivial amount of code, whic= h is not being actively tested right now. Most of the open source webrtc gat= eways I looked at have it broken. [BA] I agree that removing this code is attractive, particularly given the t= ricky issues that arise in supporting non-mux properly.=20= --Apple-Mail-3DF1E498-1073-4844-B51A-0D86D84BA395 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jul 31, 2015, at 06:45, Roman Shpou= nt <roman@telurix.com> wrote:=
=

The whole point of this discu= ssion is to remove the negotiation for rtcp-mux.

[BA] I support removing the mandate for RTP/RTC= P non-mux but do not support removing the ability to negotiate it.  If a= n implementation supports it,  why shouldn't it be possible to negotiat= e its use?

It would be better t= o reduce the code size by removing rtcp-mux negotiation and all the code rel= ated to collecting second set of candidates for RTCP connection, supporting s= econd component per media stream, negotiating second DTLS-SRTP for RTCP conn= ection, etc.This is a non-trivial amount of code, which is not being a= ctively tested right now. Most of the open source webrtc gateways I looked a= t have it broken.
[BA] I agree that removing this code is attractive, particularly= given the tricky issues that arise in supporting non-mux properly. = --Apple-Mail-3DF1E498-1073-4844-B51A-0D86D84BA395-- From nobody Fri Jul 31 09:45:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B0E1B2E61 for ; Fri, 31 Jul 2015 09:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odOA8wfKfv8o for ; Fri, 31 Jul 2015 09:45:23 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2F31B2E5D for ; Fri, 31 Jul 2015 09:45:17 -0700 (PDT) Received: by vkci6 with SMTP id i6so23409913vkc.3 for ; Fri, 31 Jul 2015 09:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aJtZULWw2Ol6RMQ6doptAHzV2N0uxsyblkC8oGwISOo=; b=GPTY/EUE8wQAAwg1ZQVa4xm/WFx9SlwYaWmOVpm4Y2J3Lz97sGc/ycH0jvL54pN+BB rQO1e6y7J9rI/dyXZFXDqTHdkGS0b76y2tcfEkOIxqYUuW5T+fRun+zfc7uUNSVewGA6 imuUG9R+lTNvKyYdkdtDSoO2a7Vx++9A+GirAce1J3hexiJCWFJ6JOt9YKbGM91L6uds HX9QzUG8/PYtRINxemQEpNyu8FoAAvXV2iCoQY561LlDhNyh4HYLLag01lu/ph869/nd jHjdq7JSQbVxKf0QUBbhtUDsiYDtkHDIqFtfLkJkKNkSvN4Nt9T+P5YC6RJBVElLnYWa VNZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aJtZULWw2Ol6RMQ6doptAHzV2N0uxsyblkC8oGwISOo=; b=gvGQf7Pm2aM8P3PCQU9Ka9e7w8uqKqpnI7nys/AtYeTLg9/7tZaXi5qSB2CrgzeBJx D531hGEuGWZwqiY3i4T3ee4H6CKmQYAh26v3qFDAK8CDVjDREf48VHlhJ5l9oVFFRBMD rHDzAEeMMZRO/XNM+aDb5i3y8RzAkGzOvYl48tbTYy8HK4YSp411DI+5cK72IPKSLaxm 1i12ohu3Fm5tqBuIcasmIAULbehmaW5oGJLO49B7ZHFUuO4wKsJMbACRo/9gwrTYRNBF ehuRAUmAIFKgVzQVR26+uLb7rdS75c8hbwCql8F6S6lPrdhw35pGqCyUIp2R5IAfErSs L+vw== X-Gm-Message-State: ALoCoQkjiYFlEc/T8zKsL6DsI0cbv6EFsIuXK2CsrOvB4sV0BIGbrSWyVjnTDO1+s9d46hkCXZGe X-Received: by 10.52.186.10 with SMTP id fg10mr5681341vdc.84.1438361116349; Fri, 31 Jul 2015 09:45:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.61.68 with HTTP; Fri, 31 Jul 2015 09:44:56 -0700 (PDT) In-Reply-To: References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> From: Justin Uberti Date: Fri, 31 Jul 2015 09:44:56 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=bcaec54864ba665d5e051c2e8bd4 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 16:45:24 -0000 --bcaec54864ba665d5e051c2e8bd4 Content-Type: text/plain; charset=UTF-8 On the Chrome side, we have taken the concrete step of allowing this functionality to be controlled via a Chrome extension: https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia/reviews?hl=en We are still sorting out some issues, which is why it is currently opt-in (i.e., an extension). However, we expect to have a more comprehensive solution in the near future. On Fri, Jul 31, 2015 at 6:53 AM, Roman Shpount wrote: > On Fri, Jul 31, 2015 at 6:47 AM, carlo von lynX < > lynX@i.know.you.are.psyced.org> wrote: > >> Alright, thanks Tim for digging deeper and confirming that >> we have a serious problem here. Unfortunately everybody >> else is talking of other things and giving the impression >> we are having just a side discussion.. and the problem >> remains: WebRTC threatens lives of dissidents. If we can't >> publish news that rtcweb has fixed the problem then the >> logical consequence is to publish that n months have passed >> and rtcweb is still not willing to fix the issue.... which >> can be interpreted as a political news all on its own - how >> industry does not care about collateral damages. Certainly >> we can't just keep quiet and let this become a working >> strategy to ignore issues. >> >> So, dear folks, this is your chance to keep the next >> shitstorm from coming your way. Do something! >> >> > In IETF we typically discuss technical issues and not political PR. So, > the other discussions that you so blatantly ignore are actually about the > actual technical implications of webrtc on user privacy and possible ways > to improve it. If you have a particular technical solution that you want > propose then please do so. Screaming that industry needs to do something or > else the puppy will die is not helpful. > > Regards, > _____________ > Roman Shpount > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec54864ba665d5e051c2e8bd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On the Chrome side, we have taken the concrete step of all= owing this functionality to be controlled via a Chrome extension:

We are still sorting out some is= sues, which is why it is currently opt-in (i.e., an extension). However, we= expect to have a more comprehensive solution in the near future.

On Fri, Jul 31,= 2015 at 6:53 AM, Roman Shpount <roman@telurix.com> wrote:
On Fri, Jul 31, 2015 at 6:47 = AM, carlo von lynX <lynX@i.know.you.are.psyced.org> wrote:
Alright, thanks Tim for diggi= ng deeper and confirming that
we have a serious problem here. Unfortunately everybody
else is talking of other things and giving the impression
we are having just a side discussion.. and the problem
remains: WebRTC threatens lives of dissidents. If we can't
publish news that rtcweb has fixed the problem then the
logical consequence is to publish that n months have passed
and rtcweb is still not willing to fix the issue.... which
can be interpreted as a political news all on its own - how
industry does not care about collateral damages. Certainly
we can't just keep quiet and let this become a working
strategy to ignore issues.

So, dear folks, this is your chance to keep the next
shitstorm from coming your way. Do something!


In IETF we typically discuss technic= al issues and not political PR. So, the other discussions that you so blata= ntly ignore are actually about the actual technical implications of webrtc = on user privacy and possible ways to improve it. If you have a particular t= echnical solution that you want propose then please do so. Screaming that i= ndustry needs to do something or else the puppy will die is not helpful.

Regards,
_____________
Roman Shpount
=C2=A0

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--bcaec54864ba665d5e051c2e8bd4-- From nobody Fri Jul 31 09:51:44 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6788D1A90EC for ; Fri, 31 Jul 2015 09:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E7mzkNEYpvZ for ; Fri, 31 Jul 2015 09:51:37 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6431A90E7 for ; Fri, 31 Jul 2015 09:51:37 -0700 (PDT) Received: by vkhg129 with SMTP id g129so23094914vkh.2 for ; Fri, 31 Jul 2015 09:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xImoIuLdp6LbVaB8sMkbGuJvGx1GOX3RUM4VsBkkfaQ=; b=g+4CSfqFtk51rA7hgdRtw1g41rGhbsdAl8GFGEVBpKZzRXacCxEe7zSQP+mb8HAs0j EgTrGrcjVIhLA5GvXXW47XSih2lyK++UUUANcQAeDmPqHLwnjJe0DyIIPn6/T4bZNNnZ 3gI//YaRn6EtGoBh3wSGYYCUs1FQtv5ZQmMv9ql3tgnSRb3HSmEMoFWhuJVYsCNHuDRD i1jdFwdW0/3zHCQGl8TCTzpMu5LseioQcr/ZHhqi/M/05qIJx0XFVItDPgPMdyJz5uIT k5f65YAMr9SSJgTcvlykiPrkeAJqfCjtxBTQLka5iE7Dx+W4gxpe2/cb/8B0omEqUrOf 2N8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xImoIuLdp6LbVaB8sMkbGuJvGx1GOX3RUM4VsBkkfaQ=; b=jCMlcf4VJJ9WzIz+tzh16TDHF6+rLgokaV0UdG4UwGy2JAF8S2sacGKmo2RU08YLHA eaqIBGmoBPFAB2oJPdIhDEJJyait/Bdq3yip4PkUheZMvCNjsQ7kN9Vbsvl8htiJgNMQ Y0NqrMYeeBfpJb9TlkjMszSqBYlZbw60DjaboebFWr1soCFIKuN87OhuJ3vIeLKYMfWi YNLkKJeE0pzsdZyqACZg+1sHGmVZ7LotWarFZq9Vq3uwn63eAvLFuxctiABaMjTfuHeu VM/yU2NRZjMdvgc7jZKQA9n2SmRmDJLVfCW61Kr7G1GByfUBKQoMF8cuLnvS6Lz1qweo IDLg== X-Gm-Message-State: ALoCoQmSykd94YVWTXr4njM7KyWANpX94nDAavLXIF+7M1q/h5jcTtoq8FvuJ4998IPdZ8velUu0 X-Received: by 10.52.92.110 with SMTP id cl14mr5435379vdb.35.1438361496450; Fri, 31 Jul 2015 09:51:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.61.68 with HTTP; Fri, 31 Jul 2015 09:51:16 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Fri, 31 Jul 2015 09:51:16 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=20cf3071cc8c0e2d84051c2ea2c3 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 16:51:43 -0000 --20cf3071cc8c0e2d84051c2ea2c3 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 9:20 AM, Bernard Aboba wrote: > On Jul 31, 2015, at 06:45, Roman Shpount wrote: > > > The whole point of this discussion is to remove the negotiation for > rtcp-mux. > > > [BA] I support removing the mandate for RTP/RTCP non-mux but do not > support removing the ability to negotiate it. If an implementation > supports it, why shouldn't it be possible to negotiate its use? > Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP, but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? That would work for us. > > It would be better to reduce the code size by removing rtcp-mux > negotiation and all the code related to collecting second set of candidates > for RTCP connection, supporting second component per media stream, > negotiating second DTLS-SRTP for RTCP connection, etc.This is a > non-trivial amount of code, which is not being actively tested right now. > Most of the open source webrtc gateways I looked at have it broken. > > > [BA] I agree that removing this code is attractive, particularly given the > tricky issues that arise in supporting non-mux properly. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf3071cc8c0e2d84051c2ea2c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 9:20 AM, Bernard Aboba <bernard.aboba@gm= ail.com> wrote:
On Jul 31, 2015, at 06:45, Roman Shpount <<= a href=3D"mailto:roman@telurix.com" target=3D"_blank">roman@telurix.com= > wrote:

The whole point = of this discussion is to remove the negotiation for rtcp-mux.

[BA] I support removing t= he mandate for RTP/RTCP non-mux but do not support removing the ability to = negotiate it.=C2=A0 If an implementation supports it, =C2=A0why shouldn'= ;t it be possible to negotiate its use?

Are you saying that compliant RTCWEB endpoints MUST support muxed = RTCP, but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)= ? That would work for us.

It would be better to redu= ce the code size by removing rtcp-mux negotiation and all the code related = to collecting second set of candidates for RTCP connection, supporting seco= nd component per media stream, negotiating second DTLS-SRTP for RTCP connec= tion, etc.This is a non-trivial amount of code, which is not being active= ly tested right now. Most of the open source webrtc gateways I looked at ha= ve it broken.

[BA] I agree that removing this code is attractive, particularly g= iven the tricky issues that arise in supporting non-mux properly.=C2=A0

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--20cf3071cc8c0e2d84051c2ea2c3-- From nobody Fri Jul 31 10:04:02 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DC61A8939 for ; Fri, 31 Jul 2015 10:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TE3K5ZPkflr4 for ; Fri, 31 Jul 2015 10:04:00 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1BF1A892E for ; Fri, 31 Jul 2015 10:03:59 -0700 (PDT) Received: by wibud3 with SMTP id ud3so65630113wib.1 for ; Fri, 31 Jul 2015 10:03:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=f87odF//E4QwIYb5tTASj5IrWrLzvodeEKD/hfHP9Pw=; b=D4EWY1xuXhhUCz8D4f6e5qLKxZpYT6fVOZsS9Fqa22MJ431+yeliFedZU5svkc87RA 07oYKnF876f4BbOChBPiCgZKNe8rXwfB4cPRThiRdPKOZNBjt9bNv3Cih84TdYUyi1Z3 +qlpSaTddL9f5UcwSN+kJKFhudwnl/jaMGZN0TQQzkBP0sfKsyTJEVHtqHLJHBCA/Znn s/MGo2MBhhnwiD71ehOk/O59Jr3Hza9YQimQddV8rm3uVihcNUUNQJvIM5juiqlUazZq ucDl8QWAKVnazBjOJVRW8i1tNG3iO68VC4MqJ5GIPZISeYq+/+hRB32htMKD11XYDgD0 /5MA== X-Gm-Message-State: ALoCoQkGTYpDs59MIaVICdVD0Vrgdv7qH4BRXch7r0wkh1JreN0XTc7W33pr2/emA+zLNW1y3ueg X-Received: by 10.180.208.114 with SMTP id md18mr8872255wic.31.1438362238266; Fri, 31 Jul 2015 10:03:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Fri, 31 Jul 2015 10:03:18 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 31 Jul 2015 19:03:18 +0200 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=001a11c37eb8454333051c2ece3d Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:04:01 -0000 --001a11c37eb8454333051c2ece3d Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 6:51 PM, Justin Uberti wrote: > > > On Fri, Jul 31, 2015 at 9:20 AM, Bernard Aboba > wrote: > >> On Jul 31, 2015, at 06:45, Roman Shpount wrote: >> >> >> The whole point of this discussion is to remove the negotiation for >> rtcp-mux. >> >> >> [BA] I support removing the mandate for RTP/RTCP non-mux but do not >> support removing the ability to negotiate it. If an implementation >> supports it, why shouldn't it be possible to negotiate its use? >> > > Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP, > but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? That > would work for us. > In this case, would browsers be able to reject attempts to set the policy to anything other than always-mux? Because I'm pretty sure that's what both we and Chrome want to do. -Ekr It would be better to reduce the code size by removing rtcp-mux negotiation >> and all the code related to collecting second set of candidates for RTCP >> connection, supporting second component per media stream, negotiating >> second DTLS-SRTP for RTCP connection, etc.This is a non-trivial amount >> of code, which is not being actively tested right now. Most of the open >> source webrtc gateways I looked at have it broken. >> >> >> [BA] I agree that removing this code is attractive, particularly given >> the tricky issues that arise in supporting non-mux properly. >> >> _______________________________________________ >> 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 > > --001a11c37eb8454333051c2ece3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 6:51 PM, Justin Uberti <juberti@google.com> wrote:

=

= On Fri, Jul 31, 2015 at 9:20 AM, Bernard Aboba <bernard.aboba@gmail.= com> wrote:
On Jul 31, 2015, at 06:45, Roman Shpount <roman@telurix.com> wrote:

The whole point of this discuss= ion is to remove the negotiation for rtcp-mux.

[BA] I support removing the mandate for = RTP/RTCP non-mux but do not support removing the ability to negotiate it.= =C2=A0 If an implementation supports it, =C2=A0why shouldn't it be poss= ible to negotiate its use?

Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP, = but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? That= would work for us.

In this case, would browsers be able to reject attempts to set the policy = to
anything other than always-mux? Because I'm pretty sure th= at's what both
we and Chrome want to do.

=
-Ekr

=
It would be better to reduce the code size by removing rtcp-mux negotiatio= n and all the code related to collecting second set of candidates for RTCP = connection, supporting second component per media stream, negotiating secon= d DTLS-SRTP for RTCP connection, etc.This is a non-trivial amount of code= , which is not being actively tested right now. Most of the open source web= rtc gateways I looked at have it broken.

[BA] I agree that removing this code is= attractive, particularly given the tricky issues that arise in supporting = non-mux properly.=C2=A0

____________= ___________________________________
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


--001a11c37eb8454333051c2ece3d-- From nobody Fri Jul 31 10:05:34 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AF11B2EAB for ; Fri, 31 Jul 2015 10:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da-MiI1HQQTq for ; Fri, 31 Jul 2015 10:05:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F511B2F03 for ; Fri, 31 Jul 2015 10:05:02 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-68-55bbaabc34ed Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D3.50.12828.CBAABB55; Fri, 31 Jul 2015 19:05:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0210.002; Fri, 31 Jul 2015 19:04:59 +0200 From: Christer Holmberg To: Bernard Aboba , Roman Shpount Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyvx8V8vzTHQq1UyV9J/pt2HwDp30w60AgAB5cYCAAAlpAIAAEkYAgAAd/QCAACs4gIAALhWu Date: Fri, 31 Jul 2015 17:04:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E29DAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3RnfPqt2hBtf3Slhs2Pef2WLGhanM Fmv/tbM7MHvsnHWX3WPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlfJ32mrngtkbFpGm/WBoY O5S7GDk5JARMJD42LWaDsMUkLtxbD2RzcQgJHGWUaPpzgAnCWcwoMamnhaWLkYODTcBCovuf NkiDiICfREPPPXYQm1lAU2LCsl1gg4QFsiQ2Nk9jBSkXEciWuHTfFaI8SqL/1C+wchYBVYnP 93Yygdi8Ar4St67/Z4dYNYVF4tT1r4wgCU4BW4nn1x6AzWQEOu77qTVMELvEJZq+rGSFOFpA Ysme88wQtqjEy8f/wPYyC+RL7D4XATFfUOLkzCcsExhFZiHpnoVQNQtJFUSJgcSX97ehbG2J ZQtfM0PY+hLd708zIYsvYGRfxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYZQe3/Nbdwbj6 teMhRgEORiUe3gXXdoUKsSaWFVfmHmKU5mBREuedsTkvVEggPbEkNTs1tSC1KL6oNCe1+BAj EwenFDCmGP4uvfW0YWrlsdvbxboc701Tt8i8X/vZZIamZGPblG9ppbL2Dj9vXHTh/LGXk/Pq Xc+PGz3XZ6+9drBVWriu4dBDv1JBB6PY4JlnGna8ipBkmn/+iVH4hgaldAG7S5OE1S5xxNX/ 9PhTFT6xq3vKar29d3rf318YrPf4l7yuftzWchn7+FtKLMUZiYZazEXFiQBXf+R1kwIAAA== Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:05:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348E29DAESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, In my opinion, even if we mandate the usage of rtcp-mux, the negotiation (r= ead: include the SDP rtcp-mux attribute in offers and answers) should not b= e removed. If there are ways to signal features we should do it. Regards, Christer Sent from my Windows Phone ________________________________ From: Bernard Aboba Sent: =FD31/=FD07/=FD2015 19:20 To: Roman Shpount Cc: Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it= would be Christmas in July!) On Jul 31, 2015, at 06:45, Roman Shpount > wrote: The whole point of this discussion is to remove the negotiation for rtcp-mu= x. [BA] I support removing the mandate for RTP/RTCP non-mux but do not support= removing the ability to negotiate it. If an implementation supports it, = why shouldn't it be possible to negotiate its use? It would be better to reduce the code size by removing rtcp-mux negotiation= and all the code related to collecting second set of candidates for RTCP c= onnection, supporting second component per media stream, negotiating second= DTLS-SRTP for RTCP connection, etc.This is a non-trivial amount of code, w= hich is not being actively tested right now. Most of the open source webrtc= gateways I looked at have it broken. [BA] I agree that removing this code is attractive, particularly given the = tricky issues that arise in supporting non-mux properly. --_000_7594FB04B1934943A5C02806D1A2204B348E29DAESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

In my opinion, even if we mandate the usage of rtcp-mux, the negotiation (r= ead: include the SDP rtcp-mux attribute in offers and answers) should not b= e removed. If there are ways to signal features we should do it.

Regards,

Christer

Sent from my Windows Phone
From: Bernard Aboba
Sent: =FD31= /=FD07/=FD2015 19:20
To: Roman Shpount
Cc: <rtcweb@ietf.org>
Subject: Re: [= rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Chri= stmas in July!)

On Jul 31, 2015, at 06:45, Roman Shpount <roman@telurix.com> wrote:

The whole point of this discussion is to remove the negotiation for rt= cp-mux.

[BA] I support removing the mandate for RTP/RTCP non-mux but do not su= pport removing the ability to negotiate it.  If an implementation supp= orts it,  why shouldn't it be possible to negotiate its use?

It would be better to reduce the code size by removing rtcp-mux negoti= ation and all the code related to collecting second set of candidates for R= TCP connection, supporting second component per media stream, negotiating s= econd DTLS-SRTP for RTCP connection, etc.This is a non-trivial amount = of code, which is not being actively tested right now. Most of the open sou= rce webrtc gateways I looked at have it broken.

[BA] I agree that removing this code is attractive, particularly given= the tricky issues that arise in supporting non-mux properly. 
--_000_7594FB04B1934943A5C02806D1A2204B348E29DAESESSMB209erics_-- From nobody Fri Jul 31 10:12:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB061B2F68 for ; Fri, 31 Jul 2015 10:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcJdcAtE21Lc for ; Fri, 31 Jul 2015 10:11:58 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06A7C1B2F66 for ; Fri, 31 Jul 2015 10:11:57 -0700 (PDT) Received: by vkca124 with SMTP id a124so23235535vkc.1 for ; Fri, 31 Jul 2015 10:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kHXizoYpVrwedTN8YWnb7V1HuSLLSi8fahyQahCw+lE=; b=grYozUMQyHWQ99m8kxPsugTxMdSu0FDVzlIKH0jOjogyZ1o30/UNsxtQDSlL76bJaG DNqF7tus1tXoepL4iyDMqPtDSZYqgFZvwaZxT66FoDSeKf4VyLyg6RO4Bg4hRcmUQMAh X1fezvICcfa66g97uhlNnqrJG09nTyvoRwKJnJzrMydRpQMhTfKIEA7Epb+haqEXEFsc D9fil/M/dAnDWy/pYwoEvokAdhLbX0WbBw4439FGYT3vcs0yyW68debbRCTPJdKDNUIR 14/bdKx5iZMH86cg/l4xwIZiiPINCCzSQJRJcEVw+cDIRrlCr7WEnyDXgIlbJA3QwQYZ NCWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kHXizoYpVrwedTN8YWnb7V1HuSLLSi8fahyQahCw+lE=; b=ZWOV1BXZcdZ6GEQTAaZIFbohEKHhdvIKd0zyAfEPPgHhhS1J2rgqGt1VIYCuaN8WpU S8VNoEpe8SnPffpDLb1KLBueoyHgqI/XW80tV3PIhQ0RbWsZ75it1qhjavZyk1jlE7NW C9SPH16TAsLJQHSEv/2X+WOVMOohP7e2XpqmCLx3GLIlyI6a8dXCjwRbHRbCzMP6fXq+ NejA2BL//6ZZutGbaihhtt5YXFrKZljHCxUxB3XF+JF/HH6Ac5t8o7BrijTK4/Xa8k+0 eJrM5BDzkXFq9n4ILdD3oTKP9QELcGaF8K7RVatWecrKX8Qpoldy2rggJYCMbEmdL1m1 ppGQ== X-Gm-Message-State: ALoCoQlVj67NR44Da58PkTqxE7Hr/Xu9QYLGByfmgvDa7hUtN7/p7zxWx1Xg/RPxt/zP/1MPnbCL X-Received: by 10.52.180.225 with SMTP id dr1mr5957591vdc.42.1438362717164; Fri, 31 Jul 2015 10:11:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.61.68 with HTTP; Fri, 31 Jul 2015 10:11:37 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> From: Justin Uberti Date: Fri, 31 Jul 2015 10:11:37 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec517a990d0befc051c2eea3a Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:11:59 -0000 --bcaec517a990d0befc051c2eea3a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mandating usage rtcp-mux means that an implementation is free to not negotiate it (or fail if the remote side does not support it). Right? On Fri, Jul 31, 2015 at 10:04 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > In my opinion, even if we mandate the usage of rtcp-mux, the negotiation > (read: include the SDP rtcp-mux attribute in offers and answers) should n= ot > be removed. If there are ways to signal features we should do it. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Bernard Aboba > Sent: =E2=80=8E31/=E2=80=8E07/=E2=80=8E2015 19:20 > To: Roman Shpount > Cc: > Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; > it would be Christmas in July!) > > On Jul 31, 2015, at 06:45, Roman Shpount wrote: > > > The whole point of this discussion is to remove the negotiation for > rtcp-mux. > > > [BA] I support removing the mandate for RTP/RTCP non-mux but do not > support removing the ability to negotiate it. If an implementation > supports it, why shouldn't it be possible to negotiate its use? > > It would be better to reduce the code size by removing rtcp-mux > negotiation and all the code related to collecting second set of candidat= es > for RTCP connection, supporting second component per media stream, > negotiating second DTLS-SRTP for RTCP connection, etc.This is a > non-trivial amount of code, which is not being actively tested right now. > Most of the open source webrtc gateways I looked at have it broken. > > > [BA] I agree that removing this code is attractive, particularly given th= e > tricky issues that arise in supporting non-mux properly. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec517a990d0befc051c2eea3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mandating usage rtcp-mux means that an implementation is f= ree to not negotiate it (or fail if the remote side does not support it). R= ight?

On Fri, Jul = 31, 2015 at 10:04 AM, Christer Holmberg <christer.holmberg@er= icsson.com> wrote:
Hi,

In my opinion, even if we mandate the usage of rtcp-mux, the negotiation (r= ead: include the SDP rtcp-mux attribute in offers and answers) should not b= e removed. If there are ways to signal features we should do it.

Regards,

Christer

Sent from my Windows Phone
From: Bernard Aboba
Sent: =E2=80= =8E31/=E2=80=8E07/=E2=80=8E2015 19:20
To: Roman Shpount
Cc: <rtcweb@ietf.org><= /span>
Subject: Re: [r= tcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Chris= tmas in July!)

On Jul 31, 2015, at 06:45, Roman Shpount <roman@telurix.com> wrote:

The whole point of this discussion is to remove the negotiation for rt= cp-mux.

[BA] I support removing the mandate for RTP/RTCP non-mux but do not su= pport removing the ability to negotiate it.=C2=A0 If an implementation supp= orts it, =C2=A0why shouldn't it be possible to negotiate its use?

It would be better to reduce the code size by removing rtcp-mux negoti= ation and all the code related to collecting second set of candidates for R= TCP connection, supporting second component per media stream, negotiating s= econd DTLS-SRTP for RTCP connection, etc.This is a non-trivial amount of code, wh= ich is not being actively tested right now. Most of the open source webrtc = gateways I looked at have it broken.

[BA] I agree that removing this code is attractive, particularly given= the tricky issues that arise in supporting non-mux properly.=C2=A0

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb


--bcaec517a990d0befc051c2eea3a-- From nobody Fri Jul 31 10:27:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE20C1B30A3 for ; Fri, 31 Jul 2015 10:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJBAZQz-n7yL for ; Fri, 31 Jul 2015 10:27:24 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFDC1B2F6B for ; Fri, 31 Jul 2015 10:27:13 -0700 (PDT) Received: by ioea135 with SMTP id a135so92037567ioe.1 for ; Fri, 31 Jul 2015 10:27:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PpI/zpE4Pxw/TM7Tlv5dtyO0rmWkukcrfggUVFtDoIc=; b=AgpG7u1RRgNYGv1Uqovu+J1u3yLCQ2JkYXfIDIza9871W+uUqHUHMGBa+5KV/74X5u WWeMX75/GSUMwLitrerUVF5sHe3+RZtunpndZ8xlVbD8N/fY2rI6izY9PNsGlQu2lQrt sJoEG+MiuNkBxF4Hy7iHJy5NROparTvFSHwcaO7cSRFrestsFFyEbt8iFC8/0tAK6Szq K68MgmIYp9xlbdQiW/TgkgORGr8tU4jm96Eifp9wPONbf3n6Z8l6/UrSClz1NqnVOi4z 3B76/BSTHpB1mOYOEp6qpu3F6h0s2gnLEIJcehLu3++Yl7fzzvWNHVbVM0+0RguekcCG RFPQ== X-Gm-Message-State: ALoCoQkPitapD3BBvBEU1uLqbCJvSuFHQkoWFCCPiWX8SCyOUxh5PwTZtOZL6YSnN2f4TLb6sAnC X-Received: by 10.107.131.91 with SMTP id f88mr7108507iod.190.1438363633209; Fri, 31 Jul 2015 10:27:13 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by smtp.gmail.com with ESMTPSA id g3sm2703576igi.10.2015.07.31.10.27.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 10:27:12 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so21303127igb.0 for ; Fri, 31 Jul 2015 10:27:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.138.193 with SMTP id qs1mr7656891igb.2.1438363631455; Fri, 31 Jul 2015 10:27:11 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Fri, 31 Jul 2015 10:27:11 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> Date: Fri, 31 Jul 2015 13:27:11 -0400 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=089e0122a5b84f999a051c2f2192 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:27:25 -0000 --089e0122a5b84f999a051c2f2192 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 1:11 PM, Justin Uberti wrote: > Mandating usage rtcp-mux means that an implementation is free to not > negotiate it (or fail if the remote side does not support it). Right? > > What I want to see precisely is the following: 1. WebRTC end point MUST include rtcp-mux for every SDP m-line in any offer it generates 2. WebRTC end point MAY include RTCP ICE component, RTCP ICE candidates, and "rtcp" SDP attribute with distinct RTCP address/port in the offer if it wants to support non mux RTCP traffic or it MAY ommit all of those attributes. 3. WebRTC end point MUST include rtcp-mux in response to any offer which contains rtcp-mux. It should not include RTCP ICE components or RTCP ICE candidates in the answer. "rtcp" SDP attribute MUST contain only port which should be the same as port associated with m-line (or address from c-line and port from m-line). 4. WebRTC end point MAY accept offers without rtcp-mux or MAY reject them. So, basically, rtcp-mux must be offered and must be accepted if offered. End point can continue to create offers which will work without rtcp-mux or accept offers without rtcp-mux if it needs to interop with legacy. _____________ Roman Shpount --089e0122a5b84f999a051c2f2192 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 31, 2015 at 1:11 PM, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:
Mandating usage rtcp-mux means that an = implementation is free to not negotiate it (or fail if the remote side does= not support it). Right?


What I want to see precisely is the following:
=
1. WebRTC end point MUST include rtcp-mux for every=C2=A0SDP= =C2=A0m-line in any offer it generates
2. WebRTC end point MAY in= clude RTCP ICE component, RTCP ICE candidates, and "rtcp" SDP att= ribute with distinct RTCP address/port in the offer if it wants to support = non mux RTCP traffic or it MAY ommit all of those attributes.
3. = WebRTC end point MUST include rtcp-mux in response to any offer which conta= ins rtcp-mux. It should not include RTCP ICE components or RTCP ICE candida= tes in the answer. "rtcp" SDP attribute MUST contain only port wh= ich should be the same as port associated with m-line (or address from c-li= ne and port from m-line).
4. WebRTC end point MAY accept offers w= ithout rtcp-mux or MAY reject them.

So, basically,= rtcp-mux must be offered and must be accepted if offered. End point can co= ntinue to create offers which will work without rtcp-mux or accept offers w= ithout rtcp-mux if it needs to interop with legacy.
_____________
Roman Shpount
=C2=A0
--089e0122a5b84f999a051c2f2192-- From nobody Fri Jul 31 10:32:02 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BFD1B30CE for ; Fri, 31 Jul 2015 10:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4PZPLrHC4OW for ; Fri, 31 Jul 2015 10:32:00 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF611B3048 for ; Fri, 31 Jul 2015 10:31:58 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so40830498wib.1 for ; Fri, 31 Jul 2015 10:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+BN9Q25wy8qN9YjckhEJ7HlfQuDRHKs+QXQJE99pF0k=; b=rdtHRVuiYxKmPXZGnfXyxICHJRX47/oyrqNAT8Ua1iPdqI/4O+dLOZrOA/b51nqPrR Jpoq1QNfQ1MNx/UmFP495jYu+TWlBOZtGUKhMmgG/vm6Ms3VegVgWA2vaGWwKgrfkykV omNhIEZDOo2do4+AbnvKF+HeOKfn237PawGBL5mWOaYqoxf0TchahnZnbUZLqp/eWQ9K APSvMPCvkUKTyzhyeTZOFvYNeEmJnRWlAa0b+8U/v32TwfaxK6u5slh0I5iz2lo/SNiT dA2pWSVA6ncoMFdfGLDUbz26+uT4mC+LuX6vDnldDr5yE7slPz1E/QpG5NtWoZ7W9LoP IlDg== MIME-Version: 1.0 X-Received: by 10.194.78.84 with SMTP id z20mr8510247wjw.141.1438363917173; Fri, 31 Jul 2015 10:31:57 -0700 (PDT) Received: by 10.28.20.132 with HTTP; Fri, 31 Jul 2015 10:31:57 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> Date: Fri, 31 Jul 2015 19:31:57 +0200 Message-ID: From: Victor Pascual Avila To: Roman Shpount Content-Type: multipart/alternative; boundary=047d7bf0c59c574a89051c2f323f Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:32:02 -0000 --047d7bf0c59c574a89051c2f323f Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 7:27 PM, Roman Shpount wrote: > On Fri, Jul 31, 2015 at 1:11 PM, Justin Uberti wrote: > >> Mandating usage rtcp-mux means that an implementation is free to not >> negotiate it (or fail if the remote side does not support it). Right? >> >> > What I want to see precisely is the following: > > 1. WebRTC end point MUST include rtcp-mux for every SDP m-line in any > offer it generates > 2. WebRTC end point MAY include RTCP ICE component, RTCP ICE candidates, > and "rtcp" SDP attribute with distinct RTCP address/port in the offer if it > wants to support non mux RTCP traffic or it MAY ommit all of those > attributes. > 3. WebRTC end point MUST include rtcp-mux in response to any offer which > contains rtcp-mux. It should not include RTCP ICE components or RTCP ICE > candidates in the answer. "rtcp" SDP attribute MUST contain only port which > should be the same as port associated with m-line (or address from c-line > and port from m-line). > 4. WebRTC end point MAY accept offers without rtcp-mux or MAY reject them. > > So, basically, rtcp-mux must be offered and must be accepted if offered. > End point can continue to create offers which will work without rtcp-mux or > accept offers without rtcp-mux if it needs to interop with legacy. > +1 Cheers, -Victor --047d7bf0c59c574a89051c2f323f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 31, 2015 at 7:27 PM, Roman Shpount <roman@telurix.com> wrote:
On Fri, Jul 31, 2015 at 1:11 PM, Ju= stin Uberti <juberti@google.com> wrote:
Mandating usage rtcp-mux means that an implementation i= s free to not negotiate it (or fail if the remote side does not support it)= . Right?

What= I want to see precisely is the following:

1. WebR= TC end point MUST include rtcp-mux for every=C2=A0SDP=C2=A0m-line in any of= fer it generates
2. WebRTC end point MAY include RTCP ICE compone= nt, RTCP ICE candidates, and "rtcp" SDP attribute with distinct R= TCP address/port in the offer if it wants to support non mux RTCP traffic o= r it MAY ommit all of those attributes.
3. WebRTC end point MUST = include rtcp-mux in response to any offer which contains rtcp-mux. It shoul= d not include RTCP ICE components or RTCP ICE candidates in the answer. &qu= ot;rtcp" SDP attribute MUST contain only port which should be the same= as port associated with m-line (or address from c-line and port from m-lin= e).
4. WebRTC end point MAY accept offers without rtcp-mux or MAY= reject them.

So, basically, rtcp-mux must be offe= red and must be accepted if offered. End point can continue to create offer= s which will work without rtcp-mux or accept offers without rtcp-mux if it = needs to interop with legacy.

=
+1

Cheers,
-Victor
<= /div>
--047d7bf0c59c574a89051c2f323f-- From nobody Fri Jul 31 10:39:43 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B3D1A92F3 for ; Fri, 31 Jul 2015 10:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkBRZJ12b1mb for ; Fri, 31 Jul 2015 10:39:36 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE25F1ABC0F for ; Fri, 31 Jul 2015 10:39:35 -0700 (PDT) Received: by pdrg1 with SMTP id g1so46077122pdr.2 for ; Fri, 31 Jul 2015 10:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kkyDbHCUEJlNsKqcDId3e7rWARnBfh2+aQFNJ/8Ome8=; b=fuMDLQBxtI6BwLrni0RgVOgz1ZpnlQf10y5ouIqtAPfpJQOYueNC4DIRCGIi6hSPj8 ITQ0yzNVLgABtVyS51xji05ITkiuwbX2lsl4x08SkL1HiWd0zl3ihApBfKsBWgE3nrXK /vh4s7db1WoZKExyQolPzZI+ePjUYedbqFhk8jVLWr0czhbUfFOelGF0NiOggwQuqeHK 6jsZBk5hZylSFClFvAQ6mQY0oEBBgn2H3iqWm/rE6VT5mzVdlutzuzKVNj4IpV+RnMkU 9a76XtBqufNgwv1Di/WA36Yxt3XBiZClI4YHvT2KEWyDJshTMb3WzVOvacxZvD+0+VAz mpXQ== X-Received: by 10.70.48.137 with SMTP id l9mr9143301pdn.45.1438364375674; Fri, 31 Jul 2015 10:39:35 -0700 (PDT) Received: from [192.168.1.110] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id mk6sm8834892pab.9.2015.07.31.10.39.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jul 2015 10:39:34 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-8181A718-2739-49C2-B647-86E9C4483270 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12H143) In-Reply-To: Date: Fri, 31 Jul 2015 10:39:32 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Eric Rescorla Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:39:42 -0000 --Apple-Mail-8181A718-2739-49C2-B647-86E9C4483270 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Jul 31, 2015, at 10:03, Eric Rescorla wrote: >>=20 >> Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP, b= ut MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? That w= ould work for us. [BA] Yes. Since RTP-Usage already requires mux support, we would only need t= o change the sentence requiring non-mux to make it optional.=20 > In this case, would browsers be able to reject attempts to set the policy t= o > anything other than always-mux? Because I'm pretty sure that's what both > we and Chrome want to do. [BA] Yes, that should be possible. If non-mux is optional, then an implement= ation that doesn't support it would only allow setting the policy to always m= ux.=20= --Apple-Mail-8181A718-2739-49C2-B647-86E9C4483270 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jul 31, 2015, at 10:03, Eric Rescor= la <ekr@rtfm.com> wrote:

Are you saying that compliant RTCWEB endpoints MUST support muxed R= TCP, but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? T= hat would work for us.

[BA] Yes.  Since RTP-Usage already re= quires mux support, we would only need to change the sentence requiring non-= mux to make it optional. 

In this case, would browsers be able to reject attempts to set the policy t= o
anything other than always-mux? Because I'm pretty sure that's w= hat both
we and Chrome want to do.

[BA] Yes, that should be possible. If non-mux is optio= nal, then an implementation that doesn't support it would only allow setting= the policy to always mux. 
= --Apple-Mail-8181A718-2739-49C2-B647-86E9C4483270-- From nobody Fri Jul 31 10:42:43 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633051ABC0F for ; Fri, 31 Jul 2015 10:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjfQJkt8O3GU for ; Fri, 31 Jul 2015 10:42:41 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9F41AC398 for ; Fri, 31 Jul 2015 10:42:40 -0700 (PDT) Received: by wibud3 with SMTP id ud3so66714449wib.1 for ; Fri, 31 Jul 2015 10:42:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=flZaHejF91n1WP5NhS00vkQogQOVIjFWbHBKvKAzGRI=; b=m8231IgFSTbOWrhUTawMEhqgbHLGy+dKZnxYUkxrcHbOaTqRgW8VwJlz6rqibrC0ow IzVg75O9jlN85nUxC+g0BWbbNDX6oyyiyWTlwRjFHrEPA1RTYusUyA4YqgLA/7U5DoIX FaZJQ8qraRcAnnrJgBDenH4a0EXPs2gcNZzQeTdlrB5jIfo3vK3gxblVo1qm0vk0M3hE nHV4iMU766gmuk37dEY7Vtjb6JuveQsUx0bVoTKp9mCly5gZpVLuROIONv0Cx2lxTdia jRO5RCZF5RwPtGVRRD8vhg3h0mp9pQbQFtYn69LCEeqyzNEDmWcKbqcS3iPJzFNIe2jb mLdw== X-Gm-Message-State: ALoCoQlC3MCj9UoMoqwbfjz3dnbsTk/b6vv4rAEfZ3yIkWgnRID0VV/p/dow3jBhx32UPXK59uOF X-Received: by 10.180.208.114 with SMTP id md18mr9201310wic.31.1438364559662; Fri, 31 Jul 2015 10:42:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Fri, 31 Jul 2015 10:42:00 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 31 Jul 2015 19:42:00 +0200 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a11c37eb8a2f1ba051c2f5805 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:42:42 -0000 --001a11c37eb8a2f1ba051c2f5805 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 7:39 PM, Bernard Aboba wrote: > On Jul 31, 2015, at 10:03, Eric Rescorla wrote: > > >> Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP, >> but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? That >> would work for us. >> > > [BA] Yes. Since RTP-Usage already requires mux support, we would only > need to change the sentence requiring non-mux to make it optional. > > In this case, would browsers be able to reject attempts to set the policy > to > anything other than always-mux? Because I'm pretty sure that's what both > we and Chrome want to do. > > > [BA] Yes, that should be possible. If non-mux is optional, then an > implementation that doesn't support it would only allow setting the policy > to always mux. > That seems satisfactory to me, since it means we can remove the code for non-mux. -Ekr --001a11c37eb8a2f1ba051c2f5805 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 7:39 PM, Bernard Aboba <bernard.aboba@gm= ail.com> wrote:
On Jul 31, 2015, at 10:03, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote= :

Are you saying that compliant RTCWEB endpoints MUST support m= uxed RTCP, but MAY support non-muxed RTCP (i.e. it is not explicitly prohib= ited)? That would work for us.

[BA] Yes.=C2=A0 Since RTP= -Usage already requires mux support, we would only need to change the sente= nce requiring non-mux to make it optional.=C2=A0

In this case, would browsers be able = to reject attempts to set the policy to
anything other than alway= s-mux? Because I'm pretty sure that's what both
we and Ch= rome want to do.

[BA] Yes, that should be possible. If non-mux = is optional, then an implementation that doesn't support it would only = allow setting the policy to always mux.=C2=A0

That seems satisfactory to me, since = it means we can remove the code for
non-mux= .

-Ekr=

--001a11c37eb8a2f1ba051c2f5805-- From nobody Fri Jul 31 10:46:24 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8C01AC3BC for ; Fri, 31 Jul 2015 10:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCbHSCXCtMnX for ; Fri, 31 Jul 2015 10:46:21 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585A31AC3A6 for ; Fri, 31 Jul 2015 10:46:21 -0700 (PDT) Received: by pdrg1 with SMTP id g1so46156390pdr.2 for ; Fri, 31 Jul 2015 10:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/ZwpwdH62Zs6BxZDtDOvO3R/eWUL+vjfS5vdf+FhD8M=; b=K/ZtPL0kXefHurToTWFBhgmxav3ZmEEyUbkeyUiGIS9FEQuTPpDWADUDOmHQrtcK7s bNDFeEA1YWmLWWK96CPrazOPU2WMDxCfBsu9nS70nK+SW6qxx4Uw5e2CrgWGYYb4szDf JVwaE5SBe80PpGI6aVfEl49jBvm+4r8+yySg7YtJxg+EUw5v2GRuMHHDNr7hxFaKPAWZ yFV5Al7vtKwSFBKCYP5vMokLkFud96rOwhqS8SJfMREMtzYH/DExlNRojzUVBUm3pZ52 j0cFU8rRh/URr3yoh0s653T7A02euuT77fu2ATFwt4lxWieN1vZ3EQbXOXQjC1uF9rRc 4Jzg== X-Received: by 10.70.109.199 with SMTP id hu7mr9380060pdb.71.1438364781012; Fri, 31 Jul 2015 10:46:21 -0700 (PDT) Received: from [192.168.1.110] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id tm3sm8796760pac.44.2015.07.31.10.46.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jul 2015 10:46:19 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-CA9AD645-5C41-47CF-A4D1-8BB0560DC8CC Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12H143) In-Reply-To: Date: Fri, 31 Jul 2015 10:46:18 -0700 Content-Transfer-Encoding: 7bit Message-Id: <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> To: Roman Shpount Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:46:22 -0000 --Apple-Mail-CA9AD645-5C41-47CF-A4D1-8BB0560DC8CC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable >> On Fri, Jul 31, 2015 at 7:27 PM, Roman Shpount wrote:= >>=20 >> So, basically, rtcp-mux must be offered and must be accepted if offered. E= nd point can continue to create offers which will work without rtcp-mux or a= ccept offers without rtcp-mux if it needs to interop with legacy. [BA] This is a bit weird because if a browser supporting non-mux negotiates w= ith a gateway that supports non-mux, the implication is that if the browser i= s the offerer, mux is negotiated, but if the gateway is the offerer, non-mux= can be negotiated. That would seem to imply that the gateway would need to r= eject the browser's offer, then send its own offer in order to negotiate non= -mux.= --Apple-Mail-CA9AD645-5C41-47CF-A4D1-8BB0560DC8CC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=
On Fri, Jul 31, 2015 a= t 7:27 PM, Roman Shpount <roman@telurix.com> wrote:

So, basically, rtcp-mux must be offered an= d must be accepted if offered. End point can continue to create offers which= will work without rtcp-mux or accept offers without rtcp-mux if it needs to= interop with legacy.
=
[BA] This is a bit weird because if a browser supporti= ng non-mux negotiates with a gateway that supports non-mux, the implication i= s that if the browser is the offerer, mux is negotiated, but if the gateway i= s the offerer, non-mux can be negotiated. That would seem to imply that the g= ateway would need to reject the browser's offer, then send its own offer in o= rder to negotiate non-mux.
= --Apple-Mail-CA9AD645-5C41-47CF-A4D1-8BB0560DC8CC-- From nobody Fri Jul 31 10:57:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DFA1B2EA2 for ; Fri, 31 Jul 2015 10:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 759oAYI9tsUV for ; Fri, 31 Jul 2015 10:57:57 -0700 (PDT) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12C91B2E88 for ; Fri, 31 Jul 2015 10:57:57 -0700 (PDT) Received: by ioeg141 with SMTP id g141so93116526ioe.3 for ; Fri, 31 Jul 2015 10:57:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gmtYaNpk7DbLO/2iTjWROp4PDH4xsohphX8yx7ZKZCc=; b=jtOTu9WLpsyW2xWLUYnmaV4MUQmZuuqGnBxj8ZUGuiUpEPTeopjhr7AO/2ssFkuoKj fQsHFtvD3VaUp8J2n75SEdP+lR6rXQZ0LQLSj/AIvycOTqvuV7cs4fWWaKqaMsuv0oyS trAz3NZWqTheVmmJqT+MKqiMMII5duD59IuLW5f/pAuTj8nyBi+QRWtdzFjpDSnE8jc3 74vsHv+s9pEh5sXZQjtMnC3uAEEh3dY83PgpjgyXAVg19dDdhkjLBFfX7p7JoMVF5hU0 nDGfhf4HXps3qZtxlk3BAu+cz7LVb5SOh9A3s97/owkeM+6I77bqt3RrYXNdx/8Car60 aSKA== X-Gm-Message-State: ALoCoQmXTXwDiinkTEfEytp2ygpN2CRoWQE2yJ88Vu00eDHWXsEkzNomYYIMi+FLcOe4v4c6F0/1 X-Received: by 10.107.16.223 with SMTP id 92mr7327946ioq.14.1438365477165; Fri, 31 Jul 2015 10:57:57 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by smtp.gmail.com with ESMTPSA id y30sm3766960ioi.23.2015.07.31.10.57.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 10:57:56 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so37017620igb.0 for ; Fri, 31 Jul 2015 10:57:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.138.193 with SMTP id qs1mr7879341igb.2.1438365475306; Fri, 31 Jul 2015 10:57:55 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Fri, 31 Jul 2015 10:57:55 -0700 (PDT) In-Reply-To: <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> Date: Fri, 31 Jul 2015 13:57:55 -0400 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=089e0122a5b83685ea051c2f8f02 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:57:59 -0000 --089e0122a5b83685ea051c2f8f02 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 1:46 PM, Bernard Aboba wrote: > On Fri, Jul 31, 2015 at 7:27 PM, Roman Shpount wrote: >> >> >> So, basically, rtcp-mux must be offered and must be accepted if offered. >> End point can continue to create offers which will work without rtcp-mux or >> accept offers without rtcp-mux if it needs to interop with legacy. >> > > [BA] This is a bit weird because if a browser supporting non-mux > negotiates with a gateway that supports non-mux, the implication is that if > the browser is the offerer, mux is negotiated, but if the gateway is the > offerer, non-mux can be negotiated. That would seem to imply that the > gateway would need to reject the browser's offer, then send its own offer > in order to negotiate non-mux. > Why would the gateway need to negotiate non-mix if rtcp-mux is supported? I have not seen anything that would normally accept an offer with rtcp-mux, but will send an offer without rtcp-mux. In any case, if the gateway behaves in such asymmetric manner, it will produce asymmetric results. _____________ Roman Shpount --089e0122a5b83685ea051c2f8f02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 31, 2015 at 1:46 PM, Bernard Aboba <<= a href=3D"mailto:bernard.aboba@gmail.com" target=3D"_blank">bernard.aboba@g= mail.com> wrote:
On Fri, Jul 31, 2015 at 7:27 PM, Roman Shpount <roman@telurix.c= om> wrote:
=

So, basically, rtcp-mux must be offered and must be acc= epted if offered. End point can continue to create offers which will work w= ithout rtcp-mux or accept offers without rtcp-mux if it needs to interop wi= th legacy.

[BA] This is a bit weird because if a browser supporting= non-mux negotiates with a gateway that supports non-mux, the implication i= s that if the browser is the offerer, mux is negotiated, but if the gateway= is the offerer, non-mux can be negotiated. That would seem to imply that t= he gateway would need to reject the browser's offer, then send its own = offer in order to negotiate non-mux.

Why would the gateway need to negotiate non-mi= x if rtcp-mux is supported? I have not seen anything that would normally ac= cept an offer with rtcp-mux, but will send an offer without rtcp-mux. In an= y case, if the gateway behaves in such asymmetric manner, it will produce a= symmetric results.
_____________
Roman Shpount

--089e0122a5b83685ea051c2f8f02-- From nobody Fri Jul 31 11:31:49 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961AC1B3443 for ; Fri, 31 Jul 2015 11:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6iYbr05j0yn for ; Fri, 31 Jul 2015 11:31:47 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20AF61B3434 for ; Fri, 31 Jul 2015 11:31:47 -0700 (PDT) Received: by pdjr16 with SMTP id r16so47787081pdj.3 for ; Fri, 31 Jul 2015 11:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dENu1p10Y4s1C2SVlYa4dyWOPemlQbqPOaGNnNE59FU=; b=vTNHbCnPIAhB89J7Gxrn9yd7BDMbUFmyc75EYNVEx8sQmTRxComonEcnQfFl7pMEOd JsaYhmSMZvaXI0CozwUn/jMkGZIWDP5T4SFQI4cGvvTgRoq4oiAs0wET6Lm+XOYo9f7Q zJAdu5uTzo6cI675gCg23lDl4qNxzR0s0sxA4vEyXGCgr0+04B1VSFGkUB+wTIrTyp2U 3pSeEMfDz/hpeDpLatQoZjsc4L5z2rb8RoL90IYFhogDBQJkpNONyTEsLx0PX67ZXZPb uQ1P6EsoYcuC/s11jURBnQJwnihrXrCaoYdeAeccWyaQfZ0qoqm/BquVFhfQwhCtBa6g wFSw== X-Received: by 10.70.135.129 with SMTP id ps1mr9718635pdb.110.1438367506749; Fri, 31 Jul 2015 11:31:46 -0700 (PDT) Received: from [192.168.1.110] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id un2sm8971060pac.28.2015.07.31.11.31.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jul 2015 11:31:45 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B817CC60-2FEA-4BA5-B3F0-C7BA5CC5C66F Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12H143) In-Reply-To: Date: Fri, 31 Jul 2015 11:31:43 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> To: Roman Shpount Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:31:48 -0000 --Apple-Mail-B817CC60-2FEA-4BA5-B3F0-C7BA5CC5C66F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Jul 31, 2015, at 10:57, Roman Shpount wrote: >=20 > Why would the gateway need to negotiate non-mux if rtcp-mux is supported? [BA] IMHO, Gateways should be required to support mux like any other WEBRTC e= ndpoint, but this is not what it says in Section 2 of https://tools.ietf.org= /html/draft-ietf-rtcweb-gateways : "If a gateway serves as a media relay into another RTP domain, it MAY choose= to support only features available in that network. This means that it MAY c= hoose to not support Bundle and any of the RTP/ RTCP extensions related to i= t, RTCP-Mux, or Trickle Ice. However, the gateway MUST support DTLS-SRTP, si= nce this is required for interworking with WebRTC endpoints." Assuming that browsers remove or do not implement non-mux, it seems prudent t= o require gateways to support mux so as to avoid negotiation failures. If we= make that change then gateways would always negotiate RTCP-mux with browser= s.= --Apple-Mail-B817CC60-2FEA-4BA5-B3F0-C7BA5CC5C66F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jul 31, 2015, at 10:57, Roman Shpou= nt <roman@telurix.com> wrote:=
=
Why would the gateway need to negotiate= non-mux if rtcp-mux is supported?

<= div>[BA] IMHO, Gateways should be required to support mux like any other WEB= RTC endpoint, but this is not what it says in Section 2 of https://tools.ietf.org/htm= l/draft-ietf-rtcweb-gateways :

"If a gateway serves as a media=
 relay into another RTP domain, it MAY
   choose to support only features available in that network.  This
   means that it MAY choose to not support Bundle and any of the RTP/
   RTCP extensions related to it, RTCP-Mux, or Trickle Ice. However, the
   gateway MUST support DTLS-SRTP, since this is required for
   interworking with WebRTC endpoints."

Assuming that browsers remove or do not implement non-mux, it see=
ms prudent to require gateways to support mux so as to avoid negotiation fai=
lures. If we make that change then gateways would always negotiate RTCP-mux w=
ith browsers.
= --Apple-Mail-B817CC60-2FEA-4BA5-B3F0-C7BA5CC5C66F-- From nobody Fri Jul 31 11:33:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25101B3444 for ; Fri, 31 Jul 2015 11:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_mAnFb-nWLM for ; Fri, 31 Jul 2015 11:33:39 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697FC1B342E for ; Fri, 31 Jul 2015 11:33:39 -0700 (PDT) Received: by vkgc186 with SMTP id c186so24049372vkg.0 for ; Fri, 31 Jul 2015 11:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zwiGiSeVQ4m/FfF05qWBRrr+zgHzu6rRfMv/L6+TVAc=; b=b6Bw+xN6NqR0+D5v1RlncHcTb+oYFXk+fxZUO+mswxjOsZ+RZTDzruXyyn7//qpV3r VR92loTayQZTPjjMXDHX8ttR+e2ebJT60usmRPQpeDr/0/2fe+9gk6KAFXmH5cP+/m15 FgxmsH24EDxHueY5th74eS/OSG3ZL9t/2tgzSYxwM/95f/hp57MP7zX2voqZ0Jp7470S OYB/aRdver1avMnVwWdMKZM1QU5dS5zA4eapiGMGLD5cUPKza7WW5soY6XL+Ea2EdMsb D7sRt9tvPxdJDYtvUXylvRkymfqV+GHDV4ux61jgk3ZHyqGS2NfYiFjaaeR8+5LQJW8O St3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zwiGiSeVQ4m/FfF05qWBRrr+zgHzu6rRfMv/L6+TVAc=; b=dpvTz5+rc4XKkbtgn/K3Kmo7TL0SK7iqZVaOJi7BFMC+hjc4WHKvWt8+mnLUGSQqq0 jIGSoan55DlfdtOIsnAbKvhXxMCJHTNfl0uvGxUld0usMosOoKzGJqm05TN5ZqeGrgVr I05itjs+k0smagNMMsO6K2+H3obPlrW2NpuQZ0wtySQaDlQ99vQa9YCnJN3gcikxaKIO cjS/ekud3Dyq8bYkR6yln9r5j0bOo/fmdJimA0Aih8QMYocxpKK9yNBMd4kE5SyGYCQ+ 4HNFzwVPXZkaOZ8H9pfyl02RZrt7GnY35Y0CG91vjmtbipEdFqlelC11V4jDwv2dhkBm 0FEA== X-Gm-Message-State: ALoCoQnHKDiDpPEflSqswl8MgiiAl2Rq6LzlgTAt6rErX2qJ6FYAOczVCZQNfXzMqWqLan2WFzCL X-Received: by 10.52.116.67 with SMTP id ju3mr6177191vdb.66.1438367618686; Fri, 31 Jul 2015 11:33:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.61.68 with HTTP; Fri, 31 Jul 2015 11:33:19 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Fri, 31 Jul 2015 11:33:19 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec548aa59f81434051c300e0a Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:33:40 -0000 --bcaec548aa59f81434051c300e0a Content-Type: text/plain; charset=UTF-8 likewise. That is the salient point here, after all. On Fri, Jul 31, 2015 at 10:42 AM, Eric Rescorla wrote: > > > On Fri, Jul 31, 2015 at 7:39 PM, Bernard Aboba > wrote: > >> On Jul 31, 2015, at 10:03, Eric Rescorla wrote: >> >> >>> Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP, >>> but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? That >>> would work for us. >>> >> >> [BA] Yes. Since RTP-Usage already requires mux support, we would only >> need to change the sentence requiring non-mux to make it optional. >> >> In this case, would browsers be able to reject attempts to set the policy >> to >> anything other than always-mux? Because I'm pretty sure that's what both >> we and Chrome want to do. >> >> >> [BA] Yes, that should be possible. If non-mux is optional, then an >> implementation that doesn't support it would only allow setting the policy >> to always mux. >> > > That seems satisfactory to me, since it means we can remove the code for > non-mux. > > -Ekr > > --bcaec548aa59f81434051c300e0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
likewise. That is the salient point here, after all.
=

On Fri, Jul 31, 2= 015 at 10:42 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Fri, Jul 31, 2015 at 7:= 39 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:<= br>
On Jul 31, 2= 015, at 10:03, Eric Rescorla <ekr@rtfm.com> wrote:

Are you saying that compl= iant RTCWEB endpoints MUST support muxed RTCP, but MAY support non-muxed RT= CP (i.e. it is not explicitly prohibited)? That would work for us.

<= /span>
[BA] Yes.=C2=A0 Since RTP-Usage already requires mux support, we= would only need to change the sentence requiring non-mux to make it option= al.=C2=A0

In this case= , would browsers be able to reject attempts to set the policy to
= anything other than always-mux? Because I'm pretty sure that's what= both
we and Chrome want to do.

[BA] Yes, that should be possible. If non-mux = is optional, then an implementation that doesn't support it would only = allow setting the policy to always mux.=C2=A0

That seems satisfactory t= o me, since it means we can remove the code for
non-mux.

-Ekr


--bcaec548aa59f81434051c300e0a-- From nobody Fri Jul 31 11:39:54 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE311B3457 for ; Fri, 31 Jul 2015 11:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAbwDcEJxbiJ for ; Fri, 31 Jul 2015 11:39:52 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7D31B3453 for ; Fri, 31 Jul 2015 11:39:50 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-b2-55bbc0f490fd Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5D.F0.29223.4F0CBB55; Fri, 31 Jul 2015 20:39:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0210.002; Fri, 31 Jul 2015 20:39:48 +0200 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyvx8V8vzTHQq1UyV9J/pt2HwDp30w60AgAB5cYCAAAlpAIAAEkYAgAAd/QCAACs4gIAALhWu///gU4CAADnhgA== Date: Fri, 31 Jul 2015 18:39:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E2CDF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E2CDFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM+Jvje7XA7tDDbbd5rHYsO8/s8XWqUIW My5MZbZY+6+d3YHFY+esu+weCzaVeixZ8pPJ49aUggCWKC6blNSczLLUIn27BK6MiWf62Qt2 VVf8mrCdpYFxQkUXIyeHhICJxJQlPWwQtpjEhXvrgWwuDiGBo4wSr6etgHIWM0rc+HiBuYuR g4NNwEKi+582SIOIgJrEw1m7WEFsZoFyies/r7KA2MICWRIbm6exgpSLCGRLXLrvClGeJfHu biMbSJhFQFVi4fsMkDCvgK/ElKt7GSE2LWSVmNv2mhkkwSkQKHG4rZkJxGYEuu37qTVMEKvE JW49mc8EcbOAxJI955khbFGJl4//sULYShIrtl9ihKjPl5i5cyc7xDJBiZMzn7BMYBSdhWTU LCRls5CUzQI6lVlAU2L9Ln2IEkWJKd0P2SFsDYnWOXPZkcUXMLKvYhQtTi1Oyk03MtJLLcpM Li7Oz9PLSy3ZxAiMxoNbfhvsYHz53PEQowAHoxIP74Jru0KFWBPLiitzDzFKc7AoifPO2JwX KiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExYGfTgWc1fC8P/Jb+4+P/rJhjNsulqZ8mPOdK e18vIBMzaZ7LofSzvzctsdveIn5zR9vRfjGpk2eP3Z/Bc73kTfjvGVHKXDWc3V63ZFIKfgne /pB6c+4RO5Mvn+Z9Pn1Jne8Ezx6umsDTmzaqOj1esbpG6fVsvWVPvgnEuN+e/c3/EuvpC0p1 75RYijMSDbWYi4oTAWBlNuKnAgAA Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:39:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348E2CDFESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk15IHN1Z2dlc3Rpb24gaXMgdGhhdCB0aGUgb2ZmZXJlciBNVVNUIGluY2x1ZGUgdGhl IGF0dHJpYnV0ZSwgYW5kIHRoZSBhbnN3ZXJlciBNVVNUIGluY2x1ZGUgdGhlIGF0dHJpYnV0ZSAo YXNzdW1pbmcgd2UgZ28gYWhlYWQgd2l0aCBtYW5kYXRpbmcgdXNhZ2Ugb2YgcnRjcC1tdXgpLg0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anVi ZXJ0aUBnb29nbGUuY29tXQ0KU2VudDogMzEgSnVseSAyMDE1IDIwOjEyDQpUbzogQ2hyaXN0ZXIg SG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBCZXJuYXJkIEFi b2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT47IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVy aXguY29tPjsgPHJ0Y3dlYkBpZXRmLm9yZz4gPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbcnRjd2ViXSBQcm9wb3NhbDogcmVxdWlyZSBydGNwLW11eCAocmVtb3ZlIG5vbi1tdXhlZCBS VENQOyBpdCB3b3VsZCBiZSBDaHJpc3RtYXMgaW4gSnVseSEpDQoNCk1hbmRhdGluZyB1c2FnZSBy dGNwLW11eCBtZWFucyB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGlzIGZyZWUgdG8gbm90IG5lZ290 aWF0ZSBpdCAob3IgZmFpbCBpZiB0aGUgcmVtb3RlIHNpZGUgZG9lcyBub3Qgc3VwcG9ydCBpdCku IFJpZ2h0Pw0KDQpPbiBGcmksIEp1bCAzMSwgMjAxNSBhdCAxMDowNCBBTSwgQ2hyaXN0ZXIgSG9s bWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KSW4gbXkgb3BpbmlvbiwgZXZlbiBp ZiB3ZSBtYW5kYXRlIHRoZSB1c2FnZSBvZiBydGNwLW11eCwgdGhlIG5lZ290aWF0aW9uIChyZWFk OiBpbmNsdWRlIHRoZSBTRFAgcnRjcC1tdXggYXR0cmlidXRlIGluIG9mZmVycyBhbmQgYW5zd2Vy cykgc2hvdWxkIG5vdCBiZSByZW1vdmVkLiBJZiB0aGVyZSBhcmUgd2F5cyB0byBzaWduYWwgZmVh dHVyZXMgd2Ugc2hvdWxkIGRvIGl0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50IGZy b20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IEJlcm5hcmQgQWJvYmE8bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPg0KU2VudDog 4oCOMzEv4oCOMDcv4oCOMjAxNSAxOToyMA0KVG86IFJvbWFuIFNocG91bnQ8bWFpbHRvOnJvbWFu QHRlbHVyaXguY29tPg0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc+PG1haWx0bzpydGN3ZWJAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUHJvcG9zYWw6IHJlcXVpcmUgcnRjcC1tdXggKHJl bW92ZSBub24tbXV4ZWQgUlRDUDsgaXQgd291bGQgYmUgQ2hyaXN0bWFzIGluIEp1bHkhKQ0KT24g SnVsIDMxLCAyMDE1LCBhdCAwNjo0NSwgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208 bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQoNClRoZSB3aG9sZSBwb2ludCBvZiB0 aGlzIGRpc2N1c3Npb24gaXMgdG8gcmVtb3ZlIHRoZSBuZWdvdGlhdGlvbiBmb3IgcnRjcC1tdXgu DQoNCltCQV0gSSBzdXBwb3J0IHJlbW92aW5nIHRoZSBtYW5kYXRlIGZvciBSVFAvUlRDUCBub24t bXV4IGJ1dCBkbyBub3Qgc3VwcG9ydCByZW1vdmluZyB0aGUgYWJpbGl0eSB0byBuZWdvdGlhdGUg aXQuICBJZiBhbiBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyBpdCwgIHdoeSBzaG91bGRuJ3QgaXQg YmUgcG9zc2libGUgdG8gbmVnb3RpYXRlIGl0cyB1c2U/DQoNCkl0IHdvdWxkIGJlIGJldHRlciB0 byByZWR1Y2UgdGhlIGNvZGUgc2l6ZSBieSByZW1vdmluZyBydGNwLW11eCBuZWdvdGlhdGlvbiBh bmQgYWxsIHRoZSBjb2RlIHJlbGF0ZWQgdG8gY29sbGVjdGluZyBzZWNvbmQgc2V0IG9mIGNhbmRp ZGF0ZXMgZm9yIFJUQ1AgY29ubmVjdGlvbiwgc3VwcG9ydGluZyBzZWNvbmQgY29tcG9uZW50IHBl ciBtZWRpYSBzdHJlYW0sIG5lZ290aWF0aW5nIHNlY29uZCBEVExTLVNSVFAgZm9yIFJUQ1AgY29u bmVjdGlvbiwgZXRjLlRoaXMgaXMgYSBub24tdHJpdmlhbCBhbW91bnQgb2YgY29kZSwgd2hpY2gg aXMgbm90IGJlaW5nIGFjdGl2ZWx5IHRlc3RlZCByaWdodCBub3cuIE1vc3Qgb2YgdGhlIG9wZW4g c291cmNlIHdlYnJ0YyBnYXRld2F5cyBJIGxvb2tlZCBhdCBoYXZlIGl0IGJyb2tlbi4NCg0KW0JB XSBJIGFncmVlIHRoYXQgcmVtb3ZpbmcgdGhpcyBjb2RlIGlzIGF0dHJhY3RpdmUsIHBhcnRpY3Vs YXJseSBnaXZlbiB0aGUgdHJpY2t5IGlzc3VlcyB0aGF0IGFyaXNlIGluIHN1cHBvcnRpbmcgbm9u LW11eCBwcm9wZXJseS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRj d2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3 ZWINCg0K --_000_7594FB04B1934943A5C02806D1A2204B348E2CDFESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5NeSBzdWdnZXN0aW9uIGlzIHRoYXQgdGhlIG9mZmVyZXIgTVVTVCBpbmNs dWRlIHRoZSBhdHRyaWJ1dGUsIGFuZCB0aGUgYW5zd2VyZXIgTVVTVCBpbmNsdWRlIHRoZSBhdHRy aWJ1dGUgKGFzc3VtaW5nIHdlIGdvIGFoZWFkIHdpdGgNCiBtYW5kYXRpbmcgdXNhZ2Ugb2YgcnRj cC1tdXgpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlA Z29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAzMSBKdWx5IDIwMTUgMjA6MTI8YnI+DQo8 Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBCZXJuYXJkIEFib2JhICZsdDtiZXJuYXJkLmFib2Jh QGdtYWlsLmNvbSZndDs7IFJvbWFuIFNocG91bnQgJmx0O3JvbWFuQHRlbHVyaXguY29tJmd0Ozsg Jmx0O3J0Y3dlYkBpZXRmLm9yZyZndDsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFByb3Bvc2FsOiByZXF1aXJlIHJ0Y3AtbXV4IChyZW1v dmUgbm9uLW11eGVkIFJUQ1A7IGl0IHdvdWxkIGJlIENocmlzdG1hcyBpbiBKdWx5ISk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYW5kYXRpbmcgdXNhZ2UgcnRjcC1tdXgg bWVhbnMgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBpcyBmcmVlIHRvIG5vdCBuZWdvdGlhdGUgaXQg KG9yIGZhaWwgaWYgdGhlIHJlbW90ZSBzaWRlIGRvZXMgbm90IHN1cHBvcnQgaXQpLiBSaWdodD88 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEp1bCAzMSwgMjAx NSBhdCAxMDowNCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkhpLDxicj4NCjxicj4NCkluIG15IG9waW5pb24sIGV2ZW4gaWYgd2UgbWFuZGF0ZSB0 aGUgdXNhZ2Ugb2YgcnRjcC1tdXgsIHRoZSBuZWdvdGlhdGlvbiAocmVhZDogaW5jbHVkZSB0aGUg U0RQIHJ0Y3AtbXV4IGF0dHJpYnV0ZSBpbiBvZmZlcnMgYW5kIGFuc3dlcnMpIHNob3VsZCBub3Qg YmUgcmVtb3ZlZC4gSWYgdGhlcmUgYXJlIHdheXMgdG8gc2lnbmFsIGZlYXR1cmVzIHdlIHNob3Vs ZCBkbyBpdC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJy Pg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIg c3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIzIiB3aWR0aD0iMTAwJSIgYWxp Z249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPkJlcm5hcmQgQWJvYmE8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+U2VudDogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKAjjMxL+KAjjA3L+KAjjIw MTUgMTk6MjA8L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UbzogPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPlJvbWFuIFNocG91bnQ8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Q2M6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWlsdG86cnRjd2Vi QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8L2E+PC9z cGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U3ViamVjdDogPC9zcGFuPg0KPC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+UmU6IFtydGN3ZWJdIFByb3Bvc2FsOiByZXF1aXJlIHJ0Y3AtbXV4IChyZW1v dmUgbm9uLW11eGVkIFJUQ1A7IGl0IHdvdWxkIGJlIENocmlzdG1hcyBpbiBKdWx5ISk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBKdWwgMzEsIDIwMTUsIGF0IDA2OjQ1LCBSb21hbiBTaHBvdW50 ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5y b21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB3 aG9sZSBwb2ludCBvZiB0aGlzIGRpc2N1c3Npb24gaXMgdG8gcmVtb3ZlIHRoZSBuZWdvdGlhdGlv biBmb3IgcnRjcC1tdXguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltCQV0g SSBzdXBwb3J0IHJlbW92aW5nIHRoZSBtYW5kYXRlIGZvciBSVFAvUlRDUCBub24tbXV4IGJ1dCBk byBub3Qgc3VwcG9ydCByZW1vdmluZyB0aGUgYWJpbGl0eSB0byBuZWdvdGlhdGUgaXQuJm5ic3A7 IElmIGFuIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIGl0LCAmbmJzcDt3aHkgc2hvdWxkbid0IGl0 IGJlIHBvc3NpYmxlIHRvIG5lZ290aWF0ZSBpdHMgdXNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 IHdvdWxkIGJlIGJldHRlciB0byByZWR1Y2UgdGhlIGNvZGUgc2l6ZSBieSByZW1vdmluZyBydGNw LW11eCBuZWdvdGlhdGlvbiBhbmQgYWxsIHRoZSBjb2RlIHJlbGF0ZWQgdG8gY29sbGVjdGluZyBz ZWNvbmQgc2V0IG9mIGNhbmRpZGF0ZXMgZm9yIFJUQ1AgY29ubmVjdGlvbiwgc3VwcG9ydGluZyBz ZWNvbmQgY29tcG9uZW50IHBlciBtZWRpYSBzdHJlYW0sIG5lZ290aWF0aW5nIHNlY29uZCBEVExT LVNSVFANCiBmb3IgUlRDUCBjb25uZWN0aW9uLCBldGMuPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5UaGlzIGlzIGEgbm9uLXRyaXZpYWwgYW1vdW50IG9mIGNvZGUsIHdoaWNoIGlzIG5vdCBiZWlu ZyBhY3RpdmVseSB0ZXN0ZWQgcmlnaHQgbm93LiBNb3N0IG9mIHRoZSBvcGVuIHNvdXJjZSB3ZWJy dGMgZ2F0ZXdheXMgSSBsb29rZWQgYXQgaGF2ZSBpdCBicm9rZW4uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQkFdIEkgYWdyZWUgdGhhdCByZW1vdmluZyB0aGlz IGNvZGUgaXMgYXR0cmFjdGl2ZSwgcGFydGljdWxhcmx5IGdpdmVuIHRoZSB0cmlja3kgaXNzdWVz IHRoYXQgYXJpc2UgaW4gc3VwcG9ydGluZyBub24tbXV4IHByb3Blcmx5LiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B348E2CDFESESSMB209erics_-- From nobody Fri Jul 31 11:41:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D6D1B346F for ; Fri, 31 Jul 2015 11:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRXgtVsYMJkW for ; Fri, 31 Jul 2015 11:41:37 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332FA1B3469 for ; Fri, 31 Jul 2015 11:41:36 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-77-55bbc15f4729 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C7.39.12828.F51CBB55; Fri, 31 Jul 2015 20:41:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Fri, 31 Jul 2015 20:41:35 +0200 From: Christer Holmberg To: Roman Shpount , Justin Uberti Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyvx8V8vzTHQq1UyV9J/pt2HwDp30w60AgAB5cYCAAAlpAIAAEkYAgAAd/QCAACs4gIAALhWu///gU4CAAARagIAANhQA Date: Fri, 31 Jul 2015 18:41:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E2D1B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E2D1BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+JvjW78wd2hBjsfSlts2Pef2WLrVCGL GRemMlus/dfO7sDisXPWXXaPBZtKPZYs+cnkcWtKQQBLFJdNSmpOZllqkb5dAldG25KrLAUN 6hXnNq1kbmB8o9rFyMEhIWAi8feEexcjJ5ApJnHh3no2EFtI4CijxLIHMl2MXED2YkaJtbue s4LUswlYSHT/0wapERHwlHjzczEzSJhZIERi80YtkLCwQJbExuZpYNUiAtkSl+67QlTnSRx5 tIwdJMwioCox47IOSJhXwFdiY99tdohFL1glZtxbywZSwykQKLGpOxykhhHosO+n1jCB2MwC 4hK3nsxngjhYQGLJnvPMELaoxMvH/1ghbCWJFdsvMULU50vcfbWSCWKXoMTJmU9YJjCKzkIy ahaSsllIymaB/aUpsX6XPkSJosSU7ofsELaGROucuezI4gsY2VcxihanFhfnphsZ66UWZSYX F+fn6eWllmxiBEbhwS2/dXcwrn7teIhRgINRiYd3wbVdoUKsiWXFlbmHGKU5WJTEeWdszgsV EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwNg0R3c5j43Zo8V3tpdOcChTutbhMcV0b5CV519V WyGNVxUL/VfvOzF9Lp+Jhlpnms+Cvbq/O1le/OvkU137oeDO+Q1H/CTFpb4v7167vF1r85Ib VVka4Xcu9tkKlW3ZEfdnvuqJSzFCm6ZnezYzdL6997PSQf7L7Za/iopfGZm2NxUV7zRwFlBi Kc5INNRiLipOBACDOo7oowIAAA== Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:41:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348E2D1BESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5TbywgYmFzaWNhbGx5LCBydGNwLW11eCBtdXN0IGJlIG9mZmVyZWQgYW5kIG11c3Qg YmUgYWNjZXB0ZWQgaWYgb2ZmZXJlZC4NCg0KWWVzLCB0aGF0IGlzIG15IG9waW5pb24gdG9vLiBB bmQg4oCcbXVzdCBiZSBvZmZlcmVk4oCdIG1lYW5zIGluY2x1ZGluZyB0aGUgU0RQIHJ0Y3AtbXV4 IGF0dHJpYnV0ZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B348E2D1BESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1Nv LCBiYXNpY2FsbHksIHJ0Y3AtbXV4IG11c3QgYmUgb2ZmZXJlZCBhbmQgbXVzdCBiZSBhY2NlcHRl ZCBpZiBvZmZlcmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlllcywgdGhhdCBpcyBteSBvcGluaW9uIHRvby4gQW5kIOKA nG11c3QgYmUgb2ZmZXJlZOKAnSBtZWFucyBpbmNsdWRpbmcgdGhlIFNEUCBydGNwLW11eCBhdHRy aWJ1dGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNocmlzdGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B348E2D1BESESSMB209erics_-- From nobody Fri Jul 31 11:43:50 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AD21B344B for ; Fri, 31 Jul 2015 11:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvGh9WDf92Wf for ; Fri, 31 Jul 2015 11:43:46 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743D11B343F for ; Fri, 31 Jul 2015 11:43:45 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-79-55bbc1df944f Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0F.87.25217.FD1CBB55; Fri, 31 Jul 2015 20:43:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0210.002; Fri, 31 Jul 2015 20:43:42 +0200 From: Christer Holmberg To: Bernard Aboba , Roman Shpount Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78thNOz8AYdMEys1nzX7WTf2J316g6A Date: Fri, 31 Jul 2015 18:43:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E2D52ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3Rvf+wd2hBjfPaFts2Pef2WLGhanM Fmv/tbM7MHvsnHWX3WPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlNM5tYStoCak4ubeNqYHx TmAXIyeHhICJxM+Xs5ggbDGJC/fWs3UxcnEICRxllNiy7S4rhLOYUaL14EagDAcHm4CFRPc/ bZAGEQE/iYaee+wgNrOApsSEZbvYQGxhAU+JW52LmSBqvCTWfb/GDGEbSXRdmwpWzyKgKrFg 1mywel4BX4lLvzYygthCAnfYJfb+LgaxOQVsJdY/ns4CYjMCHff91BomiF3iEreezIc6WkBi yZ7zzBC2qMTLx/9YIWwliRXbLzFC1OdLtF/rYILYJShxcuYTlgmMorOQjJqFpGwWkrJZQB+D vLZ+lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTG 38Etv612MB587niIUYCDUYmHd8G1XaFCrIllxZW5hxilOViUxHlnbM4LFRJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cCY7W7AK3Tk8eW6s3pTmoIqv3dbL/O+ltE/MyAtO/VsYIGXu4FERMQU fwEjmVmTdyjXLL/D6yG3al/S/HUZXk+u3H1ws1b/wn4v1ulJjjNZZmzKqzk6sUbDQHdSSN2t a6Ur3y39yvhdRpDti+SUj6v+2hz06m1Vd72b2vRGfVlJUqQ/p77I/34lluKMREMt5qLiRABJ X9uRoAIAAA== Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:43:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348E2D52ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklmIHdlIGNob29zZSB0byBtYW5kYXRlIHVzYWdlIG9mIHJ0Y3AtbXV4LCB3ZSBjb3Vs ZCBhbHNvIG1hbmRhdGUgZ2F0ZXdheXMgdG8gc3VwcG9ydCBpdC4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBCZXJuYXJkIEFib2JhDQpTZW50OiAzMSBKdWx5IDIwMTUgMjE6MzINClRvOiBS b21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4NCkNjOiA8cnRjd2ViQGlldGYub3JnPiA8 cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkg ZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpPbiBKdWwgMzEsIDIwMTUsIGF0 IDEwOjU3LCBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVs dXJpeC5jb20+PiB3cm90ZToNCg0KV2h5IHdvdWxkIHRoZSBnYXRld2F5IG5lZWQgdG8gbmVnb3Rp YXRlIG5vbi1tdXggaWYgcnRjcC1tdXggaXMgc3VwcG9ydGVkPw0KDQpbQkFdIElNSE8sIEdhdGV3 YXlzIHNob3VsZCBiZSByZXF1aXJlZCB0byBzdXBwb3J0IG11eCBsaWtlIGFueSBvdGhlciBXRUJS VEMgZW5kcG9pbnQsIGJ1dCB0aGlzIGlzIG5vdCB3aGF0IGl0IHNheXMgaW4gU2VjdGlvbiAyIG9m IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1nYXRld2F5cyA6 DQoNCg0KIklmIGEgZ2F0ZXdheSBzZXJ2ZXMgYXMgYSBtZWRpYSByZWxheSBpbnRvIGFub3RoZXIg UlRQIGRvbWFpbiwgaXQgTUFZIGNob29zZSB0byBzdXBwb3J0IG9ubHkgZmVhdHVyZXMgYXZhaWxh YmxlIGluIHRoYXQgbmV0d29yay4gVGhpcyBtZWFucyB0aGF0IGl0IE1BWSBjaG9vc2UgdG8gbm90 IHN1cHBvcnQgQnVuZGxlIGFuZCBhbnkgb2YgdGhlIFJUUC8gUlRDUCBleHRlbnNpb25zIHJlbGF0 ZWQgdG8gaXQsIFJUQ1AtTXV4LCBvciBUcmlja2xlIEljZS4gSG93ZXZlciwgdGhlIGdhdGV3YXkg TVVTVCBzdXBwb3J0IERUTFMtU1JUUCwgc2luY2UgdGhpcyBpcyByZXF1aXJlZCBmb3IgaW50ZXJ3 b3JraW5nIHdpdGggV2ViUlRDIGVuZHBvaW50cy4iDQoNCg0KQXNzdW1pbmcgdGhhdCBicm93c2Vy cyByZW1vdmUgb3IgZG8gbm90IGltcGxlbWVudCBub24tbXV4LCBpdCBzZWVtcyBwcnVkZW50IHRv IHJlcXVpcmUgZ2F0ZXdheXMgdG8gc3VwcG9ydCBtdXggc28gYXMgdG8gYXZvaWQgbmVnb3RpYXRp b24gZmFpbHVyZXMuIElmIHdlIG1ha2UgdGhhdCBjaGFuZ2UgdGhlbiBnYXRld2F5cyB3b3VsZCBh bHdheXMgbmVnb3RpYXRlIFJUQ1AtbXV4IHdpdGggYnJvd3NlcnMuDQo= --_000_7594FB04B1934943A5C02806D1A2204B348E2D52ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlVJQ1RGb250VGV4 dFN0eWxlQm9keTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SWYgd2UgY2hv b3NlIHRvIG1hbmRhdGUgdXNhZ2Ugb2YgcnRjcC1tdXgsIHdlIGNvdWxkIGFsc28gbWFuZGF0ZSBn YXRld2F5cyB0byBzdXBwb3J0IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNo cmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZXJuYXJkIEFib2JhPGJyPg0KPGI+U2VudDo8L2I+IDMx IEp1bHkgMjAxNSAyMTozMjxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hwb3VudCAmbHQ7cm9tYW5A dGVsdXJpeC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7cnRjd2ViQGlldGYub3JnJmd0OyAm bHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0g V2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAz MSwgMjAxNSwgYXQgMTA6NTcsIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21h bkB0ZWx1cml4LmNvbSI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5 IHdvdWxkIHRoZSBnYXRld2F5IG5lZWQgdG8gbmVnb3RpYXRlIG5vbi1tdXggaWYgcnRjcC1tdXgg aXMgc3VwcG9ydGVkPw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JBXSBJTUhPLCBHYXRld2F5cyBz aG91bGQgYmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBtdXggbGlrZSBhbnkgb3RoZXIgV0VCUlRDIGVu ZHBvaW50LCBidXQgdGhpcyBpcyBub3Qgd2hhdCBpdCBzYXlzIGluIFNlY3Rpb24gMiBvZg0KPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWdhdGV3 YXlzIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZ2F0ZXdh eXM8L2E+IDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlD VEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LHNlcmlmIj4mcXVvdDtJZiBhIGdhdGV3YXkgc2VydmVz IGFzIGEgbWVkaWEgcmVsYXkgaW50byBhbm90aGVyIFJUUCBkb21haW4sIGl0IE1BWSBjaG9vc2Ug dG8gc3VwcG9ydCBvbmx5IGZlYXR1cmVzIGF2YWlsYWJsZSBpbiB0aGF0IG5ldHdvcmsuIFRoaXMg bWVhbnMgdGhhdCBpdCBNQVkgY2hvb3NlIHRvIG5vdCBzdXBwb3J0IEJ1bmRsZSBhbmQgYW55IG9m IHRoZSBSVFAvIFJUQ1AgZXh0ZW5zaW9ucyByZWxhdGVkIHRvIGl0LCBSVENQLU11eCwgb3IgVHJp Y2tsZSBJY2UuIEhvd2V2ZXIsIHRoZSBnYXRld2F5IE1VU1Qgc3VwcG9ydCBEVExTLVNSVFAsIHNp bmNlIHRoaXMgaXMgcmVxdWlyZWQgZm9yIGludGVyd29ya2luZyB3aXRoIFdlYlJUQyBlbmRwb2lu dHMuJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssc2Vy aWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4 dFN0eWxlQm9keSZxdW90OyxzZXJpZiI+QXNzdW1pbmcgdGhhdCBicm93c2VycyByZW1vdmUgb3Ig ZG8gbm90IGltcGxlbWVudCBub24tbXV4LCBpdCBzZWVtcyBwcnVkZW50IHRvIHJlcXVpcmUgZ2F0 ZXdheXMgdG8gc3VwcG9ydCBtdXggc28gYXMgdG8gYXZvaWQgbmVnb3RpYXRpb24gZmFpbHVyZXMu IElmIHdlIG1ha2UgdGhhdCBjaGFuZ2UgdGhlbiBnYXRld2F5cyB3b3VsZCBhbHdheXMgbmVnb3Rp YXRlIFJUQ1AtbXV4IHdpdGggYnJvd3NlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B348E2D52ESESSMB209erics_-- From nobody Fri Jul 31 11:44:55 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E76C1B3454 for ; Fri, 31 Jul 2015 11:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKAwTKVKoIiy for ; Fri, 31 Jul 2015 11:44:52 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9732C1B344B for ; Fri, 31 Jul 2015 11:44:52 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t6VIimDZ022373 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 Jul 2015 18:44:48 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t6VIilBn029972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 20:44:47 +0200 Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 31 Jul 2015 20:44:47 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.210]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0248.002; Fri, 31 Jul 2015 20:44:46 +0200 From: "Rauschenbach, Uwe (Nokia - DE/Munich)" To: ext Christer Holmberg , Roman Shpount , Justin Uberti Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyvx73bfS+y+I40uNIW4Jcacvlp30w60AgAB5cYCAAAlpAIAAEkYAgAAd/QCAACs4gIAADI6AgAAB2oCAAARagIAAFMeAgAAhtVA= Date: Fri, 31 Jul 2015 18:44:46 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF8196FF34B@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B348E2D1B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348E2D1B@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.111] Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF8196FF34BDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8894 X-purgate-ID: 151667::1438368288-000063FD-BFDEA6D4/0/0 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:44:54 -0000 --_000_56C2F665D49E0341B9DF5938005ACDF8196FF34BDEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgY2FuIGFjY2VwdCDigJxtdXN0IGJlIG9mZmVyZWTigJ0uIEJ1dCBJIGRvIG5vdCB1 bmRlcnN0YW5kIOKAnG11c3QgYmUgYWNjZXB0ZWQgaWYgb2ZmZXJlZOKAnS4gVGhpcyBpcyBhZ2Fp bnN0IHRoZSBzcGlyaXQgb2YgbmVnb3RpYXRpb24uDQpJZiB0aGUgb3RoZXIgZW5kcG9pbnQgZG9l cyBub3Qgc3VwcG9ydCBydGNwLW11eCBpdCByZWplY3RzIHRoaXMuIEFtIEkgbWlzc2luZyBzb21l dGhpbmc/DQoNCktpbmQgcmVnYXJkcywNClV3ZQ0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBDaHJpc3RlciBIb2xtYmVyZw0K U2VudDogRnJpZGF5LCBKdWx5IDMxLCAyMDE1IDExOjQyIEFNDQpUbzogUm9tYW4gU2hwb3VudDsg SnVzdGluIFViZXJ0aQ0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gUHJvcG9zYWw6IHJlcXVpcmUgcnRjcC1tdXggKHJlbW92ZSBub24tbXV4ZWQgUlRDUDsgaXQg d291bGQgYmUgQ2hyaXN0bWFzIGluIEp1bHkhKQ0KDQpIaSwNCg0KPlNvLCBiYXNpY2FsbHksIHJ0 Y3AtbXV4IG11c3QgYmUgb2ZmZXJlZCBhbmQgbXVzdCBiZSBhY2NlcHRlZCBpZiBvZmZlcmVkLg0K DQpZZXMsIHRoYXQgaXMgbXkgb3BpbmlvbiB0b28uIEFuZCDigJxtdXN0IGJlIG9mZmVyZWTigJ0g bWVhbnMgaW5jbHVkaW5nIHRoZSBTRFAgcnRjcC1tdXggYXR0cmlidXRlLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQoNCg== --_000_56C2F665D49E0341B9DF5938005ACDF8196FF34BDEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkg Y2FuIGFjY2VwdCDigJxtdXN0IGJlIG9mZmVyZWTigJ0uIEJ1dCBJIGRvIG5vdCB1bmRlcnN0YW5k IOKAnG11c3QgYmUgYWNjZXB0ZWQgaWYgb2ZmZXJlZOKAnS4gVGhpcyBpcyBhZ2FpbnN0IHRoZSBz cGlyaXQgb2YgbmVnb3RpYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgdGhlIG90aGVyIGVuZHBvaW50 IGRvZXMgbm90IHN1cHBvcnQgcnRjcC1tdXggaXQgcmVqZWN0cyB0aGlzLiBBbSBJIG1pc3Npbmcg c29tZXRoaW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPktpbmQgcmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Vd2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFtt YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPmV4dCBD aHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMzEsIDIwMTUg MTE6NDIgQU08YnI+DQo8Yj5Ubzo8L2I+IFJvbWFuIFNocG91bnQ7IEp1c3RpbiBVYmVydGk8YnI+ DQo8Yj5DYzo8L2I+ICZsdDtydGN3ZWJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbcnRjd2ViXSBQcm9wb3NhbDogcmVxdWlyZSBydGNwLW11eCAocmVtb3ZlIG5vbi1tdXhl ZCBSVENQOyBpdCB3b3VsZCBiZSBDaHJpc3RtYXMgaW4gSnVseSEpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7U28sIGJhc2ljYWxseSwg cnRjcC1tdXggbXVzdCBiZSBvZmZlcmVkIGFuZCBtdXN0IGJlIGFjY2VwdGVkIGlmIG9mZmVyZWQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+WWVzLCB0aGF0IGlzIG15IG9waW5pb24gdG9vLiBBbmQg4oCcbXVzdCBiZSBvZmZl cmVk4oCdIG1lYW5zIGluY2x1ZGluZyB0aGUgU0RQIHJ0Y3AtbXV4IGF0dHJpYnV0ZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_56C2F665D49E0341B9DF5938005ACDF8196FF34BDEMUMBX005nsnin_-- From nobody Fri Jul 31 11:45:35 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0361B3454 for ; Fri, 31 Jul 2015 11:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSr-X6DxPRBB for ; Fri, 31 Jul 2015 11:45:32 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08611B3475 for ; Fri, 31 Jul 2015 11:45:15 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t6VIjC51004322 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 Jul 2015 18:45:12 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t6VIjBRs032436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 20:45:11 +0200 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 31 Jul 2015 20:45:11 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.210]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0248.002; Fri, 31 Jul 2015 20:45:11 +0200 From: "Rauschenbach, Uwe (Nokia - DE/Munich)" To: ext Bernard Aboba , Roman Shpount Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78tkj01AbA0AUWp46tuxkqao5316WFA Date: Fri, 31 Jul 2015 18:45:10 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF8196FF36A@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.111] Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF8196FF36ADEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 9748 X-purgate-ID: 151667::1438368312-000058E2-45088C3C/0/0 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:45:34 -0000 --_000_56C2F665D49E0341B9DF5938005ACDF8196FF36ADEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBzYXkgdGhhdCB0byBpbnRlcndvcmsgd2l0aCBsZWdhY3kgbmV0d29ya3MsIGJyb3dz ZXJzIG5lZWQgdG8gaW1wbGVtZW50IG5vbi1tdXguIFdoZXRoZXIgb3Igbm90IGl0IGlzIGFjdHVh bGx5IG5lZ290aWF0ZWQgaXMgYSBkaWZmZXJlbnQgc3RvcnkuDQoNCktpbmQgcmVnYXJkcywNClV3 ZQ0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIGV4dCBCZXJuYXJkIEFib2JhDQpTZW50OiBGcmlkYXksIEp1bHkgMzEsIDIwMTUgMTE6 MzIgQU0NClRvOiBSb21hbiBTaHBvdW50DQpDYzogPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4 L25vbi1tdXgNCg0KT24gSnVsIDMxLCAyMDE1LCBhdCAxMDo1NywgUm9tYW4gU2hwb3VudCA8cm9t YW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQoNCldoeSB3 b3VsZCB0aGUgZ2F0ZXdheSBuZWVkIHRvIG5lZ290aWF0ZSBub24tbXV4IGlmIHJ0Y3AtbXV4IGlz IHN1cHBvcnRlZD8NCg0KW0JBXSBJTUhPLCBHYXRld2F5cyBzaG91bGQgYmUgcmVxdWlyZWQgdG8g c3VwcG9ydCBtdXggbGlrZSBhbnkgb3RoZXIgV0VCUlRDIGVuZHBvaW50LCBidXQgdGhpcyBpcyBu b3Qgd2hhdCBpdCBzYXlzIGluIFNlY3Rpb24gMiBvZiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZ2F0ZXdheXMgOg0KDQoNCiJJZiBhIGdhdGV3YXkgc2VydmVz IGFzIGEgbWVkaWEgcmVsYXkgaW50byBhbm90aGVyIFJUUCBkb21haW4sIGl0IE1BWSBjaG9vc2Ug dG8gc3VwcG9ydCBvbmx5IGZlYXR1cmVzIGF2YWlsYWJsZSBpbiB0aGF0IG5ldHdvcmsuIFRoaXMg bWVhbnMgdGhhdCBpdCBNQVkgY2hvb3NlIHRvIG5vdCBzdXBwb3J0IEJ1bmRsZSBhbmQgYW55IG9m IHRoZSBSVFAvIFJUQ1AgZXh0ZW5zaW9ucyByZWxhdGVkIHRvIGl0LCBSVENQLU11eCwgb3IgVHJp Y2tsZSBJY2UuIEhvd2V2ZXIsIHRoZSBnYXRld2F5IE1VU1Qgc3VwcG9ydCBEVExTLVNSVFAsIHNp bmNlIHRoaXMgaXMgcmVxdWlyZWQgZm9yIGludGVyd29ya2luZyB3aXRoIFdlYlJUQyBlbmRwb2lu dHMuIg0KDQoNCkFzc3VtaW5nIHRoYXQgYnJvd3NlcnMgcmVtb3ZlIG9yIGRvIG5vdCBpbXBsZW1l bnQgbm9uLW11eCwgaXQgc2VlbXMgcHJ1ZGVudCB0byByZXF1aXJlIGdhdGV3YXlzIHRvIHN1cHBv cnQgbXV4IHNvIGFzIHRvIGF2b2lkIG5lZ290aWF0aW9uIGZhaWx1cmVzLiBJZiB3ZSBtYWtlIHRo YXQgY2hhbmdlIHRoZW4gZ2F0ZXdheXMgd291bGQgYWx3YXlzIG5lZ290aWF0ZSBSVENQLW11eCB3 aXRoIGJyb3dzZXJzLg0K --_000_56C2F665D49E0341B9DF5938005ACDF8196FF36ADEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlVJQ1RGb250VGV4dFN0eWxlQm9keTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkg d291bGQgc2F5IHRoYXQgdG8gaW50ZXJ3b3JrIHdpdGggbGVnYWN5IG5ldHdvcmtzLCBicm93c2Vy cyBuZWVkIHRvIGltcGxlbWVudCBub24tbXV4LiBXaGV0aGVyIG9yIG5vdCBpdCBpcyBhY3R1YWxs eSBuZWdvdGlhdGVkIGlzIGEgZGlmZmVyZW50IHN0b3J5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Vd2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPmV4dCBCZXJuYXJkIEFib2JhPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgSnVseSAzMSwgMjAxNSAxMTozMiBBTTxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hwb3Vu dDxicj4NCjxiPkNjOjwvYj4gJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91 dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBKdWwgMzEsIDIwMTUsIGF0IDEwOjU3LCBSb21hbiBTaHBvdW50ICZsdDs8 YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldoeSB3b3VsZCB0aGUgZ2F0ZXdheSBuZWVkIHRvIG5lZ290aWF0ZSBu b24tbXV4IGlmIHJ0Y3AtbXV4IGlzIHN1cHBvcnRlZD8NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltC QV0gSU1ITywgR2F0ZXdheXMgc2hvdWxkIGJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgbXV4IGxpa2Ug YW55IG90aGVyIFdFQlJUQyBlbmRwb2ludCwgYnV0IHRoaXMgaXMgbm90IHdoYXQgaXQgc2F5cyBp biBTZWN0aW9uIDIgb2YNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXJ0Y3dlYi1nYXRld2F5cyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcnRjd2ViLWdhdGV3YXlzPC9hPiA6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+JnF1b3Q7SWYgYSBnYXRld2F5IHNlcnZlcyBhcyBhIG1lZGlhIHJlbGF5IGludG8gYW5v dGhlciBSVFAgZG9tYWluLCBpdCBNQVkgY2hvb3NlIHRvIHN1cHBvcnQgb25seSBmZWF0dXJlcyBh dmFpbGFibGUgaW4gdGhhdCBuZXR3b3JrLiBUaGlzIG1lYW5zIHRoYXQgaXQgTUFZIGNob29zZSB0 byBub3Qgc3VwcG9ydCBCdW5kbGUgYW5kIGFueSBvZiB0aGUgUlRQLyBSVENQIGV4dGVuc2lvbnMg cmVsYXRlZCB0byBpdCwgUlRDUC1NdXgsIG9yIFRyaWNrbGUgSWNlLiBIb3dldmVyLCB0aGUgZ2F0 ZXdheSBNVVNUIHN1cHBvcnQgRFRMUy1TUlRQLCBzaW5jZSB0aGlzIGlzIHJlcXVpcmVkIGZvciBp bnRlcndvcmtpbmcgd2l0aCBXZWJSVEMgZW5kcG9pbnRzLiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnIgY2xlYXI9 ImFsbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8L3NwYW4+DQo8cHJlIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkFzc3Vt aW5nIHRoYXQgYnJvd3NlcnMgcmVtb3ZlIG9yIGRvIG5vdCBpbXBsZW1lbnQgbm9uLW11eCwgaXQg c2VlbXMgcHJ1ZGVudCB0byByZXF1aXJlIGdhdGV3YXlzIHRvIHN1cHBvcnQgbXV4IHNvIGFzIHRv IGF2b2lkIG5lZ290aWF0aW9uIGZhaWx1cmVzLiBJZiB3ZSBtYWtlIHRoYXQgY2hhbmdlIHRoZW4g Z2F0ZXdheXMgd291bGQgYWx3YXlzIG5lZ290aWF0ZSBSVENQLW11eCB3aXRoIGJyb3dzZXJzLjwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_56C2F665D49E0341B9DF5938005ACDF8196FF36ADEMUMBX005nsnin_-- From nobody Fri Jul 31 11:47:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FAA1B3482 for ; Fri, 31 Jul 2015 11:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDq_OJZOqwn3 for ; Fri, 31 Jul 2015 11:47:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3771B347A for ; Fri, 31 Jul 2015 11:47:14 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6VIl8Vr010793 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 31 Jul 2015 13:47:09 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55BBC2AC.9060100@nostrum.com> Date: Fri, 31 Jul 2015 13:47:08 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Justin Uberti , Roman Shpount References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:47:15 -0000 On 7/31/15 11:44, Justin Uberti wrote: > On the Chrome side, we have taken the concrete step of allowing this > functionality to be controlled via a Chrome extension: > https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia/reviews?hl=en > > We are still sorting out some issues, which is why it is currently > opt-in (i.e., an extension). However, we expect to have a more > comprehensive solution in the near future. Mozilla is taking the same approach for Firefox; for details, see: https://groups.google.com/forum/#!topic/mozilla.dev.media/L6Rx9ubSjMc /a From nobody Fri Jul 31 11:49:31 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1641B3482 for ; Fri, 31 Jul 2015 11:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFnfZtztmkOX for ; Fri, 31 Jul 2015 11:49:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0665.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:665]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679DD1B3499 for ; Fri, 31 Jul 2015 11:49:26 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 31 Jul 2015 18:49:21 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Fri, 31 Jul 2015 18:49:21 +0000 From: "Asveren, Tolga" To: Christer Holmberg , Bernard Aboba , Roman Shpount Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQ Date: Fri, 31 Jul 2015 18:49:21 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:N30g3O34GzTGe8N/ht1+sm7Tv6NjldoOAZXBPa3qRI2OlfIj2J2mKoPCyE5/EkPWe0QP9iMjdkfLaJwUJwTataGuHyPxzCXyxxm1bQxHOJiCrGD1BdaDK+SElb0WSrhV2Z3NTYu6Zi1BJHASrObfaw==; 24:jEBre4kLJGEOl5T1b/ed6YnSqyo+TnQm+mGdeMcFir0lrOnwn+9EoEO7IUKJPrqJEnJ/2a6vyGj6O5zA6NR2rCH4Y4nQmIUMfVtvepHqxFs=; 20:QVr5Y+hEcd8WAapbFiMirIdk1l8Drpufr+IvRxcdNEOHog6z5MOeE0RUyW4skhimTJG2GwcAuC/T37Xh5Gp/Zg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; sn1pr0301mb1551: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(377454003)(66066001)(76576001)(74316001)(2656002)(86362001)(2900100001)(87936001)(62966003)(106116001)(77096005)(40100003)(102836002)(92566002)(5002640100001)(93886004)(76176999)(15975445007)(50986999)(54356999)(99286002)(2950100001)(19580395003)(46102003)(33656002)(5001770100001)(5003600100002)(77156002)(122556002)(5001960100002)(19617315012)(19625215002)(5001920100001)(16236675004)(19580405001)(19300405004)(19609705001)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB155145AE63D5EF3CF2DF5B2AB28A0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 18:49:21.1038 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:49:30 -0000 --_000_SN1PR0301MB155145AE63D5EF3CF2DF5B2AB28A0SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB5b3UgKmNvdWxkKiBtYW5kYXRlIHRoZSB3aG9sZSB1bml2ZXJzZSB0byBzdXBwb3J0IGl0 LCB0aGF0IHNob3VsZG7igJl0IGJlIHRvbyBkaWZmaWN1bHQgdG8gZGVzY3JpYmUgb24gcGFwZXIg Oy0pDQoNCk9UT0gsIHdoeT8gSWYgdGhlcmUgYXJlIGZvbGtzLCBmb3Igd2hvbSBuby1ydGNwLW11 eCBpcyBqdXN0IGZpbmUgKGZvciB3aGF0ZXZlciByZWFzb24pLCBsZXQgdGhlaXIgaW1wbGVtZW50 YXRpb25zIGZ1bmN0aW9uIHRoYXQgd2F5IChhbmQgbGV0IHRoZW0gc3VmZmVyIGlmIHRoaXMgaXMg cmVhbGx5IHN1Y2ggYSB0ZXJyaWJsZSB0aGluZyBmcm9tIGltcGxlbWVudGF0aW9uIGRpZmZpY3Vs dHkgcGVyc3BlY3RpdmUpLiBBbmQgaXQgd2lsbCBiZSB0aGVpciBwcm9ibGVtIGlmIHRoYXQgY2F1 c2VzIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIGZvciB0aGVtLCBlLmcuIHRoZXkgd29u4oCZdCBi ZSBhYmxlIHRvIHRhbGsgdG8gYnJvd3NlcnMsIHdoaWNoIG1hbmRhdGUgdXNlIG9mIHJ0Y3AtbXV4 Lg0KDQpCcm93c2VycyAob3IgYW55IG90aGVyIGltcGxlbWVudGF0aW9uKSBhbHdheXMgbWFuZGF0 ZSB1c2Ugb2YgcnRjcC1tdXggYnkgYWx3YXlzIG9mZmVyaW5nIGl0IGFuZCB0ZXJtaW5hdGluZyBh IHNlc3Npb24gaWYgdGhlIGFuc3dlciBpbmRpY2F0ZXMgbm8gcnRjcC1tdXggc3VwcG9ydC4gU2lt aWxhcmx5LCB0aGV5IGNhbiByZWplY3Qgb2ZmZXJzIHdpdGggcnRjcC1tdXguDQoNClRoYW5rcywN ClRvbGdhDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IEZyaWRheSwgSnVseSAzMSwgMjAx NSAyOjQ0IFBNDQpUbzogQmVybmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+OyBS b21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4NCkNjOiA8cnRjd2ViQGlldGYub3JnPiA8 cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkg ZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpIaSwNCg0KSWYgd2UgY2hvb3Nl IHRvIG1hbmRhdGUgdXNhZ2Ugb2YgcnRjcC1tdXgsIHdlIGNvdWxkIGFsc28gbWFuZGF0ZSBnYXRl d2F5cyB0byBzdXBwb3J0IGl0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBydGN3 ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlcm5hcmQg QWJvYmENClNlbnQ6IDMxIEp1bHkgMjAxNSAyMTozMg0KVG86IFJvbWFuIFNocG91bnQgPHJvbWFu QHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+DQpDYzogPHJ0Y3dlYkBpZXRm Lm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4gPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRj d2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRy YWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KT24gSnVsIDMxLCAyMDE1LCBhdCAx MDo1NywgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVy aXguY29tPj4gd3JvdGU6DQoNCldoeSB3b3VsZCB0aGUgZ2F0ZXdheSBuZWVkIHRvIG5lZ290aWF0 ZSBub24tbXV4IGlmIHJ0Y3AtbXV4IGlzIHN1cHBvcnRlZD8NCg0KW0JBXSBJTUhPLCBHYXRld2F5 cyBzaG91bGQgYmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBtdXggbGlrZSBhbnkgb3RoZXIgV0VCUlRD IGVuZHBvaW50LCBidXQgdGhpcyBpcyBub3Qgd2hhdCBpdCBzYXlzIGluIFNlY3Rpb24gMiBvZiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZ2F0ZXdheXMgOg0K DQoNCiJJZiBhIGdhdGV3YXkgc2VydmVzIGFzIGEgbWVkaWEgcmVsYXkgaW50byBhbm90aGVyIFJU UCBkb21haW4sIGl0IE1BWSBjaG9vc2UgdG8gc3VwcG9ydCBvbmx5IGZlYXR1cmVzIGF2YWlsYWJs ZSBpbiB0aGF0IG5ldHdvcmsuIFRoaXMgbWVhbnMgdGhhdCBpdCBNQVkgY2hvb3NlIHRvIG5vdCBz dXBwb3J0IEJ1bmRsZSBhbmQgYW55IG9mIHRoZSBSVFAvIFJUQ1AgZXh0ZW5zaW9ucyByZWxhdGVk IHRvIGl0LCBSVENQLU11eCwgb3IgVHJpY2tsZSBJY2UuIEhvd2V2ZXIsIHRoZSBnYXRld2F5IE1V U1Qgc3VwcG9ydCBEVExTLVNSVFAsIHNpbmNlIHRoaXMgaXMgcmVxdWlyZWQgZm9yIGludGVyd29y a2luZyB3aXRoIFdlYlJUQyBlbmRwb2ludHMuIg0KDQoNCkFzc3VtaW5nIHRoYXQgYnJvd3NlcnMg cmVtb3ZlIG9yIGRvIG5vdCBpbXBsZW1lbnQgbm9uLW11eCwgaXQgc2VlbXMgcHJ1ZGVudCB0byBy ZXF1aXJlIGdhdGV3YXlzIHRvIHN1cHBvcnQgbXV4IHNvIGFzIHRvIGF2b2lkIG5lZ290aWF0aW9u IGZhaWx1cmVzLiBJZiB3ZSBtYWtlIHRoYXQgY2hhbmdlIHRoZW4gZ2F0ZXdheXMgd291bGQgYWx3 YXlzIG5lZ290aWF0ZSBSVENQLW11eCB3aXRoIGJyb3dzZXJzLg0K --_000_SN1PR0301MB155145AE63D5EF3CF2DF5B2AB28A0SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlVJQ1RGb250VGV4 dFN0eWxlQm9keTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlllcywgeW91ICo8Yj5jb3VsZDwv Yj4qIG1hbmRhdGUgdGhlIHdob2xlIHVuaXZlcnNlIHRvIHN1cHBvcnQgaXQsIHRoYXQgc2hvdWxk buKAmXQgYmUgdG9vIGRpZmZpY3VsdCB0byBkZXNjcmliZSBvbiBwYXBlciA7LSk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9UT0gsIHdoeT8gSWYgdGhlcmUgYXJl IGZvbGtzLCBmb3Igd2hvbSBuby1ydGNwLW11eCBpcyBqdXN0IGZpbmUgKGZvciB3aGF0ZXZlciBy ZWFzb24pLCBsZXQgdGhlaXIgaW1wbGVtZW50YXRpb25zIGZ1bmN0aW9uIHRoYXQgd2F5IChhbmQg bGV0IHRoZW0gc3VmZmVyIGlmIHRoaXMNCiBpcyByZWFsbHkgc3VjaCBhIHRlcnJpYmxlIHRoaW5n IGZyb20gaW1wbGVtZW50YXRpb24gZGlmZmljdWx0eSBwZXJzcGVjdGl2ZSkuIEFuZCBpdCB3aWxs IGJlIHRoZWlyIHByb2JsZW0gaWYgdGhhdCBjYXVzZXMgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMg Zm9yIHRoZW0sIGUuZy4gdGhleSB3b27igJl0IGJlIGFibGUgdG8gdGFsayB0byBicm93c2Vycywg d2hpY2ggbWFuZGF0ZSB1c2Ugb2YgcnRjcC1tdXguDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkJyb3dzZXJzIChvciBhbnkgb3RoZXIgaW1wbGVtZW50YXRpb24p IGFsd2F5cyBtYW5kYXRlIHVzZSBvZiBydGNwLW11eCBieSBhbHdheXMgb2ZmZXJpbmcgaXQgYW5k IHRlcm1pbmF0aW5nIGEgc2Vzc2lvbiBpZiB0aGUgYW5zd2VyIGluZGljYXRlcyBubyBydGNwLW11 eCBzdXBwb3J0Lg0KIFNpbWlsYXJseSwgdGhleSBjYW4gcmVqZWN0IG9mZmVycyB3aXRoIHJ0Y3At bXV4LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIgW21haWx0bzpydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDMxLCAyMDE1IDI6NDQgUE08YnI+DQo8Yj5U bzo8L2I+IEJlcm5hcmQgQWJvYmEgJmx0O2Jlcm5hcmQuYWJvYmFAZ21haWwuY29tJmd0OzsgUm9t YW4gU2hwb3VudCAmbHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7 cnRjd2ViQGlldGYub3JnJmd0OyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFi b3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SWYgd2UgY2hvb3NlIHRvIG1hbmRhdGUgdXNhZ2Ugb2YgcnRjcC1tdXgsIHdlIGNv dWxkIGFsc28gbWFuZGF0ZSBnYXRld2F5cyB0byBzdXBwb3J0IGl0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PC9hPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHJ0 Y3dlYiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZXJuYXJkIEFi b2JhPGJyPg0KPGI+U2VudDo8L2I+IDMxIEp1bHkgMjAxNSAyMTozMjxicj4NCjxiPlRvOjwvYj4g Um9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIj5yb21h bkB0ZWx1cml4LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkg YWJvdXQgbXV4L25vbi1tdXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+T24gSnVsIDMxLCAyMDE1LCBhdCAxMDo1NywgUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+V2h5IHdvdWxkIHRoZSBnYXRld2F5IG5lZWQgdG8gbmVnb3RpYXRlIG5vbi1tdXggaWYgcnRj cC1tdXggaXMgc3VwcG9ydGVkPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPltCQV0gSU1ITywgR2F0ZXdheXMg c2hvdWxkIGJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgbXV4IGxpa2UgYW55IG90aGVyIFdFQlJUQyBl bmRwb2ludCwgYnV0IHRoaXMgaXMgbm90IHdoYXQgaXQgc2F5cyBpbiBTZWN0aW9uIDIgb2YNCjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1nYXRl d2F5cyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWdhdGV3 YXlzPC9hPiA6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTpVSUNURm9udFRleHRTdHlsZUJv ZHkiPiZxdW90O0lmIGEgZ2F0ZXdheSBzZXJ2ZXMgYXMgYSBtZWRpYSByZWxheSBpbnRvIGFub3Ro ZXIgUlRQIGRvbWFpbiwgaXQgTUFZIGNob29zZSB0byBzdXBwb3J0IG9ubHkgZmVhdHVyZXMgYXZh aWxhYmxlIGluIHRoYXQgbmV0d29yay4gVGhpcyBtZWFucyB0aGF0IGl0IE1BWSBjaG9vc2UgdG8g bm90IHN1cHBvcnQgQnVuZGxlIGFuZCBhbnkgb2YgdGhlIFJUUC8gUlRDUCBleHRlbnNpb25zIHJl bGF0ZWQgdG8gaXQsIFJUQ1AtTXV4LCBvciBUcmlja2xlIEljZS4gSG93ZXZlciwgdGhlIGdhdGV3 YXkgTVVTVCBzdXBwb3J0IERUTFMtU1JUUCwgc2luY2UgdGhpcyBpcyByZXF1aXJlZCBmb3IgaW50 ZXJ3b3JraW5nIHdpdGggV2ViUlRDIGVuZHBvaW50cy4mcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlQm9keTttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OlVJQ1RGb250VGV4 dFN0eWxlQm9keSI+QXNzdW1pbmcgdGhhdCBicm93c2VycyByZW1vdmUgb3IgZG8gbm90IGltcGxl bWVudCBub24tbXV4LCBpdCBzZWVtcyBwcnVkZW50IHRvIHJlcXVpcmUgZ2F0ZXdheXMgdG8gc3Vw cG9ydCBtdXggc28gYXMgdG8gYXZvaWQgbmVnb3RpYXRpb24gZmFpbHVyZXMuIElmIHdlIG1ha2Ug dGhhdCBjaGFuZ2UgdGhlbiBnYXRld2F5cyB3b3VsZCBhbHdheXMgbmVnb3RpYXRlIFJUQ1AtbXV4 IHdpdGggYnJvd3NlcnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB155145AE63D5EF3CF2DF5B2AB28A0SN1PR0301MB1551_-- From nobody Fri Jul 31 11:57:53 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E001B2E2F for ; Fri, 31 Jul 2015 11:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHWEcZu8VCH9 for ; Fri, 31 Jul 2015 11:57:51 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E5C1B2E32 for ; Fri, 31 Jul 2015 11:57:51 -0700 (PDT) Received: by ioeg141 with SMTP id g141so94614845ioe.3 for ; Fri, 31 Jul 2015 11:57:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YJj+rry/p3WDR6vAeNnqlCRs4v1gHLA3CLNYFmEMMdE=; b=f3FG8E2XCCLMLTox+8qM9Zf9hpQCCmqsAqKdYNWHDcsTEU9XiBhPLaao+hQkDIVS3m djNPrPAOyoq/Mdo77Zzi8nSCOYhirfbd0qEZ1fleD5nUZEvxb2mssn5F9m0XMGhk5a+L rV3EbrhadiEG5DjbXZL7U304CCnSlPSZiB3SUwLUeFHAGzAqrSD5vUh6rPxiIr1HJ0wJ PL5qsOqjr+xybg3uS29oHuzlrAlflvxC6sZtd12L2Rvc8aZ7oZI+F2apyF90Naw1HCGa w4M5VXTAeJr6Qka0vl1m5+VHffCV37Mram8HGKrNTY8s9oYAgyd1YhSHz+BiU07K3wYH H0ZQ== X-Gm-Message-State: ALoCoQm2qhMxfbDx3w6bnAhed5cc/F7Zf7hkx3oya46im2Otzflxz6iGXiTtHfnXjhS21o4mdLSc X-Received: by 10.107.34.81 with SMTP id i78mr7848870ioi.40.1438369070453; Fri, 31 Jul 2015 11:57:50 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com. [209.85.213.182]) by smtp.gmail.com with ESMTPSA id kk9sm2896615igb.7.2015.07.31.11.57.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 11:57:49 -0700 (PDT) Received: by igr7 with SMTP id 7so22220924igr.0 for ; Fri, 31 Jul 2015 11:57:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.61.179 with SMTP id q19mr8766280igr.24.1438369068651; Fri, 31 Jul 2015 11:57:48 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Fri, 31 Jul 2015 11:57:48 -0700 (PDT) In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF8196FF36A@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <56C2F665D49E0341B9DF5938005ACDF8196FF36A@DEMUMBX005.nsn-intra.net> Date: Fri, 31 Jul 2015 14:57:48 -0400 Message-ID: From: Roman Shpount To: "Rauschenbach, Uwe (Nokia - DE/Munich)" Content-Type: multipart/alternative; boundary=047d7bdc109e649f52051c3065ee Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:57:52 -0000 --047d7bdc109e649f52051c3065ee Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 2:45 PM, Rauschenbach, Uwe (Nokia - DE/Munich) < uwe.rauschenbach@nokia.com> wrote: > I would say that to interwork with legacy networks, browsers need to > implement non-mux. Whether or not it is actually negotiated is a different > story. > > > Can you provide an example of a legacy network that implements DTLS-SRTP and does not implement rtcp-mux? >From my point of view this is no different that requirement to support ICE. This is supposed to be negotiated as well, but failure to negotiate ICE with WebRTC end point will cause connection to fail. I think suggestion here is that rtcp-mux should be treated the same. _____________ Roman Shpount --047d7bdc109e649f52051c3065ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 31, 2015 at 2:45 PM, Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com> wrote:

I would say that to interwork with legacy= networks, browsers need to implement non-mux. Whether or not it is actuall= y negotiated is a different story.=C2=A0



Can you provide an example of a legacy network that implements DTLS-SRTP a= nd does not implement rtcp-mux?

From my point of v= iew this is no different that requirement to support ICE. This is supposed = to be negotiated as well, but failure to negotiate ICE with WebRTC end poin= t will cause connection to fail. I think suggestion here is that rtcp-mux s= hould be treated the same.
_______= ______
Roman Shpount
=C2=A0
--047d7bdc109e649f52051c3065ee-- From nobody Fri Jul 31 11:58:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970F81B2F49 for ; Fri, 31 Jul 2015 11:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn9zYx4rmIDp for ; Fri, 31 Jul 2015 11:58:16 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F691B2E2F for ; Fri, 31 Jul 2015 11:58:15 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t6VIw9iE009326 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 Jul 2015 18:58:09 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t6VIw9hi015659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 20:58:09 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 31 Jul 2015 20:58:09 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.210]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0248.002; Fri, 31 Jul 2015 20:58:09 +0200 From: "Rauschenbach, Uwe (Nokia - DE/Munich)" To: "ext Asveren, Tolga" , Christer Holmberg , Bernard Aboba , Roman Shpount Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78tkj01AbA0AUWp46tuxkqao531yJ8AgAABlICAACJYIA== Date: Fri, 31 Jul 2015 18:58:07 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.111] Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF8196FF3EDDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 22760 X-purgate-ID: 151667::1438369090-000063FD-45928A0D/0/0 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:58:18 -0000 --_000_56C2F665D49E0341B9DF5938005ACDF8196FF3EDDEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbDogbm9uLW11eCBpcyBub3QgYSDigJxuZXcgdGhpbmfigJ0gdGhhdCB3ZSBtYW5kYXRlIHRo ZSB3aG9sZSB1bml2ZXJzZSB0byBzdXBwb3J0IOKAkyBpdCBpcyBvbiB0aGUgY29udHJhcnkgdGhl IHdheSBSVENQL1JUUCB1c2VkIHRvIGZ1bmN0aW9uIHNpbmNlIHRoZSBiZWdpbm5pbmcuDQpNVVhp bmcgaXMgdGhlIOKAnG5ldyB0aGluZ+KAnS4NCg0KT2YgY291cnNlIHlvdSBjYW4gdGFrZSBhd2F5 IGxlZ2FjeSBzdXBwb3J0IGlmIG5vLW9uZSBpcyBpbnRlcmVzdGVkIGluIHN1cHBvcnRpbmcgaXQg YW55bW9yZS4NCg0KSSB0aGluayB0aGlzIGlzIHRoZSBjb3JlIG9mIHRoZSBkaXNjdXNzaW9uIHRo YXQgd2UgYXJlIGhhdmluZyDigJMgZG8gd2Ugd2FudCB0byByZXRpcmUgdGhlIG9yaWdpbmFsIHdh eSBSVFArUlRDUCB3ZXJlIHdvcmtpbmcgdy5yLnQuIHBvcnQgdXNhZ2U/DQpJIGhhdmUgbXkgZG91 YnRzIChmb3IgdGhlIHRpbWUgYmVpbmcpLg0KDQpLaW5kIHJlZ2FyZHMsDQpVd2UNCg0KRnJvbTog cnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQg QXN2ZXJlbiwgVG9sZ2ENClNlbnQ6IEZyaWRheSwgSnVseSAzMSwgMjAxNSAxMTo0OSBBTQ0KVG86 IENocmlzdGVyIEhvbG1iZXJnOyBCZXJuYXJkIEFib2JhOyBSb21hbiBTaHBvdW50DQpDYzogPHJ0 Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRy YWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KWWVzLCB5b3UgKmNvdWxkKiBtYW5k YXRlIHRoZSB3aG9sZSB1bml2ZXJzZSB0byBzdXBwb3J0IGl0LCB0aGF0IHNob3VsZG7igJl0IGJl IHRvbyBkaWZmaWN1bHQgdG8gZGVzY3JpYmUgb24gcGFwZXIgOy0pDQoNCk9UT0gsIHdoeT8gSWYg dGhlcmUgYXJlIGZvbGtzLCBmb3Igd2hvbSBuby1ydGNwLW11eCBpcyBqdXN0IGZpbmUgKGZvciB3 aGF0ZXZlciByZWFzb24pLCBsZXQgdGhlaXIgaW1wbGVtZW50YXRpb25zIGZ1bmN0aW9uIHRoYXQg d2F5IChhbmQgbGV0IHRoZW0gc3VmZmVyIGlmIHRoaXMgaXMgcmVhbGx5IHN1Y2ggYSB0ZXJyaWJs ZSB0aGluZyBmcm9tIGltcGxlbWVudGF0aW9uIGRpZmZpY3VsdHkgcGVyc3BlY3RpdmUpLiBBbmQg aXQgd2lsbCBiZSB0aGVpciBwcm9ibGVtIGlmIHRoYXQgY2F1c2VzIGludGVyb3BlcmFiaWxpdHkg aXNzdWVzIGZvciB0aGVtLCBlLmcuIHRoZXkgd29u4oCZdCBiZSBhYmxlIHRvIHRhbGsgdG8gYnJv d3NlcnMsIHdoaWNoIG1hbmRhdGUgdXNlIG9mIHJ0Y3AtbXV4Lg0KDQpCcm93c2VycyAob3IgYW55 IG90aGVyIGltcGxlbWVudGF0aW9uKSBhbHdheXMgbWFuZGF0ZSB1c2Ugb2YgcnRjcC1tdXggYnkg YWx3YXlzIG9mZmVyaW5nIGl0IGFuZCB0ZXJtaW5hdGluZyBhIHNlc3Npb24gaWYgdGhlIGFuc3dl ciBpbmRpY2F0ZXMgbm8gcnRjcC1tdXggc3VwcG9ydC4gU2ltaWxhcmx5LCB0aGV5IGNhbiByZWpl Y3Qgb2ZmZXJzIHdpdGggcnRjcC1tdXguDQoNClRoYW5rcywNClRvbGdhDQoNCkZyb206IHJ0Y3dl YiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIg SG9sbWJlcmcNClNlbnQ6IEZyaWRheSwgSnVseSAzMSwgMjAxNSAyOjQ0IFBNDQpUbzogQmVybmFy ZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21h aWwuY29tPj47IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0 ZWx1cml4LmNvbT4+DQpDYzogPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3Jn Pj4gPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25v bi1tdXgNCg0KSGksDQoNCklmIHdlIGNob29zZSB0byBtYW5kYXRlIHVzYWdlIG9mIHJ0Y3AtbXV4 LCB3ZSBjb3VsZCBhbHNvIG1hbmRhdGUgZ2F0ZXdheXMgdG8gc3VwcG9ydCBpdC4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJuYXJkIEFib2JhDQpTZW50OiAzMSBKdWx5IDIwMTUgMjE6 MzINClRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVs dXJpeC5jb20+Pg0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+ IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTog W3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24t bXV4DQoNCk9uIEp1bCAzMSwgMjAxNSwgYXQgMTA6NTcsIFJvbWFuIFNocG91bnQgPHJvbWFuQHRl bHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KDQpXaHkgd291bGQg dGhlIGdhdGV3YXkgbmVlZCB0byBuZWdvdGlhdGUgbm9uLW11eCBpZiBydGNwLW11eCBpcyBzdXBw b3J0ZWQ/DQoNCltCQV0gSU1ITywgR2F0ZXdheXMgc2hvdWxkIGJlIHJlcXVpcmVkIHRvIHN1cHBv cnQgbXV4IGxpa2UgYW55IG90aGVyIFdFQlJUQyBlbmRwb2ludCwgYnV0IHRoaXMgaXMgbm90IHdo YXQgaXQgc2F5cyBpbiBTZWN0aW9uIDIgb2YgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtcnRjd2ViLWdhdGV3YXlzIDoNCg0KDQoiSWYgYSBnYXRld2F5IHNlcnZlcyBhcyBh IG1lZGlhIHJlbGF5IGludG8gYW5vdGhlciBSVFAgZG9tYWluLCBpdCBNQVkgY2hvb3NlIHRvIHN1 cHBvcnQgb25seSBmZWF0dXJlcyBhdmFpbGFibGUgaW4gdGhhdCBuZXR3b3JrLiBUaGlzIG1lYW5z IHRoYXQgaXQgTUFZIGNob29zZSB0byBub3Qgc3VwcG9ydCBCdW5kbGUgYW5kIGFueSBvZiB0aGUg UlRQLyBSVENQIGV4dGVuc2lvbnMgcmVsYXRlZCB0byBpdCwgUlRDUC1NdXgsIG9yIFRyaWNrbGUg SWNlLiBIb3dldmVyLCB0aGUgZ2F0ZXdheSBNVVNUIHN1cHBvcnQgRFRMUy1TUlRQLCBzaW5jZSB0 aGlzIGlzIHJlcXVpcmVkIGZvciBpbnRlcndvcmtpbmcgd2l0aCBXZWJSVEMgZW5kcG9pbnRzLiIN Cg0KDQpBc3N1bWluZyB0aGF0IGJyb3dzZXJzIHJlbW92ZSBvciBkbyBub3QgaW1wbGVtZW50IG5v bi1tdXgsIGl0IHNlZW1zIHBydWRlbnQgdG8gcmVxdWlyZSBnYXRld2F5cyB0byBzdXBwb3J0IG11 eCBzbyBhcyB0byBhdm9pZCBuZWdvdGlhdGlvbiBmYWlsdXJlcy4gSWYgd2UgbWFrZSB0aGF0IGNo YW5nZSB0aGVuIGdhdGV3YXlzIHdvdWxkIGFsd2F5cyBuZWdvdGlhdGUgUlRDUC1tdXggd2l0aCBi cm93c2Vycy4NCg== --_000_56C2F665D49E0341B9DF5938005ACDF8196FF3EDDEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlVJQ1RGb250VGV4dFN0eWxlQm9keTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBk aXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2VsbDogbm9uLW11 eCBpcyBub3QgYSDigJxuZXcgdGhpbmfigJ0gdGhhdCB3ZSBtYW5kYXRlIHRoZSB3aG9sZSB1bml2 ZXJzZSB0byBzdXBwb3J0IOKAkyBpdCBpcyBvbiB0aGUgY29udHJhcnkgdGhlIHdheSBSVENQL1JU UCB1c2VkIHRvIGZ1bmN0aW9uIHNpbmNlIHRoZSBiZWdpbm5pbmcuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TVVY aW5nIGlzIHRoZSDigJxuZXcgdGhpbmfigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+T2YgY291cnNlIHlvdSBjYW4gdGFrZSBhd2F5IGxlZ2FjeSBzdXBwb3J0IGlmIG5vLW9u ZSBpcyBpbnRlcmVzdGVkIGluIHN1cHBvcnRpbmcgaXQgYW55bW9yZS4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgdGhpbmsgdGhpcyBpcyB0aGUgY29yZSBvZiB0aGUgZGlz Y3Vzc2lvbiB0aGF0IHdlIGFyZSBoYXZpbmcg4oCTIGRvIHdlIHdhbnQgdG8gcmV0aXJlIHRoZSBv cmlnaW5hbCB3YXkgUlRQJiM0MztSVENQIHdlcmUgd29ya2luZyB3LnIudC4gcG9ydCB1c2FnZT8N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkkgaGF2ZSBteSBkb3VidHMgKGZvciB0aGUgdGltZSBiZWluZykuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlV3ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ZXh0IEFzdmVyZW4sIFRvbGdh PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAzMSwgMjAxNSAxMTo0OSBBTTxicj4NCjxi PlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7IFJvbWFuIFNocG91bnQ8 YnI+DQo8Yj5DYzo8L2I+ICZsdDtydGN3ZWJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQg bXV4L25vbi1tdXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCB5b3UgKjxi PmNvdWxkPC9iPiogbWFuZGF0ZSB0aGUgd2hvbGUgdW5pdmVyc2UgdG8gc3VwcG9ydCBpdCwgdGhh dCBzaG91bGRu4oCZdCBiZSB0b28gZGlmZmljdWx0IHRvIGRlc2NyaWJlIG9uIHBhcGVyIDstKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+T1RPSCwgd2h5PyBJZiB0aGVyZSBhcmUgZm9sa3MsIGZvciB3aG9tIG5vLXJ0Y3At bXV4IGlzIGp1c3QgZmluZSAoZm9yIHdoYXRldmVyIHJlYXNvbiksIGxldCB0aGVpciBpbXBsZW1l bnRhdGlvbnMgZnVuY3Rpb24gdGhhdCB3YXkgKGFuZCBsZXQgdGhlbSBzdWZmZXIgaWYNCiB0aGlz IGlzIHJlYWxseSBzdWNoIGEgdGVycmlibGUgdGhpbmcgZnJvbSBpbXBsZW1lbnRhdGlvbiBkaWZm aWN1bHR5IHBlcnNwZWN0aXZlKS4gQW5kIGl0IHdpbGwgYmUgdGhlaXIgcHJvYmxlbSBpZiB0aGF0 IGNhdXNlcyBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBmb3IgdGhlbSwgZS5nLiB0aGV5IHdvbuKA mXQgYmUgYWJsZSB0byB0YWxrIHRvIGJyb3dzZXJzLCB3aGljaCBtYW5kYXRlIHVzZSBvZiBydGNw LW11eC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QnJvd3NlcnMgKG9yIGFueSBvdGhlciBpbXBsZW1lbnRhdGlvbikg YWx3YXlzIG1hbmRhdGUgdXNlIG9mIHJ0Y3AtbXV4IGJ5IGFsd2F5cyBvZmZlcmluZyBpdCBhbmQg dGVybWluYXRpbmcgYSBzZXNzaW9uIGlmIHRoZSBhbnN3ZXIgaW5kaWNhdGVzIG5vIHJ0Y3AtbXV4 IHN1cHBvcnQuDQogU2ltaWxhcmx5LCB0aGV5IGNhbiByZWplY3Qgb2ZmZXJzIHdpdGggcnRjcC1t dXguIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ub2xn YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBb PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVy Zzxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMzEsIDIwMTUgMjo0NCBQTTxicj4NCjxi PlRvOjwvYj4gQmVybmFyZCBBYm9iYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFA Z21haWwuY29tIj5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT4mZ3Q7OyBSb21hbiBTaHBvdW50 ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29t PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYu b3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9u LW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHdlIGNob29zZSB0byBtYW5kYXRl IHVzYWdlIG9mIHJ0Y3AtbXV4LCB3ZSBjb3VsZCBhbHNvIG1hbmRhdGUgZ2F0ZXdheXMgdG8gc3Vw cG9ydCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjwv YT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIg WzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVybmFyZCBBYm9iYTxi cj4NCjxiPlNlbnQ6PC9iPiAzMSBKdWx5IDIwMTUgMjE6MzI8YnI+DQo8Yj5Ubzo8L2I+IFJvbWFu IFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSI+cm9tYW5AdGVs dXJpeC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3 ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0 IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPk9u IEp1bCAzMSwgMjAxNSwgYXQgMTA6NTcsIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0 bzpyb21hbkB0ZWx1cml4LmNvbSI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPldo eSB3b3VsZCB0aGUgZ2F0ZXdheSBuZWVkIHRvIG5lZ290aWF0ZSBub24tbXV4IGlmIHJ0Y3AtbXV4 IGlzIHN1cHBvcnRlZD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5bQkFdIElNSE8sIEdhdGV3YXlzIHNob3Vs ZCBiZSByZXF1aXJlZCB0byBzdXBwb3J0IG11eCBsaWtlIGFueSBvdGhlciBXRUJSVEMgZW5kcG9p bnQsIGJ1dCB0aGlzIGlzIG5vdCB3aGF0IGl0IHNheXMgaW4gU2VjdGlvbiAyIG9mDQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZ2F0ZXdheXMi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1nYXRld2F5czwv YT4gOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVC b2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mcXVvdDtJZiBhIGdhdGV3YXkgc2VydmVzIGFz IGEgbWVkaWEgcmVsYXkgaW50byBhbm90aGVyIFJUUCBkb21haW4sIGl0IE1BWSBjaG9vc2UgdG8g c3VwcG9ydCBvbmx5IGZlYXR1cmVzIGF2YWlsYWJsZSBpbiB0aGF0IG5ldHdvcmsuIFRoaXMgbWVh bnMgdGhhdCBpdCBNQVkgY2hvb3NlIHRvIG5vdCBzdXBwb3J0IEJ1bmRsZSBhbmQgYW55IG9mIHRo ZSBSVFAvIFJUQ1AgZXh0ZW5zaW9ucyByZWxhdGVkIHRvIGl0LCBSVENQLU11eCwgb3IgVHJpY2ts ZSBJY2UuIEhvd2V2ZXIsIHRoZSBnYXRld2F5IE1VU1Qgc3VwcG9ydCBEVExTLVNSVFAsIHNpbmNl IHRoaXMgaXMgcmVxdWlyZWQgZm9yIGludGVyd29ya2luZyB3aXRoIFdlYlJUQyBlbmRwb2ludHMu JnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxiciBj bGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxw cmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPkFzc3VtaW5nIHRoYXQgYnJvd3NlcnMgcmVtb3ZlIG9yIGRvIG5vdCBpbXBs ZW1lbnQgbm9uLW11eCwgaXQgc2VlbXMgcHJ1ZGVudCB0byByZXF1aXJlIGdhdGV3YXlzIHRvIHN1 cHBvcnQgbXV4IHNvIGFzIHRvIGF2b2lkIG5lZ290aWF0aW9uIGZhaWx1cmVzLiBJZiB3ZSBtYWtl IHRoYXQgY2hhbmdlIHRoZW4gZ2F0ZXdheXMgd291bGQgYWx3YXlzIG5lZ290aWF0ZSBSVENQLW11 eCB3aXRoIGJyb3dzZXJzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_56C2F665D49E0341B9DF5938005ACDF8196FF3EDDEMUMBX005nsnin_-- From nobody Fri Jul 31 11:59:34 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BB31B2F2E for ; Fri, 31 Jul 2015 11:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Edyc1w_2w7fc for ; Fri, 31 Jul 2015 11:59:31 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F3F1B2E2F for ; Fri, 31 Jul 2015 11:59:31 -0700 (PDT) Received: by qgii95 with SMTP id i95so52159242qgi.2 for ; Fri, 31 Jul 2015 11:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cWPMt03i9FOMMVxP7ElYMUAGAaIXrzEnhZOz+xlCyM4=; b=xwwD1wEMa9cVlEiN+HJPirHslU77oFAzB7vHfWDPo5rf2RD68UUc+DfRRvImzvz1jk wQ/N3XOSiPF6fdxTDhgPnpMkuSt3+yDtyaBSUfmXFGBdel/Iq7iPztXTyG+GM9aXbu4p 1wSQLuSJS+e+Fj1aBIa9x5O+w1Bhsv1YaKNbn04EVDoT11xBhhdKQiWvp0y0OpDVrJig cpglpMDaG4kdxONVKWaP8PXTjvIbCQ7//qMb3ecD4Tfd+GVvhJdEKzmjBRuDMIqKolj7 BwltMobe4u+Prh9Dvpx+oh+XkdIVGV9RjE3dFbSJxNyFl+ZXzzb0NDKKV/tjFZcO4j3U w0sQ== X-Received: by 10.140.234.14 with SMTP id f14mr6981186qhc.7.1438369170881; Fri, 31 Jul 2015 11:59:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.130 with HTTP; Fri, 31 Jul 2015 11:59:01 -0700 (PDT) In-Reply-To: References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> From: Daniel Roesler Date: Fri, 31 Jul 2015 11:59:01 -0700 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:59:33 -0000 I very much sympathize with carlo's frustration with this working group. So far the response here to the introduced privacy exploits has been pretty appalling. As you mentioned in the other consent thread, this standard is the first time a browser can send requests over non-default route network interfaces. _This is a life threatening issue!_ Many, many, many Chinese/Arab/Persian users buy VPNs to get around censorship and participate in free speech. The default configurations for these VPNs set the default route, but often still allow requests to be made over the real network interface (due to the way Windows configures VPNs). Thus, when ICE sends STUN requests through that real network interface, they expose the real IP of the VPN user. So any website can silently identify VPN users, which can lead to a knock a the door. If you don't believe me, just search for "ipleak" on twitter[1] and see how many foreign language references there are to the exploit test page. Very real implication: Loading a website (or even an embedded ad) is now much more life-threatening than it was before. Thanks everyone! Great work! I've heard many times on threads here that this is the fault of the VPN user for not configuring their VPN better. I couldn't disagree more. Up until WebRTC, the browser wasn't able to make non-default route requests, which means that up until WebRTC, you couldn't expose your real IP just by visiting a webpage. So WebRTC is the thing that triggered exposure of the user, not their VPN configuration. Also, blaming the user when they are using the default configuration (and don't know any better) and you introduced something that exposes them is offensive. So far there have been two proposed solutions, both of which help solve the issue. 1. Restrict STUN requests to default route. This obviously has performance implications, so I understand why people here are hesitant to require this. 2. Prompt the user for consent before sending STUN requests. This would prevent silent IP leak exploits like the one we saw in the wild embedded on the NYTimes. How about a combined solution? a) By default, restrict STUN requests to the default route. b) Add an option to PeerConnection to use non-default routes, too. c) When createOffer() or createAnswer() is called, if the non-default routes flag is present, ask the user for consent. If there are video or audio streams already attached to the peerconnection, assume that consent has already been obtained (since getUserMedia asks for consent). This solution is backwards compatible with existing webapps, and minimizes the introduction of any new prompts. The only change in user experience is when a webapp explicitly wants to use non-default routes for their connection. If a webapp is okay with the default route, then they can silently add a data channel (no prompts). I very much do not agree with Justin/Chrome's proposal to add a configuration extension that requires a user to opt-in to restricting non-default route STUN requests. That's like having the setting to show the warning for self-signed https certificates turned off by default and asking users to turn it on if they really want to be safe. The default behavior should be safe. Daniel [1]: https://twitter.com/search?q=ipleak On Fri, Jul 31, 2015 at 6:53 AM, Roman Shpount wrote: > On Fri, Jul 31, 2015 at 6:47 AM, carlo von lynX > wrote: >> >> Alright, thanks Tim for digging deeper and confirming that >> we have a serious problem here. Unfortunately everybody >> else is talking of other things and giving the impression >> we are having just a side discussion.. and the problem >> remains: WebRTC threatens lives of dissidents. If we can't >> publish news that rtcweb has fixed the problem then the >> logical consequence is to publish that n months have passed >> and rtcweb is still not willing to fix the issue.... which >> can be interpreted as a political news all on its own - how >> industry does not care about collateral damages. Certainly >> we can't just keep quiet and let this become a working >> strategy to ignore issues. >> >> So, dear folks, this is your chance to keep the next >> shitstorm from coming your way. Do something! >> > > In IETF we typically discuss technical issues and not political PR. So, the > other discussions that you so blatantly ignore are actually about the actual > technical implications of webrtc on user privacy and possible ways to > improve it. If you have a particular technical solution that you want > propose then please do so. Screaming that industry needs to do something or > else the puppy will die is not helpful. > > Regards, > _____________ > Roman Shpount > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Fri Jul 31 11:59:36 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AE91B3487 for ; Fri, 31 Jul 2015 11:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zamWdkApLR17 for ; Fri, 31 Jul 2015 11:59:34 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8161B2E2F for ; Fri, 31 Jul 2015 11:59:34 -0700 (PDT) Received: by igr7 with SMTP id 7so22248729igr.0 for ; Fri, 31 Jul 2015 11:59:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bJajnLr6uW+gMQSidigtlTEpy5QOeZHcRFAUavhROfg=; b=kKCubEOmgrtOkZwp8bghU8ntZInZ9I84xWJIj9bdQTVEeuFC55zAQb774lO72SBHh9 JrLbMQuHZyATY3JzttUa5nZz9yJHDeLPNuKHJuiDHUScrnOdJcZqSyZABrFzgGpxQisJ yCFCPBR4NWmP44SyXtUN1EwuH3evq6ZYPqGdTgahkwaISGPdpPi8M22LZKc1/e/Re/Sv ZZvafXQNiA0vQFOtyclH653AePDxrkNdSW/atN++GBoqtTjxcT2IV1gYg3VkJV2Nbl4m R+hMv30befs7GRQrFDl6GnGmDMsZdypbxq01qAaKe2NdGimWBe6JBX/jofFqkKNfqpfR VlAQ== X-Gm-Message-State: ALoCoQl3RWwtuqcRe9RDZjhRIsRRBBFFyw1RRpMGHl3l1vF3onWjpKR5V5/R+EtOXhwSJVmfg70V X-Received: by 10.50.43.193 with SMTP id y1mr8366299igl.89.1438369173930; Fri, 31 Jul 2015 11:59:33 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com. [209.85.223.178]) by smtp.gmail.com with ESMTPSA id fv2sm2869625igb.22.2015.07.31.11.59.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 11:59:33 -0700 (PDT) Received: by ioii16 with SMTP id i16so94392130ioi.0 for ; Fri, 31 Jul 2015 11:59:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.13.201 with SMTP id 192mr7876907ion.70.1438369172501; Fri, 31 Jul 2015 11:59:32 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Fri, 31 Jul 2015 11:59:32 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> Date: Fri, 31 Jul 2015 14:59:32 -0400 Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a113fd5e09541b5051c306b5d Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:59:36 -0000 --001a113fd5e09541b5051c306b5d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 31, 2015 at 2:49 PM, Asveren, Tolga wrote: > Yes, you **could** mandate the whole universe to support it, that > shouldn=E2=80=99t be too difficult to describe on paper ;-) > > > We are trying to mandate that WebRTC endpoints (browsers and gateways) must support. The rest of the universe can continue to negotiate rtcp-mux and/or not support it. _____________ Roman Shpount --001a113fd5e09541b5051c306b5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113fd5e09541b5051c306b5d-- From nobody Fri Jul 31 12:01:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2291B347A for ; Fri, 31 Jul 2015 12:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebbiBnhMtlDb for ; Fri, 31 Jul 2015 12:01:39 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C702E1B2F34 for ; Fri, 31 Jul 2015 12:01:39 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so38086460igb.0 for ; Fri, 31 Jul 2015 12:01:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Vf4uwudoY3rNnEx7Rn0KDK8cLBQTR6NueLjPd1SFRXQ=; b=Eu/F4rUkza9/06zqCZuvEKki/WGmt90H6l9Zl3mrggLICZdjWTkmts6FpfWTh0KbKJ NcRI8efYtu6ZW2NI7xKGrR5WYWHmro/cImaYnv4WsA5ZD62VlSfNc3CwoZuQBgfhXURc pBg1RkAvy61OFbVI2c/Ze8hfOLEJxAO7Sv4ATHDNdLD7G/ApFys0hEXRc4ZIr/Qet37G CMbJgRNuXZs7triAGORft987yzGM3lTAWI0fTs9I3bm06NBxEiJFUIFo6jualG1lYyC0 mpn0h2Waen+Vk1i9aZs3gLtD6XEVVddw5Jt4p7xpUraTOyGDmy664khG1JTttY+pZZ8t JZwA== X-Gm-Message-State: ALoCoQl6xKj0qbQtag21pMh+U4GL8T8czlBwzWm7Ok5/3spiJ6wX1OeJaIW00qOQoYy3jugygTbV X-Received: by 10.50.79.197 with SMTP id l5mr8743875igx.28.1438369299256; Fri, 31 Jul 2015 12:01:39 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id fv2sm2874053igb.22.2015.07.31.12.01.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 12:01:38 -0700 (PDT) Received: by ioeg141 with SMTP id g141so94712732ioe.3 for ; Fri, 31 Jul 2015 12:01:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.13.201 with SMTP id 192mr7896138ion.70.1438369297712; Fri, 31 Jul 2015 12:01:37 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Fri, 31 Jul 2015 12:01:37 -0700 (PDT) In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> Date: Fri, 31 Jul 2015 15:01:37 -0400 Message-ID: From: Roman Shpount To: "Rauschenbach, Uwe (Nokia - DE/Munich)" Content-Type: multipart/alternative; boundary=001a113fd5e00bce10051c3073b6 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 19:01:40 -0000 --001a113fd5e00bce10051c3073b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 31, 2015 at 2:58 PM, Rauschenbach, Uwe (Nokia - DE/Munich) < uwe.rauschenbach@nokia.com> wrote: > I think this is the core of the discussion that we are having =E2=80=93 d= o we want > to retire the original way RTP+RTCP were working w.r.t. port usage? > > I have my doubts (for the time being). > I agree this is the core of this discussion, so can you please clarify why you are having doubts? What is you argument or use case on why original RTP+RTCP on separate ports is needed in context of WebRTC? Regards, _____________ Roman Shpount --001a113fd5e00bce10051c3073b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 31, 2015 at 2:58 PM, Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com> wrote:

I think this is the core of the discussion that we are having =E2= =80=93 do we want to retire the original way RTP+RTCP were working w.r.t. p= ort usage?

I have my doubts (for the time being).


I agree this is the co= re of this discussion, so can you please clarify why you are having doubts?= What is you argument or use case on why original RTP+RTCP on separate port= s is needed in context of WebRTC?

Regards,
_____________
Roman Shpount
=C2=A0
--001a113fd5e00bce10051c3073b6-- From nobody Fri Jul 31 12:02:16 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4E61B2F34 for ; Fri, 31 Jul 2015 12:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqHlGD-dx0yK for ; Fri, 31 Jul 2015 12:02:15 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7F11A8A7A for ; Fri, 31 Jul 2015 12:02:14 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so22884053igb.0 for ; Fri, 31 Jul 2015 12:02:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dB6hepvzo4ZlYCGaaFmTzafxD9sDgQ+NMBXkr4CirPg=; b=bxzg9bGSpdV7tczjxnwabwRLG+xxpFS1OhqGhduGsQpqhF/VL6Iuzdi9qVzrmPus73 2NrWt0apoa4zd1a68VbmGGD+QL+xw0AMVWgM+9yvpxjn0USTg2Az9DzQI9Didtdch9Y2 FKbFPEw1Yomw0AsHvG5CnCS1x71MljTQZjsCEN9Zsm/GCdJk07FFKaLFH5qAc1lO7PO1 k3988iqQM2j99hB8JzJgmQLv/tBthQBEcsCagyni/EIE8MUDMdRwNR0MkNtFXitSX7ng QUmPfVdduWhoV1UGguRyPyJs+RiHLbkLG72e+TlMqkwDe0anzyQq4gZKvaAXthZjVPQS TCWA== X-Gm-Message-State: ALoCoQlW6SKlFH6UNkr8qiTPAo6Hvl6fFdTjggYPoY8je219lPqzf4oA/wONMtcng6KV/559ywEm X-Received: by 10.50.56.104 with SMTP id z8mr8135652igp.45.1438369334286; Fri, 31 Jul 2015 12:02:14 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id n6sm2888747igv.17.2015.07.31.12.02.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 12:02:13 -0700 (PDT) Received: by ioii16 with SMTP id i16so94464372ioi.0 for ; Fri, 31 Jul 2015 12:02:12 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.150.141 with SMTP id y135mr7361933iod.38.1438369332652; Fri, 31 Jul 2015 12:02:12 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Fri, 31 Jul 2015 12:02:12 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> Date: Fri, 31 Jul 2015 15:02:12 -0400 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11403fd420f7e8051c3075b4 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 19:02:16 -0000 --001a11403fd420f7e8051c3075b4 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 2:43 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > If we choose to mandate usage of rtcp-mux, we could also mandate gateways > to support it. > > +1 _____________ Roman Shpount --001a11403fd420f7e8051c3075b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 31, 2015 at 2:4= 3 PM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:

If we choose to mandate usage of rtcp-mux, w= e could also mandate gateways to support it.


+1
_____________
Roman Shpount
=C2=A0
--001a11403fd420f7e8051c3075b4-- From nobody Fri Jul 31 12:02:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23731A8A7A for ; Fri, 31 Jul 2015 12:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8egzZuQOksAc for ; Fri, 31 Jul 2015 12:02:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0089.outbound.protection.outlook.com [207.46.100.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7511E1A8A5A for ; Fri, 31 Jul 2015 12:02:55 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 31 Jul 2015 19:02:53 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Fri, 31 Jul 2015 19:02:53 +0000 From: "Asveren, Tolga" To: "Rauschenbach, Uwe (Nokia - DE/Munich)" , Christer Holmberg , Bernard Aboba , Roman Shpount Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsA== Date: Fri, 31 Jul 2015 19:02:53 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:uhTA++rh6NPCx/554WqM8pbLj2HaqEHn91dkiLHFmMC7OudTxT6h14T6P9t3fOff3AMKfGOg8krx+Ou1IIC/acCp/jPIg0ZriPnAlQlRGGVNmYmB49X10DjAAOdy+TlYx8XjQp+/sHNFyYePNqX9sg==; 24:HKHyscII8R9Nes+lz4NguwXnhfHzjtvszyzh7RETJJf5863CcpWjppjIIsH5ovrc2acGToej2opFgQ+4a27l8JZ7XTefardxvWMY6Da8yRY=; 20:+rSuX2xJb2NtmVhODzljMHOHzLjnp3ZMTYdQFbFitumqILb9oX08DZsVb1x8ZIsB6qXZsCpeEUcc87zOXmpvoA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; sn1pr0301mb1549: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(164054003)(71364002)(24454002)(54356999)(86362001)(5001960100002)(74316001)(77096005)(102836002)(77156002)(5002640100001)(76576001)(76176999)(99286002)(5003600100002)(50986999)(15975445007)(2900100001)(19625215002)(5001770100001)(106116001)(122556002)(33656002)(19300405004)(19609705001)(2950100001)(19580395003)(62966003)(2656002)(87936001)(92566002)(19617315012)(189998001)(19580405001)(40100003)(93886004)(16236675004)(46102003)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551B0BB54D3330C6BC752F0B28A0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 19:02:53.7020 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 19:02:57 -0000 --_000_SN1PR0301MB1551B0BB54D3330C6BC752F0B28A0SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBjb21wbGV0ZWx5IGFncmVlIG9uIHRoZSDigJxuZXfigJ0gdi5zLiDigJx0aGUgd2F5IHRo aW5ncyB1c2VkIHRvIHdvcmsgZm9yIG1hbnkgeWVhcnPigJ0gcG9pbnQgYXMgZmFyIGFzIHJ0Y3At bXV4IGlzIGNvbmNlcm5lZC4NCg0KRnVydGhlcm1vcmUsIC1mb3IgZXhhbXBsZS0sIG5vdCBtYW5k YXRpbmcgSUNFIHdvdWxkIGhhdmUgc2VyaW91cyBpbXBhY3QgYXMgZmFyIGFzIOKAnG1ha2luZyB0 aGluZ3Mgd29yayBmcm9tIGVuZCB1c2VyIHBlcnNwZWN0aXZl4oCdIGlzIGNvbmNlcm5lZC4gT1RP SCwgdGhlIHNhbWUgZG9lcyBub3QgbmVjZXNzYXJpbHkgaG9sZCB0cnVlIGZvciBydGNwLW11eC4g VHdvIFdlYlJUQyBlbGVtZW50cywgd2hpY2ggZG8gbm90IHdhbnQgdG8gdXNlIGl0IGNhbiBjb21t dW5pY2F0ZSBzdWNjZXNzZnVsbHkuDQoNClRoYW5rcywNClRvbGdhDQoNCkZyb206IFJhdXNjaGVu YmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkgW21haWx0bzp1d2UucmF1c2NoZW5iYWNoQG5v a2lhLmNvbV0NClNlbnQ6IEZyaWRheSwgSnVseSAzMSwgMjAxNSAyOjU4IFBNDQpUbzogQXN2ZXJl biwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT47IENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBCZXJuYXJkIEFib2JhIDxiZXJuYXJkLmFib2Jh QGdtYWlsLmNvbT47IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPg0KQ2M6IDxydGN3 ZWJAaWV0Zi5vcmc+IDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gV2hh dCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCldlbGw6 IG5vbi1tdXggaXMgbm90IGEg4oCcbmV3IHRoaW5n4oCdIHRoYXQgd2UgbWFuZGF0ZSB0aGUgd2hv bGUgdW5pdmVyc2UgdG8gc3VwcG9ydCDigJMgaXQgaXMgb24gdGhlIGNvbnRyYXJ5IHRoZSB3YXkg UlRDUC9SVFAgdXNlZCB0byBmdW5jdGlvbiBzaW5jZSB0aGUgYmVnaW5uaW5nLg0KTVVYaW5nIGlz IHRoZSDigJxuZXcgdGhpbmfigJ0uDQoNCk9mIGNvdXJzZSB5b3UgY2FuIHRha2UgYXdheSBsZWdh Y3kgc3VwcG9ydCBpZiBuby1vbmUgaXMgaW50ZXJlc3RlZCBpbiBzdXBwb3J0aW5nIGl0IGFueW1v cmUuDQoNCkkgdGhpbmsgdGhpcyBpcyB0aGUgY29yZSBvZiB0aGUgZGlzY3Vzc2lvbiB0aGF0IHdl IGFyZSBoYXZpbmcg4oCTIGRvIHdlIHdhbnQgdG8gcmV0aXJlIHRoZSBvcmlnaW5hbCB3YXkgUlRQ K1JUQ1Agd2VyZSB3b3JraW5nIHcuci50LiBwb3J0IHVzYWdlPw0KSSBoYXZlIG15IGRvdWJ0cyAo Zm9yIHRoZSB0aW1lIGJlaW5nKS4NCg0KS2luZCByZWdhcmRzLA0KVXdlDQoNCkZyb206IHJ0Y3dl YiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IEFzdmVy ZW4sIFRvbGdhDQpTZW50OiBGcmlkYXksIEp1bHkgMzEsIDIwMTUgMTE6NDkgQU0NClRvOiBDaHJp c3RlciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgUm9tYW4gU2hwb3VudA0KQ2M6IDxydGN3ZWJA aWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0g V2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNClll cywgeW91ICpjb3VsZCogbWFuZGF0ZSB0aGUgd2hvbGUgdW5pdmVyc2UgdG8gc3VwcG9ydCBpdCwg dGhhdCBzaG91bGRu4oCZdCBiZSB0b28gZGlmZmljdWx0IHRvIGRlc2NyaWJlIG9uIHBhcGVyIDst KQ0KDQpPVE9ILCB3aHk/IElmIHRoZXJlIGFyZSBmb2xrcywgZm9yIHdob20gbm8tcnRjcC1tdXgg aXMganVzdCBmaW5lIChmb3Igd2hhdGV2ZXIgcmVhc29uKSwgbGV0IHRoZWlyIGltcGxlbWVudGF0 aW9ucyBmdW5jdGlvbiB0aGF0IHdheSAoYW5kIGxldCB0aGVtIHN1ZmZlciBpZiB0aGlzIGlzIHJl YWxseSBzdWNoIGEgdGVycmlibGUgdGhpbmcgZnJvbSBpbXBsZW1lbnRhdGlvbiBkaWZmaWN1bHR5 IHBlcnNwZWN0aXZlKS4gQW5kIGl0IHdpbGwgYmUgdGhlaXIgcHJvYmxlbSBpZiB0aGF0IGNhdXNl cyBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBmb3IgdGhlbSwgZS5nLiB0aGV5IHdvbuKAmXQgYmUg YWJsZSB0byB0YWxrIHRvIGJyb3dzZXJzLCB3aGljaCBtYW5kYXRlIHVzZSBvZiBydGNwLW11eC4N Cg0KQnJvd3NlcnMgKG9yIGFueSBvdGhlciBpbXBsZW1lbnRhdGlvbikgYWx3YXlzIG1hbmRhdGUg dXNlIG9mIHJ0Y3AtbXV4IGJ5IGFsd2F5cyBvZmZlcmluZyBpdCBhbmQgdGVybWluYXRpbmcgYSBz ZXNzaW9uIGlmIHRoZSBhbnN3ZXIgaW5kaWNhdGVzIG5vIHJ0Y3AtbXV4IHN1cHBvcnQuIFNpbWls YXJseSwgdGhleSBjYW4gcmVqZWN0IG9mZmVycyB3aXRoIHJ0Y3AtbXV4Lg0KDQpUaGFua3MsDQpU b2xnYQ0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBGcmlkYXksIEp1bHkgMzEsIDIwMTUg Mjo0NCBQTQ0KVG86IEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0 bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4+OyBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+Pg0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc8bWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZz4+IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91 bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCkhpLA0KDQpJZiB3ZSBjaG9vc2UgdG8gbWFuZGF0 ZSB1c2FnZSBvZiBydGNwLW11eCwgd2UgY291bGQgYWxzbyBtYW5kYXRlIGdhdGV3YXlzIHRvIHN1 cHBvcnQgaXQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRv OnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVybmFyZCBBYm9iYQ0KU2Vu dDogMzEgSnVseSAyMDE1IDIxOjMyDQpUbzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5j b208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4NCkNjOiA8cnRjd2ViQGlldGYub3JnPG1haWx0 bzpydGN3ZWJAaWV0Zi5vcmc+PiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxk IHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpPbiBKdWwgMzEsIDIwMTUsIGF0IDEwOjU3LCBSb21h biBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3 cm90ZToNCg0KV2h5IHdvdWxkIHRoZSBnYXRld2F5IG5lZWQgdG8gbmVnb3RpYXRlIG5vbi1tdXgg aWYgcnRjcC1tdXggaXMgc3VwcG9ydGVkPw0KDQpbQkFdIElNSE8sIEdhdGV3YXlzIHNob3VsZCBi ZSByZXF1aXJlZCB0byBzdXBwb3J0IG11eCBsaWtlIGFueSBvdGhlciBXRUJSVEMgZW5kcG9pbnQs IGJ1dCB0aGlzIGlzIG5vdCB3aGF0IGl0IHNheXMgaW4gU2VjdGlvbiAyIG9mIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1nYXRld2F5cyA6DQoNCg0KIklmIGEg Z2F0ZXdheSBzZXJ2ZXMgYXMgYSBtZWRpYSByZWxheSBpbnRvIGFub3RoZXIgUlRQIGRvbWFpbiwg aXQgTUFZIGNob29zZSB0byBzdXBwb3J0IG9ubHkgZmVhdHVyZXMgYXZhaWxhYmxlIGluIHRoYXQg bmV0d29yay4gVGhpcyBtZWFucyB0aGF0IGl0IE1BWSBjaG9vc2UgdG8gbm90IHN1cHBvcnQgQnVu ZGxlIGFuZCBhbnkgb2YgdGhlIFJUUC8gUlRDUCBleHRlbnNpb25zIHJlbGF0ZWQgdG8gaXQsIFJU Q1AtTXV4LCBvciBUcmlja2xlIEljZS4gSG93ZXZlciwgdGhlIGdhdGV3YXkgTVVTVCBzdXBwb3J0 IERUTFMtU1JUUCwgc2luY2UgdGhpcyBpcyByZXF1aXJlZCBmb3IgaW50ZXJ3b3JraW5nIHdpdGgg V2ViUlRDIGVuZHBvaW50cy4iDQoNCg0KQXNzdW1pbmcgdGhhdCBicm93c2VycyByZW1vdmUgb3Ig ZG8gbm90IGltcGxlbWVudCBub24tbXV4LCBpdCBzZWVtcyBwcnVkZW50IHRvIHJlcXVpcmUgZ2F0 ZXdheXMgdG8gc3VwcG9ydCBtdXggc28gYXMgdG8gYXZvaWQgbmVnb3RpYXRpb24gZmFpbHVyZXMu IElmIHdlIG1ha2UgdGhhdCBjaGFuZ2UgdGhlbiBnYXRld2F5cyB3b3VsZCBhbHdheXMgbmVnb3Rp YXRlIFJUQ1AtbXV4IHdpdGggYnJvd3NlcnMuDQo= --_000_SN1PR0301MB1551B0BB54D3330C6BC752F0B28A0SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlVJQ1RGb250VGV4dFN0eWxlQm9keTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Mg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlllcywgY29tcGxldGVseSBh Z3JlZSBvbiB0aGUg4oCcbmV34oCdIHYucy4g4oCcdGhlIHdheSB0aGluZ3MgdXNlZCB0byB3b3Jr IGZvciBtYW55IHllYXJz4oCdIHBvaW50IGFzIGZhciBhcyBydGNwLW11eCBpcyBjb25jZXJuZWQu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZ1cnRoZXJtb3Jl LCAtZm9yIGV4YW1wbGUtLCBub3QgbWFuZGF0aW5nIElDRSB3b3VsZCBoYXZlIHNlcmlvdXMgaW1w YWN0IGFzIGZhciBhcyDigJxtYWtpbmcgdGhpbmdzIHdvcmsgZnJvbSBlbmQgdXNlciBwZXJzcGVj dGl2ZeKAnSBpcyBjb25jZXJuZWQuIE9UT0gsIHRoZSBzYW1lDQogZG9lcyBub3QgbmVjZXNzYXJp bHkgaG9sZCB0cnVlIGZvciBydGNwLW11eC4gVHdvIFdlYlJUQyBlbGVtZW50cywgd2hpY2ggZG8g bm90IHdhbnQgdG8gdXNlIGl0IGNhbiBjb21tdW5pY2F0ZSBzdWNjZXNzZnVsbHkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlRvbGdhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNo KSBbbWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgSnVseSAzMSwgMjAxNSAyOjU4IFBNPGJyPg0KPGI+VG86PC9iPiBBc3ZlcmVuLCBU b2xnYSAmbHQ7dGFzdmVyZW5Ac29udXNuZXQuY29tJmd0OzsgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0 O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs7IEJlcm5hcmQgQWJvYmEgJmx0O2Jl cm5hcmQuYWJvYmFAZ21haWwuY29tJmd0OzsgUm9tYW4gU2hwb3VudCAmbHQ7cm9tYW5AdGVsdXJp eC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7cnRjd2ViQGlldGYub3JnJmd0OyAmbHQ7cnRj d2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3J0Y3dlYl0gV2hhdCB0 aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+V2VsbDog bm9uLW11eCBpcyBub3QgYSDigJxuZXcgdGhpbmfigJ0gdGhhdCB3ZSBtYW5kYXRlIHRoZSB3aG9s ZSB1bml2ZXJzZSB0byBzdXBwb3J0IOKAkyBpdCBpcyBvbiB0aGUgY29udHJhcnkgdGhlIHdheSBS VENQL1JUUCB1c2VkIHRvIGZ1bmN0aW9uIHNpbmNlIHRoZSBiZWdpbm5pbmcuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TVVYaW5nIGlz IHRoZSDigJxuZXcgdGhpbmfigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T2YgY291cnNlIHlvdSBjYW4gdGFrZSBh d2F5IGxlZ2FjeSBzdXBwb3J0IGlmIG5vLW9uZSBpcyBpbnRlcmVzdGVkIGluIHN1cHBvcnRpbmcg aXQgYW55bW9yZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgdGhpcyBpcyB0aGUgY29yZSBvZiB0aGUg ZGlzY3Vzc2lvbiB0aGF0IHdlIGFyZSBoYXZpbmcg4oCTIGRvIHdlIHdhbnQgdG8gcmV0aXJlIHRo ZSBvcmlnaW5hbCB3YXkgUlRQJiM0MztSVENQIHdlcmUgd29ya2luZyB3LnIudC4gcG9ydCB1c2Fn ZT8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPkkgaGF2ZSBteSBkb3VidHMgKGZvciB0aGUgdGltZSBiZWluZykuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPlV3ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIgWzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9u IEJlaGFsZiBPZiA8L2I+ZXh0IEFzdmVyZW4sIFRvbGdhPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRh eSwgSnVseSAzMSwgMjAxNSAxMTo0OSBBTTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJl cmc7IEJlcm5hcmQgQWJvYmE7IFJvbWFuIFNocG91bnQ8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8YSBo cmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91 bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlllcywgeW91ICo8 Yj5jb3VsZDwvYj4qIG1hbmRhdGUgdGhlIHdob2xlIHVuaXZlcnNlIHRvIHN1cHBvcnQgaXQsIHRo YXQgc2hvdWxkbuKAmXQgYmUgdG9vIGRpZmZpY3VsdCB0byBkZXNjcmliZSBvbiBwYXBlciA7LSk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9UT0gsIHdoeT8gSWYg dGhlcmUgYXJlIGZvbGtzLCBmb3Igd2hvbSBuby1ydGNwLW11eCBpcyBqdXN0IGZpbmUgKGZvciB3 aGF0ZXZlciByZWFzb24pLCBsZXQgdGhlaXIgaW1wbGVtZW50YXRpb25zIGZ1bmN0aW9uIHRoYXQg d2F5IChhbmQgbGV0IHRoZW0gc3VmZmVyIGlmIHRoaXMNCiBpcyByZWFsbHkgc3VjaCBhIHRlcnJp YmxlIHRoaW5nIGZyb20gaW1wbGVtZW50YXRpb24gZGlmZmljdWx0eSBwZXJzcGVjdGl2ZSkuIEFu ZCBpdCB3aWxsIGJlIHRoZWlyIHByb2JsZW0gaWYgdGhhdCBjYXVzZXMgaW50ZXJvcGVyYWJpbGl0 eSBpc3N1ZXMgZm9yIHRoZW0sIGUuZy4gdGhleSB3b27igJl0IGJlIGFibGUgdG8gdGFsayB0byBi cm93c2Vycywgd2hpY2ggbWFuZGF0ZSB1c2Ugb2YgcnRjcC1tdXguDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJyb3dzZXJzIChvciBhbnkgb3RoZXIgaW1wbGVt ZW50YXRpb24pIGFsd2F5cyBtYW5kYXRlIHVzZSBvZiBydGNwLW11eCBieSBhbHdheXMgb2ZmZXJp bmcgaXQgYW5kIHRlcm1pbmF0aW5nIGEgc2Vzc2lvbiBpZiB0aGUgYW5zd2VyIGluZGljYXRlcyBu byBydGNwLW11eCBzdXBwb3J0Lg0KIFNpbWlsYXJseSwgdGhleSBjYW4gcmVqZWN0IG9mZmVycyB3 aXRoIHJ0Y3AtbXV4LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIgWzxhIGhy ZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+ DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDMxLCAyMDE1IDI6NDQgUE08YnI+DQo8Yj5Ubzo8 L2I+IEJlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWls LmNvbSI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L2E+Jmd0OzsgUm9tYW4gU2hwb3VudCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+ cnRjd2ViQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v cmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRj d2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB3ZSBj aG9vc2UgdG8gbWFuZGF0ZSB1c2FnZSBvZiBydGNwLW11eCwgd2UgY291bGQgYWxzbyBtYW5kYXRl IGdhdGV3YXlzIHRvIHN1cHBvcnQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48L2E+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gcnRjd2ViIFs8YSBocmVmPSJt YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJlcm5hcmQgQWJvYmE8YnI+DQo8Yj5TZW50 OjwvYj4gMzEgSnVseSAyMDE1IDIxOjMyPGJyPg0KPGI+VG86PC9iPiBSb21hbiBTaHBvdW50ICZs dDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9h PiZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3Jn Ij5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFty dGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11 eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBKdWwgMzEsIDIw MTUsIGF0IDEwOjU3LCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVs dXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5XaHkgd291bGQgdGhl IGdhdGV3YXkgbmVlZCB0byBuZWdvdGlhdGUgbm9uLW11eCBpZiBydGNwLW11eCBpcyBzdXBwb3J0 ZWQ/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+W0JBXSBJTUhPLCBHYXRld2F5cyBzaG91bGQgYmUgcmVxdWly ZWQgdG8gc3VwcG9ydCBtdXggbGlrZSBhbnkgb3RoZXIgV0VCUlRDIGVuZHBvaW50LCBidXQgdGhp cyBpcyBub3Qgd2hhdCBpdCBzYXlzIGluIFNlY3Rpb24gMiBvZg0KPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWdhdGV3YXlzIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZ2F0ZXdheXM8L2E+IDo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlQm9keSI+JnF1b3Q7SWYgYSBn YXRld2F5IHNlcnZlcyBhcyBhIG1lZGlhIHJlbGF5IGludG8gYW5vdGhlciBSVFAgZG9tYWluLCBp dCBNQVkgY2hvb3NlIHRvIHN1cHBvcnQgb25seSBmZWF0dXJlcyBhdmFpbGFibGUgaW4gdGhhdCBu ZXR3b3JrLiBUaGlzIG1lYW5zIHRoYXQgaXQgTUFZIGNob29zZSB0byBub3Qgc3VwcG9ydCBCdW5k bGUgYW5kIGFueSBvZiB0aGUgUlRQLyBSVENQIGV4dGVuc2lvbnMgcmVsYXRlZCB0byBpdCwgUlRD UC1NdXgsIG9yIFRyaWNrbGUgSWNlLiBIb3dldmVyLCB0aGUgZ2F0ZXdheSBNVVNUIHN1cHBvcnQg RFRMUy1TUlRQLCBzaW5jZSB0aGlzIGlzIHJlcXVpcmVkIGZvciBpbnRlcndvcmtpbmcgd2l0aCBX ZWJSVEMgZW5kcG9pbnRzLiZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6VUlDVEZvbnRUZXh0U3R5bGVCb2R5O21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48YnIgY2xlYXI9ImFsbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ DQo8L3NwYW4+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6VUlDVEZvbnRUZXh0U3R5bGVCb2R5Ij5Bc3N1 bWluZyB0aGF0IGJyb3dzZXJzIHJlbW92ZSBvciBkbyBub3QgaW1wbGVtZW50IG5vbi1tdXgsIGl0 IHNlZW1zIHBydWRlbnQgdG8gcmVxdWlyZSBnYXRld2F5cyB0byBzdXBwb3J0IG11eCBzbyBhcyB0 byBhdm9pZCBuZWdvdGlhdGlvbiBmYWlsdXJlcy4gSWYgd2UgbWFrZSB0aGF0IGNoYW5nZSB0aGVu IGdhdGV3YXlzIHdvdWxkIGFsd2F5cyBuZWdvdGlhdGUgUlRDUC1tdXggd2l0aCBicm93c2Vycy48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN1PR0301MB1551B0BB54D3330C6BC752F0B28A0SN1PR0301MB1551_-- From nobody Fri Jul 31 12:08:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D241B2EB5 for ; Fri, 31 Jul 2015 12:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKb5pLGkutXF for ; Fri, 31 Jul 2015 12:08:18 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484281B2E9F for ; Fri, 31 Jul 2015 12:08:18 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t6VJ8Evo024391 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 Jul 2015 19:08:15 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t6VJ8E08029275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 21:08:14 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.210]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0248.002; Fri, 31 Jul 2015 21:08:14 +0200 From: "Rauschenbach, Uwe (Nokia - DE/Munich)" To: "ext Asveren, Tolga" , Christer Holmberg , Bernard Aboba , Roman Shpount Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78tkj01AbA0AUWp46tuxkqao531yJ8AgAABlICAACJYIP//4XCAgAAh7oA= Date: Fri, 31 Jul 2015 19:08:13 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.111] Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF8196FF450DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 32248 X-purgate-ID: 151667::1438369695-000063FD-06533106/0/0 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 19:08:21 -0000 --_000_56C2F665D49E0341B9DF5938005ACDF8196FF450DEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBhZ3JlZWQsIHRoZXNlIGFyZSBpbiB0d28gZGlmZmVyZW50IGNhdGVnb3JpZXMuDQoNClJU Q1AgbXV4IGlzIGFuIG9wdGltaXphdGlvbiDigJMgbm90IHN1cHBvcnRpbmcgaXQgZG91YmxlcyB0 aGUgbnVtYmVyIG9mIHBvcnRzIHRvIGJlIHVzZWQsIGFuZCBzbG93cyBkb3duIElDRSBnYXRoZXJp bmcuDQpXaGVyZWFzIElDRSBub24tc3VwcG9ydCBpcyBhIHNob3dzdG9wcGVyDQoNCkxldCBtZSBo YXZlIHNvbWUgaW50ZXJuYWwgZGlzY3Vzc2lvbnMgb24gdGhpcyB0b3BpYyBhbmQgZ2V0IGJhY2sg dG8gdGhlIGxpc3QgbmV4dCB3ZWVrLg0KDQpLaW5kIHJlZ2FyZHMsDQpVd2UNCg0KRnJvbTogZXh0 IEFzdmVyZW4sIFRvbGdhIFttYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tXQ0KU2VudDogRnJp ZGF5LCBKdWx5IDMxLCAyMDE1IDEyOjAzIFBNDQpUbzogUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lh IC0gREUvTXVuaWNoKTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7IFJvbWFuIFNo cG91bnQNCkNjOiA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtydGN3ZWJdIFdoYXQg dGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpZZXMsIGNv bXBsZXRlbHkgYWdyZWUgb24gdGhlIOKAnG5ld+KAnSB2LnMuIOKAnHRoZSB3YXkgdGhpbmdzIHVz ZWQgdG8gd29yayBmb3IgbWFueSB5ZWFyc+KAnSBwb2ludCBhcyBmYXIgYXMgcnRjcC1tdXggaXMg Y29uY2VybmVkLg0KDQpGdXJ0aGVybW9yZSwgLWZvciBleGFtcGxlLSwgbm90IG1hbmRhdGluZyBJ Q0Ugd291bGQgaGF2ZSBzZXJpb3VzIGltcGFjdCBhcyBmYXIgYXMg4oCcbWFraW5nIHRoaW5ncyB3 b3JrIGZyb20gZW5kIHVzZXIgcGVyc3BlY3RpdmXigJ0gaXMgY29uY2VybmVkLiBPVE9ILCB0aGUg c2FtZSBkb2VzIG5vdCBuZWNlc3NhcmlseSBob2xkIHRydWUgZm9yIHJ0Y3AtbXV4LiBUd28gV2Vi UlRDIGVsZW1lbnRzLCB3aGljaCBkbyBub3Qgd2FudCB0byB1c2UgaXQgY2FuIGNvbW11bmljYXRl IHN1Y2Nlc3NmdWxseS4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogUmF1c2NoZW5iYWNoLCBV d2UgKE5va2lhIC0gREUvTXVuaWNoKSBbbWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29t XQ0KU2VudDogRnJpZGF5LCBKdWx5IDMxLCAyMDE1IDI6NTggUE0NClRvOiBBc3ZlcmVuLCBUb2xn YSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20+Pjsg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj47IEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQu YWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4+OyBSb21hbiBT aHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+Pg0KQ2M6 IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+IDxydGN3ZWJAaWV0Zi5v cmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gV2hhdCB0 aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCldlbGw6IG5v bi1tdXggaXMgbm90IGEg4oCcbmV3IHRoaW5n4oCdIHRoYXQgd2UgbWFuZGF0ZSB0aGUgd2hvbGUg dW5pdmVyc2UgdG8gc3VwcG9ydCDigJMgaXQgaXMgb24gdGhlIGNvbnRyYXJ5IHRoZSB3YXkgUlRD UC9SVFAgdXNlZCB0byBmdW5jdGlvbiBzaW5jZSB0aGUgYmVnaW5uaW5nLg0KTVVYaW5nIGlzIHRo ZSDigJxuZXcgdGhpbmfigJ0uDQoNCk9mIGNvdXJzZSB5b3UgY2FuIHRha2UgYXdheSBsZWdhY3kg c3VwcG9ydCBpZiBuby1vbmUgaXMgaW50ZXJlc3RlZCBpbiBzdXBwb3J0aW5nIGl0IGFueW1vcmUu DQoNCkkgdGhpbmsgdGhpcyBpcyB0aGUgY29yZSBvZiB0aGUgZGlzY3Vzc2lvbiB0aGF0IHdlIGFy ZSBoYXZpbmcg4oCTIGRvIHdlIHdhbnQgdG8gcmV0aXJlIHRoZSBvcmlnaW5hbCB3YXkgUlRQK1JU Q1Agd2VyZSB3b3JraW5nIHcuci50LiBwb3J0IHVzYWdlPw0KSSBoYXZlIG15IGRvdWJ0cyAoZm9y IHRoZSB0aW1lIGJlaW5nKS4NCg0KS2luZCByZWdhcmRzLA0KVXdlDQoNCkZyb206IHJ0Y3dlYiBb bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IEFzdmVyZW4s IFRvbGdhDQpTZW50OiBGcmlkYXksIEp1bHkgMzEsIDIwMTUgMTE6NDkgQU0NClRvOiBDaHJpc3Rl ciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgUm9tYW4gU2hwb3VudA0KQ2M6IDxydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hh dCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNClllcywg eW91ICpjb3VsZCogbWFuZGF0ZSB0aGUgd2hvbGUgdW5pdmVyc2UgdG8gc3VwcG9ydCBpdCwgdGhh dCBzaG91bGRu4oCZdCBiZSB0b28gZGlmZmljdWx0IHRvIGRlc2NyaWJlIG9uIHBhcGVyIDstKQ0K DQpPVE9ILCB3aHk/IElmIHRoZXJlIGFyZSBmb2xrcywgZm9yIHdob20gbm8tcnRjcC1tdXggaXMg anVzdCBmaW5lIChmb3Igd2hhdGV2ZXIgcmVhc29uKSwgbGV0IHRoZWlyIGltcGxlbWVudGF0aW9u cyBmdW5jdGlvbiB0aGF0IHdheSAoYW5kIGxldCB0aGVtIHN1ZmZlciBpZiB0aGlzIGlzIHJlYWxs eSBzdWNoIGEgdGVycmlibGUgdGhpbmcgZnJvbSBpbXBsZW1lbnRhdGlvbiBkaWZmaWN1bHR5IHBl cnNwZWN0aXZlKS4gQW5kIGl0IHdpbGwgYmUgdGhlaXIgcHJvYmxlbSBpZiB0aGF0IGNhdXNlcyBp bnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBmb3IgdGhlbSwgZS5nLiB0aGV5IHdvbuKAmXQgYmUgYWJs ZSB0byB0YWxrIHRvIGJyb3dzZXJzLCB3aGljaCBtYW5kYXRlIHVzZSBvZiBydGNwLW11eC4NCg0K QnJvd3NlcnMgKG9yIGFueSBvdGhlciBpbXBsZW1lbnRhdGlvbikgYWx3YXlzIG1hbmRhdGUgdXNl IG9mIHJ0Y3AtbXV4IGJ5IGFsd2F5cyBvZmZlcmluZyBpdCBhbmQgdGVybWluYXRpbmcgYSBzZXNz aW9uIGlmIHRoZSBhbnN3ZXIgaW5kaWNhdGVzIG5vIHJ0Y3AtbXV4IHN1cHBvcnQuIFNpbWlsYXJs eSwgdGhleSBjYW4gcmVqZWN0IG9mZmVycyB3aXRoIHJ0Y3AtbXV4Lg0KDQpUaGFua3MsDQpUb2xn YQ0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBGcmlkYXksIEp1bHkgMzEsIDIwMTUgMjo0 NCBQTQ0KVG86IEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpi ZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4+OyBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNv bTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+Pg0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZz4+IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQg c2F5IGFib3V0IG11eC9ub24tbXV4DQoNCkhpLA0KDQpJZiB3ZSBjaG9vc2UgdG8gbWFuZGF0ZSB1 c2FnZSBvZiBydGNwLW11eCwgd2UgY291bGQgYWxzbyBtYW5kYXRlIGdhdGV3YXlzIHRvIHN1cHBv cnQgaXQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVybmFyZCBBYm9iYQ0KU2VudDog MzEgSnVseSAyMDE1IDIxOjMyDQpUbzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208 bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4NCkNjOiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpy dGN3ZWJAaWV0Zi5vcmc+PiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNh eSBhYm91dCBtdXgvbm9uLW11eA0KDQpPbiBKdWwgMzEsIDIwMTUsIGF0IDEwOjU3LCBSb21hbiBT aHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90 ZToNCg0KV2h5IHdvdWxkIHRoZSBnYXRld2F5IG5lZWQgdG8gbmVnb3RpYXRlIG5vbi1tdXggaWYg cnRjcC1tdXggaXMgc3VwcG9ydGVkPw0KDQpbQkFdIElNSE8sIEdhdGV3YXlzIHNob3VsZCBiZSBy ZXF1aXJlZCB0byBzdXBwb3J0IG11eCBsaWtlIGFueSBvdGhlciBXRUJSVEMgZW5kcG9pbnQsIGJ1 dCB0aGlzIGlzIG5vdCB3aGF0IGl0IHNheXMgaW4gU2VjdGlvbiAyIG9mIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1nYXRld2F5cyA6DQoNCg0KIklmIGEgZ2F0 ZXdheSBzZXJ2ZXMgYXMgYSBtZWRpYSByZWxheSBpbnRvIGFub3RoZXIgUlRQIGRvbWFpbiwgaXQg TUFZIGNob29zZSB0byBzdXBwb3J0IG9ubHkgZmVhdHVyZXMgYXZhaWxhYmxlIGluIHRoYXQgbmV0 d29yay4gVGhpcyBtZWFucyB0aGF0IGl0IE1BWSBjaG9vc2UgdG8gbm90IHN1cHBvcnQgQnVuZGxl IGFuZCBhbnkgb2YgdGhlIFJUUC8gUlRDUCBleHRlbnNpb25zIHJlbGF0ZWQgdG8gaXQsIFJUQ1At TXV4LCBvciBUcmlja2xlIEljZS4gSG93ZXZlciwgdGhlIGdhdGV3YXkgTVVTVCBzdXBwb3J0IERU TFMtU1JUUCwgc2luY2UgdGhpcyBpcyByZXF1aXJlZCBmb3IgaW50ZXJ3b3JraW5nIHdpdGggV2Vi UlRDIGVuZHBvaW50cy4iDQoNCg0KQXNzdW1pbmcgdGhhdCBicm93c2VycyByZW1vdmUgb3IgZG8g bm90IGltcGxlbWVudCBub24tbXV4LCBpdCBzZWVtcyBwcnVkZW50IHRvIHJlcXVpcmUgZ2F0ZXdh eXMgdG8gc3VwcG9ydCBtdXggc28gYXMgdG8gYXZvaWQgbmVnb3RpYXRpb24gZmFpbHVyZXMuIElm IHdlIG1ha2UgdGhhdCBjaGFuZ2UgdGhlbiBnYXRld2F5cyB3b3VsZCBhbHdheXMgbmVnb3RpYXRl IFJUQ1AtbXV4IHdpdGggYnJvd3NlcnMuDQo= --_000_56C2F665D49E0341B9DF5938005ACDF8196FF450DEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlVJQ1RGb250VGV4dFN0eWxlQm9keTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBk aXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Ng0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WWVzLCBhZ3JlZWQsIHRoZXNlIGFyZSBpbiB0d28gZGlm ZmVyZW50IGNhdGVnb3JpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UlRD UCBtdXggaXMgYW4gb3B0aW1pemF0aW9uIOKAkyBub3Qgc3VwcG9ydGluZyBpdCBkb3VibGVzIHRo ZSBudW1iZXIgb2YgcG9ydHMgdG8gYmUgdXNlZCwgYW5kIHNsb3dzIGRvd24gSUNFIGdhdGhlcmlu Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5XaGVyZWFzIElDRSBub24tc3VwcG9ydCBpcyBhIHNob3dzdG9wcGVy PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TGV0IG1lIGhhdmUgc29tZSBpbnRl cm5hbCBkaXNjdXNzaW9ucyBvbiB0aGlzIHRvcGljIGFuZCBnZXQgYmFjayB0byB0aGUgbGlzdCBu ZXh0IHdlZWsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+S2luZCByZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlV3ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBleHQgQXN2ZXJl biwgVG9sZ2EgW21haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gRnJpZGF5LCBKdWx5IDMxLCAyMDE1IDEyOjAzIFBNPGJyPg0KPGI+VG86PC9iPiBSYXVzY2hl bmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpOyBDaHJpc3RlciBIb2xtYmVyZzsgQmVybmFy ZCBBYm9iYTsgUm9tYW4gU2hwb3VudDxicj4NCjxiPkNjOjwvYj4gJmx0O3J0Y3dlYkBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkg ZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5ZZXMsIGNvbXBsZXRlbHkgYWdyZWUgb24gdGhlIOKAnG5ld+KAnSB2LnMuIOKA nHRoZSB3YXkgdGhpbmdzIHVzZWQgdG8gd29yayBmb3IgbWFueSB5ZWFyc+KAnSBwb2ludCBhcyBm YXIgYXMgcnRjcC1tdXggaXMgY29uY2VybmVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GdXJ0aGVybW9yZSwgLWZv ciBleGFtcGxlLSwgbm90IG1hbmRhdGluZyBJQ0Ugd291bGQgaGF2ZSBzZXJpb3VzIGltcGFjdCBh cyBmYXIgYXMg4oCcbWFraW5nIHRoaW5ncyB3b3JrIGZyb20gZW5kIHVzZXIgcGVyc3BlY3RpdmXi gJ0gaXMgY29uY2VybmVkLiBPVE9ILCB0aGUgc2FtZQ0KIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGhv bGQgdHJ1ZSBmb3IgcnRjcC1tdXguIFR3byBXZWJSVEMgZWxlbWVudHMsIHdoaWNoIGRvIG5vdCB3 YW50IHRvIHVzZSBpdCBjYW4gY29tbXVuaWNhdGUgc3VjY2Vzc2Z1bGx5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhh bmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ub2xnYTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAt IERFL011bmljaCkgWzxhIGhyZWY9Im1haWx0bzp1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbSI+ bWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIEp1bHkgMzEsIDIwMTUgMjo1OCBQTTxicj4NCjxiPlRvOjwvYj4gQXN2ZXJlbiwg VG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iPnRhc3ZlcmVu QHNvbnVzbmV0LmNvbTwvYT4mZ3Q7OyBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPC9hPiZndDs7IEJlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXJu YXJkLmFib2JhQGdtYWlsLmNvbSI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L2E+Jmd0OzsNCiBS b21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPnJvbWFu QHRlbHVyaXguY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUkU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBh Ym91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldlbGw6IG5vbi1tdXggaXMgbm90IGEg 4oCcbmV3IHRoaW5n4oCdIHRoYXQgd2UgbWFuZGF0ZSB0aGUgd2hvbGUgdW5pdmVyc2UgdG8gc3Vw cG9ydCDigJMgaXQgaXMgb24gdGhlIGNvbnRyYXJ5IHRoZSB3YXkgUlRDUC9SVFAgdXNlZCB0byBm dW5jdGlvbiBzaW5jZSB0aGUgYmVnaW5uaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1VWGluZyBpcyB0aGUg 4oCcbmV3IHRoaW5n4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9mIGNv dXJzZSB5b3UgY2FuIHRha2UgYXdheSBsZWdhY3kgc3VwcG9ydCBpZiBuby1vbmUgaXMgaW50ZXJl c3RlZCBpbiBzdXBwb3J0aW5nIGl0IGFueW1vcmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5JIHRoaW5rIHRoaXMgaXMgdGhlIGNvcmUgb2YgdGhlIGRpc2N1c3Npb24gdGhh dCB3ZSBhcmUgaGF2aW5nIOKAkyBkbyB3ZSB3YW50IHRvIHJldGlyZSB0aGUgb3JpZ2luYWwgd2F5 IFJUUCYjNDM7UlRDUCB3ZXJlIHdvcmtpbmcgdy5yLnQuIHBvcnQgdXNhZ2U/DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5JIGhhdmUgbXkgZG91YnRzIChmb3IgdGhlIHRpbWUgYmVpbmcpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Vd2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPmV4dCBBc3ZlcmVuLCBUb2xnYTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIEp1bHkgMzEsIDIwMTUgMTE6NDkgQU08YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1i ZXJnOyBCZXJuYXJkIEFib2JhOyBSb21hbiBTaHBvdW50PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hv dWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5ZZXMsIHlvdSAqPGI+Y291bGQ8L2I+KiBtYW5kYXRlIHRoZSB3aG9sZSB1bml2ZXJzZSB0byBz dXBwb3J0IGl0LCB0aGF0IHNob3VsZG7igJl0IGJlIHRvbyBkaWZmaWN1bHQgdG8gZGVzY3JpYmUg b24gcGFwZXIgOy0pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PVE9ILCB3aHk/IElmIHRoZXJlIGFyZSBmb2xrcywgZm9y IHdob20gbm8tcnRjcC1tdXggaXMganVzdCBmaW5lIChmb3Igd2hhdGV2ZXIgcmVhc29uKSwgbGV0 IHRoZWlyIGltcGxlbWVudGF0aW9ucyBmdW5jdGlvbiB0aGF0IHdheSAoYW5kIGxldCB0aGVtIHN1 ZmZlciBpZg0KIHRoaXMgaXMgcmVhbGx5IHN1Y2ggYSB0ZXJyaWJsZSB0aGluZyBmcm9tIGltcGxl bWVudGF0aW9uIGRpZmZpY3VsdHkgcGVyc3BlY3RpdmUpLiBBbmQgaXQgd2lsbCBiZSB0aGVpciBw cm9ibGVtIGlmIHRoYXQgY2F1c2VzIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIGZvciB0aGVtLCBl LmcuIHRoZXkgd29u4oCZdCBiZSBhYmxlIHRvIHRhbGsgdG8gYnJvd3NlcnMsIHdoaWNoIG1hbmRh dGUgdXNlIG9mIHJ0Y3AtbXV4Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ccm93c2VycyAob3IgYW55IG90aGVyIGlt cGxlbWVudGF0aW9uKSBhbHdheXMgbWFuZGF0ZSB1c2Ugb2YgcnRjcC1tdXggYnkgYWx3YXlzIG9m ZmVyaW5nIGl0IGFuZCB0ZXJtaW5hdGluZyBhIHNlc3Npb24gaWYgdGhlIGFuc3dlciBpbmRpY2F0 ZXMgbm8gcnRjcC1tdXggc3VwcG9ydC4NCiBTaW1pbGFybHksIHRoZXkgY2FuIHJlamVjdCBvZmZl cnMgd2l0aCBydGNwLW11eC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRvbGdhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNo cmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAzMSwgMjAxNSAy OjQ0IFBNPGJyPg0KPGI+VG86PC9iPiBCZXJuYXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWlsdG86 YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iPmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPiZndDs7 IFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSI+cm9t YW5AdGVsdXJpeC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0 bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5 IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgd2UgY2hv b3NlIHRvIG1hbmRhdGUgdXNhZ2Ugb2YgcnRjcC1tdXgsIHdlIGNvdWxkIGFsc28gbWFuZGF0ZSBn YXRld2F5cyB0byBzdXBwb3J0IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PC9hPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IHJ0Y3dlYiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIj5t YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5C ZXJuYXJkIEFib2JhPGJyPg0KPGI+U2VudDo8L2I+IDMxIEp1bHkgMjAxNSAyMTozMjxicj4NCjxi PlRvOjwvYj4gUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXgu Y29tIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNo b3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+T24gSnVsIDMxLCAyMDE1LCBhdCAxMDo1NywgUm9tYW4gU2hwb3VudCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+V2h5IHdvdWxkIHRoZSBnYXRld2F5IG5lZWQgdG8gbmVnb3RpYXRlIG5vbi1t dXggaWYgcnRjcC1tdXggaXMgc3VwcG9ydGVkPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPltCQV0gSU1ITywg R2F0ZXdheXMgc2hvdWxkIGJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgbXV4IGxpa2UgYW55IG90aGVy IFdFQlJUQyBlbmRwb2ludCwgYnV0IHRoaXMgaXMgbm90IHdoYXQgaXQgc2F5cyBpbiBTZWN0aW9u IDIgb2YNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0 Y3dlYi1nYXRld2F5cyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRj d2ViLWdhdGV3YXlzPC9hPiA6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNU Rm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZxdW90O0lmIGEgZ2F0 ZXdheSBzZXJ2ZXMgYXMgYSBtZWRpYSByZWxheSBpbnRvIGFub3RoZXIgUlRQIGRvbWFpbiwgaXQg TUFZIGNob29zZSB0byBzdXBwb3J0IG9ubHkgZmVhdHVyZXMgYXZhaWxhYmxlIGluIHRoYXQgbmV0 d29yay4gVGhpcyBtZWFucyB0aGF0IGl0IE1BWSBjaG9vc2UgdG8gbm90IHN1cHBvcnQgQnVuZGxl IGFuZCBhbnkgb2YgdGhlIFJUUC8gUlRDUCBleHRlbnNpb25zIHJlbGF0ZWQgdG8gaXQsIFJUQ1At TXV4LCBvciBUcmlja2xlIEljZS4gSG93ZXZlciwgdGhlIGdhdGV3YXkgTVVTVCBzdXBwb3J0IERU TFMtU1JUUCwgc2luY2UgdGhpcyBpcyByZXF1aXJlZCBmb3IgaW50ZXJ3b3JraW5nIHdpdGggV2Vi UlRDIGVuZHBvaW50cy4mcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi Pg0KPC9zcGFuPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9k eSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QXNzdW1pbmcgdGhhdCBicm93c2VycyByZW1vdmUg b3IgZG8gbm90IGltcGxlbWVudCBub24tbXV4LCBpdCBzZWVtcyBwcnVkZW50IHRvIHJlcXVpcmUg Z2F0ZXdheXMgdG8gc3VwcG9ydCBtdXggc28gYXMgdG8gYXZvaWQgbmVnb3RpYXRpb24gZmFpbHVy ZXMuIElmIHdlIG1ha2UgdGhhdCBjaGFuZ2UgdGhlbiBnYXRld2F5cyB3b3VsZCBhbHdheXMgbmVn b3RpYXRlIFJUQ1AtbXV4IHdpdGggYnJvd3NlcnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_56C2F665D49E0341B9DF5938005ACDF8196FF450DEMUMBX005nsnin_-- From nobody Fri Jul 31 12:27:46 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB2E1B34D9 for ; Fri, 31 Jul 2015 12:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S57AMq0T7Maj for ; Fri, 31 Jul 2015 12:27:42 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B101B34D4 for ; Fri, 31 Jul 2015 12:27:40 -0700 (PDT) Received: by vkgc186 with SMTP id c186so24516175vkg.0 for ; Fri, 31 Jul 2015 12:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2Z9RLfR8kxch9MLGr0K8doi+N/Um7LMvymY4lP80XtI=; b=h2lbEJcitIc4QTn9FhRtqfQQwHm5n69Ug/hswRmEaU/wwUBCLViXNuWbYY/qdm4GAN 50PDYNA3j/IsOz+m3s5WuD89rKL4S7aUVKUWufECLxwu3N9YmDXhWUJbz39fMpUpGVLH Kzm+/KvT90b//Pl6yJuqvba0RYb7hT3XHqFQFy8oT+dWf95FeAWEoNB5DV0h5K4KBhzi eVB4BKeOFedSgwHqDPdF8L9QwDWXwMT5Nm+MlEiTxThyT9hN6oGiGrudxWhfodle5yII payrnPSKMy/Xr0HNNFqOMURZHOBcVtpCHPkdq41s+6b8QzQymMMCYiGRjvlZdafMMGOU mrfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2Z9RLfR8kxch9MLGr0K8doi+N/Um7LMvymY4lP80XtI=; b=YNjFe+/KrgPcq7b3XSKnFl7tQgOTTRCWYh04ayfLVaf1lAPPMbusGADXTCOQV19AXT NO2SwoA3KWGWEzHVDh59XoyFyM01lRnMVFJHu3Ned9E/3XIenZNieK5qCGDmNMd/KxV8 pbu5+sbX8MR8aNCEk6UI8Ub4H/fJ3R6aGEWDNRxcf9lh5BT8ku4mWZQJOwKeFobWH+j9 HyvpDXtW/zUJBNqYu5X5785nguE8q+kY9Axf+186JxOzDFzFTevDtG6hexvJqnUkJg5W 0xBNdx8OHzPB5r/1Phb/Duzab/C9o0BnMe+VIx5M0RyJLixzdxpEZklAz8S3s68NZekP XRwg== X-Gm-Message-State: ALoCoQnXye43WMSAfV4MXWV1LdisdeCA0ZEcK/AD2wp7esD7t54yEL44FJxjNreROwlGNNFPp9p/ X-Received: by 10.52.186.10 with SMTP id fg10mr6892394vdc.84.1438370859987; Fri, 31 Jul 2015 12:27:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.61.68 with HTTP; Fri, 31 Jul 2015 12:27:20 -0700 (PDT) In-Reply-To: References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> From: Justin Uberti Date: Fri, 31 Jul 2015 12:27:20 -0700 Message-ID: To: Daniel Roesler Content-Type: multipart/alternative; boundary=bcaec54864ba2a68c0051c30d0f9 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 19:27:44 -0000 --bcaec54864ba2a68c0051c30d0f9 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 11:59 AM, Daniel Roesler wrote: > I very much sympathize with carlo's frustration with this working > group. So far the response here to the introduced privacy exploits has > been pretty appalling. As you mentioned in the other consent thread, > this standard is the first time a browser can send requests over > non-default route network interfaces. > > _This is a life threatening issue!_ > > Many, many, many Chinese/Arab/Persian users buy VPNs to get around > censorship and participate in free speech. The default configurations > for these VPNs set the default route, but often still allow requests > to be made over the real network interface (due to the way Windows > configures VPNs). Thus, when ICE sends STUN requests through that real > network interface, they expose the real IP of the VPN user. So any > website can silently identify VPN users, which can lead to a knock a > the door. If you don't believe me, just search for "ipleak" on > twitter[1] and see how many foreign language references there are to > the exploit test page. > Very real implication: Loading a website (or even an embedded ad) is > now much more life-threatening than it was before. > > Thanks everyone! Great work! > > I've heard many times on threads here that this is the fault of the > VPN user for not configuring their VPN better. I couldn't disagree > more. Up until WebRTC, the browser wasn't able to make non-default > route requests, which means that up until WebRTC, you couldn't expose > your real IP just by visiting a webpage. So WebRTC is the thing that > triggered exposure of the user, not their VPN configuration. Also, > blaming the user when they are using the default configuration (and > don't know any better) and you introduced something that exposes them > is offensive. I don't really want to debate nits, but this is not true. Flash has had this 'feature', since the beginning of the modern browser era. Regardless, we think we can do better. > So far there have been two proposed solutions, both of which help > solve the issue. > > 1. Restrict STUN requests to default route. This obviously has > performance implications, so I understand why people here are hesitant > to require this. > > 2. Prompt the user for consent before sending STUN requests. This > would prevent silent IP leak exploits like the one we saw in the wild > embedded on the NYTimes. > > How about a combined solution? > > a) By default, restrict STUN requests to the default route. > > b) Add an option to PeerConnection to use non-default routes, too. > > c) When createOffer() or createAnswer() is called, if the non-default > routes flag is present, ask the user for consent. If there are video > or audio streams already attached to the peerconnection, assume that > consent has already been obtained (since getUserMedia asks for > consent). > > This solution is backwards compatible with existing webapps, and > minimizes the introduction of any new prompts. The only change in user > experience is when a webapp explicitly wants to use non-default routes > for their connection. If a webapp is okay with the default route, then > they can silently add a data channel (no prompts). > I very much do not agree with Justin/Chrome's proposal to add a > configuration extension that requires a user to opt-in to restricting > non-default route STUN requests. That's like having the setting to > show the warning for self-signed https certificates turned off by > default and asking users to turn it on if they really want to be safe. > The default behavior should be safe. > > I concur. As I said, what we have done in Chrome so far is just the first step. Opt-in allows us to ensure the solution a) works and b) doesn't break anything, in a more contained population. Once we are confident with this, we can move forward with a more comprehensive solution. --bcaec54864ba2a68c0051c30d0f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 11:59 AM, Daniel Roesler <= diafygi@gmail.com> wrote:
I very much sympathiz= e with carlo's frustration with this working
group. So far the response here to the introduced privacy exploits has
been pretty appalling. As you mentioned in the other consent thread,
this standard is the first time a browser can send requests over
non-default route network interfaces.

<strong>_This is a life threatening issue!_</strong>

Many, many, many Chinese/Arab/Persian users buy VPNs to get around
censorship and participate in free speech. The default configurations
for these VPNs set the default route, but often still allow requests
to be made over the real network interface (due to the way Windows
configures VPNs). Thus, when ICE sends STUN requests through that real
network interface, they expose the real IP of the VPN user. So any
website can silently identify VPN users, which can lead to a knock a
the door. If you don't believe me, just search for "ipleak" o= n
twitter[1] and see how many foreign language references there are to
the exploit test page.=C2=A0
=C2= =A0

Very real implication: Loading a website (or even an embedded ad) is
now much more life-threatening than it was before.

Thanks everyone! Great work!

I've heard many times on threads here that this is the fault of the
VPN user for not configuring their VPN better. I couldn't disagree
more. Up until WebRTC, the browser wasn't able to make non-default
route requests, which means that up until WebRTC, you couldn't expose your real IP just by visiting a webpage. So WebRTC is the thing that
triggered exposure of the user, not their VPN configuration. Also,
blaming the user when they are using the default configuration (and
don't know any better) and you introduced something that exposes them is offensive.=C2=A0

I don't really want= to debate nits, but this is not true. Flash has had this 'feature'= , since the beginning of the modern browser era.
Regardless, we t= hink we can do better.
=C2=A0
So far there have been two proposed solutions, both of which help
solve the issue.

1. Restrict STUN requests to default route. This obviously has
performance implications, so I understand why people here are hesitant
to require this.

2. Prompt the user for consent before sending STUN requests. This
would prevent silent IP leak exploits like the one we saw in the wild
embedded on the NYTimes.

How about a combined solution?

a) By default, restrict STUN requests to the default route.

b) Add an option to PeerConnection to use non-default routes, too.

c) When createOffer() or createAnswer() is called, if the non-default
routes flag is present, ask the user for consent. If there are video
or audio streams already attached to the peerconnection, assume that
consent has already been obtained (since getUserMedia asks for
consent).

This solution is backwards compatible with existing webapps, and
minimizes the introduction of any new prompts. The only change in user
experience is when a webapp explicitly wants to use non-default routes
for their connection. If a webapp is okay with the default route, then
they can silently add a data channel (no prompts).

I very much do not agree with Justin/Chrome's proposal to add a
configuration extension that requires a user to opt-in to restricting
non-default route STUN requests. That's like having the setting to
show the warning for self-signed https certificates turned off by
default and asking users to turn it on if they really want to be safe.
The default behavior should be safe.


I concur. As I said, what we have done= in Chrome so far is just the first step.=C2=A0

Op= t-in allows us to ensure the solution a) works and b) doesn't break any= thing, in a more contained population. Once we are confident with this, we = can move forward with a more comprehensive solution.
--bcaec54864ba2a68c0051c30d0f9-- From nobody Fri Jul 31 12:28:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23A71B2F42 for ; Fri, 31 Jul 2015 12:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u61fZ1pIY4Az for ; Fri, 31 Jul 2015 12:28:08 -0700 (PDT) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0CE1B2EFC for ; Fri, 31 Jul 2015 12:28:08 -0700 (PDT) Received: by iodd187 with SMTP id d187so94962714iod.2 for ; Fri, 31 Jul 2015 12:28:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=odcTO0agekFzSA62YY1v1z2XfV3Y7JVy6Zj9NlaFHUM=; b=K5S2CCbDbADlx4J5IBLyEwtXzx5gTvaHJN5mDFUX2Guny3aiRmXi9ZB0/sbbbqp2Ww i2/yiP4VATnXv/wKG/XiITToIzFsrVFdqBw7144ICcIeW9qD/nyZKURUQ0h8OANFgvhK K1g8FkjO6rsqA1UI1pdf/Y9Vpap1lz62peou/UfUGdTdD5Zk9wiffH+Yi5PicTGhWIct T5mE3gGPCCsORTdobdv/eu8Bv3fBfvqIa4CNXlcTLteaWf8VFBZQwah/f2lVIcNPG/UG vbTZp3vCn7M4HJtql/eKx0ikZCk44rY47QgBrIOHjcAjl06pdp/187FzQGOoiVLLwBGc ZasQ== X-Gm-Message-State: ALoCoQlcmRri4V/BKAidz+aP5IJhg6k900LQVsuaqjiUSRDfcMJNqojw9iHn5dMZ3dYtMS8vC+eb X-Received: by 10.107.4.6 with SMTP id 6mr7597188ioe.49.1438370887841; Fri, 31 Jul 2015 12:28:07 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com. [209.85.213.169]) by smtp.gmail.com with ESMTPSA id w4sm2935455igl.22.2015.07.31.12.28.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 12:28:06 -0700 (PDT) Received: by iggf3 with SMTP id f3so23286506igg.1 for ; Fri, 31 Jul 2015 12:28:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.141.164 with SMTP id rp4mr9140264igb.2.1438370885721; Fri, 31 Jul 2015 12:28:05 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Fri, 31 Jul 2015 12:28:05 -0700 (PDT) In-Reply-To: References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> Date: Fri, 31 Jul 2015 15:28:05 -0400 Message-ID: From: Roman Shpount To: Daniel Roesler Content-Type: multipart/alternative; boundary=089e01295380b2e477051c30d157 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 19:28:11 -0000 --089e01295380b2e477051c30d157 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 2:59 PM, Daniel Roesler wrote: > I very much sympathize with carlo's frustration with this working > group. So far the response here to the introduced privacy exploits has > been pretty appalling. As you mentioned in the other consent thread, > this standard is the first time a browser can send requests over > non-default route network interfaces. > > _This is a life threatening issue!_ > I actually appreciate the seriousness of the issue. I think part of the reason this group did not respond in more timely manner is that not everyone realized the behavior change (use of non-default routes). Once it was clarified, the issue started to be handled. I understand that this and any other security issue can be extremely frustrating to the end users, but people, including people who build web browsers or design web browser standards do make mistakes. > Many, many, many Chinese/Arab/Persian users buy VPNs to get around > censorship and participate in free speech. The default configurations > for these VPNs set the default route, but often still allow requests > to be made over the real network interface (due to the way Windows > configures VPNs). Thus, when ICE sends STUN requests through that real > network interface, they expose the real IP of the VPN user. So any > website can silently identify VPN users, which can lead to a knock a > the door. If you don't believe me, just search for "ipleak" on > twitter[1] and see how many foreign language references there are to > the exploit test page. > > Very real implication: Loading a website (or even an embedded ad) is > now much more life-threatening than it was before. > > Thanks everyone! Great work! > Once again, it took a while to understand the real nature of the problem. At least for me it took a while to identify what exactly changed and why it is different from previous browser behavior. I've heard many times on threads here that this is the fault of the > VPN user for not configuring their VPN better. I couldn't disagree > more. Up until WebRTC, the browser wasn't able to make non-default > route requests, which means that up until WebRTC, you couldn't expose > your real IP just by visiting a webpage. So WebRTC is the thing that > triggered exposure of the user, not their VPN configuration. Also, > blaming the user when they are using the default configuration (and > don't know any better) and you introduced something that exposes them > is offensive. > I actually agree with you here. I've spent considerable amount of effort to explain the problem with VPN since I did not think it was completely understood. > So far there have been two proposed solutions, both of which help > solve the issue. > > 1. Restrict STUN requests to default route. This obviously has > performance implications, so I understand why people here are hesitant > to require this. > > 2. Prompt the user for consent before sending STUN requests. This > would prevent silent IP leak exploits like the one we saw in the wild > embedded on the NYTimes. > > How about a combined solution? > > a) By default, restrict STUN requests to the default route. > > b) Add an option to PeerConnection to use non-default routes, too. > > c) When createOffer() or createAnswer() is called, if the non-default > routes flag is present, ask the user for consent. If there are video > or audio streams already attached to the peerconnection, assume that > consent has already been obtained (since getUserMedia asks for > consent). > > This solution is backwards compatible with existing webapps, and > minimizes the introduction of any new prompts. The only change in user > experience is when a webapp explicitly wants to use non-default routes > for their connection. If a webapp is okay with the default route, then > they can silently add a data channel (no prompts). > Justin is probably the best person to evaluate this solution. It looks workable to me. I very much do not agree with Justin/Chrome's proposal to add a > configuration extension that requires a user to opt-in to restricting > non-default route STUN requests. That's like having the setting to > show the warning for self-signed https certificates turned off by > default and asking users to turn it on if they really want to be safe. > The default behavior should be safe. > > I think you do not correctly characterize what Justin/Chrome is doing here. It is not a final solution. It is a way to test the final solution before it gets widely deployed. Since this is a major change for the browsers I appreciate the need to deploy this carefully and gradually. _____________ Roman Shpount --089e01295380b2e477051c30d157 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 31, 2015 at 2:59 PM, Daniel Roesler <diafygi@gmail.com> wrote:
I very much sympathize with = carlo's frustration with this working
group. So far the response here to the introduced privacy exploits has
been pretty appalling. As you mentioned in the other consent thread,
this standard is the first time a browser can send requests over
non-default route network interfaces.

<strong>_This is a life threatening issue!_</strong>

I actually appreciate the seriousness of the issu= e. I think part of the reason this group did not respond in more timely man= ner is that not everyone realized the behavior change (use of non-default r= outes). Once it was clarified, the issue started to be handled. I understan= d that this and any other security issue can be extremely frustrating to th= e end users, but people, including people who build web browsers or design = web browser standards do make mistakes.
=C2=A0
Many, many, many Chinese/Arab/Persian users buy VPNs to g= et around
censorship and participate in free speech. The default configurations
for these VPNs set the default route, but often still allow requests
to be made over the real network interface (due to the way Windows
configures VPNs). Thus, when ICE sends STUN requests through that real
network interface, they expose the real IP of the VPN user. So any
website can silently identify VPN users, which can lead to a knock a
the door. If you don't believe me, just search for "ipleak" o= n
twitter[1] and see how many foreign language references there are to
the exploit test page.

Very real implication: Loading a website (or even an embedded ad) is
now much more life-threatening than it was before.

Thanks everyone! Great work!

Once again= , it took a while to understand the real nature of the problem. At least fo= r me it took a while to identify what exactly changed and why it is differe= nt from previous browser behavior.

I've heard many times on threads here that this is the fault= of the
VPN user for not configuring their VPN better. I couldn't disagree
more. Up until WebRTC, the browser wasn't able to make non-default
route requests, which means that up until WebRTC, you couldn't expose your real IP just by visiting a webpage. So WebRTC is the thing that
triggered exposure of the user, not their VPN configuration. Also,
blaming the user when they are using the default configuration (and
don't know any better) and you introduced something that exposes them is offensive.

I actually agree with you= here. I've spent considerable amount of effort to explain the problem = with VPN since I did not think it was completely understood.
=C2= =A0
So far there have been two proposed= solutions, both of which help
solve the issue.

1. Restrict STUN requests to default route. This obviously has
performance implications, so I understand why people here are hesitant
to require this.

2. Prompt the user for consent before sending STUN requests. This
would prevent silent IP leak exploits like the one we saw in the wild
embedded on the NYTimes.

How about a combined solution?

a) By default, restrict STUN requests to the default route.

b) Add an option to PeerConnection to use non-default routes, too.

c) When createOffer() or createAnswer() is called, if the non-default
routes flag is present, ask the user for consent. If there are video
or audio streams already attached to the peerconnection, assume that
consent has already been obtained (since getUserMedia asks for
consent).

This solution is backwards compatible with existing webapps, and
minimizes the introduction of any new prompts. The only change in user
experience is when a webapp explicitly wants to use non-default routes
for their connection. If a webapp is okay with the default route, then
they can silently add a data channel (no prompts).
Justin is probably the best person to evaluate this solution. I= t looks workable to me.

= I very much do not agree with Justin/Chrome's proposal to add a
configuration extension that requires a user to opt-in to restricting
non-default route STUN requests. That's like having the setting to
show the warning for self-signed https certificates turned off by
default and asking users to turn it on if they really want to be safe.
The default behavior should be safe.


I think you do not correctly character= ize what Justin/Chrome is doing here. It is not a final solution. It is a w= ay to test the final solution before it gets widely deployed. Since this is= a major change for the browsers I appreciate the need to deploy this caref= ully and gradually.
_____________<= br>Roman Shpount
=C2=A0
--089e01295380b2e477051c30d157-- From nobody Fri Jul 31 12:35:46 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F5F1B34D7 for ; Fri, 31 Jul 2015 12:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsB6iWVcdSyz for ; Fri, 31 Jul 2015 12:35:44 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D811B34D6 for ; Fri, 31 Jul 2015 12:35:43 -0700 (PDT) Received: by igr7 with SMTP id 7so22823132igr.0 for ; Fri, 31 Jul 2015 12:35:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EfrEhKrObWocwk5uyF44F5xg4ZNVC47cKNBwcgZHXEo=; b=M5ULnBtn4/BY9RjxAej5DjOjsMKGrel9uS7jDY9G7dSsF9e4eU0+xrqje9giTufHu9 iDPLL91vteTbcCjLLymsJFpzpS0MdzZ/yqyX3Q3FhSD7aW1OCyJvufn9eTyMsTs15A7t n/RBb5eap/+v14EdfUW2GII2GApPDHTjx8mbeqxLRHxy9UeGxIdLXq4cboOyHjQlEZqC HSF6OCmnSF3iHeL6K+bl2SPcxhitZp6Et2BHeOYb7dizSyIlQsICJ4uMFa5rwoXt6OMR +aR6nNfrGxIvJpIZVdvNDvQ/YhDWZLbIVKSwLOzPJpmmaYCiOc1joftNRyaRNYyobuMM IyIA== X-Gm-Message-State: ALoCoQlaByzLM2UmWVMPQjvX/yWkB/XxUoWfIwzmEkQUXZ7CuxOZVAgyyWDUbrgBhkVaXkFNKr72 X-Received: by 10.50.60.68 with SMTP id f4mr8854715igr.94.1438371343433; Fri, 31 Jul 2015 12:35:43 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id g123sm3961930iog.31.2015.07.31.12.35.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 12:35:42 -0700 (PDT) Received: by ioea135 with SMTP id a135so95244699ioe.1 for ; Fri, 31 Jul 2015 12:35:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.13.201 with SMTP id 192mr8199203ion.70.1438371341568; Fri, 31 Jul 2015 12:35:41 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Fri, 31 Jul 2015 12:35:41 -0700 (PDT) In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF8196FF34B@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B348E2D1B@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF34B@DEMUMBX005.nsn-intra.net> Date: Fri, 31 Jul 2015 15:35:41 -0400 Message-ID: From: Roman Shpount To: "Rauschenbach, Uwe (Nokia - DE/Munich)" Content-Type: multipart/alternative; boundary=001a113fd5e0deb3b8051c30ec73 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 19:35:45 -0000 --001a113fd5e0deb3b8051c30ec73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 31, 2015 at 2:44 PM, Rauschenbach, Uwe (Nokia - DE/Munich) < uwe.rauschenbach@nokia.com> wrote: > I can accept =E2=80=9Cmust be offered=E2=80=9D. But I do not understand = =E2=80=9Cmust be accepted > if offered=E2=80=9D. This is against the spirit of negotiation. > > If the other endpoint does not support rtcp-mux it rejects this. Am I > missing something? > > > I am trying to differentiate here end points that can be compliant with RFC 5761 by never offering rtcp-mux and rejecting all offers with rtcp-mux. What we are proposing here is that rtcp-mux is actually used for all the RTP/RTCP streams, not just correctly negotiated away. _____________ Roman Shpount --001a113fd5e0deb3b8051c30ec73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 31, 2015 at 2:44 PM, Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com> wrote:

I can accept =E2=80=9Cmust be offered=E2=80=9D. But I do not unders= tand =E2=80=9Cmust be accepted if offered=E2=80=9D. This is against the spi= rit of negotiation.

If the other endpoint does not support rt= cp-mux it rejects this. Am I missing something?=C2=A0



I am trying to differentiate here end points that can be compliant with RF= C 5761 by never offering rtcp-mux and rejecting all offers with rtcp-mux. W= hat we are proposing here is that rtcp-mux is actually used for all the RTP= /RTCP streams, not just correctly negotiated away.
_____________
Roman Shpount
=C2=A0
--001a113fd5e0deb3b8051c30ec73-- From nobody Fri Jul 31 12:37:20 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C7D1ACDDF for ; Fri, 31 Jul 2015 12:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HntroGYO5vo for ; Fri, 31 Jul 2015 12:37:13 -0700 (PDT) Received: from Mail3.kpnnet.org (mail3.kpnnet.org [192.58.226.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62141ACDD9 for ; Fri, 31 Jul 2015 12:37:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,586,1432591200"; d="scan'208,217";a="164691192" Received: from w2005.kpnnl.local ([10.75.82.3]) by Mail3.kpnnet.org with ESMTP; 31 Jul 2015 21:37:10 +0200 Received: from W3017.kpnnl.local (158.67.247.43) by W2005.kpnnl.local (10.75.82.3) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 31 Jul 2015 21:37:10 +0200 Received: from W3018.kpnnl.local ([fe80::901f:81cf:ea70:9e75]) by W3017.kpnnl.local ([fe80::ddda:7932:7ab4:61e1%24]) with mapi id 14.03.0235.001; Fri, 31 Jul 2015 21:37:10 +0200 From: To: Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyvx8tGyfD9kDSky8j5YMyGSqOZ30w60AgAB5cYCAAAlpAIAAEkYAgAAd/QCAACs4gIAACLkAgAADXACAAAogAIAAALAAgABBtOY= Date: Fri, 31 Jul 2015 19:37:09 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A083DF1FE6514C848A1D4A43D6DD5CEDkpncom_" MIME-Version: 1.0 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 19:37:19 -0000 --_000_A083DF1FE6514C848A1D4A43D6DD5CEDkpncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When we choose this path, can we still support webrtc that is applied in de= vices / no-browser's? Richard Op 31 jul. 2015 om 19:42 heeft Eric Rescorla > het volgende geschreven: On Fri, Jul 31, 2015 at 7:39 PM, Bernard Aboba > wrote: On Jul 31, 2015, at 10:03, Eric Rescorla = > wrote: Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP, but= MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? That wo= uld work for us. [BA] Yes. Since RTP-Usage already requires mux support, we would only need= to change the sentence requiring non-mux to make it optional. In this case, would browsers be able to reject attempts to set the policy t= o anything other than always-mux? Because I'm pretty sure that's what both we and Chrome want to do. [BA] Yes, that should be possible. If non-mux is optional, then an implemen= tation that doesn't support it would only allow setting the policy to alway= s mux. That seems satisfactory to me, since it means we can remove the code for non-mux. -Ekr _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_A083DF1FE6514C848A1D4A43D6DD5CEDkpncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
When we choose this path, can we still support webrtc that is applied = in devices / no-browser's?

Richard 

Op 31 jul. 2015 om 19:42 heeft Eric Rescorla <ekr@rtfm.com> het volgende geschreven:



On Fri, Jul 31, 2015 at 7:39 PM, Bernard Aboba <= span dir=3D"ltr"> <bernard.ab= oba@gmail.com> wrote:
On Jul 31, 2015, at 10:03, Eric Rescorla <ekr@rtfm.com> wrote:
Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP= , but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? Th= at would work for us.
[BA] Yes.  Since RTP-Usage already requires mux support, we would= only need to change the sentence requiring non-mux to make it optional.&nb= sp;

In this case, would browsers be able to reject attempts to set the pol= icy to
anything other than always-mux? Because I'm pretty sure that's what bo= th
we and Chrome want to do.
[BA] Yes, that should be possible. If non-mux is optional, then an imp= lementation that doesn't support it would only allow setting the policy to = always mux. 

That seems satisfactory to me, since it means we= can remove the code for
non-mux.

-Ekr

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_A083DF1FE6514C848A1D4A43D6DD5CEDkpncom_-- From nobody Fri Jul 31 13:10:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48251B2F39 for ; Fri, 31 Jul 2015 13:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8QGW0KzOQV6 for ; Fri, 31 Jul 2015 13:10:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204A21ACD59 for ; Fri, 31 Jul 2015 13:10:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0DE97BE35; Fri, 31 Jul 2015 21:10:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRk5urMYfZrr; Fri, 31 Jul 2015 21:10:22 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.103]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 70389BE32; Fri, 31 Jul 2015 21:10:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438373422; bh=TgunEFOeGdGl688Kt0Woa62oz+fGJKHoR3FfH8HOcME=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=IBRmWz0D2Hc+WnuTQC3PTFpHlulHw/sKApz6p5aInDoCFIum2k5im8wezgU9Cwjnh 0TzJivMvFXvpDpE3t0p0Csp1deOeYf1gEOmdomLmxupe7wQLzVdaz4Fy59HAbhI0xi YczzHqYp8+QtJWoFAX5Domie1OkG8+A6s7VezRFk= Message-ID: <55BBD62B.3010209@cs.tcd.ie> Date: Fri, 31 Jul 2015 21:10:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Roman Shpount , Daniel Roesler References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 20:10:27 -0000 On 31/07/15 20:28, Roman Shpount wrote: > I actually appreciate the seriousness of the issue. I'm wondering if there's anything we could (get someone to) do so that issues like this get handled better in future? For example I'm wondering if a description of the various ways in which current VPN services operate and some of the consequences when things go wrong might be useful input to WGs faced with similar issues. I've no idea if someone would be motivated to write that up, nor for how long such text would be useful but I suspect there's a document there that'd be good to have. (Or if there's a non-RFC that has a good survey/description then a pointer to that would be good.) Anyway, I'd be happy to help someone who was willing and able to try that with any process stuff. Cheers, S. From nobody Fri Jul 31 13:21:21 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C791ACDDB for ; Fri, 31 Jul 2015 13:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdWg-pBWPPnt for ; Fri, 31 Jul 2015 13:21:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53F51ACD76 for ; Fri, 31 Jul 2015 13:21:18 -0700 (PDT) X-AuditID: c1b4fb25-f79446d000003bb1-64-55bbd8bc6fa2 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8C.2C.15281.CB8DBB55; Fri, 31 Jul 2015 22:21:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0210.002; Fri, 31 Jul 2015 22:21:16 +0200 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: Stephen Farrell , Roman Shpount , Daniel Roesler Thread-Topic: [rtcweb] Prompt for mic, camera *and* network access Thread-Index: AQHQvvsbBNn/+NXHz0ah2t2MmxsPZZ3canoAgAAwPACAAC5igIAA3hiAgAaG/gCAES7XAIAAM/WAgABVdYCAAAgfgIAAC82AgAAklYA= Date: Fri, 31 Jul 2015 20:21:15 +0000 Message-ID: References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> <55BBD62B.3010209@cs.tcd.ie> In-Reply-To: <55BBD62B.3010209@cs.tcd.ie> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <422A94F6F6A0F74F931593CB4F74264B@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM+Jvje7eG7tDDX5MY7NYM62R1eJYXxeb Re/HJYwWMy5MZbZY+6+d3WL63mvsDmweVyZcYfVY232VzWPnrLvsHkuW/GTyuDWlwOPovP2s AWxRXDYpqTmZZalF+nYJXBmT2/axFSzjqTj6+TtTA+Mf7i5GTg4JAROJqxP/MkPYYhIX7q1n A7GFBI4yStybo9PFyAVkL2aUeHGmnxEkwSbgLdHWcpgFxBYRqJBY0XGEDaSIGaTh0NKDrF2M HBzCAo4Sm7sDIWqcJLr+9LNC2GUSD260g9ksAqoSN1/uBFvMK2AtMfPgBlaIZTNYJfZuPs0E kuAU0JQ4/+EG2GJGAVmJ+9/vgS1mFhCXuPVkPhPE1QISS/ach/pAVOLl439gC0QF9CQ+nfjI AhFXklh7eDsLyG3MQDPX79KHGGMt8fnyLjYIW1FiSvdDdoh7BCVOznzCMoFRYhaSbbMQumch 6Z6FpHsWku4FjKyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQJj+uCW36o7GC+/cTzEKMDB qMTDu+DarlAh1sSy4srcQ4zSHCxK4rwzNueFCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCc 5Cj4L+/fa9uuM1mf7/aqN03tXeZ55OirsJIdJx7rn5JYulXuxKLTrx+uND8qkf1uEVfgYoen 20P5LWsCM+bcjHerOT//ghPD50mXV4hFL2d9+yDvsHB3deq2/Q8umAmc/fPI9vh3c75CQVav e4tr2HYanGu7qpJzVChkS8ZludKYE//q7pktVmIpzkg01GIuKk4EAFBcWFjKAgAA Archived-At: Cc: "rtcweb@ietf.org" , W3C WEBRTC Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 20:21:20 -0000 R29vZCBpZGVhLiBTb21ldGhpbmcgbGlrZSB0aGF0IGlzIHVzZWZ1bC4gQW5kIEkgdGhpbmsgc29t ZSBXM0MgV0cocykgbWF5DQpoYXZlIGFuIGludGVyZXN0L3Jlc3BvbnNpYmlsaXR5IGFsc28gaW4g aW1wcm92aW5nIG9uIHRoaXMuDQoNClJlZ2FyZHMNCkfDtnJhbg0KDQoNCj4NCj4NCj5PbiAzMS8w Ny8xNSAyMDoyOCwgUm9tYW4gU2hwb3VudCB3cm90ZToNCj4+IEkgYWN0dWFsbHkgYXBwcmVjaWF0 ZSB0aGUgc2VyaW91c25lc3Mgb2YgdGhlIGlzc3VlLg0KPg0KPkknbSB3b25kZXJpbmcgaWYgdGhl cmUncyBhbnl0aGluZyB3ZSBjb3VsZCAoZ2V0IHNvbWVvbmUgdG8pDQo+ZG8gc28gdGhhdCBpc3N1 ZXMgbGlrZSB0aGlzIGdldCBoYW5kbGVkIGJldHRlciBpbiBmdXR1cmU/DQo+DQo+Rm9yIGV4YW1w bGUgSSdtIHdvbmRlcmluZyBpZiBhIGRlc2NyaXB0aW9uIG9mIHRoZSB2YXJpb3VzDQo+d2F5cyBp biB3aGljaCBjdXJyZW50IFZQTiBzZXJ2aWNlcyBvcGVyYXRlIGFuZCBzb21lIG9mIHRoZQ0KPmNv bnNlcXVlbmNlcyB3aGVuIHRoaW5ncyBnbyB3cm9uZyBtaWdodCBiZSB1c2VmdWwgaW5wdXQgdG8N Cj5XR3MgZmFjZWQgd2l0aCBzaW1pbGFyIGlzc3Vlcy4NCj4NCj5JJ3ZlIG5vIGlkZWEgaWYgc29t ZW9uZSB3b3VsZCBiZSBtb3RpdmF0ZWQgdG8gd3JpdGUgdGhhdA0KPnVwLCBub3IgZm9yIGhvdyBs b25nIHN1Y2ggdGV4dCB3b3VsZCBiZSB1c2VmdWwgYnV0IEkgc3VzcGVjdA0KPnRoZXJlJ3MgYSBk b2N1bWVudCB0aGVyZSB0aGF0J2QgYmUgZ29vZCB0byBoYXZlLiAoT3IgaWYNCj50aGVyZSdzIGEg bm9uLVJGQyB0aGF0IGhhcyBhIGdvb2Qgc3VydmV5L2Rlc2NyaXB0aW9uIHRoZW4NCj5hIHBvaW50 ZXIgdG8gdGhhdCB3b3VsZCBiZSBnb29kLikNCj4NCj5Bbnl3YXksIEknZCBiZSBoYXBweSB0byBo ZWxwIHNvbWVvbmUgd2hvIHdhcyB3aWxsaW5nIGFuZA0KPmFibGUgdG8gdHJ5IHRoYXQgd2l0aCBh bnkgcHJvY2VzcyBzdHVmZi4NCj4NCj5DaGVlcnMsDQo+Uy4NCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj5y dGN3ZWJAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYg0KDQo= From nobody Fri Jul 31 13:30:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154981ACE93 for ; Fri, 31 Jul 2015 13:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEkJRDtrjYLF for ; Fri, 31 Jul 2015 13:30:46 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C332B1ACE30 for ; Fri, 31 Jul 2015 13:30:45 -0700 (PDT) Received: by wibud3 with SMTP id ud3so45618223wib.0 for ; Fri, 31 Jul 2015 13:30:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=h6HWJ3ten3bicXv4C0Gdx4gauzG2ibhuuT8xdPaNMmM=; b=BLnVS1WMlP4C2GgSo+KUB/GdQsw09g78pPjP0HmO9SKxKYM1VxsAguUoWq/EL1J2DL r7dUdHdHtw7I3jv10mGIc3d+Lipm+YWEUaUepBGQvo+FNVHSXnmYZdN+u9+/QuXqRjFX NTAdXITxpOqV9t/HWvpfUmqLLBTCo9Sg4H5Urt0bsD26wfgsrNku7vwDdA6DjA0SkXnX 1R/0JQLMKTYVImIf6blNzE67t4xryp0REyzHmN5UjmQkLNNpLjIFnaWpmrDLjMVMIoRa yt3l/OQjt9tqrv0qtxnW9DJJKez1Q2f2nu6T4fvwj5RIDL7sgoQjFSWbH5y9+CrDfd5/ fXYQ== X-Gm-Message-State: ALoCoQkMPMy0r7LfZ480r74wX1JZpdgisbCmMNb4ot0v166RnslzmHSBtq+EXQ9OiKgKgTtCuSr1 X-Received: by 10.180.75.78 with SMTP id a14mr10449073wiw.68.1438374644573; Fri, 31 Jul 2015 13:30:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.75 with HTTP; Fri, 31 Jul 2015 13:30:05 -0700 (PDT) In-Reply-To: References: <55352067.6070007@nostrum.com> <20150421154657.GA4071@lo.psyced.org> <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> From: Eric Rescorla Date: Fri, 31 Jul 2015 22:30:05 +0200 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=f46d0438eb9dbe7aba051c31b1e6 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 20:30:48 -0000 --f46d0438eb9dbe7aba051c31b1e6 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 9:27 PM, Justin Uberti wrote: > > > On Fri, Jul 31, 2015 at 11:59 AM, Daniel Roesler > wrote: > >> I very much sympathize with carlo's frustration with this working >> group. So far the response here to the introduced privacy exploits has >> been pretty appalling. As you mentioned in the other consent thread, >> this standard is the first time a browser can send requests over >> non-default route network interfaces. >> >> _This is a life threatening issue!_ >> >> Many, many, many Chinese/Arab/Persian users buy VPNs to get around >> censorship and participate in free speech. The default configurations >> for these VPNs set the default route, but often still allow requests >> to be made over the real network interface (due to the way Windows >> configures VPNs). Thus, when ICE sends STUN requests through that real >> network interface, they expose the real IP of the VPN user. So any >> website can silently identify VPN users, which can lead to a knock a >> the door. If you don't believe me, just search for "ipleak" on >> twitter[1] and see how many foreign language references there are to >> the exploit test page. > > > > >> Very real implication: Loading a website (or even an embedded ad) is >> now much more life-threatening than it was before. >> >> Thanks everyone! Great work! >> >> I've heard many times on threads here that this is the fault of the >> VPN user for not configuring their VPN better. I couldn't disagree >> more. Up until WebRTC, the browser wasn't able to make non-default >> route requests, which means that up until WebRTC, you couldn't expose >> your real IP just by visiting a webpage. So WebRTC is the thing that >> triggered exposure of the user, not their VPN configuration. Also, >> blaming the user when they are using the default configuration (and >> don't know any better) and you introduced something that exposes them >> is offensive. > > > I don't really want to debate nits, but this is not true. Flash has had > this 'feature', since the beginning of the modern browser era. > Regardless, we think we can do better. > > See also: https://www.usenix.org/system/files/conference/foci12/foci12-final8.pdf and http://www.eecs.qmul.ac.uk/~hamed/papers/PETS2015VPN.pdf -Ekr --f46d0438eb9dbe7aba051c31b1e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 9:27 PM, Justin Uberti <juberti@google.com> wrote:

=

On Fri, Jul 31, 2015 at 11:59 AM, Daniel Roesler = <diafygi@gmail.co= m> wrote:
I very much sympa= thize with carlo's frustration with this working
group. So far the response here to the introduced privacy exploits has
been pretty appalling. As you mentioned in the other consent thread,
this standard is the first time a browser can send requests over
non-default route network interfaces.

<strong>_This is a life threatening issue!_</strong>

Many, many, many Chinese/Arab/Persian users buy VPNs to get around
censorship and participate in free speech. The default configurations
for these VPNs set the default route, but often still allow requests
to be made over the real network interface (due to the way Windows
configures VPNs). Thus, when ICE sends STUN requests through that real
network interface, they expose the real IP of the VPN user. So any
website can silently identify VPN users, which can lead to a knock a
the door. If you don't believe me, just search for "ipleak" o= n
twitter[1] and see how many foreign language references there are to
the exploit test page.=C2=A0
=C2= =A0

Very real implication: Loading a website (or even an embedded ad) is
now much more life-threatening than it was before.

Thanks everyone! Great work!

I've heard many times on threads here that this is the fault of the
VPN user for not configuring their VPN better. I couldn't disagree
more. Up until WebRTC, the browser wasn't able to make non-default
route requests, which means that up until WebRTC, you couldn't expose your real IP just by visiting a webpage. So WebRTC is the thing that
triggered exposure of the user, not their VPN configuration. Also,
blaming the user when they are using the default configuration (and
don't know any better) and you introduced something that exposes them is offensive.=C2=A0

I don't= really want to debate nits, but this is not true. Flash has had this '= feature', since the beginning of the modern browser era.
Rega= rdless, we think we can do better.
=C2=A0<= /div>

See als= o:
and

-Ekr
<= /div> --f46d0438eb9dbe7aba051c31b1e6-- From nobody Fri Jul 31 13:57:06 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B951A3B9F for ; Fri, 31 Jul 2015 13:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylTbKHrn_QDS for ; Fri, 31 Jul 2015 13:56:54 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925821A21C7 for ; Fri, 31 Jul 2015 13:56:54 -0700 (PDT) Received: by pdbnt7 with SMTP id nt7so48172892pdb.0 for ; Fri, 31 Jul 2015 13:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=PfBhh6eyeo9NAYFciDKYuXfw2uF8E2YuZbFMncFu5SM=; b=v5DFoGmQkA6BLvr+WiZYha57x9GgoDFbrPeWSqIIDmJABXFixiQaxHR3l9J3V/QJtj VyGqqG9PRssHqANg0GNNz68aXuVLjGOFPZP5jKekuB5PQ6ZoaO1mHEIycCOnQyZN0GJ+ twZJZ7DzEFgPqNHKNFx07EU1v+MlUms1HKm4U/MKbPbjLr/daQNGRbC+EP5JJZZoDXjw JxcdWmeINJ1uP4q/s14jNQoQrIPmuSTvOvJurpVWhdDRfeXgIAc0F/qENHgN1HCWHgIA Hm4bOjPi4MhWuRke/R0FlxjWAgROTxCZrqLLphVgV0Aa/2X6dQ0E2WS6gOKKXR42f6nv 8+7g== X-Received: by 10.70.90.161 with SMTP id bx1mr11181202pdb.10.1438376214244; Fri, 31 Jul 2015 13:56:54 -0700 (PDT) Received: from [10.165.182.25] (mobile-166-176-184-208.mycingular.net. [166.176.184.208]) by smtp.gmail.com with ESMTPSA id ca13sm9330484pac.25.2015.07.31.13.56.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jul 2015 13:56:52 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-F423139A-7F85-4CCF-BC21-933E2F2253D7 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12H143) From: Bernard Aboba Date: Fri, 31 Jul 2015 13:56:47 -0700 To: "" Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 20:57:00 -0000 --Apple-Mail-F423139A-7F85-4CCF-BC21-933E2F2253D7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable New WebRTC devices typically use mux since it results in sending fewer packe= ts, using fewer ports, better energy consumption and reliability, etc.=20 > On Jul 31, 2015, at 12:37 PM, wrote: >=20 > When we choose this path, can we still support webrtc that is applied in d= evices / no-browser's? >=20 > Richard=20 >=20 > Op 31 jul. 2015 om 19:42 heeft Eric Rescorla het volgende g= eschreven: >=20 >>=20 >>=20 >>> On Fri, Jul 31, 2015 at 7:39 PM, Bernard Aboba = wrote: >>>> On Jul 31, 2015, at 10:03, Eric Rescorla wrote: >>>>>=20 >>>>> Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP= , but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? Tha= t would work for us. >>>=20 >>> [BA] Yes. Since RTP-Usage already requires mux support, we would only n= eed to change the sentence requiring non-mux to make it optional.=20 >>>=20 >>>> In this case, would browsers be able to reject attempts to set the poli= cy to >>>> anything other than always-mux? Because I'm pretty sure that's what bot= h >>>> we and Chrome want to do. >>>=20 >>> [BA] Yes, that should be possible. If non-mux is optional, then an imple= mentation that doesn't support it would only allow setting the policy to alw= ays mux.=20 >>=20 >> That seems satisfactory to me, since it means we can remove the code for >> non-mux. >>=20 >> -Ekr >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-F423139A-7F85-4CCF-BC21-933E2F2253D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
New WebRTC devices typically use mux since it results in sending fewer packets, using fewer ports, better energy consumption and reliability, etc. 



On Jul 31, 2015, at 12:37 PM, <richard.vandet@kpn.com> <richard.vandet@kpn.com> wrote:

When we choose this path, can we still support webrtc that is applied in devices / no-browser's?

Richard 

Op 31 jul. 2015 om 19:42 heeft Eric Rescorla <ekr@rtfm.com> het volgende geschreven:



On Fri, Jul 31, 2015 at 7:39 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
On Jul 31, 2015, at 10:03, Eric Rescorla <ekr@rtfm.com> wrote:
Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP, but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? That would work for us.
[BA] Yes.  Since RTP-Usage already requires mux support, we would only need to change the sentence requiring non-mux to make it optional. 

In this case, would browsers be able to reject attempts to set the policy to
anything other than always-mux? Because I'm pretty sure that's what both
we and Chrome want to do.
[BA] Yes, that should be possible. If non-mux is optional, then an implementation that doesn't support it would only allow setting the policy to always mux. 

That seems satisfactory to me, since it means we can remove the code for
non-mux.

-Ekr

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--Apple-Mail-F423139A-7F85-4CCF-BC21-933E2F2253D7-- From nobody Fri Jul 31 15:22:47 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3511A8AE7 for ; Fri, 31 Jul 2015 15:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5oTvuF9oSvU for ; Fri, 31 Jul 2015 15:22:43 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29CE91A90DE for ; Fri, 31 Jul 2015 15:15:03 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t6VMFFmA024518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 1 Aug 2015 00:15:16 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t6VMFFkh024516 for rtcweb@ietf.org; Sat, 1 Aug 2015 00:15:15 +0200 Date: Sat, 1 Aug 2015 00:15:15 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150731221514.GA22256@lo.psyced.org> References: <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 22:22:46 -0000 On Fri, Jul 31, 2015 at 11:59 AM, Daniel Roesler wrote: > >> more. Up until WebRTC, the browser wasn't able to make non-default > >> route requests, which means that up until WebRTC, you couldn't expose > >> your real IP just by visiting a webpage. So WebRTC is the thing that > >> triggered exposure of the user, not their VPN configuration. Also, > >> blaming the user when they are using the default configuration (and > >> don't know any better) and you introduced something that exposes them > >> is offensive. On Fri, Jul 31, 2015 at 9:27 PM, Justin Uberti wrote: > > I don't really want to debate nits, but this is not true. Flash has had > > this 'feature', since the beginning of the modern browser era. > > Regardless, we think we can do better. Wait wait.. I was developing Flash media apps some time ago in the pre-Snowden era and I never bumped into any such functionality. My business partner of those days just dropped me this link: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/Socket.html#localAddress Looks like the feature exists for installed AIR apps, not Flash plugin. Then he pointed me to Mr Kaufman's leak that RTMFP, which he introduced into Flash in 2009 AFAIR, can be abused to obtain such IP numbers. Well, if I who actually wrote push-to-talk apps with RTMP didn't know that, I doubt any HackingTeam company figured out this method for de-anonymizing VPN users. Hardly anyone looked at RTMFP all that much since the only existing server implementation was running at Adobe. Quite different from the WebRTC case where the API quite clearly explains how to get at local IP information. So let's indeed not excuse this larger problem with a previous problem that rather wasn't known until this moment where it may seem practical to leak such info for the sake of argument. Flash has NOT been offering such a feature since the beginning of time AFAICT and the sneaky way it got introduced with RTMFP and apparently wasn't actually secure as such is a too late scandal in itself. On Fri, Jul 31, 2015 at 10:30:05PM +0200, Eric Rescorla wrote: > See also: > https://www.usenix.org/system/files/conference/foci12/foci12-final8.pdf > and > http://www.eecs.qmul.ac.uk/~hamed/papers/PETS2015VPN.pdf Interesting papers, but do they describe a method for Javascript code in websites to break out of the VPN cage? I didn't see anything like that, maybe I skipped the content too fast. Also let's not talk about IPv6. It is not relevant for the dissident scenario of today and by the time industry stops preferring NAT over IPv6 we'd better already be deploying public-key based routing whereby worldwide IP addressing is no longer a worthwhile goal. Thus it is my assumption that IPv6 will hardly ever play a relevant role in Internet history. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Fri Jul 31 15:27:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61461A8AC6 for ; Fri, 31 Jul 2015 15:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHfJGd0oMapg for ; Fri, 31 Jul 2015 15:27:37 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5FF1A8AA8 for ; Fri, 31 Jul 2015 15:27:36 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t6VMRnO6025120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 1 Aug 2015 00:27:49 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t6VMRmeb025118 for rtcweb@ietf.org; Sat, 1 Aug 2015 00:27:48 +0200 Date: Sat, 1 Aug 2015 00:27:48 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150731222748.GB22256@lo.psyced.org> References: <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 22:27:39 -0000 On Fri, Jul 31, 2015 at 03:28:05PM -0400, Roman Shpount wrote: > I actually appreciate the seriousness of the issue. I think part of the > reason this group did not respond in more timely manner is that not > everyone realized the behavior change (use of non-default routes). Once it > was clarified, the issue started to be handled. I understand that this and > any other security issue can be extremely frustrating to the end users, but > people, including people who build web browsers or design web browser > standards do make mistakes. Woah, everyone reading those blogs understood the seriousness of the problem except for the developers that culled themselves into the idea of everyone out there having gotten everything wrong? Whoops. On Fri, Jul 31, 2015 at 2:59 PM, Daniel Roesler wrote: > > How about a combined solution? Sounds like going in the right direction. I still haven't understood why there can't be one single prompt that allows a site to do webrtc things.. allowing mic, cam *AND* STUN access in a single gesture. Anything else would be intransparent anyway. > > I very much do not agree with Justin/Chrome's proposal to add a > > configuration extension that requires a user to opt-in to restricting > > non-default route STUN requests. That's like having the setting to > > show the warning for self-signed https certificates turned off by > > default and asking users to turn it on if they really want to be safe. > > The default behavior should be safe. Yes, the proposal completely fails the scenario I described. You can't expect non-tech people that are simply using a web browser to understand why they suddenly need to flick some switches or install some odd addons in order to not get deanonymized. WebRTC needs a general opt-in. On Fri, Jul 31, 2015 at 03:28:05PM -0400, Roman Shpount wrote: > I think you do not correctly characterize what Justin/Chrome is doing here. > It is not a final solution. It is a way to test the final solution before > it gets widely deployed. Since this is a major change for the browsers I > appreciate the need to deploy this carefully and gradually. Features need to be introduced carefully, but this isn't a feature. This is a top notch security bug risking human lives and I can't believe it takes months of talking to get anything going here. This needs to be shut down first, then experiment alternate routes. Period. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Fri Jul 31 17:18:14 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E8A1ACE03 for ; Fri, 31 Jul 2015 17:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-G8dH2bSTDV for ; Fri, 31 Jul 2015 17:18:12 -0700 (PDT) Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 5D86A1ACDF3 for ; Fri, 31 Jul 2015 17:18:12 -0700 (PDT) Received: from Matthew-Kaufmans-MacBook-Air.local (173-160-145-233-Washington.hfc.comcastbusiness.net [173.160.145.233]) (Authenticated sender: matthew@matthew.at) by mail.eeph.com (Postfix) with ESMTPSA id E33912A3F1F for ; Fri, 31 Jul 2015 17:18:08 -0700 (PDT) Message-ID: <55BC1059.7000902@matthew.at> Date: Fri, 31 Jul 2015 17:18:33 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20150715123803.GA24976@lo.psyced.org> <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> <20150731222748.GB22256@lo.psyced.org> In-Reply-To: <20150731222748.GB22256@lo.psyced.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 00:18:14 -0000 On 7/31/15 3:27 PM, carlo von lynX wrote: > On Fri, Jul 31, 2015 at 03:28:05PM -0400, Roman Shpount wrote: >> I actually appreciate the seriousness of the issue. I think part of the >> reason this group did not respond in more timely manner is that not >> everyone realized the behavior change (use of non-default routes). Once it >> was clarified, the issue started to be handled. I understand that this and >> any other security issue can be extremely frustrating to the end users, but >> people, including people who build web browsers or design web browser >> standards do make mistakes. > Woah, everyone reading those blogs understood the seriousness of the > problem except for the developers that culled themselves into the idea > of everyone out there having gotten everything wrong? Whoops. I understood the magnitude of the issue, and I still think you're overreacting. > > On Fri, Jul 31, 2015 at 2:59 PM, Daniel Roesler wrote: >>> How about a combined solution? > Sounds like going in the right direction. I still haven't understood > why there can't be one single prompt that allows a site to do webrtc > things.. allowing mic, cam *AND* STUN access in a single gesture. > Anything else would be intransparent anyway. > >>> I very much do not agree with Justin/Chrome's proposal to add a >>> configuration extension that requires a user to opt-in to restricting >>> non-default route STUN requests. That's like having the setting to >>> show the warning for self-signed https certificates turned off by >>> default and asking users to turn it on if they really want to be safe. >>> The default behavior should be safe. > Yes, the proposal completely fails the scenario I described. You > can't expect non-tech people that are simply using a web browser to > understand why they suddenly need to flick some switches or install > some odd addons in order to not get deanonymized. WebRTC needs a > general opt-in. Disagree. > > On Fri, Jul 31, 2015 at 03:28:05PM -0400, Roman Shpount wrote: >> I think you do not correctly characterize what Justin/Chrome is doing here. >> It is not a final solution. It is a way to test the final solution before >> it gets widely deployed. Since this is a major change for the browsers I >> appreciate the need to deploy this carefully and gradually. > Features need to be introduced carefully, but this isn't a feature. > This is a top notch security bug risking human lives and I can't > believe it takes months of talking to get anything going here. > This needs to be shut down first, then experiment alternate routes. > Period. > If you're worried about "top notch security bugs risking human lives" there's at least a dozen I'd tackle before thinking about this one. It allows browsers to do little more than people have been accepting for years, in their browsers. Matthew Kaufman From nobody Fri Jul 31 18:45:01 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686001A8A3B for ; Fri, 31 Jul 2015 18:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2m1bbK9F7oG for ; Fri, 31 Jul 2015 18:44:58 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044B71A8A20 for ; Fri, 31 Jul 2015 18:44:57 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t711jD3a027802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Aug 2015 03:45:13 +0200 Received: from localhost (fippo@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) with ESMTP id t711jDSn027797; Sat, 1 Aug 2015 03:45:13 +0200 X-Authentication-Warning: lo.psyced.org: fippo owned process doing -bs Date: Sat, 1 Aug 2015 03:45:13 +0200 (CEST) From: Philipp Hancke X-X-Sender: fippo@lo.psyced.org To: carlo von lynX In-Reply-To: <20150731221514.GA22256@lo.psyced.org> Message-ID: References: <2BCEF545-D322-4589-AC85-AA80E7F934D9@phonefromhere.com> <20150715164129.GA27105@lo.psyced.org> <20150716084225.GA29652@lo.psyced.org> <0AF88216-374E-4DBA-9DB5-3E55B358E6AA@phonefromhere.com> <20150731104712.GA5228@lo.psyced.org> <20150731221514.GA22256@lo.psyced.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 01:45:00 -0000 > Well, if I who actually wrote push-to-talk apps with RTMP didn't know > that, I doubt any HackingTeam company figured out this method for > de-anonymizing VPN users. At least hackingteam didn't figure out the webrtc method themselves either according to https://wikileaks.org/hackingteam/emails/emailid/119217 Now if you assume a smarter opponent than that, why is that opponent not smart enough to have figured out the RTMFP method as well? Granted, RTMFP is a pretty tough nut to reverse engineer but it had been done back in late 2010. And it is P2P. It has to exchange some ip addresses somehow. Even despite the encryption scheme, you can use wireshark to see ice-like packets. Their content will be unreadable, but the IP addresses tell you what is going on. I do recall LOL'ing when finding out that Adobe leaked 10.x server addresses in the early days of cirrus. > Hardly anyone looked at RTMFP all that much since the only > existing server implementation was running at Adobe. I disagree with your "hardly anyone" FWIW. > Quite different from the WebRTC case where the API quite clearly > explains how to get at local IP information. I do not understand your argument. RTMFP did not expose the local IP information at the API level. However, that did not mean it was not discoverable as explained above. Assuming that your point is that WebRTC shouldn't expose this and use a signaling channel that isn't under control of the browser, how would that increase security?

Richard, David,

 

<= span lang=3DEN-US style=3D'color:#1F497D'>on the last mile of a consumer ac= cess, Deutsche Telekom operates QoS. To produce QoS with flows having a hig= h bandwidth as compared to the available resources of a class, admission co= ntrol is required. That means control plane interaction with a service plat= form for all streams consuming QoS resources. This includes awareness of th= e access resources available per QoS class.

 

Qo= S interconnection with Deutsche Telekom’s Voice platform is offered a= nd operational. A VPN is used. Available PHBs and DSCPs are specified. Also= the per flow signaling and payload properties are specified to some extent= .

 

A VPN or an outer tunnel CoS / inner tunnel C= oS scheme is useful if

-     &n= bsp;    no admission control or “live and let live̶= 1; cooperation respectively between flows requesting QoS support in the las= t mile is intended.

-     &nbs= p;    the outer tunnel QoS may be Best Effort or another CoS = like solution (a don’t drop me first, but drop me before any QoS traf= fic gets dropped approach).

-    &nb= sp;     Then the inner tunnel can carry any DSCP desired= and the outer tunnel may consist of one or two markings. The latter may ha= ve a chance to be carried end-to-end.

 

Another op= tion may be to mark admission controlled traffic by DSCP a and produce WebR= TC with DSCP b and c in the=A0 same queue, however making sure that during = congestion in that class all traffic without admission control (WebRTC) =A0= gets dropped before traffic with admission control is dropped. <= /span>

<= o:p> 

Regards,

 

Ruediger

 

 

Von:= richard.vandet@kpn.com [mailto:richard.vandet@kpn.com]
Gesendet:= Samstag, 25. Juli 2015 08:01
An: david.black@emc.com
C= c: Geib, R=FCdiger; karen.nielsen@tieto.com; rtcweb@ietf.org; tsvwg@iet= f.org
Betreff: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb d= ata channel

&nbs= p;

Sometimes legislation prohibits the Q= oS model over open internet, all traffic must be treated the same.

A= VPN may be a solution, based on a SPs services model like Voice. Setting u= p a VPN on the fly once the connection is established may suit the needs of= a developer.

 = ;

Richard


Op 24 jul. 2= 015 om 14:29 heeft Black, David <= david.black@emc.com> het volgende geschreven:

<WG chair hat OFF>

 

> All DSCPs, which have not been negotiated between access and interconne= ction are possibly bleached, especially if a network

<= p class=3DMsoNormal>> provider operates Qo= S within the network.

 

“possibly” -> “probably&= #8221; -> “almost certainly” depending on the network (YMMV)= .

 

> I’d like to read = a little more about how WEBrtc figures out which QoS resources are configur= ed and which of these are available

> for such a flow at an access when req= uired. How and where are the resources consumed by each WERrtc PHB controll= ed and

> how are these aligned with the QoS resources consumed by other ser= vices?

 

 

In= spite of all of the above, I have been told of good experiences with use o= f CS2 for gaming and CS1 for lower effort (less than best effort), plus EF = use for gaming was mentioned in the tsvwg meeting yesterday.

 

This i= s not the first time I’ve heard a request for a “what QoS servi= ces are available via which DSCPs?” interface/protocol.  I don&#= 8217;t know of one, and I’m not sure how to incentivize deployment if= we designed one.

 <= /o:p>

What is likely to happen is that if certain types= of traffic favor specific DSCPs, then operators who want to improve the us= er experience of those who send/receive such traffic may put in QoS mechani= sms for such traffic keyed by those DSCPs at network ingress.  OTOH, a= “tragedy of the commons” is possible here, e.g., the story in = tsvwg about how a lot of non-voice traffic showing up marked as if it were = voice resulted in the network operator removing that special treatment of (= residential, I presume) voice traffic.

</WG chair hat OFF>

 

<= p class=3DMsoNormal>Thanks,
--David

 

= From: tsvwg [mailto:tsvwg-boun= ces@ietf.org] On Behalf Of Ruediger.Geib@telekom.de
Sent: Friday, July 24, 2015 5= :33 AM
To: karen.niels= en@tieto.com
Cc: Michael.Tuexen@lurchi.franken.de; rtcweb@ietf.org; tsvwg@ietf.org= ; fluffy@iii.ca
Subject:= Re: [tsvwg] diffserv marking for rtcwb data channel

<= /div>

 

<= span style=3D'color:#1F497D'>Hi Karen,

 

QoS  needs to be commercially = negotiated at interconnection. If QoS should be available at a consumer acc= ess, the consumer division of a company must be involved in addition as wel= l as the technical staff setting up and maintaining technical configuration= s. 11 PHBs for a single consumer service are a challenging requirement.

 =

Al= l DSCPs, which have not been negotiated between access and interconnection = are possibly bleached, especially if a network provider operates QoS within= the network.

 

QoS to me means overprovisioning to ensure transport free of= congestion. If I see 11 PHBs for a single flow, I’m not sure if this= assumes more than CoS (drop me last). I’d like to read a little more= about how WEBrtc figures out which QoS resources are configured and which = of these are available for such a flow at an access when required. How and = where are the resources consumed by each WERrtc PHB controlled and how are = these aligned with the QoS resources consumed by other services?

 =

Regards,<= /span>

&nb= sp;

Ruediger

 

Von: Ka= ren Elisabeth Egede Nielsen [mai= lto:karen.nielsen@tieto.com]
Gesendet: Freitag, 24. Juli 201= 5 10:28
An: Geib, R=FCdiger
Cc: rtcweb@ietf.org; tsvwg@ie= tf.org; Michael Tuexen; fluffy@iii.ca<= /a>
Betreff: RE: [tsvwg] diffserv marking for rtcwb data channel<= /span>

 

=

Hi Ruediger,=

 <= o:p>

Thanks a l= ot.

 

So I think that you’re saying that even if one made sure that di= fferent diff serv markings were

<= span style=3D'color:#1F497D'>split on different 5-tuples, this setting like= ly would be bleached at the network.

 

Is that correctly understood ?=

 

If so= , then (it sounds to me – not knowing too much about this) that from = a coupling congestion control perspective it

would be preferable to  use= SCTP scheduling prioritization (within one and the same association) for f= ine granular differentiation in between

multiple data channels in between the = same end-points rather than differentiation by means of diff serv marking.<= /span>

&nb= sp;

When/if one get a more consistent and forceful ECN operation in AQMs and S= CTP end-points, perhaps the coupling congestion

principles achieved by means o= f sctp stream scheduling get to be less important.

On the other hand, again a= s said before, having the one and the same, or multiple, flow control (rece= iver buffer) contexts may be

a strength (simplicity) or a weakness.  &nbs= p; 

 

BR, Karen

 

From: Ruediger.Geib= @telekom.de [mailto:Ruedige= r.Geib@telekom.de]
Sent: Friday, July 24, 2015 10:00 AM
<= b>To: karen.nielsen@tieto.co= m
Cc: rtcweb@ietf.org;= tsvwg@ietf.org
Subject: AW= : [tsvwg] diffserv marking for rtcwb data channel

 

Karen,

=  

      Finally there was a = comment at the tsvwg meeting that the same 5-tuple with

    &nbs= p;  different diffserv markings would not get through the network – if that generally

  = ;     is correct,  then the solution i= s very easy: one MUST use different associations to

     &n= bsp; get port (5-tuple) differentiation.

     &n= bsp; I think that if this is correct, one also wants to ask what hap= pens if the diffserv is

       changed for= the same 5-tuple – i.e., is the network robust to this change even i= f

 &= nbsp;     it is not robust to concurrent us= age of different markings for the same 5-tuple.

 

Talking about the policies of the company I work for only:=

 <= o:p>

Possibilit= ies to enforce QoS policies at a provider BRAS or BNG terminating wired

consumer accesses are limited. QoS p= olicies based on full 5 tuple are very

conservative and hard to maintain. I w= ouldn’t expect full 5 tuple as basis for a QoS

=

policy then. Trust in th= e correct information on which a BRAS/BNG can

base QoS classification is an i= mportant issue. In any case, I’d not expect

more than one DSCP is assig= ned based on such a policy for the time

being. I’m not aware of any act= ual requirement to support e.g. an AFn

class by all three PHBs.

 

At interconn= ection points, any unexpected DSCP is bleached. This must

be done to protect = backbone QoS production. QoS transport can be

negotiated for a set of defined= DSCPs.

 

A study of the EU found DPI to be more common in wireless communi= cation than in wired communication. I’d not expect the QoS policies i= n that area to be more liberal than for fixed access networks for the time = being.

 

Regards,

 

Ruediger

 

<= span style=3D'color:#1F497D'> 

 

&= nbsp;

__________________= _____________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb<= /o:p>

= --_000_CA7A7C64CC4ADB458B74477EA99DF6F50529674941HE111643EMEA1_-- From nobody Mon Jul 27 11:55:01 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B241B2A82; Mon, 27 Jul 2015 04:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2jP38Pjcegc; Mon, 27 Jul 2015 04:48:41 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBC51AD359; Mon, 27 Jul 2015 04:48:40 -0700 (PDT) Received: by wibud3 with SMTP id ud3so111934229wib.0; Mon, 27 Jul 2015 04:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=A9xkBBcvOAXlJcunePNf95OkU1ZEi44KfEOkj33coWs=; b=Z4ahSfENyJScAINUrnz3z7BXO5qmEbhE3f3MMAfK6pTh6L6mxvyg/LWCz1zCW+/upk AY29OySUu8OWYw9wCJ+g5ELSNBp8wBfjJxbKsjIpVeJiZ86GQ/HHPOCPYfuykyVJMZgM WModebHLbDoql41y3jgkyS+dck7PDjnfc7aKNSzgkit2SJQ4HdOV2Q4jVT9856VNGbi7 QHmwDk1AEz0TTLv89iAj4jf5G5Tc33ZCjFD/V4L9A0i2gAqDtdV/OzQY18uLwtagFevW kKRaxFyJjTGXwflputLMyd7XYU11b/8qlzBiHX+iGNs08zd3s68FcNKd3XAxx/y+0lz2 l24g== X-Received: by 10.194.205.225 with SMTP id lj1mr53346275wjc.138.1437997719473; Mon, 27 Jul 2015 04:48:39 -0700 (PDT) Received: from [192.168.0.4] (cpc11-brig18-2-0-cust561.3-3.cable.virginm.net. [81.100.118.50]) by smtp.gmail.com with ESMTPSA id fm8sm13246871wib.9.2015.07.27.04.48.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2015 04:48:38 -0700 (PDT) Message-ID: <55B61A96.7080207@gmail.com> Date: Mon, 27 Jul 2015 23:48:38 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de, richard.vandet@kpn.com, david.black@emc.com References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Mon, 27 Jul 2015 11:54:45 -0700 Cc: karen.nielsen@tieto.com, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 11:48:44 -0000 Ruediger brings out an important point. Diffserv can only work properly if there is admission control for every traffic class that claims to offer definite guarantees. That isn't because the people who defined diffserv were trying to be annoying. It's because of the physics and mathematics of queuing systems. Regards Brian On 27/07/2015 19:46, Ruediger.Geib@telekom.de wrote: > Richard, David, >=20 > on the last mile of a consumer access, Deutsche Telekom operates QoS. T= o produce QoS with flows having a high bandwidth as compared to the avail= able resources of a class, admission control is required. That means cont= rol plane interaction with a service platform for all streams consuming Q= oS resources. This includes awareness of the access resources available p= er QoS class. >=20 > QoS interconnection with Deutsche Telekom's Voice platform is offered a= nd operational. A VPN is used. Available PHBs and DSCPs are specified. Al= so the per flow signaling and payload properties are specified to some ex= tent. >=20 > A VPN or an outer tunnel CoS / inner tunnel CoS scheme is useful if >=20 > - no admission control or "live and let live" cooperation resp= ectively between flows requesting QoS support in the last mile is intende= d. >=20 > - the outer tunnel QoS may be Best Effort or another CoS like = solution (a don't drop me first, but drop me before any QoS traffic gets = dropped approach). >=20 > - Then the inner tunnel can carry any DSCP desired and the out= er tunnel may consist of one or two markings. The latter may have a chanc= e to be carried end-to-end. >=20 > Another option may be to mark admission controlled traffic by DSCP a an= d produce WebRTC with DSCP b and c in the same queue, however making sur= e that during congestion in that class all traffic without admission cont= rol (WebRTC) gets dropped before traffic with admission control is dropp= ed. >=20 > Regards, >=20 > Ruediger >=20 >=20 > Von: richard.vandet@kpn.com [mailto:richard.vandet@kpn.com] > Gesendet: Samstag, 25. Juli 2015 08:01 > An: david.black@emc.com > Cc: Geib, R=C3=BCdiger; karen.nielsen@tieto.com; rtcweb@ietf.org; tsvwg= @ietf.org > Betreff: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel >=20 > Sometimes legislation prohibits the QoS model over open internet, all t= raffic must be treated the same. >=20 > A VPN may be a solution, based on a SPs services model like Voice. Sett= ing up a VPN on the fly once the connection is established may suit the n= eeds of a developer. >=20 > Richard >=20 > Op 24 jul. 2015 om 14:29 heeft Black, David > het volgende geschreven: > >=20 >> All DSCPs, which have not been negotiated between access and interconn= ection are possibly bleached, especially if a network >> provider operates QoS within the network. >=20 > "possibly" -> "probably" -> "almost certainly" depending on the network= (YMMV). >=20 >> I'd like to read a little more about how WEBrtc figures out which QoS = resources are configured and which of these are available >> for such a flow at an access when required. How and where are the reso= urces consumed by each WERrtc PHB controlled and >> how are these aligned with the QoS resources consumed by other service= s? >=20 > The short Web RTC answer to all of the above "it doesn't do that". The= DSCPs are in effect QoS service requests that the various networks invol= ved may deal with as they wish. Bleaching is one possibility (in effect = an "I don't do that" response to the request). Even in that case, there = may be value in DSCP usage for forwarding by equipment between the browse= r and the interface to the ISP's network (e.g., residential router/NAT/AP= box). >=20 > In spite of all of the above, I have been told of good experiences with= use of CS2 for gaming and CS1 for lower effort (less than best effort), = plus EF use for gaming was mentioned in the tsvwg meeting yesterday. >=20 > This is not the first time I've heard a request for a "what QoS service= s are available via which DSCPs?" interface/protocol. I don't know of on= e, and I'm not sure how to incentivize deployment if we designed one. >=20 > What is likely to happen is that if certain types of traffic favor spec= ific DSCPs, then operators who want to improve the user experience of tho= se who send/receive such traffic may put in QoS mechanisms for such traff= ic keyed by those DSCPs at network ingress. OTOH, a "tragedy of the comm= ons" is possible here, e.g., the story in tsvwg about how a lot of non-vo= ice traffic showing up marked as if it were voice resulted in the network= operator removing that special treatment of (residential, I presume) voi= ce traffic. >=20 > >=20 > Thanks, > --David >=20 > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Ruediger.Geib@= telekom.de > Sent: Friday, July 24, 2015 5:33 AM > To: karen.nielsen@tieto.com > Cc: Michael.Tuexen@lurchi.franken.de; rtcweb@ietf.org; tsvwg@ietf.org; fluffy@iii.ca > Subject: Re: [tsvwg] diffserv marking for rtcwb data channel >=20 > Hi Karen, >=20 > QoS needs to be commercially negotiated at interconnection. If QoS sho= uld be available at a consumer access, the consumer division of a company= must be involved in addition as well as the technical staff setting up a= nd maintaining technical configurations. 11 PHBs for a single consumer se= rvice are a challenging requirement. >=20 > All DSCPs, which have not been negotiated between access and interconne= ction are possibly bleached, especially if a network provider operates Qo= S within the network. >=20 > QoS to me means overprovisioning to ensure transport free of congestion= =2E If I see 11 PHBs for a single flow, I'm not sure if this assumes more= than CoS (drop me last). I'd like to read a little more about how WEBrtc= figures out which QoS resources are configured and which of these are av= ailable for such a flow at an access when required. How and where are the= resources consumed by each WERrtc PHB controlled and how are these align= ed with the QoS resources consumed by other services? >=20 > Regards, >=20 > Ruediger >=20 > Von: Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com] > Gesendet: Freitag, 24. Juli 2015 10:28 > An: Geib, R=C3=BCdiger > Cc: rtcweb@ietf.org; tsvwg@ietf.org; Michael Tuexen; fluffy@iii.ca > Betreff: RE: [tsvwg] diffserv marking for rtcwb data channel >=20 > Hi Ruediger, >=20 > Thanks a lot. >=20 > So I think that you're saying that even if one made sure that different= diff serv markings were > split on different 5-tuples, this setting likely would be bleached at t= he network. >=20 > Is that correctly understood ? >=20 > If so, then (it sounds to me - not knowing too much about this) that fr= om a coupling congestion control perspective it > would be preferable to use SCTP scheduling prioritization (within one = and the same association) for fine granular differentiation in between > multiple data channels in between the same end-points rather than diffe= rentiation by means of diff serv marking. >=20 > When/if one get a more consistent and forceful ECN operation in AQMs an= d SCTP end-points, perhaps the coupling congestion > principles achieved by means of sctp stream scheduling get to be less i= mportant. > On the other hand, again as said before, having the one and the same, o= r multiple, flow control (receiver buffer) contexts may be > a strength (simplicity) or a weakness. >=20 > BR, Karen >=20 > From: Ruediger.Geib@telekom.de [mailto= :Ruediger.Geib@telekom.de] > Sent: Friday, July 24, 2015 10:00 AM > To: karen.nielsen@tieto.com > Cc: rtcweb@ietf.org; tsvwg@ietf.org > Subject: AW: [tsvwg] diffserv marking for rtcwb data channel >=20 > Karen, >=20 > Finally there was a comment at the tsvwg meeting that the same 5-= tuple with > different diffserv markings would not get through the network - = if that generally > is correct, then the solution is very easy: one MUST use differ= ent associations to > get port (5-tuple) differentiation. > I think that if this is correct, one also wants to ask what happ= ens if the diffserv is > changed for the same 5-tuple - i.e., is the network robust to th= is change even if > it is not robust to concurrent usage of different markings for t= he same 5-tuple. >=20 > Talking about the policies of the company I work for only: >=20 > Possibilities to enforce QoS policies at a provider BRAS or BNG termina= ting wired > consumer accesses are limited. QoS policies based on full 5 tuple are v= ery > conservative and hard to maintain. I wouldn't expect full 5 tuple as ba= sis for a QoS > policy then. Trust in the correct information on which a BRAS/BNG can > base QoS classification is an important issue. In any case, I'd not exp= ect > more than one DSCP is assigned based on such a policy for the time > being. I'm not aware of any actual requirement to support e.g. an AFn > class by all three PHBs. >=20 > At interconnection points, any unexpected DSCP is bleached. This must > be done to protect backbone QoS production. QoS transport can be > negotiated for a set of defined DSCPs. >=20 > A study of the EU found DPI to be more common in wireless communication= than in wired communication. I'd not expect the QoS policies in that are= a to be more liberal than for fixed access networks for the time being. >=20 > Regards, >=20 > Ruediger >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Jul 27 12:02:05 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55D51B3261 for ; Mon, 27 Jul 2015 12:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXBLznujd2pi for ; Mon, 27 Jul 2015 12:02:03 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C491B3238 for ; Mon, 27 Jul 2015 12:02:03 -0700 (PDT) Received: by wibud3 with SMTP id ud3so128960752wib.0 for ; Mon, 27 Jul 2015 12:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MhOrWtWnWssDmBPx1Jq6VHwiQoR9Mo3Fp49MO+kSAKA=; b=GbNYW5HeVcS7owyKKzK53RkkJ3zY9pwk3FmmLEUgAu+5M7mN6huj/LT2fpufuNRVMi FWLP3he2Pv6BwbKCviqgr3PZzN+uhf46y1+V4nAX/ksdei7Wajw/jXY1ta+vHfJiOnws GAiRgBNU8FwXcKCMeGB2iI5iYT7QIgCklDfsdRYd5W0H9F12KGAiO+irv2YvxifCXFaI LXiYSYlBbbbIzpOarWJGbcZl+j+eW2mVikAF2KT9s8LxbYgUUR2QXsUZVZ92apeX+V6g IgNGwJ7UxxINE3S1HdflMMNBV/9a0WZnsQIitLgForn5okTuXAvbvii/DO0VOybewtc+ jhNg== MIME-Version: 1.0 X-Received: by 10.194.187.170 with SMTP id ft10mr57103780wjc.26.1438023721625; Mon, 27 Jul 2015 12:02:01 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Mon, 27 Jul 2015 12:02:01 -0700 (PDT) In-Reply-To: References: <55A95364.2070806@gmail.com> <55A96DA3.1040907@gmail.com> <55A9860D.8030903@gmail.com> Date: Mon, 27 Jul 2015 12:02:01 -0700 Message-ID: From: Ted Hardie To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7bb03a921b3056051bdffddb Archived-At: Cc: "rtcweb@ietf.org" , Tim Panton Subject: Re: [rtcweb] Please require user consent for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 19:02:04 -0000 --047d7bb03a921b3056051bdffddb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2015 at 4:43 AM, I=C3=B1aki Baz Castillo wr= ote: > 2015-07-20 13:37 GMT+02:00 Tim Panton : > >> E.g. I=E2=80=99m at home and my chromebook pixel (or firefox tablet) is = on wifi, >> but I=E2=80=99ve left LTE enabled. >> I (or the OS) is configured to prefer wifi wen available - but it happen= s >> that for a specific peer LTE completes first. >> So now my video call goes over LTE without my say-so and with no hint >> this is happening - costing me real >> money. My only option is to completely disable LTE when I get home (and >> lose SMS too) ? >> > > Exactly. > > Setting the default network route should be enough to avoid that and to > ensure a global network policy for the whole OS, unless an app (the > browser) plays to be God. > > =E2=80=8BSo, the work of MIF got mentioned during the IETF WG meeting, but = I'm not sure that folks have its coordinates; just in case, the documents are all here: http://datatracker.ietf.org/wg/mif/documents/ It's the right IETF venue to discuss the general question of how to manage multiple interfaces. regards, Ted=E2=80=8B --047d7bb03a921b3056051bdffddb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 20, 2015 at 4:43 AM= , I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
2015-07-20 13:= 37 GMT+02:00 Tim Panton <thp@westhawk.co.uk>:
E.g. I=E2=80=99m at home and my chromebook pixel = (or firefox tablet) is on wifi, but I=E2=80=99ve left LTE enabled.
I (or the OS) is configured to prefer wifi wen available - but it happens= that for a specific peer LTE completes first.
So now my video ca= ll goes over LTE without my say-so and with no hint this is happening =C2= =A0- costing me real
money. My only option is to completely disab= le LTE when I get home =C2=A0(and lose SMS too) ?
<= br>Exactly.

Setting the default network route should be enough to avoid th= at and to ensure a global network policy for the whole OS, unless an app (t= he browser) plays to be God.=


=E2=80= =8BSo, the work of MIF got mentioned during the IETF WG meeting, but I'= m not sure that folks have its coordinates; just in case, the documents are= all here:

http://datatracker.ietf.org/wg/mif/documents/

= It's the right IETF venue to discuss the general question of how to man= age multiple interfaces.

regards,
Ted=E2=80=8B