From nobody Thu Apr 2 08: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 27F861B2CCA for ; Thu, 2 Apr 2015 08:15:02 -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, HTML_MESSAGE=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 CsyaN9QZbtM3 for ; Thu, 2 Apr 2015 08:14:59 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 03FA81AC427 for ; Thu, 2 Apr 2015 08:14:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DBEEC7C5606; Thu, 2 Apr 2015 17:14:57 +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 zN1-ALVZzGYt; Thu, 2 Apr 2015 17:14:55 +0200 (CEST) Received: from [192.168.144.80] (unknown [74.125.61.146]) by mork.alvestrand.no (Postfix) with ESMTPSA id E529A7C5605; Thu, 2 Apr 2015 17:14:54 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <5519A5A4.4070205@nostrum.com> References: <5519753D.1080907@nostrum.com> <30772BF4-B814-4CB2-932F-96885D0BD76E@iii.ca> <5519A5A4.4070205@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----2KCJBSZQABPQ3EUJO9H5FX4EHW5GVW" Content-Transfer-Encoding: 8bit From: Harald Alvestrand Date: Thu, 02 Apr 2015 16:14:50 +0100 To: Adam Roach ,Cullen Jennings Message-ID: Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP lines (JSEP Issue 27) 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, 02 Apr 2015 15:15:02 -0000 ------2KCJBSZQABPQ3EUJO9H5FX4EHW5GVW Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 The API already exposes the sdp that went into set remote. Those lines should show up there. Otherwise, must ignore seems right to me. Den 30. mars 2015 20.36.04 GMT+01:00, skrev Adam Roach : >On 3/30/15 14:18, Cullen Jennings wrote: >>> On Mar 30, 2015, at 10:09 AM, Adam Roach wrote: >>> >>> i=, u=, e=, p=, z=, r= >>> SHOULD NOT send, MUST ignore. >> I don't think MUST ignore is correct. First to be clear, I'm not >saying the browser needs to do anything with the info in theses lines. >> >> I think MAY ignore or not typically used by a webrtc browser might be >a better way to say it. For example, if rtcweb device was taking a >streaming video session via webrtc protocols, it might make sense for >it to use the i= or u= particularly if the SDP had originally come from >an RTSP stream that was gatewayed to WebRTC. Similarly if a browser >reported the full SDP it had received in some stats interface, I would >expect it not to ignore the lines but actually report what it was it >received. >> >> To be clear, I'm not saying the browser needs to do anything with the >info in theses lines - it's fine to ignore them. But that's very >different from all webrtc things must ignore them. (and I agree with >SHOULD NOT send part) > >I think we're in agreement about the principle, but might be at cross >purposes regarding the venue: I agree that non-browsers may well have >reasons to use these fields, but I don't think this document has much >bearing on what those implementations do; at least, not as it currently > >describes itself. > > From the introduction section, JSEP "describes how the W3C WEBRTC >RTCPeerConnection interface is used to control the setup, management >and >teardown of a multimedia session." So, in the context of *this* >document, it would *appear* that we're in agreement that the proper >normative behavior is to ignore the values in these lines. So I can see > >why we might be quibbling about "SHOULD" versus "MUST," but your >objection seems much broader than that. > >If our difference of opinion here arises from differing views about >intended scope for the JSEP document, then we need to start a broader >conversation around, minimally, the introduction section of the current > >draft. > >/a > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------2KCJBSZQABPQ3EUJO9H5FX4EHW5GVW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit The API already exposes the sdp that went into set remote. Those lines should show up there. Otherwise, must ignore seems right to me.

Den 30. mars 2015 20.36.04 GMT+01:00, skrev Adam Roach <adam@nostrum.com>:
On 3/30/15 14:18, Cullen Jennings wrote:
 On Mar 30, 2015, at 10:09 AM, Adam Roach <adam@nostrum.com> wrote:

 i=, u=, e=, p=, z=, r=
   SHOULD NOT send, MUST ignore.
 I don't think MUST ignore is correct. First to be clear, I'm not saying the browser needs to do anything with the info in theses lines.

 I think MAY ignore or not typically used by a webrtc browser might be a better way to say it. For example, if rtcweb device was taking a streaming video session via webrtc protocols, it might make sense for it to use the i= or u= particularly if the SDP had originally come from an RTSP stream that was gatewayed to WebRTC. Similarly if a browser reported the full SDP it had
received in some stats interface, I would expect it not to ignore the lines but actually report what it was it received.

 To be clear, I'm not saying the browser needs to do anything with the info in theses lines - it's fine to ignore them. But that's very different from all webrtc things must ignore them. (and I agree with SHOULD NOT send part)

I think we're in agreement about the principle, but might be at cross 
purposes regarding the venue: I agree that non-browsers may well have 
reasons to use these fields, but I don't think this document has much 
bearing on what those implementations do; at least, not as it currently 
describes itself.

 From the introduction section, JSEP "describes how the W3C WEBRTC 
RTCPeerConnection interface is used to control the setup, management and 
teardown of a multimedia session." So, in the context of *this* 
document, it would *appear* that we're in agreement that
the proper 
normative behavior is to ignore the values in these lines. So I can see 
why we might be quibbling about "SHOULD" versus "MUST," but your 
objection seems much broader than that.

If our difference of opinion here arises from differing views about 
intended scope for the JSEP document, then we need to start a broader 
conversation around, minimally, the introduction section of the current 
draft.

/a


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

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------2KCJBSZQABPQ3EUJO9H5FX4EHW5GVW-- From nobody Fri Apr 3 08:05: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 AADFF1B29D5 for ; Wed, 25 Mar 2015 11:35:47 -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=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 31o_xtcN3qmE for ; Wed, 25 Mar 2015 11:35:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A6AED1AC40A for ; Wed, 25 Mar 2015 11:35:46 -0700 (PDT) Received: from localhost ([::1]:40228 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yaq9a-0005js-DN; Wed, 25 Mar 2015 11:35:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Wed, 25 Mar 2015 18:35:46 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/34 Message-ID: <066.1f587dc698ac0470383925900c50e054@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-rtcweb-security-arch@ietf.org Resent-Message-Id: <20150325183546.A6AED1AC40A@ietfa.amsl.com> Resent-Date: Wed, 25 Mar 2015 11:35:46 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 08:05:03 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] #34 (security-arch): Required fingerprint algorithms 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, 25 Mar 2015 18:35:47 -0000 #34: Required fingerprint algorithms It would be useful to know what fingerprint algorithms requirements are, at various levels. This was raised in July 2014: http://www.ietf.org/mail-archive/web/rtcweb/current/msg12660.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb- bernard_aboba@hotmail.com | security-arch@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: security-arch | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From nobody Fri Apr 3 08: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 5D72E1AC430 for ; Wed, 25 Mar 2015 11:47:27 -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=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 XkUOBMdm-1Ny for ; Wed, 25 Mar 2015 11:47:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 7F10F1B2B2F for ; Wed, 25 Mar 2015 11:47:24 -0700 (PDT) Received: from localhost ([::1]:40632 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YaqKq-0001vg-8m; Wed, 25 Mar 2015 11:47:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Wed, 25 Mar 2015 18:47:24 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/35 Message-ID: <066.5dbe5c56a52f02aa14701169a217a7d2@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-rtcweb-security-arch@ietf.org Resent-Message-Id: <20150325184724.7F10F1B2B2F@ietfa.amsl.com> Resent-Date: Wed, 25 Mar 2015 11:47:24 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 08:05:03 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] #35 (security-arch): srtp_mki field 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, 25 Mar 2015 18:47:27 -0000 #35: srtp_mki field A question was asked about use of MKI in RTCWEB in January 2015: http://www.ietf.org/mail-archive/web/rtcweb/current/msg14068.html Martin's recommendation was that this be explicitly prohibited or discouraged: http://www.ietf.org/mail-archive/web/rtcweb/current/msg14072.html Does this advice belong in this document? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb- bernard_aboba@hotmail.com | security-arch@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: security-arch | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From nobody Fri Apr 3 08:05: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 B60051B2A3A for ; Wed, 25 Mar 2015 11:54:31 -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=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 geZ1kxXxa_cn for ; Wed, 25 Mar 2015 11:54:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A8BE21AC41C for ; Wed, 25 Mar 2015 11:54:30 -0700 (PDT) Received: from localhost ([::1]:40866 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YaqRi-000149-EK; Wed, 25 Mar 2015 11:54:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Wed, 25 Mar 2015 18:54:30 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/36 Message-ID: <066.fac1ca456741e3eb2112cb269bf3ec43@trac.tools.ietf.org> X-Trac-Ticket-ID: 36 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-rtcweb-security-arch@ietf.org Resent-Message-Id: <20150325185430.A8BE21AC41C@ietfa.amsl.com> Resent-Date: Wed, 25 Mar 2015 11:54:30 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 08:05:03 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] #36 (security-arch): DTLS renegotiation 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, 25 Mar 2015 18:54:31 -0000 #36: DTLS renegotiation Back in December, Roman Shpount noted that existing WebRTC browsers do not support DTLS/SRTP renegotiation: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13584.html Martin replied here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13588.html Should the existing behavior be documented in this draft? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb- bernard_aboba@hotmail.com | security-arch@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: security-arch | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From nobody Fri Apr 3 08:05: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 851431A8901 for ; Wed, 25 Mar 2015 12:02:47 -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=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 RBCjTw2n1j2j for ; Wed, 25 Mar 2015 12:02:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 C001D1B2AF4 for ; Wed, 25 Mar 2015 12:02:21 -0700 (PDT) Received: from localhost ([::1]:41247 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YaqZI-0002iS-E6; Wed, 25 Mar 2015 12:02:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Wed, 25 Mar 2015 19:02:20 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/37 Message-ID: <066.d5085f15d86e6085c04560c85023c73c@trac.tools.ietf.org> X-Trac-Ticket-ID: 37 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-rtcweb-security-arch@ietf.org Resent-Message-Id: <20150325190221.C001D1B2AF4@ietfa.amsl.com> Resent-Date: Wed, 25 Mar 2015 12:02:21 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 08:05:03 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] #37 (security-arch): 6.4.1 PeerConnection Origin Check 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, 25 Mar 2015 19:02:47 -0000 #37: 6.4.1 PeerConnection Origin Check See: http://www.ietf.org/mail-archive/web/rtcweb/current/msg12747.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb- bernard_aboba@hotmail.com | security-arch@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: security-arch | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From nobody Fri Apr 3 08:05: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 6B00A1ACC7F for ; Wed, 25 Mar 2015 12:03:21 -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=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 MCbjWbgRPwGG for ; Wed, 25 Mar 2015 12:03:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 185D81B2AA9 for ; Wed, 25 Mar 2015 12:03:12 -0700 (PDT) Received: from localhost ([::1]:41358 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yaqa7-0003Lp-RF; Wed, 25 Mar 2015 12:03:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Wed, 25 Mar 2015 19:03:11 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/38 Message-ID: <066.afa456473681902151dadae7f885fb0d@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-rtcweb-security-arch@ietf.org Resent-Message-Id: <20150325190312.185D81B2AA9@ietfa.amsl.com> Resent-Date: Wed, 25 Mar 2015 12:03:12 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 08:05:03 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] #38 (security-arch): 5.6.5.3.3: Managing User Login 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, 25 Mar 2015 19:03:21 -0000 #38: 5.6.5.3.3: Managing User Login See: http://www.ietf.org/mail-archive/web/rtcweb/current/msg12748.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb- bernard_aboba@hotmail.com | security-arch@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: security-arch | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From nobody Fri Apr 3 08:05: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 18E671B2B58 for ; Wed, 25 Mar 2015 12:07:14 -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=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 ArUxDA7lvZ4l for ; Wed, 25 Mar 2015 12:07:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 858C81B2B87 for ; Wed, 25 Mar 2015 12:06:59 -0700 (PDT) Received: from localhost ([::1]:41624 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yaqdn-0004Ed-3W; Wed, 25 Mar 2015 12:06:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Wed, 25 Mar 2015 19:06:59 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/39 Message-ID: <066.a20804b1415fcc456e383a915eb16758@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-rtcweb-security-arch@ietf.org Resent-Message-Id: <20150325190659.858C81B2B87@ietfa.amsl.com> Resent-Date: Wed, 25 Mar 2015 12:06:59 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 08:05:03 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] #39 (security-arch): RTP and RTCP Key Management (mux and non-mux) 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, 25 Mar 2015 19:07:14 -0000 #39: RTP and RTCP Key Management (mux and non-mux) Back in July, the following question was raised: http://www.ietf.org/mail-archive/web/rtcweb/current/msg12739.html And clarified here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg12743.html The answer (that it is required to use separate DTLS associations for RTP and RTCP) does not appear to have been reflected in the document. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb- bernard_aboba@hotmail.com | security-arch@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: security-arch | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From nobody Fri Apr 3 08:05: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 7A0171A8999 for ; Wed, 25 Mar 2015 12:08: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=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 OqENTKF-ILtM for ; Wed, 25 Mar 2015 12:08:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 4A5111B2B87 for ; Wed, 25 Mar 2015 12:08:45 -0700 (PDT) Received: from localhost ([::1]:41712 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YaqfV-0004bW-1Q; Wed, 25 Mar 2015 12:08:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Wed, 25 Mar 2015 19:08:45 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/40 Message-ID: <066.4c7aba5e38167b89f38ffbbf6d2cec5e@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-rtcweb-security-arch@ietf.org Resent-Message-Id: <20150325190845.4A5111B2B87@ietfa.amsl.com> Resent-Date: Wed, 25 Mar 2015 12:08:45 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 08:05:03 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] #40 (security-arch): Multiple meanings of "SDES" 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, 25 Mar 2015 19:08:51 -0000 #40: Multiple meanings of "SDES" Colin Perkins raised the following issue: http://www.ietf.org/mail-archive/web/rtcweb/current/msg12725.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb- bernard_aboba@hotmail.com | security-arch@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: security-arch | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From nobody Fri Apr 3 08:05: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 94FE51B2AE5 for ; Wed, 25 Mar 2015 12:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.84 X-Spam-Level: X-Spam-Status: No, score=0.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001, TVD_SPACE_RATIO_MINFP=2.749, 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 GOSVJYwcDWCs for ; Wed, 25 Mar 2015 12:09:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B80991A8999 for ; Wed, 25 Mar 2015 12:09:49 -0700 (PDT) Received: from localhost ([::1]:41756 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YaqgW-0004tM-VG; Wed, 25 Mar 2015 12:09:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-security@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Wed, 25 Mar 2015 19:09:48 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/41 Message-ID: <066.f98c17c35bb391b5679f69c03121803e@trac.tools.ietf.org> X-Trac-Ticket-ID: 41 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-security@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-rtcweb-security@ietf.org Resent-Message-Id: <20150325190949.B80991A8999@ietfa.amsl.com> Resent-Date: Wed, 25 Mar 2015 12:09:49 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 08:05:03 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] #41 (security): Identity Assertions 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, 25 Mar 2015 19:09:50 -0000 #41: Identity Assertions From Michael Proctor, back in July: http://www.ietf.org/mail-archive/web/rtcweb/current/msg12696.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb- bernard_aboba@hotmail.com | security@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: security | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From nobody Fri Apr 3 08:05: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 443C11B2B8B for ; Wed, 25 Mar 2015 12:13:37 -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=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 bcy3lLnxk31G for ; Wed, 25 Mar 2015 12:13:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 BD8431B2B87 for ; Wed, 25 Mar 2015 12:13:31 -0700 (PDT) Received: from localhost ([::1]:41942 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yaqk7-0006nO-Bk; Wed, 25 Mar 2015 12:13:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Wed, 25 Mar 2015 19:13:31 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/42 Message-ID: <066.9d82c3cabd1c87305f5c9143788eeb88@trac.tools.ietf.org> X-Trac-Ticket-ID: 42 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-rtcweb-security-arch@ietf.org Resent-Message-Id: <20150325191331.BD8431B2B87@ietfa.amsl.com> Resent-Date: Wed, 25 Mar 2015 12:13:31 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 08:05:03 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] #42 (security-arch): Idp for RTP And RTCP 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, 25 Mar 2015 19:13:37 -0000 #42: Idp for RTP And RTCP Back in July, the following question was raised: http://www.ietf.org/mail-archive/web/rtcweb/current/msg12643.html Martin suggested a resolution here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg12644.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb- bernard_aboba@hotmail.com | security-arch@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: security-arch | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From nobody Fri Apr 3 08:05: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 1F3A81B2BBC for ; Wed, 25 Mar 2015 12:14:46 -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=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 mGTTVlgHfdI5 for ; Wed, 25 Mar 2015 12:14:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 0784E1B2BAF for ; Wed, 25 Mar 2015 12:14:35 -0700 (PDT) Received: from localhost ([::1]:42077 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yaql8-0007dh-Ft; Wed, 25 Mar 2015 12:14:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Wed, 25 Mar 2015 19:14:34 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/34#comment:1 Message-ID: <081.ade10073bd9b04a72b09c7f88fbd0fba@trac.tools.ietf.org> References: <066.1f587dc698ac0470383925900c50e054@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <066.1f587dc698ac0470383925900c50e054@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-rtcweb-security-arch@ietf.org Resent-Message-Id: <20150325191435.0784E1B2BAF@ietfa.amsl.com> Resent-Date: Wed, 25 Mar 2015 12:14:35 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 08:05:03 -0700 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #34 (security-arch): Required fingerprint algorithms 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, 25 Mar 2015 19:14:46 -0000 #34: Required fingerprint algorithms Comment (by bernard_aboba@hotmail.com): Here is more detail on the original issue from Iñaki: http://www.ietf.org/mail-archive/web/rtcweb/current/msg12657.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb- bernard_aboba@hotmail.com | security-arch@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: security-arch | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: rtcweb From nobody Fri Apr 3 09: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 78B0E1AC443 for ; Fri, 3 Apr 2015 09:28:11 -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_14=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 FdFHixYzjGVS for ; Fri, 3 Apr 2015 09:28:10 -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 20C2B1ACD24 for ; Fri, 3 Apr 2015 09:28:10 -0700 (PDT) Received: by igcau2 with SMTP id au2so103149143igc.0 for ; Fri, 03 Apr 2015 09:28: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=XHVZazVrkcTV0uReAp+YiTMxrscYJDDh9uNW/vqLaBY=; b=YKcQ1ciENCskUgByWjPxEMxNQGvzgHKfBewhgczpYT2voxXfFmUAsevB3H8kQTMCUB LtpQ3csyKzwncGDKME9O53Mf/V06NiogAz3iJWrz5Q/AqMD3niWApY0v0hiyRqlsSUbz Rn4lKEcdKyab6IryCmkxwj4w59NHRtzC8hrjio0A4l+aBDE8svbmvHVfIsR0antznrO9 pWez8s0Y+a38on3sMrNvdRBWuesMePPnSLwPwc+/Ql7bedobESIGAl+kI+Z2IRb0zun7 bvNT1OPbZ0GC745u7qyHQhPkegCDQ/Qlbk1d9rtlS5rjhaN+mny1MvK4DteEQUFmy+2H vAXw== X-Gm-Message-State: ALoCoQk8yJuDXaL1pi9IbF21y9H4ds3jnW944RjY2nyN0R/PzTMuMdUYfPdm1wV9EiKnBNu1k3cc X-Received: by 10.107.135.75 with SMTP id j72mr5136355iod.0.1428078489533; Fri, 03 Apr 2015 09:28:09 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by mx.google.com with ESMTPSA id x10sm1743113igl.13.2015.04.03.09.28.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2015 09:28:08 -0700 (PDT) Received: by igblo3 with SMTP id lo3so9686133igb.1 for ; Fri, 03 Apr 2015 09:28:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.204.14 with SMTP id fk14mr4820535icb.96.1428078487226; Fri, 03 Apr 2015 09:28:07 -0700 (PDT) Received: by 10.36.110.141 with HTTP; Fri, 3 Apr 2015 09:28:07 -0700 (PDT) In-Reply-To: <066.9d82c3cabd1c87305f5c9143788eeb88@trac.tools.ietf.org> References: <066.9d82c3cabd1c87305f5c9143788eeb88@trac.tools.ietf.org> Date: Fri, 3 Apr 2015 12:28:07 -0400 Message-ID: From: Roman Shpount To: rtcweb issue tracker Content-Type: multipart/alternative; boundary=20cf30363b93f150290512d46ea8 Archived-At: Cc: Bernard Aboba , draft-ietf-rtcweb-security-arch@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] #42 (security-arch): Idp for RTP And RTCP 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, 03 Apr 2015 16:28:11 -0000 --20cf30363b93f150290512d46ea8 Content-Type: text/plain; charset=UTF-8 Where is the use of multiple fingerprint attributes per single m=line is defined? RFC 4572 is written in such a way that only one fingerprint per m= line can be present. _____________ Roman Shpount On Wed, Mar 25, 2015 at 3:13 PM, rtcweb issue tracker < trac+rtcweb@zinfandel.tools.ietf.org> wrote: > #42: Idp for RTP And RTCP > > Back in July, the following question was raised: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg12643.html > > Martin suggested a resolution here: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg12644.html > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-rtcweb- > bernard_aboba@hotmail.com | security-arch@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: security-arch | Version: 1.0 > Severity: In WG Last Call | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf30363b93f150290512d46ea8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Where is the use of multiple fingerprint attributes per si= ngle m=3Dline is defined?
RFC 4572 is written in such a way that only o= ne fingerprint per m=3D line can be present.

_____________=
Roman Shpount

On Wed, Mar 25, 2015 at 3:13 PM, rtcweb issu= e tracker <trac+rtcweb@zinfandel.tools.ietf.org>= wrote:
#42: Idp for RTP And RTCP<= br>
=C2=A0Back in July, the following question was raised:
=C2=A0http://www.ietf.org/mail-archive/web/rtcweb/curr= ent/msg12643.html

=C2=A0Martin suggested a resolution here:
=C2=A0http://www.ietf.org/mail-archive/web/rtcweb/curr= ent/msg12644.html

--
-------------------------------------+-------------------------------------=
=C2=A0Reporter:=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 =C2=A0|=C2=A0 =C2=A0 =C2=A0 Owner:=C2=A0 dr= aft-ietf-rtcweb-
=C2=A0 bernard_aboba@hotmail.c= om=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 security-arch@tools.ietf.org
=C2=A0 =C2=A0 =C2=A0Type:=C2=A0 defect=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=A0Status:=C2=A0 new =C2=A0Priority:=C2=A0 major=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 Milestone:=C2=A0 milestone1
Component:=C2=A0 security-arch=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 Version:=C2=A0 1.0
=C2=A0Severity:=C2=A0 In WG Last Call=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0Keywords:
-------------------------------------+-------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/42<= /a>>
rtcweb <http= ://tools.ietf.org/rtcweb/>

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

--20cf30363b93f150290512d46ea8-- From nobody Fri Apr 3 10:00: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 68ED51ACD9C for ; Fri, 3 Apr 2015 10:00:48 -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_14=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 sFPi6e6w7PwW for ; Fri, 3 Apr 2015 10:00:47 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 9A2351ACD98 for ; Fri, 3 Apr 2015 10:00:47 -0700 (PDT) Received: by obvd1 with SMTP id d1so178445680obv.0 for ; Fri, 03 Apr 2015 10:00:47 -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=+4q3jux0LL9yU23nkSzVF7jspwLsgC6V6uHfbntCqaA=; b=FkhVDg6uwigtxmu2aKNbUz8T8NIdkBZmkgflntfmqjI1AJ6xbycoI8ZpMetXgj4jHf vrK+dMBwcaa/729lLyKWXhaN6dejuG6mUzeeWVvuyKp8j3QAWwywkaqPTGuNH6491j1h pxZiceMXEINjzAmRw/NLEDOQJ4/9lh/elbpRuND8f209UJBXrxO/r4hOTpeRrrsHYn3I 5W6RgaAHX66F4j1X+uuJUEPoeOMTO6EQPUE1nwnjmelSsO7lrlSIsqXj0VJO95I/JlDJ ZdYpJvzxkaSuuc+pUgcVwv7ZfVdz4rOoJJfhp+80wbLc89/tCS3N1B1KEnFPqgxqM8cI c1qQ== MIME-Version: 1.0 X-Received: by 10.60.155.135 with SMTP id vw7mr3997269oeb.62.1428080447084; Fri, 03 Apr 2015 10:00:47 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Fri, 3 Apr 2015 10:00:47 -0700 (PDT) In-Reply-To: References: <066.9d82c3cabd1c87305f5c9143788eeb88@trac.tools.ietf.org> Date: Fri, 3 Apr 2015 10:00:47 -0700 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Bernard Aboba , "rtcweb@ietf.org" Subject: Re: [rtcweb] #42 (security-arch): Idp for RTP And RTCP 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, 03 Apr 2015 17:00:48 -0000 On 3 April 2015 at 09:28, Roman Shpount wrote: > Where is the use of multiple fingerprint attributes per single m=line is > defined? > RFC 4572 is written in such a way that only one fingerprint per m= line can > be present. I don't think that's right. 4572 only requires the fingerprint to match the hash used in the certificate signature. If you have multiple certificates, then you are ok. As we discussed in the meeting, we are going to need to update 4572. The requirement I mention is bogus anyway. From nobody Fri Apr 3 14:57: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 CE0EA1A1AAD for ; Fri, 3 Apr 2015 14:57:14 -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_14=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 0E4lV7n4BLlD for ; Fri, 3 Apr 2015 14:57:13 -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 8333D1A1AA6 for ; Fri, 3 Apr 2015 14:57:13 -0700 (PDT) Received: by igblo3 with SMTP id lo3so14554159igb.1 for ; Fri, 03 Apr 2015 14:57: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=2vBuIyzOxOIpoh42Jrsk377jIQ39LDvY9Ym8IkGHJcQ=; b=MNQbnhQCzdRmwiFl1E5dorxe5rtS5eLWHvoPafapLnyUl3mkJqTZJPDHcjx0GN4yKG Bb+dQD7PSr0QDehIJzq0lbEQ1cMVh/jKv51+pG7ydMmwY58lvXwuu4f3oJZwRmy7487U tiBoSQyTbbYamdhBoXKYrHhyxTj2g8hZKO5WiKaoq65MvEs+T8i0d1JKfyfCGzVUlbQb A+l/Q5H9Ar2SV6YE6ccpQvw/yhew3GnxV1adh5J+G+OJ+kxgWpW+YBa4lUsqmRBcSLnN xt8ltqlbmIhtxDlYpN3ECdk2y745wCwkZWiwBDvm6FNYYB8PhgkBvPp2IsSZ6eaYOm73 E4vw== MIME-Version: 1.0 X-Received: by 10.43.61.80 with SMTP id wv16mr6178174icb.97.1428098232538; Fri, 03 Apr 2015 14:57:12 -0700 (PDT) Received: by 10.107.173.232 with HTTP; Fri, 3 Apr 2015 14:57:12 -0700 (PDT) In-Reply-To: References: <066.9d82c3cabd1c87305f5c9143788eeb88@trac.tools.ietf.org> Date: Fri, 3 Apr 2015 14:57:12 -0700 Message-ID: From: Suhas Nandakumar To: Martin Thomson Content-Type: multipart/alternative; boundary=bcaec51a8978daf0cf0512d9073b Archived-At: Cc: Bernard Aboba , "rtcweb@ietf.org" Subject: Re: [rtcweb] #42 (security-arch): Idp for RTP And RTCP 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, 03 Apr 2015 21:57:15 -0000 --bcaec51a8978daf0cf0512d9073b Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 10:00 AM, Martin Thomson wrote: > On 3 April 2015 at 09:28, Roman Shpount wrote: > > Where is the use of multiple fingerprint attributes per single m=line is > > defined? > > RFC 4572 is written in such a way that only one fingerprint per m= line > can > > be present. > > I don't think that's right. 4572 only requires the fingerprint to > match the hash used in the certificate signature. If you have > multiple certificates, then you are ok. > > As we discussed in the meeting, we are going to need to update 4572. > The requirement I mention is bogus anyway. > > I agree that RFC4572 doesn't say against using multiple fingerprints except for saying how it is generated as Martin suggested. I don't think RFC4572 needs to be updated either for this... > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec51a8978daf0cf0512d9073b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 3, 2015 at 10:00 AM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 3 April 2015 at 09:28, Roman Shpount <roman@telurix.com> wrote:
> Where is the use of multiple fingerprint attributes per single m=3Dlin= e is
> defined?
> RFC 4572 is written in such a way that only one fingerprint per m=3D l= ine can
> be present.

I don't think that's right.=C2=A0 4572 only requires the fin= gerprint to
match the hash used in the certificate signature.=C2=A0 If you have
multiple certificates, then you are ok.

As we discussed in the meeting, we are going to need to update 4572.
The requirement I mention is bogus anyway.

I= agree that RFC4572 doesn't say against using multiple fingerprints exc= ept for saying how it is generated as Martin suggested. I don't think R= FC4572 needs to be updated either for this...=C2=A0
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec51a8978daf0cf0512d9073b-- From nobody Fri Apr 3 19:54: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 387951A8907 for ; Fri, 3 Apr 2015 19:54:16 -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_14=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 D2XQGyPTsvud for ; Fri, 3 Apr 2015 19:54:15 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-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 108441A8902 for ; Fri, 3 Apr 2015 19:54:14 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so94291227ieb.0 for ; Fri, 03 Apr 2015 19:54: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=mFqt2VeaA3n24ONvv8IWEtTRcqYynwD2Tsce2aIedDo=; b=NGF2D6OqZ97kiCBJuQOcwNU9qYWgbL58IZgi94BmDvIgjobKDVXP1ZsYtAVJ0vY0eY Z+eknQAMdI+AlG3z+PixcZSN7Upuve/thVNycbXq8CJh1AoC5Ojg/evvnasHApDFNF5s /N6PSK5rGhR1GWeSKJf5WlXDDZ71w1PYtVvbJokAPjM58bfsC95Z39M6HLURxXzKhDUb cdS9W+W4gXwhR9WoDWcfro10cU42jt9666tGWuZl2LTP9BmGf0xB4GQbP+nZw2Rd4I3z zMfmYtoSMAEgJb4wa28DEtuMFlgrXVmhMKnVTECNslifAwJEt4VZygBSVllbKiaolIBP HT8A== X-Gm-Message-State: ALoCoQkCZvfaxcIaSRF9P1ZNgIKfHkgsasmi2UQTR+DWskN9myBxeSkfE6PAjEjx3zEkBzT4uA9U X-Received: by 10.50.29.52 with SMTP id g20mr10206125igh.27.1428116054227; Fri, 03 Apr 2015 19:54:14 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com. [209.85.213.174]) by mx.google.com with ESMTPSA id b137sm6793013ioe.36.2015.04.03.19.54.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2015 19:54:13 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so105102879igb.1 for ; Fri, 03 Apr 2015 19:54:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.155.13 with SMTP id d13mr7794967ioe.29.1428116051819; Fri, 03 Apr 2015 19:54:11 -0700 (PDT) Received: by 10.36.110.141 with HTTP; Fri, 3 Apr 2015 19:54:11 -0700 (PDT) In-Reply-To: References: <066.9d82c3cabd1c87305f5c9143788eeb88@trac.tools.ietf.org> Date: Fri, 3 Apr 2015 22:54:11 -0400 Message-ID: From: Roman Shpount To: Suhas Nandakumar Content-Type: multipart/alternative; boundary=001a1141bd00f784690512dd2d00 Archived-At: Cc: Bernard Aboba , "rtcweb@ietf.org" Subject: Re: [rtcweb] #42 (security-arch): Idp for RTP And RTCP 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, 04 Apr 2015 02:54:16 -0000 --001a1141bd00f784690512dd2d00 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 5:57 PM, Suhas Nandakumar wrote: > > > On Fri, Apr 3, 2015 at 10:00 AM, Martin Thomson > wrote: > >> On 3 April 2015 at 09:28, Roman Shpount wrote: >> > Where is the use of multiple fingerprint attributes per single m=line is >> > defined? >> > RFC 4572 is written in such a way that only one fingerprint per m= line >> can >> > be present. >> >> I don't think that's right. 4572 only requires the fingerprint to >> match the hash used in the certificate signature. If you have >> multiple certificates, then you are ok. >> >> As we discussed in the meeting, we are going to need to update 4572. >> The requirement I mention is bogus anyway. >> >> I agree that RFC4572 doesn't say against using multiple fingerprints > except for saying how it is generated as Martin suggested. I don't think > RFC4572 needs to be updated either for this... > >> >> It does not say anything about how multiple fingerprints should work either, i.e. it does not say that only one needs to match. I agree that this is logical, but I do not think it is mentioned anywhere. _____________ Roman Shpount --001a1141bd00f784690512dd2d00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 3, 2015 at 5:57 PM, Suhas Nandakumar <suhasietf@gmail.com&g= t; wrote:


On Fri, Apr= 3, 2015 at 10:00 AM, Martin Thomson <martin.thomson@gmail.com&= gt; wrote:
On 3 April 2015 at 09:28, Roman= Shpount <roman@t= elurix.com> wrote:
> Where is the use of multiple fingerprint attributes per single m=3Dlin= e is
> defined?
> RFC 4572 is written in such a way that only one fingerprint per m=3D l= ine can
> be present.

I don't think that's right.=C2=A0 4572 only requires the fin= gerprint to
match the hash used in the certificate signature.=C2=A0 If you have
multiple certificates, then you are ok.

As we discussed in the meeting, we are going to need to update 4572.
The requirement I mention is bogus anyway.

I agree that RFC457= 2 doesn't say against using multiple fingerprints except for saying how= it is generated as Martin suggested. I don't think RFC4572 needs to be= updated either for this...=C2=A0
=


It does not say anything about how multiple fingerpri= nts should work either, i.e. it does not say that only one needs to match. = I agree that this is logical, but I do not think it is mentioned anywhere.<= /div>
_____________
Roman Shpount
=C2=A0
=C2=A0
--001a1141bd00f784690512dd2d00-- From nobody Mon Apr 6 12:39: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 B0D0D1A90D3 for ; Mon, 6 Apr 2015 12:39:58 -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 AHO1EoWYa1VW for ; Mon, 6 Apr 2015 12:39:57 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43CB1A0231 for ; Mon, 6 Apr 2015 12:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3454; q=dns/txt; s=iport; t=1428349196; x=1429558796; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gx9Qa8lO5Xqtt9gjjMdU2VDKLv+tkEvQuWfeqhc3rAI=; b=iECVmeFegeClf5+47+M64Jxw9rovou0wir5tvM0EIlXaWWTJBxi7G+kv AFeXk4j0lqvlFyUTNbDQC56viOSUPKAkTJ0Cy2FHvYa0Cj63WSwHcfOKD 7Lq8DoKWKo1rciF91p8dZhLhuZBI/IQ1CSix/KrwlJ9cmPPSdoO7KYHms M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQA34CJV/51dJa1cgwhSXAXFKgqFL04CgSFMAQEBAQEBfoQeAQEBAwEBAQE3NAsFCwIBCBgeECcLJQIEAQ0FiCcIDcxMAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLKYE9gmoBAR0zB4MXgRYFkGuKAoEdgzWMOoNIIoIDDQ+BUG+BCzl/AQEB X-IronPort-AV: E=Sophos;i="5.11,533,1422921600"; d="scan'208";a="138704435" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP; 06 Apr 2015 19:39:56 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t36JdtEO030533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Apr 2015 19:39:56 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.130]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 6 Apr 2015 14:39:55 -0500 From: "Cullen Jennings (fluffy)" To: Harald Tveit Alvestrand , Adam Roach Thread-Topic: [rtcweb] SDP lines (JSEP Issue 27) Thread-Index: AQHQcKF0wGF8Ci0c+0+XWZV08Q3otA== Date: Mon, 6 Apr 2015 19:40:14 +0000 Message-ID: References: <5519753D.1080907@nostrum.com> <30772BF4-B814-4CB2-932F-96885D0BD76E@iii.ca> <5519A5A4.4070205@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <8CE6DCCF8C166C4A8D1965F9519D4079@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP lines (JSEP Issue 27) 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 Apr 2015 19:39:58 -0000 I think we are just seeing different meanings in the word ignore. I see it = as "ignore" would mean the browser did not process or store whatever it fou= nd in something that it MUST ignore. It's doing syntax checking on this and= then storing it and then passing it back later (presumable unchanged).=20 The things we are talking about here (with the exception of k=3D) seems lik= e if some browser wanted to use them in the way SDP meant that is fine too,= it just SDP does not require anything to happen with them.=20 Can we find a different way of phrasing this than "MUST ignore" - I'm agree= ing with you on what browser need to implement, I just don't think "MUST ig= nore" is the right way to say it.=20 > On Apr 2, 2015, at 9:14 AM, Harald Alvestrand wrot= e: >=20 > The API already exposes the sdp that went into set remote. Those lines sh= ould show up there. Otherwise, must ignore seems right to me. >=20 > Den 30. mars 2015 20.36.04 GMT+01:00, skrev Adam Roach = : > On 3/30/15 14:18, Cullen Jennings wrote: > On Mar 30, 2015, at 10:09 AM, Adam Roach wrote: >=20 > i=3D, u=3D, e=3D, p=3D, z=3D, r=3D > SHOULD NOT send, MUST ignore. > I don't think MUST ignore is correct. First to be clear, I'm not saying = the browser needs to do anything with the info in theses lines. >=20 > I think MAY ignore or not typically used by a webrtc browser might be a = better way to say it. For example, if rtcweb device was taking a streaming = video session via webrtc protocols, it might make sense for it to use the i= =3D or u=3D particularly if the SDP had originally come from an RTSP stream= that was gatewayed to WebRTC. Similarly if a browser reported the full SDP= it had > received in some stats interface, I would expect it not to ignore the lin= es but actually report what it was it received. >=20 >=20 > To be clear, I'm not saying the browser needs to do anything with the in= fo in theses lines - it's fine to ignore them. But that's very different fr= om all webrtc things must ignore them. (and I agree with SHOULD NOT send pa= rt) >=20 > I think we're in agreement about the principle, but might be at cross=20 > purposes regarding the venue: I agree that non-browsers may well have=20 > reasons to use these fields, but I don't think this document has much=20 > bearing on what those implementations do; at least, not as it currently=20 > describes itself. >=20 > From the introduction section, JSEP "describes how the W3C WEBRTC=20 > RTCPeerConnection interface is used to control the setup, management and= =20 > teardown of a multimedia session." So, in the context of *this*=20 > document, it would *appear* that we're in agreement that > the proper=20 >=20 > normative behavior is to ignore the values in these lines. So I can see=20 > why we might be quibbling about "SHOULD" versus "MUST," but your=20 > objection seems much broader than that. >=20 > If our difference of opinion here arises from differing views about=20 > intended scope for the JSEP document, then we need to start a broader=20 > conversation around, minimally, the introduction section of the current=20 > draft. >=20 > /a >=20 >=20 > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. From nobody Tue Apr 7 02:39: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 95D8C1B339C for ; Tue, 7 Apr 2015 02:39:37 -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 kxfj5sjZ2qP7 for ; Tue, 7 Apr 2015 02:39:35 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 78ACD1B33A7 for ; Tue, 7 Apr 2015 02:39:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 218237C4EA3; Tue, 7 Apr 2015 11:39:34 +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 g35VmiBaF8_U; Tue, 7 Apr 2015 11:39:33 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:2891:c682:6461:104e] (unknown [IPv6:2001:470:de0a:27:2891:c682:6461:104e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 077E47C3813; Tue, 7 Apr 2015 11:39:32 +0200 (CEST) Message-ID: <5523A5D4.9070907@alvestrand.no> Date: Tue, 07 Apr 2015 11:39:32 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , Adam Roach References: <5519753D.1080907@nostrum.com> <30772BF4-B814-4CB2-932F-96885D0BD76E@iii.ca> <5519A5A4.4070205@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP lines (JSEP Issue 27) 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 Apr 2015 09:39:37 -0000 Den 06. april 2015 21:40, skrev Cullen Jennings (fluffy): > I think we are just seeing different meanings in the word ignore. I see it as "ignore" would mean the browser did not process or store whatever it found in something that it MUST ignore. It's doing syntax checking on this and then storing it and then passing it back later (presumable unchanged). > > The things we are talking about here (with the exception of k=) seems like if some browser wanted to use them in the way SDP meant that is fine too, it just SDP does not require anything to happen with them. > > Can we find a different way of phrasing this than "MUST ignore" - I'm agreeing with you on what browser need to implement, I just don't think "MUST ignore" is the right way to say it. > For browsers, it would be a source of inconsistent behaviour if one browser did something magical with "z=" (timezone adjustment) or "p=" (phone numbers) and another browser did not. Javascript apps that cared would have to adapt according to which browser they ran on, which is not a Good Thing. For non-browsers, which may or may not bundle an application inside whatever-it-is, they need to be free to do whatever they need to do. I think "browsers MUST ignore" is the right thing to do, even if the language may be expressed better in a different way. From nobody Tue Apr 7 03:28: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 9FE331B33E9 for ; Tue, 7 Apr 2015 03:28:53 -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 tYj3rMkMK-wh for ; Tue, 7 Apr 2015 03:28:52 -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 DCDC21B33E8 for ; Tue, 7 Apr 2015 03:28:51 -0700 (PDT) Received: by iggg4 with SMTP id g4so7764398igg.0 for ; Tue, 07 Apr 2015 03:28: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:mime-version:date:message-id:subject:from:to :content-type; bh=VOFzQVqsb9BB4R9U/KGST4PtoZ0FAR+iRgIAiis28oA=; b=H37n72W1j9mo3ngkh6Gpsmgm+J46XRjDG9wNT3ChyiXwuYhZpwSFgmS1J6KoBEEBfg RsJRft7p073XOCfr2PuT1MKeytRZQgMALQsHR947l+2StfCoGzXZsAeSwqLiDnwIg+0O xgFXT/Fe40cAHO0+7Bl1yOX4H59X8LPSkAeIS4L4z7dwVZ49S1RCzRBTPkGPjOH4j9lE FF3MqlOYeuRihSgjfQgfIML+v2QokG43rP9CS0nlNT5h7QcJ8xREguH90vtI7gBGghwO xH5fof3Lnxw1u4wB4AjZkfSWG5TdBt1T/snXKc0RSB2A09n/r4f0YhwS+MuZ20ht4rmS l/gA== X-Gm-Message-State: ALoCoQmgmj4jNEPIkwjDePq1SLAFjlzlBjRTzhJ3SawXjE7/LMFQRyysY0xeIguEIn9XkQgxpuY5 X-Received: by 10.50.136.228 with SMTP id qd4mr2486800igb.13.1428402531364; Tue, 07 Apr 2015 03:28:51 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by mx.google.com with ESMTPSA id b6sm4554224igb.15.2015.04.07.03.28.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 03:28:50 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so7441831igb.1 for ; Tue, 07 Apr 2015 03:28:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.138.68 with SMTP id qo4mr2401534igb.33.1428402529224; Tue, 07 Apr 2015 03:28:49 -0700 (PDT) Received: by 10.36.110.149 with HTTP; Tue, 7 Apr 2015 03:28:49 -0700 (PDT) Date: Tue, 7 Apr 2015 06:28:49 -0400 Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1134bd8059d02005131fe1f1 Archived-At: Subject: [rtcweb] ice-lite as a media level attribute in jsep 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 Apr 2015 10:28:53 -0000 --001a1134bd8059d02005131fe1f1 Content-Type: text/plain; charset=UTF-8 Why is ice-lite a media level attribute in JSEP section 5.6.2 ( http://rtcweb-wg.github.io/jsep/#rfc.section.5.6.2)? Per RFC 5245 (http://tools.ietf.org/html/rfc5245#section-15.3) "ice-lite" is a session level attribute only. Have this been redefined somewhere? _____________ Roman Shpount --001a1134bd8059d02005131fe1f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Why is ice-lite a media level attribute in JSEP section 5.= 6.2 (http://rtcweb-wg.github.io/jsep/#rfc.section.5.6.2)?=C2=A0<= div>
Per RFC 5245 (http://tools.ietf.org/html/rfc5245#sect= ion-15.3) "ice-lite" is a session level attribute only.

Have this been redefined somewhere?
_____________
Roman= Shpount

--001a1134bd8059d02005131fe1f1-- From nobody Tue Apr 7 15:28: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 A39C41B3CA6 for ; Tue, 7 Apr 2015 15:28:26 -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 w842v4VNYgb6 for ; Tue, 7 Apr 2015 15:28:25 -0700 (PDT) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.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 F228E1B3C9C for ; Tue, 7 Apr 2015 15:28:24 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so59903389ieb.3 for ; Tue, 07 Apr 2015 15:28: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:date:message-id:subject:from:to :content-type; bh=wMHCdINOhRf69TQYGM4hm5D8N/uhQm4NrTbS7CLAFfM=; b=QuMbevhS4gPKGr6x2Dv1vGK3RZcCliUkpanCWFT9NANmtlSB3jprX+LIQFW+bREeM3 KX8ONPMODrkoG0Wt3L82jW3SXP+46vWQXNPKIBlj+k7WzSSEKOehC8wPTFp3hSzYG4qf o8vFHr9/1jNEkYUXf7aNnDSjVp1KjnrNBvPbIiVKF2i2N3W3laGUuCGprPP/d9Ywt0t/ ZCO3YXBkJmUq6TGFBI39uPOxXpLktczN9/cJ+MlhngXmu6KzAF6MeisDNP9dawJH2P5U Fcc7SLwkePnXzEUAoaVVDylwZ2wXoAfioNJQdommFpKkZxV/Uci6dCf8fXsBFdZX8//5 /pHw== X-Gm-Message-State: ALoCoQk31HD9ey+GY8J/Pqchyqfd6IdhjSZLTke51Hn/DkI0ph/9WmSA4FPNl0LJqhMlc8RChpTW X-Received: by 10.107.137.28 with SMTP id l28mr31971082iod.23.1428445704382; Tue, 07 Apr 2015 15:28:24 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com. [209.85.213.176]) by mx.google.com with ESMTPSA id v14sm3451773igd.12.2015.04.07.15.28.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 15:28:23 -0700 (PDT) Received: by ignm3 with SMTP id m3so18342051ign.0 for ; Tue, 07 Apr 2015 15:28:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.117.4 with SMTP id ka4mr7319226igb.10.1428445702415; Tue, 07 Apr 2015 15:28:22 -0700 (PDT) Received: by 10.36.110.149 with HTTP; Tue, 7 Apr 2015 15:28:22 -0700 (PDT) Date: Tue, 7 Apr 2015 18:28:22 -0400 Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e011617aeac6e9d051329ee10 Archived-At: Subject: [rtcweb] Constraint to disable IPv6 candidate collection 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 Apr 2015 22:28:26 -0000 --089e011617aeac6e9d051329ee10 Content-Type: text/plain; charset=UTF-8 Hi All, It is possible to run into interop issues with end-points that support ICE and DTLS-SRTP but do not support IPv6, such as current versions of Firefox. Chrome currently offers googIPv6 constraint, which enables or disables IPv6 candidate collection. Unfortunately, this constraint is Chrome specific, provided via deprecated interface (PeerConnection constructor), and when this constraint is not set, Chrome collects or does not collect IPv6 candidates pretty much in random. Without setting this constraint, the same Chrome browser on the same network includes or does not include IPv6 candidates with no identifiable pattern. Because of this, we currently set googIPv6 constraint to false. Our only other alternative would be to examine the SDP and remove the IPv6 candidates and replace c= line with IPv4 address. In anticipation of IPv6 support being enabled by default, and to avoid SDP mucking, it would be better to define a constraint that can be used to suppress IPv6 candidate collection, which can be provided via current constraint interfaces. _____________ Roman Shpount --089e011617aeac6e9d051329ee10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

It is possible to run into inte= rop issues with end-points that support ICE and DTLS-SRTP but do not suppor= t IPv6, such as current versions of Firefox. Chrome currently offers googIP= v6 constraint, which enables or disables IPv6 candidate collection. Unfortu= nately, this constraint is Chrome specific, provided via deprecated interfa= ce (PeerConnection constructor), and when this constraint is not set, Chrom= e collects or does not collect IPv6 candidates pretty much in random. Witho= ut setting this constraint, the same Chrome browser on the same network inc= ludes or does not include IPv6 candidates with no identifiable pattern. Bec= ause of this, we currently set googIPv6 constraint to false. Our only other= alternative would be to examine the SDP and remove the IPv6 candidates and= replace c=3D line with IPv4 address. In anticipation of IPv6 support being= enabled by default, and to avoid SDP mucking, it would be better to define= a constraint that can be used to suppress IPv6 candidate collection, which= can be provided via current constraint interfaces.

_____________<= br>Roman Shpount
--089e011617aeac6e9d051329ee10-- From nobody Tue Apr 7 17:30: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 9AED91B2A2A for ; Tue, 7 Apr 2015 17:30:50 -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 bRDNshpLpExv for ; Tue, 7 Apr 2015 17:30:49 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F2F1B2A28 for ; Tue, 7 Apr 2015 17:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1294; q=dns/txt; s=iport; t=1428453049; x=1429662649; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6/JucUHlknlTqXvWc8wZi5Oab4xeF42Nk+tTii/xc0U=; b=auy89lHHYiTYLr/c1W0+M/viXPO17y4sZnrMtgNDq2cLrxyQ3uDiPFQI YE17f5+sE8gWZgbRez5qluhLEEVcjnAfutioN9OI5slwVBG6x+VbTu+mG VLme3HYo+/19eIePBdT2jkBlWNQqetpuVHgAsNAlD5l7c4qK/3Q/B2V5O Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BeBAAjdiRV/5JdJa1cgwWBLsNzCYdPAoEuOBQBAQEBAQEBfYQfAQEEOj8QCxguVwYTiCrMEQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLK4RJMweDF4EWBYsnj1SHFo1FIoQPHjGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.11,541,1422921600"; d="scan'208";a="139173878" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP; 08 Apr 2015 00:30:48 +0000 Received: from [10.24.196.146] ([10.24.196.146]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t380UlDp014942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 00:30:48 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Tue, 7 Apr 2015 17:30:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Roman Shpount X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Constraint to disable IPv6 candidate collection 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 Apr 2015 00:30:50 -0000 On 07-Apr-2015 03:28 pm, Roman Shpount wrote:=20 > It is possible to run into interop issues with end-points that support = ICE and DTLS-SRTP but do not support IPv6, such as current versions of = Firefox. Chrome currently offers googIPv6 constraint, which enables or = disables IPv6 candidate collection. Unfortunately, this constraint is = Chrome specific, provided via deprecated interface (PeerConnection = constructor), and when this constraint is not set, Chrome collects or = does not collect IPv6 candidates pretty much in random. Without setting = this constraint, the same Chrome browser on the same network includes or = does not include IPv6 candidates with no identifiable pattern. Because = of this, we currently set googIPv6 constraint to false. Our only other = alternative would be to examine the SDP and remove the IPv6 candidates = and replace c=3D line with IPv4 address. In anticipation of IPv6 support = being enabled by default, and to avoid SDP mucking, it would be better = to define a constraint that can be used to suppress IPv6 candidate = collection, which can be provided via current constraint interfaces. What is the interop issue? Are v6 candidates mistakenly attempted to be = processed by Firefox and failing? -d From nobody Tue Apr 7 17:58: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 44E501B2A66 for ; Tue, 7 Apr 2015 17:58:18 -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 wVH4xTeinTep for ; Tue, 7 Apr 2015 17:58:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD6E1B2A63 for ; Tue, 7 Apr 2015 17:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1499; q=dns/txt; s=iport; t=1428454696; x=1429664296; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zvN0bejHNUj/CwJ5sSHVcW2722Tm4kg9JeQ8cVqKp9M=; b=AymOpmmMukoN3Cv7nrEBlGiU7joCV/91X1jFbt6f7u42Ihd7FF/Vxr/x 742o/JlYpWVeLFdlr1KQuey034RSiKXuQRmczDGzcWmdiDwEmj7LSVARX hr70qjZXLRbR7ULIS0J1dl9ikToLq+4JhKVlFO6UvL8+iOlazdoGffECa A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBQDdeyRV/5pdJa1cgwhSXAXFTIV7AoEuTAEBAQEBAX6EHgEBAQMBOj8FCwIBCBgeEDIlAgQOBQmIGQgNzAgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyuEJA0YMweDF4EWBZB0igeBHY90g0oig29vgQNBfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,541,1422921600"; d="scan'208";a="409973107" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 08 Apr 2015 00:58:15 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t380wFKS002561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Apr 2015 00:58:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.130]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 7 Apr 2015 19:58:15 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: draft-schwartz-rtcweb-return Thread-Index: AQHQcZcXNcaRDaX+lUCRQe6Qs13tdg== Date: Wed, 8 Apr 2015 00:58:29 +0000 Message-ID: <6042868B-57EB-4C5A-B93E-C58D846E14E4@cisco.com> References: <9DA8307B-263C-4951-A55C-36B42D27C08B@cisco.com> In-Reply-To: <9DA8307B-263C-4951-A55C-36B42D27C08B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <0515A927655C71489A47EEE69D08AE57@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] draft-schwartz-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: Wed, 08 Apr 2015 00:58:18 -0000 > On Mar 26, 2015, at 9:20 AM, Cullen Jennings wrote: >=20 > I'd like to point out that the combination of ietf-tram-turn-server-disco= very and draft-schwartz-rtcweb-return allow any network you are connected t= o more or less MITM your media and do things like rate limit it, generate a= nalytics on who you are talking to, force your traffic through an intermedi= ary that is in a different legal jurisdiction and so on.=20 We discussed this after the meeting and came up with a way to resolve this= concern. Benjamin has added some text to the -06 to that specifically addr= esses this issue http://www.ietf.org/rfcdiff?url1=3Ddraft-schwartz-rtcweb-return-05&url2=3Dd= raft-schwartz-rtcweb-return-06 This completely deals with the issue I raised and with that change I suppor= t adopting this as a WG document.=20 After adoption, I think the WG should consider if any text is needed around= the issue of TURN credentials. (If you run TURN with no credentials and an= attacker can spoof the IP address in UDP packets, you can end up with the = TURN servers in a nasty forwarding loop that allows an huge amplification f= actor for an attacker trying do DOS the turn servers - this is still possib= le with authentication but you know who to blame. When TURN was first done = with was one of the reason TURN requires auth and STUN does not). However, = I believe this issue can solved and should not block adopting the draft. ) Cullen=20 From nobody Tue Apr 7 18:02: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 E74C51B2A8A for ; Tue, 7 Apr 2015 18:02:46 -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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 gXxpgeVT3L4K for ; Tue, 7 Apr 2015 18:02:45 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.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 761371B2AA5 for ; Tue, 7 Apr 2015 18:02:27 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so70105370ied.1 for ; Tue, 07 Apr 2015 18:02:26 -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=MyEr/eeBuZNRyp8vgt6wreJ3YYAJGisS/0TKICX75O4=; b=lWK7ZNFk7ze3pbir1WTPwgL1L8bE5ddYcwkylWeo2IiexbEZvQPlNDTBNfbXSm1mbH +RM5wdtINI4WQqmwYMyA+vG/Hcm3KIpn0vHtrqxl1C2axkxeJTtfETv21dh5ooOxSkFd d3pH/E5tSv85czh8r9xFNijHn+IioUhQWCily/N+t/QIeQ7B9Gcf/5n9ADhvl1VqMl6x 0SwOOG9p7cWOJaeRnFBvcsvb28lMIOiIQkcUKQqxBSER2juZq8MVdaESd7Jv1AZfzPT/ R1+wcyeg2ZTvPkgrjlL1/PdyfxoXMSakEA/UdlwFQLn0KAUua9q6k+wZy8DCEsSQBPNK Qf1Q== X-Gm-Message-State: ALoCoQlUdh59Gsdl8bqPi1+dOeT5fAZdbLn8LzjGbTOhB0+MhG8KGZmV7O4M25dGH6Mr2dq1Ixyk X-Received: by 10.107.3.17 with SMTP id 17mr33756642iod.60.1428454946901; Tue, 07 Apr 2015 18:02:26 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com. [209.85.223.177]) by mx.google.com with ESMTPSA id pl4sm5843018igb.22.2015.04.07.18.02.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 18:02:25 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so70104578ied.1 for ; Tue, 07 Apr 2015 18:02:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.91.142 with SMTP id p14mr29715669icm.24.1428454944484; Tue, 07 Apr 2015 18:02:24 -0700 (PDT) Received: by 10.36.110.149 with HTTP; Tue, 7 Apr 2015 18:02:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Apr 2015 21:02:24 -0400 Message-ID: From: Roman Shpount To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: multipart/alternative; boundary=90e6ba6150068b558205132c1564 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Constraint to disable IPv6 candidate collection 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 Apr 2015 01:02:47 -0000 --90e6ba6150068b558205132c1564 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 7, 2015 at 8:30 PM, =F0=9F=94=93Dan Wing wrot= e: > On 07-Apr-2015 03:28 pm, Roman Shpount wrote: > > It is possible to run into interop issues with end-points that support > ICE and DTLS-SRTP but do not support IPv6, such as current versions of > Firefox. Chrome currently offers googIPv6 constraint, which enables or > disables IPv6 candidate collection. Unfortunately, this constraint is > Chrome specific, provided via deprecated interface (PeerConnection > constructor), and when this constraint is not set, Chrome collects or doe= s > not collect IPv6 candidates pretty much in random. Without setting this > constraint, the same Chrome browser on the same network includes or does > not include IPv6 candidates with no identifiable pattern. Because of this= , > we currently set googIPv6 constraint to false. Our only other alternative > would be to examine the SDP and remove the IPv6 candidates and replace c= =3D > line with IPv4 address. In anticipation of IPv6 support being enabled by > default, and to avoid SDP mucking, it would be better to define a > constraint that can be used to suppress IPv6 candidate collection, which > can be provided via current constraint interfaces. > > > What is the interop issue? Are v6 candidates mistakenly attempted to be > processed by Firefox and failing? > > setRemoteDescription fails when SDP has an IN IP6 address in the c=3D line.= I think parsing SDP iwth IPv6 addresses is fully supported by Firefox. _____________ Roman Shpount --90e6ba6150068b558205132c1564 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 7, 2015 at 8:30 PM, =F0=9F=94=93Dan Wing <dwing@cisco.com> wrote:
On 07-Apr-2015 03:28 pm, Roman Shpount <roman@telurix.com> wrote:
> It is possible to run into interop issues with end-points that support= ICE and DTLS-SRTP but do not support IPv6, such as current versions of Fir= efox. Chrome currently offers googIPv6 constraint, which enables or disable= s IPv6 candidate collection. Unfortunately, this constraint is Chrome speci= fic, provided via deprecated interface (PeerConnection constructor), and wh= en this constraint is not set, Chrome collects or does not collect IPv6 can= didates pretty much in random. Without setting this constraint, the same Ch= rome browser on the same network includes or does not include IPv6 candidat= es with no identifiable pattern. Because of this, we currently set googIPv6= constraint to false. Our only other alternative would be to examine the SD= P and remove the IPv6 candidates and replace c=3D line with IPv4 address. I= n anticipation of IPv6 support being enabled by default, and to avoid SDP m= ucking, it would be better to define a constraint that can be used to suppr= ess IPv6 candidate collection, which can be provided via current constraint= interfaces.


What is the interop issue?=C2=A0 Are v6 candidates mistakenly attemp= ted to be processed by Firefox and failing?


setRemoteDescription fails when SDP has an IN IP6 address = in the c=3D line. I think parsing SDP iwth IPv6 addresses is fully supporte= d by Firefox.
_____________
Rom= an Shpount
=C2=A0
--90e6ba6150068b558205132c1564-- From nobody Tue Apr 7 19:21: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 827041B2B5E for ; Tue, 7 Apr 2015 19:21:41 -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 e6qaqkM6EnNi for ; Tue, 7 Apr 2015 19:21:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BA1E41B2B48 for ; Tue, 7 Apr 2015 19:21:39 -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.1/8.14.9) with ESMTPSA id t382LcB2004715 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2015 21:21:38 -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: <552490B1.4080106@nostrum.com> Date: Tue, 07 Apr 2015 21:21:37 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Roman Shpount , "rtcweb@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Byron Campen Subject: Re: [rtcweb] Constraint to disable IPv6 candidate collection 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 Apr 2015 02:21:41 -0000 On 4/7/15 17:28, Roman Shpount wrote: > It is possible to run into interop issues with end-points that support > ICE and DTLS-SRTP but do not support IPv6, such as current versions of > Firefox. ... [I propose we] define a constraint that can be used to > suppress IPv6 candidate collection, which can be provided via current > constraint interfaces. While full support of IPv6 in our ICE stack is going to require a significant amount of development work, I think it's a flaw if Firefox doesn't at least parse IPv6 candidates and recognize them as something it can't (currently) use. Just to make sure that we're not getting our wires crossed here: the JSEP stack was completely revamped in Firefox 37 (which is the most recent released version). If you find that IPv6 candidates are tripping Firefox 37 up, we should get a bug filed on that and fix it. So, if that's the case, please report it at https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=WebRTC%3A%20Networking -- or, if you'd prefer, send me an example of SDP and/or candidates that cause issues, and I'll file the bug myself. But I don't think we need to make spec changes to work around implementation flaws. Any mishandling by Firefox is a temporary condition, and the spec will be around for a long time. /a From nobody Wed Apr 8 02:20: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 9B9231B2E55 for ; Wed, 8 Apr 2015 02:20:28 -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 OnXX1P2xyXQo for ; Wed, 8 Apr 2015 02:20:27 -0700 (PDT) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.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 6479A1B2E54 for ; Wed, 8 Apr 2015 02:20:27 -0700 (PDT) Received: by qkhg7 with SMTP id g7so78176566qkh.2 for ; Wed, 08 Apr 2015 02:20:26 -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=r5YURdZofIkw4Zpt5l+ig3eHIVzCIkyJ1uKONjBOEEA=; b=l0KnKpLky+hWiNwYaAQslxJfUOamTW4MUWu0lbtwylWC6IPRbDzr5RIN5889HuFQrb 2PQ4ZEGaU2PGB3m27bmGZ3M/ZpaAVDLxsS9Cg8vJCqd8SAUTC6CDMs4zX4REK94TUXOw W+hcVTOAjuJZ+f0+gBm8AIXAyR9GYjn2Erb9PgxORl12UAjM/ktg5feQYsDe3NPz5bkg CPgb12avoJ55YsnUhCw/TcWRWYGBkJI0rIwcke0B4eh3qQZCBMlizFlD32tJesUc2yPX fjVuFuqY6euLxAHbYW0QBqk+/xxxRSpEtDbRmExP8XDAcNiXXhveb1CfH3SBCqPL2k9w fhHQ== X-Gm-Message-State: ALoCoQmScBbwGPmlehxTyS10Zx8KBKneCxFj2U308Hhzt8HQX06ziSaLQWXjlN30TDl+WdmKcS+1 X-Received: by 10.55.31.167 with SMTP id n39mr46442776qkh.59.1428484826564; Wed, 08 Apr 2015 02:20:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.227 with HTTP; Wed, 8 Apr 2015 02:20:06 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 8 Apr 2015 11:20:06 +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] Constraint to disable IPv6 candidate collection 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 Apr 2015 09:20:28 -0000 2015-04-08 0:28 GMT+02:00 Roman Shpount : > it would be better to define a constraint that can be used to suppress > IPv6 candidate collection I'm against any approach or option that treats IPv6 as "optional" or less important than IPv4. IMHO if Firefox fails (even) to parse IPv6 candidates, the vendor should fix it. Said that, it is very *sad* that Firefox fails to parse an SDP due to an IPv6 address in the c=3D line. Come on! this is about a grammar defined more than 15 years ago! --=20 I=C3=B1aki Baz Castillo From nobody Thu Apr 9 02:31: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 D2C4B1B2A8C for ; Thu, 9 Apr 2015 02:31:57 -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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 odELL_VZHzHV for ; Thu, 9 Apr 2015 02:31:56 -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 C4F931B2A05 for ; Thu, 9 Apr 2015 02:31:55 -0700 (PDT) Received: by ignm3 with SMTP id m3so45528566ign.0 for ; Thu, 09 Apr 2015 02:31:54 -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=RluBkMOpi0tPBSiLF611+YZsg+ptqPW0rYOfsc0GJpc=; b=TtzMGoXlOeIX7p+04Rr3lGI9i4OSnAl/KyNiNwiQOUJbVKI9/OtTr7G3WnNkX4lO/q T5PO1PaxGBDgG07qJvAFv2qT9AWC8CzxJV4/hZ4P7q8lr0L0r2Y+RND5+yH7deoDUaw9 gDOAkrG1lHo85iho5m2UNkflvAZH6tBJ+gq1KppsD+yCnh5fzcStZm/X4mmOos5oa0bc G6znb8lOzY8YpxQxMR8Dajnch8ME0it2d6tL+gwIwN0c4hLQMzAOwooXymsSyaYBnCHw 0vEC44dOvzUZHS77iGSUqMXtHtaOxcyAvXo3kY1hkLEGIj9gdjxC7PYL4LTj1ABQDbON truQ== X-Gm-Message-State: ALoCoQknpM1i2y9/iiE0h/05fYahcdr9Hyq+YKkOgMd6xZFKteZiJ3hxMau5mOzk4kT17WQ97qid X-Received: by 10.50.78.130 with SMTP id b2mr18283152igx.42.1428571914210; Thu, 09 Apr 2015 02:31:54 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com. [209.85.213.178]) by mx.google.com with ESMTPSA id k2sm8422816iok.11.2015.04.09.02.31.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 02:31:53 -0700 (PDT) Received: by iget9 with SMTP id t9so45539792ige.1 for ; Thu, 09 Apr 2015 02:31:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.204.14 with SMTP id fk14mr37751150icb.96.1428571911902; Thu, 09 Apr 2015 02:31:51 -0700 (PDT) Received: by 10.36.110.149 with HTTP; Thu, 9 Apr 2015 02:31:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Apr 2015 05:31:51 -0400 Message-ID: From: Roman Shpount To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , Adam Roach Content-Type: multipart/alternative; boundary=20cf30363b93585abb051347515d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Constraint to disable IPv6 candidate collection 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 Apr 2015 09:31:58 -0000 --20cf30363b93585abb051347515d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 8, 2015 at 5:20 AM, I=C3=B1aki Baz Castillo wro= te: > 2015-04-08 0:28 GMT+02:00 Roman Shpount : > > it would be better to define a constraint that can be used to suppress > > IPv6 candidate collection > > I'm against any approach or option that treats IPv6 as "optional" or > less important than IPv4. IMHO if Firefox fails (even) to parse IPv6 > candidates, the vendor should fix it. > > Said that, it is very *sad* that Firefox fails to parse an SDP due to > an IPv6 address in the c=3D line. Come on! this is about a grammar > defined more than 15 years ago! > We will retest Firefox 37 for IPv6, but this was really not the reason for the constraint, but an illustration of the problem. This issue was brought up as one of the examples of SDP mucking that is currently required to deal with interop issues. Until IPv6 is implemented by default in both Chrome and Firefox, we will be in the state of transition. During this transition all surrounding services would need to be updated to IPv6 and tested with the browser implementations. Until this happens, IPv6 as a feature would need to be disabled in the JavaScript client code. One way to do this is via constraints, and Chrome already provides such a constraint. I assume when Firefox will introduce IPv6 support, some sort of similar constraint is going to be provided there as well. If such constraint will not be provided, we will need to do SDP mucking, which everyone assumes is bad. So, in the real world outside of standard committees and labs, each new feature which is introduced needs to be controlled in such a way that it can be deployed into production in gradual and managed manner. Since IPv6 is not a feature which was implemented from the start by the browsers, we now need to manage the transition. This will take at least another year, or at least this is how long it will take for Firefox 36 and older installations to clear out. I understand that this is a short time frame in comparison with the lifetime of the specification, but some solution for managing the transition to IPv6 would be appreciated. I understand that in this particular case a client side SDP filter for old Firefox versions which removes IPv6 candidates and IPv6 address from the c=3D line can be clunky but acceptable answer to this problem. Regards, _____________ Roman Shpount --20cf30363b93585abb051347515d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 8, 2015 at 5:20 AM, I=C3=B1aki Baz Castillo <<= a href=3D"mailto:ibc@aliax.net" target=3D"_blank">ibc@aliax.net> wrote:
2015-04-08 0:28 GMT+02:00 R= oman Shpount <roman@telurix.com= >:
> it would be better to define a constraint that can be used to suppress=
> IPv6 candidate collection

I'm against any approach or option that treats IPv6 as "opt= ional" or
less important than IPv4. IMHO if Firefox fails (even) to parse IPv6
candidates, the vendor should fix it.

Said that, it is very *sad* that Firefox fails to parse an SDP due to
an IPv6 address in the c=3D line. Come on! this is about a grammar
defined more than 15 years ago!

We will= retest Firefox 37 for IPv6, but this was really not the reason for the con= straint, but an illustration of the problem. This issue was brought up as o= ne of the examples of SDP mucking that is currently required to deal with i= nterop issues. Until IPv6 is implemented by default in both Chrome and =C2= =A0Firefox, we will be in the state of transition. During this transition a= ll surrounding services would need to be updated to IPv6 and tested with th= e browser implementations. Until this happens, IPv6 as a feature would need= to be disabled in the JavaScript client code. One way to do this is via co= nstraints, and Chrome already provides such a constraint. I assume when Fir= efox will introduce IPv6 support, some sort of similar constraint is going = to be provided there as well. If such constraint will not be provided, we w= ill need to do SDP mucking, which everyone assumes is bad.

So, in the real world outside of standard committees and labs, eac= h new feature which is introduced needs to be controlled in such a way that= it can be deployed into production in gradual and managed manner. Since IP= v6 is not a feature which was implemented from the start by the browsers, w= e now need to manage the transition. This will take at least another year, = or at least this is how long it will take for Firefox 36 and older installa= tions to clear out. I understand that this is a short time frame in compari= son with the lifetime of the specification, but some solution for managing = the transition to IPv6 would be appreciated. I understand that in this part= icular case a client side SDP filter for old Firefox versions which removes= IPv6 candidates and IPv6 address from the c=3D line can be clunky but acce= ptable answer to this problem.

Regards,
=
_____________
Roman Shpount
=C2=A0
--20cf30363b93585abb051347515d-- From nobody Fri Apr 10 02: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 23A361AD0AE for ; Fri, 10 Apr 2015 02:29:44 -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 tG9uQY53LOMx for ; Fri, 10 Apr 2015 02:29:41 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADBE1AD0B2 for ; Fri, 10 Apr 2015 02:29:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5C97C7C57A6 for ; Fri, 10 Apr 2015 11:29:40 +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 2p48oSzaLAJ8 for ; Fri, 10 Apr 2015 11:29:38 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:e8f8:541b:c4d0:58f4] (unknown [IPv6:2001:470:de0a:27:e8f8:541b:c4d0:58f4]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0EE9D7C57A2 for ; Fri, 10 Apr 2015 11:29:38 +0200 (CEST) Message-ID: <55279801.6040504@alvestrand.no> Date: Fri, 10 Apr 2015 11:29:37 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Constraint to disable IPv6 candidate collection 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, 10 Apr 2015 09:29:44 -0000 Den 09. april 2015 11:31, skrev Roman Shpount: > On Wed, Apr 8, 2015 at 5:20 AM, Iñaki Baz Castillo > wrote: > > 2015-04-08 0:28 GMT+02:00 Roman Shpount >: > > it would be better to define a constraint that can be used to suppress > > IPv6 candidate collection > > I'm against any approach or option that treats IPv6 as "optional" or > less important than IPv4. IMHO if Firefox fails (even) to parse IPv6 > candidates, the vendor should fix it. > > Said that, it is very *sad* that Firefox fails to parse an SDP due to > an IPv6 address in the c= line. Come on! this is about a grammar > defined more than 15 years ago! > > > We will retest Firefox 37 for IPv6, but this was really not the reason > for the constraint, but an illustration of the problem. This issue was > brought up as one of the examples of SDP mucking that is currently > required to deal with interop issues. Until IPv6 is implemented by > default in both Chrome and Firefox, we will be in the state of > transition. During this transition all surrounding services would need > to be updated to IPv6 and tested with the browser implementations. Until > this happens, IPv6 as a feature would need to be disabled in the > JavaScript client code. Just to make sure we're all on the same page here: This is NOT what we're talking about. We're talking about the c= line, which is meaningless semantic noise added to SDP for backwards compatibility, and which all conformant WebRTC implementations will ignore in favor of the ICE candidate lines. The only purpuse the c= line has in the WebRTC context is to serve as fodder for intercepting proxies that read the SDP and take action based on the c= line because they don't understand ICE candidates. The claim that has been made is that putting IPv6 addresses into the c= line causes parsing of the SDP to fail in certain contexts. If the only example of this issue is an old version of Firefox that will go away at the speed at which Firefox replaces old versions - I say "good riddance", and let's ignore the issue - it does not need solving. If the issue exists for other ecosystem components (such as the aforementioned proxies), this is a sad statement about the state of the art in SDP parsing - but I could see an argument for changing the generated default for this (semantically meaningless) value to be something that makes fewer spec-violating parsers behave strangely. This is NOT about introducing IPv6 - we've got address families in ICE candidates for that, and nobody's reported a problem with those. This is SOLELY about how far we bend over in order to not provoke broken SDP parsers. From nobody Fri Apr 10 05:01: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 4D1111B2CD8 for ; Fri, 10 Apr 2015 05:01:27 -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 LJk7e3_nYcy3 for ; Fri, 10 Apr 2015 05:01:26 -0700 (PDT) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.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 1D3271B2CD1 for ; Fri, 10 Apr 2015 05:01:25 -0700 (PDT) Received: by qkhg7 with SMTP id g7so27043371qkh.2 for ; Fri, 10 Apr 2015 05:01: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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=R4vw79R3gzBZug8XTbay6AnyTImE00rALwNee8qYlbI=; b=XB1UNW2LZ+rT7J2tmrpsxbVY64G+2+W9xj6gZrU0MGawLNWy0TRJGzcp9+5GxQQKBo v2ecRb0/LJtvFBmhiok/A4mRNtU1VucI7hoZptuaCPQ+7bQQW1Vk+iuIcrFDaFJ41b4v Ikaw4T2SS1Co7osoRVvQgnEZRuIsgw9G8L8J2v2IvO9NsVTyKSyUTCiGLBP0JO5ICMEG anMvPT/EaLR2FDW0bLf516WddlUl/y6a0mkV5tRf8NTd0Ov2IerSyGhHkXIZYaZ0SXoM gdU6wz0xuZaUgNf61JuLJ13IYKp0VjJMputDLfO8EHzslr4KoHMFZYL/GMzVB0xJ94qD VXsA== X-Gm-Message-State: ALoCoQnlhYFw5H4z1JwwP5l55azGN9xmyBsY2elXVL70Odij5HUnb2eZpYNFAFIq/Hg038oNjNWs X-Received: by 10.140.93.72 with SMTP id c66mr1196361qge.0.1428667229245; Fri, 10 Apr 2015 05:00:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.227 with HTTP; Fri, 10 Apr 2015 04:54:03 -0700 (PDT) In-Reply-To: References: <55279801.6040504@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 10 Apr 2015 13:54:03 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Constraint to disable IPv6 candidate collection 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, 10 Apr 2015 12:01:27 -0000 2015-04-10 13:52 GMT+02:00 I=C3=B1aki Baz Castillo : > Please don't add stuff to the WebRTC just to make some browsers' or > WebRTC devices' old SDP stacks work. If a SDP stack in 2015 is not > capable of parsing an IPv6 in the meaningless c=3D line that's vendor's > fault and something the vendor must fix ASAP. BTW: mangle the c=3D line (set there your favorite meaningless IPv4) before providing setRemoteDescription() with the SDP and done. --=20 I=C3=B1aki Baz Castillo From nobody Fri Apr 10 05:31: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 8BDCF1B30AC for ; Fri, 10 Apr 2015 05:31:30 -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 g8Q3L2wSdHNj for ; Fri, 10 Apr 2015 05:31:29 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.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 80E391B3099 for ; Fri, 10 Apr 2015 05:31:29 -0700 (PDT) Received: by qcrf4 with SMTP id f4so393713qcr.0 for ; Fri, 10 Apr 2015 05:31:28 -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=D2Rp09d9GqYXeElQENRoUy1cPIrIQ8PbSC6zyMYRmY8=; b=WGcH/3oXnL3XmcIZ6WM+XpuSMcBmGItpCiP/93dKmV1RlTWXYAfu7wYzZlyjZr0LE8 Nuxg7iHfuOCCG3U+e7+0uZPHlAa1COnioV9I1bQrhFDWyASCRLB7YY/30uYOTI5g1QZ5 BmBEqxHqMBJdzHuIrFk3FYjaHcLpFAp8JAa2Z7x4Ezk5khcMW2GjQnC3ljAfBNEmL3Dn sRTHi40bdo2qIwgbkSQxECFgjdrfgIITvfdHX+z2+Ramd9vkZ+85fzzZ0ZzJRgdoRFXg FcZSqJoCldi/T0Bq9/tvPYyGVD4/5HHsHVKTxvAYtBFzLiYErpO/W/U/fe+e/baE4Ipz 9sjQ== X-Gm-Message-State: ALoCoQnzRZOf2gX5TxaYhHM2rB+PcdodTYloZ/eU9DWZqQh9LPUSYlEiPTimF3J6Vj2pJSXXGLS5 X-Received: by 10.140.132.199 with SMTP id 190mr1255692qhe.24.1428667228214; Fri, 10 Apr 2015 05:00:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.227 with HTTP; Fri, 10 Apr 2015 04:52:26 -0700 (PDT) In-Reply-To: <55279801.6040504@alvestrand.no> References: <55279801.6040504@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 10 Apr 2015 13:52:26 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Constraint to disable IPv6 candidate collection 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, 10 Apr 2015 12:31:30 -0000 2015-04-10 11:29 GMT+02:00 Harald Alvestrand : > We're talking about the c=3D line, which is meaningless semantic noise > added to SDP for backwards compatibility, and which all conformant > WebRTC implementations will ignore in favor of the ICE candidate lines. > > The only purpuse the c=3D line has in the WebRTC context is to serve as > fodder for intercepting proxies that read the SDP and take action based > on the c=3D line because they don't understand ICE candidates. > > The claim that has been made is that putting IPv6 addresses into the c=3D > line causes parsing of the SDP to fail in certain contexts. +1 Please don't add stuff to the WebRTC just to make some browsers' or WebRTC devices' old SDP stacks work. If a SDP stack in 2015 is not capable of parsing an IPv6 in the meaningless c=3D line that's vendor's fault and something the vendor must fix ASAP. --=20 I=C3=B1aki Baz Castillo From nobody Mon Apr 13 00:38: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 E9DF11A1A4C for ; Mon, 13 Apr 2015 00:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ONpP2wWKbEw5 for ; Mon, 13 Apr 2015 00:38:34 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 5106B1A0026 for ; Mon, 13 Apr 2015 00:38:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E204E7C55A2; Mon, 13 Apr 2015 09:38:32 +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 s5XqyhDVKgM3; Mon, 13 Apr 2015 09:38:31 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:911d:a3a:8796:79c1]) by mork.alvestrand.no (Postfix) with ESMTPSA id B1DFE7C39A5; Mon, 13 Apr 2015 09:38:31 +0200 (CEST) Message-ID: <552B7277.4060401@alvestrand.no> Date: Mon, 13 Apr 2015 09:38:31 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Cullen Jennings , Ted Hardie , Sean Turner , "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [rtcweb] W3C Media Capture and Streams - Last Call review request 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 Apr 2015 07:38:40 -0000 To the chairs of the IETF RTCWEB working group (cc the group): The W3C WebRTC and Device APIs Working Groups request feedback on the Last Call Working Draft of Media Capture and Streams, a JavaScript API that enables access to cameras and microphones from Web browsers: http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/ This forms part of an interface that is intended to connect a Javascript API with the functionality standardized in the IETF rtcweb working group. Some aspects of this API relate to requirements from the RTCWEB requirements draft, and we’d especially like feedback on those aspects; we would welcome feedback from the IETF RTCWEB WG on this document. We naturally also welcome feedback from any other reviewers. The end of last call review for this specification is set to May 15; should that deadline prove difficult to target, please get in touch so that we can determine a new deadline. As indicated in the document, comments should be sent to the public-media-capture@w3.org mailing list. Thanks, Harald Alvestrand and Stefan Hakansson, WebRTC Working Group Chairs and Media Capture Task Force Chairs From nobody Mon Apr 13 19:02: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 AA6281B2C55 for ; Mon, 13 Apr 2015 19:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 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, 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 0Kn35eSGPHjR for ; Mon, 13 Apr 2015 19:02:05 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::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 618B31B2C54 for ; Mon, 13 Apr 2015 19:02:05 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so4121959ieb.3 for ; Mon, 13 Apr 2015 19:02:04 -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=jCGOGqQtoZKSl/ZTAgHJEAHC2up11xq0uFQ+pmRrfTQ=; b=Xy3J3S2l8KlU0sHJMNdsY3HlMdm+enuTv8dyEbhzH68bPkuAqtQhYUPE4YWEoNopMi NrmK3gsI1NJRc1FdiuueGT3LcZQZOoRataMreMUJlvZ84AEdrDcwQKtzQzmJ4NAaNl45 XYTFr87Q5SJ9/WqW3IBvfWPm/E9cJvQ4sGaXSbgoz/Di5acW4b1jVdiGZvK7LArj8xbg Zde2RGLs5keeOLXLmJqcMpc0ADl3dWVM/fi15MvO1fTggbUpKKuh+Ee0C6t1Ld7AID0J EXCue80cVhvO1nLrnFqCmS0nbFR2ksFItIz8tZVldBkzIOiFbGslJWFVEADXepPB7DRU b/gA== 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=jCGOGqQtoZKSl/ZTAgHJEAHC2up11xq0uFQ+pmRrfTQ=; b=cTcwLfmSVl3q+NA0i35XcITCwyDnF65fYy39e4lg+NDCjf3mwFypTDog4483Y4ocT3 UA5+Gi7sRHl3OzoLuAq80kW/3Puym1akqevIRZlu+eccuy0BpOLBzbGRGILXcw9dpuKP Os+OXk/N91mxxzA+d/gxNR9dYOvJANzvAYKyq3R+hoQnN3g3w6kM7/RyiARYY9hmqe2U xppbEOoRvB1+QeD5iDVKb4goydPHPGQsek/o2feTtqXFbepdhMzgdNxq+atCdSBImxIU wD7XRMhsxyGtL5ktTaFazAowPvYsgE+qt6NDwG7QG8vWgVc8uLpcl7pZFsH3XHUgY/Uw TXhg== X-Gm-Message-State: ALoCoQmjLuWataxwOQeZIAuVOX2Afco84usvkECoCq7VciXb1Xus+uqGJnCA2HU7yAbHnXAmYVrj X-Received: by 10.107.170.135 with SMTP id g7mr25868338ioj.2.1428976924810; Mon, 13 Apr 2015 19:02:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.63.3 with HTTP; Mon, 13 Apr 2015 19:01:44 -0700 (PDT) In-Reply-To: References: <55279801.6040504@alvestrand.no> From: Justin Uberti Date: Mon, 13 Apr 2015 19:01:44 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , Guo-wei Shieh Content-Type: multipart/alternative; boundary=001a11427064ff26310513a59d29 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Constraint to disable IPv6 candidate collection 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 Apr 2015 02:02:06 -0000 --001a11427064ff26310513a59d29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FWIW, this was fixed in Chrome 42 to not put IPv6 addresses into the c=3D line, when IPv4 addresses exist - because of these exact types of problems encountered in the wild. We think this is entirely consistent with RFC5245, which indicates the c=3D line should contain the candidate most likely to work. On Fri, Apr 10, 2015 at 4:54 AM, I=C3=B1aki Baz Castillo wr= ote: > 2015-04-10 13:52 GMT+02:00 I=C3=B1aki Baz Castillo : > > Please don't add stuff to the WebRTC just to make some browsers' or > > WebRTC devices' old SDP stacks work. If a SDP stack in 2015 is not > > capable of parsing an IPv6 in the meaningless c=3D line that's vendor's > > fault and something the vendor must fix ASAP. > > BTW: mangle the c=3D line (set there your favorite meaningless IPv4) > before providing setRemoteDescription() with the SDP and done. > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11427064ff26310513a59d29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW, this was fixed in Chrome 42 to not put IPv6 addresse= s into the c=3D line, when IPv4 addresses exist - because of these exact ty= pes of problems encountered in the wild.

We think this i= s entirely consistent with RFC5245, which indicates the c=3D line should co= ntain the candidate most likely to work.

On Fri, Apr 10, 2015 at 4:54 AM, I=C3=B1= aki Baz Castillo <ibc@aliax.net> wrote:
2015-04-10 13:52 GMT+02:00 I=C3=B1aki Baz Castil= lo <ibc@aliax.net>:
> Please don't add stuff to the WebRTC just to make some browsers= 9; or
> WebRTC devices' old SDP stacks work. If a SDP stack in 2015 is not=
> capable of parsing an IPv6 in the meaningless c=3D line that's ven= dor's
> fault and something the vendor must fix ASAP.

BTW: mangle the c=3D line (set there your favorite meaningless IPv4)=
before providing setRemoteDescription() with the SDP and done.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

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

--001a11427064ff26310513a59d29-- From nobody Mon Apr 13 19:22: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 6CEF31B2F20 for ; Mon, 13 Apr 2015 19:22:10 -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 nYoI7MBaLnGv for ; Mon, 13 Apr 2015 19:22:09 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::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 CFF451B2C91 for ; Mon, 13 Apr 2015 19:22:08 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so4399539ieb.3 for ; Mon, 13 Apr 2015 19:22:08 -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=qN4tS4eJVwmpaYoSKwNFWNPXhZ8RQwF/VodhlJwGUVw=; b=cTKOwWliOys4xycsQK9dyVa5MGXN6pX02AXly44NqWenDqT7R/W0IGPpVUa/NlKi5w IChAUdBHrWJ3QbrlwRsaBxrOPvfKwYmopfm2YlA9bT2F46nWHibPdvKGe12+HD+uYzzP HeVLyiymzF1ASO8++6697hDZaCKyjqwGZgxfAVZ7k6qIoGxdijnZgWPO928DJktUqSiU cB+7YA4ToELEvEKSQFvnTLaiVx6ZTxaPpiUreal3T9LW22UI4/EPD5MUvvYRW9NYr0Dz dP5KfCe+SuFLUepSQ7UcXvrzveyC710nASpjCSne6bOvKhD5Dt/WNc4jrnFNU5nmq5eX zEqQ== 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=qN4tS4eJVwmpaYoSKwNFWNPXhZ8RQwF/VodhlJwGUVw=; b=BQUdydvOkEpapcWFMWYAYaV94OcAAQTeA9TJqwgxF+AprsErmT8KOSR0Gb6MWKStMT mQMXwRWWzW4rxPE3BSzLfxheLH6XV65XwEJqQ5qFodEwZXZF1L33AlgMySUYgKWavPv6 jWDagrQMU0hYd2pSUCzLGLVbHjf6IdMt4saMrxJ9T6BS9/QJ1lSdFKipuukq/P3r6mdA j4MzyJdRLWVXJcR0cSPLbX2UPEm4D5V/w8Ewgi5SRyGnYg8iXqiEJ2nF6wCyyujqY66w eibSHwXTn4b/A1x91QAYF+TxdSyuUhISn7w+dbOBilPPBZymOMtAYTXTqCwJ2tuC4X5Q w2aQ== X-Gm-Message-State: ALoCoQkEqesU2WEcTDLC3oKTrmSaRR18uj0JNw127Fv+XMenOTgV+0aNdb6HlIhKbjB9VJRrYGsq X-Received: by 10.43.24.76 with SMTP id rd12mr22661091icb.84.1428978128293; Mon, 13 Apr 2015 19:22:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.63.3 with HTTP; Mon, 13 Apr 2015 19:21:47 -0700 (PDT) In-Reply-To: <6042868B-57EB-4C5A-B93E-C58D846E14E4@cisco.com> References: <9DA8307B-263C-4951-A55C-36B42D27C08B@cisco.com> <6042868B-57EB-4C5A-B93E-C58D846E14E4@cisco.com> From: Justin Uberti Date: Mon, 13 Apr 2015 19:21:47 -0700 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=bcaec51dd02dbac11c0513a5e5f3 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-schwartz-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: Tue, 14 Apr 2015 02:22:10 -0000 --bcaec51dd02dbac11c0513a5e5f3 Content-Type: text/plain; charset=UTF-8 I think this is a sensible change and we should adopt the revised document. On Tue, Apr 7, 2015 at 5:58 PM, Cullen Jennings (fluffy) wrote: > > > On Mar 26, 2015, at 9:20 AM, Cullen Jennings wrote: > > > > I'd like to point out that the combination of > ietf-tram-turn-server-discovery and draft-schwartz-rtcweb-return allow any > network you are connected to more or less MITM your media and do things > like rate limit it, generate analytics on who you are talking to, force > your traffic through an intermediary that is in a different legal > jurisdiction and so on. > > We discussed this after the meeting and came up with a way to resolve > this concern. Benjamin has added some text to the -06 to that specifically > addresses this issue > > > http://www.ietf.org/rfcdiff?url1=draft-schwartz-rtcweb-return-05&url2=draft-schwartz-rtcweb-return-06 > > This completely deals with the issue I raised and with that change I > support adopting this as a WG document. > > After adoption, I think the WG should consider if any text is needed > around the issue of TURN credentials. (If you run TURN with no credentials > and an attacker can spoof the IP address in UDP packets, you can end up > with the TURN servers in a nasty forwarding loop that allows an huge > amplification factor for an attacker trying do DOS the turn servers - this > is still possible with authentication but you know who to blame. When TURN > was first done with was one of the reason TURN requires auth and STUN does > not). However, I believe this issue can solved and should not block > adopting the draft. ) > > Cullen > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec51dd02dbac11c0513a5e5f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this is a sensible change and we should adopt the = revised document.

= On Tue, Apr 7, 2015 at 5:58 PM, Cullen Jennings (fluffy) = <fluffy@cisco.com<= /a>> wrote:

> On Mar 26, 2015, at 9:20 AM, Cullen Jennings <fluffy@cisco.com> wrote:
>
> I'd like to point out that the combination of ietf-tram-turn-serve= r-discovery and draft-schwartz-rtcweb-return allow any network you are conn= ected to more or less MITM your media and do things like rate limit it, gen= erate analytics on who you are talking to, force your traffic through an in= termediary that is in a=C2=A0 different legal jurisdiction and so on.

We discussed this after the meeting and came up with a=C2=A0 way to = resolve this concern. Benjamin has added some text to the -06 to that speci= fically addresses this issue

http://www= .ietf.org/rfcdiff?url1=3Ddraft-schwartz-rtcweb-return-05&url2=3Ddraft-s= chwartz-rtcweb-return-06

This completely deals with the issue I raised and with that change I suppor= t adopting this as a WG document.

After adoption, I think the WG should consider if any text is needed around= the issue of TURN credentials. (If you run TURN with no credentials and an= attacker can spoof the IP address in UDP packets, you can end up with the = TURN servers in a nasty forwarding loop that allows an huge amplification f= actor for an attacker trying do DOS the turn servers - this is still possib= le with authentication but you know who to blame. When TURN was first done = with was one of the reason TURN requires auth and STUN does not). However, = I believe this issue can solved and should not block adopting the draft. )<= br>
Cullen




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

--bcaec51dd02dbac11c0513a5e5f3-- From nobody Mon Apr 13 19:26: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 EFE2D1B2FE9 for ; Mon, 13 Apr 2015 19:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 zdqY9hIt8H_t for ; Mon, 13 Apr 2015 19:26:36 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 B14331B2C61 for ; Mon, 13 Apr 2015 19:26:36 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so4417004igb.1 for ; Mon, 13 Apr 2015 19:26: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=3dhYhQ7a3u1jsfPmVc3sPnH//3iyIQ9U5wNJD5i/Pxg=; b=SuD33XWd3mKT9dYN29A2UmNcUu/CS9VKRUjzo86LNeeRzbAMEqWATtJHkdLnzXPSmk Un8JBoexFLfa8RkEIwExhvMiHo1JEuwDhYeMEG5Yvj2NPrXGYYq1pCGx3kNb/l3NbzLL /lncuE9GpcZe4VPDsm/0wfe4ySh5M4hNXpUKtvco3vWbmgGLe6jxSrsQRR8s06l3umki MAlAlLC4xDyI/ncsOoEDIeQsq4EkmDgSpf4E17o+VmM/ADw+hh9+EvurZECFrHHrocFv Kg2CRQny0rinZ/wa/SBnFp9Z22k7BTc+kKxI1SfXbvn5J08gpAHHk3rwPL2axXa/DOsU zc4w== 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=3dhYhQ7a3u1jsfPmVc3sPnH//3iyIQ9U5wNJD5i/Pxg=; b=S7YTtNJ7yOKPDh31/h45VaCCSRRuSp73eE0apskL3DojU+/O4dyJL2l/Z+a8maHdD6 w9X5jX/mg4rhSa9nJItpLs1tNMQwBQ0agREXCWAE9NA/hfGMpEVVWyxTCa5tjTfxjtl/ zV85f1bfrzywfIM1wNJ5RzLh5ewHVI7z38jzRVAChOS9Ts3+fBOUoR+V2br5yhuWFtT5 IXlEtjFodt5sUlJbsOYsY5ZPutVVv+RfGW/a1P5mo9Y6GhyA8ZUTtZvBvn/hpwx1mLgn Ab2QEcdopU3iXdlP+BuaZaB/Xm2beX1h5w8NJ2HDbhrTT2+d5L/LZAcLWSWudjZS+tGP /GIQ== X-Gm-Message-State: ALoCoQmobxyvVbKk4VNZsC1WVAWiq5gUjRXR0aLhChIAgxSFVEZufQxm5wsScLLXLP30yaxvTzyx X-Received: by 10.50.117.4 with SMTP id ka4mr20752181igb.10.1428978396137; Mon, 13 Apr 2015 19:26:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.63.3 with HTTP; Mon, 13 Apr 2015 19:26:15 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Mon, 13 Apr 2015 19:26:15 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=089e011617aeb1b9e60513a5f509 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ice-lite as a media level attribute in jsep 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 Apr 2015 02:26:38 -0000 --089e011617aeb1b9e60513a5f509 Content-Type: text/plain; charset=UTF-8 This is a bug. https://github.com/rtcweb-wg/jsep/issues/126 On Tue, Apr 7, 2015 at 3:28 AM, Roman Shpount wrote: > Why is ice-lite a media level attribute in JSEP section 5.6.2 ( > http://rtcweb-wg.github.io/jsep/#rfc.section.5.6.2)? > > Per RFC 5245 (http://tools.ietf.org/html/rfc5245#section-15.3) "ice-lite" > is a session level attribute only. > > Have this been redefined somewhere? > _____________ > Roman Shpount > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e011617aeb1b9e60513a5f509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 7, 2015= at 3:28 AM, Roman Shpount <roman@telurix.com> wrote:
Why is ice-lite a media level = attribute in JSEP section 5.6.2 (http://rtcweb-wg.github.io/jsep/#rfc= .section.5.6.2)?=C2=A0

Per RFC 5245 (http://tools= .ietf.org/html/rfc5245#section-15.3) "ice-lite" is a session = level attribute only.

Have this been redefined= somewhere?
_____________
Roman Shpount
<= /div>

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


--089e011617aeb1b9e60513a5f509-- From nobody Mon Apr 13 20:58: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 9510F1B32E1 for ; Mon, 13 Apr 2015 20:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 eXIJm2F0r46G for ; Mon, 13 Apr 2015 20:58:37 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001: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 164E11B32E0 for ; Mon, 13 Apr 2015 20:58:37 -0700 (PDT) Received: by igblo3 with SMTP id lo3so5525877igb.0 for ; Mon, 13 Apr 2015 20:58: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=6ZU72mFJv17VPhtTa5NVnsGuwC48Bwf3pe8J5D1g7D0=; b=fDEbl4JlZONBo/YasYhHkDgZTc35CyTJMZHWPPc45XmcRUrGcSxx1xw4Sj/HqBRT4J ycThmGqu61cqZVbWFpo0/Ipt+phLQoOqZb3Zg0C/mC7Fj1pPYMwcv+latPFaMTRqn96v repl8w0Lmc7UKiWclrucFRE0It/swN5E8Ra4ON/GsDIcLZqfiMhdMt+0kvE3PZrgbQJ6 vsossFasIpEDMT+dGJemIOC3iOm3xLzWoRkM4m2Jujw39Y3aBSJiq09s0svPwiahVD1C a3Epeo07AATVCPL8rL4LGDg83Rn2G1gTKlRi09BwAXUADKggJjtPYtSJ/r4KjSoRbyuj 8T/A== 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=6ZU72mFJv17VPhtTa5NVnsGuwC48Bwf3pe8J5D1g7D0=; b=KoVu/nhAeKwALBcPyROS3/wT65nyIZKOQ/ikMmS2bgWw5DBOjKFYjKP50Okv/rNwRj eKc9qlMJb3LSvxvxz2rMxBDbijLffZmoulsU+jzNdUykAQCfnrO8i638O73MsnPXgB6D 32Mz+0WzNnS5cqkuUSo50dDRwmD3W46Saq5VVJshyBh4twAS2pzP5K7C+h9EPyJvRkWR XSUeAkS4SCYTSwJVfOE77PrAgX9UZPhdRc1jQZeSPX/5aceL8z6iP053ur2207fgSGVF fyBLppp6d//DqbhkX0wUNTeNBwu7aQDtzuRcPdMSiCuIE+RuOPsAqSsrn+DLnBKNK8gu OUUA== X-Gm-Message-State: ALoCoQmjvGKTWDovs0hYwbJrg58BPvkrM+ou1+4j5IbyoaVAhPQBFJvK+RryZPGMqhp7dCj+xs6T X-Received: by 10.50.43.136 with SMTP id w8mr21166953igl.26.1428983916464; Mon, 13 Apr 2015 20:58:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.63.3 with HTTP; Mon, 13 Apr 2015 20:58:16 -0700 (PDT) In-Reply-To: <5523A5D4.9070907@alvestrand.no> References: <5519753D.1080907@nostrum.com> <30772BF4-B814-4CB2-932F-96885D0BD76E@iii.ca> <5519A5A4.4070205@nostrum.com> <5523A5D4.9070907@alvestrand.no> From: Justin Uberti Date: Mon, 13 Apr 2015 20:58:16 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e011602a8bb36760513a73e2c Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP lines (JSEP Issue 27) 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 Apr 2015 03:58:38 -0000 --089e011602a8bb36760513a73e2c Content-Type: text/plain; charset=UTF-8 I realize the word 'ignore' may not be optimal, as an implementation may want to store these lines for debugging or some other non-core operation. I think the key aspect here is that these lines have must no further impact on JSEP processing. On Tue, Apr 7, 2015 at 2:39 AM, Harald Alvestrand wrote: > Den 06. april 2015 21:40, skrev Cullen Jennings (fluffy): > > I think we are just seeing different meanings in the word ignore. I see > it as "ignore" would mean the browser did not process or store whatever it > found in something that it MUST ignore. It's doing syntax checking on this > and then storing it and then passing it back later (presumable unchanged). > > > > The things we are talking about here (with the exception of k=) seems > like if some browser wanted to use them in the way SDP meant that is fine > too, it just SDP does not require anything to happen with them. > > > > Can we find a different way of phrasing this than "MUST ignore" - I'm > agreeing with you on what browser need to implement, I just don't think > "MUST ignore" is the right way to say it. > > > > For browsers, it would be a source of inconsistent behaviour if one > browser did something magical with "z=" (timezone adjustment) or "p=" > (phone numbers) and another browser did not. Javascript apps that cared > would have to adapt according to which browser they ran on, which is not > a Good Thing. > > For non-browsers, which may or may not bundle an application inside > whatever-it-is, they need to be free to do whatever they need to do. > > I think "browsers MUST ignore" is the right thing to do, even if the > language may be expressed better in a different way. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e011602a8bb36760513a73e2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I realize the word 'ignore' may not be optimal, as= an implementation may want to store these lines for debugging or some othe= r non-core operation. I think the key aspect here is that these lines have = must no further impact on JSEP processing.
=
On Tue, Apr 7, 2015 at 2:39 AM, Harald Alves= trand <harald@alvestrand.no> wrote:
Den 06. april 2015 21:40, skrev Cullen Jenni= ngs (fluffy):
> I think we are just seeing different meanings in the word ignore. I se= e it as "ignore" would mean the browser did not process or store = whatever it found in something that it MUST ignore. It's doing syntax c= hecking on this and then storing it and then passing it back later (presuma= ble unchanged).
>
> The things we are talking about here (with the exception of k=3D) seem= s like if some browser wanted to use them in the way SDP meant that is fine= too, it just SDP does not require anything to happen with them.
>
> Can we find a different way of phrasing this than "MUST ignore&qu= ot; - I'm agreeing with you on what browser need to implement, I just d= on't think "MUST ignore" is the right way to say it.
>

For browsers, it would be a source of inconsistent behaviour if one<= br> browser did something magical with "z=3D" (timezone adjustment) o= r "p=3D"
(phone numbers) and another browser did not. Javascript apps that cared
would have to adapt according to which browser they ran on, which is not a Good Thing.

For non-browsers, which may or may not bundle an application inside
whatever-it-is, they need to be free to do whatever they need to do.

I think "browsers MUST ignore" is the right thing to do, even if = the
language may be expressed better in a different way.



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

--089e011602a8bb36760513a73e2c-- From nobody Wed Apr 15 08:50: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 B70391B35E7 for ; Wed, 15 Apr 2015 08:50:17 -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 2EQoYlIY6VZe for ; Wed, 15 Apr 2015 08:50:16 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81281B35DE for ; Wed, 15 Apr 2015 08:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=296; q=dns/txt; s=iport; t=1429113017; x=1430322617; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Rz/kMBg4L9pOUxQyDBcF0Db2+AqI7Tl6wbT6H9ajkmU=; b=K5VHaZV49MJUmFrQ8+P7xPZexABA5onmhucIFgLkP5/DHDYhn1eIXFDi Ihvhj+vAU8CxfHa2nKAYbayPNq6hBoKVlJjsUWSA6aXJIH7IzBle2iY80 49V131k56qjWKqS8JStp3PZz0DQgbVTubK3JOweFmMl092BOgX62qrGi4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CIBAC7hy5V/5BdJa1cgwxSXQTFXQmBUYc+OBQBAQEBAQEBfYQnOlEBPkInBC2IEA2fQaVZAQoBAQEegk2QeIEWBZEOihGUbyKDb4IzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,582,1422921600"; d="scan'208";a="141510729" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP; 15 Apr 2015 15:50:16 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t3FFoFUm015516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 15 Apr 2015 15:50:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.188]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 15 Apr 2015 10:50:15 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: The W3C is doing a last call of the WebRTC GetUserMedia API spec Thread-Index: AQHQd5PdpqwOaiArxEGaWo1u4L8L2w== Date: Wed, 15 Apr 2015 15:50:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F6D3DCDACD8774D942BD1AF2DFDCFC6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [rtcweb] The W3C is doing a last call of the WebRTC GetUserMedia API spec 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 Apr 2015 15:50:17 -0000 Announcement at=20 http://www.w3.org/blog/news/archives/4600?pk_campaign=3Dfeed&pk_kwd=3Dlast-= call-media-capture-and-streams Spec at=20 http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/ They are happy to get comments from everyone - you don't need to be a W3C m= ember From nobody Thu Apr 16 07:05: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 AA3091B3249; Thu, 16 Apr 2015 07:05:20 -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 YzEsuVXwo8tq; Thu, 16 Apr 2015 07:05:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAC81B324D; Thu, 16 Apr 2015 07:03:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Sean Turner" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416140313.4737.85265.idtracker@ietfa.amsl.com> Date: Thu, 16 Apr 2015 07:03:13 -0700 Archived-At: Cc: draft-ietf-rtcweb-video.ad@ietf.org, rtcweb-chairs@tools.ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-video@ietf.org, iesg-secretary@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-video.shepherd@ietf.org Subject: [rtcweb] Publication has been requested for draft-ietf-rtcweb-video-05 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: Thu, 16 Apr 2015 14:05:20 -0000 spt has requested publication of draft-ietf-rtcweb-video-05 as Proposed Standard on behalf of the RTCWEB working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ From nobody Thu Apr 16 10:41: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 4B5FB1B3383 for ; Thu, 16 Apr 2015 10:41:04 -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 vtUAW_hQ6VWm for ; Thu, 16 Apr 2015 10:41:02 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB901B3377 for ; Thu, 16 Apr 2015 10:41:02 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 35B801EB843F; Thu, 16 Apr 2015 19:41:01 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.22]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0224.002; Thu, 16 Apr 2015 19:41:00 +0200 From: "Hutton, Andrew" To: Justin Uberti , "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] draft-schwartz-rtcweb-return Thread-Index: AQHQdlnUVAWuNux41UeqAkJvjqNVyZ1P69NA Date: Thu, 16 Apr 2015 17:41:00 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E734E46@MCHP04MSX.global-ad.net> References: <9DA8307B-263C-4951-A55C-36B42D27C08B@cisco.com> <6042868B-57EB-4C5A-B93E-C58D846E14E4@cisco.com> 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: Subject: Re: [rtcweb] draft-schwartz-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, 16 Apr 2015 17:41:04 -0000 KzEgSSBhbHNvIHRoaW5rIHRoaXMgbG9va3MgbGlrZSBhIHNlbnNpYmxlIHJldmlzaW9uIGFuZCB3 b3VsZCBsaWtlIHRvIHNlZSB0aGlzIGFkb3B0ZWQgc29vbmVyIHJhdGhlciB0aGFuIGxhdGVyLg0K DQpBbmR5DQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJ0Y3dl YiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluDQo+ IFViZXJ0aQ0KPiBTZW50OiAxNCBBcHJpbCAyMDE1IDAzOjIyDQo+IFRvOiBDdWxsZW4gSmVubmlu Z3MgKGZsdWZmeSkNCj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVybg0KPiANCj4gSSB0aGluayB0aGlzIGlzIGEg c2Vuc2libGUgY2hhbmdlIGFuZCB3ZSBzaG91bGQgYWRvcHQgdGhlIHJldmlzZWQNCj4gZG9jdW1l bnQuDQo+IA0KPiBPbiBUdWUsIEFwciA3LCAyMDE1IGF0IDU6NTggUE0sIEN1bGxlbiBKZW5uaW5n cyAoZmx1ZmZ5KQ0KPiA8Zmx1ZmZ5QGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiA+IE9uIE1hciAy NiwgMjAxNSwgYXQgOToyMCBBTSwgQ3VsbGVuIEplbm5pbmdzIDxmbHVmZnlAY2lzY28uY29tPg0K PiB3cm90ZToNCj4gPg0KPiA+IEknZCBsaWtlIHRvIHBvaW50IG91dCB0aGF0IHRoZSBjb21iaW5h dGlvbiBvZiBpZXRmLXRyYW0tdHVybi1zZXJ2ZXItDQo+IGRpc2NvdmVyeSBhbmQgZHJhZnQtc2No d2FydHotcnRjd2ViLXJldHVybiBhbGxvdyBhbnkgbmV0d29yayB5b3UgYXJlDQo+IGNvbm5lY3Rl ZCB0byBtb3JlIG9yIGxlc3MgTUlUTSB5b3VyIG1lZGlhIGFuZCBkbyB0aGluZ3MgbGlrZSByYXRl IGxpbWl0DQo+IGl0LCBnZW5lcmF0ZSBhbmFseXRpY3Mgb24gd2hvIHlvdSBhcmUgdGFsa2luZyB0 bywgZm9yY2UgeW91ciB0cmFmZmljDQo+IHRocm91Z2ggYW4gaW50ZXJtZWRpYXJ5IHRoYXQgaXMg aW4gYcKgIGRpZmZlcmVudCBsZWdhbCBqdXJpc2RpY3Rpb24gYW5kDQo+IHNvIG9uLg0KPiANCj4g V2UgZGlzY3Vzc2VkIHRoaXMgYWZ0ZXIgdGhlIG1lZXRpbmcgYW5kIGNhbWUgdXAgd2l0aCBhwqAg d2F5IHRvIHJlc29sdmUNCj4gdGhpcyBjb25jZXJuLiBCZW5qYW1pbiBoYXMgYWRkZWQgc29tZSB0 ZXh0IHRvIHRoZSAtMDYgdG8gdGhhdA0KPiBzcGVjaWZpY2FsbHkgYWRkcmVzc2VzIHRoaXMgaXNz dWUNCj4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LXNjaHdhcnR6 LXJ0Y3dlYi1yZXR1cm4tDQo+IDA1JnVybDI9ZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVybi0w Ng0KPiANCj4gVGhpcyBjb21wbGV0ZWx5IGRlYWxzIHdpdGggdGhlIGlzc3VlIEkgcmFpc2VkIGFu ZCB3aXRoIHRoYXQgY2hhbmdlIEkNCj4gc3VwcG9ydCBhZG9wdGluZyB0aGlzIGFzIGEgV0cgZG9j dW1lbnQuDQo+IA0KPiBBZnRlciBhZG9wdGlvbiwgSSB0aGluayB0aGUgV0cgc2hvdWxkIGNvbnNp ZGVyIGlmIGFueSB0ZXh0IGlzIG5lZWRlZA0KPiBhcm91bmQgdGhlIGlzc3VlIG9mIFRVUk4gY3Jl ZGVudGlhbHMuIChJZiB5b3UgcnVuIFRVUk4gd2l0aCBubw0KPiBjcmVkZW50aWFscyBhbmQgYW4g YXR0YWNrZXIgY2FuIHNwb29mIHRoZSBJUCBhZGRyZXNzIGluIFVEUCBwYWNrZXRzLA0KPiB5b3Ug Y2FuIGVuZCB1cCB3aXRoIHRoZSBUVVJOIHNlcnZlcnMgaW4gYSBuYXN0eSBmb3J3YXJkaW5nIGxv b3AgdGhhdA0KPiBhbGxvd3MgYW4gaHVnZSBhbXBsaWZpY2F0aW9uIGZhY3RvciBmb3IgYW4gYXR0 YWNrZXIgdHJ5aW5nIGRvIERPUyB0aGUNCj4gdHVybiBzZXJ2ZXJzIC0gdGhpcyBpcyBzdGlsbCBw b3NzaWJsZSB3aXRoIGF1dGhlbnRpY2F0aW9uIGJ1dCB5b3Uga25vdw0KPiB3aG8gdG8gYmxhbWUu IFdoZW4gVFVSTiB3YXMgZmlyc3QgZG9uZSB3aXRoIHdhcyBvbmUgb2YgdGhlIHJlYXNvbiBUVVJO DQo+IHJlcXVpcmVzIGF1dGggYW5kIFNUVU4gZG9lcyBub3QpLiBIb3dldmVyLCBJIGJlbGlldmUg dGhpcyBpc3N1ZSBjYW4NCj4gc29sdmVkIGFuZCBzaG91bGQgbm90IGJsb2NrIGFkb3B0aW5nIHRo ZSBkcmFmdC4gKQ0KPiANCj4gQ3VsbGVuDQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0 DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3J0Y3dlYg0KDQo= From nobody Thu Apr 16 11:15: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 C052C1B2F08 for ; Thu, 16 Apr 2015 11:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 ntyBudv7gJgI for ; Thu, 16 Apr 2015 11:15:33 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [67.18.62.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D7D1B2F0C for ; Thu, 16 Apr 2015 11:15:32 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 6259720D785CE; Thu, 16 Apr 2015 13:15:31 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 5229C20D78530 for ; Thu, 16 Apr 2015 13:15:31 -0500 (CDT) Received: from [96.231.227.6] (port=61838 helo=[192.168.1.10]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YioK1-0006HQ-Ha; Thu, 16 Apr 2015 13:15:29 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2015 14:15:28 -0400 Message-Id: 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.227.6 X-Exim-ID: 1YioK1-0006HQ-Ha X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.10]) [96.231.227.6]:61838 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org Subject: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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 Apr 2015 18:15:34 -0000 All, There=92s been some interest expressed in having = http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ = adopted as an RTCWeb WG item. Please respond to say whether you support = adoption of this work as a working group work item and whether you will = participate in the discussion. If you are opposed to this draft = becoming a WG document, please say so (and say why). Please have your = response in by 20150423 23:59 UTC. Thanks in advance! spt= From nobody Thu Apr 16 11:16: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 5F83B1B2F0F for ; Thu, 16 Apr 2015 11:16:07 -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 nsJYUMIJrEOC for ; Thu, 16 Apr 2015 11:16:06 -0700 (PDT) Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.1]) (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 118941B2F0A for ; Thu, 16 Apr 2015 11:16:06 -0700 (PDT) Received: by gateway32.websitewelcome.com (Postfix, from userid 500) id 9AD357B63251; Thu, 16 Apr 2015 13:16:05 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 8B75D7B6322E for ; Thu, 16 Apr 2015 13:16:05 -0500 (CDT) Received: from [96.231.227.6] (port=61838 helo=[192.168.1.10]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YioKZ-0006HQ-3j; Thu, 16 Apr 2015 13:16:03 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2015 14:16:02 -0400 Message-Id: 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.227.6 X-Exim-ID: 1YioKZ-0006HQ-3j X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.10]) [96.231.227.6]:61838 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: draft-schwartz-rtcweb-return@tools.ietf.org Subject: [rtcweb] WG call for adoption: draft-schwartz-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, 16 Apr 2015 18:16:07 -0000 All, There=92s been some interest expressed in having = http://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/ adopted as = an RTCWeb WG item. Please respond to say whether you support adoption = of this work as a working group work item and whether you will = participate in the discussion. If you are opposed to this draft = becoming a WG document, please say so (and say why). Please have your = response in by 20150423 23:59 UTC. Thanks in advance! spt PS - For the casual lurker, there was some vigorous discussion in Dallas = on the -05 version but based on the [1] thread and the -06 version it = looks like we=92re in much better shape. [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg14402.html= From nobody Thu Apr 16 11:27: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 0BEA21B2EB4 for ; Thu, 16 Apr 2015 11:27:05 -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 92VwNV5xp8sm for ; Thu, 16 Apr 2015 11:27:04 -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 CF20F1B2EB1 for ; Thu, 16 Apr 2015 11:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=353; q=dns/txt; s=iport; t=1429208825; x=1430418425; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=B2dyswu2zvRNl5jLt6CibqRv5L+qmgLKOMOAk5DVDdI=; b=XJwTRg9GduKQExQpr8Kws1SyhXBJIHgeS9gQQQd9aUnnhc6x+9vExP06 FISuTa9qbY6IAgLd7GusMXtvL5aYkw3Jz2WNg+QASKGZxf7o0Mr8OreSi TQzD0HNzXrm6nAMp0TQFmIZ5LY11pHpSQjrPEBN6lFrZ+i1ZdMbu33yaN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ALBQDi/S9V/49dJa1cgwyBM8YEiSQ6EgEBAQEBAQF9hCcdHVEBPkInBIg9ozSlNgEBAQEGAQEBAQEBHI9EEQGDb4EWBZEWihmBHYM5kCUig2+Bejl/AQEB X-IronPort-AV: E=Sophos;i="5.11,589,1422921600"; d="scan'208";a="141909772" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP; 16 Apr 2015 18:27:04 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t3GIR37X014983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 16 Apr 2015 18:27:03 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.188]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 16 Apr 2015 13:27:03 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: WGLC for draft-ietf-rtcweb-audio-07 Thread-Index: AQHQeHLufRXDMiayqUy2T9sh6lvwsg== Date: Thu, 16 Apr 2015 18:27:38 +0000 Message-ID: <6D8CC46E-1A9F-4C2E-B133-D2040B0D78DE@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <83C44FC91EC8DF47BDB0F58143DE5C36@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [rtcweb] WGLC for draft-ietf-rtcweb-audio-07 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 Apr 2015 18:27:05 -0000 Dear WG, This starts a working group last call for: draft-ietf-rtcweb-audio-07 Please review them in detail. The chairs will send a separate email with s= ome comments from us and others that can be considered part of the WGLC com= ments.=20 This WGLC will end on May 1, 2015. Thanks,=20 Ted, Sean, Cullen (with our Chairs hat on) From nobody Thu Apr 16 11:27: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 79AE51B2EB1 for ; Thu, 16 Apr 2015 11:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.211 X-Spam-Level: X-Spam-Status: No, score=-112.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, 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 gclNXbl2qIcv for ; Thu, 16 Apr 2015 11:27:52 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FA81B33CC for ; Thu, 16 Apr 2015 11:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3142; q=dns/txt; s=iport; t=1429208871; x=1430418471; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=9v0+IdoYbcNRnp60YncherDssRErhaMDBBDJa+1uisY=; b=Err/SsOJSHJpmXbhLaUJpOZ9/VX4b0WRgbcCT1dYdcFHT2tWRqEdvEA4 0hwqs8Da1iTPxZVCuCRSbFPFrW29EF14/ZqyAzzZ+86VSHzxyUSNRJqDm nBVQ/YFRzBC/xuj/MWcrvsVSLlcoavbXEuf4/IpjNFBVoprs28RWU9A00 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APBQCR/i9V/5JdJa1cgwyBM4MQymSBNEwBAQEBAQF+hCcjETgKFQEiAiYCBDAVEgSIPaMsj1WVYQEBAQEGAQEBAQEBHIEhkXUvgRYFkRaKGYEdgzmQJSKDb4IzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,589,1422921600"; d="scan'208";a="412448429" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP; 16 Apr 2015 18:27:51 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t3GIRopY030966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 16 Apr 2015 18:27:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.188]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 16 Apr 2015 13:27:50 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: Few comments on draft-ietf-rtcweb-audio-07 Thread-Index: AQHQeHML77sxMDhOrU23Dq41MURdCw== Date: Thu, 16 Apr 2015 18:28:26 +0000 Message-ID: <7703998F-5364-487A-84F1-1AAEE6E4C3C8@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="utf-8" Content-ID: <35EBFEF715EBDB4EA171A4FA8376B87D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [rtcweb] Few comments on draft-ietf-rtcweb-audio-07 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 Apr 2015 18:27:54 -0000 DQpTb21lIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvIGZyb20gYSBtaXh0dXJl IG9mIE1hZ251cywgU2VhbiwgQ3VsbGVuLCBhbmQgVGVkLiBQbGVhc2UgY29uc2lkZXIgdGhlc2Ug YXMgV0dMQyBjb21tZW50cy4gDQoNCg0KDQoxYSkgSXQgd291bGQgYmUgYmVzdCB0byB1c2UgdGhl IHNhbWUgdGVybWlub2xvZ3kgZnJvbSBydGN3ZWItb3ZlcnZpZXcNCg0KUmlnaHQgbm93IHRoZSBh YnN0cmFjdCBzYXlzOg0KDQpUaGlzIGRvY3VtZW50IG91dGxpbmVzIHRoZSBhdWRpbyBjb2RlYyBh bmQgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMNCmZvciBXZWJSVEMgY2xpZW50IGFwcGxpY2F0aW9u IGFuZCBlbmRwb2ludCBkZXZpY2VzLg0KDQpUaGlzIHNob3VsZCBwcm9iYWJseSBjaGFuZ2UgdG8g KGFuZCB0aGVuIGl04oCZbGwgbWF0Y2ggaW4gdGhlIGludHJvIHNlY3Rpb24pOg0KDQpUaGlzIGRv Y3VtZW50IG91dGxpbmVzIHRoZSBhdWRpbyBjb2RlYyBhbmQgcHJvY2Vzc2luZyByZXF1aXJlbWVu dHMNCmZvciBXZWJSVEMgZW5kcG9pbnRzLg0KDQoxYikgSW4gU2VjdGlvbiAzOg0KDQpXZWJSVEMg Y2xpZW50cyBhcmUgUkVRVUlSRUQgdG8gaW1wbGVtZW50IHRoZSBmb2xsb3dpbmcgYXVkaW8gY29k ZWNzOg0KDQpJIHRoaW5rIHRoaXMgc2hvdWxkIHVzZSB0aGUgT3ZlcnZpZXcgZGVmaW5pdGlvbnMu IFRodXMsIEkgdGhpbmsgdGhpcw0KYXBwbGllcyB0byBhbiAiV2ViUlRDIGVuZHBvaW50Ig0KDQoN CjIpIE5lZWQgdG8gdHdlYWsgU2VjIDIgdG8gaW5jbHVkZSBOT1QgUkVDT01NRU5ERUQ6DQoNCk9M RDoNCg0KVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFM TCIsICJTSEFMTCBOT1QiLA0KIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwg Ik1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCmRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnBy ZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkgW1JGQzIxMTldLg0KDQpORVc6DQoNClRoZSBr ZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwN Ck5PVCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgDQpSRUNP TU1FTkRFRCIsICAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8g DQpiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkgW1JGQzIxMTldLg0KDQoz KSBUbyBhdm9pZCBhIHNlYyBjb25zaWRlcmF0aW9ucyBjb21tZW50LCBJ4oCZZCBwcm9iYWJseSBi b2xzdGVyIHRoZW0gYnkgYWRkaW5nIHNvbWV0aGluZyBsaWtlOg0KDQpGb3Igc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgcmVnYXJkaW5nIHRoZSBjb2RlcyB0aGVtc2VsdmVzIHBsZWFzZSByZWZlciB0 aGVpciBzcGVjaWZpY2F0aW9ucy4gIExpa2V3aXNlLCBjb25zdWx0IHRoZSBSVFAgYmFzZSBzcGVj aWZpY2F0aW9uIGZvciBzZWN1cml0eSBSVFAtYmFzZWQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMu DQoNCjQpIFRoZSBsYXN0IHNlbnRlbmNlIGluIHRoZSBzZWMgY29ucyBpcyBsaWtlbHkgdG8gYXR0 cmFjdCBmbGllcy4gIENhbiB3ZSBwb2ludCB0byB0aGUgdHdvIHNlY3VyaXR5IGRyYWZ0cyBpbnN0 ZWFkPw0KDQo1KSBJ4oCZZCBwcm9iYWJseSB0aGUgcmVmZXIgdG8gdGhlIG9wdXMgcnRwIHBheWxv YWQgZHJhZnQgZnJvbSAtMDMgdG8gLTA4IChpdOKAmXMgaW4gSUVTRyBldmFsIC0geWlwcGllKSBh bmQgdGhlIHJlZmVyZW5jZSB0byB0aGUgYXVkaW8gY29kZWNzIGZvciBpbnRlcm9wIGZyb20gLTAw IHRvIC0wMS4NCg0KNikgVGhlIGRyYWZ0IGhhcyAiQmVjYXVzZSBvZiB0aGlzLCBjbGllbnRzIE1B WSBpbmNyZWFzZSB0aGUgZ2FpbiBiZWZvcmUgcGxheWJhY2suIiBUbyBtYWtlIGNvbnNpc3RlbnQg c291bmQgbGV2ZWxzIGFjcm9zcyBicm93c2VycywgSSB3b25kZXIgaWYgdGhpcyBzaG91bGQgY29u dGludWUgdG8gc2F5IHNvbWV0aGluZyBsaWtlIC0gIm1hbnkgYnJvd3NlcnMgaW5jcmVhc2UgaXQg YnkgWCBkYiIgYW5kIGluc2VydCB3aGF0ZXZlciB2YWx1ZSBvZiBYIHRoYXQgY2hyb21lIGFuZCBG RiB0aGluayB0aGV5IHNob3VsZCBiZSB1c2luZy4gSSBkb24ndCBmZWVsIHN0cm9uZ2x5IGFib3V0 IGFkZGluZyB0aGlzIG9uZSB3YXkgb3IgdGhlIG90aGVyIGJ1dCBjYW4gdGhlIGF1dGhvcnMgZ2l2 ZSBpdCBhIGxpdHRsZSB0aG91Z2h0IGFuZCBzZWUgaWYgdGhleSB0aGluayBpdCBpcyBuZWVkZWQg b3Igbm90Lg0KDQoNCg== From nobody Thu Apr 16 11:32: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 34BC91B342C for ; Thu, 16 Apr 2015 11:32: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 6KnZQ8S0_FJe for ; Thu, 16 Apr 2015 11:32:31 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 2152D1B342B for ; Thu, 16 Apr 2015 11:32:31 -0700 (PDT) Received: by oift201 with SMTP id t201so55047440oif.3 for ; Thu, 16 Apr 2015 11:32: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:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5SMAFcFIMOJgksfFyyjzpl5KVFkW5cf1jKtzlIGQv+w=; b=JIWM/WhHyoaeB5/zY+4R/9AD3Gih4ZGA5UUke7v2q4RfrUf/RgNmgw8Rv4YMOkYCk7 Oh5DqKC17d8b7BhPD727O+nN9sPk+HxnUYzL/t4G/eFg1QUdSyXr/bfbgRlqSz/eYR49 mtPP82Ec/ki/1eBvtdy40TI1sjx3qFdE+S2vdN3fRQYnV+5YegGZBVxXf5gkKbNm8NcE 9pxm2xDEfsbug8UXJ0aunPt1Bl8Q48JfR34no9ks27RgSt0cAD1VBoXTcD9xeqH67rGf Wy6xT59iGc/CUw0ZAQ4DNqqhGlnmwlUrSiYykUTMxF8zGRdwUcu70NufKbMmlK91OpFS ds6w== MIME-Version: 1.0 X-Received: by 10.182.39.195 with SMTP id r3mr26949298obk.44.1429209150496; Thu, 16 Apr 2015 11:32:30 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Thu, 16 Apr 2015 11:32:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Apr 2015 11:32:30 -0700 Message-ID: From: Martin Thomson To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" , draft-schwartz-rtcweb-return@tools.ietf.org Subject: Re: [rtcweb] WG call for adoption: draft-schwartz-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, 16 Apr 2015 18:32:32 -0000 On 16 April 2015 at 11:16, Sean Turner wrote: > PS - For the casual lurker, there was some vigorous discussion in Dallas = on the -05 version but based on the [1] thread and the -06 version it looks= like we=E2=80=99re in much better shape. As I mentioned in the thread, I think that the new text is too restrictive, but can live with being in the rough on this. From nobody Thu Apr 16 11:39: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 4853B1B3452 for ; Thu, 16 Apr 2015 11:39:22 -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 9fBmFeeANgMP for ; Thu, 16 Apr 2015 11:39:20 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::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 91F681B344F for ; Thu, 16 Apr 2015 11:39:20 -0700 (PDT) Received: by vnbf1 with SMTP id f1so24521268vnb.5 for ; Thu, 16 Apr 2015 11:39:19 -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=gleFsA/GLRbM6JJ5cmMgjn8pryWLwPjO1wVadBSQK3A=; b=fiwmf8xMyyU1szP78NuBfXmCa9n3O8ogjodDUoDCFLuL+f8Z1f+y+teI39n/Fbik17 UuAI7U0Q82HO3XeAoxFXas+YYugop+B2bdFPvSSDRyYtOMUDdTfGTSjJZ3C2FLeLmdZO DPMrR/0kODoNR9AW5XzELoo2e02bEbEETEI1stxduoTMTRIj1UMz7gFuloxwnw5wU+Rz gTE3l/qdEg0Z27jHTffOh/lPhnVxYTnqVha0DB+2CKYo6ZQcCjRJVSwDrhTrD6z23LBl g+GsneT3W9GmnJWhHBe8K+Y7SXg71Zh1K81e150D1JpgYSPYsfkisB22IO/g7uEM8Ty+ 4sfg== MIME-Version: 1.0 X-Received: by 10.52.115.132 with SMTP id jo4mr39782267vdb.43.1429209559841; Thu, 16 Apr 2015 11:39:19 -0700 (PDT) Received: by 10.52.133.7 with HTTP; Thu, 16 Apr 2015 11:39:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Apr 2015 13:39:19 -0500 Message-ID: From: Alan Johnston To: Martin Thomson Content-Type: multipart/alternative; boundary=bcaec548a7911fc1880513dbc817 Archived-At: Cc: "rtcweb@ietf.org" , draft-schwartz-rtcweb-return@tools.ietf.org Subject: Re: [rtcweb] WG call for adoption: draft-schwartz-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, 16 Apr 2015 18:39:22 -0000 --bcaec548a7911fc1880513dbc817 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support adoption of the draft. I'm also fine with the new text for now. We need a good discussion about the security of TURN server auto discovery, but that should happen in TRAM where the auto discovery draft lives. This RTCWEB draft can then be updated to align with that consensus. - Alan - On Thu, Apr 16, 2015 at 1:32 PM, Martin Thomson wrote: > On 16 April 2015 at 11:16, Sean Turner wrote: > > PS - For the casual lurker, there was some vigorous discussion in Dalla= s > on the -05 version but based on the [1] thread and the -06 version it loo= ks > like we=E2=80=99re in much better shape. > > As I mentioned in the thread, I think that the new text is too > restrictive, but can live with being in the rough on this. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec548a7911fc1880513dbc817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support adoption of the draft.

I'= m also fine with the new text for now.=C2=A0 We need a good discussion abou= t the security of TURN server auto discovery, but that should happen in TRA= M where the auto discovery draft lives.=C2=A0 This RTCWEB draft can then be= updated to align with that consensus.

- Alan -

On Thu, = Apr 16, 2015 at 1:32 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 16 April 2015 at = 11:16, Sean Turner <turners@ieca.com= > wrote:
> PS - For the casual lurker, there was some vigorous discussion in Dall= as on the -05 version but based on the [1] thread and the -06 version it lo= oks like we=E2=80=99re in much better shape.

As I mentioned in the thread, I think that the new text is too
restrictive, but can live with being in the rough on this.

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

--bcaec548a7911fc1880513dbc817-- From nobody Thu Apr 16 19:25: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 839191A905C for ; Thu, 16 Apr 2015 19:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_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 LUizq8tsbL1h for ; Thu, 16 Apr 2015 19:25:31 -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 B94781A9041 for ; Thu, 16 Apr 2015 19:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8450; q=dns/txt; s=iport; t=1429237532; x=1430447132; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z1a6+t7iIC7rVk+zVs2eARX32+Rtmb2rdIt7TxPdSoM=; b=l2Tf5KVY5aueS/seRqrlacNRiGwy2m1WKYuPObsrz0Dzuu1oQHDuphAv FzwWfeWynctv+rekrVGHZIW0HJ2O3nwOFDAuKTlyQApbVuvpovNPMDOfK 2EkgoNMUIVnxKB52oNBsGkh/FSJFdQzCGL4fIDd4b6XnALO0uK0SDbclA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BVBQAYbjBV/4oNJK1dgkVHUlwFgxDCCII0AQmFNU4CHIE1TAEBAQEBAX6EIAEBAQQBAQEaBgpBCxACAQgRBAEBAQodAwICAh8GCxQJCAIEAQ0FCIgOAxENsiyQJQ2FLgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiymCR4FqGhYXBAYBgmgvgRYFkRqITJAQhkEig29vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,591,1422921600"; d="scan'208,217";a="412890107" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP; 17 Apr 2015 02:25:31 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3H2PUA2023021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Apr 2015 02:25:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.220]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 16 Apr 2015 21:25:30 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alan Johnston , Martin Thomson Thread-Topic: [rtcweb] WG call for adoption: draft-schwartz-rtcweb-return Thread-Index: AQHQeHFuxye4rAeOEkGeqiNht+CucZ1QSlMAgAAB54CAAC6AYA== Date: Fri, 17 Apr 2015 02:25:29 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A412101FF@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.69] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A412101FFxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" , "draft-schwartz-rtcweb-return@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-schwartz-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: Fri, 17 Apr 2015 02:25:33 -0000 --_000_913383AAA69FF945B8F946018B75898A412101FFxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KLVRpcnUNCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBBbGFuIEpvaG5zdG9uDQpTZW50OiBGcmlkYXksIEFwcmlsIDE3LCAy MDE1IDEyOjA5IEFNDQpUbzogTWFydGluIFRob21zb24NCkNjOiBydGN3ZWJAaWV0Zi5vcmc7IGRy YWZ0LXNjaHdhcnR6LXJ0Y3dlYi1yZXR1cm5AdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb cnRjd2ViXSBXRyBjYWxsIGZvciBhZG9wdGlvbjogZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVy bg0KDQpJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhlIGRyYWZ0Lg0KDQpJJ20gYWxzbyBmaW5lIHdp dGggdGhlIG5ldyB0ZXh0IGZvciBub3cuICBXZSBuZWVkIGEgZ29vZCBkaXNjdXNzaW9uIGFib3V0 IHRoZSBzZWN1cml0eSBvZiBUVVJOIHNlcnZlciBhdXRvIGRpc2NvdmVyeSwgYnV0IHRoYXQgc2hv dWxkIGhhcHBlbiBpbiBUUkFNIHdoZXJlIHRoZSBhdXRvIGRpc2NvdmVyeSBkcmFmdCBsaXZlcy4g IFRoaXMgUlRDV0VCIGRyYWZ0IGNhbiB0aGVuIGJlIHVwZGF0ZWQgdG8gYWxpZ24gd2l0aCB0aGF0 IGNvbnNlbnN1cy4NCg0KLSBBbGFuIC0NCg0KT24gVGh1LCBBcHIgMTYsIDIwMTUgYXQgMTozMiBQ TSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpPbiAxNiBBcHJpbCAyMDE1IGF0IDExOjE2LCBT ZWFuIFR1cm5lciA8dHVybmVyc0BpZWNhLmNvbTxtYWlsdG86dHVybmVyc0BpZWNhLmNvbT4+IHdy b3RlOg0KPiBQUyAtIEZvciB0aGUgY2FzdWFsIGx1cmtlciwgdGhlcmUgd2FzIHNvbWUgdmlnb3Jv dXMgZGlzY3Vzc2lvbiBpbiBEYWxsYXMgb24gdGhlIC0wNSB2ZXJzaW9uIGJ1dCBiYXNlZCBvbiB0 aGUgWzFdIHRocmVhZCBhbmQgdGhlIC0wNiB2ZXJzaW9uIGl0IGxvb2tzIGxpa2Ugd2XigJlyZSBp biBtdWNoIGJldHRlciBzaGFwZS4NCg0KQXMgSSBtZW50aW9uZWQgaW4gdGhlIHRocmVhZCwgSSB0 aGluayB0aGF0IHRoZSBuZXcgdGV4dCBpcyB0b28NCnJlc3RyaWN0aXZlLCBidXQgY2FuIGxpdmUg d2l0aCBiZWluZyBpbiB0aGUgcm91Z2ggb24gdGhpcy4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBp ZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_913383AAA69FF945B8F946018B75898A412101FFxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsxPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3 ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ QWxhbiBKb2huc3Rvbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDE3LCAyMDE1IDEy OjA5IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNvbjxicj4NCjxiPkNjOjwvYj4gcnRj d2ViQGlldGYub3JnOyBkcmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuQHRvb2xzLmlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXRyBjYWxsIGZvciBhZG9wdGlvbjog ZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVybjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhlIGRyYWZ0 LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGFsc28g ZmluZSB3aXRoIHRoZSBuZXcgdGV4dCBmb3Igbm93LiZuYnNwOyBXZSBuZWVkIGEgZ29vZCBkaXNj dXNzaW9uIGFib3V0IHRoZSBzZWN1cml0eSBvZiBUVVJOIHNlcnZlciBhdXRvIGRpc2NvdmVyeSwg YnV0IHRoYXQgc2hvdWxkIGhhcHBlbiBpbiBUUkFNIHdoZXJlIHRoZSBhdXRvIGRpc2NvdmVyeSBk cmFmdCBsaXZlcy4mbmJzcDsgVGhpcyBSVENXRUIgZHJhZnQgY2FuIHRoZW4gYmUgdXBkYXRlZCB0 byBhbGlnbiB3aXRoDQogdGhhdCBjb25zZW5zdXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gQWxhbiAtPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgQXByIDE2LCAyMDE1IGF0 IDE6MzIgUE0sIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21z b25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxNiBB cHJpbCAyMDE1IGF0IDExOjE2LCBTZWFuIFR1cm5lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR1cm5l cnNAaWVjYS5jb20iPnR1cm5lcnNAaWVjYS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IFBT IC0gRm9yIHRoZSBjYXN1YWwgbHVya2VyLCB0aGVyZSB3YXMgc29tZSB2aWdvcm91cyBkaXNjdXNz aW9uIGluIERhbGxhcyBvbiB0aGUgLTA1IHZlcnNpb24gYnV0IGJhc2VkIG9uIHRoZSBbMV0gdGhy ZWFkIGFuZCB0aGUgLTA2IHZlcnNpb24gaXQgbG9va3MgbGlrZSB3ZeKAmXJlIGluIG11Y2ggYmV0 dGVyIHNoYXBlLjxicj4NCjxicj4NCkFzIEkgbWVudGlvbmVkIGluIHRoZSB0aHJlYWQsIEkgdGhp bmsgdGhhdCB0aGUgbmV3IHRleHQgaXMgdG9vPGJyPg0KcmVzdHJpY3RpdmUsIGJ1dCBjYW4gbGl2 ZSB3aXRoIGJlaW5nIGluIHRoZSByb3VnaCBvbiB0aGlzLjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A412101FFxmbrcdx10ciscoc_-- From nobody Fri Apr 17 21:44: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 7552C1A9029 for ; Fri, 17 Apr 2015 21:44:30 -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 WPrDst_MfwNm for ; Fri, 17 Apr 2015 21:44:25 -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 F13951A905B for ; Fri, 17 Apr 2015 21:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1249; q=dns/txt; s=iport; t=1429332265; x=1430541865; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=uYkdZRF/kekbdfeMNKx19WEtS53iXVizs7wcx6oXmj8=; b=BwPjH5s03Tc377bTGDRHIsZbpTFD3xjt/5w4vS4QU1KjRi+9i63pcCzN XpbZhSnne2O0NepSa9LbfR1HODRlBdi8kt+iRRKLER2sURvWD2p3yGwLq bYSsdLK9E/tQCSKPO9yAPncVVPJ1UxRa3PBOJoUWnzefRDv7s6Odosr+v 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BhBABy4DFV/5pdJa1dgwxSXAXGKQmBRQqFNU4CgTs4FAEBAQEBAQF9hCABAQEEAQEBGlEXBAIBCBEDAQIvJwsdCAIEARIJiCINxzUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiymEKgEBUgUGhCcFiweGHIN8hiSBHjqDAIxng04igh6BVW8BgQo5gQABAQE X-IronPort-AV: E=Sophos;i="5.11,598,1422921600"; d="scan'208";a="142361834" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 18 Apr 2015 04:44:24 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3I4iN55023387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 Apr 2015 04:44:24 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.175]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Fri, 17 Apr 2015 23:44:23 -0500 From: "Ram Mohan R (rmohanr)" To: Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG call for adoption: draft-schwartz-rtcweb-return Thread-Index: AQHQeZJXgrhkWpWsqUW2ssC4lqfcyA== Date: Sat, 18 Apr 2015 04:44:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.33.204] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] WG call for adoption: draft-schwartz-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: Sat, 18 Apr 2015 04:44:30 -0000 I support adoption of this draft. Ram -----Original Message----- From: Sean Turner Date: Thursday, 16 April 2015 11:46 pm To: "rtcweb@ietf.org" Cc: "draft-schwartz-rtcweb-return@tools.ietf.org" Subject: [rtcweb] WG call for adoption: draft-schwartz-rtcweb-return >All, > >There=B9s been some interest expressed in having >http://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/ adopted as >an RTCWeb WG item. Please respond to say whether you support adoption of >this work as a working group work item and whether you will participate >in the discussion. If you are opposed to this draft becoming a WG >document, please say so (and say why). Please have your response in by >20150423 23:59 UTC. > >Thanks in advance! > >spt > >PS - For the casual lurker, there was some vigorous discussion in Dallas >on the -05 version but based on the [1] thread and the -06 version it >looks like we=B9re in much better shape. > >[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg14402.html >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Apr 17 22:47: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 BFE0B1AC3DB for ; Fri, 17 Apr 2015 22:47:05 -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 osxUzOG1olP8 for ; Fri, 17 Apr 2015 22:47:03 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9180B1A923C for ; Fri, 17 Apr 2015 22:47:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 97F2B7C0472; Sat, 18 Apr 2015 07:47:01 +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 cdxCAlVXanRY; Sat, 18 Apr 2015 07:46:59 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 51F687C0245; Sat, 18 Apr 2015 07:46:59 +0200 (CEST) Message-ID: <5531EFD2.5010107@alvestrand.no> Date: Sat, 18 Apr 2015 07:46:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sean Turner , rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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 Apr 2015 05:47:05 -0000 On 04/16/2015 08:15 PM, Sean Turner wrote: > All, > > There’s been some interest expressed in having http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ adopted as an RTCWeb WG item. Please respond to say whether you support adoption of this work as a working group work item and whether you will participate in the discussion. If you are opposed to this draft becoming a WG document, please say so (and say why). Please have your response in by 20150423 23:59 UTC. > > Thanks in advance! > > spt Naturally, I support adoption. Question: Is this a repeat of the exercise on which Cullen reported consensus for adoption in December 2014, or is this a side effect of starting fomal tracking of adoption status? -- Surveillance is pervasive. Go Dark. From nobody Sun Apr 19 11: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 0D44A1B2CF0 for ; Sun, 19 Apr 2015 11:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 n73QI_s_QKaq for ; Sun, 19 Apr 2015 11:52:17 -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 5C9DD1B2CF6 for ; Sun, 19 Apr 2015 11:51:57 -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 t3JIpm6I020744 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Apr 2015 18:51:48 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 t3JIpfNh002948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Apr 2015 20:51:43 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.118]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0224.002; Sun, 19 Apr 2015 20:51:35 +0200 From: "Rauschenbach, Uwe (Nokia - DE/Munich)" To: ext Harald Alvestrand , Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways Thread-Index: AQHQeHFYVWMgQ5c0+UWIb1btRq1l3Z1SI8EAgAKN7AI= Date: Sun, 19 Apr 2015 18:51:34 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> References: , <5531EFD2.5010107@alvestrand.no> In-Reply-To: <5531EFD2.5010107@alvestrand.no> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [93.183.12.65] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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: 1690 X-purgate-ID: 151667::1429469509-00007476-9F9448E3/0/0 Archived-At: Cc: "draft-alvestrand-rtcweb-gateways@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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 Apr 2015 18:52:19 -0000 +1 for adoption.=0A= =0A= The same question that Harald raised came to my mind - there was another ad= option call end of last year with a lot of support (https://www.ietf.org/ma= il-archive/web/rtcweb/current/msg14050.html).=0A= =0A= Kind regards,=0A= Uwe=0A= =0A= ________________________________________=0A= Von: rtcweb [rtcweb-bounces@ietf.org]" im Auftrag von "ext Harald= Alvestrand [harald@alvestrand.no]=0A= Gesendet: Samstag, 18. April 2015 07:46=0A= An: Sean Turner; rtcweb@ietf.org=0A= Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org=0A= Betreff: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateway= s=0A= =0A= On 04/16/2015 08:15 PM, Sean Turner wrote:=0A= > All,=0A= >=0A= > There=92s been some interest expressed in having http://datatracker.ietf.= org/doc/draft-alvestrand-rtcweb-gateways/ adopted as an RTCWeb WG item. Pl= ease respond to say whether you support adoption of this work as a working = group work item and whether you will participate in the discussion. If yo= u are opposed to this draft becoming a WG document, please say so (and say = why). Please have your response in by 20150423 23:59 UTC.=0A= >=0A= > Thanks in advance!=0A= >=0A= > spt=0A= Naturally, I support adoption.=0A= =0A= Question: Is this a repeat of the exercise on which Cullen reported=0A= consensus for adoption in December 2014, or is this a side effect of=0A= starting fomal tracking of adoption status?=0A= =0A= --=0A= Surveillance is pervasive. Go Dark.=0A= =0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb=0A= From nobody Sun Apr 19 22:50: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 557721ACDC8 for ; Sun, 19 Apr 2015 22:49: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 oIsKSM2M_J5H for ; Sun, 19 Apr 2015 22:49:57 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001: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 8BDCF1ACDC7 for ; Sun, 19 Apr 2015 22:49:57 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so108898330ieb.3 for ; Sun, 19 Apr 2015 22:49:57 -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:cc:content-type; bh=wyJIoU1vRuWrpOQcEobrFngu+X2kyOrDtFlW+DkzxLE=; b=O2gesD9CrVUF0HPVVnIcSxX5Qd4kyXTyYpF4lEuyIXEZI4ZtrlredzhTU/qTt4oJcw aW20wSAGv4DgLQLLuqbw6P2ToLPqm4LCUtMP5E+r55SMDBuWkSGLiyOx7QaQgS3thUWR ktmuRXv7wn640PtC3IOXS0R3cziGWkzARXgyM/Qrs5h5hRwe5AmUVar354I5C1GC/+92 uPcVdWmqaaKb6Ed/+R3+BrpCn8n50MMFz75eY9x+CeXtPe9YckGTnZanNtMvTH3P6tQv DOzAcgKV7jGgkbArlISfRpD1kzsm/jnHovSlVSZDm9rdfpNcjVAc1dThJfHF8sJLz9LK 1V0Q== 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:cc :content-type; bh=wyJIoU1vRuWrpOQcEobrFngu+X2kyOrDtFlW+DkzxLE=; b=f867j6wKkqYzia4kXfiRc9gnN8NzAoW9Eoh+qeYUPuEpvqY4zpQ52DThA2hhLlg8Te LkfOmHGu1yebBmo68GlchBmQGyI5sJxiKcfhuQUwi/Up6TQLiL/HWSomP8IDJOw3OqH4 XhGL2nTDT8S4XigrYodT4WgfrXwqI361Fm2NIlIShIIZX2Po7JiTTM6pSnGVfzEgssEQ nzmcpgFKnnvWbgcekxMl/QAR40BdSqHOSSxP3h3dO4BCIOAVPQ6iunrILyZmqsVtA40D hf8shSCzZF+fqkoiChm53wjfVNbDRbKWiM4/YlGbLzGJkpbYYDI13vRehCPQH8cbR6wz 1dOA== X-Gm-Message-State: ALoCoQmoobHyZ5uDbanEvtaAyUInD5C9Z52ZcXYH9JttGxr12YpfouKilf0B6sYCYHcAA8DMUyPG X-Received: by 10.43.71.201 with SMTP id yl9mr599002icb.66.1429508996920; Sun, 19 Apr 2015 22:49:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.63.3 with HTTP; Sun, 19 Apr 2015 22:49:36 -0700 (PDT) From: Justin Uberti Date: Sun, 19 Apr 2015 22:49:36 -0700 Message-ID: To: Guo-wei Shieh , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1dcbcf7473a0514217fd7 Archived-At: Subject: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 05:49:59 -0000 --001a11c1dcbcf7473a0514217fd7 Content-Type: text/plain; charset=UTF-8 *Background* At IETF 92 we proposed a browser mechanism that users could enable to avoid disclosing their VPN IP to websites as a side effect of ICE candidate generation. When this mechanism was enabled, the browser would bind only to 0.0.0.0 and ::, and only generate candidates via STUN and TURN; because these sockets would follow the OS default routing, the only candidate addresses discovered would be the ones that the website already had access to (i.e. from the HTTP request). The primary downsides with this mechanism were: a) users had to manually enable it (through some potentially non-obvious preference) b) when enabled, it caused trombone routing in intranet cases c) when enabled, it broke pretty much every simple demo page (which typically don't use STUN servers) *Proposal* We now propose a new mechanism that attempts to address these issues. The new mechanism works like the previous mechanism, but during the candidate generation process, we call getsockname to obtain the local IP address of the interface used to talk to the STUN/TURN server. This obtains a *single* interface IP, which allows the browser to avoid trombone routing, but also minimizes the amount of IP information revealed to JS. Furthermore, the STUN traffic continues to go out the default route, meaning that if a VPN is used, the 'real' public address is still not disclosed. (Naturally, this has some performance implications, as a user may not always want their media to go out the VPN.) For pages that don't use STUN/TURN servers (typically demo pages), there are a few options to consider: a) always surface localhost as a candidate when no STUN/TURN servers are provided (works with existing demos, but may have false positives with certain apps) b) always include some default STUN server when no STUN/TURN servers are provided (similar to above, plus complexity of choosing default) c) add some RTCConfiguration parameter indicating that the localhost address is desired (requires updating many demo pages) None of these choices is ideal, but this seems like a solvable problem. *Implications for Browsers* As this mechanism should alleviate the primary security concerns with interface enumeration, with relatively small impact on user experience, we propose that this be the default for browsers. For users that don't want to disclose any local IP information, browsers could expose a preference that prevents surfacing even the single local IP (i.e. the originally proposed behavior). For users that want to ensure maximum performance (e.g. to address the VPN issue above), a similar preference (or permissions grant) could be exposed that allows enumeration of all IPs. *FAQ* Q: WebRTC already requires permission to access getUserMedia. Why not use that permission to control interface enumeration? A: Receive-only applications (e.g. streaming media) or datachannel applications don't require a call to gUM, so there are cases where that approach would not work. Q: Is this only for browsers, or also for native apps? A: This proposal is currently targeted at browsers. Native applications, especially on mobile, need to be able to access individual interfaces in order to be able to do seamless wifi-cellular call handover. We welcome feedback on this proposal. Guo-wei Shieh and Justin Uberti --001a11c1dcbcf7473a0514217fd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Backgroun= d
At IETF 92 we proposed a browser mechanism that users could enable = to avoid disclosing their VPN IP to websites as a side effect of ICE candid= ate generation. When this mechanism was enabled, the browser would bind onl= y to 0.0.0.0 and ::, and only generate candidates via STUN and TURN; becaus= e these sockets would follow the OS default routing, the only candidate add= resses discovered would be the ones that the website already had access to = (i.e. from the HTTP request).

The primary downsides with = this mechanism were:
a) users had to manually enable it (through some= potentially non-obvious preference)
b) when enabled, it caused tromb= one routing in intranet cases
c) when enabled, it broke pretty much e= very simple demo page (which typically don't use STUN servers)
Proposa= l
We now propose a new mechanism that attempts to address these i= ssues. The new mechanism works like the previous mechanism, but during the = candidate generation process, we call getsockname to obtain the local IP ad= dress of the interface used to talk to the STUN/TURN server. This obtains a= *single* interface IP, which allows the browser to avoid trombone routing,= but also minimizes the amount of IP information revealed to JS. Furthermor= e, the STUN traffic continues to go out the default route, meaning that if = a VPN is used, the 'real' public address is still not disclosed. (N= aturally, this has some performance implications, as a user may not always = want their media to go out the VPN.)

For pages that don= 9;t use STUN/TURN servers (typically demo pages), there are a few options t= o consider:
a) always surface localhost as a candidate when no STUN/T= URN servers are provided (works with existing demos, but may have false pos= itives with certain apps)
b) always include some default STUN server = when no STUN/TURN servers are provided (similar to above, plus complexity o= f choosing default)
c) add some RTCConfiguration parameter indicating= that the localhost address is desired (requires updating many demo pages)<= /div>

None of these choice= s is ideal, but this seems like a solvable problem.

Implications for Browsers
As this m= echanism should alleviate the primary security concerns with interface enum= eration, with relatively small impact on user experience, we propose that t= his be the default for browsers. For users that don't want to disclose = any local IP information, browsers could expose a preference that prevents = surfacing even the single local IP (i.e. the originally proposed behavior).= For users that want to ensure maximum performance (e.g. to address the VPN= issue above), a similar preference (or permissions grant) could be exposed= that allows enumeration of all IPs.

FAQ
Q: WebRTC already requires permission to access getUserM= edia. Why not use that permission to control interface enumeration?
A= : Receive-only applications (e.g. streaming media) or datachannel applicati= ons don't require a call to gUM, so there are cases where that approach= would not work.
Q: Is this only for browsers, or also for native apps= ?
A: This proposal is currently targeted at browsers. Native applicat= ions, especially on mobile, need to be able to access individual interfaces= in order to be able to do seamless wifi-cellular call handover.

=
We welcome feedback on this proposal.

Guo-wei Shieh= and Justin Uberti

--001a11c1dcbcf7473a0514217fd7-- From nobody Mon Apr 20 01:52: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 F2EC31AD0A4 for ; Mon, 20 Apr 2015 01:52:44 -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 bw8EFosGWWMV for ; Mon, 20 Apr 2015 01:52:43 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 97C3F1AD0A3 for ; Mon, 20 Apr 2015 01:52:43 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 4FB901EB8478; Mon, 20 Apr 2015 10:52:42 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.22]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0224.002; Mon, 20 Apr 2015 10:52:42 +0200 From: "Hutton, Andrew" To: Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG call for adoption: draft-schwartz-rtcweb-return Thread-Index: AQHQeHFuqzJQBRzJZkuSrnXI8T9yI51VnVkg Date: Mon, 20 Apr 2015 08:52:41 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E73A7CB@MCHP04MSX.global-ad.net> References: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-schwartz-rtcweb-return@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-schwartz-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: Mon, 20 Apr 2015 08:52:45 -0000 I support adoption and will participate in the discussion. As others have said the auto-discovery is an issue that should be discussed= in TRAM and this draft should reflect the conclusion to that discussion. Andy > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sean Turner > Sent: 16 April 2015 19:16 > To: rtcweb@ietf.org > Cc: draft-schwartz-rtcweb-return@tools.ietf.org > Subject: [rtcweb] WG call for adoption: draft-schwartz-rtcweb-return >=20 > All, >=20 > There's been some interest expressed in having > http://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/ adopted > as an RTCWeb WG item. Please respond to say whether you support > adoption of this work as a working group work item and whether you will > participate in the discussion. If you are opposed to this draft > becoming a WG document, please say so (and say why). Please have your > response in by 20150423 23:59 UTC. >=20 > Thanks in advance! >=20 > spt >=20 > PS - For the casual lurker, there was some vigorous discussion in > Dallas on the -05 version but based on the [1] thread and the -06 > version it looks like we're in much better shape. >=20 > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg14402.html > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Apr 20 01:59: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 EA2E41AD0BC for ; Mon, 20 Apr 2015 01:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, 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 CMogGv48Sdr2 for ; Mon, 20 Apr 2015 01:59:39 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951A01AD0BB for ; Mon, 20 Apr 2015 01:59:38 -0700 (PDT) Received: from ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201504201059374883; Mon, 20 Apr 2015 10:59:37 +0200 From: "Karl Stahl" To: "'Hutton, Andrew'" , "'Sean Turner'" , References: <9F33F40F6F2CD847824537F3C4E37DDF1E73A7CB@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E73A7CB@MCHP04MSX.global-ad.net> Date: Mon, 20 Apr 2015 10:59:34 +0200 Message-ID: <03fd01d07b48$528b3160$f7a19420$@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: AQHQeHFuqzJQBRzJZkuSrnXI8T9yI51VnVkggAACIYA= Content-Language: sv Archived-At: Cc: draft-schwartz-rtcweb-return@tools.ietf.org Subject: Re: [rtcweb] WG call for adoption: draft-schwartz-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: Mon, 20 Apr 2015 08:59:41 -0000 I also support adoption and will participate in the discussion. /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Hutton, Andrew Skickat: den 20 april 2015 10:53 Till: Sean Turner; rtcweb@ietf.org Kopia: draft-schwartz-rtcweb-return@tools.ietf.org =C4mne: Re: [rtcweb] WG call for adoption: draft-schwartz-rtcweb-return I support adoption and will participate in the discussion. As others have said the auto-discovery is an issue that should be = discussed in TRAM and this draft should reflect the conclusion to that discussion. Andy > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sean Turner > Sent: 16 April 2015 19:16 > To: rtcweb@ietf.org > Cc: draft-schwartz-rtcweb-return@tools.ietf.org > Subject: [rtcweb] WG call for adoption: draft-schwartz-rtcweb-return >=20 > All, >=20 > There's been some interest expressed in having=20 > http://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/ adopted=20 > as an RTCWeb WG item. Please respond to say whether you support=20 > adoption of this work as a working group work item and whether you = will > participate in the discussion. If you are opposed to this draft > becoming a WG document, please say so (and say why). Please have your = > response in by 20150423 23:59 UTC. >=20 > Thanks in advance! >=20 > spt >=20 > PS - For the casual lurker, there was some vigorous discussion in=20 > Dallas on the -05 version but based on the [1] thread and the -06=20 > version it looks like we're in much better shape. >=20 > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg14402.html > _______________________________________________ > 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 Mon Apr 20 04:32: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 654C21B2AE2 for ; Mon, 20 Apr 2015 04:32: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 Uiah0VH7woMt for ; Mon, 20 Apr 2015 04:32:09 -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 020AB1B2AD8 for ; Mon, 20 Apr 2015 04:31:56 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-02-5534e3aaff60 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B3.12.28347.AA3E4355; Mon, 20 Apr 2015 13:31:54 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.210.2; Mon, 20 Apr 2015 13:31:54 +0200 Message-ID: <5534E3A9.2010508@ericsson.com> Date: Mon, 20 Apr 2015 13:31:53 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" References: <6D8CC46E-1A9F-4C2E-B133-D2040B0D78DE@cisco.com> In-Reply-To: <6D8CC46E-1A9F-4C2E-B133-D2040B0D78DE@cisco.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvje6qxyahBjcvGFl0TGazWPuvnd2B yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgypgwm6NgF3fF5s2LWBsYWzi7GDk5JARMJD5/ vMsCYYtJXLi3nq2LkYtDSOAoo8TOq0vZIZzljBILVr8GynBw8ApoS5xYEQLSwCKgKvH450Qm EJtNwELi5o9GNhBbVCBKYuLXQ2BDeQUEJU7OfAJmiwhESEy8fgGsRljAUuLBl+/sILaQgI3E rptLGEFsTgFbieP7+plBbGYBA4kji+awQtjyEs1bZzND1GtLNDR1sE5gFJiFZMUsJC2zkLQs YGRexShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYkge3/DbYwfjyueMhRgEORiUe3gWxJqFC rIllxZW5hxilOViUxHntjA+FCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDcpnqu4oxBxGPh 7DPtMw5KaJ11Vnx4cL1fnW1o45YSJ7mLL0tNtj5mjrdVYTrI4nHjlPbub2Z3FixpaZwZPfuL 5+2da9NWZWoVcC+SjG+R5Ew66nDi0ewE/4dNybq7Du3etjXD9YqO+LOv15IM8kIfz1mgZyVs 8e6u0Vsl0QMiXRxLg01uXL2hxFKckWioxVxUnAgAt93mBioCAAA= Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-audio-07 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 Apr 2015 11:32:10 -0000 Hi, I have one comment on this, which I sent earlier on. But to ensure that it is not missed I include it here: 1. Section 3: WebRTC clients are REQUIRED to implement the following audio codecs: I think this should use the Overview definitions. Thus, I think this applies to an "WebRTC endpoint". With the above resolved, I support publication. Cheers Magnus Cullen Jennings (fluffy) skrev den 2015-04-16 20:27: > > Dear WG, > > This starts a working group last call for: > > draft-ietf-rtcweb-audio-07 > > Please review them in detail. The chairs will send a separate email with some comments from us and others that can be considered part of the WGLC comments. > > This WGLC will end on May 1, 2015. > > Thanks, > Ted, Sean, Cullen (with our Chairs hat on) > > > > > _______________________________________________ > 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 Mon Apr 20 06:50: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 0C48D1B2BB3 for ; Mon, 20 Apr 2015 06:50:39 -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 qiOPPW5MN09w for ; Mon, 20 Apr 2015 06:50:37 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.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 E8A081B2BB2 for ; Mon, 20 Apr 2015 06:50:36 -0700 (PDT) Received: by oica37 with SMTP id a37so122617646oic.0 for ; Mon, 20 Apr 2015 06:50: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vn2KEULYRO4/Ch8zE+iCxqBvjUipeu9vld412FKz34Q=; b=icQQTh0IJOe9PYdB0V13iXmLCZ0WvRT8peTPwyxDXTCX+DQJ4nLtwXmnLmxXf2O1YM Mp63H9q0egX1eClbVzdADyDtzo8wPlbPSA2jFwFj/zCmfwReq/gXivgjMRwpyaSLsLP3 lab/gp1E2zQ15IERcrB5po7vu3bzmJ8ZkhXTnkva0DwKNgBLFynMJKQ2ySMfjL2Cl/9S 5PFvANKRRbfZXx48QUkYigudqHG8tuggxajbnnRGB/nawdWP6aKglqHqhH2EiJAunex+ hw2qd/vprdUklX1V9gWrwsYh9Xy1PcdPKmPe9fuVYGFvlftIWUdn3pMeknbCgahob4p1 M1vA== X-Gm-Message-State: ALoCoQlLcwVyKJfMEdvbtiwyAZXmSExYj9hkIEcBWJ9DNnx7wAoXxoUW5GQtpjfvGLYIk23W8Bz7 X-Received: by 10.60.103.70 with SMTP id fu6mr14539306oeb.27.1429537836299; Mon, 20 Apr 2015 06:50:36 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id u141sm12473893oie.8.2015.04.20.06.50.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 06:50:35 -0700 (PDT) Message-ID: <55350429.9060608@jive.com> Date: Mon, 20 Apr 2015 09:50:33 -0400 From: Simon Perreault 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: Justin Uberti , Guo-wei Shieh , "rtcweb@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 13:50:39 -0000 Interesting! Would a dual-stack client do the same procedure for IPv6 and offer both IPv4 and IPv6 candidates? Would a single IPv6 host candidate be enumerated, and would it be the one used to contact the STUN/TURN server? This proposal has potential to reduce the bandwidth used by connectivity checks quite a bit. Do you see this reduction as significant? Worst case would be (1 host, 1 server reflexive, 1 relayed)^2 x (IPv4, IPv6) = 18 checks if I'm not mistaken. That's close to practically negligible. Simon Le 2015-04-20 01:49, Justin Uberti a écrit : > *Background* > At IETF 92 we proposed a browser mechanism that users could enable to > avoid disclosing their VPN IP to websites as a side effect of ICE > candidate generation. When this mechanism was enabled, the browser would > bind only to 0.0.0.0 and ::, and only generate candidates via STUN and > TURN; because these sockets would follow the OS default routing, the > only candidate addresses discovered would be the ones that the website > already had access to (i.e. from the HTTP request). > > The primary downsides with this mechanism were: > a) users had to manually enable it (through some potentially non-obvious > preference) > b) when enabled, it caused trombone routing in intranet cases > c) when enabled, it broke pretty much every simple demo page (which > typically don't use STUN servers) > > *Proposal* > We now propose a new mechanism that attempts to address these issues. > The new mechanism works like the previous mechanism, but during the > candidate generation process, we call getsockname to obtain the local IP > address of the interface used to talk to the STUN/TURN server. This > obtains a *single* interface IP, which allows the browser to avoid > trombone routing, but also minimizes the amount of IP information > revealed to JS. Furthermore, the STUN traffic continues to go out the > default route, meaning that if a VPN is used, the 'real' public address > is still not disclosed. (Naturally, this has some performance > implications, as a user may not always want their media to go out the VPN.) > > For pages that don't use STUN/TURN servers (typically demo pages), there > are a few options to consider: > a) always surface localhost as a candidate when no STUN/TURN servers are > provided (works with existing demos, but may have false positives with > certain apps) > b) always include some default STUN server when no STUN/TURN servers are > provided (similar to above, plus complexity of choosing default) > c) add some RTCConfiguration parameter indicating that the localhost > address is desired (requires updating many demo pages) > > None of these choices is ideal, but this seems like a solvable problem. > > *Implications for Browsers* > As this mechanism should alleviate the primary security concerns with > interface enumeration, with relatively small impact on user experience, > we propose that this be the default for browsers. For users that don't > want to disclose any local IP information, browsers could expose a > preference that prevents surfacing even the single local IP (i.e. the > originally proposed behavior). For users that want to ensure maximum > performance (e.g. to address the VPN issue above), a similar preference > (or permissions grant) could be exposed that allows enumeration of all IPs. > > *FAQ* > Q: WebRTC already requires permission to access getUserMedia. Why not > use that permission to control interface enumeration? > A: Receive-only applications (e.g. streaming media) or datachannel > applications don't require a call to gUM, so there are cases where that > approach would not work. > Q: Is this only for browsers, or also for native apps? > A: This proposal is currently targeted at browsers. Native applications, > especially on mobile, need to be able to access individual interfaces in > order to be able to do seamless wifi-cellular call handover. > > We welcome feedback on this proposal. > > Guo-wei Shieh and Justin Uberti > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Apr 20 06:59: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 E9F631B2BC0 for ; Mon, 20 Apr 2015 06:59:43 -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 9XokQRq0cZBT for ; Mon, 20 Apr 2015 06:59:41 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1FE1B2BBC for ; Mon, 20 Apr 2015 06:59:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EA9B97C39A0; Mon, 20 Apr 2015 15:59:39 +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 lsPxO0PO_VBw; Mon, 20 Apr 2015 15:59:37 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9B2387C396B; Mon, 20 Apr 2015 15:59:37 +0200 (CEST) Message-ID: <55350649.8080502@alvestrand.no> Date: Mon, 20 Apr 2015 15:59:37 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Justin Uberti , Guo-wei Shieh , "rtcweb@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 13:59:44 -0000 Den 20. april 2015 07:49, skrev Justin Uberti: > *Background* > At IETF 92 we proposed a browser mechanism that users could enable to > avoid disclosing their VPN IP to websites as a side effect of ICE > candidate generation. When this mechanism was enabled, the browser would > bind only to 0.0.0.0 and ::, and only generate candidates via STUN and > TURN; because these sockets would follow the OS default routing, the > only candidate addresses discovered would be the ones that the website > already had access to (i.e. from the HTTP request). > > The primary downsides with this mechanism were: > a) users had to manually enable it (through some potentially non-obvious > preference) > b) when enabled, it caused trombone routing in intranet cases > c) when enabled, it broke pretty much every simple demo page (which > typically don't use STUN servers) > > *Proposal* > We now propose a new mechanism that attempts to address these issues. > The new mechanism works like the previous mechanism, but during the > candidate generation process, we call getsockname to obtain the local IP > address of the interface used to talk to the STUN/TURN server. This > obtains a *single* interface IP, which allows the browser to avoid > trombone routing, but also minimizes the amount of IP information > revealed to JS. Furthermore, the STUN traffic continues to go out the > default route, meaning that if a VPN is used, the 'real' public address > is still not disclosed. (Naturally, this has some performance > implications, as a user may not always want their media to go out the VPN.) > > For pages that don't use STUN/TURN servers (typically demo pages), there > are a few options to consider: > a) always surface localhost as a candidate when no STUN/TURN servers are > provided (works with existing demos, but may have false positives with > certain apps) > b) always include some default STUN server when no STUN/TURN servers are > provided (similar to above, plus complexity of choosing default) > c) add some RTCConfiguration parameter indicating that the localhost > address is desired (requires updating many demo pages) > > None of these choices is ideal, but this seems like a solvable problem. > > *Implications for Browsers* > As this mechanism should alleviate the primary security concerns with > interface enumeration, with relatively small impact on user experience, > we propose that this be the default for browsers. For users that don't > want to disclose any local IP information, browsers could expose a > preference that prevents surfacing even the single local IP (i.e. the > originally proposed behavior). For users that want to ensure maximum > performance (e.g. to address the VPN issue above), a similar preference > (or permissions grant) could be exposed that allows enumeration of all IPs. > > *FAQ* > Q: WebRTC already requires permission to access getUserMedia. Why not > use that permission to control interface enumeration? > A: Receive-only applications (e.g. streaming media) or datachannel > applications don't require a call to gUM, so there are cases where that > approach would not work. > Q: Is this only for browsers, or also for native apps? > A: This proposal is currently targeted at browsers. Native applications, > especially on mobile, need to be able to access individual interfaces in > order to be able to do seamless wifi-cellular call handover. Just checking - what about browsers on mobile? Wouldn't they want to do seamless handover too? (if they can be allowed to detect that the interface has changed when a connection breaks, and add new candidates at that time (which implies trickle ICE), this may be a minor issue.) > > We welcome feedback on this proposal. > > Guo-wei Shieh and Justin Uberti > From nobody Mon Apr 20 07:29: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 671581B2E00 for ; Mon, 20 Apr 2015 07:29: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 zteC_45XhwKJ for ; Mon, 20 Apr 2015 07:29:00 -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 E390A1B2DF8 for ; Mon, 20 Apr 2015 07:28:59 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so61904785igb.1 for ; Mon, 20 Apr 2015 07:28:59 -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=vvF+GxPEyKfZFFoslvreeyc5xnF5lPaTlPBcPG2Sy8Y=; b=TPkAIlezPruitSJfAYDjkvdLOq2Hs7NRC4vZCJ4kMGV+Fe+EDoP3aIPclXT2GjmC0O nN399EjJTOXp9DMmi8isTZhyIwBMpuwFhMH3tXk/k9Fo/KVnC31bIVfYkouFcZrLCAcq irJV1NRp+yd6X1tGHcRN3OT0xc+8OfLCYJzQj4gwU5fmnvG6JW7s6P+/hXtaWPLcc5mW n/VCOKBYJeG0U2GGK8L/w7ILQBrorAmBZUwNiQhBmEv1Zbt4Ns+lyUvYJ1pVqsKtfkMe YkAPGn2bGi9M2Na9H6cuVZUCt+xtXTzVhkPQem82dSHl2h1TdGoSFXfttRoczCiIEIjN i9wQ== X-Gm-Message-State: ALoCoQlab/GIsY+9aCZCyg3HJY7NZKRpL313D5EiZrfnkTv94DNWE5MZk7BHbgGTq0tJWxk1+3xl X-Received: by 10.50.41.8 with SMTP id b8mr20966386igl.38.1429540138306; Mon, 20 Apr 2015 07:28:58 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com. [209.85.213.172]) by mx.google.com with ESMTPSA id d15sm5622883igo.8.2015.04.20.07.28.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 07:28:57 -0700 (PDT) Received: by igblo3 with SMTP id lo3so61471239igb.0 for ; Mon, 20 Apr 2015 07:28:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.43.227 with SMTP id z3mr6625063igl.33.1429540136080; Mon, 20 Apr 2015 07:28:56 -0700 (PDT) Received: by 10.36.110.149 with HTTP; Mon, 20 Apr 2015 07:28:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Apr 2015 10:28:56 -0400 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=089e0111c01600de7a051428c00b Archived-At: Cc: "rtcweb@ietf.org" , Guo-wei Shieh Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 14:29:01 -0000 --089e0111c01600de7a051428c00b Content-Type: text/plain; charset=UTF-8 On Mon, Apr 20, 2015 at 1:49 AM, Justin Uberti wrote: > > For pages that don't use STUN/TURN servers (typically demo pages), there > are a few options to consider: > > This will also affect the applications that only communicate with servers on public IP. Such applications (especially if they implement ICE-TCP) have no need for STUN/TURN servers. Would it make sense to sense to use the IP address used to retrieve the application via HTTP as a candidate address? Alternatively, applications that communicate only with the servers on public IPs will work even if they include candidates with fake IPs. Real IPs will be resolved as peer reflexive during the ICE connectivity checks. _____________ Roman Shpount --089e0111c01600de7a051428c00b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 20, 2015 at 1:49 AM, Justin Uberti <ju= berti@google.com> wrote:

For pages that don't use STUN/TURN server= s (typically demo pages), there are a few options to consider:


This will also affect the = applications that only communicate with servers on public IP. Such applicat= ions (especially if they implement ICE-TCP) have no need for STUN/TURN serv= ers.

Would it make sense to sense to use the IP ad= dress used to retrieve the application via HTTP as a candidate address?

Alternatively, applications that communicate only wit= h the servers on public IPs will work even if they include candidates with = fake IPs. Real IPs will be resolved as peer reflexive during the ICE connec= tivity checks.
_____________
Ro= man Shpount

=C2=A0
--089e0111c01600de7a051428c00b-- From nobody Mon Apr 20 07:40: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 39CD51B2E26 for ; Mon, 20 Apr 2015 07:40:06 -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 JS_QLaSdvPwq for ; Mon, 20 Apr 2015 07:40:04 -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 19DFA1B2E25 for ; Mon, 20 Apr 2015 07:40:04 -0700 (PDT) Received: by qgeb100 with SMTP id b100so53331650qge.3 for ; Mon, 20 Apr 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=jFMvZvI/UpVEcAUW12wsL34l8nsnlAd0bCfOuFvH994=; b=LW6QUK81SRS3OPXrLbJ8TT9aIrYUJYlx8KLICWeI5LXg5GEaKBrV11Z94zsAnG22ym mG6UizOrIzMeh80LdJjOzQspZZXhC+H9mhu1qRxSu66esp3LGXTfW5/YQcc1j01vl4U5 b/FpBA9S8Ye0+D79e709QEmRISgMGS/fIrdgj1jebXeyqcdtoPxbPANUadE4A1S6bJSP wU8OPhDLwKCcaaX+4AKdwhQNI8TfaxC+Gk1O726K8NNWTWew5L7lsF1kV0ioaf4J35dQ OQYugFtad5U9FlaM2ljzKQwZJQhZDgf3ffWXfnrccYtcs5xUTHTM4w5ewnkCNuv0Mu5m s4PQ== MIME-Version: 1.0 X-Received: by 10.55.21.166 with SMTP id 38mr28343941qkv.88.1429540803373; Mon, 20 Apr 2015 07:40:03 -0700 (PDT) Received: by 10.229.61.9 with HTTP; Mon, 20 Apr 2015 07:40:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Apr 2015 10:40:03 -0400 Message-ID: From: Kaiduan Xie To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Guo-wei Shieh , "rtcweb@ietf.org" Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 14:40:06 -0000 For two users on the same VPN, the traffic may go through TURN server if hairpin is not supported on the router. /Kaiduan On Mon, Apr 20, 2015 at 10:28 AM, Roman Shpount wrote: > > On Mon, Apr 20, 2015 at 1:49 AM, Justin Uberti wrote: >> >> >> For pages that don't use STUN/TURN servers (typically demo pages), there >> are a few options to consider: >> > > This will also affect the applications that only communicate with servers on > public IP. Such applications (especially if they implement ICE-TCP) have no > need for STUN/TURN servers. > > Would it make sense to sense to use the IP address used to retrieve the > application via HTTP as a candidate address? > > Alternatively, applications that communicate only with the servers on public > IPs will work even if they include candidates with fake IPs. Real IPs will > be resolved as peer reflexive during the ICE connectivity checks. > _____________ > Roman Shpount > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Apr 20 07:52: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 EE29F1B2C09 for ; Mon, 20 Apr 2015 07:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_92=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 jLe_SFsUibDe for ; Mon, 20 Apr 2015 07:52:04 -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 EECB61B2C02 for ; Mon, 20 Apr 2015 07:52:03 -0700 (PDT) Received: from [10.199.33.195] ([216.2.50.205]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t3KEq6ea005395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 20 Apr 2015 16:52:10 +0200 Message-ID: <5535128D.10504@goodadvice.pages.de> Date: Mon, 20 Apr 2015 07:51:57 -0700 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.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] New proposal for IP address handling in WebRTC 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 Apr 2015 14:52:06 -0000 [...] > For pages that don't use STUN/TURN servers (typically demo pages), there > are a few options to consider: just checking: usecases like sharedrop.io (which put the users in the same "room" based on the ip address used to connect to the signaling server) are not really affected by this, right? Since users know a-priori that they're on the same LAN, STUN servers are not necessary here, but adding them doesn't hurt much either. From nobody Mon Apr 20 08:11: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 723601B2E97 for ; Mon, 20 Apr 2015 08:11:19 -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 LGtxYageLca2 for ; Mon, 20 Apr 2015 08:11:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7702B1B2E6A for ; Mon, 20 Apr 2015 08:11:18 -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.1/8.14.9) with ESMTPSA id t3KFBDMG016166 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Apr 2015 10:11:14 -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: <55351711.9090302@nostrum.com> Date: Mon, 20 Apr 2015 10:11:13 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Philipp Hancke , rtcweb@ietf.org References: <5535128D.10504@goodadvice.pages.de> In-Reply-To: <5535128D.10504@goodadvice.pages.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 15:11:19 -0000 On 4/20/15 09:51, Philipp Hancke wrote: > Since users know a-priori that they're on the same LAN, STUN servers > are not necessary here, but adding them doesn't hurt much either. If you look at Justin's proposal, you'll note that he suggests that the lack of a STUN server means you'll only offer up localhost as a candidate. In other words, without a STUN server, you can't talk to anyone but yourself. /a From nobody Mon Apr 20 08:19: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 8A0EB1B2ED1 for ; Mon, 20 Apr 2015 08:19: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, 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 Me1FoChi10AS for ; Mon, 20 Apr 2015 08:19:44 -0700 (PDT) Received: from relay.mailchannels.net (ftx-008-i771.relay.mailchannels.net [50.61.143.71]) by ietfa.amsl.com (Postfix) with ESMTP id D64F01B2ECB for ; Mon, 20 Apr 2015 08:19:43 -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 AB47560747 for ; Mon, 20 Apr 2015 15:19:39 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.254.9.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Mon, 20 Apr 2015 15:19:40 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1429543179882:3218065694 X-MC-Ingress-Time: 1429543179882 Received: from pool-173-49-141-196.phlapa.fios.verizon.net ([173.49.141.196]:61034 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YkDU2-0000MM-Pp for rtcweb@ietf.org; Mon, 20 Apr 2015 10:19:38 -0500 Message-ID: <553518F0.6090904@jesup.org> Date: Mon, 20 Apr 2015 11:19:12 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.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] New proposal for IP address handling in WebRTC 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 Apr 2015 15:19:46 -0000 On 4/20/2015 1:49 AM, Justin Uberti wrote: > *Proposal* > We now propose a new mechanism that attempts to address these issues. > The new mechanism works like the previous mechanism, but during the > candidate generation process, we call getsockname to obtain the local > IP address of the interface used to talk to the STUN/TURN server. One concern here is that this is underspecified; I presume this means "the interface used to contact the STUN/TURN server by default if you don't force it to an interface" (or perhaps the interface used if you try to contact those addresses via TCP). I have concerns about how portable this is and how stable the binding would be. I suspect this can be worked through and specified, though. > This obtains a *single* interface IP, which allows the browser to > avoid trombone routing, but also minimizes the amount of IP > information revealed to JS. Furthermore, the STUN traffic continues to > go out the default route, meaning that if a VPN is used, the 'real' > public address is still not disclosed. (Naturally, this has some > performance implications, as a user may not always want their media to > go out the VPN.) This has major performance concerns, as many users (especially those who use VPNs for other-than-anonymity reasons, such as work VPNs) will simply see "WebRTC sucks" and have no real idea as to why - it would be very poorly discoverable if at all. I think browsers would need to find some way to surface this - but it's hard to do so without punching data through on the other interfaces to see if they're connected to something that can reach the STUN/TURN servers. This may not be visible to the JS, but does generate correlatable traffic on those addresses that could de-anonymize you. > *Implications for Browsers* > As this mechanism should alleviate the primary security concerns with > interface enumeration, with relatively small impact on user > experience, we propose that this be the default for browsers. For > users that don't want to disclose any local IP information, browsers > could expose a preference that prevents surfacing even the single > local IP (i.e. the originally proposed behavior). For users that want > to ensure maximum performance (e.g. to address the VPN issue above), a > similar preference (or permissions grant) could be exposed that allows > enumeration of all IPs. I'm not sure there's a way to resolve the paradox of making it work well, and making it impossible to leak information; I hope we can improve on this compromise to at least make the "your calls suck because you have a VPN" somewhat discoverable by users. The downside is that likely means UI changes, and possibly somewhat opaque-to-users descriptions required. I think this is another piecemeal attempt to wallpaper over the mess that results when half-hearted/half-understood attempts at anonymity are taken by users. I think a better (and more discoverable/understandable) solution is to tie changes in this to higher-level "anonymity mode" (very similar to Private Browsing, and perhaps combined with it). If you really want/need to by anonymous, you need to lock down a lot more than this. (See discussions of fingerprinting, for example.) I think this highlights the sort of problem when such half-hearted/half-understood attempts are made: http://arstechnica.com/security/2015/04/op-ed-why-the-entire-premise-of-tor-enabled-routers-is-ridiculous/ -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Mon Apr 20 08:34: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 7E2131B2EF9 for ; Mon, 20 Apr 2015 08:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_71=0.6, 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 LrQHDAMlbieR for ; Mon, 20 Apr 2015 08:34:42 -0700 (PDT) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.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 155111B2EFD for ; Mon, 20 Apr 2015 08:34:42 -0700 (PDT) Received: by qku63 with SMTP id 63so192718646qku.3 for ; Mon, 20 Apr 2015 08:34:41 -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:references:in-reply-to:content-type :content-transfer-encoding; bh=p89vXN5VInlLe2yNDSrla5HmVb7oYsH6sn2e3jVAkys=; b=YqlU+861gDB/xOTDIV5257LC+1mlj131rQnQr6u8HexFwDbsel8AFmxlpxf1JkrmG+ KTx7tvwlXmtJhTA85GitXkG8QRvtaxTw09fTxFiBVbU7t5K9ZdvA4fb2ddsibAIbaDo4 iDK4f0LewfEWAvppzpLSjPr6ZqoNUI7rzYZOCT1jdlz42cMOIf7Hq7VFYjTgv0yky/+6 e54LdP7udymybpgVK1i4KYms6aM2eSms7upPCppt5TmMKjcOcywezL8JsKv9sTUwAFT2 I7lJLOOExz1O5mmFTCtHLFdbF1GVcwm7qq8PXfwS9QeaEJroPXNxWr2ijk3SmOB4/KRU INUw== X-Gm-Message-State: ALoCoQlGlWdFrWIiJQo3xE8fNGAPukUaejqz3++fuN2Hh3y61upYbMBkmk96PJbMna7HhdvRbX7C X-Received: by 10.140.148.215 with SMTP id 206mr15092869qhu.62.1429544081356; Mon, 20 Apr 2015 08:34:41 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id n24sm14677314qkh.3.2015.04.20.08.34.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 08:34:40 -0700 (PDT) Message-ID: <55351C8E.1030906@jive.com> Date: Mon, 20 Apr 2015 11:34:38 -0400 From: Simon Perreault 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: Randell Jesup , rtcweb@ietf.org References: <553518F0.6090904@jesup.org> In-Reply-To: <553518F0.6090904@jesup.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 15:34:45 -0000 Le 2015-04-20 11:19, Randell Jesup a écrit : > On 4/20/2015 1:49 AM, Justin Uberti wrote: >> *Proposal* >> We now propose a new mechanism that attempts to address these issues. >> The new mechanism works like the previous mechanism, but during the >> candidate generation process, we call getsockname to obtain the local >> IP address of the interface used to talk to the STUN/TURN server. > > One concern here is that this is underspecified; I presume this means > "the interface used to contact the STUN/TURN server by default if you > don't force it to an interface" (or perhaps the interface used if you > try to contact those addresses via TCP). I have concerns about how > portable this is and how stable the binding would be. I suspect this > can be worked through and specified, though. I thought that this is what was implied: s = socket(...); connect(s, ); getsockname(s, &local_addr); local_addr would then be advertised as host candidate. Works with both UDP and TCP, on every platform. > This has major performance concerns, as many users (especially those who > use VPNs for other-than-anonymity reasons, such as work VPNs) will > simply see "WebRTC sucks" and have no real idea as to why - it would be > very poorly discoverable if at all. Work VPNs very often suck and users already blame them for every problem they have, real or imaginary... Simon From nobody Mon Apr 20 08:51: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 932101B2E6A for ; Mon, 20 Apr 2015 08:51:09 -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 dnbft4CVoRtQ for ; Mon, 20 Apr 2015 08:51:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 210EF1B2C0C for ; Mon, 20 Apr 2015 08:51:05 -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.1/8.14.9) with ESMTPSA id t3KFp429019576 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Apr 2015 10:51:04 -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: <55352067.6070007@nostrum.com> Date: Mon, 20 Apr 2015 10:51:03 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 15:51:09 -0000 On 4/20/15 00:49, Justin Uberti wrote: > We now propose a new mechanism that attempts to address these issues. > The new mechanism works like the previous mechanism, but during the > candidate generation process, we call getsockname to obtain the local > IP address of the interface used to talk to the STUN/TURN server. This > obtains a *single* interface IP, which allows the browser to avoid > trombone routing, but also minimizes the amount of IP information > revealed to JS. Furthermore, the STUN traffic continues to go out the > default route, meaning that if a VPN is used, the 'real' public > address is still not disclosed. (Naturally, this has some performance > implications, as a user may not always want their media to go out the > VPN.) I think this is an incremental improvement on the previous proposal that is worth adding. > As this mechanism should alleviate the primary security concerns with > interface enumeration, with relatively small impact on user > experience, we propose that this be the default for browsers. Okay, you had me until here. The idea about choosing the address that we would use to route to a TURN server makes some assumptions about network architectures that don't hold in the general case. For those users who are willing to accept increased latency (sometimes), decreased quality (sometimes), and reduced connection rates (sometimes) in exchange for obscuring certain aspects of their network configuration, that's probably okay. You're making things slightly worse, but for a real benefit. Well, a real benefit for those specific users. The problem is that, despite the noise and fury that's resulted from this issue, the number of users for whom it is a real concern is an infinitesimally small fraction of those people who will ever use a web browser. And I'm not okay with taking an across-the-board service degradation for all users based on something that the overwhelming majority of them won't care about. I'll repeat what I said at the mic in Dallas: for users looking for the level of obscurity that you're proposing to provide, WebRTC isn't the only concern with regards to modern web browser operation. To get this correct requires a vast amount of work, and it's not something that anyone is likely to get right by themselves, regardless of level of ability. You need a comprehensive approach, such as that described at . To really get this correct, you usually need to have someone take care of the heavy lifting for you, which means running something like TorBrowser If we turn your proposed behavior on by default, we're doing the equivalent of putting a locked deadbolt on the bathroom window while leaving the front door unlocked, open, and made out of cardboard. So I'm all for including this ability as something that users can turn on, and I'd be happy to brainstorm ways to expose this to users in ways other than deep, dark prefs tweaking. But I think it would be a very detrimental overreaction to hobble WebRTC by default just to solve a problem for a tiny fraction of users. /a From nobody Mon Apr 20 10:59: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 8319C1A8AD0 for ; Mon, 20 Apr 2015 10:59: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 3FXgtZh-yEJQ for ; Mon, 20 Apr 2015 10:59:20 -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 DC3751B2C92 for ; Mon, 20 Apr 2015 10:59:04 -0700 (PDT) Received: by igblo3 with SMTP id lo3so66072496igb.1 for ; Mon, 20 Apr 2015 10:59:04 -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=okq632zyg70Br8SDAT0CPkFPGr5Pio3VmUml6+cLXkw=; b=v0UImSSeA+t4ShYyDHvHBg/Bn6zc85n8MsiSwSnMPehjQlLPg+nTaUUYSghvfbcKSd 3TTAynKjtoTQr763mTbJ3SOFIEy+PrLeGrc0INuQWZX0JwUn9tQ59gBQbt+0asJQ3vkH qc2u7/EUtUysmDRhXHOCFbFbmnOeyoFUFJBl5JPtBZoQ5SA88WrVe2Tok7RHD6pznwAT sJL0QNrwttYwY5T1+r1yeu7iVlCGYXFuEQUtzHoCqtNL0+xA87eKWKBDgLAINIMnb4Ne AgRaGk6mJy2xC1btb62tg3J6p+NzrPHfhKRUIS0LqwU/EHVumZvdvKuqonjJc1NJbuoe xpZg== MIME-Version: 1.0 X-Received: by 10.43.6.65 with SMTP id oj1mr19301267icb.75.1429552744319; Mon, 20 Apr 2015 10:59:04 -0700 (PDT) Received: by 10.64.76.106 with HTTP; Mon, 20 Apr 2015 10:59:04 -0700 (PDT) In-Reply-To: <55352067.6070007@nostrum.com> References: <55352067.6070007@nostrum.com> Date: Mon, 20 Apr 2015 10:59:04 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 17:59:22 -0000 I agree with Adam's assessment here. Have you considered whether enabling this selectively would be of any value? Say, for third parties... On 20 April 2015 at 08:51, Adam Roach wrote: > On 4/20/15 00:49, Justin Uberti wrote: >> >> We now propose a new mechanism that attempts to address these issues. The >> new mechanism works like the previous mechanism, but during the candidate >> generation process, we call getsockname to obtain the local IP address of >> the interface used to talk to the STUN/TURN server. This obtains a *single* >> interface IP, which allows the browser to avoid trombone routing, but also >> minimizes the amount of IP information revealed to JS. Furthermore, the STUN >> traffic continues to go out the default route, meaning that if a VPN is >> used, the 'real' public address is still not disclosed. (Naturally, this has >> some performance implications, as a user may not always want their media to >> go out the VPN.) > > > I think this is an incremental improvement on the previous proposal that is > worth adding. > > >> As this mechanism should alleviate the primary security concerns with >> interface enumeration, with relatively small impact on user experience, we >> propose that this be the default for browsers. > > > Okay, you had me until here. > > The idea about choosing the address that we would use to route to a TURN > server makes some assumptions about network architectures that don't hold in > the general case. For those users who are willing to accept increased > latency (sometimes), decreased quality (sometimes), and reduced connection > rates (sometimes) in exchange for obscuring certain aspects of their network > configuration, that's probably okay. You're making things slightly worse, > but for a real benefit. Well, a real benefit for those specific users. > > The problem is that, despite the noise and fury that's resulted from this > issue, the number of users for whom it is a real concern is an > infinitesimally small fraction of those people who will ever use a web > browser. And I'm not okay with taking an across-the-board service > degradation for all users based on something that the overwhelming majority > of them won't care about. > > I'll repeat what I said at the mic in Dallas: for users looking for the > level of obscurity that you're proposing to provide, WebRTC isn't the only > concern with regards to modern web browser operation. To get this correct > requires a vast amount of work, and it's not something that anyone is likely > to get right by themselves, regardless of level of ability. You need a > comprehensive approach, such as that described at > . To really get this > correct, you usually need to have someone take care of the heavy lifting for > you, which means running something like TorBrowser > > If we turn your proposed behavior on by default, we're doing the equivalent > of putting a locked deadbolt on the bathroom window while leaving the front > door unlocked, open, and made out of cardboard. > > So I'm all for including this ability as something that users can turn on, > and I'd be happy to brainstorm ways to expose this to users in ways other > than deep, dark prefs tweaking. But I think it would be a very detrimental > overreaction to hobble WebRTC by default just to solve a problem for a tiny > fraction of users. > > /a > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Apr 20 11:46: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 8BADA1B2C8F for ; Mon, 20 Apr 2015 11:46:11 -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 4lU6La3Wx9hK for ; Mon, 20 Apr 2015 11:46:09 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id A9C6D1B2C8C for ; Mon, 20 Apr 2015 11:46:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 84E9A7C3987 for ; Mon, 20 Apr 2015 20:46:07 +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 zxQRZ04qE1vh for ; Mon, 20 Apr 2015 20:46:05 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3670E7C3798 for ; Mon, 20 Apr 2015 20:46:05 +0200 (CEST) Message-ID: <5535496C.4000809@alvestrand.no> Date: Mon, 20 Apr 2015 20:46:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <55352067.6070007@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 18:46:11 -0000 On 04/20/2015 07:59 PM, Martin Thomson wrote: > I agree with Adam's assessment here. > > Have you considered whether enabling this selectively would be of any > value? Say, for third parties... Assuming that by "enabling this selectively", you mean "reveal less information than before".... As far as I can tell, the only selectivity that would make sense would be to enable this for the whole "drive-by web"; I can't figure out any conditions under which it would make sense to enable this for and disable it (revealing more information) for a random URL that users click on. Which leaves us with the option of enabling this new mechanism for the "drive-by web", and having the old, more information-revealing mechanism for installed apps. > > On 20 April 2015 at 08:51, Adam Roach wrote: >> On 4/20/15 00:49, Justin Uberti wrote: >>> We now propose a new mechanism that attempts to address these issues. The >>> new mechanism works like the previous mechanism, but during the candidate >>> generation process, we call getsockname to obtain the local IP address of >>> the interface used to talk to the STUN/TURN server. This obtains a *single* >>> interface IP, which allows the browser to avoid trombone routing, but also >>> minimizes the amount of IP information revealed to JS. Furthermore, the STUN >>> traffic continues to go out the default route, meaning that if a VPN is >>> used, the 'real' public address is still not disclosed. (Naturally, this has >>> some performance implications, as a user may not always want their media to >>> go out the VPN.) >> >> I think this is an incremental improvement on the previous proposal that is >> worth adding. >> >> >>> As this mechanism should alleviate the primary security concerns with >>> interface enumeration, with relatively small impact on user experience, we >>> propose that this be the default for browsers. >> >> Okay, you had me until here. >> >> The idea about choosing the address that we would use to route to a TURN >> server makes some assumptions about network architectures that don't hold in >> the general case. For those users who are willing to accept increased >> latency (sometimes), decreased quality (sometimes), and reduced connection >> rates (sometimes) in exchange for obscuring certain aspects of their network >> configuration, that's probably okay. You're making things slightly worse, >> but for a real benefit. Well, a real benefit for those specific users. >> >> The problem is that, despite the noise and fury that's resulted from this >> issue, the number of users for whom it is a real concern is an >> infinitesimally small fraction of those people who will ever use a web >> browser. And I'm not okay with taking an across-the-board service >> degradation for all users based on something that the overwhelming majority >> of them won't care about. >> >> I'll repeat what I said at the mic in Dallas: for users looking for the >> level of obscurity that you're proposing to provide, WebRTC isn't the only >> concern with regards to modern web browser operation. To get this correct >> requires a vast amount of work, and it's not something that anyone is likely >> to get right by themselves, regardless of level of ability. You need a >> comprehensive approach, such as that described at >> . To really get this >> correct, you usually need to have someone take care of the heavy lifting for >> you, which means running something like TorBrowser >> >> If we turn your proposed behavior on by default, we're doing the equivalent >> of putting a locked deadbolt on the bathroom window while leaving the front >> door unlocked, open, and made out of cardboard. >> >> So I'm all for including this ability as something that users can turn on, >> and I'd be happy to brainstorm ways to expose this to users in ways other >> than deep, dark prefs tweaking. But I think it would be a very detrimental >> overreaction to hobble WebRTC by default just to solve a problem for a tiny >> fraction of users. >> >> /a >> >> >> _______________________________________________ >> 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 -- Surveillance is pervasive. Go Dark. From nobody Mon Apr 20 12:03: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 516BC1B305C for ; Mon, 20 Apr 2015 12:03:02 -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 yR5qHOEMujhI for ; Mon, 20 Apr 2015 12:03:00 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001: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 1D0591B308B for ; Mon, 20 Apr 2015 12:02:41 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so67985060igb.0 for ; Mon, 20 Apr 2015 12:02:40 -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=5e8mVGga86eUJL/obye1FJ+ZqMEW8kZhIHX8hfkbWrg=; b=SX+5q1HvrA3F2KCoBHaHYvhaMnkK3Y18hqmAeGrPejFpTHr+volA1GGlbAnMYDESg1 uDXWDUmBhLtJWTL1L9dkM/ghg0v7ni+kVmcjLgsUXYzWgaDTh4r3K0/KBgjUurswlztu phYQGiGRU36POF+yBzTPrF/nyGRFg+u5MTMO0PjcN0msYX+moeQt4pM18fUIDjX9dDGU lpJLXJi2z1IJlGc7ZMTwuAtHryBckjts6D/g4IO8zmaFK/+KbhXW/yZtPBnwsqoKyS85 L83r1gFM3wxpBty0N114JplPx/0RdgngtcF4GGUgTQfUnbzfBth/3zKKw2Z/2NVzPw4d mGkw== MIME-Version: 1.0 X-Received: by 10.50.78.9 with SMTP id x9mr22683256igw.44.1429556560629; Mon, 20 Apr 2015 12:02:40 -0700 (PDT) Received: by 10.64.76.106 with HTTP; Mon, 20 Apr 2015 12:02:40 -0700 (PDT) In-Reply-To: <5535496C.4000809@alvestrand.no> References: <55352067.6070007@nostrum.com> <5535496C.4000809@alvestrand.no> Date: Mon, 20 Apr 2015 12:02:40 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 19:03:02 -0000 On 20 April 2015 at 11:46, Harald Alvestrand wrote: > As far as I can tell, the only selectivity that would make sense would > be to enable this for the whole "drive-by web"; I can't figure out any > conditions under which it would make sense to enable this for thing> and disable it (revealing more information) for a random URL that > users click on. You are describing the harder meta-problem of determining what sites users actually trust. That's a hard problem. And I would never make solving that problem a condition on anything. If anything, that argument is cause to not break the world and turn this on for everyone, it's a reason to keep the API functional. I mentioned third parties. That's a very simple technical thing to accomplish. If we can more precisely identify when NOT to share information, that would help a great deal. Or, if someone manages to solve the trust problem (hah!), then we can talk about degrading the experience for the untrustworthy. From nobody Mon Apr 20 12:40: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 E5D6F1A86DD for ; Mon, 20 Apr 2015 12:40:43 -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 0YFz1GOI2MY4 for ; Mon, 20 Apr 2015 12:40:42 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D7A1A702B for ; Mon, 20 Apr 2015 12:40:42 -0700 (PDT) Received: from [81.187.2.149] (port=36556 helo=[192.168.0.18]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YkHYe-0001IP-5z for rtcweb@ietf.org; Mon, 20 Apr 2015 20:40:40 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <6D8CC46E-1A9F-4C2E-B133-D2040B0D78DE@cisco.com> Date: Mon, 20 Apr 2015 20:40:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <10EE2D8D-2EBF-4B11-B20E-133F52937CE2@csperkins.org> References: <6D8CC46E-1A9F-4C2E-B133-D2040B0D78DE@cisco.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-audio-07 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 Apr 2015 19:40:44 -0000 On 16 Apr 2015, at 19:27, Cullen Jennings (fluffy) = wrote: > This starts a working group last call for: >=20 > draft-ietf-rtcweb-audio-07 >=20 > Please review them in detail. The chairs will send a separate email = with some comments from us and others that can be considered part of the = WGLC comments.=20 Two quick comments: - Section 3 says "Clients MAY use the offer/answer mechanism to signal a = preference for a particular mode or ptime". Is this just of Opus, or in = general? It might be worthwhile saying something explicit about = acceptable ptime values in general. - Security considerations ought to explicitly point to the security = considerations of RFCs 3389, 4733, 6716, and = draft-ietf-payload-rtp-opus. It should possibly also point to the = draft-ietf-rtcweb-security-arch-11, and the security considerations for = RTP use in WebRTC in draft-ietf-rtcweb-rtp-usage-22 In general though, I think this draft is in good shape, and support = publication. --=20 Colin Perkins https://csperkins.org/ From nobody Mon Apr 20 13:59: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 C1A481B31AF for ; Mon, 20 Apr 2015 13:59:31 -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 OBNL8TvVPHFU for ; Mon, 20 Apr 2015 13:59:28 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id B6B111B31B3 for ; Mon, 20 Apr 2015 13:59:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id ED9857C3987; Mon, 20 Apr 2015 22:59: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 TpY96qXQBA_W; Mon, 20 Apr 2015 22:59:26 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id D428F7C3798; Mon, 20 Apr 2015 22:59:26 +0200 (CEST) Message-ID: <553568AE.3040706@alvestrand.no> Date: Mon, 20 Apr 2015 22:59:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Martin Thomson References: <55352067.6070007@nostrum.com> <5535496C.4000809@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 20:59:32 -0000 Den 20. april 2015 21:02, skrev Martin Thomson: > On 20 April 2015 at 11:46, Harald Alvestrand wrote: >> As far as I can tell, the only selectivity that would make sense would >> be to enable this for the whole "drive-by web"; I can't figure out any >> conditions under which it would make sense to enable this for > thing> and disable it (revealing more information) for a random URL that >> users click on. > > You are describing the harder meta-problem of determining what sites > users actually trust. That's a hard problem. And I would never make > solving that problem a condition on anything. I think we agree on this point. If anything, that > argument is cause to not break the world and turn this on for > everyone, it's a reason to keep the API functional. > > I mentioned third parties. That's a very simple technical thing to > accomplish. If we can more precisely identify when NOT to share > information, that would help a great deal. Or, if someone manages to > solve the trust problem (hah!), then we can talk about degrading the > experience for the untrustworthy. > What do you mean by "third parties", and why should one trust them less than others? I'm sure there's a reference somewhere, but I don't know what it is. From nobody Mon Apr 20 14:19: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 687B31B3201 for ; Mon, 20 Apr 2015 14:19:21 -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 vX9SeNsc9d_l for ; Mon, 20 Apr 2015 14:19:20 -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 2ADA21B31FF for ; Mon, 20 Apr 2015 14:19:20 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so72416913igb.1 for ; Mon, 20 Apr 2015 14:19:19 -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=CH/X9Pi0Cd3XE0RPFqHdpZWZVOiwMpXu8OkEU11zWY8=; b=KljkJkiwpppDCzbL052klfNm3RdyJAkQsxku6/gjAHEAWULHo87NLnCtZz8nk3ZLvq 2+RzdQSWbQ2xnFntFOUMqkBalDxJ1W18TYbqvNq0CDKwhTY9FRkN5E17R3CC5ECO4J1T LLHKiQaZfOZX6oVv4db43njC7NVN51gGTq3lEzE/OM4pTrG/7ceL5cv6E06vTkoZt583 9oeFAjzJ8C2UpEnvFDuz15MUnmfaWUaa33/Ga1ebeFkBApN6PQuhwwJucgoC+s6AlQ2f LqxGlUzkOwylbrOQQ27BCDmfFjFxRxXJag3Zhy3oH9nMiL6KFJnro94GWwj2oSdNswYk nYlg== MIME-Version: 1.0 X-Received: by 10.50.41.8 with SMTP id b8mr23354699igl.38.1429564759667; Mon, 20 Apr 2015 14:19:19 -0700 (PDT) Received: by 10.64.76.106 with HTTP; Mon, 20 Apr 2015 14:19:19 -0700 (PDT) In-Reply-To: <553568AE.3040706@alvestrand.no> References: <55352067.6070007@nostrum.com> <5535496C.4000809@alvestrand.no> <553568AE.3040706@alvestrand.no> Date: Mon, 20 Apr 2015 14:19:19 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 21:19:21 -0000 On 20 April 2015 at 13:59, Harald Alvestrand wrote: > What do you mean by "third parties", and why should one trust them less > than others? > > I'm sure there's a reference somewhere, but I don't know what it is. Sorry, I thought this was well understood. First party: what you see in the funny bar at the top that no one pays attention to Third party: those that provide the images you see From nobody Mon Apr 20 15: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 839AA1B32FF for ; Mon, 20 Apr 2015 15:14:12 -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 dqxk2r2wPvps for ; Mon, 20 Apr 2015 15:14:11 -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 95D461B32F7 for ; Mon, 20 Apr 2015 15:14:11 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so72179892igb.0 for ; Mon, 20 Apr 2015 15:14:11 -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=OafnbkimVrAx+XHdERI7UaoLcC7TtwA+jfZKsP18yck=; b=B7+xQ0qHwKLQ9ZpcOHTo6vTf1h/jV45f+nbLz+HBdZ6bpnYw0BmLXSbpoCq8Sg2Kck vuYU+MRUHWAZrVZ2882sTYWKiYiil6roTj1hxAFbKv3aY/0jIkSxAAwDMIHK6RmQlcN4 VHaJTUe6C23vjo112fIyVERhiCx2ZFwC4LSLJ3hkU2a5WxdYo8xOdRlpGvm1GwD4C7m2 gv/G/34bowxpmMVxbknoxQODW6YetH+af15mGhUiLbFq4ewEfekEggpwdAPuz4o6WujY ZxJKk3sm+OLew4QOXw2RrxHeGRDP8u5MPrSA+GVfH90S4y33FHJbfnr61D2QChrWIvwQ ac+Q== 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=OafnbkimVrAx+XHdERI7UaoLcC7TtwA+jfZKsP18yck=; b=BaPyAf7D0Ye5rH9Df0ezccC0NLfgFbKptp1yqIwH87C+mKeJsCI87FpnIwpP67/fNE OWvjFIR72ayUwQ68s23bqQrqfT2QJ1KP2I5b8nij4oIt+e90z06w9iMLGCzoa33CEPP9 5sbJj6fZxdLDxD0DeuG2lysKXJeAO0z5V1DqpcHw4Axp9Z1UlNq5PXna/NBRB+xXhBp4 W8PBsuqLx3nQ/YCP+GnSPjmycNxdiJbFefddxP9DYbKYc5T+e5HC+hrI1+8DqAxaxKDL V7c30ipGOPpTepxicjQ2eKyRsR4QwfzxLlFaOBsUNCPH3qJjzXdmMBKwGDRRgDi0IBqE JScg== X-Gm-Message-State: ALoCoQlTznxq9C/m8NE4xTIaJkHh6LV/cGSYpgXyRCTV4kuukORFSNvdXIZHh4MBLlUMDNZT4xO3 X-Received: by 10.43.71.201 with SMTP id yl9mr35758icb.66.1429568051018; Mon, 20 Apr 2015 15:14:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.63.3 with HTTP; Mon, 20 Apr 2015 15:13:50 -0700 (PDT) In-Reply-To: <55351711.9090302@nostrum.com> References: <5535128D.10504@goodadvice.pages.de> <55351711.9090302@nostrum.com> From: Justin Uberti Date: Mon, 20 Apr 2015 15:13:50 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a11c1dcbcdd283105142f3f1b Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 22:14:12 -0000 --001a11c1dcbcdd283105142f3f1b Content-Type: text/plain; charset=UTF-8 On Mon, Apr 20, 2015 at 8:11 AM, Adam Roach wrote: > On 4/20/15 09:51, Philipp Hancke wrote: > >> Since users know a-priori that they're on the same LAN, STUN servers are >> not necessary here, but adding them doesn't hurt much either. >> > > If you look at Justin's proposal, you'll note that he suggests that the > lack of a STUN server means you'll only offer up localhost as a candidate. > > In other words, without a STUN server, you can't talk to anyone but > yourself. Not exactly true; in the case where one side has a public IP, a STUN server is not needed. As Roman points out, even without a STUN server, you can still generate binding requests which will cause prflx candidates to be created on the remote side. --001a11c1dcbcdd283105142f3f1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 20, 2015 at 8:11 AM, Adam Roach <adam@nostrum.com> wrote:
On 4/20/15 = 09:51, Philipp Hancke wrote:
Since users know a-priori that they're on the same LAN, STUN servers ar= e not necessary here, but adding them doesn't hurt much either.

 If you look at Justin's proposal, you'll note that he suggests that= the lack of a STUN server means you'll only offer up localhost as a ca= ndidate.

In other words, without a STUN server, you can't talk to anyone but you= rself.

Not exactly true; in the case where = one side has a public IP, a STUN server is not needed. As Roman points out,= even without a STUN server, you can still generate binding requests which = will cause prflx candidates to be created on the remote side.
--001a11c1dcbcdd283105142f3f1b-- From nobody Tue Apr 21 02:40: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 86FC31A8853 for ; Tue, 21 Apr 2015 02:40:28 -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 EOF42NQPN9vD for ; Tue, 21 Apr 2015 02:40:27 -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 C502F1A885C for ; Tue, 21 Apr 2015 02:40:26 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-3b-55361b08f708 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5F.F8.01716.80B16355; Tue, 21 Apr 2015 11:40:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.210.2; Tue, 21 Apr 2015 11:40:24 +0200 Message-ID: <55361B07.3010707@ericsson.com> Date: Tue, 21 Apr 2015 11:40:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Emil Ivov , Martin Thomson References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+JvjS6HtFmowYmP1hbLX55gtFizcwKL RcdkNotrZ/4xWqz9187uwOox5fdGVo9p9++zeeycdZfdY8mSn0we/98EBrBGcdmkpOZklqUW 6dslcGU0fVnOXPCfveLAtDVMDYz72boYOTgkBEwkVv1U7mLkBDLFJC7cWw8U5uIQEjjKKLH1 0VcWCGc5o8TCrhZ2kCpeAW2JnlmrWUFsFgFViTNLdjCC2GwCFhI3fzSygdiiAlESE78eYoGo F5Q4OfMJmC0i4CXx+sAnsF5mgWqJu9dPgcWFBXwlGjZ9YYdYNpVZouXkJrAEp0CgxN2vzSwQ DQYSRxbNgWqWl2jeOpsZxBYCOqihqYN1AqPgLCT7ZiFpmYWkZQEj8ypG0eLU4uLcdCNjvdSi zOTi4vw8vbzUkk2MwEA/uOW37g7G1a8dDzEKcDAq8fAqrDcNFWJNLCuuzD3EKM3BoiTOa2d8 KERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo4/uo9gJ6Q9EZl66ZHyAXYD3lHgJN3fal79H 7OIL3L03vvD89UFM1JC7TFJuWYPlxg7fb1uO3NtgLu7iVaFQxlhttm5C2Ik2w+bFe/U012hr GX1fau+4zGtD+8zHMzc4PXikcVZKR9s4NWlXj/rN6dkXCn/fNzZ9Yvicb9FNP+mFfB17+Xe+ VWIpzkg01GIuKk4EAIQ4fRhVAgAA Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 09:40:28 -0000 Emil Ivov skrev den 2015-03-30 23:00: > Makes sense to me! (and of course, any number would make sense here > given how superfluous circuit breakers are in the presence of consent > checks) > I think you are quite wrong here. The circuit breaker is there to stop persistent congestion. I think you are likely to get your consent checks through in sufficient frequency to maintain consent, but have totally crappy audio due to packet loss in the 10% range. So please don't confuse the purposes of these mechanisms. 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 ---------------------------------------------------------------------- From nobody Tue Apr 21 02: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 049441A89AC for ; Tue, 21 Apr 2015 02:52:16 -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 iebCbhTPNMKM for ; Tue, 21 Apr 2015 02:52:14 -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 98CCE1A8994 for ; Tue, 21 Apr 2015 02:52:13 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-4e-55361dcb8880 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0E.3B.01716.BCD16355; Tue, 21 Apr 2015 11:52:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Tue, 21 Apr 2015 11:52:11 +0200 Message-ID: <55361DCA.7000101@ericsson.com> Date: Tue, 21 Apr 2015 11:52:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Martin Thomson , Harald Alvestrand References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <551A902A.9080402@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvje5pWbNQg5lbrC2O9XWxWVw784/R Yu2/dnYHZo8rE66weuycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGbOf9rMUrOWpeLn2F3sD 42fOLkYODgkBE4kl12W7GDmBTDGJC/fWs3UxcnEICRxllDj1pJsRwlnOKLH+5xE2kCpeAW2J D1NPs4PYLAKqEgfu/2MEsdkELCRu/mgEqxEViJKY+PUQC0S9oMTJmU/AbBGBSIkjR86C9TIL qEvcWXwOzBYW8JVo2PSFHWLZKXaJm717mUESnAKBEhP/TWCBaDCQOLJoDiuELS/RvHU2WI0Q 0EENTR2sExgFZyHZNwtJyywkLQsYmVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBAbxwS2/ dXcwrn7teIhRgINRiYdXYb1pqBBrYllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGMNW+uy20QxfGVog8uSNc8kJzmkXva4Ff0v1+ZubYLIubTOPpZU27/Emtdbr O9+6iU2Zo3/ibvID1kn7vpSb/uzLP7SqLfJ1xiK97zP/XUh/VN3P39y8den2lXtefli7cd0Z 6+TUble9ZVpKNUut1G7nZwr+cDcurHS94pMSaBfPK/nxbcWWRCWW4oxEQy3mouJEAOk1TGdD AgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 09:52:16 -0000 Hi, I think I have a more specific proposal of how to deal with this case regarding the circuit breakers and legacy peer end-point that don't send RTCP. I think it is important that we consider these legacy gatewaying cases. Unfortunately there appear to be a lot of audio RTP senders that don't send RTCP. Proposal: In case circuit breaker #2 RTCP Timeout is triggered and; - No RTCP at all has been received; - This endpoint neither sends nor receive more than 72 kbps of RTP payload data on average over a 5 second window per direction; then this triggering of the circuit breaker MAY be ignored. This would be done if it is desired to support legacy RTP sender that lacks RTCP implementations. The motivation for the above formulation is really to make it clear that this is only for legacy, and not create a situation where ignoring the circuit breaker is okay, even if RTCP is being received, just because one are in a really low-rate situation. I wonder if the above should go into the RTP usage or into the circuit breaker document itself? 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 ---------------------------------------------------------------------- From nobody Tue Apr 21 03:08: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 4DA1D1A0064 for ; Tue, 21 Apr 2015 03:08:51 -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 jNQE1U6bM7Qg for ; Tue, 21 Apr 2015 03:08:49 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 503631A0076 for ; Tue, 21 Apr 2015 03:08:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 826127C3AFA; Tue, 21 Apr 2015 12:08:41 +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 z3qzI29bqCEF; Tue, 21 Apr 2015 12:08:40 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8B1247C3AF7; Tue, 21 Apr 2015 12:08:40 +0200 (CEST) Message-ID: <553621A8.5000400@alvestrand.no> Date: Tue, 21 Apr 2015 12:08:40 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Magnus Westerlund , Martin Thomson References: <551A902A.9080402@alvestrand.no> <55361DCA.7000101@ericsson.com> In-Reply-To: <55361DCA.7000101@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 10:08:51 -0000 Den 21. april 2015 11:52, skrev Magnus Westerlund: > Hi, > > I think I have a more specific proposal of how to deal with this case > regarding the circuit breakers and legacy peer end-point that don't send > RTCP. I think it is important that we consider these legacy gatewaying > cases. Unfortunately there appear to be a lot of audio RTP senders that > don't send RTCP. > > Proposal: > > In case circuit breaker #2 RTCP Timeout is triggered and; > - No RTCP at all has been received; > - This endpoint neither sends nor receive more than 72 kbps of RTP > payload data on average over a 5 second window per direction; > > then this triggering of the circuit breaker MAY be ignored. This would > be done if it is desired to support legacy RTP sender that lacks RTCP > implementations. > > > > The motivation for the above formulation is really to make it clear that > this is only for legacy, and not create a situation where ignoring the > circuit breaker is okay, even if RTCP is being received, just because > one are in a really low-rate situation. > > I wonder if the above should go into the RTP usage or into the circuit > breaker document itself? I think it belongs to advice on gatewaying, actually - and that gateways should be prepared to do RTCP synthesis in this situation. Perpetuating tolerance for the broken behavior of ignoring "MUST send RTCP" seems like a path that doesn't lead to getting rid of the behavior in the end. From nobody Tue Apr 21 03:11: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 C27721A00B8 for ; Tue, 21 Apr 2015 03:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 S4j1dkQtd6OG for ; Tue, 21 Apr 2015 03:10:56 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.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 BB9531A0076 for ; Tue, 21 Apr 2015 03:10:56 -0700 (PDT) Received: by oblw8 with SMTP id w8so141893225obl.0 for ; Tue, 21 Apr 2015 03:10:56 -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=AvB5UN5sNQSmzHsAC93uThQyzHvGu3ZPCflHkcY2zDc=; b=TmmtlkMa6dHH2zeU2pJ+Uzvr1fQhP8WDU6fj84TS+En3M+lu6eZHcM20Dh1SYKG+Tr vBJckkqVR6lH98iIam9gZojgtqcH+DLNJZUjS2S2ARcbc6lAyLvmVj2tHmRh0mXejz36 ErY9gtPKu1k1NQc4u4CFcLebx3h/3gCfVb+5VYcDchiELnZpdERwt+JqphSnBy8Yq9gj KzSGhSQLn5+JehZZqq9jHtOrsrXqKdz2kY+qq+pWtHbPOgnbl2t8GStHz3umPmVL4dCn eqIjtUiREWwCgwnmEcCKK1A51DGs3tree/liNEXXsPy9ESrk9IMAh1JDhzhyzfyn0YX2 3FHA== X-Gm-Message-State: ALoCoQnjpKDqU5MALyLkdjxBE3d8Kkk+CyuF4fOHg+EsoEKpbfCRbWSnW3PbYwxyriv/lPqdYyLN X-Received: by 10.202.225.65 with SMTP id y62mr17214271oig.78.1429611056185; Tue, 21 Apr 2015 03:10:56 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com. [209.85.218.46]) by mx.google.com with ESMTPSA id cd3sm926621oec.2.2015.04.21.03.10.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 03:10:55 -0700 (PDT) Received: by oift201 with SMTP id t201so150064434oif.3 for ; Tue, 21 Apr 2015 03:10:55 -0700 (PDT) X-Received: by 10.60.82.67 with SMTP id g3mr18100576oey.29.1429611055532; Tue, 21 Apr 2015 03:10:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.22.9 with HTTP; Tue, 21 Apr 2015 03:10:35 -0700 (PDT) In-Reply-To: <55361B07.3010707@ericsson.com> References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> From: Emil Ivov Date: Tue, 21 Apr 2015 13:10:35 +0300 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 10:10:58 -0000 On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund wrote: > Emil Ivov skrev den 2015-03-30 23:00: > >> Makes sense to me! (and of course, any number would make sense here >> given how superfluous circuit breakers are in the presence of consent >> checks) >> > > I think you are quite wrong here. The circuit breaker is there to stop > persistent congestion. I think you are likely to get your consent checks > through in sufficient frequency to maintain consent, but have totally > crappy audio due to packet loss in the 10% range. I am going to be *very* upset if my browser drops a call because of 10% packet loss. I regularly have calls in hotel networks with up to 20%+ regular packet loss and still enjoy productive conversations thanks to FEC and PLC. If my audio does happen to be crappy I will be the one to decide when to hang up. The only times I could see as sensible for circuit breakers to take over would be in situations where no data is getting through. One example of a userful breakup would be users mistakenly leaving connections open thinking they are dead. Obviously consent checks would also cover this scenario. So as I've mentioned before, I can see circuit breakers as an useful recommendation for some applications but they are definitely redundant in the context of WebRTC. > So please don't confuse the purposes of these mechanisms. I assure you I am not. One actually serves a purpose as MTI in webrtc the other doesn't (which is why no one will implement it). Emil -- https://jitsi.org From nobody Tue Apr 21 03:35: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 9FE341A90FC for ; Tue, 21 Apr 2015 03:35:38 -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 CBszpeFcc44H for ; Tue, 21 Apr 2015 03:35:37 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9E51A90F9 for ; Tue, 21 Apr 2015 03:35:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7D2C67C3AFA for ; Tue, 21 Apr 2015 12:35:36 +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 ZWJlZvoIUH78 for ; Tue, 21 Apr 2015 12:35:35 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 58B487C3AF7 for ; Tue, 21 Apr 2015 12:35:35 +0200 (CEST) Message-ID: <553627F7.6010407@alvestrand.no> Date: Tue, 21 Apr 2015 12:35:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 10:35:38 -0000 Den 21. april 2015 12:10, skrev Emil Ivov: > On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund > wrote: >> Emil Ivov skrev den 2015-03-30 23:00: >> >>> Makes sense to me! (and of course, any number would make sense here >>> given how superfluous circuit breakers are in the presence of consent >>> checks) >>> >> >> I think you are quite wrong here. The circuit breaker is there to stop >> persistent congestion. I think you are likely to get your consent checks >> through in sufficient frequency to maintain consent, but have totally >> crappy audio due to packet loss in the 10% range. > > I am going to be *very* upset if my browser drops a call because of > 10% packet loss. I regularly have calls in hotel networks with up to > 20%+ regular packet loss and still enjoy productive conversations > thanks to FEC and PLC. > > If my audio does happen to be crappy I will be the one to decide when > to hang up. The only times I could see as sensible for circuit > breakers to take over would be in situations where no data is getting > through. One example of a userful breakup would be users mistakenly > leaving connections open thinking they are dead. Obviously consent > checks would also cover this scenario. > > So as I've mentioned before, I can see circuit breakers as an useful > recommendation for some applications but they are definitely redundant > in the context of WebRTC. The purpose of circuit breakers is not to save the users from themselves. It is to save the network from the users - to make sure that if WebRTC users cause persistent congestion in the network, that congestion will eventually go away. This is the same purpose as the AIMD algorithm in TCP (which is not particularly beneficial for each individual user). From nobody Tue Apr 21 03:53: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 275FC1A913B for ; Tue, 21 Apr 2015 03:53: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 T6wbMLUKG7Kp for ; Tue, 21 Apr 2015 03:53:11 -0700 (PDT) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.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 8E8721A9136 for ; Tue, 21 Apr 2015 03:53:11 -0700 (PDT) Received: by oblw8 with SMTP id w8so142555637obl.0 for ; Tue, 21 Apr 2015 03: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=oTM7ax2Cf+TSpG71/Uf1rHUIvnEc7xCI/DfQzgEZ2SY=; b=mn5PQoOr20NpLlo7oSXQLh4ut9C4glffPskoVoCDhpFdrT8IrKvK5K08SKxwIk46mj WUcmahqEsqLVkXxzXXpTXfjVtH1spniYyhxGriy4NcnkhAOpQyMp2fPDIZuq4x802+6E PeFJDCQuTbBhOPQkXozMGhEHvuktg08qacu9QZWMJQmdHehmFNk9VC9KFpwJV7zSAxHt La5iolGK6iFEOkRhjFcA7mET3W+4+mOGsdyfZxySNBVJ6VyUavfsgsa+6TCxterD/8Qb GDFvtGTUUKTexvcQbt+/ZASlE2ZFPaDLRGr3LzpvPLwNGi7t3yaMKmi0tnNCuHwDkjBC dDtw== X-Gm-Message-State: ALoCoQn2SxOYZ8pC8tz6MU40lRZUe5TPm2H3RSGqwZQpCpBZiQDMLMuPhdcIP9JBVA04BBFXCGJ4 X-Received: by 10.202.168.204 with SMTP id r195mr17600449oie.32.1429613590969; Tue, 21 Apr 2015 03:53:10 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com. [209.85.214.174]) by mx.google.com with ESMTPSA id y62sm982916oif.12.2015.04.21.03.53.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 03:53:10 -0700 (PDT) Received: by obfe9 with SMTP id e9so141106159obf.1 for ; Tue, 21 Apr 2015 03:53:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.194.84 with SMTP id s81mr3284833oif.39.1429613589902; Tue, 21 Apr 2015 03:53:09 -0700 (PDT) Received: by 10.76.22.9 with HTTP; Tue, 21 Apr 2015 03:53:09 -0700 (PDT) In-Reply-To: <553627F7.6010407@alvestrand.no> References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> Date: Tue, 21 Apr 2015 13:53:09 +0300 Message-ID: From: Emil Ivov To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a113cd216315648051439da0a Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Endpoints that don't support RTCP 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 Apr 2015 10:53:13 -0000 --001a113cd216315648051439da0a Content-Type: text/plain; charset=UTF-8 Hey Harald, On Tuesday, April 21, 2015, Harald Alvestrand wrote: > Den 21. april 2015 12:10, skrev Emil Ivov: > > On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund > > > wrote: > >> Emil Ivov skrev den 2015-03-30 23:00: > > So as I've mentioned before, I can see circuit breakers as an useful > > recommendation for some applications but they are definitely redundant > > in the context of WebRTC. > > The purpose of circuit breakers is not to save the users from themselves. > > It is to save the network from the users - to make sure that if WebRTC > users cause persistent congestion in the network, that congestion will > eventually go away. Sure, I completely understand the intention. I just think CBs are a very crude attempt of achieving it. Also somewhat redundant in the context of WebRTC. I have repeatedly asked for data that shows how CBs are beneficial in large-scale diverse deployments and so far I haven't seen any (I have even been asked by Colin to provide data that they don't work ... which is quite absurd :) ) > This is the same purpose as the AIMD algorithm in TCP (which is not > particularly beneficial for each individual user). > Well ... it isn't really the same though is it. AIMD doesn't sadistically kill your connection at the first whiff of trouble ... :) ... it just MDs your bandwidth usage. Ah ... whatever ... Emil -- --sent from my mobile --001a113cd216315648051439da0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Harald,

On Tuesday, April 21, 2015, Harald Alvestrand <harald@alvestrand.no> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Den 21. april 2015 12:10, skrev Emil Ivov: > On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund
> <magnus.westerlund@ericsson.com&g= t; wrote:
>> Emil Ivov skrev den 2015-03-30 23:00:
> So as I've mentioned before, I can see circuit breakers as an usef= ul
> recommendation for some applications but they are definitely redundant=
> in the context of WebRTC.

The purpose of circuit breakers is not to save the users from themselves.
It is to save the network from the users - to make sure that if WebRTC
users cause persistent congestion in the network, that congestion will
eventually go away.

Sure, I completely understan= d the intention. I just think CBs are a very crude attempt of=C2=A0achievin= g it. Also somewhat redundant in the context of WebRTC.

I have repeatedly asked for data that=C2=A0shows how CBs are benefici= al=C2=A0in large-scale diverse=C2=A0deployments and so far I haven't se= en any (I have even been asked by Colin=C2=A0to provide data that they don&= #39;t work ... which is quite absurd :) )
=C2=A0
This is the same purpose as the AIMD algorithm in TCP (which is not
particularly beneficial for each individual user).

Well ... it=C2=A0isn't really the same thou= gh is it. AIMD doesn't sadistically kill your connection at the first w= hiff of trouble ...=C2=A0:) ... it just MDs your bandwidth usage.

Ah ... whatever ...

Emil
=C2=A0


--
--sent from my mobile
--001a113cd216315648051439da0a-- From nobody Tue Apr 21 03:56: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 22D811A914D for ; Tue, 21 Apr 2015 03:56:33 -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, 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 6cAkfsbKg3nU for ; Tue, 21 Apr 2015 03:56:31 -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 3379A1A8AE1 for ; Tue, 21 Apr 2015 03:56:19 -0700 (PDT) Received: (qmail 78005 invoked from network); 21 Apr 2015 10:56:17 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 5699 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 21 Apr 2015 10:56:17 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 7719E18A069E; Tue, 21 Apr 2015 11:56:13 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 5951118A05CA; Tue, 21 Apr 2015 11:56:13 +0100 (BST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Tim Panton In-Reply-To: <55350429.9060608@jive.com> Date: Tue, 21 Apr 2015 11:56:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55350429.9060608@jive.com> To: Simon Perreault X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Guo-wei Shieh , "rtcweb@ietf.org" Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 10:56:33 -0000 > On 20 Apr 2015, at 14:50, Simon Perreault wrote: >=20 > Interesting! >=20 > Would a dual-stack client do the same procedure for IPv6 and offer = both > IPv4 and IPv6 candidates? Would a single IPv6 host candidate be > enumerated, and would it be the one used to contact the STUN/TURN = server? We should _only_ send IPV6 candidates with temporary addresses, not the = ones derived from the hardware mac address.=20 Chrome currently _prefers_ temporary addresses but will send a hardware = one if no temporary is available. T. Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk From nobody Tue Apr 21 04:08: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 2829F1A01EA for ; Tue, 21 Apr 2015 04:08:19 -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 xucZvKVXD5z4 for ; Tue, 21 Apr 2015 04:08: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 9B6D01A9135 for ; Tue, 21 Apr 2015 04:08:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D71CB7C3B1A; Tue, 21 Apr 2015 13:08: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 j-xFTVfkvu8X; Tue, 21 Apr 2015 13:08:15 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9A92C7C3B17; Tue, 21 Apr 2015 13:08:15 +0200 (CEST) Message-ID: <55362F9F.60908@alvestrand.no> Date: Tue, 21 Apr 2015 13:08:15 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Emil Ivov References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Endpoints that don't support RTCP 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 Apr 2015 11:08:19 -0000 Den 21. april 2015 12:53, skrev Emil Ivov: > Hey Harald, > > On Tuesday, April 21, 2015, Harald Alvestrand > wrote: > > Den 21. april 2015 12:10, skrev Emil Ivov: > > On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund > > > wrote: > >> Emil Ivov skrev den 2015-03-30 23:00: > > So as I've mentioned before, I can see circuit breakers as an useful > > recommendation for some applications but they are definitely redundant > > in the context of WebRTC. > > The purpose of circuit breakers is not to save the users from > themselves. > > It is to save the network from the users - to make sure that if WebRTC > users cause persistent congestion in the network, that congestion will > eventually go away. > > > Sure, I completely understand the intention. I just think CBs are a very > crude attempt of achieving it. Also somewhat redundant in the context of > WebRTC. When we started out, we kind of hoped it would be rendered OBE by RMCAT, but that's taken a bit longer than I originally hoped.... > > I have repeatedly asked for data that shows how CBs are beneficial in > large-scale diverse deployments and so far I haven't seen any (I have > even been asked by Colin to provide data that they don't work ... which > is quite absurd :) ) All the data I've seen so far seems to show that it's not going to be a complete PITA by firing far too often..... but that's what I have.... > > > This is the same purpose as the AIMD algorithm in TCP (which is not > particularly beneficial for each individual user). > > > Well ... it isn't really the same though is it. AIMD doesn't > sadistically kill your connection at the first whiff of trouble ... :) > ... it just MDs your bandwidth usage. I'd rather describe circuitbreakers as "kills your connection when the shit has already hit the fan", but the difference between the two is a matter of whether the trigger point is too low or too high... matter of debate... > > Ah ... whatever ... > > Emil > > > > -- > --sent from my mobile From nobody Tue Apr 21 05:42: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 388491ACD36 for ; Tue, 21 Apr 2015 05:42:48 -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_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 16p6p81lf3-m for ; Tue, 21 Apr 2015 05:42:46 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB0D1ACD2F for ; Tue, 21 Apr 2015 05:42:29 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.241.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 929BC22E263; Tue, 21 Apr 2015 08:42:27 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Cullen Jennings In-Reply-To: <55361DCA.7000101@ericsson.com> Date: Tue, 21 Apr 2015 06:42:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <551A902A.9080402@alvestrand.no> <55361DCA.7000101@e ricsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 12:42:48 -0000 That sounds workable but I think the 72 kbps is a bit low when you = consider header extensions for audio level and other things. I'd be more = comfortable with something closer to100 kbps. Given the granularity of = circuit breakers I don't think 100 vs 72 is going to make circuit = breaker not work.=20 I think this needs to be in circuit breakers draft.=20 > On Apr 21, 2015, at 3:52 AM, Magnus Westerlund = wrote: >=20 > Hi, >=20 > I think I have a more specific proposal of how to deal with this case > regarding the circuit breakers and legacy peer end-point that don't = send > RTCP. I think it is important that we consider these legacy gatewaying > cases. Unfortunately there appear to be a lot of audio RTP senders = that > don't send RTCP. >=20 > Proposal: >=20 > In case circuit breaker #2 RTCP Timeout is triggered and; > - No RTCP at all has been received; > - This endpoint neither sends nor receive more than 72 kbps of RTP > payload data on average over a 5 second window per direction; >=20 > then this triggering of the circuit breaker MAY be ignored. This would > be done if it is desired to support legacy RTP sender that lacks RTCP > implementations. >=20 >=20 >=20 > The motivation for the above formulation is really to make it clear = that > this is only for legacy, and not create a situation where ignoring the > circuit breaker is okay, even if RTCP is being received, just because > one are in a really low-rate situation. >=20 > I wonder if the above should go into the RTP usage or into the circuit > breaker document itself? >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Tue Apr 21 07:09: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 9ED671ACD44 for ; Tue, 21 Apr 2015 07:09:12 -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 2Do1H_b9f7OL for ; Tue, 21 Apr 2015 07:09:02 -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 8D6FD1ACD96 for ; Tue, 21 Apr 2015 07:08:57 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-a0-553659f7296d Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EE.99.19337.7F956355; Tue, 21 Apr 2015 16:08:55 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.210.2; Tue, 21 Apr 2015 16:08:55 +0200 Message-ID: <553659F6.2040906@ericsson.com> Date: Tue, 21 Apr 2015 16:08:54 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Harald Alvestrand , Martin Thomson References: <551A902A.9080402@alvestrand.no> <55361DCA.7000101@ericsson.com> <553621A8.5000400@alvestrand.no> In-Reply-To: <553621A8.5000400@alvestrand.no> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvje73SLNQg95nJhbH+rrYLK6d+cdo sfZfO7sDs8eVCVdYPXbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSujO+H29gKZktUNP+cydjA OEu4i5GTQ0LARKJj128WCFtM4sK99WwgtpDAUUaJd80GXYxcQPZyRolfV48ygiR4BbQl/myZ DtbAIqAq0fXrGzuIzSZgIXHzRyNYs6hAlMTEr4dYIOoFJU7OfAJmiwhESqxd+A6snllAXeLO 4nNgtrCAr0TDpi/sEMtusUtc+f6GCSTBKaArcXvnEjaIBgOJI4vmsELY8hLNW2czQ1yqLdHQ 1ME6gVFwFpJ9s5C0zELSsoCReRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYBAf3PJbdQfj 5TeOhxgFOBiVeHgV1puGCrEmlhVX5h5ilOZgURLntTM+FCIkkJ5YkpqdmlqQWhRfVJqTWnyI kYmDU6qBcQJP3vcv9xZE/wq0tXxTOyfXuH7Zi9cir17yLnCY9U5pUvsEiyMzLrLftWZ5+OzA rLql9ZK76z/teyTsW/Navok3+//aW/7Wa0pcomMrAo1mLxBOqf5W365w59sFLfkOvryTzA6y 0f7RkSdOloh0Jd9qML/pGVC1ctuuCTvUftg3KXFy7G30V2Ipzkg01GIuKk4EAGHGthVDAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 14:09:12 -0000 Harald Alvestrand skrev den 2015-04-21 12:08: > Den 21. april 2015 11:52, skrev Magnus Westerlund: >> Hi, >> >> I think I have a more specific proposal of how to deal with this case >> regarding the circuit breakers and legacy peer end-point that don't send >> RTCP. I think it is important that we consider these legacy gatewaying >> cases. Unfortunately there appear to be a lot of audio RTP senders that >> don't send RTCP. >> >> Proposal: >> >> In case circuit breaker #2 RTCP Timeout is triggered and; >> - No RTCP at all has been received; >> - This endpoint neither sends nor receive more than 72 kbps of RTP >> payload data on average over a 5 second window per direction; >> >> then this triggering of the circuit breaker MAY be ignored. This would >> be done if it is desired to support legacy RTP sender that lacks RTCP >> implementations. >> >> >> >> The motivation for the above formulation is really to make it clear that >> this is only for legacy, and not create a situation where ignoring the >> circuit breaker is okay, even if RTCP is being received, just because >> one are in a really low-rate situation. >> >> I wonder if the above should go into the RTP usage or into the circuit >> breaker document itself? > > > I think it belongs to advice on gatewaying, actually - and that gateways > should be prepared to do RTCP synthesis in this situation. I think the question here is if the gateways MUST do. From this thread that answer appears to me to be no. It would be a rough consensus but still no. That they SHOULD do it in a way that cause minimal issues I think there is support for. What I have seen there are several issues here. One if that a gateway may not know if the gatewayed endpoint will send RTCP. Secondly, the gateway only reports on part of the path. Which may or may not be an issue depending on that path. In some cases the path beyond the gateway to the far end in relation to the WebRTC endpoint will be on reserved resources / dedicated networks, in others it will be on best effort networks. Thus, this RTCP helps but is not the full story and that needs to be clear when such reporting is done. > > Perpetuating tolerance for the broken behavior of ignoring "MUST send > RTCP" seems like a path that doesn't lead to getting rid of the behavior > in the end. I tend to agree, but the question is what you do when you have such significant deployed base with this issue. Because in this case the cost of dealing with that deployed base is not put on the deployed base, but on the gateways. 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 ---------------------------------------------------------------------- From nobody Tue Apr 21 07:34: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 87F1D1AC442 for ; Tue, 21 Apr 2015 07:34:00 -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 43fIbELlrZeW for ; Tue, 21 Apr 2015 07:33:59 -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 5B3FC1ACDA7 for ; Tue, 21 Apr 2015 07:33:43 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-22-55365fc5c6b9 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BB.3E.19337.5CF56355; Tue, 21 Apr 2015 16:33:41 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.210.2; Tue, 21 Apr 2015 16:23:09 +0200 Message-ID: <55365D4A.30507@ericsson.com> Date: Tue, 21 Apr 2015 16:23:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Cullen Jennings References: <551A902A.9080402@alvestrand.no> <55361DCA.7000101@e ricsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM+Jvje7ReLNQg3WfJSw+rP/BaHHtzD9G i7X/2tkdmD12zrrL7rFkyU8mj8vnPzIGMEdx2aSk5mSWpRbp2yVwZSydeYitYCJnxZzfF5ka GLexdzFyckgImEj0t25kgbDFJC7cW8/WxcjFISRwlFHix7X7UM5yRolvtyeyglTxCmhKbP3Y yQZiswioSsz9uhosziZgIXHzRyNYXFQgSmLi10MsEPWCEidnPgGzRQSUJc7tuMsMYjMLhEg8 PPsOzBYW8JVo2PSFHWLZYnaJT6/ngA3lFLCS2D3xGxNEg4HEkUUQcWYBeYnmrbPBmoUEtCUa mjpYJzAKzkKybxaSlllIWhYwMq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECAzjg1t+q+5g vPzG8RCjAAejEg+vwnrTUCHWxLLiytxDjNIcLErivHbGh0KEBNITS1KzU1MLUovii0pzUosP MTJxcEo1MLK4lrQfK94U0p8Y7mHA/tRSmHvVg8Nlv/9O4/iatip81/2ffutV38VqSMqdCebi iRPy9ogr/sy+XHJ7y8vZxukfTB8+uXtiza3TT4VWVb7fqnPyvZvk1oQYrSSPNeyvV7rlHW0t v70tMEjkqsKXf9ZbpohdZiu8eGzBqe8rGK/dOrR2hZj87AYlluKMREMt5qLiRADISqi0RAIA AA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 14:34:00 -0000 Cullen Jennings skrev den 2015-04-21 14:42: > > That sounds workable but I think the 72 kbps is a bit low when you > consider header extensions for audio level and other things. I'd be > more comfortable with something closer to100 kbps. Given the > granularity of circuit breakers I don't think 100 vs 72 is going to > make circuit breaker not work. Sorry, but I specified it as RTP Payload bit-rate, which would exclude header extension. My thought would be to allow for 64 kbps codec plus some payload format overhead. However, I have to ask if really audio level header extensions and legacy audio endpoint that don't send RTCP being a likely combination? 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 ---------------------------------------------------------------------- From nobody Tue Apr 21 08:13: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 2BC171ACDD9 for ; Tue, 21 Apr 2015 08:13:56 -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 qUtJ4QjK40i3 for ; Tue, 21 Apr 2015 08:13:53 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 79A751ACE12 for ; Tue, 21 Apr 2015 08:13:53 -0700 (PDT) Received: by wgso17 with SMTP id o17so217324912wgs.1 for ; Tue, 21 Apr 2015 08:13:52 -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=b6D5w3dW4Am5lpKXmUf9nqwWisx3lsWD8I7jMx/o1so=; b=RKbRm066fCYhrnhJ6PTnvX7vOlmX2Or8qHAK9CSc6hlycS1Z8TZWsnC3NvINBa3+bc XQ/ACd8BdRmKAPNUJfcRKbk/PPhwisj0m/iwAJz1hSUl5z7WFfjE7XIru8EovWeekyUK CKlc79+L2rvSdVGCAqUOFzkpyXIrfpMy5ytqX/pK5WgBd4PSJCfhBag1lEHgamRkrS7S 7L6OQXh+pEQgE7vnMXWv20ULXizzqfH5aQ75/gcB1+L2vWSJ/o3DAsfGPk/QVVwnT8SL DolQC93oQjaRCRxmWykn8OJaO2Ug0FXWq1iqR1D0e4/kMzPCzAK/uVBcRc0Z7ISfN6X+ JJag== MIME-Version: 1.0 X-Received: by 10.180.186.99 with SMTP id fj3mr33892186wic.10.1429629232203; Tue, 21 Apr 2015 08:13:52 -0700 (PDT) Received: by 10.194.233.233 with HTTP; Tue, 21 Apr 2015 08:13:52 -0700 (PDT) In-Reply-To: References: <55350429.9060608@jive.com> Date: Tue, 21 Apr 2015 08:13:52 -0700 Message-ID: From: Ted Hardie To: Tim Panton Content-Type: multipart/alternative; boundary=001a11c2677c8bd01205143d7ec4 Archived-At: Cc: "rtcweb@ietf.org" , Guo-wei Shieh Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 15:13:56 -0000 --001a11c2677c8bd01205143d7ec4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 21, 2015 at 3:56 AM, Tim Panton wrote: > > > On 20 Apr 2015, at 14:50, Simon Perreault wrote: > > > > Interesting! > > > > Would a dual-stack client do the same procedure for IPv6 and offer both > > IPv4 and IPv6 candidates? Would a single IPv6 host candidate be > > enumerated, and would it be the one used to contact the STUN/TURN serve= r? > > We should _only_ send IPV6 candidates with temporary addresses, not the > ones derived from > the hardware mac address. > > Chrome currently _prefers_ temporary addresses but will send a hardware > one if > no temporary is available. > > T. > > =E2=80=8BJust for clarity, I assume you mean IPv6 address derived accordi= ng RFC 4941, right? Ted=E2=80=8B > > > > > > Tim Panton - Web/VoIP consultant and implementor > www.westhawk.co.uk > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c2677c8bd01205143d7ec4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 21, 2015 at 3:56 AM= , Tim Panton <tim@phonefromhere.com> wrote:

> On 20 Apr 2015, at 14:50, Simon Perreault <sperreault@jive.com> wrote:
>
> Interesting!
>
> Would a dual-stack client do the same procedure for IPv6 and offer bot= h
> IPv4 and IPv6 candidates? Would a single IPv6 host candidate be
> enumerated, and would it be the one used to contact the STUN/TURN serv= er?

We should _only_ send IPV6 candidates with temporary addresses, not = the ones derived from
the hardware mac address.

Chrome currently _prefers_ temporary addresses but will send a hardware one= if
no temporary is available.

T.

=E2=80=8BJust for clarity, I assume you mea= n IPv6 address derived according RFC 4941, right?

= Ted=E2=80=8B



=C2=A0





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



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

--001a11c2677c8bd01205143d7ec4-- From nobody Tue Apr 21 08:18: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 BA7F01ACE53 for ; Tue, 21 Apr 2015 08:18:52 -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, 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 aofmgjvTg-Dx for ; Tue, 21 Apr 2015 08:18:51 -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 EFDEB1ACE4C for ; Tue, 21 Apr 2015 08:18:50 -0700 (PDT) Received: (qmail 85313 invoked from network); 21 Apr 2015 15:18:49 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 11206 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 21 Apr 2015 15:18:49 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 4EDFA18A0ECB; Tue, 21 Apr 2015 16:18:41 +0100 (BST) Received: from [192.168.157.65] (unknown [192.67.4.66]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 34B6E18A0E49; Tue, 21 Apr 2015 16:18:41 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: tim panton In-Reply-To: Date: Tue, 21 Apr 2015 16:18:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3E254BCF-395C-479A-B63C-A8B76CF34C99@phonefromhere.com> References: <55350429.9060608@jive.com> To: Ted Hardie X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "rtcweb@ietf.org" , Guo-wei Shieh Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 15:18:52 -0000 > On 21 Apr 2015, at 16:13, Ted Hardie wrote: >=20 > On Tue, Apr 21, 2015 at 3:56 AM, Tim Panton = wrote: >=20 > > On 20 Apr 2015, at 14:50, Simon Perreault = wrote: > > > > Interesting! > > > > Would a dual-stack client do the same procedure for IPv6 and offer = both > > IPv4 and IPv6 candidates? Would a single IPv6 host candidate be > > enumerated, and would it be the one used to contact the STUN/TURN = server? >=20 > We should _only_ send IPV6 candidates with temporary addresses, not = the ones derived from > the hardware mac address. >=20 > Chrome currently _prefers_ temporary addresses but will send a = hardware one if > no temporary is available. >=20 > T. >=20 > =E2=80=8BJust for clarity, I assume you mean IPv6 address derived = according RFC 4941, right? Yes. OSX labels them ' autoconf temporary' Which is how I tend to think of them. T. From nobody Tue Apr 21 08:47: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 E58341ACE7E for ; Tue, 21 Apr 2015 08:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.276 X-Spam-Level: ** X-Spam-Status: No, score=2.276 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FAKE_REPLY_C=1.486, 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 n6AEmMf_ScTX for ; Tue, 21 Apr 2015 08:47:04 -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 A0FC01ACEDF for ; Tue, 21 Apr 2015 08:47:00 -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 t3LFkwUM004764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Apr 2015 17:46:58 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t3LFkwhQ004763 for rtcweb@ietf.org; Tue, 21 Apr 2015 17:46:58 +0200 Date: Tue, 21 Apr 2015 17:46:58 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150421154657.GA4071@lo.psyced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55352067.6070007@nostrum.com> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 15:47:06 -0000 On 20 April 2015 at 08:51, Adam Roach wrote: > [...] And I'm not okay with taking an across-the-board service > degradation for all users based on something that the overwhelming majority > of them won't care about. Okay, let's just for a minute make sure that even if it only few are affected, these few are not facing a threat of life or death. 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. -- E-mail is public! Talk to me in private using Tor. torify telnet loupsycedyglgamf.onion DON'T SEND ME irc://loupsycedyglgamf.onion:67/lynX PRIVATE EMAIL http://loupsycedyglgamf.onion/LynX/ OR FACEBOOGLE From nobody Tue Apr 21 10: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 6DE971A1A52 for ; Tue, 21 Apr 2015 10:08:34 -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_12=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 y0ofjiiWC2Rc for ; Tue, 21 Apr 2015 10:08:33 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::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 AF7B21A005A for ; Tue, 21 Apr 2015 10:08:33 -0700 (PDT) Received: by iecrt8 with SMTP id rt8so18780028iec.0 for ; Tue, 21 Apr 2015 10:08: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:date:message-id:subject:from:to :cc:content-type; bh=0pFg9jB3fBgaPEPcjUtsFgl9fFnPlZ1mTQIbRMm7RPU=; b=Ev4/72ryhOis3fNDVYJ04Zq6jvC1shxWors4qqreXhiQAZvB2ABJXW7uYjkLfwmyi5 tmAP5itKxnInOB81nkwmhCYpkm5d7iroLFTLmZyJmfZn31VpJWebXW36czlHyhuqeEWM i/dFvdkmX6RZ1j2twp7tKmudyj4xPMIVa1iRGHu8yViLp2q91swwnxra+YpaNvb5qW9L Ltvhlt2mEoGImlmUg8P2BtO72DgnbBHV8mHYI32Nbortl6tLOyGuLa3QGtBCFxIsC8MO h3quMJ1mMelfr/dVWjutFeqVZjBnEDHdJF/avGgsM2wqd3BPwoklFsNyoPnh8eUVW0JX alcQ== MIME-Version: 1.0 X-Received: by 10.50.29.40 with SMTP id g8mr29325064igh.41.1429636113270; Tue, 21 Apr 2015 10:08:33 -0700 (PDT) Received: by 10.64.76.106 with HTTP; Tue, 21 Apr 2015 10:08:33 -0700 (PDT) In-Reply-To: <55365D4A.30507@ericsson.com> References: <551A902A.9080402@alvestrand.no> <55365D4A.30507@ericsson.com> Date: Tue, 21 Apr 2015 10:08:33 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 17:08:34 -0000 On 21 April 2015 at 07:23, Magnus Westerlund wrote: > Sorry, but I specified it as RTP Payload bit-rate, which would exclude > header extension. My thought would be to allow for 64 kbps codec plus > some payload format overhead. I think that specifying this in terms of b=AS is cleaner. From nobody Tue Apr 21 15:58: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 BB69B1B2DFB for ; Tue, 21 Apr 2015 15:58:56 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 g1KKL9QT9fGv for ; Tue, 21 Apr 2015 15:58:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7FDE1B2DFF for ; Tue, 21 Apr 2015 15:58:54 -0700 (PDT) Received: from netb.Speedport_W_723V_1_36_000 ([84.189.12.53]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lyj4F-1ZMiuy2HNn-0164lA; Wed, 22 Apr 2015 00:58:51 +0200 From: Bjoern Hoehrmann To: Martin Thomson Date: Wed, 22 Apr 2015 00:58:54 +0200 Message-ID: References: <55352067.6070007@nostrum.com> <5535496C.4000809@alvestrand.no> <553568AE.3040706@alvestrand.no> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:hbWGWN9omNBtHqDEsTWSFHIhjXuZyxG1dxpjXs62Tyi2ZO05V0w i7SwQR3qbvCQaqUiIkAPOsa9OMfC/77z1SxeKklpkYOc1lzJhqm9v5a+UzFlsTMtDyNnyqU MeEvI3QDwHo8g30kit+z/KIqPbr7qSibQ/0kh93LEVCIyOll2Zs+4EzAwqZduOFGzB4vTFq ozFDotjBJ1dA1+7HAPQ1g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 22:58:56 -0000 * Martin Thomson wrote: >Sorry, I thought this was well understood. > >First party: what you see in the funny bar at the top that no one pays >attention to >Third party: those that provide the images you see If being "first party" comes with any sort of potential commercial ad- vantage, you can be sure that plenty of people will argue their stuff is first party stuff, regardless how ridiculous the argument may be. See e.g. W3C's "Tracking Protection" list archives. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de From nobody Tue Apr 21 16:19: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 806EB1B2E57 for ; Tue, 21 Apr 2015 16:19:12 -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 1ck5hMl2zk_q for ; Tue, 21 Apr 2015 16:19:11 -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 AB3D51B2E55 for ; Tue, 21 Apr 2015 16:19:10 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so28742652ied.1 for ; Tue, 21 Apr 2015 16:19:10 -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=x/+OTN52vqXylK1X1mbsoITK2OkOLKWqC3lZebfUJLw=; b=OoW2OJ6gTINmUiHz/0fyktXYb9ElpYIQD/eF2iOCxk0WVgzyJNf6gPgdThWlX+s9d5 ypajKzBhElAVLjFLc4A6/groAwAUUopkDSQlPJlYFzXvt/cH8Tx83TYAUXneUdDAyTDl BehZP9ckpUqdC8JOsb04lUXzrRq8u9MenCU44q0vaBrckXvrMsTM6WYR9XjdHMVOKCa3 0jkxON0WoEMk6ifHOLk+yF+WvWh1Oa77bRjX5HB51ocWFYHLzqW3pkJ7eNNHJNsvClIX B41jWdvchRbnS82lBrHP7tPvQtxNWb1bbzcyEb/IHiBvyMiI/T1gNFd3uEyGMWArWUqz Rbpw== MIME-Version: 1.0 X-Received: by 10.50.143.38 with SMTP id sb6mr576780igb.44.1429658350145; Tue, 21 Apr 2015 16:19:10 -0700 (PDT) Received: by 10.64.76.106 with HTTP; Tue, 21 Apr 2015 16:19:10 -0700 (PDT) In-Reply-To: References: <55352067.6070007@nostrum.com> <5535496C.4000809@alvestrand.no> <553568AE.3040706@alvestrand.no> Date: Tue, 21 Apr 2015 16:19:10 -0700 Message-ID: From: Martin Thomson To: Bjoern Hoehrmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 23:19:12 -0000 On 21 April 2015 at 15:58, Bjoern Hoehrmann wrote: > If being "first party" comes with any sort of potential commercial ad- > vantage, you can be sure that plenty of people will argue their stuff is > first party stuff I don't think arguing has any material effect here. Your origin is either displayed in the address bar (presumably because you served the primary HTML) or it is not. From nobody Tue Apr 21 23:40: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 CA56B1B31C1 for ; Tue, 21 Apr 2015 23:40:27 -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 IIoFqI8b1MM1 for ; Tue, 21 Apr 2015 23:40:25 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id AC4AF1B31B9 for ; Tue, 21 Apr 2015 23:40:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 401437C380D; Wed, 22 Apr 2015 08:40:24 +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 VeMp365I7R1B; Wed, 22 Apr 2015 08:40:22 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id A4AEE7C0323; Wed, 22 Apr 2015 08:40:22 +0200 (CEST) Message-ID: <55374256.7020006@alvestrand.no> Date: Wed, 22 Apr 2015 08:40:22 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Martin Thomson , Bjoern Hoehrmann References: <55352067.6070007@nostrum.com> <5535496C.4000809@alvestrand.no> <553568AE.3040706@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: [rtcweb] Effectiveness of first-party vs third-party distinction (Re: New proposal for IP address handling in WebRTC) 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, 22 Apr 2015 06:40:28 -0000 Changing the subject, since we're off at a tangent.. Den 22. april 2015 01:19, skrev Martin Thomson: > On 21 April 2015 at 15:58, Bjoern Hoehrmann wrote: >> If being "first party" comes with any sort of potential commercial ad- >> vantage, you can be sure that plenty of people will argue their stuff is >> first party stuff > > I don't think arguing has any material effect here. Your origin is > either displayed in the address bar (presumably because you served the > primary HTML) or it is not. > The standard trick (ten years ago when I last looked seriously at least) for advertisers being first-party is that they serve the shell of the advert off a piece of Javascript in your document, and then they pull in the real content by JS-includes and dynamically built HTML. All first party. The other trick (which only works with large hosting companies, and only works to get around cookie restrictions, not same-origin policy, I believe) is to serve the embedded content from a subdomain of the host's domain that is served off the advertiser's servers. It's not so much what they argue, it's what the parties agree to do as a result of the argument. From nobody Wed Apr 22 05: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 117421B3523 for ; Wed, 22 Apr 2015 05:23:02 -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_12=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 o41maPVsLADH for ; Wed, 22 Apr 2015 05:23:00 -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 CFD971B352B for ; Wed, 22 Apr 2015 05:22:54 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-54-5537929cf82d Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EC.AA.19337.C9297355; Wed, 22 Apr 2015 14:22:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.210.2; Wed, 22 Apr 2015 14:22:52 +0200 Message-ID: <5537929C.5000108@ericsson.com> Date: Wed, 22 Apr 2015 14:22:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Martin Thomson References: <551A902A.9080402@alvestrand.no> <55365D4A.30507@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvje7cSeahBkfauCw+rP/BaHHtzD9G i7X/2tkdmD12zrrL7rFkyU8mj8vnPzIGMEdx2aSk5mSWpRbp2yVwZRw+fYGt4BBnxfqNP5ka GB+xdzFyckgImEg0nV7LCmGLSVy4t56ti5GLQ0jgKKPE/XvnwIqEBJYzSpxanQNi8wpoS5zY sB+sgUVAVWJey1dGEJtNwELi5o9GNhBbVCBKYuLXQywQ9YISJ2c+AbNFBHQlFp19ADSTg4NZ wEPi9rJkkLCwgK9Ew6Yv7BB7n7JLvLi3ghWkhlMgUGLBNU6Ick2J9bv0QcqZBeQlmrfOZoa4 TFuioamDdQKj4Cwky2YhdMxC0rGAkXkVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmDwHtzy W3UH4+U3jocYBTgYlXh4H1iYhwqxJpYVV+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgVF205prwgeNepTDntz+cXPlPu9qebEdZ6yfbw3Ut+gLc9737X3EBP8CCXaW /qCtsYdza3x+VUZunpLeMeO8tSbnK74lm6y1lWMfMxwW2X3n6N1lrJ8TAkJSfl23uhwbcU+t 33pKbGVv/5MZfTfzF1kxfxJatfPj3t+J7CecRG1Xs/bkfjnZ363EUpyRaKjFXFScCABBINTb PwIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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, 22 Apr 2015 12:23:02 -0000 Martin Thomson skrev den 2015-04-21 19:08: > On 21 April 2015 at 07:23, Magnus Westerlund > wrote: >> Sorry, but I specified it as RTP Payload bit-rate, which would exclude >> header extension. My thought would be to allow for 64 kbps codec plus >> some payload format overhead. > > > I think that specifying this in terms of b=AS is cleaner. > Are you meaning considering the rate for the whole packet, i.e. IP+UDP+RTP+Payload rate, or as your own implementation calculates b=AS? The later is very undefined, as there are no defined timescale for which one calculates b=AS. Sure, for PCM audio this is straight forward, but for anything that is variable rate it is not. 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 ---------------------------------------------------------------------- From nobody Wed Apr 22 05:31: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 03D561B3561 for ; Wed, 22 Apr 2015 05:31:25 -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 Mv3iCpSMiw4g for ; Wed, 22 Apr 2015 05:31:23 -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 7BC051B356C for ; Wed, 22 Apr 2015 05:31:13 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-34-5537948f27ee Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5A.0C.19337.F8497355; Wed, 22 Apr 2015 14:31:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.210.2; Wed, 22 Apr 2015 14:31:10 +0200 Message-ID: <5537948F.6040007@ericsson.com> Date: Wed, 22 Apr 2015 14:31:11 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Emil Ivov References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvjW7/FPNQg30zjSyWvzzBaLFm5wQW i47JbBbXzvxjtFj7r53dgdVjyu+NrB7T7t9n89g56y67x5IlP5k8/r8JDGCN4rJJSc3JLEst 0rdL4MpoX/ieseCvUMX8NeYNjLP5uxg5OSQETCSmb/rGDmGLSVy4t56ti5GLQ0jgKKNE1/L/ UM5yRok9N/vAqngFtCWWvz3B3MXIwcEioCoxvYcFJMwmYCFx80cjG4gtKhAlMfHrIRaIckGJ kzOfgNkiAvIS3W2LmEBmMgusYJRo3PuWCSQhLOAr0bDpCzvEsl/MEkse7mMESXAKBEr8bD3N DrKMWUBTYv0ufZAwM9Cg5q2zmUFsIaB7Gpo6WCcwCs5Csm8WQscsJB0LGJlXMYoWpxYn5aYb GeulFmUmFxfn5+nlpZZsYgQG+cEtv1V3MF5+43iIUYCDUYmH94GFeagQa2JZcWXuIUZpDhYl cV4740MhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgn5vP+tJevFO5Jimm2LXt4ee7S/oVv BHjt10ws1p6ePG1FJ6ePtPtPxvZNuv/8pom5v7q656Wr9/4ZTxO9NTZ8ki+cFXKUjd9McZ2b 818DpsfT6g/13N5wQ8jJ5D5TRGJdcWDIcoMX66zui6/fc0SO8wNjqN2Fuaciddcf/5m2Suz4 BJbHIeuVWIozEg21mIuKEwGbuPkuUwIAAA== Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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, 22 Apr 2015 12:31:25 -0000 Emil Ivov skrev den 2015-04-21 12:10: > On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund > wrote: >> Emil Ivov skrev den 2015-03-30 23:00: >> >>> Makes sense to me! (and of course, any number would make sense here >>> given how superfluous circuit breakers are in the presence of consent >>> checks) >>> >> >> I think you are quite wrong here. The circuit breaker is there to stop >> persistent congestion. I think you are likely to get your consent checks >> through in sufficient frequency to maintain consent, but have totally >> crappy audio due to packet loss in the 10% range. > > I am going to be *very* upset if my browser drops a call because of > 10% packet loss. I regularly have calls in hotel networks with up to > 20%+ regular packet loss and still enjoy productive conversations > thanks to FEC and PLC. Yes, with FEC. And I pulled 10% out of hat. I should of course calculated the 10* TCP rate for some typical RTT to determine if the circuit breaker would fire or not. But, as you already discussed, the point is that your network usage is grossly unfair and the goodput at 20% loss is substantially reduced, thus quite far along into congestion collapse. > >> So please don't confuse the purposes of these mechanisms. > > I assure you I am not. One actually serves a purpose as MTI in webrtc > the other doesn't (which is why no one will implement it). Okay, but that was my interpretation of what you wrote. If you believe that it will not be implemented, fine. I am actually fine with it as long as the implementation does have some adaptation mechanism. But, from a specification point of view we did need a stop gap. I think the progress in RMCAT is clear on that. I do note that especially when one adds FEC, one do need adaptation. One cant' use ones redundancy to steam role all other flows sharing a congested bottleneck. 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 ---------------------------------------------------------------------- From nobody Wed Apr 22 08:29: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 6395E1AC3C0 for ; Wed, 22 Apr 2015 08:29:24 -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 c9mYT34pvXMo for ; Wed, 22 Apr 2015 08:29:22 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6FE1AC3C4 for ; Wed, 22 Apr 2015 08:29:21 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 18E4AC94A9; Wed, 22 Apr 2015 11:29:09 -0400 (EDT) Date: Wed, 22 Apr 2015 11:29:09 -0400 From: John Leslie To: Magnus Westerlund Message-ID: <20150422152908.GF63465@verdi> References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <5537948F.6040007@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5537948F.6040007@ericsson.com> User-Agent: Mutt/1.4.1i Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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, 22 Apr 2015 15:29:24 -0000 Magnus Westerlund wrote: > > Emil Ivov skrev den 2015-04-21 12:10: >> >> I am going to be *very* upset if my browser drops a call because of >> 10% packet loss. I regularly have calls in hotel networks with up to >> 20%+ regular packet loss and still enjoy productive conversations >> thanks to FEC and PLC. > > Yes, with FEC. We can take Emil at his word that 10% packet loss does not imply "crappy audio" to at least some users. However, Forward Error Correction _is_ leading us down the path to congestion collapse: in that the reaction to packet loss is to send more bits. :^( How far down that path is an open question... From my experience, 20% packet loss at MAE-East, for example, was too far. But we seem to be talking 10-20% at a hotel choke-point. That's a different story. The damage is mostly limited to hotel customers. In all likelihood, the _hotel_ would prefer to punish Emil -- but that's not _our_ job. > And I pulled 10% out of hat. I should of course [have] calculated > the 10* TCP rate for some typical RTT to determine if the circuit > breaker would fire or not. Packet loss is an easier metric for us to understand. > But, as you already discussed, the point is that your network usage is > grossly unfair... I doubt folks in Emil's position would agree that 10*TCP is "grossly unfair". (4*TCP is normal in web-browsing, and IW10 sends a lot more bits...) But perhaps they could agree that 20% packet loss is "too far" down the road to congestion collapse. (I'm pretty sure they'd agree that 10% packet loss is something the hotel "really-should" fix; and I suspect we should stay out of that tussle.) >... I am actually fine with it as long as the implementation does > have some adaptation mechanism. But, from a specification point of > view we did need a stop gap. I think the progress in RMCAT is clear > on that. > > I do note that especially when one adds FEC, one do need adaptation. > One can't use ones redundancy to steam roll all other flows sharing > a congested bottleneck. My intuition says that 72 kbps goodput must not be guaranteed in the presence of 20% packet loss -- but that dropping to 0 kbps should not be the only reduction option. YMMV... -- John Leslie From nobody Wed Apr 22 08:36: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 1F7551A6F01 for ; Wed, 22 Apr 2015 08:36:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 NYJhZnQ9C-8x for ; Wed, 22 Apr 2015 08:36:45 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE381A049A for ; Wed, 22 Apr 2015 08:36:44 -0700 (PDT) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 22 Apr 2015 11:36:38 -0400 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0210.002; Wed, 22 Apr 2015 11:36:37 -0400 From: Gaelle Martin-Cocher To: "Rauschenbach, Uwe (Nokia - DE/Munich)" , "ext Harald Alvestrand" , Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways Thread-Index: AQHQeHFa5bXT8KfOaES0di1Z0MxN+Z1SiFYAgAJtjACABB1wYA== Date: Wed, 22 Apr 2015 15:36:37 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> References: , <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-alvestrand-rtcweb-gateways@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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, 22 Apr 2015 15:36:47 -0000 Dear all, I do have some concerns with this proposal. >From https://www.ietf.org/mail-archive/web/rtcweb/current/msg13885.html I was under impression that the gateway would be an informational draft and= there was no desire to specify conformance requirements. The current text describes high level functions that can be expected from a= gateway but does not define clearly what would be required to conform to.= =20 If the intend of the draft is to specify conformance requirements (first se= ntence of the abstract) there could be more requirements to relax and the c= urrent requirements would need to be define more clearly.=20 Is it the intend? If it is, here are some examples: While the WebRTC Gateway is described in the abstract (but not only, see se= ction 1) as "a class of WebRTC-compatible endpoints called "WebRTC gateways" ", section 2 states= that WebRTC gateway are "expected to conform to the requirements for WebRT= C non-browsers in [I-D.ietf-rtcweb-overview], with the exceptions defined i= n this section" Wouldn't it be clearer to just define the WebRTC gateway from the WebRTC no= n-browser rather than from an unspecified WebRTC-compatible endpoint?=20 It might provide a better understanding of what the gateway should be confo= rming to. Requirements in 2, either: - are clear: e.g. the gateway MUST support DTLS-SRTP=20 - describe what the gateway MAY NOT support....see second to last paragraph= =20 - or leave some ambiguity: The gateway does not have to do X (e.g. full ICE= ); so it may do Y (e.g. ICE-Lite).=20 Playing devil's advocate: can there be a gateway doing yet something else?= =20 What would it conform to? =20 Shouldn't the requirement be reworded to state what the gateway MAY or SHAL= L do/support.... and conform to? Section 1.1 and 1.2 seems unclear if meant to belong to a conformance requi= rements draft. =20 It is unclear to me if the purpose of the draft is to define conformance re= quirements for WebRTC gateway, or is to focus on relaxing some requirements= for gateways as per section 2, or is an informational description of what = can be expected from a WebRTC 'compatible' gateway. =20 Sincerely, Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Rauschenbach, Uw= e (Nokia - DE/Munich) Sent: Sunday, April 19, 2015 2:52 PM To: ext Harald Alvestrand; Sean Turner; rtcweb@ietf.org Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateway= s +1 for adoption. The same question that Harald raised came to my mind - there was another ad= option call end of last year with a lot of support (https://www.ietf.org/ma= il-archive/web/rtcweb/current/msg14050.html). Kind regards, Uwe ________________________________________ Von: rtcweb [rtcweb-bounces@ietf.org]" im Auftrag von "ext Harald= Alvestrand [harald@alvestrand.no] Gesendet: Samstag, 18. April 2015 07:46 An: Sean Turner; rtcweb@ietf.org Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org Betreff: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateway= s On 04/16/2015 08:15 PM, Sean Turner wrote: > All, > > There's been some interest expressed in having http://datatracker.ietf.or= g/doc/draft-alvestrand-rtcweb-gateways/ adopted as an RTCWeb WG item. Plea= se respond to say whether you support adoption of this work as a working gr= oup work item and whether you will participate in the discussion. If you = are opposed to this draft becoming a WG document, please say so (and say wh= y). Please have your response in by 20150423 23:59 UTC. > > Thanks in advance! > > spt Naturally, I support adoption. Question: Is this a repeat of the exercise on which Cullen reported consens= us for adoption in December 2014, or is this a side effect of starting foma= l tracking of adoption status? -- Surveillance is pervasive. Go Dark. _______________________________________________ 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 Apr 22 09: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 6E6E01B3761 for ; Wed, 22 Apr 2015 09:19:52 -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 bOH2DWMnUEID for ; Wed, 22 Apr 2015 09:19:49 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBFA1B3764 for ; Wed, 22 Apr 2015 09:19:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 991447C3DDA; Wed, 22 Apr 2015 18:19: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 vSYqncgEAuC5; Wed, 22 Apr 2015 18:19:43 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id BF9917C3DD9; Wed, 22 Apr 2015 18:19:43 +0200 (CEST) Message-ID: <5537CA1F.1060209@alvestrand.no> Date: Wed, 22 Apr 2015 18:19:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Gaelle Martin-Cocher , "Rauschenbach, Uwe (Nokia - DE/Munich)" , Sean Turner , "rtcweb@ietf.org" References: , <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-alvestrand-rtcweb-gateways@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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, 22 Apr 2015 16:19:52 -0000 Den 22. april 2015 17:36, skrev Gaelle Martin-Cocher: > Dear all, > > I do have some concerns with this proposal. > From https://www.ietf.org/mail-archive/web/rtcweb/current/msg13885.html > I was under impression that the gateway would be an informational draft and there was no desire to specify conformance requirements. > > The current text describes high level functions that can be expected from a gateway but does not define clearly what would be required to conform to. > If the intend of the draft is to specify conformance requirements (first sentence of the abstract) there could be more requirements to relax and the current requirements would need to be define more clearly. > Is it the intend? I have not updated the intro - I think feedback was reasonably clear that an informational document was wanted, we want to give advice, but not to dictate what implementations do. > > If it is, here are some examples: > While the WebRTC Gateway is described in the abstract (but not only, see section 1) as "a class of > WebRTC-compatible endpoints called "WebRTC gateways" ", section 2 states that WebRTC gateway are "expected to conform to the requirements for WebRTC non-browsers in [I-D.ietf-rtcweb-overview], with the exceptions defined in this section" > > Wouldn't it be clearer to just define the WebRTC gateway from the WebRTC non-browser rather than from an unspecified WebRTC-compatible endpoint? > It might provide a better understanding of what the gateway should be conforming to. > > Requirements in 2, either: > - are clear: e.g. the gateway MUST support DTLS-SRTP > - describe what the gateway MAY NOT support....see second to last paragraph > - or leave some ambiguity: The gateway does not have to do X (e.g. full ICE); so it may do Y (e.g. ICE-Lite). > Playing devil's advocate: can there be a gateway doing yet something else? > What would it conform to? > > Shouldn't the requirement be reworded to state what the gateway MAY or SHALL do/support.... and conform to? > > Section 1.1 and 1.2 seems unclear if meant to belong to a conformance requirements draft. > > > It is unclear to me if the purpose of the draft is to define conformance requirements for WebRTC gateway, or is to focus on relaxing some requirements for gateways as per section 2, or is an informational description of what can be expected from a WebRTC 'compatible' gateway. > > > Sincerely, > Gaëlle > > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Rauschenbach, Uwe (Nokia - DE/Munich) > Sent: Sunday, April 19, 2015 2:52 PM > To: ext Harald Alvestrand; Sean Turner; rtcweb@ietf.org > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways > > +1 for adoption. > > The same question that Harald raised came to my mind - there was another adoption call end of last year with a lot of support (https://www.ietf.org/mail-archive/web/rtcweb/current/msg14050.html). > > Kind regards, > Uwe > > ________________________________________ > Von: rtcweb [rtcweb-bounces@ietf.org]" im Auftrag von "ext Harald Alvestrand [harald@alvestrand.no] > Gesendet: Samstag, 18. April 2015 07:46 > An: Sean Turner; rtcweb@ietf.org > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > Betreff: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways > > On 04/16/2015 08:15 PM, Sean Turner wrote: >> All, >> >> There's been some interest expressed in having http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ adopted as an RTCWeb WG item. Please respond to say whether you support adoption of this work as a working group work item and whether you will participate in the discussion. If you are opposed to this draft becoming a WG document, please say so (and say why). Please have your response in by 20150423 23:59 UTC. >> >> Thanks in advance! >> >> spt > Naturally, I support adoption. > > Question: Is this a repeat of the exercise on which Cullen reported consensus for adoption in December 2014, or is this a side effect of starting fomal tracking of adoption status? > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > 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 Apr 22 10:19: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 498221B3895 for ; Wed, 22 Apr 2015 10:19:12 -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_12=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 TfRWTgfVWwUv for ; Wed, 22 Apr 2015 10:19:11 -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 6BCDE1B3884 for ; Wed, 22 Apr 2015 10:19:03 -0700 (PDT) Received: by ykep21 with SMTP id p21so27770755yke.3 for ; Wed, 22 Apr 2015 10:19:02 -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=xbTchzAJ3kSVgVzTS8jHvKx2cW0fYaryCyAT3smzsp8=; b=Rk79MB/L930MaNNOMBx8LhMir2iS8D1kr42Bm8zraX/V94DbaKPLNPc4a2xRpS4xZO pVNFrTGCd0CvFw88/cd4Bsi+ujO5Ts1zaIt9HEgNXlwwgPx5hOzcmoMGEo+w/AgBVua2 626uPF7gZ+z3VlD7BINOR7mgGiww4ZUd64tiuARCLDscsXy/wJYDjQWxY2yAXVLqCOzb zDOdlTKG67Eg5f4i2wAz4ZtoTnujtymOC1Ss+/++jMMZo8STGs2uHY0VHyzI6TqCI3VB /c5BIbZUQarMz6StualH5zwsCbCqvSJexApVutb5vsOau2ISHsWjJ8p6jNBXTytHUNHI IcZQ== MIME-Version: 1.0 X-Received: by 10.236.16.138 with SMTP id h10mr22576362yhh.93.1429723142789; Wed, 22 Apr 2015 10:19:02 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Wed, 22 Apr 2015 10:19:02 -0700 (PDT) In-Reply-To: <5537929C.5000108@ericsson.com> References: <551A902A.9080402@alvestrand.no> <55365D4A.30507@ericsson.com> <5537929C.5000108@ericsson.com> Date: Wed, 22 Apr 2015 10:19:02 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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, 22 Apr 2015 17:19:12 -0000 On 22 April 2015 at 05:22, Magnus Westerlund wrote: > Are you meaning considering the rate for the whole packet, i.e. > IP+UDP+RTP+Payload rate, or as your own implementation calculates b=AS? > The later is very undefined, as there are no defined timescale for which > one calculates b=AS. Sure, for PCM audio this is straight forward, but > for anything that is variable rate it is not. That sounds like a problem worth solving to me. From nobody Wed Apr 22 11:44: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 1C63F1AD376 for ; Wed, 22 Apr 2015 11:44:57 -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_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 YnDyiH86Uzb2 for ; Wed, 22 Apr 2015 11:44:55 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6684A1AD373 for ; Wed, 22 Apr 2015 11:44:55 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.241.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A26E5509BF; Wed, 22 Apr 2015 14:44:53 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Cullen Jennings In-Reply-To: <55365D4A.30507@ericsson.com> Date: Wed, 22 Apr 2015 12:44:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <151887E0-B94D-4FC7-92FD-3C150C343C1B@iii.ca> References: <551A902A.9080402@alvestrand.no> <55361DCA.7000101@e ricsson.com> <55365D4A.30507@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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, 22 Apr 2015 18:44:57 -0000 > On Apr 21, 2015, at 8:23 AM, Magnus Westerlund = wrote: >=20 > Cullen Jennings skrev den 2015-04-21 14:42: >>=20 >> That sounds workable but I think the 72 kbps is a bit low when you >> consider header extensions for audio level and other things. I'd be >> more comfortable with something closer to100 kbps. Given the >> granularity of circuit breakers I don't think 100 vs 72 is going to >> make circuit breaker not work. >=20 > Sorry, but I specified it as RTP Payload bit-rate, which would exclude > header extension. My thought would be to allow for 64 kbps codec plus > some payload format overhead. Ah, OK, that works. I don't care how it get specified as long as it = allows that use case.=20 >=20 > However, I have to ask if really audio level header extensions and > legacy audio endpoint that don't send RTCP being a likely combination? Yes, unfortunately, very likely >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- >=20 >=20 From nobody Wed Apr 22 15:32: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 46FFB1B2C3F for ; Wed, 22 Apr 2015 15:32:16 -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 adljTJ7v205T for ; Wed, 22 Apr 2015 15:32:14 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8221B2CDB for ; Wed, 22 Apr 2015 15:31:54 -0700 (PDT) Received: from [81.187.2.149] (port=35430 helo=[192.168.0.18]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yl3BP-0003GV-C8; Wed, 22 Apr 2015 23:31:52 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_9A7091E3-8830-4EDE-B4DB-8608F26EE6B7" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Wed, 22 Apr 2015 23:31:45 +0100 Message-Id: References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> To: Emil Ivov X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Endpoints that don't support RTCP 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, 22 Apr 2015 22:32:16 -0000 --Apple-Mail=_9A7091E3-8830-4EDE-B4DB-8608F26EE6B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 Apr 2015, at 11:53, Emil Ivov wrote: > Hey Harald, >=20 > On Tuesday, April 21, 2015, Harald Alvestrand = wrote: > Den 21. april 2015 12:10, skrev Emil Ivov: > > On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund > > wrote: > >> Emil Ivov skrev den 2015-03-30 23:00: > > So as I've mentioned before, I can see circuit breakers as an useful > > recommendation for some applications but they are definitely = redundant > > in the context of WebRTC. >=20 > The purpose of circuit breakers is not to save the users from = themselves. >=20 > It is to save the network from the users - to make sure that if WebRTC > users cause persistent congestion in the network, that congestion will > eventually go away. >=20 > Sure, I completely understand the intention. I just think CBs are a = very crude attempt of achieving it. Also somewhat redundant in the = context of WebRTC. >=20 > I have repeatedly asked for data that shows how CBs are beneficial in = large-scale diverse deployments and so far I haven't seen any (I have = even been asked by Colin to provide data that they don't work ... which = is quite absurd :) ) The benefit is to the network, not to your application, of course.=20 And yes, I am looking for cases where the circuit breaker interferes = with real applications, because I want to understand if the circuit = breaker is being over-sensitive, or if the applications are being = unreasonable. > This is the same purpose as the AIMD algorithm in TCP (which is not > particularly beneficial for each individual user). >=20 > Well ... it isn't really the same though is it. AIMD doesn't = sadistically kill your connection at the first whiff of trouble ... :) = ... it just MDs your bandwidth usage. If the circuit breaker is working correctly, it won't "kill your = connection at the first whiff of trouble". It's designed to stop flows = that cause long-term and persistent congestion. You earlier said: > I am going to be *very* upset if my browser drops a call because of > 10% packet loss. I regularly have calls in hotel networks with up to > 20%+ regular packet loss and still enjoy productive conversations > thanks to FEC and PLC. Give us some numbers: what packet size, data rate, and approximate RTT = are being used for these calls with 10-20% packet loss, so we can = evaluate if the circuit breaker will impact them? --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_9A7091E3-8830-4EDE-B4DB-8608F26EE6B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On 21 = Apr 2015, at 11:53, Emil Ivov <emcho@jitsi.org> = wrote:
Hey Harald,

On Tuesday, = April 21, 2015, Harald Alvestrand <harald@alvestrand.no> = wrote:
Den 21. april 2015 = 12:10, skrev Emil Ivov:
> On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund
> <magnus.westerlund@ericsson.com> = wrote:
>> Emil Ivov skrev den 2015-03-30 23:00:
> So as I've mentioned before, I can see circuit breakers as an = useful
> recommendation for some applications but they are definitely = redundant
> in the context of WebRTC.

The purpose of circuit breakers is not to save the users from = themselves.

It is to save the network from the users - to make sure that if = WebRTC
users cause persistent congestion in the network, that congestion = will
eventually go away.

Sure, I completely = understand the intention. I just think CBs are a very crude attempt = of achieving it. Also somewhat redundant in the context of = WebRTC.

I have repeatedly asked for data = that shows how CBs are beneficial in large-scale = diverse deployments and so far I haven't seen any (I have even been = asked by Colin to provide data that they don't work ... which is = quite absurd :) )

The benefit is = to the network, not to your application, of = course. 

And yes, I am looking for cases = where the circuit breaker interferes with real applications, because I = want to understand if the circuit breaker is being over-sensitive, or if = the applications are being unreasonable.

This is the same purpose as the AIMD algorithm in TCP (which is not
particularly beneficial for each individual user).

Well ... it isn't really the same = though is it. AIMD doesn't sadistically kill your connection at the = first whiff of trouble ... :) ... it just MDs your bandwidth = usage.

If the circuit breaker is = working correctly, it won't "kill your connection at the first whiff of = trouble". It's designed to stop flows that cause long-term and = persistent congestion.

You earlier = said:

I am going to be *very* = upset if my browser drops a call because of
10% packet loss. I regularly have calls in hotel = networks with up to
20%+ regular packet loss and still enjoy = productive conversations
thanks to FEC and = PLC.

Give us some numbers: what packet size, data = rate, and approximate RTT are being used for these calls with 10-20% = packet loss, so we can evaluate if the circuit breaker will impact = them?



-- 
Colin Perkins

<= /div>


= --Apple-Mail=_9A7091E3-8830-4EDE-B4DB-8608F26EE6B7-- From nobody Wed Apr 22 15:44: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 C76A31B2C65 for ; Wed, 22 Apr 2015 15:44:21 -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 BNi_9qKvHYgn for ; Wed, 22 Apr 2015 15:44:20 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5D61B3AE5 for ; Wed, 22 Apr 2015 15:44:20 -0700 (PDT) Received: from [81.187.2.149] (port=39500 helo=[192.168.0.18]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yl3NR-0004AZ-IZ; Wed, 22 Apr 2015 23:44:18 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <553621A8.5000400@alvestrand.no> Date: Wed, 22 Apr 2015 23:44:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7B9A5F8B-5269-4CB3-8741-976AB7BAA9C6@csperkins.org> References: <551A902A.9080402@alvestrand.no> <55361DCA.7000101@ericsson.com> <553621A8.5000400@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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, 22 Apr 2015 22:44:21 -0000 On 21 Apr 2015, at 11:08, Harald Alvestrand = wrote: > Den 21. april 2015 11:52, skrev Magnus Westerlund: >> Hi, >>=20 >> I think I have a more specific proposal of how to deal with this case >> regarding the circuit breakers and legacy peer end-point that don't = send >> RTCP. I think it is important that we consider these legacy = gatewaying >> cases. Unfortunately there appear to be a lot of audio RTP senders = that >> don't send RTCP. >>=20 >> Proposal: >>=20 >> In case circuit breaker #2 RTCP Timeout is triggered and; >> - No RTCP at all has been received; >> - This endpoint neither sends nor receive more than 72 kbps of RTP >> payload data on average over a 5 second window per direction; >>=20 >> then this triggering of the circuit breaker MAY be ignored. This = would >> be done if it is desired to support legacy RTP sender that lacks RTCP >> implementations. >>=20 >>=20 >>=20 >> The motivation for the above formulation is really to make it clear = that >> this is only for legacy, and not create a situation where ignoring = the >> circuit breaker is okay, even if RTCP is being received, just because >> one are in a really low-rate situation. >>=20 >> I wonder if the above should go into the RTP usage or into the = circuit >> breaker document itself? >=20 >=20 > I think it belongs to advice on gatewaying, actually - and that = gateways > should be prepared to do RTCP synthesis in this situation. >=20 > Perpetuating tolerance for the broken behavior of ignoring "MUST send > RTCP" seems like a path that doesn't lead to getting rid of the = behavior > in the end. I tend to agree: this seems like something where the gateway ought to = handle the interoperability, and synthesise appropriate RTCP.=20 Or, if that's really too onerous, tie into some other consent check that = can indicate that the flow is still wanted and not causing problems. --=20 Colin Perkins https://csperkins.org/ From nobody Wed Apr 22 17:15: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 B8F671B2BF2 for ; Wed, 22 Apr 2015 17:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 kXusKg53xIGf for ; Wed, 22 Apr 2015 17:15:07 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::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 D53501B2BE8 for ; Wed, 22 Apr 2015 17:15:00 -0700 (PDT) Received: by iejt8 with SMTP id t8so49980483iej.2 for ; Wed, 22 Apr 2015 17:14:59 -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=3jZiIKDEVhj4tU9zkWk8c5aSpk8ZJdYMCn6PrWkuXJc=; b=VH8wnGD8oFYp3xxBzLqIIzSdoJwBPyxm9V+yfcc2JbF6pusrTdD4Qbw+8yqyXO8weH S4rNjP5mVU6CCL5axgP3+hdLuY5B62zXXA1Q3nXG9WfG1LNO3O7jaDvx0yDTZLoo9/fO +xrKeg7UrzmL2/LDU3I5hew8TqIqzvST58pdPWDzr8oEMdBANLM9/1wGINzYOVjB1ctk lHkNZs2omHCIYnyJL+iflElfwgz08Jlb+CPzsb9iTkOzZK1MqmF3pY4Gab1SX4eKyF1D CFmt7Q5WRF5ynowagVm3aHDa7H3VNsiScfqe7E0pGZgpa1sQGcUmRMShspj5f/7aRuxg 6K3w== 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=3jZiIKDEVhj4tU9zkWk8c5aSpk8ZJdYMCn6PrWkuXJc=; b=KfLJ+zwd1Ak0BrVk86fj26DrjBJBYffmmy2ZKD1C9lSRJjKZDmB4ZqSm7wggubb4HA a4iu12TGMlvoYEWUavQOGsLgJ4Ex5k/PJCkZc8R8uJ93bXjLEz11TalD9yFbegge99DI 8py9yZYbWURjIN51DeO6914t09ly0N0DTQA4CteYlam9uiNykb6DFh+pvPEFUCb5Lxg3 DZNytzt9BFEerUW8vNyH1kU+MA+/+QI1d+Wf+eJwXw6khHtsg4IyTP2bqZu+E//U337o EA+prfZcwHfesSZms15WFGyyBMb9zFNrdU0+d0MMDuzUgGXDdj+1TYUq7E2iN/eJk2T0 afSw== X-Gm-Message-State: ALoCoQnTZxbOyMBMhPiaZvwGjxYQ4MrvdPh+M6YmaF//5iWp+UFFW7kNMKneV6ulBjqetVyxPyDv X-Received: by 10.107.150.198 with SMTP id y189mr196466iod.21.1429748099503; Wed, 22 Apr 2015 17:14:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.63.3 with HTTP; Wed, 22 Apr 2015 17:14:39 -0700 (PDT) In-Reply-To: <55352067.6070007@nostrum.com> References: <55352067.6070007@nostrum.com> From: Justin Uberti Date: Wed, 22 Apr 2015 17:14:39 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a1140ec389702260514592b8e Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 00:15:09 -0000 --001a1140ec389702260514592b8e Content-Type: text/plain; charset=UTF-8 On Mon, Apr 20, 2015 at 8:51 AM, Adam Roach wrote: > On 4/20/15 00:49, Justin Uberti wrote: > >> We now propose a new mechanism that attempts to address these issues. The >> new mechanism works like the previous mechanism, but during the candidate >> generation process, we call getsockname to obtain the local IP address of >> the interface used to talk to the STUN/TURN server. This obtains a *single* >> interface IP, which allows the browser to avoid trombone routing, but also >> minimizes the amount of IP information revealed to JS. Furthermore, the >> STUN traffic continues to go out the default route, meaning that if a VPN >> is used, the 'real' public address is still not disclosed. (Naturally, this >> has some performance implications, as a user may not always want their >> media to go out the VPN.) >> > > I think this is an incremental improvement on the previous proposal that > is worth adding. > > > As this mechanism should alleviate the primary security concerns with >> interface enumeration, with relatively small impact on user experience, we >> propose that this be the default for browsers. >> > > Okay, you had me until here. > > The idea about choosing the address that we would use to route to a TURN > server makes some assumptions about network architectures that don't hold > in the general case. For those users who are willing to accept increased > latency (sometimes), decreased quality (sometimes), and reduced connection > rates (sometimes) in exchange for obscuring certain aspects of their > network configuration, that's probably okay. You're making things slightly > worse, but for a real benefit. Well, a real benefit for those specific > users. > > The problem is that, despite the noise and fury that's resulted from this > issue, the number of users for whom it is a real concern is an > infinitesimally small fraction of those people who will ever use a web > browser. And I'm not okay with taking an across-the-board service > degradation for all users based on something that the overwhelming majority > of them won't care about. > > I'll repeat what I said at the mic in Dallas: for users looking for the > level of obscurity that you're proposing to provide, WebRTC isn't the only > concern with regards to modern web browser operation. To get this correct > requires a vast amount of work, and it's not something that anyone is > likely to get right by themselves, regardless of level of ability. You need > a comprehensive approach, such as that described at < > https://www.torproject.org/projects/torbrowser/design/>. To really get > this correct, you usually need to have someone take care of the heavy > lifting for you, which means running something like TorBrowser > > If we turn your proposed behavior on by default, we're doing the > equivalent of putting a locked deadbolt on the bathroom window while > leaving the front door unlocked, open, and made out of cardboard. > > So I'm all for including this ability as something that users can turn on, > and I'd be happy to brainstorm ways to expose this to users in ways other > than deep, dark prefs tweaking. But I think it would be a very detrimental > overreaction to hobble WebRTC by default just to solve a problem for a tiny > fraction of users. I certainly understand this position. But I wonder if we are overestimating the downside and underestimating the upside. My sense is that any service degradation will be mainly limited to cases where the user is using a VPN for work, and media ends up tunnelled where it would otherwise go direct. But pretty much all the other cases result in the same routing as in our current implementations. And even cases where routing is suboptimal could perhaps be resolved by adding an explicit permission request for full interface access. Regarding upside, these issues are very complex and hard to explain even to technical people unless they have a comms background. This leads to widespread confusion and misleading pronouncements, which could become a headwind for WebRTC adoption. --001a1140ec389702260514592b8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 20, 2015 at 8:51 AM, Adam Roach <adam@nostrum.com> wrote:
On 4/20/15 = 00:49, Justin Uberti wrote:
We now propose a new mechanism that attempts to address these issues. The n= ew mechanism works like the previous mechanism, but during the candidate ge= neration process, we call getsockname to obtain the local IP address of the= interface used to talk to the STUN/TURN server. This obtains a *single* in= terface IP, which allows the browser to avoid trombone routing, but also mi= nimizes the amount of IP information revealed to JS. Furthermore, the STUN = traffic continues to go out the default route, meaning that if a VPN is use= d, the 'real' public address is still not disclosed. (Naturally, th= is has some performance implications, as a user may not always want their m= edia to go out the VPN.)

 I think this is an incremental improvement on the previous proposal that is= worth adding.


As this mechanism should alleviate the primary security concerns with inter= face enumeration, with relatively small impact on user experience, we propo= se that this be the default for browsers.

 Okay, you had me until here.

The idea about choosing the address that we would use to route to a TURN se= rver makes some assumptions about network architectures that don't hold= in the general case. For those users who are willing to accept increased l= atency (sometimes), decreased quality (sometimes), and reduced connection r= ates (sometimes) in exchange for obscuring certain aspects of their network= configuration, that's probably okay. You're making things slightly= worse, but for a real benefit. Well, a real benefit for those specific use= rs.

The problem is that, despite the noise and fury that's resulted from th= is issue, the number of users for whom it is a real concern is an infinites= imally small fraction of those people who will ever use a web browser. And = I'm not okay with taking an across-the-board service degradation for al= l users based on something that the overwhelming majority of them won't= care about.

I'll repeat what I said at the mic in Dallas: for users looking for the= level of obscurity that you're proposing to provide, WebRTC isn't = the only concern with regards to modern web browser operation. To get this = correct requires a vast amount of work, and it's not something that any= one is likely to get right by themselves, regardless of level of ability. Y= ou need a comprehensive approach, such as that described at <h= ttps://www.torproject.org/projects/torbrowser/design/>. To really ge= t this correct, you usually need to have someone take care of the heavy lif= ting for you, which means running something like TorBrowser

If we turn your proposed behavior on by default, we're doing the equiva= lent of putting a locked deadbolt on the bathroom window while leaving the = front door unlocked, open, and made out of cardboard.

So I'm all for including this ability as something that users can turn = on, and I'd be happy to brainstorm ways to expose this to users in ways= other than deep, dark prefs tweaking. But I think it would be a very detri= mental overreaction to hobble WebRTC by default just to solve a problem for= a tiny fraction of users.

I certainly unde= rstand this position. But I wonder if we are overestimating the downside an= d underestimating the upside.=C2=A0

My sense is th= at any service degradation will be mainly limited to cases where the user i= s using a VPN for work, and media ends up tunnelled where it would otherwis= e go direct. But pretty much all the other cases result in the same routing= as in our current implementations. And even cases where routing is subopti= mal could perhaps be resolved by adding an explicit permission request for = full interface access.

Regarding upside, these iss= ues are very complex and hard to explain even to technical people unless th= ey have a comms background. This leads to widespread confusion and misleadi= ng pronouncements, which could become a headwind for WebRTC adoption.
=
--001a1140ec389702260514592b8e-- From nobody Wed Apr 22 22:32: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 D03341A871D for ; Wed, 22 Apr 2015 22:31: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 2KXJ3qnbV3hu for ; Wed, 22 Apr 2015 22:31:57 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (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 AD1621A1B8F for ; Wed, 22 Apr 2015 22:31:55 -0700 (PDT) Received: by oift201 with SMTP id t201so6064204oif.3 for ; Wed, 22 Apr 2015 22:31:55 -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=R8m4xPUgr7hXMMKxVxEWgZU2I5haO4I+4hiMKedyyDw=; b=kzyW5SkBib1PuIxUnIKkA6ziWCKXNQVm6sV/xvd4sDXh0tb5/1ZautF3dsLmEqBYFn nVnwDeHyRhGSDdDhD6E0b2VZDLxOQp3eYuJUBhl34YdX3YlvwWn/B5m7vXix+KmYM+9F psfRRe7u+cY95QoNWQhVp3U8uUi3DpM0UJJNsol85mps3pBt71bUrA67kX9pMCY3maz8 8KBgWRdJ0UqEkgko16JVR3QSoxBgekZ8WTluD6VT1GNohcdOeTGJsGRN2glScsjt7huN cPsg5Lr9thk3guZz0W76OgrWm/0HIPNyUhB9FuTooDdEqDceNw/dMbgcw8/VCdcc7rYZ YqAA== X-Gm-Message-State: ALoCoQlTiinFdmuvhL8dtKxpOBGhjGXGY3E+oHb4ZOr3hSCOHXU5YACB+OHqxDjz67Yj2S+fpHSi X-Received: by 10.202.80.22 with SMTP id e22mr890222oib.76.1429767115043; Wed, 22 Apr 2015 22:31:55 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com. [209.85.218.50]) by mx.google.com with ESMTPSA id oo10sm4376232oeb.0.2015.04.22.22.31.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 22:31:54 -0700 (PDT) Received: by oiko83 with SMTP id o83so6149138oik.1 for ; Wed, 22 Apr 2015 22:31:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.223.228 with SMTP id qx4mr950401oec.24.1429767113454; Wed, 22 Apr 2015 22:31:53 -0700 (PDT) Received: by 10.76.22.9 with HTTP; Wed, 22 Apr 2015 22:31:53 -0700 (PDT) In-Reply-To: References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> Date: Thu, 23 Apr 2015 08:31:53 +0300 Message-ID: From: Emil Ivov To: Colin Perkins Content-Type: multipart/alternative; boundary=001a1130d02ae8cd9805145d98de Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Endpoints that don't support RTCP 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 Apr 2015 05:32:00 -0000 --001a1130d02ae8cd9805145d98de Content-Type: text/plain; charset=UTF-8 Colin, Is it really that hard to see that the burden of providing performence evidence lies with the people advocating a solution? Please show me the data from all the real world deployments where you evaluated your mechanism and showed that it performed reasonably well! Emil On Thursday, April 23, 2015, Colin Perkins wrote: > On 21 Apr 2015, at 11:53, Emil Ivov > wrote: > > Hey Harald, > > On Tuesday, April 21, 2015, Harald Alvestrand > wrote: > >> Den 21. april 2015 12:10, skrev Emil Ivov: >> > On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund >> > wrote: >> >> Emil Ivov skrev den 2015-03-30 23:00: >> > So as I've mentioned before, I can see circuit breakers as an useful >> > recommendation for some applications but they are definitely redundant >> > in the context of WebRTC. >> >> The purpose of circuit breakers is not to save the users from themselves. >> >> It is to save the network from the users - to make sure that if WebRTC >> users cause persistent congestion in the network, that congestion will >> eventually go away. > > > Sure, I completely understand the intention. I just think CBs are a very > crude attempt of achieving it. Also somewhat redundant in the context of > WebRTC. > > I have repeatedly asked for data that shows how CBs are beneficial in > large-scale diverse deployments and so far I haven't seen any (I have even > been asked by Colin to provide data that they don't work ... which is quite > absurd :) ) > > > The benefit is to the network, not to your application, of course. > > And yes, I am looking for cases where the circuit breaker interferes with > real applications, because I want to understand if the circuit breaker is > being over-sensitive, or if the applications are being unreasonable. > > This is the same purpose as the AIMD algorithm in TCP (which is not >> particularly beneficial for each individual user). >> > > Well ... it isn't really the same though is it. AIMD doesn't sadistically > kill your connection at the first whiff of trouble ... :) ... it just MDs > your bandwidth usage. > > > If the circuit breaker is working correctly, it won't "kill your > connection at the first whiff of trouble". It's designed to stop flows that > cause long-term and persistent congestion. > > You earlier said: > > I am going to be *very* upset if my browser drops a call because of > 10% packet loss. I regularly have calls in hotel networks with up to > 20%+ regular packet loss and still enjoy productive conversations > thanks to FEC and PLC. > > > Give us some numbers: what packet size, data rate, and approximate RTT are > being used for these calls with 10-20% packet loss, so we can evaluate if > the circuit breaker will impact them? > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > -- --sent from my mobile --001a1130d02ae8cd9805145d98de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Colin,

Is it really that hard to see that the burden of = providing performence=C2=A0evidence lies with the people advocating a=C2=A0= solution?=C2=A0

Please show me the=C2=A0data from = all the real world deployments where you evaluated your mechanism and showe= d that it performed reasonably well!

Emil
=
On Thursday, April 23, 2015, Colin Perkins <csp@csperkins.org> wrote:
On 21 Apr 2015, at 11:53, Emil Ivo= v <emcho@jitsi.org> wrote:
Hey Harald,

On Tuesday, April 21, 2015, Harald Alvestran= d <harald@alvestrand.no> wrote:
Den 21. april 2015 12:10, skrev Emil Ivov:
> On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund
> <magnus.westerlund@ericsson.com> wrote:
>> Emil Ivov skrev den 2015-03-30 23:00:
> So as I've mentioned before, I can see circuit breakers as an usef= ul
> recommendation for some applications but they are definitely redundant=
> in the context of WebRTC.

The purpose of circuit breakers is not to save the users from themselves.
It is to save the network from the users - to make sure that if WebRTC
users cause persistent congestion in the network, that congestion will
eventually go away.

Sure, I completely understan= d the intention. I just think CBs are a very crude attempt of=C2=A0achievin= g it. Also somewhat redundant in the context of WebRTC.

I have repeatedly asked for data that=C2=A0shows how CBs are benefici= al=C2=A0in large-scale diverse=C2=A0deployments and so far I haven't se= en any (I have even been asked by Colin=C2=A0to provide data that they don&= #39;t work ... which is quite absurd :) )

=
The benefit is to the network, not to your application, of course.=C2= =A0

And yes, I am looking for cases where the circ= uit breaker interferes with real applications, because I want to understand= if the circuit breaker is being over-sensitive, or if the applications are= being unreasonable.

This is the same purpose as the AIMD algorithm in TCP (which is not
particularly beneficial for each individual user).

Well ... it=C2=A0isn't really the same thou= gh is it. AIMD doesn't sadistically kill your connection at the first w= hiff of trouble ...=C2=A0:) ... it just MDs your bandwidth usage.

If the circuit breaker is working correctly, it won= 't "kill your connection at the first whiff of trouble". It&#= 39;s designed to stop flows that cause long-term and persistent congestion.=

You earlier said:

=
I am going to be *very* upset if my browser drops a call because of
10% packet loss. I regularly have calls in hote= l networks with up to
20%+ regular packet loss= and still enjoy productive conversations
than= ks to FEC and PLC.

Give us some numbers: what packet size, data rate, and= approximate RTT are being used for these calls with 10-20% packet loss, so= we can evaluate if the circuit breaker will impact them?

<= div>


--=C2=A0
Colin Perkins






--
--sent from my mobile
--001a1130d02ae8cd9805145d98de-- From nobody Wed Apr 22 23:12: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 702F71A8899 for ; Wed, 22 Apr 2015 23:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 Qw4YAoFvXU2h for ; Wed, 22 Apr 2015 23:12:05 -0700 (PDT) Received: from relay.mailchannels.net (si-002-i39.relay.mailchannels.net [184.154.112.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9079C1A8897 for ; Wed, 22 Apr 2015 23:11:58 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-33-12-218.us-west-2.compute.internal [10.33.12.218]) by relay.mailchannels.net (Postfix) with ESMTPA id 4F249120200 for ; Thu, 23 Apr 2015 06:11:56 +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.4.8); Thu, 23 Apr 2015 06:11:56 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1429769516539:4131223808 X-MC-Ingress-Time: 1429769516539 Received: from pool-173-49-141-196.phlapa.fios.verizon.net ([173.49.141.196]:52446 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YlAMd-0000tQ-EA for rtcweb@ietf.org; Thu, 23 Apr 2015 01:11:55 -0500 Message-ID: <55388CE2.4070909@jesup.org> Date: Thu, 23 Apr 2015 02:10:42 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <55352067.6070007@nostrum.com> 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] New proposal for IP address handling in WebRTC 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 Apr 2015 06:12:06 -0000 On 4/22/2015 8:14 PM, Justin Uberti wrote: > On Mon, Apr 20, 2015 at 8:51 AM, Adam Roach > wrote: > > > If we turn your proposed behavior on by default, we're doing the > equivalent of putting a locked deadbolt on the bathroom window > while leaving the front door unlocked, open, and made out of > cardboard. > > So I'm all for including this ability as something that users can > turn on, and I'd be happy to brainstorm ways to expose this to > users in ways other than deep, dark prefs tweaking. But I think it > would be a very detrimental overreaction to hobble WebRTC by > default just to solve a problem for a tiny fraction of users. > > > I certainly understand this position. But I wonder if we are > overestimating the downside and underestimating the upside. > > My sense is that any service degradation will be mainly limited to > cases where the user is using a VPN for work, and media ends up > tunnelled where it would otherwise go direct. But pretty much all the > other cases result in the same routing as in our current > implementations. And even cases where routing is suboptimal could > perhaps be resolved by adding an explicit permission request for full > interface access. Are you thinking of a constraint on new RTCPeerConnection? (or createOffer...) Or something separate from a specific PeerConnection, since certain patterns will result in the same page making a series of PeerConnections (in parallel or series). We don't want a page to repeatedly have to request access... Of course, #include , but it would be (somewhat!) safer-by-default, modulo Adam's cardboard analogy limiting the total effectiveness. And of course the point being made here is that there's a difference here between successfully fingerprinting someone, and identifying their external DHCP address that can lead to a knock on the door. Of course, if the attacker is halfway competent, successfully fingerprinting someone (without external IP) is most of the work required to knock on the door (since you can then take that fingerprint and match it against zillions of other records which identify the fingerprint as Joe Shmoe, 123 Main St - so the front door really is made of cardboard). > Regarding upside, these issues are very complex and hard to explain > even to technical people unless they have a comms background. This > leads to widespread confusion and misleading pronouncements, which > could become a headwind for WebRTC adoption. True - regardless of the facts, if it's seen as "dangerous", it will hurt. Of course, it silently and inexplicably sucking for a major (though far from majority) class of users will hurt too. If there's some way to make it not silent about sucking, that would help a lot in shifting the balance. Ideas? -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Thu Apr 23 00:46: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 7943E1B2F23 for ; Thu, 23 Apr 2015 00:46:42 -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 Vx55hQU1XzCo for ; Thu, 23 Apr 2015 00:46:40 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3251B2F3D for ; Thu, 23 Apr 2015 00:46:31 -0700 (PDT) Received: from [81.187.2.149] (port=38989 helo=[192.168.0.18]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YlBq7-0000lM-UT; Thu, 23 Apr 2015 08:46:29 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_35FF34E6-DC5F-419B-8696-52AF8E8E38B3" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Thu, 23 Apr 2015 08:46:23 +0100 Message-Id: <8FC332B1-653F-423B-8B37-CD5574BF9A85@csperkins.org> References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> To: Emil Ivov X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Endpoints that don't support RTCP 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 Apr 2015 07:46:42 -0000 --Apple-Mail=_35FF34E6-DC5F-419B-8696-52AF8E8E38B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Emil, I have repeatedly presented evidence, including measurements on = real-world networks and simulations, to show that the proposal works. = Varun and Zahed have also done tests and presented their results at = IETF.=20 You claim the circuit breaker doesn't work in some environments. I'm = asking for details, so we can try to evaluate it in similar cases. That = doesn't seem unreasonable.=20 Colin On 23 Apr 2015, at 06:31, Emil Ivov wrote: > Colin, >=20 > Is it really that hard to see that the burden of providing performence = evidence lies with the people advocating a solution?=20 >=20 > Please show me the data from all the real world deployments where you = evaluated your mechanism and showed that it performed reasonably well! >=20 > Emil >=20 > On Thursday, April 23, 2015, Colin Perkins wrote: > On 21 Apr 2015, at 11:53, Emil Ivov wrote: >> Hey Harald, >>=20 >> On Tuesday, April 21, 2015, Harald Alvestrand = wrote: >> Den 21. april 2015 12:10, skrev Emil Ivov: >> > On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund >> > wrote: >> >> Emil Ivov skrev den 2015-03-30 23:00: >> > So as I've mentioned before, I can see circuit breakers as an = useful >> > recommendation for some applications but they are definitely = redundant >> > in the context of WebRTC. >>=20 >> The purpose of circuit breakers is not to save the users from = themselves. >>=20 >> It is to save the network from the users - to make sure that if = WebRTC >> users cause persistent congestion in the network, that congestion = will >> eventually go away. >>=20 >> Sure, I completely understand the intention. I just think CBs are a = very crude attempt of achieving it. Also somewhat redundant in the = context of WebRTC. >>=20 >> I have repeatedly asked for data that shows how CBs are beneficial in = large-scale diverse deployments and so far I haven't seen any (I have = even been asked by Colin to provide data that they don't work ... which = is quite absurd :) ) >=20 > The benefit is to the network, not to your application, of course.=20 >=20 > And yes, I am looking for cases where the circuit breaker interferes = with real applications, because I want to understand if the circuit = breaker is being over-sensitive, or if the applications are being = unreasonable. >=20 >> This is the same purpose as the AIMD algorithm in TCP (which is not >> particularly beneficial for each individual user). >>=20 >> Well ... it isn't really the same though is it. AIMD doesn't = sadistically kill your connection at the first whiff of trouble ... :) = ... it just MDs your bandwidth usage. >=20 > If the circuit breaker is working correctly, it won't "kill your = connection at the first whiff of trouble". It's designed to stop flows = that cause long-term and persistent congestion. >=20 > You earlier said: >=20 >> I am going to be *very* upset if my browser drops a call because of >> 10% packet loss. I regularly have calls in hotel networks with up to >> 20%+ regular packet loss and still enjoy productive conversations >> thanks to FEC and PLC. >=20 > Give us some numbers: what packet size, data rate, and approximate RTT = are being used for these calls with 10-20% packet loss, so we can = evaluate if the circuit breaker will impact them? >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > --sent from my mobile --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_35FF34E6-DC5F-419B-8696-52AF8E8E38B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Emil,

I have repeatedly presented = evidence, including measurements on real-world networks and simulations, = to show that the proposal works. Varun and Zahed have also done tests = and presented their results at IETF. 

You = claim the circuit breaker doesn't work in some environments. I'm asking = for details, so we can try to evaluate it in similar cases. That doesn't = seem = unreasonable. 

Colin



On 23 Apr 2015, at 06:31, Emil Ivov = <emcho@jitsi.org> = wrote:

Colin,

Is it really that hard to see = that the burden of providing performence evidence lies with the = people advocating a solution? 

Please = show me the data from all the real world deployments where you = evaluated your mechanism and showed that it performed reasonably = well!

Emil

On Thursday, April 23, = 2015, Colin Perkins <csp@csperkins.org> = wrote:
On 21 Apr 2015, at 11:53, Emil Ivov = <emcho@jitsi.org> wrote:
Hey Harald,

On Tuesday, April 21, 2015, Harald = Alvestrand <harald@alvestrand.no> wrote:
Den 21. april 2015 12:10, skrev Emil Ivov:
> On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund
> <magnus.westerlund@ericsson.com> wrote:
>> Emil Ivov skrev den 2015-03-30 23:00:
> So as I've mentioned before, I can see circuit breakers as an = useful
> recommendation for some applications but they are definitely = redundant
> in the context of WebRTC.

The purpose of circuit breakers is not to save the users from = themselves.

It is to save the network from the users - to make sure that if = WebRTC
users cause persistent congestion in the network, that congestion = will
eventually go away.

Sure, I completely = understand the intention. I just think CBs are a very crude attempt = of achieving it. Also somewhat redundant in the context of = WebRTC.

I have repeatedly asked for data = that shows how CBs are beneficial in large-scale = diverse deployments and so far I haven't seen any (I have even been = asked by Colin to provide data that they don't work ... which is = quite absurd :) )

The benefit is = to the network, not to your application, of = course. 

And yes, I am looking for cases = where the circuit breaker interferes with real applications, because I = want to understand if the circuit breaker is being over-sensitive, or if = the applications are being unreasonable.

This is the same purpose as the AIMD algorithm in TCP (which is not
particularly beneficial for each individual user).

Well ... it isn't really the same = though is it. AIMD doesn't sadistically kill your connection at the = first whiff of trouble ... :) ... it just MDs your bandwidth = usage.

If the circuit breaker is working = correctly, it won't "kill your connection at the first whiff of = trouble". It's designed to stop flows that cause long-term and = persistent congestion.

You earlier = said:

I am going to be *very* = upset if my browser drops a call because of
10% packet loss. I regularly = have calls in hotel networks with up to
20%+ regular packet loss and = still enjoy productive conversations
thanks to FEC and = PLC.

Give us some numbers: what = packet size, data rate, and approximate RTT are being used for these = calls with 10-20% packet loss, so we can evaluate if the circuit breaker = will impact them?



<= div>-- 
Colin Perkins





--
--sent from my = mobile



-- 
Colin Perkins

<= /div>


= --Apple-Mail=_35FF34E6-DC5F-419B-8696-52AF8E8E38B3-- From nobody Thu Apr 23 02:39: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 1C46C1A9060 for ; Thu, 23 Apr 2015 02:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 Xj_wIvwGMltt for ; Thu, 23 Apr 2015 02:39:16 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.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 A8B921A907E for ; Thu, 23 Apr 2015 02:38:53 -0700 (PDT) Received: by oica37 with SMTP id a37so9858282oic.0 for ; Thu, 23 Apr 2015 02:38: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=7py+ApaDwfuiTrl/K2JevtaI3eXMHiZqN6V4Xl7MisM=; b=B7dlbjUA8LQq7APR/hJ8AC+yxQSV62NdEN65LdLV3SuLErsqIVH3dp6BrIISvQChM5 qVwPMSFzzPZyujXeV62utVWbVQF8mY2JanMA/p+hL+dQNTvMohdcuhXoA1mP817TQ48u IHSy4+olxF6Axz+yCASqtPa+W08q47plsCeHxbFgtJ7dCLTKWPJErLYWZEdGHsJ7L/WV IH86sH7ajFGHccR4RNvQwsDLvKrqCnjJ+nmWRObosyX7OiAj1FR3F/YXHVP3rkLpshGm TcBctXZewf5nGJ0kocdzEPF2V8tlRUKo4o6AHKvuoYfzc5bmHdoAiYvcGWF6fFavxSZg u9rA== X-Gm-Message-State: ALoCoQmamM3RZXyBAABL393dF/Rgb9CI8Ol3DJHsLjKaXLTxOJBtAdJm2ZiOnVnPpetjk+ptiKrK X-Received: by 10.202.169.2 with SMTP id s2mr1552730oie.71.1429781933075; Thu, 23 Apr 2015 02:38:53 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com. [209.85.214.177]) by mx.google.com with ESMTPSA id su4sm4595321obc.20.2015.04.23.02.38.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 02:38:52 -0700 (PDT) Received: by obcux3 with SMTP id ux3so9263256obc.2 for ; Thu, 23 Apr 2015 02:38:52 -0700 (PDT) X-Received: by 10.202.197.138 with SMTP id v132mr1529632oif.17.1429781932174; Thu, 23 Apr 2015 02:38:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.22.9 with HTTP; Thu, 23 Apr 2015 02:38:31 -0700 (PDT) In-Reply-To: <8FC332B1-653F-423B-8B37-CD5574BF9A85@csperkins.org> References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> <8FC332B1-653F-423B-8B37-CD5574BF9A85@csperkins.org> From: Emil Ivov Date: Thu, 23 Apr 2015 12:38:31 +0300 Message-ID: To: Colin Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Endpoints that don't support RTCP 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 Apr 2015 09:39:19 -0000 Colin, On Thu, Apr 23, 2015 at 10:46 AM, Colin Perkins wrote: > Emil, > > I have repeatedly presented evidence, You inadvertently forgot to paste the link to these presentations. I am particularly interested in the "real-world networks" ones. > including measurements on real-world > networks and The one that I've seen is this: http://csperkins.org/publications/2013/12/singh2013circuitbreaker.pdf It discusses a testbed evaluation. That's certainly a useful first step for a proof of concept sanity check but it is hardly more than that. > simulations, Simulations are handy to evaluate very specific features of CBs in very specific scenarios. What we are discussing here is mandating mechanisms that have an impact in a huge variety of networks. > to show that the proposal works. Varun and Zahed > have also done tests and presented their results at IETF. Here too you forgot to paste the link. I am sure you wanted to be helpful and this was not intentional, so could you please send them over? A quick google search with the names at site:ietf.org does not immediately yield pointers to measurements on real-world networks. > You claim the circuit breaker doesn't work in some environments. I'm asking > for details, so we can try to evaluate it in similar cases. That doesn't > seem unreasonable. I am claiming that we don't have sufficient evidence that they work and am concerned that they would trigger in situations where common sense dictates they shouldn't. Now, I understand that our attitude is "we just need a backup plan on paper because in practice everyone is going to have some sort of congestion control anyway" and as such having circuit breakers lets us sort of pretend we did our job. I am fine with this. Let's just try not to forget it and treat CBs as rules set in stone (which is why I made the commented that started this discussion). Emil > Colin > > > > On 23 Apr 2015, at 06:31, Emil Ivov wrote: > > Colin, > > Is it really that hard to see that the burden of providing performence > evidence lies with the people advocating a solution? > > Please show me the data from all the real world deployments where you > evaluated your mechanism and showed that it performed reasonably well! > > Emil > > On Thursday, April 23, 2015, Colin Perkins wrote: >> >> On 21 Apr 2015, at 11:53, Emil Ivov wrote: >> >> Hey Harald, >> >> On Tuesday, April 21, 2015, Harald Alvestrand >> wrote: >>> >>> Den 21. april 2015 12:10, skrev Emil Ivov: >>> > On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund >>> > wrote: >>> >> Emil Ivov skrev den 2015-03-30 23:00: >>> > So as I've mentioned before, I can see circuit breakers as an useful >>> > recommendation for some applications but they are definitely redundant >>> > in the context of WebRTC. >>> >>> The purpose of circuit breakers is not to save the users from themselves. >>> >>> It is to save the network from the users - to make sure that if WebRTC >>> users cause persistent congestion in the network, that congestion will >>> eventually go away. >> >> >> Sure, I completely understand the intention. I just think CBs are a very >> crude attempt of achieving it. Also somewhat redundant in the context of >> WebRTC. >> >> I have repeatedly asked for data that shows how CBs are beneficial in >> large-scale diverse deployments and so far I haven't seen any (I have even >> been asked by Colin to provide data that they don't work ... which is quite >> absurd :) ) >> >> >> The benefit is to the network, not to your application, of course. >> >> And yes, I am looking for cases where the circuit breaker interferes with >> real applications, because I want to understand if the circuit breaker is >> being over-sensitive, or if the applications are being unreasonable. >> >>> This is the same purpose as the AIMD algorithm in TCP (which is not >>> particularly beneficial for each individual user). >> >> >> Well ... it isn't really the same though is it. AIMD doesn't sadistically >> kill your connection at the first whiff of trouble ... :) ... it just MDs >> your bandwidth usage. >> >> >> If the circuit breaker is working correctly, it won't "kill your >> connection at the first whiff of trouble". It's designed to stop flows that >> cause long-term and persistent congestion. >> >> You earlier said: >> >> I am going to be *very* upset if my browser drops a call because of >> 10% packet loss. I regularly have calls in hotel networks with up to >> 20%+ regular packet loss and still enjoy productive conversations >> thanks to FEC and PLC. >> >> >> Give us some numbers: what packet size, data rate, and approximate RTT are >> being used for these calls with 10-20% packet loss, so we can evaluate if >> the circuit breaker will impact them? >> >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> > > > -- > --sent from my mobile > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > -- https://jitsi.org From nobody Thu Apr 23 02:53: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 645531A907A for ; Thu, 23 Apr 2015 02:53:19 -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 1Kuok8_k9Y2M for ; Thu, 23 Apr 2015 02:53:17 -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 80E241A905D for ; Thu, 23 Apr 2015 02:53:17 -0700 (PDT) Received: by wgyo15 with SMTP id o15so12539880wgy.2 for ; Thu, 23 Apr 2015 02:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=L07KYpo4qAbtKAdtu87FJQnOcV7TD3FLJVH23jSHxSM=; b=EmhPIWyIpZw+e2Jyl+bxubUIS53O/jmmplOhox8ZmEr3WUN24Sv1qX9ODbCtGBtdHG 5Kyw8hSzXHD1A1JRlunwkUrFfx2jBf3pjdMyyOG1shCwvyUwTMo+KEQDEA/qsPNVuB4x KWe0RRbT8KUCsTCpvCWn1E4NfYXMSq4I1ZGh57kJQiRJhGs9mBcE/LYX3IGMvIm0LS4V U1xzemZNomThGnuJxVoRKko+oIbJXQ57+QzE71R5XnNIxlix6IEaJZX7lJwRzU4NIjbB 2Oz58XOS0fZPPas4RtehD/pu+0W/b2DGJPE2qRAGBEruZqSJiFohHUc7li0rjs/Wx6RQ fBCA== X-Received: by 10.180.73.180 with SMTP id m20mr4378369wiv.2.1429782796270; Thu, 23 Apr 2015 02:53:16 -0700 (PDT) Received: from [192.168.1.39] (136.Red-81-36-170.dynamicIP.rima-tde.net. [81.36.170.136]) by mx.google.com with ESMTPSA id i13sm28375155wic.13.2015.04.23.02.53.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 02:53:15 -0700 (PDT) Message-ID: <5538C10C.10905@gmail.com> Date: Thu, 23 Apr 2015 11:53:16 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> <8FC332B1-653F-423B-8B37-CD5574BF9A85@csperkins.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Endpoints that don't support RTCP 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 Apr 2015 09:53:19 -0000 On 23/04/2015 11:38, Emil Ivov wrote: > > I am claiming that we don't have sufficient evidence that they work > and am concerned that they would trigger in situations where common > sense dictates they shouldn't. +1 I completely agree with Emil. In fact, as a WebRTC service providers, what we are going to do in case of CB is to re-establish the connection immediately (maybe disabling video), so in fact the effectivity of the CB are going to be null and only add burdens to developers . Best regards Sergio From nobody Thu Apr 23 03:40: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 A15BC1ACDF4 for ; Thu, 23 Apr 2015 03:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 rKStzrJXq10U for ; Thu, 23 Apr 2015 03:40:08 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0630.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7F71ACDE8 for ; Thu, 23 Apr 2015 03:39:57 -0700 (PDT) Received: from DB4PR02MB127.eurprd02.prod.outlook.com (10.242.157.23) by DB4PR02MB174.eurprd02.prod.outlook.com (10.242.158.147) with Microsoft SMTP Server (TLS) id 15.1.148.15; Thu, 23 Apr 2015 10:28:10 +0000 Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; Received: from [193.147.51.18] (193.147.51.18) by DB4PR02MB127.eurprd02.prod.outlook.com (10.242.157.23) with Microsoft SMTP Server (TLS) id 15.1.136.25; Thu, 23 Apr 2015 10:28:08 +0000 MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_BBDCC48E-FF6A-445A-92CB-BBB3FBD774EE" From: =?iso-8859-1?Q?Luis_L=F3pez_Fern=E1ndez?= In-Reply-To: <5538C10C.10905@gmail.com> Date: Thu, 23 Apr 2015 12:28:04 +0200 Message-ID: <5C04FAA6-3F94-492F-8E9E-B475BC27434D@urjc.es> References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> <8FC332B1-653F-423B-8B37-CD5574BF9A85@csperkins.org> <5538C10C.10905@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.1510) X-Originating-IP: [193.147.51.18] X-ClientProxiedBy: DB4PR04CA0031.eurprd04.prod.outlook.com (25.160.41.41) To DB4PR02MB127.eurprd02.prod.outlook.com (10.242.157.23) X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR02MB127; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR02MB174; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10009020)(6049001)(51704005)(479174004)(24454002)(87976001)(86362001)(40100003)(2950100001)(92566002)(77096005)(36756003)(57306001)(62966003)(15975445007)(84326002)(512934002)(33656002)(50226001)(77156002)(66066001)(83716003)(19580405001)(19580395003)(50986999)(76176999)(110136001)(93886004)(82746002)(42186005)(74482002)(46102003)(3940600001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR02MB127; H:[193.147.51.18]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DB4PR02MB127; BCL:0; PCL:0; RULEID:; SRVR:DB4PR02MB127; X-Forefront-PRVS: 0555EC8317 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2015 10:28:08.8322 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR02MB127 X-OriginatorOrg: urjc.es Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Endpoints that don't support RTCP 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 Apr 2015 10:40:10 -0000 --Apple-Mail=_BBDCC48E-FF6A-445A-92CB-BBB3FBD774EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, I don't have a strong position on this, but my initial feelings are = aligned with the ones of Emil and Sergio. For service and technology = providers, CB are a relevant concern and can significantly increase the = complexity of developments for managing them. For being in favor of CB I = would need to see more clear information on their need and also a deep = analysis of the algorithms showing that they are compatible with the = whole WebRTC ecosystem, which is beyond P2P models. We have quite bad = experiences with bandwidth estimation algorithms that seem to work well = in P2P but as sub-optimal when an infrastructure is mediating. Best. L. El 23/04/2015, a las 11:53, Sergio Garcia Murillo = escribi=F3: > On 23/04/2015 11:38, Emil Ivov wrote: >>=20 >> I am claiming that we don't have sufficient evidence that they work >> and am concerned that they would trigger in situations where common >> sense dictates they shouldn't. >=20 > +1 >=20 > I completely agree with Emil. In fact, as a WebRTC service providers, = what we are going to do in case of CB is to re-establish the connection = immediately (maybe disabling video), so in fact the effectivity of the = CB are going to be null and only add burdens to developers . >=20 > Best regards > Sergio >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_BBDCC48E-FF6A-445A-92CB-BBB3FBD774EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Hi,
I = don't have a strong position on this, but my initial feelings are = aligned with the ones of Emil and Sergio. For service and technology = providers, CB are a relevant concern and can significantly increase the = complexity of developments for managing them. For being in favor of CB I = would need to see more clear information on their need and also a deep = analysis of the algorithms showing that they are compatible with the = whole WebRTC ecosystem, which is beyond P2P models. We have quite bad = experiences with bandwidth estimation algorithms that seem to work well = in P2P but as sub-optimal when an infrastructure is = mediating.

Best.

L.

El 23/04/2015, a las 11:53, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> escribi=F3:

On = 23/04/2015 11:38, Emil Ivov wrote:

I am = claiming that we don't have sufficient evidence that they work
and am = concerned that they would trigger in situations where common
sense = dictates they shouldn't.

+1

I completely = agree with Emil. In fact, as a WebRTC service providers, what we are = going to do in case of CB is to re-establish the connection immediately = (maybe disabling video), so in fact the effectivity of the CB are going = to be null and only add burdens to developers .

Best = regards
Sergio

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

= --Apple-Mail=_BBDCC48E-FF6A-445A-92CB-BBB3FBD774EE-- From nobody Thu Apr 23 04:01: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 C1DAA1B2CEF for ; Thu, 23 Apr 2015 04:01:57 -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 Fb1_PDONg8Dk for ; Thu, 23 Apr 2015 04:01:55 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D241B2D1B for ; Thu, 23 Apr 2015 04:01:41 -0700 (PDT) Received: from [130.209.247.112] (port=62946 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YlEsy-0005P5-Rp; Thu, 23 Apr 2015 12:01:38 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Thu, 23 Apr 2015 12:01:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> <8FC332B1-653F-423B-8B37-CD5574BF9A85@csperkins.org> To: Emil Ivov X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Endpoints that don't support RTCP 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 Apr 2015 11:01:57 -0000 Emil, On 23 Apr 2015, at 10:38, Emil Ivov wrote: > On Thu, Apr 23, 2015 at 10:46 AM, Colin Perkins = wrote: >> Emil, >>=20 >> I have repeatedly presented evidence, >=20 > You inadvertently forgot to paste the link to these presentations. I > am particularly interested in the "real-world networks" ones. They're in the IETF proceedings, for example AVTCORE at IETF 87 and 88: http://www.ietf.org/proceedings/87/slides/slides-87-avtcore-2.pdf http://www.ietf.org/proceedings/88/slides/slides-88-avtcore-4.pdf I had assumed you were at the meetings and saw the presentations, but = perhaps not. >> including measurements on real-world >> networks and >=20 > The one that I've seen is this: > http://csperkins.org/publications/2013/12/singh2013circuitbreaker.pdf >=20 > It discusses a testbed evaluation. That's certainly a useful first > step for a proof of concept sanity check but it is hardly more than > that. You'll also note that it evaluates the circuit breaker on several = thousand packet traces taken over the public Internet, to residential = users in the UK and Finland. It is, of course, always possible to do = more measurements, and in different scenarios, but to say that this = hasn't been tested on real networks is false. >> simulations, >=20 > Simulations are handy to evaluate very specific features of CBs in > very specific scenarios. >=20 > What we are discussing here is mandating mechanisms that have an > impact in a huge variety of networks. >=20 >> to show that the proposal works. Varun and Zahed >> have also done tests and presented their results at IETF. >=20 > Here too you forgot to paste the link. I am sure you wanted to be > helpful and this was not intentional, so could you please send them > over? >=20 > A quick google search with the names at site:ietf.org does not > immediately yield pointers to measurements on real-world networks. See above.=20 >> You claim the circuit breaker doesn't work in some environments. I'm = asking for details, so we can try to evaluate it in similar cases. That = doesn't seem unreasonable. >=20 > I am claiming that we don't have sufficient evidence that they work > and am concerned that they would trigger in situations where common > sense dictates they shouldn't. If you have specific scenarios where you want more evidence, that = haven't been tested, then you need to explain those scenarios.=20 > Now, I understand that our attitude is "we just need a backup plan on > paper because in practice everyone is going to have some sort of > congestion control anyway" and as such having circuit breakers lets us > sort of pretend we did our job. I am fine with this. Let's just try > not to forget it and treat CBs as rules set in stone (which is why I > made the commented that started this discussion). Given the number of caveats and the flexibility in the circuit breaker, = it can hardly be claimed to be "rules set in stone". It's a tool, needed = to protect the network, that if designed properly will rarely be = triggered, since it's protecting against sustained overload only. Colin > Emil >=20 >=20 >=20 >> Colin >>=20 >>=20 >>=20 >> On 23 Apr 2015, at 06:31, Emil Ivov wrote: >>=20 >> Colin, >>=20 >> Is it really that hard to see that the burden of providing = performence >> evidence lies with the people advocating a solution? >>=20 >> Please show me the data from all the real world deployments where you >> evaluated your mechanism and showed that it performed reasonably = well! >>=20 >> Emil >>=20 >> On Thursday, April 23, 2015, Colin Perkins wrote: >>>=20 >>> On 21 Apr 2015, at 11:53, Emil Ivov wrote: >>>=20 >>> Hey Harald, >>>=20 >>> On Tuesday, April 21, 2015, Harald Alvestrand >>> wrote: >>>>=20 >>>> Den 21. april 2015 12:10, skrev Emil Ivov: >>>>> On Tue, Apr 21, 2015 at 12:40 PM, Magnus Westerlund >>>>> wrote: >>>>>> Emil Ivov skrev den 2015-03-30 23:00: >>>>> So as I've mentioned before, I can see circuit breakers as an = useful >>>>> recommendation for some applications but they are definitely = redundant >>>>> in the context of WebRTC. >>>>=20 >>>> The purpose of circuit breakers is not to save the users from = themselves. >>>>=20 >>>> It is to save the network from the users - to make sure that if = WebRTC >>>> users cause persistent congestion in the network, that congestion = will >>>> eventually go away. >>>=20 >>>=20 >>> Sure, I completely understand the intention. I just think CBs are a = very >>> crude attempt of achieving it. Also somewhat redundant in the = context of >>> WebRTC. >>>=20 >>> I have repeatedly asked for data that shows how CBs are beneficial = in >>> large-scale diverse deployments and so far I haven't seen any (I = have even >>> been asked by Colin to provide data that they don't work ... which = is quite >>> absurd :) ) >>>=20 >>>=20 >>> The benefit is to the network, not to your application, of course. >>>=20 >>> And yes, I am looking for cases where the circuit breaker interferes = with >>> real applications, because I want to understand if the circuit = breaker is >>> being over-sensitive, or if the applications are being unreasonable. >>>=20 >>>> This is the same purpose as the AIMD algorithm in TCP (which is not >>>> particularly beneficial for each individual user). >>>=20 >>>=20 >>> Well ... it isn't really the same though is it. AIMD doesn't = sadistically >>> kill your connection at the first whiff of trouble ... :) ... it = just MDs >>> your bandwidth usage. >>>=20 >>>=20 >>> If the circuit breaker is working correctly, it won't "kill your >>> connection at the first whiff of trouble". It's designed to stop = flows that >>> cause long-term and persistent congestion. >>>=20 >>> You earlier said: >>>=20 >>> I am going to be *very* upset if my browser drops a call because of >>> 10% packet loss. I regularly have calls in hotel networks with up to >>> 20%+ regular packet loss and still enjoy productive conversations >>> thanks to FEC and PLC. >>>=20 >>>=20 >>> Give us some numbers: what packet size, data rate, and approximate = RTT are >>> being used for these calls with 10-20% packet loss, so we can = evaluate if >>> the circuit breaker will impact them? >>>=20 >>>=20 >>>=20 >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> -- >> --sent from my mobile >>=20 >>=20 >>=20 >>=20 >> -- >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 > --=20 > https://jitsi.org --=20 Colin Perkins https://csperkins.org/ From nobody Thu Apr 23 04:07: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 8F0021B2D58 for ; Thu, 23 Apr 2015 04:07:38 -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 F6xuQfXKZ3Bl for ; Thu, 23 Apr 2015 04:07:35 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2631B2D52 for ; Thu, 23 Apr 2015 04:07:09 -0700 (PDT) Received: from [130.209.247.112] (port=62961 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YlEyI-00067G-KC; Thu, 23 Apr 2015 12:07:07 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <5538C10C.10905@gmail.com> Date: Thu, 23 Apr 2015 12:07:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> <8FC332B1-653F-423B-8B37-CD5574BF9A85@csperkins.org> <5538C10C.10905@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Endpoints that don't support RTCP 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 Apr 2015 11:07:38 -0000 On 23 Apr 2015, at 10:53, Sergio Garcia Murillo = wrote: > On 23/04/2015 11:38, Emil Ivov wrote: >>=20 >> I am claiming that we don't have sufficient evidence that they work >> and am concerned that they would trigger in situations where common >> sense dictates they shouldn't. >=20 > +1 >=20 > I completely agree with Emil. What scenarios are you concerned with? I keep hearing claims that the = circuit breaker is problematic, but have been given no examples.=20 > In fact, as a WebRTC service providers, what we are going to do in = case of CB is to re-establish the connection immediately (maybe = disabling video), As described in Section 4.3 of the circuit breaker draft, you mean? --=20 Colin Perkins https://csperkins.org/ From nobody Thu Apr 23 06:13: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 A0DBD1B2DD6 for ; Thu, 23 Apr 2015 06:13:43 -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 8d9Qo_fLLiq3 for ; Thu, 23 Apr 2015 06:13:42 -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 809301B2DC5 for ; Thu, 23 Apr 2015 06:13:16 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-05-5538efeaa2f6 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.F7.19337.AEFE8355; Thu, 23 Apr 2015 15:13:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.210.2; Thu, 23 Apr 2015 15:13:13 +0200 Message-ID: <5538EFE9.7040200@ericsson.com> Date: Thu, 23 Apr 2015 15:13:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Leslie References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <5537948F.6040007@ericsson.com> <20150422152908.GF63465@verdi> In-Reply-To: <20150422152908.GF63465@verdi> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+Jvje6r9xahBq8OG1ms2TmBxeL9hfOM Fmv/tbM7MHssWfKTyeP/m0CPY3MPMwcwR3HZpKTmZJalFunbJXBlHPu+mKlgqWDFtgkvWRoY b/N2MXJwSAiYSKy4bdHFyAlkiklcuLeerYuRi0NI4CijxL8P55khnOWMErOvrGYBqeIV0JZo e3uZGcRmEVCVOHV6GzuIzSZgIXHzRyMbiC0qECUx8eshqHpBiZMzn4DZIgJyEr/OPmAEsZkF jCR+/L8DVi8s4CvRsOkLO8SynSwSJ+5cBhvKCbTs98SNLCCXMgvYSzzYWgbRKy/RvHU22A1C QCUNTR2sExgFZyFZNwuhYxaSjgWMzKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAsP34Jbf qjsYL79xPMQowMGoxMOb0GURKsSaWFZcmXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGxpRChusPnvoe37Eg8a1U/5wfvZ4PJ3+/OUdAbJF/+aOslcY3WZu+dCYFBJh8 mm0TOfGTwJ3LfKWP4jSVJx1d0BG+VXwWN7v7xEWxeVJbpSKKl2TP2VyxY03njc3Rh3YdmlBo aGhhfCwvZHoy971l3jWrnU5OmPn3gd05q+tGpm4WvZ/07/7wtVBiKc5INNRiLipOBABSfLJN QAIAAA== Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 13:13:43 -0000 Hi, I don't want to argue actual numbers here. My main point is that WebRTC traffic can be a substantial part of the load on a given congestion point. Fairness is always difficult to discuss, as it is a matter of time scales, traffic importance, user impact and what can actually be done with technologhy being deployed. But we do need mechanism to protect the network. Especially when the network doesn't work as intended that do happens from time to time. On a best-effort network, a WebRTC "call" is no more worth than a video stream session, a download of an archive, web-surfing, etc. > >> ... I am actually fine with it as long as the implementation does >> have some adaptation mechanism. But, from a specification point of >> view we did need a stop gap. I think the progress in RMCAT is clear >> on that. >> >> I do note that especially when one adds FEC, one do need adaptation. >> One can't use ones redundancy to steam roll all other flows sharing >> a congested bottleneck. > > My intuition says that 72 kbps goodput must not be guaranteed in > the presence of 20% packet loss -- but that dropping to 0 kbps should > not be the only reduction option. For circuit breaker it is, but the whole point is that if you have a better congestion control / bit-rate adaptation then you may be possible to support 30 kbps. The circuit breaker do give you the option of using 7,2 kbps or less when it triggers. But, I do note if that if your only supported codec is PCM, then it is 72 kbps or nothing else than RTCP. The goal must be to have as much flexibility to offer the media communication at the best possible quality that is supported by the network. 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 ---------------------------------------------------------------------- From nobody Thu Apr 23 06:15: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 69E491B2DDC for ; Thu, 23 Apr 2015 06:15:55 -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_12=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 XKnE-vXWb__8 for ; Thu, 23 Apr 2015 06:15:49 -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 2BC9F1B2DD5 for ; Thu, 23 Apr 2015 06:15:34 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-45-5538f07444e6 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.78.19337.470F8355; Thu, 23 Apr 2015 15:15:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Thu, 23 Apr 2015 15:15:31 +0200 Message-ID: <5538F073.20503@ericsson.com> Date: Thu, 23 Apr 2015 15:15:31 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Martin Thomson References: <551A902A.9080402@alvestrand.no> <55365D4A.30507@ericsson.com> <5537929C.5000108@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+JvjW7JB4tQg1+PlSw+rP/BaHHtzD9G i7X/2tkdmD12zrrL7rFkyU8mj8vnPzIGMEdx2aSk5mSWpRbp2yVwZcw8/Z+t4A9HxfFXAQ2M 29i7GDk5JARMJHYuaGeFsMUkLtxbzwZiCwkcZZRY/ZSxi5ELyF7OKPHlwBEmkASvgKbE9wdP mbsYOThYBFQlljzzBgmzCVhI3PzRCNYrKhAlMfHrIRaIckGJkzOfgNkiAroSi84+YAdpZRbw kLi9LBkkLCzgK9Gw6Qs7xKoD7BLzuqexgtRwCgRKtG6SAalhBho/c/55RghbXqJ562xmiDO1 JRqaOlgnMArOQrJtFpKWWUhaFjAyr2IULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIDN6DW36r 7mC8/MbxEKMAB6MSD29Cl0WoEGtiWXFl7iFGaQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFFpTmp xYcYmTg4pRoYtfObfHRcDnK8Mv/V32ctps24W/jBp57Sur3/MkxOlbE5zbZcv/ivmv7m9j9r 7XhjPnXOn7cy/I66rMqflXkFTP/z/05q3WKcdqn0mEa65/G4OUzxvb1nM0v6Kv/Yink4+Ikq XjH+ImW67PTfjwpvn9R47jxefod1nemHhc3hd5MD2Vc8XGKixFKckWioxVxUnAgAPSaF5D8C AAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 13:15:55 -0000 Martin Thomson skrev den 2015-04-22 19:19: > On 22 April 2015 at 05:22, Magnus Westerlund > wrote: >> Are you meaning considering the rate for the whole packet, i.e. >> IP+UDP+RTP+Payload rate, or as your own implementation calculates b=AS? >> The later is very undefined, as there are no defined timescale for which >> one calculates b=AS. Sure, for PCM audio this is straight forward, but >> for anything that is variable rate it is not. > > That sounds like a problem worth solving to me. > > I tried, and failed in MMUSIC. See https://datatracker.ietf.org/doc/draft-westerlund-mmusic-sdp-bw-attribute/ 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 ---------------------------------------------------------------------- From nobody Thu Apr 23 06:39: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 ADF521B3097 for ; Thu, 23 Apr 2015 06:38:55 -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 2S9VWmph31zZ for ; Thu, 23 Apr 2015 06:38:53 -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 198B31B309F for ; Thu, 23 Apr 2015 06:38:53 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 2481C4DB538D6; Thu, 23 Apr 2015 13:38:49 +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 t3NDcm6T019991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 15:38:49 +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; Thu, 23 Apr 2015 15:38:48 +0200 From: "DRAGE, Keith (Keith)" To: Colin Perkins , Sergio Garcia Murillo Thread-Topic: [rtcweb] Endpoints that don't support RTCP Thread-Index: AQHQfUw3D6jG0bV1yEuF2X1NGaVsvZ1Z8XyAgAAllICAAB9VgIAABB8AgAAUngCAAEoKIA== Date: Thu, 23 Apr 2015 13:38:47 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B697093ED@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> <8FC332B1-653F-423B-8B37-CD5574BF9A85@csperkins.org> <5538C10C.10905@gmail.com> In-Reply-To: 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] Endpoints that don't support RTCP 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 Apr 2015 13:38:55 -0000 I have to agree with Colin's request for details and measurements here. The first thing I learnt about congestion control (in telephony networks ba= sed on Erlang's work) was that sounds like a good solution to congestion do= es not look as good when you either do the maths or simulate it. So measurements (or the maths if you are expert in things like Markov chain= s) are needed for the particular use case to prove that the general testing= performed by Colin is invalid for that use case. Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Colin Perkins > Sent: 23 April 2015 12:07 > To: Sergio Garcia Murillo > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Endpoints that don't support RTCP >=20 > On 23 Apr 2015, at 10:53, Sergio Garcia Murillo=20 > wrote: > > On 23/04/2015 11:38, Emil Ivov wrote: > >>=20 > >> I am claiming that we don't have sufficient evidence that=20 > they work=20 > >> and am concerned that they would trigger in situations=20 > where common=20 > >> sense dictates they shouldn't. > >=20 > > +1 > >=20 > > I completely agree with Emil. >=20 > What scenarios are you concerned with? I keep hearing claims=20 > that the circuit breaker is problematic, but have been given=20 > no examples.=20 >=20 > > In fact, as a WebRTC service providers, what we are going to do in=20 > > case of CB is to re-establish the connection immediately (maybe=20 > > disabling video), >=20 > As described in Section 4.3 of the circuit breaker draft, you mean? >=20 > -- > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Thu Apr 23 06:48: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 743EF1B3056 for ; Thu, 23 Apr 2015 06:47:58 -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 yuQI0tvN4o5t for ; Thu, 23 Apr 2015 06:47:55 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id DE81E1A88F1 for ; Thu, 23 Apr 2015 06:47:54 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id DE447C94C0; Thu, 23 Apr 2015 09:47:42 -0400 (EDT) Date: Thu, 23 Apr 2015 09:47:42 -0400 From: John Leslie To: Magnus Westerlund Message-ID: <20150423134742.GI63465@verdi> References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <5537948F.6040007@ericsson.com> <20150422152908.GF63465@verdi> <5538EFE9.7040200@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5538EFE9.7040200@ericsson.com> User-Agent: Mutt/1.4.1i Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 13:47:58 -0000 Magnus Westerlund wrote: > > I don't want to argue actual numbers here. I'm not wild about arguing numbers, either; but there's no point in discussing this at all if we can't discuss numbers. > My main point is that WebRTC traffic can be a substantial part of the > load on a given congestion point. True. > Fairness is always difficult to discuss, as it is a matter of time > scales, traffic importance, user impact and what can actually be > done with technologhy being deployed. Fairness is _always_ in the eye of the beholder. :^( > But we do need mechanism to protect the network. Especially when the > network doesn't work as intended that do happens from time to time. This would imply that if the network "usually" has 20% packet loss, then we have no obligation to "protect" it from 20% packet loss... > On a best-effort network, a WebRTC "call" is no more worth than a video > stream session, a download of an archive, web-surfing, etc. Um... No. The worth of any Internet stream cannot be judged that way. It is actually quite likely that a WebRTC call is more valuable to the participants than anything else they might do with their connection. It's not our job to second-guess that evaluation. Further, "best-effort" describes the _network_, not the applications using the network. Thus, "best-effort" is quite orthogonal to "TCP- Friendly". We _may_ feel an obligation to appear "TCP-Friendly" (I don't.) If so, we should be looking at how to "enforce" reduction of sending rate in the presence of congestion. "Circuit-breaker" is a bad name for that, IMHO. Very roughly speaking, a WebRTC application could add 20% FEC bits to compensate for 20% packet loss. This _is_ a step down the road to congestion collapse; but it's not -- of itself -- a _big_ step. Its effect upon competing TCP traffic _is_ substantial (and there may be political considerations saying we have to reduce that effect). "Circuit-breaker" is not a terribly effective way to do that -- especially when the WebRTC application can simply start another call. > The goal must be to have as much flexibility to offer the media > communication at the best possible quality that is supported by the > network. Reasonable... (Gotta run: the IESG telechat starts soon.) -- John Leslie From nobody Thu Apr 23 12:44: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 C4D621B31AC for ; Thu, 23 Apr 2015 12:44:33 -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_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 v9lha5rPjCza for ; Thu, 23 Apr 2015 12:44:32 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836491B31CF for ; Thu, 23 Apr 2015 12:44:26 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.241.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 99DA9509C4; Thu, 23 Apr 2015 15:44:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Cullen Jennings In-Reply-To: <7B9A5F8B-5269-4CB3-8741-976AB7BAA9C6@csperkins.org> Date: Thu, 23 Apr 2015 13:44:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <551A902A.9080402@alvestrand.no> <55361DCA.7000101@ericsson.com> <553621A8.5000400@alvestrand.no> <7B 9A5F8B-5269-4CB3-8741-976AB7BAA9C6@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 19:44:33 -0000 > On Apr 22, 2015, at 4:44 PM, Colin Perkins wrote: >=20 >> Perpetuating tolerance for the broken behavior of ignoring "MUST send >> RTCP" seems like a path that doesn't lead to getting rid of the = behavior >> in the end. >=20 > I tend to agree: this seems like something where the gateway ought to = handle the interoperability, and synthesise appropriate RTCP.=20 >=20 > Or, if that's really too onerous, tie into some other consent check = that can indicate that the flow is still wanted and not causing = problems. People keep talking about gateway's but I'm talking about endpoints that = do ICE and DTLS-SRTP but don't do RTCP. They also don't do video.=20 The reason they don't do RTCP is because they don't perceive a value in = it. I'm not arguing this is right or wrong, I'm just saying they don't = see the value. The point the folks that think this is a good idea make = is that if RTCP says there is X jitter, or Y % packet loss, there is = nothing they can do with this. They will not stop the call until the = audio is so bad that user hangs up. Only the user hanging up stops the = call. Thus the only thing RTCP does is cause more congestion. Again, not = saying this is right but given that most the audio only RTP I see on the = network does not have RTCP, I don't think this is likely to change any = time soon. And I want to say again, for video it is the opposite story, = the bulk of the interactive video RTP I see has RTCP.=20 From nobody Thu Apr 23 12: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 038BE1B3207 for ; Thu, 23 Apr 2015 12:48:52 -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_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 rvN5Uvr7bQJC for ; Thu, 23 Apr 2015 12:48:48 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7431B3212 for ; Thu, 23 Apr 2015 12:48:23 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.241.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 52A9D509BB; Thu, 23 Apr 2015 15:48:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Cullen Jennings In-Reply-To: <20150423134742.GI63465@verdi> Date: Thu, 23 Apr 2015 13:48:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2417561F-AD14-4713-B403-EED558F9F4E2@iii.ca> References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <5537948F.6040007@ericsson.com> <20150422152908.GF63465@verdi> <5538EFE9.7040200@ericsson.com> <20150423134742.GI63465@verdi> To: John Leslie X-Mailer: Apple Mail (2.2098) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 19:48:52 -0000 > On Apr 23, 2015, at 7:47 AM, John Leslie wrote: >=20 > We _may_ feel an obligation to appear "TCP-Friendly" (I don't.) I suspect the IESG will expect whatever we do to meet the existing BCPs, = which, for the most part, require TCP Friendly.=20 From nobody Thu Apr 23 13:01: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 76E961B324B for ; Thu, 23 Apr 2015 13:01: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 Z8lsBChV2F4K for ; Thu, 23 Apr 2015 13:01:23 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::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 185651B3239 for ; Thu, 23 Apr 2015 13:01:17 -0700 (PDT) Received: by wgso17 with SMTP id o17so29931707wgs.1 for ; Thu, 23 Apr 2015 13:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=ayKoeYzKLC40BskfqtRH486IVXpgxMSG031FXJG1GPg=; b=oQl25NuAn8QLAKkDEnIDsL1GBZ2V5iyLB8VTrRpScfYm8rUuaOXaLaZuEQ56Cka19x aeroMF1wsKKslTewC1+5GIBlLwSNhN8p4eOR+vGqb/eDQ8sOvQ/S9Q0fR5SIHdvvRoFc +96kueDxlLSyz1cG/tLCOzM8eXKwNMsLx8kok8xCXRanRb9m/Ls4SwAeMR9qnaCuHQ+I oAbhfOFCUKM40hoiSQ2pEh9kPX05uTeo91PNQhmMTKKOL+OcuTO+s+JPCR+pJhZedRvx 5yy2nQ8cNB0UhjXQueVvKSnLkbG75LfGiZ5juPQ/KrMD8YOZXyqrVu7mxKG4dV+7R4bh 8dsg== X-Received: by 10.180.98.195 with SMTP id ek3mr2983578wib.57.1429819275714; Thu, 23 Apr 2015 13:01:15 -0700 (PDT) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id gi17sm13661410wjc.8.2015.04.23.13.01.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 13:01:14 -0700 (PDT) Message-ID: <55394F8C.7090407@gmail.com> Date: Thu, 23 Apr 2015 22:01:16 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Colin Perkins References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> <8FC332B1-653F-423B-8B37-CD5574BF9A85@csperkins.org> <5538C10C.10905@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000402070000010607000509" Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Endpoints that don't support RTCP 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 Apr 2015 20:01:25 -0000 This is a multi-part message in MIME format. --------------000402070000010607000509 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 23/04/2015 13:07, Colin Perkins wrote: > On 23 Apr 2015, at 10:53, Sergio Garcia Murillo wrote: >> On 23/04/2015 11:38, Emil Ivov wrote: >>> I am claiming that we don't have sufficient evidence that they work >>> and am concerned that they would trigger in situations where common >>> sense dictates they shouldn't. >> +1 >> >> I completely agree with Emil. > What scenarios are you concerned with? I keep hearing claims that the circuit breaker is problematic, but have been given no examples. > >> In fact, as a WebRTC service providers, what we are going to do in case of CB is to re-establish the connection immediately (maybe disabling video), > As described in Section 4.3 of the circuit breaker draft, you mean? > From the draft: 4.6 . Ceasing Transmission What it means to cease transmission depends on the application, but the intention is that the application will stop sending RTP data packets to a particular destination 3-tuple (transport protocol, destination port, IP address), until the user makes an explicit attempt to restart the call. I think it is a matter of deciding who is the "application", it it is the browser or the HTML/JS app running on it. If the congestion detected by the CB is signaled in the WebRTC API to the JS, so my application can choose what they want to do, then I am completely fine. If we the application is the browser and decides by itself what to do, then that's where I have the problem. If the media stops flowing, they are going to blame my service, not the network, not chrome/firefox. Best regards Sergio --------------000402070000010607000509 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 23/04/2015 13:07, Colin Perkins wrote:
On 23 Apr 2015, at 10:53, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

On 23/04/2015 11:38, Emil Ivov wrote:

I am claiming that we don't have sufficient evidence that they work
and am concerned that they would trigger in situations where common
sense dictates they shouldn't.

+1

I completely agree with Emil.

What scenarios are you concerned with? I keep hearing claims that the circuit breaker is problematic, but have been given no examples. 


In fact, as a WebRTC service providers, what we are going to do in case of CB is to re-establish the connection immediately (maybe disabling video),

As described in Section 4.3 of the circuit breaker draft, you mean?

From the draft: 

4.6.  Ceasing Transmission


   What it means to cease transmission depends on the application, but
   the intention is that the application will stop sending RTP data
   packets to a particular destination 3-tuple (transport protocol,
   destination port, IP address), until the user makes an explicit
   attempt to restart the call.

I think it is a matter of deciding who is the "application", it it is the browser or the HTML/JS app running on it. If the congestion detected by the CB is signaled in the WebRTC API to the JS, so my application can choose what they want to do, then I am completely fine. If we the application is the browser and decides by itself what to do, then that's where I have the problem.

If the media stops flowing, they are going to blame my service, not the network, not chrome/firefox.

Best regards
Sergio
--------------000402070000010607000509-- From nobody Thu Apr 23 15:33: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 E400A1A889F for ; Thu, 23 Apr 2015 15:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 7QxZgPlfRe_W for ; Thu, 23 Apr 2015 15:33:09 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350F11A8888 for ; Thu, 23 Apr 2015 15:33:01 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-10v.sys.comcast.net with comcast id KaXs1q0032Qkjl901aZ0w2; Thu, 23 Apr 2015 22:33:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-15v.sys.comcast.net with comcast id KaYz1q00K3Ge9ey01aZ0XV; Thu, 23 Apr 2015 22:33:00 +0000 Message-ID: <5539731B.4010904@alum.mit.edu> Date: Thu, 23 Apr 2015 18:32:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <5537948F.6040007@ericsson.com> <20150422152908.GF63465@verdi> <5538EFE9.7040200@ericsson.com> <20150423134742.GI63465@verdi> In-Reply-To: <20150423134742.GI63465@verdi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429828380; bh=amOfj6wCyWL/qxSMAGdRXWgcaLAgYPT6FmQy9wAEWRc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WaTOOtywF+FGZc5IWM+D/0qUVbqSllK8fmo0b7gorMbH0E0ZJGtGdJty9GwJsL4Vi mBKVRNYkQTGHwAJdjRftfQ2HSL0W6EBCbDCXT+wnKY414LB2h+2Lvqi9vwGO8K5RJw CJR6oPNTQHIuqufiueqFh5YMmvkNw0Ap458E5wjw00MOINO5dL4800AYFVb9JW+1ui qmPK2fJXwM+nxcwLaY5XIS9SEDC95CI6p33syQ51slChLQLHFLPNm29MbkKP0lTbwR vsupEB4OV3k4NMeZ6hnPI1SVSsdj3ikt+cBh/u34vGrS+6ma+LRFx/cIDPx5yjltMv WjnvA+tb1FWkA== Archived-At: Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 22:33:11 -0000 On 4/23/15 9:47 AM, John Leslie wrote: > Very roughly speaking, a WebRTC application could add 20% FEC bits > to compensate for 20% packet loss. This _is_ a step down the road to > congestion collapse; but it's not -- of itself -- a _big_ step. Its > effect upon competing TCP traffic _is_ substantial (and there may be > political considerations saying we have to reduce that effect). > > "Circuit-breaker" is not a terribly effective way to do that -- > especially when the WebRTC application can simply start another call. I'm just a kibitzer here, but IIUC CB indeed doesn't *intend* to do that. Rather, its goal is to motivate the application to do something better, so that the CB isn't triggered. Thanks, Paul From nobody Fri Apr 24 01:06: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 155611B3594 for ; Fri, 24 Apr 2015 01:06:18 -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 rT69jtZzKZCg for ; Fri, 24 Apr 2015 01:06:16 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id CF8C91B3583 for ; Fri, 24 Apr 2015 01:05:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B16747C3E1C for ; Fri, 24 Apr 2015 10:05:44 +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 xxH8RDIzVwdB for ; Fri, 24 Apr 2015 10:05:42 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id B07D87C3E1B for ; Fri, 24 Apr 2015 10:05:42 +0200 (CEST) Message-ID: <5539F956.8070705@alvestrand.no> Date: Fri, 24 Apr 2015 10:05:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <551A902A.9080402@alvestrand.no> <55361DCA.7000101@ericsson.com> <553621A8.5000400@alvestrand.no> <7B 9A5F8B-5269-4CB3-8741-976AB7BAA9C6@csperkins.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 08:06:18 -0000 Den 23. april 2015 21:44, skrev Cullen Jennings: > >> On Apr 22, 2015, at 4:44 PM, Colin Perkins wrote: >> >>> Perpetuating tolerance for the broken behavior of ignoring "MUST send >>> RTCP" seems like a path that doesn't lead to getting rid of the behavior >>> in the end. >> >> I tend to agree: this seems like something where the gateway ought to handle the interoperability, and synthesise appropriate RTCP. >> >> Or, if that's really too onerous, tie into some other consent check that can indicate that the flow is still wanted and not causing problems. > > People keep talking about gateway's but I'm talking about endpoints that do ICE and DTLS-SRTP but don't do RTCP. They also don't do video. > > The reason they don't do RTCP is because they don't perceive a value in it. I'm not arguing this is right or wrong, I'm just saying they don't see the value. The point the folks that think this is a good idea make is that if RTCP says there is X jitter, or Y % packet loss, there is nothing they can do with this. They will not stop the call until the audio is so bad that user hangs up. Only the user hanging up stops the call. Thus the only thing RTCP does is cause more congestion. Again, not saying this is right but given that most the audio only RTP I see on the network does not have RTCP, I don't think this is likely to change any time soon. And I want to say again, for video it is the opposite story, the bulk of the interactive video RTP I see has RTCP. > And I'm arguing (thinking out loud) that if we condone this behavior by successfully interoperating with these devices from WebRTC installations, we're prolonging the problem. If our consensus (or consensus-minus-Emil) is that we need devices to back off on sending RTP in the face of severe congestion for the sake of the network, and our consensus is that we need RTCP in order to detect that condition, the only reasonable conclusion is that we should refuse to interoperate with those devices that do not send RTCP. These devices already upgraded to ICE and DTLS-SRTP, presumably because they wanted to interoperate with WebRTC installations. Sending an RTCP packet once every few seconds is not going to be what kills them. From nobody Fri Apr 24 04:42: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 21A511A8F37 for ; Fri, 24 Apr 2015 04:42:03 -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 gPEHRoStNjNn for ; Fri, 24 Apr 2015 04:41:59 -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 6E3B31A8F35 for ; Fri, 24 Apr 2015 04:41:58 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-8e-553a2c04b4e1 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.29.28347.40C2A355; Fri, 24 Apr 2015 13:41:56 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.210.2; Fri, 24 Apr 2015 13:41:50 +0200 Message-ID: <553A2BFE.4050904@ericsson.com> Date: Fri, 24 Apr 2015 13:41:50 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Leslie References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <5537948F.6040007@ericsson.com> <20150422152908.GF63465@verdi> <5538EFE9.7040200@ericsson.com> <20150423134742.GI63465@verdi> In-Reply-To: <20150423134742.GI63465@verdi> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+JvjS6LjlWowfsGbYs1OyewWLy/cJ7R Yu2/dnYHZo8lS34yefx/E+hxbO5h5gDmKC6blNSczLLUIn27BK6MrTd2MRXMV6qYe+AaSwPj Z6kuRk4OCQETian/2pggbDGJC/fWs4HYQgJHGSXWNxV0MXIB2csZJeY3/mQFSfAKaEvc6TzG DGKzCKhKrF53BsxmE7CQuPmjEaxZVCBKYuLXQywQ9YISJ2c+AbNFBOQkfp19wAhiMwsYSfz4 fwesXljAV6Jh0xd2iGWbWSS6bpwGW8YJtOzcnAVADRxADfYSD7aWQfTKSzRvnc0Mcai2RENT B+sERsFZSNbNQuiYhaRjASPzKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzA8D245bfBDsaX zx0PMQpwMCrx8C5YbBkqxJpYVlyZe4hRmoNFSZzXzvhQiJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQZGM3cTD+ZP1m0XVkrz8zELuM6bsZCfPUPX88Ne3ZUZslU8sd3fUw/MNWg2uf2LY3kn x1Ytnpc2OrktuTOz//KbTvU4cYplofohLg7pz4J9Kz7/UFPafmjHsx6zsqfmgv/8ecTXW8z/ t/7flfsTJpzd1sSVE/yN6UkWn/mPitoT2gu6LD40239TYinOSDTUYi4qTgQANulubEACAAA= Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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 Apr 2015 11:42:03 -0000 John Leslie skrev den 2015-04-23 15:47: > Magnus Westerlund wrote: >> >> I don't want to argue actual numbers here. > > I'm not wild about arguing numbers, either; but there's no point in > discussing this at all if we can't discuss numbers. Sure, my main point was that the numbers I early put out in the thread was not intended to definitive in any sense or back up. But, below I will give my opinion on numbers given. > >> My main point is that WebRTC traffic can be a substantial part of the >> load on a given congestion point. > > True. > >> Fairness is always difficult to discuss, as it is a matter of time >> scales, traffic importance, user impact and what can actually be >> done with technologhy being deployed. > > Fairness is _always_ in the eye of the beholder. :^( > >> But we do need mechanism to protect the network. Especially when the >> network doesn't work as intended that do happens from time to time. > > This would imply that if the network "usually" has 20% packet loss, > then we have no obligation to "protect" it from 20% packet loss... Yes, but that is a network that has a good-put of less than 80% that is not something I would like to operate. A lot of resources down the drain. > >> On a best-effort network, a WebRTC "call" is no more worth than a video >> stream session, a download of an archive, web-surfing, etc. > > Um... No. > > The worth of any Internet stream cannot be judged that way. > > It is actually quite likely that a WebRTC call is more valuable to > the participants than anything else they might do with their connection. > It's not our job to second-guess that evaluation. > > Further, "best-effort" describes the _network_, not the applications > using the network. Thus, "best-effort" is quite orthogonal to "TCP- > Friendly". > > We _may_ feel an obligation to appear "TCP-Friendly" (I don't.) > If so, we should be looking at how to "enforce" reduction of sending > rate in the presence of congestion. > > "Circuit-breaker" is a bad name for that, IMHO. > > Very roughly speaking, a WebRTC application could add 20% FEC bits > to compensate for 20% packet loss. This _is_ a step down the road to > congestion collapse; but it's not -- of itself -- a _big_ step. Its > effect upon competing TCP traffic _is_ substantial (and there may be > political considerations saying we have to reduce that effect). My personal view is that it is fine to be using FEC to make sensible audio when encountering packet loss. But, the total bit-rate in such a scenario would be that audio+FEC should use less bandwidth than prior to the indication that you have 20% packet loss. In my opinion a circuit breaker that triggers for a sustained packet loss rate of 20% over a time period of seconds, is in fact doing its jobb. If there is a short duration, like 400 ms with that loss rate and then it otherwise drops down below 5% for the next 5 seconds and this flow is in the region of 30-50 kbps in total, then I think that is fine. All based on my judgement. I haven't, but believe that if you run this case through the circuit breaker, you might get away with it. It is the TCP equation based breaker that is the one that will fire here if any. So it depends on the RTT and how many loss events this corresponds with. > > "Circuit-breaker" is not a terribly effective way to do that -- > especially when the WebRTC application can simply start another call. Well, to automatically restart/create a new PC when the circuit breakers has triggered is not in the spirit of things. The spirit of things is to adjust your parameter settings so that it consumes less bandwidth, then start it again, or simply let the session be, unless the human user insists. 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 ---------------------------------------------------------------------- From nobody Sun Apr 26 07:03: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 26B131A9024 for ; Sun, 26 Apr 2015 07:03:03 -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 HQ3mT9hx9Pnz for ; Sun, 26 Apr 2015 07:03:01 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.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 617F31A9023 for ; Sun, 26 Apr 2015 07:03:01 -0700 (PDT) Received: by obfe9 with SMTP id e9so66986460obf.1 for ; Sun, 26 Apr 2015 07:03:00 -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=6XgRNWL4LURjCLtJsm1bIVLx0bxlM8gj+psU1GYdizw=; b=jbIJ3To5haBllUJmj/woM7FJR5eXz2o8iSGSR8rj0Ilgum1JQtFXi8Ja9PrwOUgx+0 nZADLYBW1OLxZnTe9iIK157EzKx868EjZJO/X2/Slo3+UGP4Tiqdj0JDVQrn2QIgMSL4 MqL13mRo1vMHKz4I84Llu5OLR8XeM9hA4TILM8sJa6pi2YYht1CxubQB05nyHb+un7ps PiavhLbdwj8NI2/3cCnguQ0TjpeFjNm3/qQSB4E/74KkBpkgR5iQ/HTWumxY/LGthpIc Sroql4Fwse9JhjzMOA0Wtml9Foornv4g0uuBHr+8A4CV7z00tuAm+I4L+Im2CsHFSz7o BWmg== X-Gm-Message-State: ALoCoQn21SLqCUFE6WGZjBhDnO4aidNtmg7M0bYRTxIqVsv59c6JNf0GeSBBWuXGw9tk8qyJ0feN X-Received: by 10.60.116.170 with SMTP id jx10mr6332239oeb.7.1430056980682; Sun, 26 Apr 2015 07:03:00 -0700 (PDT) Received: from camionet.local ([84.238.157.117]) by mx.google.com with ESMTPSA id zk5sm9745755obc.22.2015.04.26.07.02.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 07:02:55 -0700 (PDT) Message-ID: <553CF00C.8060701@jitsi.org> Date: Sun, 26 Apr 2015 17:02:52 +0300 From: Emil Ivov 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: Colin Perkins References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <553627F7.6010407@alvestrand.no> <8FC332B1-653F-423B-8B37-CD5574BF9A85@csperkins.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Endpoints that don't support RTCP 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, 26 Apr 2015 14:03:03 -0000 Hey Colin, On 23.04.15 14:01, Colin Perkins wrote: > Emil, > > On 23 Apr 2015, at 10:38, Emil Ivov wrote: >> On Thu, Apr 23, 2015 at 10:46 AM, Colin Perkins >> wrote: >>> Emil, >>> >>> I have repeatedly presented evidence, >> >> You inadvertently forgot to paste the link to these presentations. >> I am particularly interested in the "real-world networks" ones. > > They're in the IETF proceedings, for example AVTCORE at IETF 87 and > 88: > http://www.ietf.org/proceedings/87/slides/slides-87-avtcore-2.pdf > http://www.ietf.org/proceedings/88/slides/slides-88-avtcore-4.pdf > > I had assumed you were at the meetings and saw the presentations, but > perhaps not. Indeed not. Thanks very much for forwarding! Unfortunately, as far as Circuit Breakers are concerned I fail to find the "measurements on real-world networks" that you mentioned. Maybe I missed something? The results that Varun and you presented are based on a simulation derived from a semi-synthetic data set. Zahed's is exclusively based on simulations. All of this is obviously great work and very rewarding to read (some of it was new to me), so thanks for forwarding. Still, none of it however represents a practical evaluation of CB behaviour. Ideally what we need in order to validate CBs is: A) For a given real-world deployment, how much congestion do we see with and without CBs B) For a given real-world deployment, how does user satisfaction vary with and without CBs What I am worried about is that A) might not be particularly important because users, server-side apps and JS apps themselves would automatically resume calls. As for B) I suspect that real-world scenarios might cause more cases where CBs trigger prematurely, which would have a negative impact on user satisfaction. So with all that in mind I find that at this stage we are likely overly confident in CBs to MUST them in cases with no congestion control. Still given how people simply ignore the parts they don't like when implementing IETF RFCs I don't think we are in the face of a disaster or anything ... Emil -- https://jitsi.org From nobody Sun Apr 26 07:15: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 758DB1A906D for ; Sun, 26 Apr 2015 07:15:09 -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 q8VDxrsrIxt7 for ; Sun, 26 Apr 2015 07:15:07 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.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 7B0E81A906A for ; Sun, 26 Apr 2015 07:15:06 -0700 (PDT) Received: by oica37 with SMTP id a37so71783113oic.0 for ; Sun, 26 Apr 2015 07:15:06 -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=idGbmSXMp361GOIYfhDMpaFQ1xT9ARQm0YWhkE0uGwk=; b=fTtGM+6G/1uvSO9wu7VK7McphevTZIBUZOTPYJk3xV7wD169xv/Da+G0Q52tMKzGmQ 5s3HW2y6blBvLwrN2zBFmyZ2EkxKsLQLL9M9OG7SqQt2V9gfyVqfiBbF3+eDSbGva5Mg ChV3sDsX0e8/uUOqPY3lS0f/hYOTaDbAIqTC1LLsHkCiq6rhumBNog+FIpFgcs8Sgjmw HZDt9yjfOwJJuT9L6q6hjuL0+v7s3LF4Ta/hwgSQSXNNCrLgFlkRR0FFltwcDVIs186U mn7MswPBS7NiOYcote7VEaQ14Sokm3UqUf5+ELNGP+XlonfKMQtvuitcoxs3m9KIzREc 2n9g== X-Gm-Message-State: ALoCoQlSCbVAKa8WEXKnjIMWPfegWEDJO/uq46lwrqMSxcedvEvRxejT89buRCyMPvb5keEEi6Uu X-Received: by 10.182.230.104 with SMTP id sx8mr6341269obc.61.1430057705998; Sun, 26 Apr 2015 07:15:05 -0700 (PDT) Received: from camionet.local ([84.238.157.117]) by mx.google.com with ESMTPSA id a76sm9806905oig.11.2015.04.26.07.15.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 07:15:04 -0700 (PDT) Message-ID: <553CF2E4.7000700@jitsi.org> Date: Sun, 26 Apr 2015 17:15:00 +0300 From: Emil Ivov 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: Magnus Westerlund , John Leslie References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <5537948F.6040007@ericsson.com> <20150422152908.GF63465@verdi> <5538EFE9.7040200@ericsson.com> <20150423134742.GI63465@verdi> <553A2BFE.4050904@ericsson.com> In-Reply-To: <553A2BFE.4050904@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP 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, 26 Apr 2015 14:15:09 -0000 On 24.04.15 14:41, Magnus Westerlund wrote: > John Leslie skrev den 2015-04-23 15:47: >> Magnus Westerlund wrote: >>> But we do need mechanism to protect the network. Especially when the >>> network doesn't work as intended that do happens from time to time. >> >> This would imply that if the network "usually" has 20% packet loss, >> then we have no obligation to "protect" it from 20% packet loss... > > Yes, but that is a network that has a good-put of less than 80% that is > not something I would like to operate. A lot of resources down the drain. I don't think anyone wishes to operate such a network. The point is that we all find ourselves in them and when we do, we'd rather be able to join that important call and make the best of it (and that best is actually sometimes quite acceptable to the user even if it looks horrible in wireshark). After all, networks are there to serve users. Not just to be pretty. >>> On a best-effort network, a WebRTC "call" is no more worth than a video >>> stream session, a download of an archive, web-surfing, etc. >> >> Um... No. >> >> The worth of any Internet stream cannot be judged that way. >> >> It is actually quite likely that a WebRTC call is more valuable to >> the participants than anything else they might do with their connection. >> It's not our job to second-guess that evaluation. >> >> Further, "best-effort" describes the _network_, not the applications >> using the network. Thus, "best-effort" is quite orthogonal to "TCP- >> Friendly". >> >> We _may_ feel an obligation to appear "TCP-Friendly" (I don't.) >> If so, we should be looking at how to "enforce" reduction of sending >> rate in the presence of congestion. >> >> "Circuit-breaker" is a bad name for that, IMHO. >> >> Very roughly speaking, a WebRTC application could add 20% FEC bits >> to compensate for 20% packet loss. This _is_ a step down the road to >> congestion collapse; but it's not -- of itself -- a _big_ step. Its >> effect upon competing TCP traffic _is_ substantial (and there may be >> political considerations saying we have to reduce that effect). > > My personal view is that it is fine to be using FEC to make sensible > audio when encountering packet loss. But, the total bit-rate in such a > scenario would be that audio+FEC should use less bandwidth than prior to > the indication that you have 20% packet loss. You shouldn't consider FEC as something that is only used as a reaction to congestion. Audio codecs such as Opus and Silk allow for inband FEC and most apps that I am aware of do turn it on unconditionally prior to every call. > In my opinion a circuit breaker that triggers for a sustained packet > loss rate of 20% over a time period of seconds, is in fact doing its > jobb. This is where I disagree. In many cases sustained 20% packet loss is something that inband FEC would fix. How many users do you think would be happy in such situations when given the explanation that: we could have made your call work but it really makes us look bad to mess with such crappy networks. > If there is a short duration, like 400 ms with that loss rate and > then it otherwise drops down below 5% for the next 5 seconds and this > flow is in the region of 30-50 kbps in total, then I think that is fine. > All based on my judgement. I haven't, but believe that if you run this > case through the circuit breaker, you might get away with it. It is the > TCP equation based breaker that is the one that will fire here if any. > So it depends on the RTT and how many loss events this corresponds with. > > >> >> "Circuit-breaker" is not a terribly effective way to do that -- >> especially when the WebRTC application can simply start another call. > > Well, to automatically restart/create a new PC when the circuit breakers > has triggered is not in the spirit of things. The spirit of things is to > adjust your parameter settings so that it consumes less bandwidth, then > start it again, or simply let the session be, unless the human user > insists. Your "spirit of things" does not necessarily coincide with that of the application/service providers and users. Also, given that users will be allowed to insist, what exactly have we done to resolve congestion? Emil -- https://jitsi.org From nobody Sun Apr 26 20:24: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 C96CE1AD35F for ; Sun, 26 Apr 2015 20:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 ZABWkV7rSja9 for ; Sun, 26 Apr 2015 20:24:36 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE0C1AD373 for ; Sun, 26 Apr 2015 20:24:27 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.241.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C124322E200; Sun, 26 Apr 2015 23:24:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Cullen Jennings In-Reply-To: Date: Sun, 26 Apr 2015 21:24:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Justin Uberti X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "rtcweb@ietf.org" , Guo-wei Shieh Subject: Re: [rtcweb] New proposal for IP address handling in WebRTC 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 Apr 2015 03:24:38 -0000 I'm still more of a fan of going with a solutions of "if you want your = VPN to hide your IP address, make sure you use a VPN that hides your IP = address." - that is to say don't use a split tunnel VPN if you want to = make sure all your traffic only goes down the VPN.=20 I don't think the "default route" is as straight forward as that. For = example, if the VPN is v4 only, but there is a v6 connectivity too, then = the default route for v6 packets is not over the VPN but default route = for v4 might be over the VPN. I think we would need to understand how = cases like this work. If we add in the type of multpath proposal that = people want for WiFi / Cellular handover. It's complicated with some = VPNs - for example, the IOS VPN can look at the DNS information to = decide what the default route might be for a given flow so the default = route for one flow might not be the same as for another flow.=20 > On Apr 19, 2015, at 11:49 PM, Justin Uberti = wrote: >=20 > Background > At IETF 92 we proposed a browser mechanism that users could enable to = avoid disclosing their VPN IP to websites as a side effect of ICE = candidate generation. When this mechanism was enabled, the browser would = bind only to 0.0.0.0 and ::, and only generate candidates via STUN and = TURN; because these sockets would follow the OS default routing, the = only candidate addresses discovered would be the ones that the website = already had access to (i.e. from the HTTP request). >=20 > The primary downsides with this mechanism were: > a) users had to manually enable it (through some potentially = non-obvious preference) > b) when enabled, it caused trombone routing in intranet cases > c) when enabled, it broke pretty much every simple demo page (which = typically don't use STUN servers) >=20 > Proposal > We now propose a new mechanism that attempts to address these issues. = The new mechanism works like the previous mechanism, but during the = candidate generation process, we call getsockname to obtain the local IP = address of the interface used to talk to the STUN/TURN server. This = obtains a *single* interface IP, which allows the browser to avoid = trombone routing, but also minimizes the amount of IP information = revealed to JS. Furthermore, the STUN traffic continues to go out the = default route, meaning that if a VPN is used, the 'real' public address = is still not disclosed. (Naturally, this has some performance = implications, as a user may not always want their media to go out the = VPN.) >=20 > For pages that don't use STUN/TURN servers (typically demo pages), = there are a few options to consider: > a) always surface localhost as a candidate when no STUN/TURN servers = are provided (works with existing demos, but may have false positives = with certain apps) > b) always include some default STUN server when no STUN/TURN servers = are provided (similar to above, plus complexity of choosing default) > c) add some RTCConfiguration parameter indicating that the localhost = address is desired (requires updating many demo pages) >=20 > None of these choices is ideal, but this seems like a solvable = problem. >=20 > Implications for Browsers > As this mechanism should alleviate the primary security concerns with = interface enumeration, with relatively small impact on user experience, = we propose that this be the default for browsers. For users that don't = want to disclose any local IP information, browsers could expose a = preference that prevents surfacing even the single local IP (i.e. the = originally proposed behavior). For users that want to ensure maximum = performance (e.g. to address the VPN issue above), a similar preference = (or permissions grant) could be exposed that allows enumeration of all = IPs. >=20 > FAQ > Q: WebRTC already requires permission to access getUserMedia. Why not = use that permission to control interface enumeration? > A: Receive-only applications (e.g. streaming media) or datachannel = applications don't require a call to gUM, so there are cases where that = approach would not work. > Q: Is this only for browsers, or also for native apps? > A: This proposal is currently targeted at browsers. Native = applications, especially on mobile, need to be able to access individual = interfaces in order to be able to do seamless wifi-cellular call = handover. >=20 > We welcome feedback on this proposal. >=20 > Guo-wei Shieh and Justin Uberti >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Apr 26 20:24: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 94C441AD376 for ; Sun, 26 Apr 2015 20:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.764 X-Spam-Level: X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 mvtj_5szcnuG for ; Sun, 26 Apr 2015 20:24:54 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159D71AD35A for ; Sun, 26 Apr 2015 20:24:34 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.241.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DED9D22E25F for ; Sun, 26 Apr 2015 23:24:32 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <91729460-43E8-43A2-8A95-57513EBC03B2@iii.ca> Date: Sun, 26 Apr 2015 21:24:32 -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] Importance of local addresses in ICE 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 Apr 2015 03:24:56 -0000 There has been some suggestion that the ICE should not advertise = candidates that were addresses from a NATed address space. I think it is = critical that we do and here is why. Carrier Grade NATs (CGN) are becoming far more common in many countries. = Most measures of them show they are not friendly towards over the top = VoIP traffic (totally shocker given they are often deployed by people = offering a commercial voice service as well). So when you have two user = both behind the same GCN, if ICE does not expose the local address, all = of the traffic is forced thought the GCN (which may have more jitter = than you might hope) and to a TURN server. If the ICE contained the = local candidates then media would go directly through between the = devices.=20 CGN while not that common in the US is prevalent in many countries - = particularly ones that had less IPv4 addressed allocated to them.=20 Now you can say that this might reveal some information about their IP = address. But think about what we really wish the wold looked like. There = was no NAT and they had a IPv6 address. I have a hard time seeing how to = DHCP generated address behind the NAT is hugely different than a random = allocated v6 address so I don't see much downside on doing this and I = see huge upside - particularly for people that are working of a cellular = data link behind a CGN.=20 I am also think that in general, end to end is better for privacy than = forcing all your data through a MITM that the user does not control (the = TURN server and CGN in this case).=20 From nobody Mon Apr 27 02:31: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 436721B2F95 for ; Mon, 27 Apr 2015 02:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 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, J_BACKHAIR_44=1, 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 fI1-bInYcRhf for ; Mon, 27 Apr 2015 02:31:10 -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 BA87D1B2F91 for ; Mon, 27 Apr 2015 02:31:09 -0700 (PDT) Received: by wgin8 with SMTP id n8so109180260wgi.0 for ; Mon, 27 Apr 2015 02:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=wXtEh1fAIHMdVEA8nH/1Q2AprZ0xmbyxDJLsc8Kum18=; b=qrD34SyIctp+I2jzFuSEcF313EOLN53exAkntEUhvb9bM/50hQRzQHpPvaj/0d4kpt +tuBzl0JAlTVH/AYt1c//RwLtMlXMWR9NGWmXsi2nwlXIB321whXsR1L7BXQ9WLk42yo xm3FUm0mLQzQ4n9PzaG/ZgdIlXhe9pkaSqcmWKwT4mDqoD3tf/61KXRq6ppLJdecUQ6Y Js4k2Q5t9KYKJRnrn18oEJY6+TV0L4dlpxjEdsIJUhFlrTIfd9K2x8KAyXRMwAvrn64f yQVT4QtwPslzIb9MhEkNWkcgCKLBDacC5EwGIuBZD1IqC2spbNbqfQtcR3f47eKS1Nqp /LFw== X-Received: by 10.194.79.199 with SMTP id l7mr1148104wjx.158.1430127068392; Mon, 27 Apr 2015 02:31:08 -0700 (PDT) Received: from [192.168.1.39] (136.Red-81-36-170.dynamicIP.rima-tde.net. [81.36.170.136]) by mx.google.com with ESMTPSA id l3sm10766227wik.16.2015.04.27.02.31.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 02:31:07 -0700 (PDT) Message-ID: <553E01D7.6070600@gmail.com> Date: Mon, 27 Apr 2015 11:31:03 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <52475369.9040107@gmail.com> In-Reply-To: <52475369.9040107@gmail.com> Content-Type: multipart/alternative; boundary="------------040906070107030407040609" Archived-At: Subject: Re: [rtcweb] Camera rotation on mobile phones 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 Apr 2015 09:31:16 -0000 This is a multi-part message in MIME format. --------------040906070107030407040609 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all, I have just seen that Chrome 43 has added CVO as per my suggestion in the message below * Issue 4145 Added support for CVO (Coordination of video rotation) header extension in webrtc. When both sides support CVO, device rotation will not cause a new key-frame. https://code.google.com/p/webrtc/issues/detail?id=4145 I have always thought that it would be a nice addition to the WebRTC requirements, especially in terms of mobile performance and user experience (at least in theory). Would it be possible if anyone from the Chrome team could share some feedback about it's usage in the real life? Best regards Sergio On 29/09/2013 0:08, Sergio Garcia Murillo wrote: > Hi all, > > Currently, in order to keep image property displayed on the receiver > side if the sender rotates the phone (and the camera), it is needed > that the sender rotates the image from WxH to HxW so it is sent in > upward position over the wire. Also, if the receiver is a mobile phone > and has it rotated, it will have to rotate it again to match the > current phone orientation. > > How about using Coordination of Video Orientation as in 3GPP TS 26.114 > (http://www.3gpp.org/ftp/Specs/html-info/26114.htm)? > > Coordination of Video Orientation consists in signalling of the > current orientation of the image captured on the sender side to the > receiver for appropriate rendering and displaying. When CVO is > succesfully negotiated it shall be signalled by the MTSI client. The > signalling of the CVO uses RTP Header Extensions as specified in IETF > RFC 5285 [95]. The one-byte form of the header shall be used. CVO > information for a 2 bit granularity of Rotation (corresponding to > urn:3gpp:video-orientation) is carried as a byte formatted as follows: > > Bit#76543210(LSB) > Definition0000CFR1R0 > > With the following definitions: > > C = Camera: indicates the direction of the camera used for this video > stream. It can be used by the MTSI client in receiver to e.g. display > the received video differently depending on the source camera. > > 0: Front-facing camera, facing the user. If camera direction is > unknown by the sending MTSI client in the terminal then this is the > default value used. > > 1: Back-facing camera, facing away from the user. > > F = Flip: indicates a horizontal (left-right flip) mirror operation on > the video as sent on the link. > > 0: No flip operation. If the sending MTSI client in terminal does not > know if a horizontal mirror operation is necessary, then this is the > default value used. > > 1: Horizontal flip operation > > R1, R0 = Rotation: indicates the rotation of the video as transmitted > on the link. The receiver should rotate the video to compensate that > rotation. E.g. a 90° Counter Clockwise rotation should be compensated > by the receiver with a 90° Clockwise rotation prior to displaying. > > Table 7.2: Rotation signalling for 2 bit granularity > > R1 > > > > R0 > > > > Rotation of the video as sent on the link > > > > Rotation on the receiver before display > > 0 > > > > 0 > > > > 0° rotation > > > > None > > 0 > > > > 1 > > > > 90° Counter Clockwise (CCW) rotation or 270° Clockwise (CW) rotation > > > > 90° CW rotation > > 1 > > > > 0 > > > > 180° CCW rotation or 180° CW rotation > > > > 180° CW rotation > > 1 > > > > 1 > > > > 270° CCW rotation or 90° CW rotation > > > > 90° CCW rotation > > CVO information for a higher granularity of Rotation (corresponding to > urn:3GPP:video-orientation:6) is carried as a byteformatted as follows:** > > Bit#76543210(LSB) > DefinitionR5R4R3R2CFR1R0 > > where Cand Fare as defined above and the bits R5,R4,R3,R2,R1,R0 > represent the Rotation, which indicates the rotation of the video as > transmitted on the link. Table 7.3 describes the rotation to be > applied by the receiver based on the rotation bits. > > Table 7.3: Rotation signalling for 6 bit granularity > > R1 > > > > R0 > > > > R5 > > > > R4 > > > > R3 > > > > R2 > > > > Rotation of the video as sent on the link > > > > Rotation on the receiver before display > > 0 > > > > 0 > > > > 0 > > > > 0 > > > > 0 > > > > 0 > > > > 0° rotation > > > > None > > 0 > > > > 0 > > > > 0 > > > > 0 > > > > 0 > > > > 1 > > > > (360/64)° Counter Clockwise (CCW) rotation > > > > (360/64)° CW rotation > > 0 > > > > 0 > > > > 0 > > > > 0 > > > > 1 > > > > 0 > > > > (2*360/64)° CCW rotation > > > > (2*360/64)° CW rotation > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > > > *.* > > 1 > > > > 1 > > > > 1 > > > > 1 > > > > 1 > > > > 0 > > > > (62*360/64)° CCW rotation > > > > (2*360/64)° CCW rotation > > 1 > > > > 1 > > > > 1 > > > > 1 > > > > 1 > > > > 1 > > > > (63*360/64)° CCW rotation > > > > (360/64)° CCW rotation > > Best regards > Sergio > --------------040906070107030407040609 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi all,


I have just seen that Chrome 43 has added CVO as per my suggestion in the message below

  • Issue 4145 Added support for CVO (Coordination of video rotation) header extension in webrtc. When both sides support CVO, device rotation will not cause a new key-frame.

          https://code.google.com/p/webrtc/issues/detail?id=4145


I have always thought that it would be a nice addition to the WebRTC requirements,  especially in terms of mobile performance and user experience (at least in theory). Would it be possible if anyone from the Chrome team could share some feedback about it's usage in the real life?

Best regards
Sergio


On 29/09/2013 0:08, Sergio Garcia Murillo wrote:
Hi all,

Currently, in order to keep image property displayed on the  receiver side if the sender rotates the phone (and the camera), it is needed that the sender rotates the image from WxH to HxW so it is sent in upward position over the wire. Also, if the receiver is a mobile phone and has it rotated, it will have to rotate it again to match the current phone orientation.

How about using Coordination of Video Orientation as in 3GPP TS 26.114 (http://www.3gpp.org/ftp/Specs/html-info/26114.htm)?

Coordination of Video Orientation consists in signalling of the current orientation of the image captured on the sender side to the receiver for appropriate rendering and displaying. When CVO is succesfully negotiated it shall be signalled by the MTSI client. The signalling of the CVO uses RTP Header Extensions as specified in IETF RFC 5285 [95]. The one-byte form of the header shall be used. CVO information for a 2 bit granularity of Rotation (corresponding to urn:3gpp:video-orientation) is carried as a byte formatted as follows:

Bit#                   7                 6                 5                 4               3                 2                 1                 0(LSB)
Definition      0           0           0           0           C          F           R1          R0

With the following definitions:

C = Camera: indicates the direction of the camera used for this video stream. It can be used by the MTSI client in receiver to e.g. display the received video differently depending on the source camera.

    0: Front-facing camera, facing the user. If camera direction is unknown by the sending MTSI client in the terminal then this is the default value used.

1: Back-facing camera, facing away from the user.

F = Flip: indicates a horizontal (left-right flip) mirror operation on the video as sent on the link.

    0: No flip operation. If the sending MTSI client in terminal does not know if a horizontal mirror operation is necessary, then this is the default value used.

    1: Horizontal flip operation

R1, R0 = Rotation: indicates the rotation of the video as transmitted on the link. The receiver should rotate the video to compensate that rotation. E.g. a 90° Counter Clockwise rotation should be compensated by the receiver with a 90° Clockwise rotation prior to displaying.

Table 7.2: Rotation signalling for 2 bit granularity

R1

R0

Rotation of the video as sent on the link

Rotation on the receiver before display

0

0

0° rotation

None

0

1

90° Counter Clockwise (CCW) rotation or 270° Clockwise (CW) rotation

90° CW rotation

1

0

180° CCW rotation or 180° CW rotation

180° CW rotation

1

1

270° CCW rotation or 90° CW rotation

90° CCW rotation

 

CVO information for a higher granularity of Rotation (corresponding to urn:3GPP:video-orientation:6) is carried as a byte  formatted as follows:

Bit#                   7                 6                 5                 4               3                 2                 1                 0(LSB)
Definition      R5          R4          R3          R2          C          F           R1          R0

where C and F are as defined above and the bits R5,R4,R3,R2,R1,R0 represent the Rotation, which indicates the rotation of the video as transmitted on the link. Table 7.3 describes the rotation to be applied by the receiver based on the rotation bits.

Table 7.3: Rotation signalling for 6 bit granularity

R1

R0

R5

R4

R3

R2

Rotation of the video as sent on the link

Rotation on the receiver before display

0

0

0

0

0

0

0° rotation

None

0

0

0

0

0

1

(360/64)° Counter Clockwise (CCW) rotation

(360/64)° CW rotation

0

0

0

0

1

0

(2*360/64)° CCW rotation

(2*360/64)° CW rotation

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

1

1

1

1

1

0

(62*360/64)° CCW rotation

(2*360/64)° CCW rotation

1

1

1

1

1

1

(63*360/64)° CCW rotation

(360/64)° CCW rotation

 

Best regards
Sergio


--------------040906070107030407040609-- From nobody Wed Apr 29 08:27: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 5EEFA1A1B1F for ; Wed, 29 Apr 2015 08:27:16 -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 wkf0lrr8BarE for ; Wed, 29 Apr 2015 08:27:12 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0FA1A1AC2 for ; Wed, 29 Apr 2015 08:27:12 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 2DBF823F044C; Wed, 29 Apr 2015 17:27:11 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.54]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0224.002; Wed, 29 Apr 2015 17:27:10 +0200 From: "Hutton, Andrew" To: Harald Alvestrand , Gaelle Martin-Cocher , "Rauschenbach, Uwe (Nokia - DE/Munich)" , Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways Thread-Index: AQHQeHFa5bXT8KfOaES0di1Z0MxN+Z1SiFYAgAJtjACABB1wYIAACoyAgAsSGNA= Date: Wed, 29 Apr 2015 15:27:09 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E75341E@MCHP04MSX.global-ad.net> References: , <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> <5537CA1F.1060209@alvestrand.no> In-Reply-To: <5537CA1F.1060209@alvestrand.no> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-alvestrand-rtcweb-gateways@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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, 29 Apr 2015 15:27:16 -0000 So to be clear my understanding is that the draft status will be changed to= "Informational" and the abstract will be changed to remove the statement a= bout specifying "conformance requirements". Is that correct? The draft is therefore not intended to specify conformance requirements but= will provide implementation guidance. Regards Andy > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > Alvestrand > Sent: 22 April 2015 17:20 > To: Gaelle Martin-Cocher; Rauschenbach, Uwe (Nokia - DE/Munich); Sean > Turner; rtcweb@ietf.org > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- > gateways >=20 > Den 22. april 2015 17:36, skrev Gaelle Martin-Cocher: > > Dear all, > > > > I do have some concerns with this proposal. > > From https://www.ietf.org/mail- > archive/web/rtcweb/current/msg13885.html > > I was under impression that the gateway would be an informational > draft and there was no desire to specify conformance requirements. > > > > The current text describes high level functions that can be expected > from a gateway but does not define clearly what would be required to > conform to. > > If the intend of the draft is to specify conformance requirements > (first sentence of the abstract) there could be more requirements to > relax and the current requirements would need to be define more > clearly. > > Is it the intend? >=20 > I have not updated the intro - I think feedback was reasonably clear > that an informational document was wanted, we want to give advice, but > not to dictate what implementations do. >=20 > > > > If it is, here are some examples: > > While the WebRTC Gateway is described in the abstract (but not only, > see section 1) as "a class of > > WebRTC-compatible endpoints called "WebRTC gateways" ", section 2 > states that WebRTC gateway are "expected to conform to the requirements > for WebRTC non-browsers in [I-D.ietf-rtcweb-overview], with the > exceptions defined in this section" > > > > Wouldn't it be clearer to just define the WebRTC gateway from the > WebRTC non-browser rather than from an unspecified WebRTC-compatible > endpoint? > > It might provide a better understanding of what the gateway should be > conforming to. > > > > Requirements in 2, either: > > - are clear: e.g. the gateway MUST support DTLS-SRTP > > - describe what the gateway MAY NOT support....see second to last > paragraph > > - or leave some ambiguity: The gateway does not have to do X (e.g. > full ICE); so it may do Y (e.g. ICE-Lite). > > Playing devil's advocate: can there be a gateway doing yet something > else? > > What would it conform to? > > > > Shouldn't the requirement be reworded to state what the gateway MAY > or SHALL do/support.... and conform to? > > > > Section 1.1 and 1.2 seems unclear if meant to belong to a conformance > requirements draft. > > > > > > It is unclear to me if the purpose of the draft is to define > conformance requirements for WebRTC gateway, or is to focus on relaxing > some requirements for gateways as per section 2, or is an informational > description of what can be expected from a WebRTC 'compatible' gateway. > > > > > > Sincerely, > > Ga=EBlle > > > > > > > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Rauschenbach, Uwe (Nokia - DE/Munich) > > Sent: Sunday, April 19, 2015 2:52 PM > > To: ext Harald Alvestrand; Sean Turner; rtcweb@ietf.org > > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- > gateways > > > > +1 for adoption. > > > > The same question that Harald raised came to my mind - there was > another adoption call end of last year with a lot of support > (https://www.ietf.org/mail-archive/web/rtcweb/current/msg14050.html). > > > > Kind regards, > > Uwe > > > > ________________________________________ > > Von: rtcweb [rtcweb-bounces@ietf.org]" im Auftrag von "ext > Harald Alvestrand [harald@alvestrand.no] > > Gesendet: Samstag, 18. April 2015 07:46 > > An: Sean Turner; rtcweb@ietf.org > > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > Betreff: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- > gateways > > > > On 04/16/2015 08:15 PM, Sean Turner wrote: > >> All, > >> > >> There's been some interest expressed in having > http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ > adopted as an RTCWeb WG item. Please respond to say whether you > support adoption of this work as a working group work item and whether > you will participate in the discussion. If you are opposed to this > draft becoming a WG document, please say so (and say why). Please have > your response in by 20150423 23:59 UTC. > >> > >> Thanks in advance! > >> > >> spt > > Naturally, I support adoption. > > > > Question: Is this a repeat of the exercise on which Cullen reported > consensus for adoption in December 2014, or is this a side effect of > starting fomal tracking of adoption status? > > > > -- > > Surveillance is pervasive. Go Dark. > > > > _______________________________________________ > > 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 > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Apr 29 11:50: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 12B051A8A23 for ; Wed, 29 Apr 2015 11:50:57 -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 JJXYEx_fnwsF for ; Wed, 29 Apr 2015 11:50:54 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id ACBD01A897A for ; Wed, 29 Apr 2015 11:50:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 809A17C4482; Wed, 29 Apr 2015 20:50:51 +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 Lc_j1l3mFqkn; Wed, 29 Apr 2015 20:50:49 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:8d2e:30ed:7182:f59a] (unknown [IPv6:2001:470:de0a:27:8d2e:30ed:7182:f59a]) by mork.alvestrand.no (Postfix) with ESMTPSA id 187707C447F; Wed, 29 Apr 2015 20:50:49 +0200 (CEST) Message-ID: <55412808.7040409@alvestrand.no> Date: Wed, 29 Apr 2015 20:50:48 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Hutton, Andrew" , Gaelle Martin-Cocher , "Rauschenbach, Uwe (Nokia - DE/Munich)" , Sean Turner , "rtcweb@ietf.org" References: , <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> <5537CA1F.1060209@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E75341E@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E75341E@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-alvestrand-rtcweb-gateways@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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, 29 Apr 2015 18:50:57 -0000 Den 29. april 2015 17:27, skrev Hutton, Andrew: > So to be clear my understanding is that the draft status will be changed to "Informational" and the abstract will be changed to remove the statement about specifying "conformance requirements". Is that correct? > > The draft is therefore not intended to specify conformance requirements but will provide implementation guidance. > Yes, that's my plan. > Regards > Andy > > > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >> Alvestrand >> Sent: 22 April 2015 17:20 >> To: Gaelle Martin-Cocher; Rauschenbach, Uwe (Nokia - DE/Munich); Sean >> Turner; rtcweb@ietf.org >> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org >> Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- >> gateways >> >> Den 22. april 2015 17:36, skrev Gaelle Martin-Cocher: >>> Dear all, >>> >>> I do have some concerns with this proposal. >>> From https://www.ietf.org/mail- >> archive/web/rtcweb/current/msg13885.html >>> I was under impression that the gateway would be an informational >> draft and there was no desire to specify conformance requirements. >>> >>> The current text describes high level functions that can be expected >> from a gateway but does not define clearly what would be required to >> conform to. >>> If the intend of the draft is to specify conformance requirements >> (first sentence of the abstract) there could be more requirements to >> relax and the current requirements would need to be define more >> clearly. >>> Is it the intend? >> >> I have not updated the intro - I think feedback was reasonably clear >> that an informational document was wanted, we want to give advice, but >> not to dictate what implementations do. >> >>> >>> If it is, here are some examples: >>> While the WebRTC Gateway is described in the abstract (but not only, >> see section 1) as "a class of >>> WebRTC-compatible endpoints called "WebRTC gateways" ", section 2 >> states that WebRTC gateway are "expected to conform to the requirements >> for WebRTC non-browsers in [I-D.ietf-rtcweb-overview], with the >> exceptions defined in this section" >>> >>> Wouldn't it be clearer to just define the WebRTC gateway from the >> WebRTC non-browser rather than from an unspecified WebRTC-compatible >> endpoint? >>> It might provide a better understanding of what the gateway should be >> conforming to. >>> >>> Requirements in 2, either: >>> - are clear: e.g. the gateway MUST support DTLS-SRTP >>> - describe what the gateway MAY NOT support....see second to last >> paragraph >>> - or leave some ambiguity: The gateway does not have to do X (e.g. >> full ICE); so it may do Y (e.g. ICE-Lite). >>> Playing devil's advocate: can there be a gateway doing yet something >> else? >>> What would it conform to? >>> >>> Shouldn't the requirement be reworded to state what the gateway MAY >> or SHALL do/support.... and conform to? >>> >>> Section 1.1 and 1.2 seems unclear if meant to belong to a conformance >> requirements draft. >>> >>> >>> It is unclear to me if the purpose of the draft is to define >> conformance requirements for WebRTC gateway, or is to focus on relaxing >> some requirements for gateways as per section 2, or is an informational >> description of what can be expected from a WebRTC 'compatible' gateway. >>> >>> >>> Sincerely, >>> Gaëlle >>> >>> >>> >>> -----Original Message----- >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of >> Rauschenbach, Uwe (Nokia - DE/Munich) >>> Sent: Sunday, April 19, 2015 2:52 PM >>> To: ext Harald Alvestrand; Sean Turner; rtcweb@ietf.org >>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org >>> Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- >> gateways >>> >>> +1 for adoption. >>> >>> The same question that Harald raised came to my mind - there was >> another adoption call end of last year with a lot of support >> (https://www.ietf.org/mail-archive/web/rtcweb/current/msg14050.html). >>> >>> Kind regards, >>> Uwe >>> >>> ________________________________________ >>> Von: rtcweb [rtcweb-bounces@ietf.org]" im Auftrag von "ext >> Harald Alvestrand [harald@alvestrand.no] >>> Gesendet: Samstag, 18. April 2015 07:46 >>> An: Sean Turner; rtcweb@ietf.org >>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org >>> Betreff: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- >> gateways >>> >>> On 04/16/2015 08:15 PM, Sean Turner wrote: >>>> All, >>>> >>>> There's been some interest expressed in having >> http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ >> adopted as an RTCWeb WG item. Please respond to say whether you >> support adoption of this work as a working group work item and whether >> you will participate in the discussion. If you are opposed to this >> draft becoming a WG document, please say so (and say why). Please have >> your response in by 20150423 23:59 UTC. >>>> >>>> Thanks in advance! >>>> >>>> spt >>> Naturally, I support adoption. >>> >>> Question: Is this a repeat of the exercise on which Cullen reported >> consensus for adoption in December 2014, or is this a side effect of >> starting fomal tracking of adoption status? >>> >>> -- >>> Surveillance is pervasive. Go Dark. >>> >>> _______________________________________________ >>> 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 From nobody Wed Apr 29 12:02: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 DAF511A0018 for ; Wed, 29 Apr 2015 12:02:16 -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 eWeFNqYbTcst for ; Wed, 29 Apr 2015 12:02:11 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450: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 2D5191A897A for ; Wed, 29 Apr 2015 12:02:11 -0700 (PDT) Received: by widdi4 with SMTP id di4so191561422wid.0 for ; Wed, 29 Apr 2015 12:02:10 -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:content-transfer-encoding; bh=gOChIwqs7ZPNLwZqsq2oQbJVnVB9g/qZt/ul55Y3HwA=; b=D6Tv81oW57R6u5so6MLimusEOSLoEpn7y49FBPeMyVaPyZ4ckgeMk9vSgVN9C2M9N+ Bwm7EBB69XiwCfHsCyZZt5milBCPU63C8pCrIAnGY+q/kEJ/4aDx3ldcyD/P7++FxRPU xgW351CrbL+88FlD9LESAX7bbYNtF/RbQ/M6t9fN/5Nbjs7mdxwvi/g2ylArF4Qwy/IE LQswy5LZe0eVHC6HCX1F6oErFjJBfcg3MJqXOhFLXB5t9OoM2l5KgU82laPcRRea9xd0 naBUpOss5wuwjGmnxssOqUkneDI3KjsgBpwv7SD9NQp2qcqNOYYnQ48nGQUO3F7drNNo EF1w== MIME-Version: 1.0 X-Received: by 10.180.73.202 with SMTP id n10mr8780293wiv.0.1430334129957; Wed, 29 Apr 2015 12:02:09 -0700 (PDT) Received: by 10.28.1.198 with HTTP; Wed, 29 Apr 2015 12:02:09 -0700 (PDT) In-Reply-To: <55412808.7040409@alvestrand.no> References: <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> <5537CA1F.1060209@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E75341E@MCHP04MSX.global-ad.net> <55412808.7040409@alvestrand.no> Date: Wed, 29 Apr 2015 21:02:09 +0200 Message-ID: From: Victor Pascual Avila To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-alvestrand-rtcweb-gateways@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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, 29 Apr 2015 19:02:17 -0000 On Wed, Apr 29, 2015 at 8:50 PM, Harald Alvestrand w= rote: > Den 29. april 2015 17:27, skrev Hutton, Andrew: >> So to be clear my understanding is that the draft status will be changed= to "Informational" and the abstract will be changed to remove the statemen= t about specifying "conformance requirements". Is that correct? >> >> The draft is therefore not intended to specify conformance requirements = but will provide implementation guidance. >> > > Yes, that's my plan. > Fine with me. -Victor > >> Regards >> Andy >> >> >> >>> -----Original Message----- >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >>> Alvestrand >>> Sent: 22 April 2015 17:20 >>> To: Gaelle Martin-Cocher; Rauschenbach, Uwe (Nokia - DE/Munich); Sean >>> Turner; rtcweb@ietf.org >>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org >>> Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- >>> gateways >>> >>> Den 22. april 2015 17:36, skrev Gaelle Martin-Cocher: >>>> Dear all, >>>> >>>> I do have some concerns with this proposal. >>>> From https://www.ietf.org/mail- >>> archive/web/rtcweb/current/msg13885.html >>>> I was under impression that the gateway would be an informational >>> draft and there was no desire to specify conformance requirements. >>>> >>>> The current text describes high level functions that can be expected >>> from a gateway but does not define clearly what would be required to >>> conform to. >>>> If the intend of the draft is to specify conformance requirements >>> (first sentence of the abstract) there could be more requirements to >>> relax and the current requirements would need to be define more >>> clearly. >>>> Is it the intend? >>> >>> I have not updated the intro - I think feedback was reasonably clear >>> that an informational document was wanted, we want to give advice, but >>> not to dictate what implementations do. >>> >>>> >>>> If it is, here are some examples: >>>> While the WebRTC Gateway is described in the abstract (but not only, >>> see section 1) as "a class of >>>> WebRTC-compatible endpoints called "WebRTC gateways" ", section 2 >>> states that WebRTC gateway are "expected to conform to the requirements >>> for WebRTC non-browsers in [I-D.ietf-rtcweb-overview], with the >>> exceptions defined in this section" >>>> >>>> Wouldn't it be clearer to just define the WebRTC gateway from the >>> WebRTC non-browser rather than from an unspecified WebRTC-compatible >>> endpoint? >>>> It might provide a better understanding of what the gateway should be >>> conforming to. >>>> >>>> Requirements in 2, either: >>>> - are clear: e.g. the gateway MUST support DTLS-SRTP >>>> - describe what the gateway MAY NOT support....see second to last >>> paragraph >>>> - or leave some ambiguity: The gateway does not have to do X (e.g. >>> full ICE); so it may do Y (e.g. ICE-Lite). >>>> Playing devil's advocate: can there be a gateway doing yet something >>> else? >>>> What would it conform to? >>>> >>>> Shouldn't the requirement be reworded to state what the gateway MAY >>> or SHALL do/support.... and conform to? >>>> >>>> Section 1.1 and 1.2 seems unclear if meant to belong to a conformance >>> requirements draft. >>>> >>>> >>>> It is unclear to me if the purpose of the draft is to define >>> conformance requirements for WebRTC gateway, or is to focus on relaxing >>> some requirements for gateways as per section 2, or is an informational >>> description of what can be expected from a WebRTC 'compatible' gateway. >>>> >>>> >>>> Sincerely, >>>> Ga=C3=ABlle >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of >>> Rauschenbach, Uwe (Nokia - DE/Munich) >>>> Sent: Sunday, April 19, 2015 2:52 PM >>>> To: ext Harald Alvestrand; Sean Turner; rtcweb@ietf.org >>>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org >>>> Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- >>> gateways >>>> >>>> +1 for adoption. >>>> >>>> The same question that Harald raised came to my mind - there was >>> another adoption call end of last year with a lot of support >>> (https://www.ietf.org/mail-archive/web/rtcweb/current/msg14050.html). >>>> >>>> Kind regards, >>>> Uwe >>>> >>>> ________________________________________ >>>> Von: rtcweb [rtcweb-bounces@ietf.org]" im Auftrag von "ext >>> Harald Alvestrand [harald@alvestrand.no] >>>> Gesendet: Samstag, 18. April 2015 07:46 >>>> An: Sean Turner; rtcweb@ietf.org >>>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org >>>> Betreff: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- >>> gateways >>>> >>>> On 04/16/2015 08:15 PM, Sean Turner wrote: >>>>> All, >>>>> >>>>> There's been some interest expressed in having >>> http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ >>> adopted as an RTCWeb WG item. Please respond to say whether you >>> support adoption of this work as a working group work item and whether >>> you will participate in the discussion. If you are opposed to this >>> draft becoming a WG document, please say so (and say why). Please have >>> your response in by 20150423 23:59 UTC. >>>>> >>>>> Thanks in advance! >>>>> >>>>> spt >>>> Naturally, I support adoption. >>>> >>>> Question: Is this a repeat of the exercise on which Cullen reported >>> consensus for adoption in December 2014, or is this a side effect of >>> starting fomal tracking of adoption status? >>>> >>>> -- >>>> Surveillance is pervasive. Go Dark. >>>> >>>> _______________________________________________ >>>> 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 --=20 Victor Pascual =C3=81vila From nobody Wed Apr 29 12:31: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 5AF4C1ACE54 for ; Wed, 29 Apr 2015 12:31:49 -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 iIiouuNxzhkX for ; Wed, 29 Apr 2015 12:31:46 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 400F71ACE70 for ; Wed, 29 Apr 2015 12:31:46 -0700 (PDT) Received: by iget9 with SMTP id t9so114041037ige.1 for ; Wed, 29 Apr 2015 12:31:45 -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=Tqe9qbz1Dv6OUIECfmyO896F4d5y+axeoYZlX1zYHNA=; b=KUB2T87NnCQel5vHmI/3HEpczc2GgTpKWTZAn4hCGZ80HTeHR+fv3OAEpNLwl0UBb+ LTsil/HQIW/9ezhFGUhAu4o2EE7pdDwKWgV+hXDxU/cD+zvehsf6dyQ/xw8NLzYr/lLn 1eyF4TkHitnEkM3gbFwBXvLudxTAdcO4K3S0bIXQftOXaWg4oWxPdgIp12Icdx1phpsp R1KPLnbmRSisAb/nsP8DZTAfqoz4/RuZYCvxXK1pYJw5UQ2GvTougVUaRE4mhuHsyvja F/RFDDrL0P6Pvk/z8QYIWH5SGAcW8TbX8lCafCRH62yB8x+SdSCNSzs1A2nvdMZ2O86W M1XA== 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=Tqe9qbz1Dv6OUIECfmyO896F4d5y+axeoYZlX1zYHNA=; b=CPNkXKD1FmNNblDBwioNuryPPDx2gDf8yu1+tigr3y3wxLa6vhVduHk4njmQ/007wu bGRfuPLz1sGC06of4TAlERUbzah/B5fab2v171tOSFR7rFmld1nZkVgXJgrzWf+bS3AT PGqoLEqqVbK5DfyXae7Y6nR7slbDZMNjzzp/s3i8TIHAhgeQ5677MjYLBhUzFx/GBWeg x9TkKEs1Ph0aTaI8Ob8GYwOeq19fKZshMtpTYZax0WRWOuQTSHaXiFg89/ziCkhomjVI 7sq8r+7EACkNJ1HLaK333GPzEq4IusmOTwv7PZooY8R4ir53zl8erBqyVgD25NqAlruV oY6g== X-Gm-Message-State: ALoCoQnR2ZBrNkICWd9DmntbS3mOlI06Xn3OVgtmrivk1cUxbBf3C8wPoLXNMmPlTuSixMEp/qga X-Received: by 10.107.128.149 with SMTP id k21mr901392ioi.7.1430335905641; Wed, 29 Apr 2015 12:31:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.233 with HTTP; Wed, 29 Apr 2015 12:31:25 -0700 (PDT) In-Reply-To: <553E01D7.6070600@gmail.com> References: <52475369.9040107@gmail.com> <553E01D7.6070600@gmail.com> From: Justin Uberti Date: Wed, 29 Apr 2015 12:31:25 -0700 Message-ID: To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=001a113f922490ed6b0514e2075b Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Camera rotation on mobile phones 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, 29 Apr 2015 19:31:49 -0000 --001a113f922490ed6b0514e2075b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable CVO is part of the rtcweb-video requirements. On Mon, Apr 27, 2015 at 2:31 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi all, > > > I have just seen that Chrome 43 has added CVO as per my suggestion in the > message below > > > - > > Issue 4145 > Added support for CVO (Coordination of video rotation) header extensio= n in > webrtc. When both sides support CVO, device rotation will not cause a = new > key-frame. > > https://code.google.com/p/webrtc/issues/detail?id=3D4145 > > I have always thought that it would be a nice addition to the WebRTC > requirements, especially in terms of mobile performance and user > experience (at least in theory). Would it be possible if anyone from the > Chrome team could share some feedback about it's usage in the real life? > > Best regards > Sergio > > > On 29/09/2013 0:08, Sergio Garcia Murillo wrote: > > Hi all, > > Currently, in order to keep image property displayed on the receiver sid= e > if the sender rotates the phone (and the camera), it is needed that the > sender rotates the image from WxH to HxW so it is sent in upward position > over the wire. Also, if the receiver is a mobile phone and has it rotated= , > it will have to rotate it again to match the current phone orientation. > > How about using Coordination of Video Orientation as in 3GPP TS 26.114 ( > http://www.3gpp.org/ftp/Specs/html-info/26114.htm)? > > Coordination of Video Orientation consists in signalling of the current > orientation of the image captured on the sender side to the receiver for > appropriate rendering and displaying. When CVO is succesfully negotiated = it > shall be signalled by the MTSI client. The signalling of the CVO uses RTP > Header Extensions as specified in IETF RFC 5285 [95]. The one-byte form o= f > the header shall be used. CVO information for a 2 bit granularity of > Rotation (corresponding to urn:3gpp:video-orientation) is carried as a by= te > formatted as follows: > > Bit# 7 6 5 > 4 3 2 1 0 > (LSB) > Definition 0 0 0 0 C > F R1 R0 > > With the following definitions: > > C =3D Camera: indicates the direction of the camera used for this video > stream. It can be used by the MTSI client in receiver to e.g. display the > received video differently depending on the source camera. > > 0: Front-facing camera, facing the user. If camera direction is > unknown by the sending MTSI client in the terminal then this is the defau= lt > value used. > > 1: Back-facing camera, facing away from the user. > > F =3D Flip: indicates a horizontal (left-right flip) mirror operation on = the > video as sent on the link. > > 0: No flip operation. If the sending MTSI client in terminal does not > know if a horizontal mirror operation is necessary, then this is the > default value used. > > 1: Horizontal flip operation > > R1, R0 =3D Rotation: indicates the rotation of the video as transmitted o= n > the link. The receiver should rotate the video to compensate that rotatio= n. > E.g. a 90=C2=B0 Counter Clockwise rotation should be compensated by the r= eceiver > with a 90=C2=B0 Clockwise rotation prior to displaying. > > Table 7.2: Rotation signalling for 2 bit granularity > > R1 > > R0 > > Rotation of the video as sent on the link > > Rotation on the receiver before display > > 0 > > 0 > > 0=C2=B0 rotation > > None > > 0 > > 1 > > 90=C2=B0 Counter Clockwise (CCW) rotation or 270=C2=B0 Clockwise (CW) rot= ation > > 90=C2=B0 CW rotation > > 1 > > 0 > > 180=C2=B0 CCW rotation or 180=C2=B0 CW rotation > > 180=C2=B0 CW rotation > > 1 > > 1 > > 270=C2=B0 CCW rotation or 90=C2=B0 CW rotation > > 90=C2=B0 CCW rotation > > > > CVO information for a higher granularity of Rotation (corresponding to > urn:3GPP:video-orientation:6) is carried as a byte formatted as follows: > > Bit# 7 6 5 > 4 3 2 1 0 > (LSB) > Definition R5 R4 R3 R2 C > F R1 R0 > > where C and F are as defined above and the bits R5,R4,R3,R2,R1,R0 > represent the Rotation, which indicates the rotation of the video as > transmitted on the link. Table 7.3 describes the rotation to be applied b= y > the receiver based on the rotation bits. > > Table 7.3: Rotation signalling for 6 bit granularity > > R1 > > R0 > > R5 > > R4 > > R3 > > R2 > > Rotation of the video as sent on the link > > Rotation on the receiver before display > > 0 > > 0 > > 0 > > 0 > > 0 > > 0 > > 0=C2=B0 rotation > > None > > 0 > > 0 > > 0 > > 0 > > 0 > > 1 > > (360/64)=C2=B0 Counter Clockwise (CCW) rotation > > (360/64)=C2=B0 CW rotation > > 0 > > 0 > > 0 > > 0 > > 1 > > 0 > > (2*360/64)=C2=B0 CCW rotation > > (2*360/64)=C2=B0 CW rotation > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > *.* > > 1 > > 1 > > 1 > > 1 > > 1 > > 0 > > (62*360/64)=C2=B0 CCW rotation > > (2*360/64)=C2=B0 CCW rotation > > 1 > > 1 > > 1 > > 1 > > 1 > > 1 > > (63*360/64)=C2=B0 CCW rotation > > (360/64)=C2=B0 CCW rotation > > > Best regards > Sergio > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113f922490ed6b0514e2075b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
CVO is part of the rtcweb-video requirements.

On Mon, Apr 27, 2015 at = 2:31 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.= com> wrote:
=20 =20 =20
Hi all,


I have just seen that Chrome 43 has added CVO as per my suggestion in the message below

  • Issu= e 4145 Added support for CVO (Coordination of video rotation) header extension in webrtc. When both sides support CVO, device rotation will not cause a new key-frame.

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://code= .google.com/p/webrtc/issues/detail?id=3D4145


I have always thought that it would be a nice addition to the WebRTC requirements,=C2=A0 especially in terms of mobile performanc= e and user experience (at least in theory). Would it be possible if anyone from the Chrome team could share some feedback about it's usage in the real life?

Best regards
Sergio


On 29/09/2013 0:08, Sergio Garcia Murillo wrote:
=20 Hi all,

Currently, in order to keep image property displayed on the=C2=A0 receiver side if the sender rotates the phone (and the camera), it is needed that the sender rotates the image from WxH to HxW so it is sent in upward position over the wire. Also, if the receiver is a mobile phone and has it rotated, it will have to rotate it again to match the current phone orientation.

How about using Coordination of Video Orientati= on as in 3GPP TS 26.114 (http://www.3gpp.org/ftp/Specs/html-info/26114.ht= m)?

Coordination of Video Orientation consists in signalling of the current orientation of the image captured on the sender side to the receiver for appropriate rendering and displaying. When CVO is succesfully negotiated it shall be signalled by the MTSI client. The signalling of the CVO uses RTP Header Extensions as specified in IETF RFC 5285 [95]. The one-byte form of the header shall be used. CVO information for a 2 bit granularity of Rotation (corresponding to urn:3gpp:video-orientation) is carried as a byte formatted as follows:

Bit# =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=C2=A0=C2=A0=C2=A0=C2=A0 = 7=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=C2=A0=C2=A0 6=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=C2=A0=C2= =A0 5=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=C2=A0=C2=A0 = 4=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 3= =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= =C2=A0=C2=A0 2=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=C2=A0=C2=A0 1=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=C2=A0=C2=A0 0(LSB= )
Definitio= n=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0 <= span style=3D"font-family:Courier" lang=3D"EN-GB">=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 F=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 R1= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 R0

With the following defini= tions:

C =3D Camera: <= /u>indicates the direction of the camera used for this video stream. It can be used by the MTSI client in receiver to e.g. display the received video differently depending on the source camera.<= /p>

=C2=A0=C2=A0=C2=A0 0: Fro= nt-facing camera, facing the user. If camera direction is unknown by the sending MTSI client in the terminal then this is the default value used.

1: Back-facing camera, facing away from the user.

F =3D Flip: indicates a h= orizontal (left-right flip) mirror operation on the video as sent on the link.

=C2=A0=C2=A0=C2=A0 = 0: No flip operation. If the sending MTSI client in terminal does not know if a horizontal mirror operation is necessary, then this is the default value used.

=C2=A0=C2=A0=C2=A0 = 1: Horizontal flip operation

R1, R0 =3D Rotation: <= /u>indicates the rotation of the video as transmitted on the link. The receiver should rotate the video to compensate that rotation. E.g. a 90=C2=B0 Counter Clockwise rotation should be compensated by the receiver with a 90=C2=B0 Clockwise rotation prior to displaying.<= u>

Table 7.2: Rotation signalling for 2 bit granularity

R1

R0

Rotation= of the video as sent on the link

Rotation= on the receiver before display

0

0

0=C2=B0 rotation

None<= /u>

0

1

90=C2=B0 Counter Clockwise (CCW) rotation or 270=C2=B0 Clockwise (CW) rotation

90=C2=B0= CW rotation

1

0

180=C2= =B0 CCW rotation or 180=C2=B0 CW rotation

180=C2= =B0 CW rotation

1

1

270=C2= =B0 CCW rotation or 90=C2=B0 CW rotation

90=C2=B0= CCW rotation

=C2=A0

CVO information for a higher granularity of Rotation (corresponding to urn:3GPP:video-orientation:6) is carried as a byte=C2=A0 formatted as follows:

Bit# =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=C2=A0=C2=A0=C2=A0=C2=A0 = 7=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=C2=A0=C2=A0 6=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=C2=A0=C2= =A0 5=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=C2=A0=C2=A0 = 4=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 3= =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= =C2=A0=C2=A0 2=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=C2=A0=C2=A0 1=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=C2=A0=C2=A0 0(LSB= )
Definitio= n=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 R5=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 R4<= /span>=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 R3=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 R2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 C=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 F=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 R1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 R0

where C and F are as defined above and the b= its R5,R4,R3,R2,R1,R0 represent the Rotation, which indicates the rotation of the video as transmitted on the link. Table 7.3 describes the rotation to be applied by the receiver based on the rotation bits.

Table 7.3: Rotation signalling for 6 bit granularity

R1

R0

R5

R4

R3

R2

Rotation= of the video as sent on the link

Rotation= on the receiver before display

0

0

0

0

0

0

0=C2=B0 rotation

None<= /u>

0

0

0

0

0

1

(360/64)= =C2=B0 Counter Clockwise (CCW) rotation

(360/64)= =C2=B0 CW rotation

0

0

0

0

1

0

(2*360/6= 4)=C2=B0 CCW rotation

(2*360/6= 4)=C2=B0 CW rotation

.

.

.

.

.

.

.

.<= /u>

.

.

.

.

.

.

.<= /u>

.<= /u>

.

.

.

.

.

.

.<= /u>

.<= /u>

1

1

1

1

1

0

(62*360/= 64)=C2=B0 CCW rotation

(2*360/6= 4)=C2=B0 CCW rotation

1

1

1

1

1

1

(63*360/= 64)=C2=B0 CCW rotation

(360/64)= =C2=B0 CCW rotation

=C2=A0

Best regards
Sergio



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


--001a113f922490ed6b0514e2075b-- From nobody Wed Apr 29 14:08: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 9A5081A1BED for ; Wed, 29 Apr 2015 14:08:06 -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 Dd0IoTM2zlt3 for ; Wed, 29 Apr 2015 14:08:03 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::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 544321A1BE3 for ; Wed, 29 Apr 2015 14:08:02 -0700 (PDT) Received: by wgen6 with SMTP id n6so41855671wge.3 for ; Wed, 29 Apr 2015 14:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=H0sIPFY7+aW53XOA2kC6vElJiNHacAzJktC346NYEUY=; b=RZatOi0GlISF/EVF+yL/9mcpWERA/8jCxsI58DXA2ZYkFu7HvQO9a6YQn7zKarprCL EjKthMn1TSu74xR43/1+s26PUrBN48KPEhlxfG89lpNAJxIg8i5Uatel9hM3zQ212irq EE+SXOQLCHrtZMfHobaXmbxF2g9f3DGiKaa1AzzTIAXa6K6Vh/DLfOQUvJZf4tE/l+FY E3sllPPaBELH+5nDUkOQ8TRvibkmiwaTkCni9uJ4W3nlqXrg7RD0YDCAe6xbEuObd7S7 ZcnrajO/n/PJDYvTSemraDr5jWyqQnlOOpRnrp5pEouv3GBCgVnCPbko4I2+fnP5NePN 6obw== X-Received: by 10.180.208.84 with SMTP id mc20mr9548435wic.38.1430341681047; Wed, 29 Apr 2015 14:08:01 -0700 (PDT) Received: from [192.168.0.196] ([95.61.111.78]) by mx.google.com with ESMTPSA id df1sm22801731wib.12.2015.04.29.14.07.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 14:08:00 -0700 (PDT) Message-ID: <55414830.9050804@gmail.com> Date: Wed, 29 Apr 2015 23:08:00 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Justin Uberti References: <52475369.9040107@gmail.com> <553E01D7.6070600@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080400040404050202020203" Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Camera rotation on mobile phones 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, 29 Apr 2015 21:08:06 -0000 This is a multi-part message in MIME format. --------------080400040404050202020203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Justin! Was not aware of it as I didn't saw any feedback on the mailing list. Sometimes is difficult to be up to date with latest changes :) Best regards Sergio On 29/04/2015 21:31, Justin Uberti wrote: > CVO is part of the rtcweb-video requirements. > > On Mon, Apr 27, 2015 at 2:31 AM, Sergio Garcia Murillo > > wrote: > > Hi all, > > > I have just seen that Chrome 43 has added CVO as per my suggestion > in the message below > > * > > Issue 4145 > Added > support for CVO (Coordination of video rotation) header > extension in webrtc. When both sides support CVO, device > rotation will not cause a new key-frame. > > https://code.google.com/p/webrtc/issues/detail?id=4145 > > > I have always thought that it would be a nice addition to the > WebRTC requirements, especially in terms of mobile performance > and user experience (at least in theory). Would it be possible if > anyone from the Chrome team could share some feedback about it's > usage in the real life? > > Best regards > Sergio > > > On 29/09/2013 0:08, Sergio Garcia Murillo wrote: >> Hi all, >> >> Currently, in order to keep image property displayed on the >> receiver side if the sender rotates the phone (and the camera), >> it is needed that the sender rotates the image from WxH to HxW so >> it is sent in upward position over the wire. Also, if the >> receiver is a mobile phone and has it rotated, it will have to >> rotate it again to match the current phone orientation. >> >> How about using Coordination of Video Orientation as in 3GPP TS >> 26.114 (http://www.3gpp.org/ftp/Specs/html-info/26114.htm)? >> >> Coordination of Video Orientation consists in signalling of the >> current orientation of the image captured on the sender side to >> the receiver for appropriate rendering and displaying. When CVO >> is succesfully negotiated it shall be signalled by the MTSI >> client. The signalling of the CVO uses RTP Header Extensions as >> specified in IETF RFC 5285 [95]. The one-byte form of the header >> shall be used. CVO information for a 2 bit granularity of >> Rotation (corresponding to urn:3gpp:video-orientation) is carried >> as a byte formatted as follows: >> >> Bit#76543210(LSB) >> Definition0000CFR1R0 >> >> With the following definitions: >> >> C = Camera: indicates the direction of the camera used for this >> video stream. It can be used by the MTSI client in receiver to >> e.g. display the received video differently depending on the >> source camera. >> >> 0: Front-facing camera, facing the user. If camera direction >> is unknown by the sending MTSI client in the terminal then this >> is the default value used. >> >> 1: Back-facing camera, facing away from the user. >> >> F = Flip: indicates a horizontal (left-right flip) mirror >> operation on the video as sent on the link. >> >> 0: No flip operation. If the sending MTSI client in terminal does >> not know if a horizontal mirror operation is necessary, then this >> is the default value used. >> >> 1: Horizontal flip operation >> >> R1, R0 = Rotation: indicates the rotation of the video as >> transmitted on the link. The receiver should rotate the video to >> compensate that rotation. E.g. a 90° Counter Clockwise rotation >> should be compensated by the receiver with a 90° Clockwise >> rotation prior to displaying. >> >> Table 7.2: Rotation signalling for 2 bit granularity >> >> R1 >> >> >> >> R0 >> >> >> >> Rotation of the video as sent on the link >> >> >> >> Rotation on the receiver before display >> >> 0 >> >> >> >> 0 >> >> >> >> 0° rotation >> >> >> >> None >> >> 0 >> >> >> >> 1 >> >> >> >> 90° Counter Clockwise (CCW) rotation or 270° Clockwise (CW) rotation >> >> >> >> 90° CW rotation >> >> 1 >> >> >> >> 0 >> >> >> >> 180° CCW rotation or 180° CW rotation >> >> >> >> 180° CW rotation >> >> 1 >> >> >> >> 1 >> >> >> >> 270° CCW rotation or 90° CW rotation >> >> >> >> 90° CCW rotation >> >> CVO information for a higher granularity of Rotation >> (corresponding to urn:3GPP:video-orientation:6) is carried as a >> byteformatted as follows:** >> >> Bit#76543210(LSB) >> DefinitionR5R4R3R2CFR1R0 >> >> where Cand Fare as defined above and the bits R5,R4,R3,R2,R1,R0 >> represent the Rotation, which indicates the rotation of the video >> as transmitted on the link. Table 7.3 describes the rotation to >> be applied by the receiver based on the rotation bits. >> >> Table 7.3: Rotation signalling for 6 bit granularity >> >> R1 >> >> >> >> R0 >> >> >> >> R5 >> >> >> >> R4 >> >> >> >> R3 >> >> >> >> R2 >> >> >> >> Rotation of the video as sent on the link >> >> >> >> Rotation on the receiver before display >> >> 0 >> >> >> >> 0 >> >> >> >> 0 >> >> >> >> 0 >> >> >> >> 0 >> >> >> >> 0 >> >> >> >> 0° rotation >> >> >> >> None >> >> 0 >> >> >> >> 0 >> >> >> >> 0 >> >> >> >> 0 >> >> >> >> 0 >> >> >> >> 1 >> >> >> >> (360/64)° Counter Clockwise (CCW) rotation >> >> >> >> (360/64)° CW rotation >> >> 0 >> >> >> >> 0 >> >> >> >> 0 >> >> >> >> 0 >> >> >> >> 1 >> >> >> >> 0 >> >> >> >> (2*360/64)° CCW rotation >> >> >> >> (2*360/64)° CW rotation >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> >> >> *.* >> >> 1 >> >> >> >> 1 >> >> >> >> 1 >> >> >> >> 1 >> >> >> >> 1 >> >> >> >> 0 >> >> >> >> (62*360/64)° CCW rotation >> >> >> >> (2*360/64)° CCW rotation >> >> 1 >> >> >> >> 1 >> >> >> >> 1 >> >> >> >> 1 >> >> >> >> 1 >> >> >> >> 1 >> >> >> >> (63*360/64)° CCW rotation >> >> >> >> (360/64)° CCW rotation >> >> Best regards >> Sergio >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------080400040404050202020203 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks Justin!

Was not aware of it as I didn't saw any feedback on the mailing list. Sometimes is difficult to be up to date with latest changes :)

Best regards
Sergio
On 29/04/2015 21:31, Justin Uberti wrote:
CVO is part of the rtcweb-video requirements.

On Mon, Apr 27, 2015 at 2:31 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Hi all,


I have just seen that Chrome 43 has added CVO as per my suggestion in the message below

  • Issue 4145 Added support for CVO (Coordination of video rotation) header extension in webrtc. When both sides support CVO, device rotation will not cause a new key-frame.

          https://code.google.com/p/webrtc/issues/detail?id=4145


I have always thought that it would be a nice addition to the WebRTC requirements,  especially in terms of mobile performance and user experience (at least in theory). Would it be possible if anyone from the Chrome team could share some feedback about it's usage in the real life?

Best regards
Sergio

On 29/09/2013 0:08, Sergio Garcia Murillo wrote:
Hi all,

Currently, in order to keep image property displayed on the  receiver side if the sender rotates the phone (and the camera), it is needed that the sender rotates the image from WxH to HxW so it is sent in upward position over the wire. Also, if the receiver is a mobile phone and has it rotated, it will have to rotate it again to match the current phone orientation.

How about using Coordination of Video Orientation as in 3GPP TS 26.114 (http://www.3gpp.org/ftp/Specs/html-info/26114.htm)?

Coordination of Video Orientation consists in signalling of the current orientation of the image captured on the sender side to the receiver for appropriate rendering and displaying. When CVO is succesfully negotiated it shall be signalled by the MTSI client. The signalling of the CVO uses RTP Header Extensions as specified in IETF RFC 5285 [95]. The one-byte form of the header shall be used. CVO information for a 2 bit granularity of Rotation (corresponding to urn:3gpp:video-orientation) is carried as a byte formatted as follows:

Bit#                   7                 6                 5                 4               3                 2                 1                 0(LSB)
Definition      0           0           0           0           C          F           R1          R0

With the following definitions:

C = Camera: indicates the direction of the camera used for this video stream. It can be used by the MTSI client in receiver to e.g. display the received video differently depending on the source camera.

    0: Front-facing camera, facing the user. If camera direction is unknown by the sending MTSI client in the terminal then this is the default value used.

1: Back-facing camera, facing away from the user.

F = Flip: indicates a horizontal (left-right flip) mirror operation on the video as sent on the link.

    0: No flip operation. If the sending MTSI client in terminal does not know if a horizontal mirror operation is necessary, then this is the default value used.

    1: Horizontal flip operation

R1, R0 = Rotation: indicates the rotation of the video as transmitted on the link. The receiver should rotate the video to compensate that rotation. E.g. a 90° Counter Clockwise rotation should be compensated by the receiver with a 90° Clockwise rotation prior to displaying.

Table 7.2: Rotation signalling for 2 bit granularity

R1

R0

Rotation of the video as sent on the link

Rotation on the receiver before display

0

0

0° rotation

None

0

1

90° Counter Clockwise (CCW) rotation or 270° Clockwise (CW) rotation

90° CW rotation

1

0

180° CCW rotation or 180° CW rotation

180° CW rotation

1

1

270° CCW rotation or 90° CW rotation

90° CCW rotation

 

CVO information for a higher granularity of Rotation (corresponding to urn:3GPP:video-orientation:6) is carried as a byte  formatted as follows:

Bit#                   7                 6                 5                 4               3                 2                 1                 0(LSB)
Definition      R5          R4          R3          R2          C          F           R1          R0

where C and F are as defined above and the bits R5,R4,R3,R2,R1,R0 represent the Rotation, which indicates the rotation of the video as transmitted on the link. Table 7.3 describes the rotation to be applied by the receiver based on the rotation bits.

Table 7.3: Rotation signalling for 6 bit granularity

R1

R0

R5

R4

R3

R2

Rotation of the video as sent on the link

Rotation on the receiver before display

0

0

0

0

0

0

0° rotation

None

0

0

0

0

0

1

(360/64)° Counter Clockwise (CCW) rotation

(360/64)° CW rotation

0

0

0

0

1

0

(2*360/64)° CCW rotation

(2*360/64)° CW rotation

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

1

1

1

1

1

0

(62*360/64)° CCW rotation

(2*360/64)° CCW rotation

1

1

1

1

1

1

(63*360/64)° CCW rotation

(360/64)° CCW rotation

 

Best regards
Sergio



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



--------------080400040404050202020203-- From nobody Wed Apr 29 16: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 DA2541A8AEC for ; Wed, 29 Apr 2015 16:54:57 -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 vMmPYI6D5XYP for ; Wed, 29 Apr 2015 16:54:56 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001: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 2EC051A8AEA for ; Wed, 29 Apr 2015 16:54:56 -0700 (PDT) Received: by iejt8 with SMTP id t8so55389596iej.2 for ; Wed, 29 Apr 2015 16:54:55 -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=DiLbqjC4QrzGPcDJ7/Ziy77vdPOnBBOF7plV8IpSl0U=; b=lx2S8p/FIU/G6+pel3pjohuzE5xAf+jZFORjGczvtEb7CLrRCI3gNhdrCBpzOBeG2c qyvErLfgRY5ktqREZ9xMcUY2Qe1uGQrllTvCOK2khbZOnE0CeBhp0OaY+nf4eEfLPVMI 14iZDqwM3bqfbjmTTYuqVHBCMleANO2Rxo3NV0qMPRHMYPw1ZWIOzsISBRlAy3+OQygq FSDadIUzfAco6eKWj22qYJPv8TQjfmhBHrEGMonGJUUCw7OsYztrw25pU2b56ItBz4U6 +rykbACjC1cchyrplQuRBVzGKT2rFBemfzhPqNe+qOLkK7yShmKzsLTp8kAUuUPjnGAV DufA== 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=DiLbqjC4QrzGPcDJ7/Ziy77vdPOnBBOF7plV8IpSl0U=; b=SJllRjv1gpZiK11YRjyeH5fn16L5WN9u49I28hw3ZL6qCvZ01vaOf507y++4mWrBE+ WsrY6sHActZhe1rNQqtRcRJSfmSzOLDDUnGY37vhpy0A0wkgqR6Dq6pwXpppMwhK/RXY a8CHyzYuNlPWJukVG6M6S0NGOPVc8uzELzlbBQJGgbJ7CUXazBdIJQpfHqSMQUHrCOHE NIR2KlFn/yGRJ+fp/u21mFgs+HSmWg1ScBxUyr0Ss2s/3KPCbWkMTIswYi55kiXoTfDp Yt5l1VUSGkLnDLlet+6eg4sqWtUCHFA4Og0gDEbzzhooqZOqE4CIlAo1K4b/vSM4G2ti GUTQ== X-Gm-Message-State: ALoCoQkiht92jg8bWxk2DrwMBFHJwiE8WaFpRSPhD1U7fJAtU2myeu3A/pEv+P3646rJavjOtD3x X-Received: by 10.107.128.149 with SMTP id k21mr2072366ioi.7.1430351695527; Wed, 29 Apr 2015 16:54:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.233 with HTTP; Wed, 29 Apr 2015 16:54:35 -0700 (PDT) In-Reply-To: <91729460-43E8-43A2-8A95-57513EBC03B2@iii.ca> References: <91729460-43E8-43A2-8A95-57513EBC03B2@iii.ca> From: Justin Uberti Date: Wed, 29 Apr 2015 16:54:35 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a113f9224b75cf60514e5b4db Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Importance of local addresses in ICE 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, 29 Apr 2015 23:54:58 -0000 --001a113f9224b75cf60514e5b4db Content-Type: text/plain; charset=UTF-8 Are you referring to our proposal where we surface the single host IP used for contacting the STUN/TURN servers, or surfacing all host IPs? I generally agree that surfacing a single host IP is important, especially given CGN as you mention, but surfacing all may have fingerprinting implications. It would be good to get empirical data on how often host-host occurs in the wild - if anyone is running a WebRTC service with p2p calls and can get data on the %age of host-host candidate calls, that would be greatly appreciated. (Hangouts is client-server.) On Sun, Apr 26, 2015 at 8:24 PM, Cullen Jennings wrote: > There has been some suggestion that the ICE should not advertise > candidates that were addresses from a NATed address space. I think it is > critical that we do and here is why. > > Carrier Grade NATs (CGN) are becoming far more common in many countries. > Most measures of them show they are not friendly towards over the top VoIP > traffic (totally shocker given they are often deployed by people offering a > commercial voice service as well). So when you have two user both behind > the same GCN, if ICE does not expose the local address, all of the traffic > is forced thought the GCN (which may have more jitter than you might hope) > and to a TURN server. If the ICE contained the local candidates then media > would go directly through between the devices. > > CGN while not that common in the US is prevalent in many countries - > particularly ones that had less IPv4 addressed allocated to them. > > Now you can say that this might reveal some information about their IP > address. But think about what we really wish the wold looked like. There > was no NAT and they had a IPv6 address. I have a hard time seeing how to > DHCP generated address behind the NAT is hugely different than a random > allocated v6 address so I don't see much downside on doing this and I see > huge upside - particularly for people that are working of a cellular data > link behind a CGN. > > I am also think that in general, end to end is better for privacy than > forcing all your data through a MITM that the user does not control (the > TURN server and CGN in this case). > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113f9224b75cf60514e5b4db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Are you referring to our proposal where we surface the sin= gle host IP used for contacting the STUN/TURN servers, or surfacing all hos= t IPs? I generally agree that surfacing a single host IP is important, espe= cially given CGN as you mention, but surfacing all may have fingerprinting = implications.

It would be good to get empirical data on = how often host-host occurs in the wild - if anyone is running a WebRTC serv= ice with p2p calls and can get data on the %age of host-host candidate call= s, that would be greatly appreciated. (Hangouts is client-server.)

=
On Sun, A= pr 26, 2015 at 8:24 PM, Cullen Jennings <fluffy@iii.ca> wrote:
There has been some suggestion that the IC= E should not advertise candidates that were addresses from a NATed address = space. I think it is critical that we do and here is why.

Carrier Grade NATs (CGN) are becoming far more common in many countries. Mo= st measures of them show they are not friendly towards over the top VoIP tr= affic (totally shocker given they are often deployed by people offering a c= ommercial voice service as well). So when you have two user both behind the= same GCN, if ICE does not expose the local address, all of the traffic is = forced thought the GCN (which may have more jitter than you might hope) and= to a TURN server. If the ICE contained the local candidates then media wou= ld go directly through between the devices.

CGN while not that common in the US is prevalent in many countries - partic= ularly ones that had less IPv4 addressed allocated to them.

Now you can say that this might reveal some information about their IP addr= ess. But think about what we really wish the wold looked like. There was no= NAT and they had a IPv6 address. I have a hard time seeing how to DHCP gen= erated address behind the NAT is hugely different than a random allocated v= 6 address so I don't see much downside on doing this and I see huge ups= ide - particularly for people that are working of a cellular data link behi= nd a CGN.

I am also think that in general, end to end is better for privacy than forc= ing all your data through a MITM that the user does not control (the TURN s= erver and CGN in this case).





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

--001a113f9224b75cf60514e5b4db-- From nobody Thu Apr 30 01:10: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 C342C1ACF19 for ; Thu, 30 Apr 2015 01:10:52 -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 0qaoxFUjWTvt for ; Thu, 30 Apr 2015 01:10:50 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id C44651ACF18 for ; Thu, 30 Apr 2015 01:10:34 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id DEC0823F0403; Thu, 30 Apr 2015 10:10:33 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.54]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0224.002; Thu, 30 Apr 2015 10:10:33 +0200 From: "Hutton, Andrew" To: Harald Alvestrand , Gaelle Martin-Cocher , "Rauschenbach, Uwe (Nokia - DE/Munich)" , Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways Thread-Index: AQHQeHFa5bXT8KfOaES0di1Z0MxN+Z1SiFYAgAJtjACABB1wYIAACoyAgAsSGNCAABhwAIABAJzw Date: Thu, 30 Apr 2015 08:10:33 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E754711@MCHP04MSX.global-ad.net> References: , <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> <5537CA1F.1060209@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E75341E@MCHP04MSX.global-ad.net> <55412808.7040409@alvestrand.no> In-Reply-To: <55412808.7040409@alvestrand.no> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-alvestrand-rtcweb-gateways@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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 Apr 2015 08:10:52 -0000 I do support adoption of the draft as an informational draft. Andy > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: 29 April 2015 19:51 > To: Hutton, Andrew; Gaelle Martin-Cocher; Rauschenbach, Uwe (Nokia - > DE/Munich); Sean Turner; rtcweb@ietf.org > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- > gateways >=20 > Den 29. april 2015 17:27, skrev Hutton, Andrew: > > So to be clear my understanding is that the draft status will be > changed to "Informational" and the abstract will be changed to remove > the statement about specifying "conformance requirements". Is that > correct? > > > > The draft is therefore not intended to specify conformance > requirements but will provide implementation guidance. > > >=20 > Yes, that's my plan. >=20 >=20 > > Regards > > Andy > > > > > > > >> -----Original Message----- > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > >> Alvestrand > >> Sent: 22 April 2015 17:20 > >> To: Gaelle Martin-Cocher; Rauschenbach, Uwe (Nokia - DE/Munich); > Sean > >> Turner; rtcweb@ietf.org > >> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > >> Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- > >> gateways > >> > >> Den 22. april 2015 17:36, skrev Gaelle Martin-Cocher: > >>> Dear all, > >>> > >>> I do have some concerns with this proposal. > >>> From https://www.ietf.org/mail- > >> archive/web/rtcweb/current/msg13885.html > >>> I was under impression that the gateway would be an informational > >> draft and there was no desire to specify conformance requirements. > >>> > >>> The current text describes high level functions that can be > expected > >> from a gateway but does not define clearly what would be required to > >> conform to. > >>> If the intend of the draft is to specify conformance requirements > >> (first sentence of the abstract) there could be more requirements to > >> relax and the current requirements would need to be define more > >> clearly. > >>> Is it the intend? > >> > >> I have not updated the intro - I think feedback was reasonably clear > >> that an informational document was wanted, we want to give advice, > but > >> not to dictate what implementations do. > >> > >>> > >>> If it is, here are some examples: > >>> While the WebRTC Gateway is described in the abstract (but not > only, > >> see section 1) as "a class of > >>> WebRTC-compatible endpoints called "WebRTC gateways" ", section > 2 > >> states that WebRTC gateway are "expected to conform to the > requirements > >> for WebRTC non-browsers in [I-D.ietf-rtcweb-overview], with the > >> exceptions defined in this section" > >>> > >>> Wouldn't it be clearer to just define the WebRTC gateway from the > >> WebRTC non-browser rather than from an unspecified WebRTC-compatible > >> endpoint? > >>> It might provide a better understanding of what the gateway should > be > >> conforming to. > >>> > >>> Requirements in 2, either: > >>> - are clear: e.g. the gateway MUST support DTLS-SRTP > >>> - describe what the gateway MAY NOT support....see second to last > >> paragraph > >>> - or leave some ambiguity: The gateway does not have to do X (e.g. > >> full ICE); so it may do Y (e.g. ICE-Lite). > >>> Playing devil's advocate: can there be a gateway doing yet > something > >> else? > >>> What would it conform to? > >>> > >>> Shouldn't the requirement be reworded to state what the gateway MAY > >> or SHALL do/support.... and conform to? > >>> > >>> Section 1.1 and 1.2 seems unclear if meant to belong to a > conformance > >> requirements draft. > >>> > >>> > >>> It is unclear to me if the purpose of the draft is to define > >> conformance requirements for WebRTC gateway, or is to focus on > relaxing > >> some requirements for gateways as per section 2, or is an > informational > >> description of what can be expected from a WebRTC 'compatible' > gateway. > >>> > >>> > >>> Sincerely, > >>> Ga=EBlle > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > >> Rauschenbach, Uwe (Nokia - DE/Munich) > >>> Sent: Sunday, April 19, 2015 2:52 PM > >>> To: ext Harald Alvestrand; Sean Turner; rtcweb@ietf.org > >>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > >>> Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand- > rtcweb- > >> gateways > >>> > >>> +1 for adoption. > >>> > >>> The same question that Harald raised came to my mind - there was > >> another adoption call end of last year with a lot of support > >> (https://www.ietf.org/mail- > archive/web/rtcweb/current/msg14050.html). > >>> > >>> Kind regards, > >>> Uwe > >>> > >>> ________________________________________ > >>> Von: rtcweb [rtcweb-bounces@ietf.org]" im Auftrag von > "ext > >> Harald Alvestrand [harald@alvestrand.no] > >>> Gesendet: Samstag, 18. April 2015 07:46 > >>> An: Sean Turner; rtcweb@ietf.org > >>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > >>> Betreff: Re: [rtcweb] WG call for adoption: draft-alvestrand- > rtcweb- > >> gateways > >>> > >>> On 04/16/2015 08:15 PM, Sean Turner wrote: > >>>> All, > >>>> > >>>> There's been some interest expressed in having > >> http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ > >> adopted as an RTCWeb WG item. Please respond to say whether you > >> support adoption of this work as a working group work item and > whether > >> you will participate in the discussion. If you are opposed to this > >> draft becoming a WG document, please say so (and say why). Please > have > >> your response in by 20150423 23:59 UTC. > >>>> > >>>> Thanks in advance! > >>>> > >>>> spt > >>> Naturally, I support adoption. > >>> > >>> Question: Is this a repeat of the exercise on which Cullen reported > >> consensus for adoption in December 2014, or is this a side effect of > >> starting fomal tracking of adoption status? > >>> > >>> -- > >>> Surveillance is pervasive. Go Dark. > >>> > >>> _______________________________________________ > >>> 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 From nobody Thu Apr 30 01:30: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 6C0001AD05C for ; Thu, 30 Apr 2015 01:30:31 -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 gWgYJ4-nuUMe for ; Thu, 30 Apr 2015 01:30:29 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5A11AD059 for ; Thu, 30 Apr 2015 01:30:29 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 733ED23F058F; Thu, 30 Apr 2015 10:30:28 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.54]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0224.002; Thu, 30 Apr 2015 10:30:27 +0200 From: "Hutton, Andrew" To: Harald Alvestrand , "Rauschenbach, Uwe (Nokia - DE/Munich)" , "rtcweb@ietf.org" Thread-Topic: rtcweb-gateways- Statis IP Address Comment Thread-Index: AQHQgx/pXiFFWqJNpkG9pL4WTR9CtQ== Date: Thu, 30 Apr 2015 08:30:27 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E7547BD@MCHP04MSX.global-ad.net> References: , <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> <5537CA1F.1060209@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E75341E@MCHP04MSX.global-ad.net> <55412808.7040409@alvestrand.no> In-Reply-To: <55412808.7040409@alvestrand.no> 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] rtcweb-gateways- Statis IP Address 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: Thu, 30 Apr 2015 08:30:31 -0000 Section 2 contains the following text: "Since a gateway is expected to be deployed where it can be reached with a = static IP address (as seen from the client), a WebRTC gateway does not need= to support full ICE; it therefore MAY implement ICE-Lite only". It might be a minor comment but I think it is wrong to say that a gateway "= is expected to be deployed where it can be reached with a static IP address= " and this gives the wrong impression. A gateway might be deployed in such a way but I would not say it is expecte= d to be deployed that way. So I suggest the following text. "A WebRTC gateway which is deployed where it can be reached with a static I= P address (as seen from the client), does not need to support full ICE; it = therefore MAY implement ICE-Lite only". Regards Andy From nobody Thu Apr 30 06:18: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 9505A1B29DE for ; Thu, 30 Apr 2015 06:18:02 -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 VXQ9w4odwBr3 for ; Thu, 30 Apr 2015 06:18:00 -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 B5EA81A8A1B for ; Thu, 30 Apr 2015 06:17:59 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A843B836A9DD8; Thu, 30 Apr 2015 13:17:55 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3UDHq5q001066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Apr 2015 15:17:56 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 30 Apr 2015 15:17:55 +0200 From: "DRAGE, Keith (Keith)" To: "Hutton, Andrew" , Harald Alvestrand , Gaelle Martin-Cocher , "Rauschenbach, Uwe (Nokia - DE/Munich)" , "Sean Turner" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways Thread-Index: AQHQeHFZk/kiDbUe00yMhhi49ry8lp1SiFYAgAJtjACABB1wYIAACoyAgAsSGNCAABhwAIAA33KAgABuvyA= Date: Thu, 30 Apr 2015 13:17:53 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6970CD26@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: , <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> <5537CA1F.1060209@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E75341E@MCHP04MSX.global-ad.net> <55412808.7040409@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E754711@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E754711@MCHP04MSX.global-ad.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-alvestrand-rtcweb-gateways@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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 Apr 2015 13:18:02 -0000 I remain to be convinced that this should be entirely informational. I suspect a mixture of conditional conformable requirements and information= al material may be what we end up with. For example, if the gateway terminates the datachannel, then the gateway MU= ST support the requirements of the datachannel document. If the gateway per= forms trascoding, or other interference with the RTP stream, then the gatew= ay MUST support the requirements of rtp-usage document. >From an external referencing perspective, it does not matter whether it is = informational or standards track, but the important point to me is that the= document can and will contain normative requirements where appropriate. Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Hutton, Andrew > Sent: 30 April 2015 09:11 > To: Harald Alvestrand; Gaelle Martin-Cocher; Rauschenbach,=20 > Uwe (Nokia - DE/Munich); Sean Turner; rtcweb@ietf.org > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > Subject: Re: [rtcweb] WG call for adoption:=20 > draft-alvestrand-rtcweb-gateways >=20 > I do support adoption of the draft as an informational draft. >=20 > Andy >=20 >=20 >=20 > > -----Original Message----- > > From: Harald Alvestrand [mailto:harald@alvestrand.no] > > Sent: 29 April 2015 19:51 > > To: Hutton, Andrew; Gaelle Martin-Cocher; Rauschenbach, Uwe=20 > (Nokia -=20 > > DE/Munich); Sean Turner; rtcweb@ietf.org > > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > Subject: Re: [rtcweb] WG call for adoption:=20 > draft-alvestrand-rtcweb-=20 > > gateways > >=20 > > Den 29. april 2015 17:27, skrev Hutton, Andrew: > > > So to be clear my understanding is that the draft status will be > > changed to "Informational" and the abstract will be changed=20 > to remove=20 > > the statement about specifying "conformance requirements". Is that=20 > > correct? > > > > > > The draft is therefore not intended to specify conformance > > requirements but will provide implementation guidance. > > > > >=20 > > Yes, that's my plan. > >=20 > >=20 > > > Regards > > > Andy > > > > > > > > > > > >> -----Original Message----- > > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf=20 > Of Harald=20 > > >> Alvestrand > > >> Sent: 22 April 2015 17:20 > > >> To: Gaelle Martin-Cocher; Rauschenbach, Uwe (Nokia - DE/Munich); > > Sean > > >> Turner; rtcweb@ietf.org > > >> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > >> Subject: Re: [rtcweb] WG call for adoption:=20 > > >> draft-alvestrand-rtcweb- gateways > > >> > > >> Den 22. april 2015 17:36, skrev Gaelle Martin-Cocher: > > >>> Dear all, > > >>> > > >>> I do have some concerns with this proposal. > > >>> From https://www.ietf.org/mail- > > >> archive/web/rtcweb/current/msg13885.html > > >>> I was under impression that the gateway would be an=20 > informational > > >> draft and there was no desire to specify conformance=20 > requirements. > > >>> > > >>> The current text describes high level functions that can be > > expected > > >> from a gateway but does not define clearly what would be=20 > required=20 > > >> to conform to. > > >>> If the intend of the draft is to specify conformance=20 > requirements > > >> (first sentence of the abstract) there could be more=20 > requirements=20 > > >> to relax and the current requirements would need to be=20 > define more=20 > > >> clearly. > > >>> Is it the intend? > > >> > > >> I have not updated the intro - I think feedback was reasonably=20 > > >> clear that an informational document was wanted, we want to give=20 > > >> advice, > > but > > >> not to dictate what implementations do. > > >> > > >>> > > >>> If it is, here are some examples: > > >>> While the WebRTC Gateway is described in the abstract (but not > > only, > > >> see section 1) as "a class of > > >>> WebRTC-compatible endpoints called "WebRTC gateways"=20 > ", section > > 2 > > >> states that WebRTC gateway are "expected to conform to the > > requirements > > >> for WebRTC non-browsers in [I-D.ietf-rtcweb-overview], with the=20 > > >> exceptions defined in this section" > > >>> > > >>> Wouldn't it be clearer to just define the WebRTC=20 > gateway from the > > >> WebRTC non-browser rather than from an unspecified=20 > > >> WebRTC-compatible endpoint? > > >>> It might provide a better understanding of what the=20 > gateway should > > be > > >> conforming to. > > >>> > > >>> Requirements in 2, either: > > >>> - are clear: e.g. the gateway MUST support DTLS-SRTP > > >>> - describe what the gateway MAY NOT support....see=20 > second to last > > >> paragraph > > >>> - or leave some ambiguity: The gateway does not have to=20 > do X (e.g. > > >> full ICE); so it may do Y (e.g. ICE-Lite). > > >>> Playing devil's advocate: can there be a gateway doing yet > > something > > >> else? > > >>> What would it conform to? > > >>> > > >>> Shouldn't the requirement be reworded to state what the gateway=20 > > >>> MAY > > >> or SHALL do/support.... and conform to? > > >>> > > >>> Section 1.1 and 1.2 seems unclear if meant to belong to a > > conformance > > >> requirements draft. > > >>> > > >>> > > >>> It is unclear to me if the purpose of the draft is to define > > >> conformance requirements for WebRTC gateway, or is to focus on > > relaxing > > >> some requirements for gateways as per section 2, or is an > > informational > > >> description of what can be expected from a WebRTC 'compatible' > > gateway. > > >>> > > >>> > > >>> Sincerely, > > >>> Ga=EBlle > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > > >> Rauschenbach, Uwe (Nokia - DE/Munich) > > >>> Sent: Sunday, April 19, 2015 2:52 PM > > >>> To: ext Harald Alvestrand; Sean Turner; rtcweb@ietf.org > > >>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > >>> Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand- > > rtcweb- > > >> gateways > > >>> > > >>> +1 for adoption. > > >>> > > >>> The same question that Harald raised came to my mind - there was > > >> another adoption call end of last year with a lot of support > > >> (https://www.ietf.org/mail- > > archive/web/rtcweb/current/msg14050.html). > > >>> > > >>> Kind regards, > > >>> Uwe > > >>> > > >>> ________________________________________ > > >>> Von: rtcweb [rtcweb-bounces@ietf.org]" im Auftrag von > > "ext > > >> Harald Alvestrand [harald@alvestrand.no] > > >>> Gesendet: Samstag, 18. April 2015 07:46 > > >>> An: Sean Turner; rtcweb@ietf.org > > >>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > >>> Betreff: Re: [rtcweb] WG call for adoption: draft-alvestrand- > > rtcweb- > > >> gateways > > >>> > > >>> On 04/16/2015 08:15 PM, Sean Turner wrote: > > >>>> All, > > >>>> > > >>>> There's been some interest expressed in having > > >> http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ > > >> adopted as an RTCWeb WG item. Please respond to say whether you=20 > > >> support adoption of this work as a working group work item and > > whether > > >> you will participate in the discussion. If you are=20 > opposed to this > > >> draft becoming a WG document, please say so (and say=20 > why). Please > > have > > >> your response in by 20150423 23:59 UTC. > > >>>> > > >>>> Thanks in advance! > > >>>> > > >>>> spt > > >>> Naturally, I support adoption. > > >>> > > >>> Question: Is this a repeat of the exercise on which Cullen=20 > > >>> reported > > >> consensus for adoption in December 2014, or is this a=20 > side effect=20 > > >> of starting fomal tracking of adoption status? > > >>> > > >>> -- > > >>> Surveillance is pervasive. Go Dark. > > >>> > > >>> _______________________________________________ > > >>> 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Thu Apr 30 06:18: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 F3B3D1A8A1B for ; Thu, 30 Apr 2015 06:18:02 -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 TP6hFWz-G93J for ; Thu, 30 Apr 2015 06:18:00 -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 72D6F1B29D8 for ; Thu, 30 Apr 2015 06:18:00 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 8FCE3B24858CE; Thu, 30 Apr 2015 13:17:56 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3UDHqjA001049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Apr 2015 15:17:58 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 30 Apr 2015 15:17:55 +0200 From: "DRAGE, Keith (Keith)" To: Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways Thread-Index: AQHQeHFZk/kiDbUe00yMhhi49ry8lp1ll8Dg Date: Thu, 30 Apr 2015 13:17:55 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6970CD2E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-alvestrand-rtcweb-gateways@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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 Apr 2015 13:18:03 -0000 I support this draft, but I was also under the impression that adoption had= already been agreed. Therefore this call seems to be yet another excuse for delaying work on thi= s document. Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sean Turner > Sent: 16 April 2015 19:15 > To: rtcweb@ietf.org > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > Subject: [rtcweb] WG call for adoption:=20 > draft-alvestrand-rtcweb-gateways >=20 > All, >=20 > There's been some interest expressed in having=20 > http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gatewa > ys/ adopted as an RTCWeb WG item. Please respond to say=20 > whether you support adoption of this work as a working group=20 > work item and whether you will participate in the discussion.=20 > If you are opposed to this draft becoming a WG document,=20 > please say so (and say why). Please have your response in by=20 > 20150423 23:59 UTC. >=20 > Thanks in advance! >=20 > spt > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Thu Apr 30 08: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 DAD431A038A for ; Thu, 30 Apr 2015 08:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ejyiBwIIjJ4G for ; Thu, 30 Apr 2015 08:17:06 -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 8F5691A01F0 for ; Thu, 30 Apr 2015 08:17:06 -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 t3UFGrDN020926 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Apr 2015 15:16:53 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t3UFGp7g005651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Apr 2015 17:16:51 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.119]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0235.001; Thu, 30 Apr 2015 17:16:51 +0200 From: "Rauschenbach, Uwe (Nokia - DE/Munich)" To: "ext DRAGE, Keith (Keith)" , "Hutton, Andrew" , Harald Alvestrand , Gaelle Martin-Cocher , Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways Thread-Index: AQHQeHFYVWMgQ5c0+UWIb1btRq1l3Z1SI8EAgAKN7AKABGAmgIAADAuAgArxooCAADjmAIAA33KAgABV34CAAEGAMA== Date: Thu, 30 Apr 2015 15:16:50 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF819649F40@DEMUMBX005.nsn-intra.net> References: , <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> <5537CA1F.1060209@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E75341E@MCHP04MSX.global-ad.net> <55412808.7040409@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E754711@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8B6970CD26@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6970CD26@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: [10.159.42.109] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: 9161 X-purgate-ID: 151667::1430407015-00002D61-D674E6F0/0/0 Archived-At: Cc: "draft-alvestrand-rtcweb-gateways@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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 Apr 2015 15:17:11 -0000 I agree.=20 This draft contains informative parts and requirements to gateway implement= ations - and it needs to be able to express these in normative language. Kind regards, Uwe=20 -----Original Message----- From: ext DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Sent: Thursday, April 30, 2015 3:18 PM To: Hutton, Andrew; Harald Alvestrand; Gaelle Martin-Cocher; Rauschenbach, = Uwe (Nokia - DE/Munich); Sean Turner; rtcweb@ietf.org Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org Subject: RE: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateway= s I remain to be convinced that this should be entirely informational. I suspect a mixture of conditional conformable requirements and information= al material may be what we end up with. For example, if the gateway terminates the datachannel, then the gateway MU= ST support the requirements of the datachannel document. If the gateway per= forms trascoding, or other interference with the RTP stream, then the gatew= ay MUST support the requirements of rtp-usage document. >From an external referencing perspective, it does not matter whether it is = informational or standards track, but the important point to me is that the= document can and will contain normative requirements where appropriate. Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Hutton, Andrew > Sent: 30 April 2015 09:11 > To: Harald Alvestrand; Gaelle Martin-Cocher; Rauschenbach,=20 > Uwe (Nokia - DE/Munich); Sean Turner; rtcweb@ietf.org > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > Subject: Re: [rtcweb] WG call for adoption:=20 > draft-alvestrand-rtcweb-gateways >=20 > I do support adoption of the draft as an informational draft. >=20 > Andy >=20 >=20 >=20 > > -----Original Message----- > > From: Harald Alvestrand [mailto:harald@alvestrand.no] > > Sent: 29 April 2015 19:51 > > To: Hutton, Andrew; Gaelle Martin-Cocher; Rauschenbach, Uwe=20 > (Nokia -=20 > > DE/Munich); Sean Turner; rtcweb@ietf.org > > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > Subject: Re: [rtcweb] WG call for adoption:=20 > draft-alvestrand-rtcweb-=20 > > gateways > >=20 > > Den 29. april 2015 17:27, skrev Hutton, Andrew: > > > So to be clear my understanding is that the draft status will be > > changed to "Informational" and the abstract will be changed=20 > to remove=20 > > the statement about specifying "conformance requirements". Is that=20 > > correct? > > > > > > The draft is therefore not intended to specify conformance > > requirements but will provide implementation guidance. > > > > >=20 > > Yes, that's my plan. > >=20 > >=20 > > > Regards > > > Andy > > > > > > > > > > > >> -----Original Message----- > > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf=20 > Of Harald=20 > > >> Alvestrand > > >> Sent: 22 April 2015 17:20 > > >> To: Gaelle Martin-Cocher; Rauschenbach, Uwe (Nokia - DE/Munich); > > Sean > > >> Turner; rtcweb@ietf.org > > >> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > >> Subject: Re: [rtcweb] WG call for adoption:=20 > > >> draft-alvestrand-rtcweb- gateways > > >> > > >> Den 22. april 2015 17:36, skrev Gaelle Martin-Cocher: > > >>> Dear all, > > >>> > > >>> I do have some concerns with this proposal. > > >>> From https://www.ietf.org/mail- > > >> archive/web/rtcweb/current/msg13885.html > > >>> I was under impression that the gateway would be an=20 > informational > > >> draft and there was no desire to specify conformance=20 > requirements. > > >>> > > >>> The current text describes high level functions that can be > > expected > > >> from a gateway but does not define clearly what would be=20 > required=20 > > >> to conform to. > > >>> If the intend of the draft is to specify conformance=20 > requirements > > >> (first sentence of the abstract) there could be more=20 > requirements=20 > > >> to relax and the current requirements would need to be=20 > define more=20 > > >> clearly. > > >>> Is it the intend? > > >> > > >> I have not updated the intro - I think feedback was reasonably=20 > > >> clear that an informational document was wanted, we want to give=20 > > >> advice, > > but > > >> not to dictate what implementations do. > > >> > > >>> > > >>> If it is, here are some examples: > > >>> While the WebRTC Gateway is described in the abstract (but not > > only, > > >> see section 1) as "a class of > > >>> WebRTC-compatible endpoints called "WebRTC gateways"=20 > ", section > > 2 > > >> states that WebRTC gateway are "expected to conform to the > > requirements > > >> for WebRTC non-browsers in [I-D.ietf-rtcweb-overview], with the=20 > > >> exceptions defined in this section" > > >>> > > >>> Wouldn't it be clearer to just define the WebRTC=20 > gateway from the > > >> WebRTC non-browser rather than from an unspecified=20 > > >> WebRTC-compatible endpoint? > > >>> It might provide a better understanding of what the=20 > gateway should > > be > > >> conforming to. > > >>> > > >>> Requirements in 2, either: > > >>> - are clear: e.g. the gateway MUST support DTLS-SRTP > > >>> - describe what the gateway MAY NOT support....see=20 > second to last > > >> paragraph > > >>> - or leave some ambiguity: The gateway does not have to=20 > do X (e.g. > > >> full ICE); so it may do Y (e.g. ICE-Lite). > > >>> Playing devil's advocate: can there be a gateway doing yet > > something > > >> else? > > >>> What would it conform to? > > >>> > > >>> Shouldn't the requirement be reworded to state what the gateway=20 > > >>> MAY > > >> or SHALL do/support.... and conform to? > > >>> > > >>> Section 1.1 and 1.2 seems unclear if meant to belong to a > > conformance > > >> requirements draft. > > >>> > > >>> > > >>> It is unclear to me if the purpose of the draft is to define > > >> conformance requirements for WebRTC gateway, or is to focus on > > relaxing > > >> some requirements for gateways as per section 2, or is an > > informational > > >> description of what can be expected from a WebRTC 'compatible' > > gateway. > > >>> > > >>> > > >>> Sincerely, > > >>> Ga=EBlle > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > > >> Rauschenbach, Uwe (Nokia - DE/Munich) > > >>> Sent: Sunday, April 19, 2015 2:52 PM > > >>> To: ext Harald Alvestrand; Sean Turner; rtcweb@ietf.org > > >>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > >>> Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand- > > rtcweb- > > >> gateways > > >>> > > >>> +1 for adoption. > > >>> > > >>> The same question that Harald raised came to my mind - there was > > >> another adoption call end of last year with a lot of support > > >> (https://www.ietf.org/mail- > > archive/web/rtcweb/current/msg14050.html). > > >>> > > >>> Kind regards, > > >>> Uwe > > >>> > > >>> ________________________________________ > > >>> Von: rtcweb [rtcweb-bounces@ietf.org]" im Auftrag von > > "ext > > >> Harald Alvestrand [harald@alvestrand.no] > > >>> Gesendet: Samstag, 18. April 2015 07:46 > > >>> An: Sean Turner; rtcweb@ietf.org > > >>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > >>> Betreff: Re: [rtcweb] WG call for adoption: draft-alvestrand- > > rtcweb- > > >> gateways > > >>> > > >>> On 04/16/2015 08:15 PM, Sean Turner wrote: > > >>>> All, > > >>>> > > >>>> There's been some interest expressed in having > > >> http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ > > >> adopted as an RTCWeb WG item. Please respond to say whether you=20 > > >> support adoption of this work as a working group work item and > > whether > > >> you will participate in the discussion. If you are=20 > opposed to this > > >> draft becoming a WG document, please say so (and say=20 > why). Please > > have > > >> your response in by 20150423 23:59 UTC. > > >>>> > > >>>> Thanks in advance! > > >>>> > > >>>> spt > > >>> Naturally, I support adoption. > > >>> > > >>> Question: Is this a repeat of the exercise on which Cullen=20 > > >>> reported > > >> consensus for adoption in December 2014, or is this a=20 > side effect=20 > > >> of starting fomal tracking of adoption status? > > >>> > > >>> -- > > >>> Surveillance is pervasive. Go Dark. > > >>> > > >>> _______________________________________________ > > >>> 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Thu Apr 30 08:35: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 1CE7E1B2CC7 for ; Thu, 30 Apr 2015 08:35: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 w0hG87UDc9lE for ; Thu, 30 Apr 2015 08:35:37 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 404DD1B2CC5 for ; Thu, 30 Apr 2015 08:35:37 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 2A40F23F05C3; Thu, 30 Apr 2015 17:35:36 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.54]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0224.002; Thu, 30 Apr 2015 17:35:35 +0200 From: "Hutton, Andrew" To: "Rauschenbach, Uwe (Nokia - DE/Munich)" , "ext DRAGE, Keith (Keith)" , "Harald Alvestrand" , Gaelle Martin-Cocher , Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways Thread-Index: AQHQeHFa5bXT8KfOaES0di1Z0MxN+Z1SiFYAgAJtjACABB1wYIAACoyAgAsSGNCAABhwAIABAJzwgAA0tYCAACE8AIAAJN3A Date: Thu, 30 Apr 2015 15:35:34 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E755675@MCHP04MSX.global-ad.net> References: , <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> <5537CA1F.1060209@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E75341E@MCHP04MSX.global-ad.net> <55412808.7040409@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E754711@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8B6970CD26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF819649F40@DEMUMBX005.nsn-intra.net> In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF819649F40@DEMUMBX005.nsn-intra.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-alvestrand-rtcweb-gateways@tools.ietf.org" Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways 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 Apr 2015 15:35:40 -0000 I won't lose any sleep over the classification of the draft but the definit= ion of a WebRTC Gateway is that it is a WebRTC Compatible Device (as stated= in draft-ietf-rtcweb-overview) which by definition is not constrained by t= he RTCWEB spec's. I can wait and see what normative text makes it in to the document so far w= hat I see are obvious statements that if not followed the WebRTC part of th= e gateway just would not work. Andy > -----Original Message----- > From: Rauschenbach, Uwe (Nokia - DE/Munich) > [mailto:uwe.rauschenbach@nokia.com] > Sent: 30 April 2015 16:17 > To: ext DRAGE, Keith (Keith); Hutton, Andrew; Harald Alvestrand; Gaelle > Martin-Cocher; Sean Turner; rtcweb@ietf.org > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > Subject: RE: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- > gateways >=20 > I agree. > This draft contains informative parts and requirements to gateway > implementations - and it needs to be able to express these in normative > language. >=20 > Kind regards, > Uwe >=20 > -----Original Message----- > From: ext DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Thursday, April 30, 2015 3:18 PM > To: Hutton, Andrew; Harald Alvestrand; Gaelle Martin-Cocher; > Rauschenbach, Uwe (Nokia - DE/Munich); Sean Turner; rtcweb@ietf.org > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > Subject: RE: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb- > gateways >=20 > I remain to be convinced that this should be entirely informational. >=20 > I suspect a mixture of conditional conformable requirements and > informational material may be what we end up with. >=20 > For example, if the gateway terminates the datachannel, then the > gateway MUST support the requirements of the datachannel document. If > the gateway performs trascoding, or other interference with the RTP > stream, then the gateway MUST support the requirements of rtp-usage > document. >=20 > From an external referencing perspective, it does not matter whether it > is informational or standards track, but the important point to me is > that the document can and will contain normative requirements where > appropriate. >=20 > Keith >=20 > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > > Hutton, Andrew > > Sent: 30 April 2015 09:11 > > To: Harald Alvestrand; Gaelle Martin-Cocher; Rauschenbach, > > Uwe (Nokia - DE/Munich); Sean Turner; rtcweb@ietf.org > > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > Subject: Re: [rtcweb] WG call for adoption: > > draft-alvestrand-rtcweb-gateways > > > > I do support adoption of the draft as an informational draft. > > > > Andy > > > > > > > > > -----Original Message----- > > > From: Harald Alvestrand [mailto:harald@alvestrand.no] > > > Sent: 29 April 2015 19:51 > > > To: Hutton, Andrew; Gaelle Martin-Cocher; Rauschenbach, Uwe > > (Nokia - > > > DE/Munich); Sean Turner; rtcweb@ietf.org > > > Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > > Subject: Re: [rtcweb] WG call for adoption: > > draft-alvestrand-rtcweb- > > > gateways > > > > > > Den 29. april 2015 17:27, skrev Hutton, Andrew: > > > > So to be clear my understanding is that the draft status will be > > > changed to "Informational" and the abstract will be changed > > to remove > > > the statement about specifying "conformance requirements". Is that > > > correct? > > > > > > > > The draft is therefore not intended to specify conformance > > > requirements but will provide implementation guidance. > > > > > > > > > > Yes, that's my plan. > > > > > > > > > > Regards > > > > Andy > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf > > Of Harald > > > >> Alvestrand > > > >> Sent: 22 April 2015 17:20 > > > >> To: Gaelle Martin-Cocher; Rauschenbach, Uwe (Nokia - DE/Munich); > > > Sean > > > >> Turner; rtcweb@ietf.org > > > >> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > > >> Subject: Re: [rtcweb] WG call for adoption: > > > >> draft-alvestrand-rtcweb- gateways > > > >> > > > >> Den 22. april 2015 17:36, skrev Gaelle Martin-Cocher: > > > >>> Dear all, > > > >>> > > > >>> I do have some concerns with this proposal. > > > >>> From https://www.ietf.org/mail- > > > >> archive/web/rtcweb/current/msg13885.html > > > >>> I was under impression that the gateway would be an > > informational > > > >> draft and there was no desire to specify conformance > > requirements. > > > >>> > > > >>> The current text describes high level functions that can be > > > expected > > > >> from a gateway but does not define clearly what would be > > required > > > >> to conform to. > > > >>> If the intend of the draft is to specify conformance > > requirements > > > >> (first sentence of the abstract) there could be more > > requirements > > > >> to relax and the current requirements would need to be > > define more > > > >> clearly. > > > >>> Is it the intend? > > > >> > > > >> I have not updated the intro - I think feedback was reasonably > > > >> clear that an informational document was wanted, we want to give > > > >> advice, > > > but > > > >> not to dictate what implementations do. > > > >> > > > >>> > > > >>> If it is, here are some examples: > > > >>> While the WebRTC Gateway is described in the abstract (but not > > > only, > > > >> see section 1) as "a class of > > > >>> WebRTC-compatible endpoints called "WebRTC gateways" > > ", section > > > 2 > > > >> states that WebRTC gateway are "expected to conform to the > > > requirements > > > >> for WebRTC non-browsers in [I-D.ietf-rtcweb-overview], with the > > > >> exceptions defined in this section" > > > >>> > > > >>> Wouldn't it be clearer to just define the WebRTC > > gateway from the > > > >> WebRTC non-browser rather than from an unspecified > > > >> WebRTC-compatible endpoint? > > > >>> It might provide a better understanding of what the > > gateway should > > > be > > > >> conforming to. > > > >>> > > > >>> Requirements in 2, either: > > > >>> - are clear: e.g. the gateway MUST support DTLS-SRTP > > > >>> - describe what the gateway MAY NOT support....see > > second to last > > > >> paragraph > > > >>> - or leave some ambiguity: The gateway does not have to > > do X (e.g. > > > >> full ICE); so it may do Y (e.g. ICE-Lite). > > > >>> Playing devil's advocate: can there be a gateway doing yet > > > something > > > >> else? > > > >>> What would it conform to? > > > >>> > > > >>> Shouldn't the requirement be reworded to state what the gateway > > > >>> MAY > > > >> or SHALL do/support.... and conform to? > > > >>> > > > >>> Section 1.1 and 1.2 seems unclear if meant to belong to a > > > conformance > > > >> requirements draft. > > > >>> > > > >>> > > > >>> It is unclear to me if the purpose of the draft is to define > > > >> conformance requirements for WebRTC gateway, or is to focus on > > > relaxing > > > >> some requirements for gateways as per section 2, or is an > > > informational > > > >> description of what can be expected from a WebRTC 'compatible' > > > gateway. > > > >>> > > > >>> > > > >>> Sincerely, > > > >>> Ga=EBlle > > > >>> > > > >>> > > > >>> > > > >>> -----Original Message----- > > > >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > > > >> Rauschenbach, Uwe (Nokia - DE/Munich) > > > >>> Sent: Sunday, April 19, 2015 2:52 PM > > > >>> To: ext Harald Alvestrand; Sean Turner; rtcweb@ietf.org > > > >>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > > >>> Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand- > > > rtcweb- > > > >> gateways > > > >>> > > > >>> +1 for adoption. > > > >>> > > > >>> The same question that Harald raised came to my mind - there > was > > > >> another adoption call end of last year with a lot of support > > > >> (https://www.ietf.org/mail- > > > archive/web/rtcweb/current/msg14050.html). > > > >>> > > > >>> Kind regards, > > > >>> Uwe > > > >>> > > > >>> ________________________________________ > > > >>> Von: rtcweb [rtcweb-bounces@ietf.org]" im Auftrag von > > > "ext > > > >> Harald Alvestrand [harald@alvestrand.no] > > > >>> Gesendet: Samstag, 18. April 2015 07:46 > > > >>> An: Sean Turner; rtcweb@ietf.org > > > >>> Cc: draft-alvestrand-rtcweb-gateways@tools.ietf.org > > > >>> Betreff: Re: [rtcweb] WG call for adoption: draft-alvestrand- > > > rtcweb- > > > >> gateways > > > >>> > > > >>> On 04/16/2015 08:15 PM, Sean Turner wrote: > > > >>>> All, > > > >>>> > > > >>>> There's been some interest expressed in having > > > >> http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb- > gateways/ > > > >> adopted as an RTCWeb WG item. Please respond to say whether you > > > >> support adoption of this work as a working group work item and > > > whether > > > >> you will participate in the discussion. If you are > > opposed to this > > > >> draft becoming a WG document, please say so (and say > > why). Please > > > have > > > >> your response in by 20150423 23:59 UTC. > > > >>>> > > > >>>> Thanks in advance! > > > >>>> > > > >>>> spt > > > >>> Naturally, I support adoption. > > > >>> > > > >>> Question: Is this a repeat of the exercise on which Cullen > > > >>> reported > > > >> consensus for adoption in December 2014, or is this a > > side effect > > > >> of starting fomal tracking of adoption status? > > > >>> > > > >>> -- > > > >>> Surveillance is pervasive. Go Dark. > > > >>> > > > >>> _______________________________________________ > > > >>> 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 > > From nobody Thu Apr 30 14:57: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 ACF221A6FEF; Thu, 30 Apr 2015 14:57:36 -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 SfCXZuqEmPDl; Thu, 30 Apr 2015 14:57:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B311A3BA2; Thu, 30 Apr 2015 14:57:35 -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.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150430215735.22035.51087.idtracker@ietfa.amsl.com> Date: Thu, 30 Apr 2015 14:57:35 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-08.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: Thu, 30 Apr 2015 21:57:36 -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 Audio Codec and Processing Requirements Authors : Jean-Marc Valin Cary Bran Filename : draft-ietf-rtcweb-audio-08.txt Pages : 7 Date : 2015-04-30 Abstract: This document outlines the audio codec and processing requirements for WebRTC endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-audio-08 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-08 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 Thu Apr 30 15:10: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 BFBAE1A8766 for ; Thu, 30 Apr 2015 15:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, 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 D4rISHm15CyC for ; Thu, 30 Apr 2015 15:10:25 -0700 (PDT) Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.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 F199B1A8713 for ; Thu, 30 Apr 2015 15:10:24 -0700 (PDT) Received: by qku63 with SMTP id 63so42005745qku.3 for ; Thu, 30 Apr 2015 15:10: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5n0pCspmfh/UJK505Lj8e5QxTrA0oS/iXxYyTa7nZI4=; b=lhoPwV07aIwyM8npHvffOtqiKUIdnytMAnkWZ64KFZLUaTdB+jVdL7m0ZO8s7BeXj7 vHl3OrGBeOWMuXTilP2nZlgH0rHPPy9MXZVCScbHo6J+PFFzPwUg72yt9/iZOrnNfpqx F56Izyc6kzu2w6luTV/oB2BQqKEf5jL54Ne/q2yJIyXbvo8qSMGK+Pf9dbcLHgYEeRRP 98Ka0Ttn1F/wNO47Qc4EtFjxRm9AQVEB3m4ex0pzKj3F1kzXYM6w1oWX4OaPgUXl2ghz hVGIjr+X3kzAsYBL7IAVDzH3wbtgvKAXrJMZ09q4QeRIitRRKmbZZf57LukZ0xaqXlbc 3wQA== X-Gm-Message-State: ALoCoQk1pkhPHqimYbX61IZeFK2jzriwEMfpTJsiXXTqMr0p2u/eNEwFbFNZa78AkSdRxAHTyjyA X-Received: by 10.55.24.11 with SMTP id j11mr12052317qkh.73.1430431824063; Thu, 30 Apr 2015 15:10:24 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id n24sm1934378qkh.3.2015.04.30.15.10.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2015 15:10:23 -0700 (PDT) Message-ID: <5542A84D.3040006@mozilla.com> Date: Thu, 30 Apr 2015 18:10:21 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" References: <7703998F-5364-487A-84F1-1AAEE6E4C3C8@cisco.com> In-Reply-To: <7703998F-5364-487A-84F1-1AAEE6E4C3C8@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Few comments on draft-ietf-rtcweb-audio-07 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 Apr 2015 22:10:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Cullen, Magnus, Colin, Thanks for the review. I just updated the draft. As some of you pointed out, I changed all instances of "client" to "endpoint" to match the terminology. See below for more: On 16/04/15 02:28 PM, Cullen Jennings (fluffy) wrote: > 2) Need to tweak Sec 2 to include NOT RECOMMENDED: Done. > 3) To avoid a sec considerations comment, I’d probably bolster > them by adding something like: > > For security considerations regarding the codes themselves please > refer their specifications. Likewise, consult the RTP base > specification for security RTP-based security considerations. Added that text, along with references. > 4) The last sentence in the sec cons is likely to attract flies. > Can we point to the two security drafts instead? Added many security references. I didn't delete the sentence itself, but I can do that too if you think it should go. > 5) I’d probably the refer to the opus rtp payload draft from -03 > to -08 (it’s in IESG eval - yippie) and the reference to the audio > codecs for interop from -00 to -01. Done. > 6) The draft has "Because of this, clients MAY increase the gain > before playback." To make consistent sound levels across browsers, > I wonder if this should continue to say something like - "many > browsers increase it by X db" and insert whatever value of X that > chrome and FF think they should be using. I don't feel strongly > about adding this one way or the other but can the authors give it > a little thought and see if they think it is needed or not. I don't know that browsers are doing that yet and I'm not exactly sure what would be a good value there. I suspect it's more of a W3C discussio n. On 20/04/15 03:40 PM, Colin Perkins wrote: > - Section 3 says "Clients MAY use the offer/answer mechanism to > signal a preference for a particular mode or ptime". Is this just > of Opus, or in general? It might be worthwhile saying something > explicit about acceptable ptime values in general. There was some discussion on acceptable ptime values in the past, but there was no consensus achieved. > - Security considerations ought to explicitly point to the > security considerations of RFCs 3389, 4733, 6716, and > draft-ietf-payload-rtp-opus. It should possibly also point to the > draft-ietf-rtcweb-security-arch-11, and the security > considerations for RTP use in WebRTC in > draft-ietf-rtcweb-rtp-usage-22 Done. Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVQqhNAAoJEJ6/8sItn9q9bP4H/2BwbcFqUo8V0BuG/mRWdzxv W5pAhsphO+4hxSV2c6bGABRR3KRkjqHklRpQHebSQ/yAhQEWRWWZXoSeX/sqfMqD RODCF56ZLMIfPtep3ss7eLaRN3qjMfJMbyP7nvTzYqZujbcnlQzw11pJSywMKVqh Yg0/Fa9X+C5ymWRE3Y9v2ITCoVDwd5A4MnHO3FY+3gotmsT/6+RRgccbXGyqUp2t OLMknp3lA3ofidZAWkQ1lMv9D/GrLxCqpya2w/4LGZFCK++q0YBvfxlyXjoL7N9l CKtTreovnhJwULcyp5RVEr3G8BJ0YniOGfkjHuslfAg/L45jVmP/pMxorR7s1LU= =Afic -----END PGP SIGNATURE----- From nobody Thu Apr 30 17:32: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 6048F1B2F34 for ; Thu, 30 Apr 2015 17:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 sU0dqK27ydAo for ; Thu, 30 Apr 2015 17:32:00 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBC11B2F33 for ; Thu, 30 Apr 2015 17:32:00 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 44F5F20CE5 for ; Thu, 30 Apr 2015 20:32:00 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 30 Apr 2015 20:32:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=8xn WXmdBDk3hdW/PQgFS9bzj3gw=; b=I8mbYooNKh57npox9syl85yBohEUk1sNCum 3rPGWTXwfdPESZhLRvHXT2unbaku2aMxrQHNDUYtugK066rlUm+WGLJ8wWRqEcUS 8XbFmj+sQd0ExSLsnwP0boAFdEWM10yJTPABVMAIVGiKIvnFfTlBhDDqZGvMf/yg kBlkkFHg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=8xnWXmdBDk3hdW/PQgFS9bzj3gw=; b=KF0wX xwvULXMA0bSOcLHWZ57ZaZ6KBWEAdLAXpsED5+mV24+ywSDv6NnLbjDK8VEKzRCH cDHYkJoa9PRHoBHoUinx95uVXyAdJBs9/JYdzFznshEKkdUetmS1MsJoH+qrJe3K NsLUC60k6N7Cp8758SJGamF8+CbtWUzTEkgAv4= X-Sasl-enc: +sK2O/1CrTPvYp+aYeHtpLSBQN8p5zsepkJGGe+33QcE 1430440319 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.183]) by mail.messagingengine.com (Postfix) with ESMTPA id A8C68C00015 for ; Thu, 30 Apr 2015 20:31:59 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> Date: Thu, 30 Apr 2015 17:32:06 -0700 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 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, 01 May 2015 00:32:02 -0000 I have reviewed draft-ietf-rtcweb-stun-consent-freshness-11 in = preparation for IETF LC. The document is in good shape and I will = request the last call shortly. I have a couple of questions I=92d like = to discuss while the last call is ongoing, though. I=92m not entirely = caught up on mailing list traffic so apologies if these = questions/comments have already been discussed. Section 4.1: "An endpoint that is not sending any application data does not need to maintain consent. However, failure to send could cause any NAT or firewall mappings for the flow to expire. Furthermore, having one peer unable to send is detrimental to many protocols." It sounds like the unstated implication here is that if you are such an = endpoint, you should keep doing consent checks anyway to maintain = consent. Should that be stated explicitly, or am I misunderstanding? Section 7: The normative MAY here seems odd. It seems like this section could be = replaced with: "The W3C specification [cite] may provide an API hook that generates an = event when consent has expired for a given 5-tuple, meaning that = transmission of data has ceased. This could indicate what application = data is affected, such as media or data channels.=94 Alissa=