From rogerj@gmail.com Sat Nov 30 05:45:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DFF1AE437; Sat, 30 Nov 2013 05:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfiySP74k57l; Sat, 30 Nov 2013 05:45:13 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8479A1AE42E; Sat, 30 Nov 2013 05:45:12 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id k14so7755059wgh.22 for ; Sat, 30 Nov 2013 05:45:10 -0800 (PST) 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=65RbuuqEZ5DTkTFyD/A+sRFZFL2sQoiWuXWtaiPWIio=; b=VM4VJxfIe0S6hLYMsg/5kwEiZZQ5oCUuT5f+VCLj+mVsT+eyiXBzQFaGZDcrpmntMp E3lxWvBociTxhlqBUKIhOlM8nKVtFkqWlfWIRrT7JnvOTZ3aA/esLS7v+S+XYOt/Emvt YAMTj3Brc9tGRwfHWkOclCA61e7cNjxVfSEQdfC8zZ7BymfTtweMmHP41sHpdwwlU1Ta Icc0t3uOiWMVCoVjLzrFr/wq/CqaG/q85R18guCGu/oN1nUJH0154eJFLt+YSyFMZC9h V+RNnXtB+Kczx4oebKJ93LJgyE4YRWoLOXLfeWmE7SNinWA60687lhab6E/gz1b4+1iV hOnw== MIME-Version: 1.0 X-Received: by 10.180.208.4 with SMTP id ma4mr10700193wic.43.1385819110138; Sat, 30 Nov 2013 05:45:10 -0800 (PST) Received: by 10.217.89.4 with HTTP; Sat, 30 Nov 2013 05:45:10 -0800 (PST) In-Reply-To: <52974AA8.6080702@cisco.com> References: <52974AA8.6080702@cisco.com> Date: Sat, 30 Nov 2013 14:45:10 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Eliot Lear Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 01 Dec 2013 08:27:15 -0800 Cc: rtcweb-chairs@tools.ietf.org, rtcweb@ietf.org, IETF Discussion , Eric Burger , Dave Cridland Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 30 Nov 2013 13:45:14 -0000 On Thu, Nov 28, 2013 at 2:52 PM, Eliot Lear wrote: > While I appreciate the difficult position the chairs are in, I don't > agree with the approach and I believe it is inappropriate for the > working group to make such a decision. Working groups don't vote. Want > to change that process? Better gain IETF consensus first. And I will > argue against any such attempt. There are plenty of other standards > bodies that do vote. Go to one of them if that's what you want. Have to agree on this, no voting. And if the problem is that bad, that it's impossible to reach consensus in the WG, what about replacing the chairs? ... --- Roger J --- > Eliot > > On 11/28/13 2:35 PM, Herv=E9 wrote: >> Dave Cridland wrote: >> >>> 2) If the Working Group does want to mandate a single codec, is there >> consensus for one of the alternate decision-making processes described >> in RFC 3929? This is our best guess at what to do here; despite it being >> a (presumably expired) Experimental track RFC. >> >> >> RFC 3929 has been mentioned on the rtcweb mailinglist and during the las= t meeting. >> http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html >> http://ietf88.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB_II >> >> >>> If nobody else appeals the decision, then I will - assuming I'm allowed= to - if it gets this far. >>> it's not clear to me that there is a consensus surrounding the voting >> rules - they've certainly yet to be summarised in one place based on the >> discussion that has occurred so far. >> >> No decision yet. Per >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html today >> is the last planned day for comment/discussion on the _proposal_ to vote= , >> before the proposal gets updated. A further call for consensus to use >> the proposal would follow after updating. >> Perhaps you'd like to get involved now rather than later. >> >> >> Here's what I sent to someone else regarding the proposed schedule: >> Nov 28 last day of comment/discussion period on proposed _votin= g process_ http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.htm= l >> >> after Nov 28 WG chairs will update, if necessary, the process proposa= l >> after update normal IETF process to reach consensus about adopting th= e (updated) process proposal >> >> +2 weeks last day of the consensus call about adopting the voting= process >> >> >> IF consensus was reached to use the voting process in those 2 weeks afte= r the update for that process, ONLY THEN would the (2 week) voting period s= tart (if that wasn't changed in the update/concensus call). >> >> So the voting process can theoretically _start_ Dec 13 at the earliest, = if accepted. Probably later (if ever), given that updating the proposal is = unlikely to be instantaneous. >> >> >> I hope that made it clearer. The source for this is the bottom section o= f http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html >> >> >> - Herv=E9 >> > --=20 Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From harald@alvestrand.no Mon Dec 2 01:50:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F3C1AE114 for ; Mon, 2 Dec 2013 01:50:07 -0800 (PST) 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, RP_MATCHES_RCVD=-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 iNOZVxp_vbBc for ; Mon, 2 Dec 2013 01:50:04 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B4A3E1AE0F9 for ; Mon, 2 Dec 2013 01:50:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 92D6E39E33C for ; Mon, 2 Dec 2013 10:50:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OS3odczh-UW for ; Mon, 2 Dec 2013 10:50:02 +0100 (CET) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9D21D39E062 for ; Mon, 2 Dec 2013 10:50:02 +0100 (CET) Message-ID: <529C57CC.209@alvestrand.no> Date: Mon, 02 Dec 2013 10:50:04 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529935FD.7090409@thaumas.net> <529A78E0.4020106@googlemail.com> In-Reply-To: <529A78E0.4020106@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] MTI motion JPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 09:50:07 -0000 Designing new video codecs is something that I don't think we should do in this WG at this time. On 12/01/2013 12:46 AM, Maik Merten wrote: > Am 30.11.2013 01:49, schrieb Ralph Giles: >> I'd like propose motion JPEG as the manditory-to-implement video codec, >> per RFC 2435 or similar. > > Is it feasible to extend the RFC with, e.g., a run-length coded list > of skipped MCUs ("macroblocks")? Picture data for those would be > copied over from the last frame. This may even work with unmodified > JPEG decoders (either by filling in stub data for the skipped MCUs at > the receiving end or by encoding skipped MCUs compact run of zeroed > coefficents) and a postprocessing step. > > (If coding an explicit list of skipped MCUs is not practical, one can > regard MCUs with all-zero coefficients as "skipped". An encoder will > have to take this into account so no MCUs are skipped by accident, > though.) > > This contradicts the minimal-effort argument to some degree, but at > least this would enable efficient transmission of screencasts, > increase coding efficiency for "talking head" content, and offer > additional means for bitrate management (partial screen updates). > > > > Maik > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From maikmerten@googlemail.com Mon Dec 2 02:27:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECC11AE205 for ; Mon, 2 Dec 2013 02:27:20 -0800 (PST) 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 Bpq2k1sCuozM for ; Mon, 2 Dec 2013 02:27:18 -0800 (PST) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFB61AE1CF for ; Mon, 2 Dec 2013 02:27:17 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id 6so5386982bkj.10 for ; Mon, 02 Dec 2013 02:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=NBjd+V064MisV8aKMFrJCy6D6rg6F0GltAwX4COghkw=; b=sOqkAJ2v5Vzo4CD3IZeYTyF5op7xYdTE0CIKo7zSS8iF96Bcjo6b0cDIapFzFxWUyk 9vRosDmuPmQwGSR0WhYlewESSF/ETRM2QxNxAB4i483TDwUdfWSrZhd2lizBHxubs+zn F4QeCePnM6v65iobvCPQDNaMrlGIzFyTP7HmHQpVnSbnG7WOH++v3EVqqj3qEDRnx90x ESLh0XlBGiARYq3qL8WWP4orhn4dKDXfi6BWV4KOrQqnSSwVIHgNRvKmIuP+sqySCwva 5tT6FqDPiL0vlgaSMyxX4AP9vqtnS9Pft84B5nzFcMvc97RBjCWhwLHPc5UKwOAR/0r+ b11g== X-Received: by 10.204.123.3 with SMTP id n3mr112082bkr.73.1385980035246; Mon, 02 Dec 2013 02:27:15 -0800 (PST) Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id a4sm74269699bko.11.2013.12.02.02.27.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 02:27:14 -0800 (PST) Message-ID: <529C60E1.6060504@googlemail.com> Date: Mon, 02 Dec 2013 11:28:49 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529935FD.7090409@thaumas.net> <529A78E0.4020106@googlemail.com> <529C57CC.209@alvestrand.no> In-Reply-To: <529C57CC.209@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] MTI motion JPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 10:27:20 -0000 Yes, I guess you're right, this is out of scope. It's just that its tempting to come up with ideas for improvements, given the low-hanging fruits in case of MJPEG are basically touching the ground. Maik Am 02.12.2013 10:50, schrieb Harald Alvestrand: > Designing new video codecs is something that I don't think we should do > in this WG at this time. > > > On 12/01/2013 12:46 AM, Maik Merten wrote: >> Am 30.11.2013 01:49, schrieb Ralph Giles: >>> I'd like propose motion JPEG as the manditory-to-implement video codec, >>> per RFC 2435 or similar. >> >> Is it feasible to extend the RFC with, e.g., a run-length coded list >> of skipped MCUs ("macroblocks")? Picture data for those would be >> copied over from the last frame. This may even work with unmodified >> JPEG decoders (either by filling in stub data for the skipped MCUs at >> the receiving end or by encoding skipped MCUs compact run of zeroed >> coefficents) and a postprocessing step. >> >> (If coding an explicit list of skipped MCUs is not practical, one can >> regard MCUs with all-zero coefficients as "skipped". An encoder will >> have to take this into account so no MCUs are skipped by accident, >> though.) >> >> This contradicts the minimal-effort argument to some degree, but at >> least this would enable efficient transmission of screencasts, >> increase coding efficiency for "talking head" content, and offer >> additional means for bitrate management (partial screen updates). >> >> >> >> Maik >> _______________________________________________ >> 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 mary.ietf.barnes@gmail.com Mon Dec 2 07:34:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E3A1AE486; Mon, 2 Dec 2013 07:34:45 -0800 (PST) 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 fXPLrLjrIlUl; Mon, 2 Dec 2013 07:34:44 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id D09221AE48B; Mon, 2 Dec 2013 07:34:43 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so10319680wgh.29 for ; Mon, 02 Dec 2013 07:34:41 -0800 (PST) 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=O6EY2xf0GC9WzU2VQCwbihaS84Pv8JHMMw11WCk4/l4=; b=vqIoqRXWSMkEyFvExnzDwZ0ErUDQFklDEqs+6GGUcnfiyxvMz7Het4KU2FfguQG6Bm xybshXfFvcnYHQ+DBwsjv7+TidBtCKR7n2dvlGHZZ1QE/CoYvJhWWTqB7GO4sdqOB0sA lUFadMtgSlQ+sDfXLJyaOyqF26IuyM6Apf2+7c0KXfL3KWkzArg1nbjnUgquCC/DgO9A 1LwRQab6tL+lxy1hVBx4OUd37w2wAeldi2LUSf3FMe1jVH5i/KC2+BRLMm34QIzHu9ny HhBUiBmBHlw3zdKGEKK747OPvhZ47lEoe6DyuIk+RxkrLr2uMxQC5VHhFN4sCpMELkOc DwfA== MIME-Version: 1.0 X-Received: by 10.180.92.230 with SMTP id cp6mr18689322wib.0.1385998481098; Mon, 02 Dec 2013 07:34:41 -0800 (PST) Received: by 10.216.172.9 with HTTP; Mon, 2 Dec 2013 07:34:41 -0800 (PST) In-Reply-To: <5006.1385666853@sandelman.ca> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> Date: Mon, 2 Dec 2013 09:34:41 -0600 Message-ID: From: Mary Barnes To: Michael Richardson Content-Type: multipart/alternative; boundary=f46d043892cf200e9404ec8eeb82 Cc: IETF Discussion , "rtcweb-chairs@tools.ietf.org" , "rtcweb@ietf.org" , Dave Crocker , Eric Burger , Ted Lemon Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 15:34:46 -0000 --f46d043892cf200e9404ec8eeb82 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 28, 2013 at 1:27 PM, Michael Richardson wrote: > > Ted Lemon wrote: > > On Nov 28, 2013, at 11:29 AM, Dave Crocker wrote: > >> As merely one obvious example, people can simply be tired of the > >> impasse and eagerly seek progress and be willing to settle on any > >> mechanism they think will fairly break it -- even if it works > against > >> the outcome they prefer. > > > The one tidbit you may be missing is that the working group > > specifically chose not to do a coin toss. So "willing to settle for > > any mechanism" clearly doesn't apply in this case. > > That tells me that the participants are not willing to live with losing and > move on, and so no voting process will work either. > [MB] Exactly. [/MB] > > -- > Michael Richardson , Sandelman Software Works > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d043892cf200e9404ec8eeb82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 28, 2013 at 1:27 PM= , Michael Richardson <mcr+ietf@sandelman.ca> wrote:
<= div class=3D"gmail_quote">

Ted Lemon <ted.lemon@nominum.co= m> wrote:
=A0 =A0 > On Nov 28, 2013, at 11:29 AM, Dave Crocker <dhc@dcrocker.net> wrote:
=A0 =A0 >> As merely one obvious example, people can simply be tired = of the
=A0 =A0 >> impasse and eagerly seek progress and be willing to settle= on any
=A0 =A0 >> mechanism they think will fairly break it -- even if it wo= rks against
=A0 =A0 >> the outcome they prefer.

=A0 =A0 > The one tidbit you may be missing is that the working group =A0 =A0 > specifically chose not to do a coin toss. =A0So "willing = to settle for
=A0 =A0 > any mechanism" clearly doesn't apply in this case.
That tells me that the participants are not willing to live with losi= ng and
move on, and so no voting process will work either.
[MB] Exactly. [/MB]=A0

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works



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


--f46d043892cf200e9404ec8eeb82-- From derhoermi@gmx.net Mon Dec 2 11:27:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32EF1AC4A7 for ; Mon, 2 Dec 2013 11:27:27 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 lwi7fdtfb1T1 for ; Mon, 2 Dec 2013 11:27:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 450F21AD687 for ; Mon, 2 Dec 2013 11:27:25 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.23.195]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0Lkjuq-1VD7wD1LgC-00aSsl for ; Mon, 02 Dec 2013 20:27:22 +0100 From: Bjoern Hoehrmann To: Ron Date: Mon, 02 Dec 2013 20:27:20 +0100 Message-ID: <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> In-Reply-To: <20131129060936.GV3245@audi.shelbyville.oz> 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:OR6LjnH7QanpLRy5nSVFqwph0u1uKXHMfMEhhTkQtH+mWRNvWee jPznKyUgGQznacKCrPWaz1tz7r2YJkRm7tj/PEI3vJzp9E7csE/l2HkFQ12GnvFY5+9FZ7Y oQjGb9j7KJXzSOHDHP1sV8sc0kZXizhQXy/xrJugNvIqX6rrnVUeft3NOFOJynq2f54XaXy n4ChjIKSvZ+hzmpUEo8yA== Cc: "rtcweb@ietf.org" , IETF Discussion Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 19:27:28 -0000 * Ron wrote: > 2. Can anybody show a sustainable objection for why we _can't_ use H.261. > > If they can, we're probably doomed. If they can't we have an initial > choice for MTI. I have not seen a convincing argument that H.261 performs well enough to permit real-time video communication at reasonable quality and bitrates. I have not seen recent statistics for Germany but I suspect it is common that household members share a line with an upstream of around 640 kbps, that would basically allow for two 320x240 H.264 CBP + Audio streams at 30 fps in good quality. Would H.261 permit at least one stream at the same quality? If not, then nobody would use H.261-only WebRTC products, and people are not going to appreciate if a VP8 product connecting with a H.264 product falls back to H.261 to avoid negotiation failure. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From basilgohar@librevideo.org Mon Dec 2 11:50:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE211AD7C1 for ; Mon, 2 Dec 2013 11:50:21 -0800 (PST) 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 ukAyzQMsjACG for ; Mon, 2 Dec 2013 11:50:19 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 775981AC4A7 for ; Mon, 2 Dec 2013 11:50:19 -0800 (PST) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id DB80E9D91EF for ; Mon, 2 Dec 2013 14:50:16 -0500 (EST) Message-ID: <529CE475.6000901@librevideo.org> Date: Mon, 02 Dec 2013 14:50:13 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529935FD.7090409@thaumas.net> <529A78E0.4020106@googlemail.com> <529C57CC.209@alvestrand.no> <529C60E1.6060504@googlemail.com> In-Reply-To: <529C60E1.6060504@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] MTI motion JPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 19:50:21 -0000 For what it's worth, what you described sounds a lot like the "Smoke" video codec, which, as far as I know, exists only on the OLPC project via gstreamer. At least, that's about the only reference I've ever found for it. On 12/02/2013 05:28 AM, Maik Merten wrote: > Yes, I guess you're right, this is out of scope. It's just that its > tempting to come up with ideas for improvements, given the low-hanging > fruits in case of MJPEG are basically touching the ground. > > Maik > > Am 02.12.2013 10:50, schrieb Harald Alvestrand: >> Designing new video codecs is something that I don't think we should do >> in this WG at this time. >> >> >> On 12/01/2013 12:46 AM, Maik Merten wrote: >>> Am 30.11.2013 01:49, schrieb Ralph Giles: >>>> I'd like propose motion JPEG as the manditory-to-implement video codec, >>>> per RFC 2435 or similar. >>> >>> Is it feasible to extend the RFC with, e.g., a run-length coded list >>> of skipped MCUs ("macroblocks")? Picture data for those would be >>> copied over from the last frame. This may even work with unmodified >>> JPEG decoders (either by filling in stub data for the skipped MCUs at >>> the receiving end or by encoding skipped MCUs compact run of zeroed >>> coefficents) and a postprocessing step. >>> >>> (If coding an explicit list of skipped MCUs is not practical, one can >>> regard MCUs with all-zero coefficients as "skipped". An encoder will >>> have to take this into account so no MCUs are skipped by accident, >>> though.) >>> >>> This contradicts the minimal-effort argument to some degree, but at >>> least this would enable efficient transmission of screencasts, >>> increase coding efficiency for "talking head" content, and offer >>> additional means for bitrate management (partial screen updates). >>> >>> >>> >>> Maik -- Libre Video http://librevideo.org From adam@nostrum.com Mon Dec 2 11:56:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A191AD8D5 for ; Mon, 2 Dec 2013 11:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 4YNuGGuzyL42 for ; Mon, 2 Dec 2013 11:56:23 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 66D2E1AD845 for ; Mon, 2 Dec 2013 11:56:23 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB2JuB0j069244 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 2 Dec 2013 13:56:11 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <529CE5D6.2060209@nostrum.com> Date: Mon, 02 Dec 2013 13:56:06 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" , Ron , "rtcweb@ietf.org" References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 19:56:24 -0000 On 11/22/13 22:45, Mo Zanaty (mzanaty) wrote: > All major distros including Debian already include x264, ffmpeg, etc. > http://packages.debian.org/wheezy/x264 Wait, what? Why would Linux distros care whether they can include the Cisco library when they already distribute an H.264 encoder library? Is there some reason they would *need* two different encoders? /a From basilgohar@librevideo.org Mon Dec 2 12:04:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D0E1ADED8 for ; Mon, 2 Dec 2013 12:04:45 -0800 (PST) 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 zPAqatd_FMqY for ; Mon, 2 Dec 2013 12:04:44 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 576BC1ADEB4 for ; Mon, 2 Dec 2013 12:04:44 -0800 (PST) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id D920E65B82E for ; Mon, 2 Dec 2013 15:04:41 -0500 (EST) Message-ID: <529CE7D7.50601@librevideo.org> Date: Mon, 02 Dec 2013 15:04:39 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> <52963FB9.7020002@bbs.darktech.org> <5296589D.9070009@bbs.darktech.org> <20131127220418.GR3245@audi.shelbyville.oz> In-Reply-To: <20131127220418.GR3245@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 20:04:45 -0000 On 11/27/2013 05:04 PM, Ron wrote: > On Wed, Nov 27, 2013 at 12:42:25PM -0800, Eric Rescorla wrote: >> >> On Wed, Nov 27, 2013 at 12:39 PM, cowwoc wrote: >>> Either you misunderstood my question or I am misunderstanding your answer. >>> I'm asking what prevents us from bundling Cisco's binary as part of our >>> installer or image? >> >> What makes it a Cisco product is that it comes from Cisco, not that you >> make a bunch of copies and send it to people. > > So, if I buy a video camera with H.264 support from some local store, > are you saying that it's the retailer responsible for purchasing the > licence? Or maybe it's the sweat-shop fabricator that's responsible > for this? Who did my camera "come from" in this case? > > And are you by extension saying that I'm responsible for a 'unit' > every time that Cisco binary is copied from disk storage to RAM? > What if the disk it's on is in a NAS? > > Juries in Texas are going to love this. > > Ron Sorry, I missed this whole thread of discussion, but I think I know the answer to this, not that I think it matters a whole bunch. The camera manufacturer only has a transitive license to its customers for private, non-commercial usage, and that's exactly what it says in the discussion. This, by the way, is exactly and only the usages that will be allowed by the Cisco binary, unless MPEG-LA has changed their transitive licensing practices since I last investigated this. -- Libre Video http://librevideo.org From basilgohar@librevideo.org Mon Dec 2 12:16:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961811ADED6 for ; Mon, 2 Dec 2013 12:16:45 -0800 (PST) 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 cC4MJu6f7A9T for ; Mon, 2 Dec 2013 12:16:44 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id DF4431ACCFF for ; Mon, 2 Dec 2013 12:16:43 -0800 (PST) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 6B06D65B82E for ; Mon, 2 Dec 2013 15:16:41 -0500 (EST) Message-ID: <529CEAA6.9000501@librevideo.org> Date: Mon, 02 Dec 2013 15:16:38 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> In-Reply-To: <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 20:16:45 -0000 On 12/02/2013 02:27 PM, Bjoern Hoehrmann wrote: > * Ron wrote: >> 2. Can anybody show a sustainable objection for why we _can't_ use H.261. >> >> If they can, we're probably doomed. If they can't we have an initial >> choice for MTI. > > I have not seen a convincing argument that H.261 performs well enough to > permit real-time video communication at reasonable quality and bitrates. > > I have not seen recent statistics for Germany but I suspect it is common > that household members share a line with an upstream of around 640 kbps, > that would basically allow for two 320x240 H.264 CBP + Audio streams at > 30 fps in good quality. Would H.261 permit at least one stream at the > same quality? If not, then nobody would use H.261-only WebRTC products, > and people are not going to appreciate if a VP8 product connecting with > a H.264 product falls back to H.261 to avoid negotiation failure. > The problem with your problem is that you've set an ambiguous bar that is also irrelevant - "reasonable quality". That is not the purpose of an MTI codec. Rather, an MTI codec is there to prevent the absolute worst case of two endpoints being unable to communicate via video at all due to codec negotiation failure. And MTI codec is also not mandating that it be the ONLY codec or even the BEST codec to be used. It's there specifically to ensure communication can ALWAYS happen, no matter what. It's a codec of last resort, and should not be compared against the state of the art that's available elsewhere. It also has the added bonus of being ridiculously simple to implement, both for encoding and decoding, compared to what's out there. It really fits the bill as being something to serve as the worst case scenario that's not catastrophic. And as stated elsewhere on this list, some tests have been done on CIF videos (352x288) at lower framerates at 256kbps, and got acceptable results. In fact, it was designed in the area of ISDN (64k + 64k), so it will, in fact, work at the stated bitrates you're talking about here. We'd need also to add only about 16kbps for a killer Opus speech channel, and you'd be set. The fight against H.261 as MTI is really not about quality or efficiency, but rather, about forcing a royalty-bearing format on what should be an open standard and to save a few big players some implementation dollars because they might want to reuse some existing hardware, all of which are secondary points in this charter compared to a universally applicable MTI video codec. -- Libre Video http://librevideo.org From martin.thomson@gmail.com Mon Dec 2 14:44:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224A21ADDAF for ; Mon, 2 Dec 2013 14:44:34 -0800 (PST) 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 7ieGbspu6gQm for ; Mon, 2 Dec 2013 14:44:32 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C50E61AD845 for ; Mon, 2 Dec 2013 14:44:31 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id ca18so5658889wib.4 for ; Mon, 02 Dec 2013 14:44:29 -0800 (PST) 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=0OPuoDjcmYtwlVGaV98gClwh7xmThwkxsLoMUi9Ybag=; b=NdxDb3Tqxds83IX1g0Mhvs2CByxf/kyZ89I8o/NADZ0FLtSHTH9ejGTLBDAgYXzbHS UG4TbG9TcD07cZe48uucBGesTxMg2LUiu7QTB/mvB5U5KCF1IxNvcuTgJ4Y6PJD5Mh/f T0p/jUNCdnzuGnFWJSsDqNwCvBVXEf3bablfLOSV+t7JkHDFjST6z0cG7d2gNbmhxmE8 kXzGPaX6KZj+glEl2zRmCh1ppxI4pt8hcJcQBYBqiLB3YxVed3eeDoZE3yWTddyboied w8m40r+Fhu1ba55MK+uMGqkVBA/gwNqxNiQvswh0Yh2V0Yf1fW+2TZMWhLM1x/elhjB1 NqoQ== MIME-Version: 1.0 X-Received: by 10.180.107.193 with SMTP id he1mr20296804wib.50.1386024268933; Mon, 02 Dec 2013 14:44:28 -0800 (PST) Received: by 10.227.134.195 with HTTP; Mon, 2 Dec 2013 14:44:28 -0800 (PST) In-Reply-To: <52989933.6000907@ericsson.com> References: <52989933.6000907@ericsson.com> Date: Mon, 2 Dec 2013 14:44:28 -0800 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 22:44:34 -0000 On 29 November 2013 05:40, Magnus Westerlund wrote: > I have looked briefly on this and wonder if this isn't vulnerable to > active attacks from a attacker (Alice) that likes to use a set of WebRTC > browsers, including (Bob) to generate DDOS traffic towards the target > (Charlie). Hi Magnus, I think that you did manage to hit on something critical here. The basic security primitive in play with ICE consent is proof of receipt. That is the key piece at play here as well. We require proof of receipt simply because that elevates the requirements for an attacker to the point that they have to basically be on-path. At that point, they (likely) already have the ability to generate traffic toward a victim of an equal (or maybe greater) volume to the sender and gain little by mounting the attack. That's why I'm not particularly interested in the part where you talk about attackers intercepting binding requests. The actual attack that you have hit upon (or caused me to think about) is not quite as you described, but it does rely on the fact that the proposed change to the consent mechanism no longer actively depends on proof of receipt. It also relies on the possibility that a DTLS connection can be moved without requiring proof of receipt on the new path. That, to me, is the fundamental problem to be solved. From my reread of RFC 6347, it appears as though the only consideration given to DoS was at the handshake. Once something like ICE is in play (and MICE makes this worse), the ability to "move" the connection presents an attacker with an opportunity. (I have to point out that this also confirms my fears about the mechanism used to signal ICE restarts, but I'll get back to that.) Here is the attack as I understand it: 1. A talks to B, establishing a DTLS connection using ICE. There is no need for lots of data to flow at this point, this is the "warm-up" phase of the attack. 2. B (the attacker) triggers an "ICE restart" with A, though really this generates a new ICE negotiation with a victim, C. C consents to talk to B, but not necessarily with A. This arrangement is easy to achieve on the drive-by web. 3. A completes ICE with C and expects to continue the DTLS connection over the newly discovered 5-tuple. C is confused, but really has no recourse at this point. Even if the DTLS connection fails, C is now the victim on the other end of an unending stream of bits. B spoofs the source address of the necessary packets to continue consent, A continues to send to C, and nothing that C does can stop the flood because they don't have access to the master secret and cannot therefore produce an authenticated packet that terminates the connection. B can continue the attack as long as A is willing, at the bargain-basement price of a (spoofed) DTLS heartbeat response every 10-20 seconds. The key here is the lack of a proof of receipt from A toward C for the DTLS connection that is moved. There is nothing inherent to DTLS that provides proof that C received data from A and is also willing to continue to communicate... Almost. The DTLS heartbeat extension does provide such a thing: http://tools.ietf.org/html/rfc6520#page-6 All we need to do to close this little loophole is to require that a DTLS heartbeat request be sent after any change in underlying 5-tuple. That request MUST contain sufficient entropy that guessing would be difficult for an off-path attacker; noting that this is also covered by TLS record layer encryption and authentication, limiting the number of parties that are even allowed to make a guess. I'm a big fan of 128 bits, but less is almost certainly OK. If no response is received within N seconds, consent is expired. The basic consent timer seems appropriate here, i.e., N=30. DTLS renegotiation would also work, but I consider that to be a little heavyweight. I'm not sure that it's that widely implemented either. From derhoermi@gmx.net Mon Dec 2 14:52:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CB11ADDCA for ; Mon, 2 Dec 2013 14:52:40 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 UUfNQUb6-AEJ for ; Mon, 2 Dec 2013 14:52:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7221ADF8C for ; Mon, 2 Dec 2013 14:52:37 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.34.108]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0LgdBZ-1VHd2v0E21-00nxJg for ; Mon, 02 Dec 2013 23:52:34 +0100 From: Bjoern Hoehrmann To: Phillip Hallam-Baker Date: Mon, 02 Dec 2013 23:52:26 +0100 Message-ID: <242q99176qj0e4t7as5lu3e7rosd8grn1v@hive.bjoern.hoehrmann.de> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> 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:wEN4eIZsIlKWrsrM+FB+gMT94MpBlxabaI9WS7WZLgZhqCkKZ51 v8c/cBijZWkrD8omDttNOO/Hwahovl4d/fXbwA1pkwLhgpr6gvjxFwI1/HJbHeVRmnfxa0p LjRiVHyemyW5s69Tobz3ags7wV3FOsbdN4h5QI2+ftK73aPfseZ5XbfjtUoqeLErFVuTQNi 6i+WLfe1LcAVZK0OSM/ug== Cc: "rtcweb@ietf.org" , IETF Discussion Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 22:52:40 -0000 * Phillip Hallam-Baker wrote: >MTI does not need to be a good choice, it merely needs to achieve >interoperability. The Working Group seeks interoperability in the area of real-time video, not in the area of slide shows or scaled animated icons. I suggested earlier to compare H.261 to sending a series of JPEG images or sending animated GIFs in terms of resolution, framerates, bitrates, and so on. If H.261 is shown to be much closer to H.264 CBP than it is to those, I would be willing to consider it. >People would use H.261 if that is all the clients at either end supported. If they were unable to use other clients and really need low-resolution slide shows and there are no other factors to consider -- then perhaps. I myself would not voluntarily watch low-framerate or extremely blurry video if I do not have to. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From martin.thomson@gmail.com Mon Dec 2 14:59:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86081ADF91; Mon, 2 Dec 2013 14:59:44 -0800 (PST) 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 PA6FicTOQdAb; Mon, 2 Dec 2013 14:59:43 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAC71ADF8F; Mon, 2 Dec 2013 14:59:43 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so11727330wgh.14 for ; Mon, 02 Dec 2013 14:59:40 -0800 (PST) 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=gKhJucV4CjwMx13HRjFpIsZ/vOAbE+R2yodHPh1Ub9c=; b=DaWo4Ukpkuli/gKoyPLShTltZYGNFt9lm3P5ekZryzKALZQBOxWKyFIj9m5r223eko C8wfP894vihWjDLLYTwkyozj4WuzolBRjN2CMei6e86VK3s1dCCelzsYV9ZngB6QUe54 jHQFtHfBFL+Qd6v4CpLowgiIJevPAga+AFE67HfbBWVW2dARm3H6/HKd69NCMtLJURQ9 rJH46NQVIry9wPeuiafOyUlEfj0emQEzLXgGB1btu9DGEjjS8+SlnjbJNo43bh4EA2BQ 6MS08a41uD2uqz8xtfVkzJvPC+SyVcqz0/LO/wBVmNGOQWkGgjE+qWRHbODziTz834HL lKTQ== MIME-Version: 1.0 X-Received: by 10.180.108.162 with SMTP id hl2mr10566950wib.56.1386025180458; Mon, 02 Dec 2013 14:59:40 -0800 (PST) Received: by 10.227.134.195 with HTTP; Mon, 2 Dec 2013 14:59:40 -0800 (PST) In-Reply-To: <242q99176qj0e4t7as5lu3e7rosd8grn1v@hive.bjoern.hoehrmann.de> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <242q99176qj0e4t7as5lu3e7rosd8grn1v@hive.bjoern.hoehrmann.de> Date: Mon, 2 Dec 2013 14:59:40 -0800 Message-ID: From: Martin Thomson To: Bjoern Hoehrmann Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" , Phillip Hallam-Baker , IETF Discussion Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 22:59:44 -0000 On 2 December 2013 14:52, Bjoern Hoehrmann wrote: > I myself would not voluntarily watch low-framerate or extremely blurry > video if I do not have to. I love playing devil's advocate... But you need to remind yourself that a) you do the audio equivalent just about every time you make a phone call on the PSTN (which I grant, you might not do, the world is moving on), and b) those specific problems can be addressed with the application of more bandwidth or by having teeny postage-stamp videos. From silviapfeiffer1@gmail.com Mon Dec 2 15:07:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261601ADFA9 for ; Mon, 2 Dec 2013 15:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_KPbcy2LNmj for ; Mon, 2 Dec 2013 15:07:35 -0800 (PST) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 773DD1ADF9B for ; Mon, 2 Dec 2013 15:07:35 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i4so14200946oah.29 for ; Mon, 02 Dec 2013 15:07:33 -0800 (PST) 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=FeUTrHaYAXYR1N4bCWsFaz5ZbSFBPVn5Sjil1yibe74=; b=VfbzBmbj2GL9tUknDvP16rjheTDI9BL4uRKG2cFhWJKQboEL4toSMNSdq+lw+Q0SNp 5EvGsyBc9YnbvfXawwBPTbpz9BxQxztcOqu9RAcdyApp5zr20xbrZPqH26kSwISE+Wfg v5melQpiOqiD9cU9crfi5gqLlpXQ0EJn5b/+ZmxYlQp9WGljB70SMjYblL5aOwtauv7I +TcCl7eCp9+yo1Ca0rgy4DFLj8e1AWyN/sjHinyPdktVK2A23mvJCs7U6Yq/M/jDWy+n +cwQPJ6VCtRcMKtZOkv1E2I/lmiiDtIJt2X9HQro/aWDqeW6DGXUeAU0ezNGZHEc56t6 rJfA== MIME-Version: 1.0 X-Received: by 10.182.223.37 with SMTP id qr5mr7313496obc.41.1386025652922; Mon, 02 Dec 2013 15:07:32 -0800 (PST) Received: by 10.76.68.106 with HTTP; Mon, 2 Dec 2013 15:07:32 -0800 (PST) Received: by 10.76.68.106 with HTTP; Mon, 2 Dec 2013 15:07:32 -0800 (PST) In-Reply-To: <529CEAA6.9000501@librevideo.org> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <529CEAA6.9000501@librevideo.org> Date: Tue, 3 Dec 2013 10:07:32 +1100 Message-ID: From: Silvia Pfeiffer To: Basil Mohamed Gohar Content-Type: multipart/alternative; boundary=f46d0444ee69b1307404ec953e04 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 23:07:37 -0000 --f46d0444ee69b1307404ec953e04 Content-Type: text/plain; charset=ISO-8859-1 On 3 Dec 2013 07:16, "Basil Mohamed Gohar" wrote: > > On 12/02/2013 02:27 PM, Bjoern Hoehrmann wrote: > > * Ron wrote: > >> 2. Can anybody show a sustainable objection for why we _can't_ use H.261. > >> > >> If they can, we're probably doomed. If they can't we have an initial > >> choice for MTI. > > > > I have not seen a convincing argument that H.261 performs well enough to > > permit real-time video communication at reasonable quality and bitrates. > > > > I have not seen recent statistics for Germany but I suspect it is common > > that household members share a line with an upstream of around 640 kbps, > > that would basically allow for two 320x240 H.264 CBP + Audio streams at > > 30 fps in good quality. Would H.261 permit at least one stream at the > > same quality? If not, then nobody would use H.261-only WebRTC products, > > and people are not going to appreciate if a VP8 product connecting with > > a H.264 product falls back to H.261 to avoid negotiation failure. > > > > The problem with your problem is that you've set an ambiguous bar that > is also irrelevant - "reasonable quality". That is not the purpose of > an MTI codec. Rather, an MTI codec is there to prevent the absolute > worst case of two endpoints being unable to communicate via video at all > due to codec negotiation failure. And MTI codec is also not mandating > that it be the ONLY codec or even the BEST codec to be used. It's there > specifically to ensure communication can ALWAYS happen, no matter what. > > It's a codec of last resort, and should not be compared against the > state of the art that's available elsewhere. > > It also has the added bonus of being ridiculously simple to implement, > both for encoding and decoding, compared to what's out there. > > It really fits the bill as being something to serve as the worst case > scenario that's not catastrophic. > > And as stated elsewhere on this list, some tests have been done on CIF > videos (352x288) at lower framerates at 256kbps, and got acceptable > results. In fact, it was designed in the area of ISDN (64k + 64k), so > it will, in fact, work at the stated bitrates you're talking about here. > We'd need also to add only about 16kbps for a killer Opus speech > channel, and you'd be set. > > The fight against H.261 as MTI is really not about quality or > efficiency, but rather, about forcing a royalty-bearing format on what > should be an open standard and to save a few big players some > implementation dollars because they might want to reuse some existing > hardware, all of which are secondary points in this charter compared to > a universally applicable MTI video codec. > I guess one thing that the vote should determine is whether implementers are more accepting of falling back to an old codec (Theora, h.261, etc) over implementing decoding for 2 modern codecs (h.264 & vp8) plus encoding of one of them. Is the vote set up in a way that will let us answer this question in the end? Silvia. --f46d0444ee69b1307404ec953e04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 3 Dec 2013 07:16, "Basil Mohamed Gohar" <basilgohar@librevideo.org> wrote:
>
> On 12/02/2013 02:27 PM, Bjoern Hoehrmann wrote:
> > * Ron wrote:
> >> 2. Can anybody show a sustainable objection for why we _can&#= 39;t_ use H.261.
> >>
> >> =A0 If they can, we're probably doomed. =A0If they can= 9;t we have an initial
> >> =A0 choice for MTI.
> >
> > I have not seen a convincing argument that H.261 performs well en= ough to
> > permit real-time video communication at reasonable quality and bi= trates.
> >
> > I have not seen recent statistics for Germany but I suspect it is= common
> > that household members share a line with an upstream of around 64= 0 kbps,
> > that would basically allow for two 320x240 H.264 CBP + Audio stre= ams at
> > 30 fps in good quality. Would H.261 permit at least one stream at= the
> > same quality? If not, then nobody would use H.261-only WebRTC pro= ducts,
> > and people are not going to appreciate if a VP8 product connectin= g with
> > a H.264 product falls back to H.261 to avoid negotiation failure.=
> >
>
> The problem with your problem is that you've set an ambiguous bar = that
> is also irrelevant - "reasonable quality". =A0That is not th= e purpose of
> an MTI codec. =A0Rather, an MTI codec is there to prevent the absolute=
> worst case of two endpoints being unable to communicate via video at a= ll
> due to codec negotiation failure. =A0And MTI codec is also not mandati= ng
> that it be the ONLY codec or even the BEST codec to be used. =A0It'= ;s there
> specifically to ensure communication can ALWAYS happen, no matter what= .
>
> It's a codec of last resort, and should not be compared against th= e
> state of the art that's available elsewhere.
>
> It also has the added bonus of being ridiculously simple to implement,=
> both for encoding and decoding, compared to what's out there.
>
> It really fits the bill as being something to serve as the worst case<= br> > scenario that's not catastrophic.
>
> And as stated elsewhere on this list, some tests have been done on CIF=
> videos (352x288) at lower framerates at 256kbps, and got acceptable > results. =A0In fact, it was designed in the area of ISDN (64k + 64k), = so
> it will, in fact, work at the stated bitrates you're talking about= here.
> =A0We'd need also to add only about 16kbps for a killer Opus speec= h
> channel, and you'd be set.
>
> The fight against H.261 as MTI is really not about quality or
> efficiency, but rather, about forcing a royalty-bearing format on what=
> should be an open standard and to save a few big players some
> implementation dollars because they might want to reuse some existing<= br> > hardware, all of which are secondary points in this charter compared t= o
> a universally applicable MTI video codec.
>

I guess one thing that the vote should determine is whether = implementers are more accepting of falling back to an old codec (Theora, h.= 261, etc) over implementing decoding for 2 modern codecs (h.264 & vp8) = plus encoding of one of them.

Is the vote set up in a way that will let us answer this que= stion in the end?

Silvia.

--f46d0444ee69b1307404ec953e04-- From derhoermi@gmx.net Mon Dec 2 18:00:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15D41ADF33 for ; Mon, 2 Dec 2013 18:00:40 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 vkeMPdIjRCRX for ; Mon, 2 Dec 2013 18:00:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id F0B6E1ADE8B for ; Mon, 2 Dec 2013 18:00:38 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.34.108]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MBnPX-1VvbeO1cu7-00AjU9 for ; Tue, 03 Dec 2013 03:00:35 +0100 From: Bjoern Hoehrmann To: Basil Mohamed Gohar Date: Tue, 03 Dec 2013 03:00:36 +0100 Message-ID: References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <529CEAA6.9000501@librevideo.org> In-Reply-To: <529CEAA6.9000501@librevideo.org> 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:pNaxOqH7V6DZNKUK2SoqGsSoyBXpvR0FirK0YJzh50fw93QFeZ1 vlnklbClLCZQ1poc3h9bGaSCkhP6tmdYKezzMLlZQbFzOAOk3lKK+aJmRWqpwEFHjfTNmC+ VFtT5nD0Q4tQnn4AjIAQIsaS9fvCVUfHDsOQctMBeGyct4NvYzQJ1eAOD0wxsD/7LvkShse kU+hDILiU0h5AGGW6jaIQ== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 02:00:40 -0000 * Basil Mohamed Gohar wrote: >The problem with your problem is that you've set an ambiguous bar that >is also irrelevant - "reasonable quality". That is not the purpose of >an MTI codec. Rather, an MTI codec is there to prevent the absolute >worst case of two endpoints being unable to communicate via video at all >due to codec negotiation failure. And MTI codec is also not mandating >that it be the ONLY codec or even the BEST codec to be used. It's there >specifically to ensure communication can ALWAYS happen, no matter what. I think it is highly relevant whether the mandatory-to-implement codec supports two people in typical German households communicate via video in sign language, and how it does so relative to non-mandatory options, as a simple example. If H.264 supports the scenario and H.261 does not, then selecting H.261 does not in fact prevent the absolute worst case and does not ensure that communication via video can always happen. >The fight against H.261 as MTI is really not about quality or >efficiency, but rather, about forcing a royalty-bearing format on what >should be an open standard and to save a few big players some >implementation dollars because they might want to reuse some existing >hardware, all of which are secondary points in this charter compared to >a universally applicable MTI video codec. Like I said, I have not seen a convincing argument that H.261 performs well enough, and the implementation techniques that can reasonably be assumed to be unencumbered are old enough that I think it is fair to assume without investigating myself that selecting H.261 as only manda- tory-to-implement video codec could work on paper, but not in practise. I read the "irrelevant" responses as essentially advocating that we may just as well make sending raw and unencoded RGB data the MTI codec. I'm more than willing to hear better arguments. The same goes for the H.263 option that has been suggested. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From stewe@stewe.org Mon Dec 2 18:36:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2881AE01C; Mon, 2 Dec 2013 18:36:31 -0800 (PST) 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 7Mv6yXhE2pKL; Mon, 2 Dec 2013 18:36:28 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5DC1ADF62; Mon, 2 Dec 2013 18:36:27 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 3 Dec 2013 02:36:22 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.113]) with mapi id 15.00.0820.005; Tue, 3 Dec 2013 02:36:22 +0000 From: Stephan Wenger To: Bjoern Hoehrmann , Phillip Hallam-Baker Thread-Topic: [rtcweb] Alternative decision process in RTCWeb Thread-Index: AQHO7FceOvmZk1qkDkG4v07q5fPHxpo63rCAgAAoZ4CAABdrAIAAHk2AgAB9qwCABZXhAIAADKKAgAAsqwD//7hjgA== Date: Tue, 3 Dec 2013 02:36:19 +0000 Message-ID: References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <242q99176qj0e4t7as5lu3e7rosd8grn1v@hive.bjoern.hoehrmann.de> In-Reply-To: <242q99176qj0e4t7as5lu3e7rosd8grn1v@hive.bjoern.hoehrmann.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.99] x-forefront-prvs: 0049B3F387 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(24454002)(51704005)(69226001)(49866001)(74662001)(74502001)(87266001)(74876001)(77982001)(16601075003)(80022001)(19580395003)(59766001)(19580405001)(15202345003)(74706001)(66066001)(4396001)(79102001)(83322001)(63696002)(65816001)(83072001)(47446002)(47736001)(85852002)(80976001)(47976001)(77096001)(31966008)(54316002)(87936001)(74366001)(36756003)(81816001)(76786001)(76796001)(53806001)(85306002)(81342001)(76482001)(81542001)(15975445006)(54356001)(51856001)(56776001)(50986001)(46102001)(2656002)(81686001)(56816005)(90146001)(42262001)(18886065003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:50.174.124.99; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <82DAEACCAFA32A40A04831C7DA643D82@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" , IETF Discussion Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 02:36:31 -0000 Hi, A few data point re video codecs (most of them were made already on the rtcweb list): 1. A reasonably well tuned H.261 codec (including pre/post filters etc.) will under almost any circumstance produce a better picture than MJPEG. The intra coding tools of H.261 have a lot in common with JPEG, and H.261 offers inter picture prediction on top of that. 2. At 48 kbit/s, we (and anyone else who had products at the time) got reasonably good looking video conferencing QCIF pictures (176x144 samples, 15 fps) on Pentium P54C hardware back in 1996. The Pentium was also loaded with an ISDN software stack, G.728 audio (which took the rest of the 64 kbit/s of one ISDN B channel), rudimentary echo cancellation, and a user interface based on Windows 95. 3. I=B9m confident that a competent video coding engineer could clean-room implement a complete, reasonably well tuned H.261 codec in less than a man year. If starting from the existing H.261 sources that can be found in various software packages, it should take much less than that. 4. In pretty much all video coding algorithms, factors such as blurriness and framerate are a function of the bitrate you allow the encoder to use. Throw a megabit at H.261, and it will produce a good CIF picture. 5. The bitrate required per sample (for the typical picture sizes in use) have approximately halved between each generation of video codecs. That is, to achieve the same visual quality, one needs approximately half the bitrate when moving on one generation. I wrote =B3per sample=B2 and =B3for typical picture sizes in use=B2, because newer video codecs tend to be optimized for larger picture sizes. H.261 was clearly optimized for QCIF and CIF, whereas H.265 shines at 1080p and above. Many use the following generations in discussions like this: 1st (ca. 1989): H.261 2nd (ca. 1993): MPEG-1, MPEG-2, (aka H.262) 3rd (ca. 1996): H.263, MPEG 4 part 2, VC1 4th (ca. 2003): H.264, VP8 5th (ca. 2013): H.265, VP9 5. Patent claims allegedly covering technologies in video coding according to the 2nd and 4th generation standards are *today* actively litigated. Stephan =20 On 12.2.2013, 14:52 , "Bjoern Hoehrmann" wrote: >* Phillip Hallam-Baker wrote: >>MTI does not need to be a good choice, it merely needs to achieve >>interoperability. > >The Working Group seeks interoperability in the area of real-time video, >not in the area of slide shows or scaled animated icons. I suggested >earlier to compare H.261 to sending a series of JPEG images or sending >animated GIFs in terms of resolution, framerates, bitrates, and so on. >If H.261 is shown to be much closer to H.264 CBP than it is to those, I >would be willing to consider it. > >>People would use H.261 if that is all the clients at either end >>supported. > >If they were unable to use other clients and really need low-resolution >slide shows and there are no other factors to consider -- then perhaps. >I myself would not voluntarily watch low-framerate or extremely blurry >video if I do not have to. >--=20 >Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehrm= ann.de >Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.= de >25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.= de/=20 From bernard_aboba@hotmail.com Mon Dec 2 18:44:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6BD1AE01E for ; Mon, 2 Dec 2013 18:44:01 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 XkYib6lJmQ3Q for ; Mon, 2 Dec 2013 18:43:56 -0800 (PST) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by ietfa.amsl.com (Postfix) with ESMTP id EFC621ACCE7 for ; Mon, 2 Dec 2013 18:43:55 -0800 (PST) Received: from BLU169-W106 ([65.55.111.71]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 18:43:53 -0800 X-TMN: [xLYOcufVeB2cI0bv4JB7ZU+lZT8b8RFvrxDvIzoZncc=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_19ec846f-4d98-4e20-800a-9aa4f9de074b_" From: Bernard Aboba To: Bjoern Hoehrmann Date: Mon, 2 Dec 2013 18:43:52 -0800 Importance: Normal In-Reply-To: References: , <52974AA8.6080702@cisco.com>, <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com>, <52976F56.4020706@dcrocker.net>, <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com>, <5006.1385666853@sandelman.ca>, , , <20131129060936.GV3245@audi.shelbyville.oz>, <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de>, <529CEAA6.9000501@librevideo.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2013 02:43:53.0800 (UTC) FILETIME=[815ECC80:01CEEFD1] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 02:44:02 -0000 --_19ec846f-4d98-4e20-800a-9aa4f9de074b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I think it is highly relevant whether the mandatory-to-implement codec s= upports two people in typical German households communicate via video in si= gn language... =20 [BA] This isn't just an issue for Germany. An inability to support sign l= anguage would be "highly relevant" to compliance with the proposed Section = 255/508 revision in the US. =20 =20 From: http://www.access-board.gov/attachments/article/490/draft-rule.pdf=2C= Section 408.8:=20 =20 "408.8 Video Communication. Where ICT that provides two way voice communic= ation includes real time video functionality=2C the quality of the video sh= all be sufficient to support communication using sign language." =20 =20 =20 =20 =20 =20 = --_19ec846f-4d98-4e20-800a-9aa4f9de074b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 =3B>=3B I think it is hig= hly relevant whether the mandatory-to-implement codec =3Bsupports two p= eople in typical German households communicate via video in sign language..= .
 =3B
[BA] This isn't just an issue for Germany. =3B =3B= An inability to support sign language =3Bwould be "highly relevant" to= compliance with the proposed Section 255/508 revision in the US. =3B <= BR> =3B
From: http://www.access-board.gov/attachments/article/49= 0/draft-rule.pdf=2C Section 408.8:
 =3B
"408.8 Video Communi= cation. =3B Where ICT that provides two way voice communication include= s real time video functionality=2C the quality of the video shall be suffic= ient to support communication using sign language."
 =3B
 =3B=
 =3B
 =3B
 =3B

 =3B
<= /body> = --_19ec846f-4d98-4e20-800a-9aa4f9de074b_-- From cowwoc@bbs.darktech.org Mon Dec 2 18:46:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721F61AE027 for ; Mon, 2 Dec 2013 18:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV8htp8Ni2xo for ; Mon, 2 Dec 2013 18:46:53 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 431C91AE026 for ; Mon, 2 Dec 2013 18:46:53 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so22234668iec.23 for ; Mon, 02 Dec 2013 18:46:50 -0800 (PST) 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; bh=cGApMNI5BNjl7rpv9IsK/lAvRktBq1HGN9byHIIS/eM=; b=HnYrlpNaWEkQfj7cNAHR0sxaomInhwcT7P1U2iemiSUmS2eL0Ypdgxe4gOZGXouPnj 7pJxJFSKcgBawfdgNoPQx93nglWKYKxnjlz7Jeu6NO9fkMKOp0LmtXX8ZGaT1pJYbxdg IJ6cykfxUNSIfMSPWafaCHrVlTxuDKyVAM3kl+sb8Ktn21Jn8zBNAQ2nKftqLpwfNHBu t1Id7aBYBxQEO88vjnLJPYkdIdt5Zby4WYbUgINK/LWQ0JjirwxskSiosiynItyuVzZY 75J3Jrodm8CKrNi/5+qkz8FX3ud3FrYUimgdmVjPbeeorK6OGf1AemAM5GHivZWvuiip yLCw== X-Gm-Message-State: ALoCoQkhAHHq7W6NSA3qFIzZ3VeyFzK4RMKVUIyr5jaisp4NCkUhZ2w4pUOQzQsaDyoTGhrI0/WS X-Received: by 10.42.224.10 with SMTP id im10mr4509217icb.46.1386038810595; Mon, 02 Dec 2013 18:46:50 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id i11sm797829igh.0.2013.12.02.18.46.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 18:46:49 -0800 (PST) Message-ID: <529D4617.6060909@bbs.darktech.org> Date: Mon, 02 Dec 2013 21:46:47 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <529CEAA6.9000501@librevideo.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030306040008090406060407" Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 02:46:55 -0000 This is a multi-part message in MIME format. --------------030306040008090406060407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/12/2013 9:00 PM, Bjoern Hoehrmann wrote: > I think it is highly relevant whether the mandatory-to-implement codec > supports two people in typical German households communicate via video > in sign language, and how it does so relative to non-mandatory > options, as a simple example. If H.264 supports the scenario and H.261 > does not, then selecting H.261 does not in fact prevent the absolute > worst case and does not ensure that communication via video can always > happen. Bjoern, I'd like to point you to http://www.netindex.com/upload/allcountries/ for two reasons: 1. It states that Germany has an average upload rate of 3.13Mbps. 2. It shows that upload speeds are increasing over time. >> The fight against H.261 as MTI is really not about quality or >> efficiency, but rather, about forcing a royalty-bearing format on what >> should be an open standard and to save a few big players some >> implementation dollars because they might want to reuse some existing >> hardware, all of which are secondary points in this charter compared to >> a universally applicable MTI video codec. > Like I said, I have not seen a convincing argument that H.261 performs > well enough, and the implementation techniques that can reasonably be > assumed to be unencumbered are old enough that I think it is fair to > assume without investigating myself that selecting H.261 as only manda- > tory-to-implement video codec could work on paper, but not in practise. > > I read the "irrelevant" responses as essentially advocating that we may > just as well make sending raw and unencoded RGB data the MTI codec. I'm > more than willing to hear better arguments. The same goes for the H.263 > option that has been suggested. H.261 is meant as a fallback only in the case that the market cannot agree to upgrade to VP8 or H.264 at runtime. If a sizable portion of the market cannot agree at runtime, what makes you believe that that same sizable portion can agree on a MTI codec? And a final question, in case you disagree with everything I've written so far: How do you advocate we proceed in light of the fact that we already tried to (and failed) to reach consensus around VP8 and H.264? Gili --------------030306040008090406060407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/12/2013 9:00 PM, Bjoern Hoehrmann wrote:
I think it is highly relevant whether the mandatory-to-implement codec supports two people in typical German households communicate via video in sign language, and how it does so relative to non-mandatory options, as a simple example. If H.264 supports the scenario and H.261 does not, then selecting H.261 does not in fact prevent the absolute worst case and does not ensure that communication via video can always happen.

Bjoern,

I'd like to point you to http://www.netindex.com/upload/allcountries/ for two reasons:
  1. It states that Germany has an average upload rate of 3.13Mbps.
  2. It shows that upload speeds are increasing over time.
The fight against H.261 as MTI is really not about quality or
efficiency, but rather, about forcing a royalty-bearing format on what
should be an open standard and to save a few big players some
implementation dollars because they might want to reuse some existing
hardware, all of which are secondary points in this charter compared to
a universally applicable MTI video codec.

Like I said, I have not seen a convincing argument that H.261 performs
well enough, and the implementation techniques that can reasonably be
assumed to be unencumbered are old enough that I think it is fair to
assume without investigating myself that selecting H.261 as only manda-
tory-to-implement video codec could work on paper, but not in practise.

I read the "irrelevant" responses as essentially advocating that we may
just as well make sending raw and unencoded RGB data the MTI codec. I'm
more than willing to hear better arguments. The same goes for the H.263
option that has been suggested.

H.261 is meant as a fallback only in the case that the market cannot agree to upgrade to VP8 or H.264 at runtime. If a sizable portion of the market cannot agree at runtime, what makes you believe that that same sizable portion can agree on a MTI codec? And a final question, in case you disagree with everything I've written so far: How do you advocate we proceed in light of the fact that we already tried to (and failed) to reach consensus around VP8 and H.264?

Gili
--------------030306040008090406060407-- From basilgohar@librevideo.org Mon Dec 2 19:03:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D521AE034 for ; Mon, 2 Dec 2013 19:03:48 -0800 (PST) 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 jSj_D5BjtMxt for ; Mon, 2 Dec 2013 19:03:44 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 609251AE033 for ; Mon, 2 Dec 2013 19:03:44 -0800 (PST) Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 7E4E7659228 for ; Mon, 2 Dec 2013 22:03:41 -0500 (EST) Message-ID: <529D4A06.4080708@librevideo.org> Date: Mon, 02 Dec 2013 22:03:34 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rtcweb] H.261 encoding samples at typical bitrates - sign language example X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 03:03:48 -0000 Let's let any further discussions about the usability of H.261, or any other codec for that matter, use actual examples going forward. The following is a VERY quick test of ffmpeg's h261 encoder in the context of the IETF's rtcweb working group's discussion of an MTI (mandatory-to-implement) video codec. sine_irene_cif.y4m taken from derf's collection: http://media.xiph.org/video/derf/y4m/sign_irene_cif.y4m ffmpeg version N-58565-gc122e69 bitrate=64k,128k,256k,512k ffmpeg -i sign_irene_cif.y4m -codec:v h261 -b:v $bitrate -g 30 sign_irene_cif.y4m-$bitrate.h261 http://media.basilgohar.com/rtcweb/sign_irene_cif.y4m-64k.h261 (real rate: 157.8kbits/s) http://media.basilgohar.com/rtcweb/sign_irene_cif.y4m-128k.h261 (real rate: 165.6kbits/s) http://media.basilgohar.com/rtcweb/sign_irene_cif.y4m-256k.h261 (real rate: 289.5kbits/s) http://media.basilgohar.com/rtcweb/sign_irene_cif.y4m-512k.h261 (real rate: 541.8kbits/s) I apologize for the bitrate inflation, but if I had more time I can tweak the settings for a more accurate number. These are simply the rates that ffmpeg produced with such a short clip at the given requested rates. -- Libre Video http://librevideo.org From basilgohar@librevideo.org Mon Dec 2 19:10:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CACE1AD8CD for ; Mon, 2 Dec 2013 19:10:22 -0800 (PST) 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 wve8-FqnU-MO for ; Mon, 2 Dec 2013 19:10:20 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 968531AD73F for ; Mon, 2 Dec 2013 19:10:20 -0800 (PST) Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 0476F9D935D for ; Mon, 2 Dec 2013 22:10:17 -0500 (EST) Message-ID: <529D4B96.7070901@librevideo.org> Date: Mon, 02 Dec 2013 22:10:14 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: , <52974AA8.6080702@cisco.com>, <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com>, <52976F56.4020706@dcrocker.net>, <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com>, <5006.1385666853@sandelman.ca>, , , <20131129060936.GV3245@audi.shelbyville.oz>, <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de>, <529CEAA6.9000501@librevideo.org>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 03:10:22 -0000 On 12/02/2013 09:43 PM, Bernard Aboba wrote: > > I think it is highly relevant whether the mandatory-to-implement > codec supports two people in typical German households communicate via > video in sign language... > > [BA] This isn't just an issue for Germany. An inability to support > sign language would be "highly relevant" to compliance with the proposed > Section 255/508 revision in the US. > > From: > http://www.access-board.gov/attachments/article/490/draft-rule.pdf, > Section 408.8: > > "408.8 Video Communication. Where ICT that provides two way voice > communication includes real time video functionality, the quality of the > video shall be sufficient to support communication using sign language." I believe this is a moot point for H.261, as even at relatively low bitrates, in an unoptimized configuration, it can produce sufficiently high quality to clearly convey a person communicating with sign language. Please see my recent post entitled, "H.261 encoding samples at typical bitrates - sign language example" or the actual examples here (please see the text file that explains the real rates that ffmpeg ended-up using): http://media.basilgohar.com/rtcweb/ -- Libre Video http://librevideo.org From basilgohar@librevideo.org Mon Dec 2 20:23:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B251ADF95 for ; Mon, 2 Dec 2013 20:23:51 -0800 (PST) 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 FliToMqsqT5J for ; Mon, 2 Dec 2013 20:23:47 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7996E1ADFB5 for ; Mon, 2 Dec 2013 20:23:47 -0800 (PST) Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 39B6B9DA3EC for ; Mon, 2 Dec 2013 23:23:44 -0500 (EST) Message-ID: <529D5CCD.8070801@librevideo.org> Date: Mon, 02 Dec 2013 23:23:41 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "" References: <529D4A06.4080708@librevideo.org> In-Reply-To: <529D4A06.4080708@librevideo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 encoding samples at typical bitrates - sign language example X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 04:23:51 -0000 On 12/02/2013 10:03 PM, Basil Mohamed Gohar wrote: > Let's let any further discussions about the usability of H.261, or any > other codec for that matter, use actual examples going forward. > > The following is a VERY quick test of ffmpeg's h261 encoder in the > context of the IETF's rtcweb working group's discussion of an MTI > (mandatory-to-implement) video codec. > > sine_irene_cif.y4m taken from derf's collection: > > http://media.xiph.org/video/derf/y4m/sign_irene_cif.y4m > > ffmpeg version N-58565-gc122e69 > > bitrate=64k,128k,256k,512k > > ffmpeg -i sign_irene_cif.y4m -codec:v h261 -b:v $bitrate -g 30 > sign_irene_cif.y4m-$bitrate.h261 > > http://media.basilgohar.com/rtcweb/sign_irene_cif.y4m-64k.h261 > (real rate: 157.8kbits/s) > > http://media.basilgohar.com/rtcweb/sign_irene_cif.y4m-128k.h261 > (real rate: 165.6kbits/s) > > http://media.basilgohar.com/rtcweb/sign_irene_cif.y4m-256k.h261 > (real rate: 289.5kbits/s) > > http://media.basilgohar.com/rtcweb/sign_irene_cif.y4m-512k.h261 > (real rate: 541.8kbits/s) > > I apologize for the bitrate inflation, but if I had more time I can > tweak the settings for a more accurate number. These are simply the > rates that ffmpeg produced with such a short clip at the given requested > rates. > I've updated the encoding settings as follows to get more accurate resulting bitrates, but ffmpeg's h261 encoder seems to bottom-out at around ~140kbps, so the only examples from above that are close (after using the new settings) are 256k and 512k. for bitrate in {1..512}k; do ffmpeg -i ../sign_irene_cif.y4m -codec:v h261 -b:v $bitrate -minrate $bitrate -maxrate $bitrate -bufsize $bitrate -qmax 1024 -g 30 -y sign_irene_cif.y4m-$bitrate.h261; done; All the above posted examples can be viewed with mplayer and a bash command line using the following, if you're interested: mplayer http://media.basilgohar.com/rtcweb/sign_irene_cif.y4m-{64,128,256,512}k.h261 The full integer range of bitrates from 1 to 512 can be found here: http://media.basilgohar.com/rtcweb/h261/ Target bitrate and actual bitrate start to match around 150kbps with these new settings. I am currently exploring other codecs with the same methodology and will share the results accordingly. -- Libre Video http://librevideo.org From mperumal@cisco.com Mon Dec 2 20:30:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577601ADF95 for ; Mon, 2 Dec 2013 20:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 czTnH8fFYTeE for ; Mon, 2 Dec 2013 20:30:17 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 30BA81ADF38 for ; Mon, 2 Dec 2013 20:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5229; q=dns/txt; s=iport; t=1386045015; x=1387254615; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bal7/6ZRT+ULcFSO/Sa3gZjv9lRiBeIFQw0dnqLn9fQ=; b=PDbE+QIyuL5xofbu4XDFyInibBpxKWByQLXRaSxs9zj7UKbGhr50RnRR aNqziVrOfao9bYaDfvtcKVGz39a4VQW/8cxfawHKysdgBa6zo4wWvhVzJ mFmZj3miIAtyRebFOPKyvPkIFz/ih2b5LR5hBqo12S8Xcr0imDnTD/yN7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGddnVKtJV2c/2dsb2JhbABZgwc4U7gcToEaFnSCJQEBAQQBAQE3MgIIAwwEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCId5DcBeF45XMQcGgxqBEwOZRJBjgymCKg X-IronPort-AV: E=Sophos;i="4.93,815,1378857600"; d="scan'208";a="289025611" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 03 Dec 2013 04:30:14 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB34UERM003104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 04:30:14 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 22:30:14 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Martin Thomson , Magnus Westerlund Thread-Topic: [rtcweb] Consent alternative Thread-Index: AQHO77AWPi9LFgXOuUGt5r/tDp7yvppB3ZQQ Date: Tue, 3 Dec 2013 04:30:13 +0000 Message-ID: References: <52989933.6000907@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 04:30:19 -0000 |2. B (the attacker) triggers an "ICE restart" with A, though really |this generates a new ICE negotiation with a victim, C. C consents to |talk to B, but not necessarily with A. This arrangement is easy to |achieve on the drive-by web. | |3. A completes ICE with C and expects to continue the DTLS connection |over the newly discovered 5-tuple. Assuming this is a regular ICE restart, the STUN binding requests sent as p= art of the ICE connectivity checks from A to C would have randomly generate= d transaction IDs. Unless B is on the A-C path or can guess those transacti= on IDs, it wouldn't be able to generate legitimate binding responses to cau= se ICE to conclude b/w A and C. Muthu |-----Original Message----- |From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson |Sent: Tuesday, December 03, 2013 4:14 AM |To: Magnus Westerlund |Cc: Cullen Jennings (fluffy); rtcweb@ietf.org |Subject: Re: [rtcweb] Consent alternative | |On 29 November 2013 05:40, Magnus Westerlund | wrote: |> I have looked briefly on this and wonder if this isn't vulnerable to |> active attacks from a attacker (Alice) that likes to use a set of WebRTC |> browsers, including (Bob) to generate DDOS traffic towards the target |> (Charlie). | |Hi Magnus, | |I think that you did manage to hit on something critical here. | |The basic security primitive in play with ICE consent is proof of |receipt. That is the key piece at play here as well. We require |proof of receipt simply because that elevates the requirements for an |attacker to the point that they have to basically be on-path. At that |point, they (likely) already have the ability to generate traffic |toward a victim of an equal (or maybe greater) volume to the sender |and gain little by mounting the attack. | |That's why I'm not particularly interested in the part where you talk |about attackers intercepting binding requests. | |The actual attack that you have hit upon (or caused me to think about) |is not quite as you described, but it does rely on the fact that the |proposed change to the consent mechanism no longer actively depends on |proof of receipt. | |It also relies on the possibility that a DTLS connection can be moved |without requiring proof of receipt on the new path. That, to me, is |the fundamental problem to be solved. From my reread of RFC 6347, it |appears as though the only consideration given to DoS was at the |handshake. Once something like ICE is in play (and MICE makes this |worse), the ability to "move" the connection presents an attacker with |an opportunity. (I have to point out that this also confirms my fears |about the mechanism used to signal ICE restarts, but I'll get back to |that.) | |Here is the attack as I understand it: | |1. A talks to B, establishing a DTLS connection using ICE. There is |no need for lots of data to flow at this point, this is the "warm-up" |phase of the attack. | |2. B (the attacker) triggers an "ICE restart" with A, though really |this generates a new ICE negotiation with a victim, C. C consents to |talk to B, but not necessarily with A. This arrangement is easy to |achieve on the drive-by web. | |3. A completes ICE with C and expects to continue the DTLS connection |over the newly discovered 5-tuple. C is confused, but really has no |recourse at this point. Even if the DTLS connection fails, C is now |the victim on the other end of an unending stream of bits. B spoofs |the source address of the necessary packets to continue consent, A |continues to send to C, and nothing that C does can stop the flood |because they don't have access to the master secret and cannot |therefore produce an authenticated packet that terminates the |connection. B can continue the attack as long as A is willing, at the |bargain-basement price of a (spoofed) DTLS heartbeat response every |10-20 seconds. | |The key here is the lack of a proof of receipt from A toward C for the |DTLS connection that is moved. There is nothing inherent to DTLS that |provides proof that C received data from A and is also willing to |continue to communicate... Almost. | |The DTLS heartbeat extension does provide such a thing: |http://tools.ietf.org/html/rfc6520#page-6 | |All we need to do to close this little loophole is to require that a |DTLS heartbeat request be sent after any change in underlying 5-tuple. | That request MUST contain sufficient entropy that guessing would be |difficult for an off-path attacker; noting that this is also covered |by TLS record layer encryption and authentication, limiting the number |of parties that are even allowed to make a guess. I'm a big fan of |128 bits, but less is almost certainly OK. If no response is received |within N seconds, consent is expired. The basic consent timer seems |appropriate here, i.e., N=3D30. | |DTLS renegotiation would also work, but I consider that to be a little |heavyweight. I'm not sure that it's that widely implemented either. |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From mperumal@cisco.com Mon Dec 2 20:47:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4BD1ADFC4 for ; Mon, 2 Dec 2013 20:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 HYlm76N5Vjbs for ; Mon, 2 Dec 2013 20:47:27 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 40A811ADF6B for ; Mon, 2 Dec 2013 20:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1757; q=dns/txt; s=iport; t=1386046045; x=1387255645; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1wPeqnQVjkuaKuRVB1mmPla0UXFSh5AY9JvihOT6Tc8=; b=mxVzNbEogtLN1USJVwZKY5Yzw7qgn4cvwqNR1Nfo0jzZDFmOnrTJmdYK S6ccm6G5gh/hwwySByoGhKZ2fNAqSsi2qQIQpD8FJyUC3J6+B9jcEUKq0 FD4t0//+BLN3yD2EN+gb7bbWqI0UE2x2zlwE7bSDroUwgrlMewPhWJbGN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAGlhnVKtJV2c/2dsb2JhbABZgweBC7hqgRoWdIIlAQEBBDo/DAQCAQgRBAEBCxQJBzIUCQgCBAENBQiHecBtF45XMQcGgxqBEwOqJ4Mpgio X-IronPort-AV: E=Sophos;i="4.93,815,1378857600"; d="scan'208";a="3842545" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 03 Dec 2013 04:47:24 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB34lNXh022754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 04:47:24 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 22:47:23 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Tirumaleswar Reddy (tireddy)" , Christer Holmberg , Martin Thomson Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 Thread-Index: AQHO60O63kHRuwrIQkmVqlzIxQ7eZJo4sw3AgABpCYD//+ogoIAI5OWw Date: Tue, 3 Dec 2013 04:47:22 +0000 Message-ID: References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C55D40B@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A2426EF4D@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C55D48D@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A2426F209@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2426F209@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 04:47:29 -0000 |-----Original Message----- |From: Tirumaleswar Reddy (tireddy) |Sent: Wednesday, November 27, 2013 6:32 PM |To: Christer Holmberg; Martin Thomson |Cc: draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org; rtcweb@ietf.o= rg |Subject: RE: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshnes= s-00 | |> -----Original Message----- |> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] |> Sent: Wednesday, November 27, 2013 1:32 PM |> To: Tirumaleswar Reddy (tireddy); Martin Thomson |> Cc: draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org; rtcweb@ietf= .org |> Subject: RE: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshn= ess-00 |> |> Hi, |> |> >>> [1] and [2] can be solved by mandating WebRTC endpoints to support |> consent. |> >> |> >> I thought we were going to do that anyway - no matter what consent |> >> mechanism we use. |> > |> > If DTLS based consent mechanism is picked then both peers must support= DTLS |> heartbeat and willing to exchange DTLS heartbeat request/response. |> |> How is that different from using ICE for consent? That also require supp= ort |> from both peers, doesn't it ? | |Yes, ICE for consent also requires support from both peers. No, there is one difference when the peer is not sending any traffic (e.g V= oD): For the STUN based mechanism, the peer is required to support only ICE-lite= (or ICE) for the sender to verify consent freshness. With the DTLS based m= echanism, the peer is required to support DTLS Heartbeat (RFC6520) and resp= ond to HeartbeatRequest messages for the sender to verify consent freshness= . That is asking more from legacy implementations. Muthu | |-Tiru. | |> |> Regards, |> |> Christer From martin.thomson@gmail.com Mon Dec 2 21:38:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606111AE04A for ; Mon, 2 Dec 2013 21:38:21 -0800 (PST) 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 l_HiFF0w5Tei for ; Mon, 2 Dec 2013 21:38:18 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF0A1AE049 for ; Mon, 2 Dec 2013 21:38:17 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id z2so4436393wiv.13 for ; Mon, 02 Dec 2013 21:38:14 -0800 (PST) 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=C2EoCiDjRhn6nHyKHiaL0492LerBYDLRB5DIDOuTJDg=; b=QVvjfqH6jM6SA8MqkkvxlFSarjBvHUDvcC4gaEFHTLOdsN1mSXzexlw5bVbsZb5RDS 4cCJt99t7MaiHvIMWmwiHHdhyXYLAB/ZPkth5rEAMYMbZfmujcUVz0plYyQp2jNcEsAe EOjEMaz5W6ToIJmzzdymf9ABuiJYv0ULJM2F/VC35rzEoq5+HbO6mC0bg7H1PXCXfg67 +LdPxJrQPGPlPBRZR2Dwt/PZVM8/rr1/KjAtFYFx8EvN9pjGx3E+6e3/dJ/LehthwWDQ T4iQBTdu766US+1hekSdjeUH3eEh9JzZPZg9LNnAeiY9jOn0YyZ4sKPQMLj8fIqK2F+4 PFtA== MIME-Version: 1.0 X-Received: by 10.180.36.105 with SMTP id p9mr739407wij.58.1386049094500; Mon, 02 Dec 2013 21:38:14 -0800 (PST) Received: by 10.227.134.195 with HTTP; Mon, 2 Dec 2013 21:38:14 -0800 (PST) Received: by 10.227.134.195 with HTTP; Mon, 2 Dec 2013 21:38:14 -0800 (PST) In-Reply-To: References: <52989933.6000907@ericsson.com> Date: Mon, 2 Dec 2013 21:38:14 -0800 Message-ID: From: Martin Thomson To: "Muthu Arul Mozhi Perumal, (mperumal)" Content-Type: multipart/alternative; boundary=e89a8f503562eb471804ec9ab320 Cc: "Cullen Jennings \(fluffy\)" , rtcweb@ietf.org Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 05:38:21 -0000 --e89a8f503562eb471804ec9ab320 Content-Type: text/plain; charset=UTF-8 I think that you misunderstood. This looks like a restarted ICE to A (from B), but it is really an entirely new session to C. It completes because C is unwittingly duped into briefly visiting B's page, which only needs to be long enough to clear a single connectivity check. On Dec 2, 2013 8:30 PM, "Muthu Arul Mozhi Perumal (mperumal)" < mperumal@cisco.com> wrote: > > |2. B (the attacker) triggers an "ICE restart" with A, though really > |this generates a new ICE negotiation with a victim, C. C consents to > |talk to B, but not necessarily with A. This arrangement is easy to > |achieve on the drive-by web. > | > |3. A completes ICE with C and expects to continue the DTLS connection > |over the newly discovered 5-tuple. > > Assuming this is a regular ICE restart, the STUN binding requests sent as part of the ICE connectivity checks from A to C would have randomly generated transaction IDs. Unless B is on the A-C path or can guess those transaction IDs, it wouldn't be able to generate legitimate binding responses to cause ICE to conclude b/w A and C. > > Muthu > > |-----Original Message----- > |From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson > |Sent: Tuesday, December 03, 2013 4:14 AM > |To: Magnus Westerlund > |Cc: Cullen Jennings (fluffy); rtcweb@ietf.org > |Subject: Re: [rtcweb] Consent alternative > | > |On 29 November 2013 05:40, Magnus Westerlund > | wrote: > |> I have looked briefly on this and wonder if this isn't vulnerable to > |> active attacks from a attacker (Alice) that likes to use a set of WebRTC > |> browsers, including (Bob) to generate DDOS traffic towards the target > |> (Charlie). > | > |Hi Magnus, > | > |I think that you did manage to hit on something critical here. > | > |The basic security primitive in play with ICE consent is proof of > |receipt. That is the key piece at play here as well. We require > |proof of receipt simply because that elevates the requirements for an > |attacker to the point that they have to basically be on-path. At that > |point, they (likely) already have the ability to generate traffic > |toward a victim of an equal (or maybe greater) volume to the sender > |and gain little by mounting the attack. > | > |That's why I'm not particularly interested in the part where you talk > |about attackers intercepting binding requests. > | > |The actual attack that you have hit upon (or caused me to think about) > |is not quite as you described, but it does rely on the fact that the > |proposed change to the consent mechanism no longer actively depends on > |proof of receipt. > | > |It also relies on the possibility that a DTLS connection can be moved > |without requiring proof of receipt on the new path. That, to me, is > |the fundamental problem to be solved. From my reread of RFC 6347, it > |appears as though the only consideration given to DoS was at the > |handshake. Once something like ICE is in play (and MICE makes this > |worse), the ability to "move" the connection presents an attacker with > |an opportunity. (I have to point out that this also confirms my fears > |about the mechanism used to signal ICE restarts, but I'll get back to > |that.) > | > |Here is the attack as I understand it: > | > |1. A talks to B, establishing a DTLS connection using ICE. There is > |no need for lots of data to flow at this point, this is the "warm-up" > |phase of the attack. > | > |2. B (the attacker) triggers an "ICE restart" with A, though really > |this generates a new ICE negotiation with a victim, C. C consents to > |talk to B, but not necessarily with A. This arrangement is easy to > |achieve on the drive-by web. > | > |3. A completes ICE with C and expects to continue the DTLS connection > |over the newly discovered 5-tuple. C is confused, but really has no > |recourse at this point. Even if the DTLS connection fails, C is now > |the victim on the other end of an unending stream of bits. B spoofs > |the source address of the necessary packets to continue consent, A > |continues to send to C, and nothing that C does can stop the flood > |because they don't have access to the master secret and cannot > |therefore produce an authenticated packet that terminates the > |connection. B can continue the attack as long as A is willing, at the > |bargain-basement price of a (spoofed) DTLS heartbeat response every > |10-20 seconds. > | > |The key here is the lack of a proof of receipt from A toward C for the > |DTLS connection that is moved. There is nothing inherent to DTLS that > |provides proof that C received data from A and is also willing to > |continue to communicate... Almost. > | > |The DTLS heartbeat extension does provide such a thing: > |http://tools.ietf.org/html/rfc6520#page-6 > | > |All we need to do to close this little loophole is to require that a > |DTLS heartbeat request be sent after any change in underlying 5-tuple. > | That request MUST contain sufficient entropy that guessing would be > |difficult for an off-path attacker; noting that this is also covered > |by TLS record layer encryption and authentication, limiting the number > |of parties that are even allowed to make a guess. I'm a big fan of > |128 bits, but less is almost certainly OK. If no response is received > |within N seconds, consent is expired. The basic consent timer seems > |appropriate here, i.e., N=30. > | > |DTLS renegotiation would also work, but I consider that to be a little > |heavyweight. I'm not sure that it's that widely implemented either. > |_______________________________________________ > |rtcweb mailing list > |rtcweb@ietf.org > |https://www.ietf.org/mailman/listinfo/rtcweb --e89a8f503562eb471804ec9ab320 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think that you misunderstood. This looks like a restarted = ICE to A (from B), but it is really an entirely new session to C. It comple= tes because C is unwittingly duped into briefly visiting B's page, whic= h only needs to be long enough to clear a single connectivity check.

On Dec 2, 2013 8:30 PM, "Muthu Arul Mozhi Perumal (mper= umal)" <mperumal@cisco.com> wrote:
>
> |2. B (the attacker) triggers an "ICE restart" with A, thoug= h really
> |this generates a new ICE negotiation with a victim, C. =C2=A0C consen= ts to
> |talk to B, but not necessarily with A. =C2=A0This arrangement is easy= to
> |achieve on the drive-by web.
> |
> |3. A completes ICE with C and expects to continue the DTLS connection=
> |over the newly discovered 5-tuple.
>
> Assuming this is a regular ICE restart, the STUN binding requests sent= as part of the ICE connectivity checks from A to C would have randomly gen= erated transaction IDs. Unless B is on the A-C path or can guess those tran= saction IDs, it wouldn't be able to generate legitimate binding respons= es to cause ICE to conclude b/w A and C.
>
> Muthu
>
> |-----Original Message-----
> |From: rtcweb [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Martin Thomson
> |Sent: Tuesday, December 03, 2013 4:14 AM
> |To: Magnus Westerlund
> |Cc: Cullen Jennings (fluffy); rtcw= eb@ietf.org
> |Subject: Re: [rtcweb] Consent alternative
> |
> |On 29 November 2013 05:40, Magnus Westerlund
> |<magnus.westerlu= nd@ericsson.com> wrote:
> |> I have looked briefly on this and wonder if this isn't vulne= rable to
> |> active attacks from a attacker (Alice) that likes to use a set o= f WebRTC
> |> browsers, including (Bob) to generate DDOS traffic towards the t= arget
> |> (Charlie).
> |
> |Hi Magnus,
> |
> |I think that you did manage to hit on something critical here.
> |
> |The basic security primitive in play with ICE consent is proof of
> |receipt. =C2=A0That is the key piece at play here as well. =C2=A0We r= equire
> |proof of receipt simply because that elevates the requirements for an=
> |attacker to the point that they have to basically be on-path. =C2=A0A= t that
> |point, they (likely) already have the ability to generate traffic
> |toward a victim of an equal (or maybe greater) volume to the sender > |and gain little by mounting the attack.
> |
> |That's why I'm not particularly interested in the part where = you talk
> |about attackers intercepting binding requests.
> |
> |The actual attack that you have hit upon (or caused me to think about= )
> |is not quite as you described, but it does rely on the fact that the<= br> > |proposed change to the consent mechanism no longer actively depends o= n
> |proof of receipt.
> |
> |It also relies on the possibility that a DTLS connection can be moved=
> |without requiring proof of receipt on the new path. =C2=A0That, to me= , is
> |the fundamental problem to be solved. =C2=A0From my reread of RFC 634= 7, it
> |appears as though the only consideration given to DoS was at the
> |handshake. =C2=A0Once something like ICE is in play (and MICE makes t= his
> |worse), the ability to "move" the connection presents an at= tacker with
> |an opportunity. =C2=A0(I have to point out that this also confirms my= fears
> |about the mechanism used to signal ICE restarts, but I'll get bac= k to
> |that.)
> |
> |Here is the attack as I understand it:
> |
> |1. A talks to B, establishing a DTLS connection using ICE. =C2=A0Ther= e is
> |no need for lots of data to flow at this point, this is the "war= m-up"
> |phase of the attack.
> |
> |2. B (the attacker) triggers an "ICE restart" with A, thoug= h really
> |this generates a new ICE negotiation with a victim, C. =C2=A0C consen= ts to
> |talk to B, but not necessarily with A. =C2=A0This arrangement is easy= to
> |achieve on the drive-by web.
> |
> |3. A completes ICE with C and expects to continue the DTLS connection=
> |over the newly discovered 5-tuple. =C2=A0C is confused, but really ha= s no
> |recourse at this point. =C2=A0Even if the DTLS connection fails, C is= now
> |the victim on the other end of an unending stream of bits. =C2=A0B sp= oofs
> |the source address of the necessary packets to continue consent, A > |continues to send to C, and nothing that C does can stop the flood > |because they don't have access to the master secret and cannot > |therefore produce an authenticated packet that terminates the
> |connection. =C2=A0B can continue the attack as long as A is willing, = at the
> |bargain-basement price of a (spoofed) DTLS heartbeat response every > |10-20 seconds.
> |
> |The key here is the lack of a proof of receipt from A toward C for th= e
> |DTLS connection that is moved. =C2=A0There is nothing inherent to DTL= S that
> |provides proof that C received data from A and is also willing to
> |continue to communicate... Almost.
> |
> |The DTLS heartbeat extension does provide such a thing:
> |http://tools.ie= tf.org/html/rfc6520#page-6
> |
> |All we need to do to close this little loophole is to require that a<= br> > |DTLS heartbeat request be sent after any change in underlying 5-tuple= .
> | That request MUST contain sufficient entropy that guessing would be<= br> > |difficult for an off-path attacker; noting that this is also covered<= br> > |by TLS record layer encryption and authentication, limiting the numbe= r
> |of parties that are even allowed to make a guess. =C2=A0I'm a big= fan of
> |128 bits, but less is almost certainly OK. =C2=A0If no response is re= ceived
> |within N seconds, consent is expired. =C2=A0The basic consent timer s= eems
> |appropriate here, i.e., N=3D30.
> |
> |DTLS renegotiation would also work, but I consider that to be a littl= e
> |heavyweight. =C2=A0I'm not sure that it's that widely impleme= nted either.
> |_______________________________________________
> |rtcweb mailing list
> |rtcweb@ietf.org
> |https://www.= ietf.org/mailman/listinfo/rtcweb

--e89a8f503562eb471804ec9ab320-- From michelg@upperside.fr Tue Dec 3 02:48:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FFF1AE0FA for ; Tue, 3 Dec 2013 02:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.501 X-Spam-Level: * X-Spam-Status: No, score=1.501 tagged_above=-999 required=5 tests=[BAYES_60=1.5, HTML_MESSAGE=0.001, 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 afdrXlw5sMZG for ; Tue, 3 Dec 2013 02:48:25 -0800 (PST) Received: from smtp28.msg.oleane.net (smtp28.msg.oleane.net [62.161.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id DF79C1A8026 for ; Tue, 3 Dec 2013 02:48:24 -0800 (PST) Received: from MichelGosseDel (AAubervilliers-752-1-4-25.w90-35.abo.wanadoo.fr [90.35.155.25]) (authenticated) by smtp28.msg.oleane.net (MSA) with ESMTP id rB3AmJSP003082 for ; Tue, 3 Dec 2013 11:48:19 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Tue, 3 Dec 2013 11:48:14 +0100 Message-ID: <00c301cef015$2e6dcb90$8b4962b0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C4_01CEF01D.90358EF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7wE1bP++lIKcwwQRCCh3OGe8TNpg== Content-Language: fr X-Backend: vm-smtp-sophos15 X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.3.100617 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [rtcweb] WebRTC 2013: The First Real-World Deployments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 10:48:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C4_01CEF01D.90358EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WebRTC Conference will open its doors December 10 in Paris Roissy CDG. The success of the exhibition, the quality of the demos at the Start-Up Speed Dating as well as the reports from the first deployments demonstrate that WebRTC is the technology of the future. More information: http://www.uppersideconferences.com/webrtc2013/webrtc2013intro.html ------=_NextPart_000_00C4_01CEF01D.90358EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WebRTC Conference will open its doors December 10 = in Paris Roissy CDG.

The success of the exhibition, the quality = of the demos at the Start-Up Speed Dating as well as the reports from = the first deployments demonstrate

that WebRTC is the technology of the = future.

 

More information:

http://www.uppersideconferences.com/web= rtc2013/webrtc2013intro.html

------=_NextPart_000_00C4_01CEF01D.90358EF0-- From mperumal@cisco.com Tue Dec 3 04:48:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDBA1AE139 for ; Tue, 3 Dec 2013 04:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 Wyn8Q4HSaSJF for ; Tue, 3 Dec 2013 04:48:28 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BE8341ADEA6 for ; Tue, 3 Dec 2013 04:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24156; q=dns/txt; s=iport; t=1386074905; x=1387284505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5bqWLB2FmE36zvTc078LwWSRMwRwtX/kSC6MmUr5UaQ=; b=UvkxvkYCL7vI+OFDP9F3WsUTG/o0uHujQUUtgkoQaJRXyjcowjcvlu8a sBH7NI3OT+0j1NN47dj8Dfel5PJMi0Nb5HduhVW60G0+Yv3dJH1PD6G4M vcln1tnxALFV6BSG5ZbJSRn++6+eUgVPckJOtqjd1gTi4bkLI1hNRaqqc E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQHABrSnVKtJV2Y/2dsb2JhbABagkNEOFOCeq0diAJOGIEDFnSCJQEBAQQBAQEgCj8CCAMMBAIBCBEEAQEBCh0DAgICHwYLFAkIAgQOBQiHZwMPDbB9iQYNhzsXjG2BYBYXBAYBBoJlNYETA5YpgxuLKoU5gymCKg X-IronPort-AV: E=Sophos;i="4.93,817,1378857600"; d="scan'208,217";a="286025277" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 03 Dec 2013 12:48:24 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB3CmOXE008631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 12:48:24 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 06:48:24 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Martin Thomson Thread-Topic: [rtcweb] Consent alternative Thread-Index: AQHO77AWPi9LFgXOuUGt5r/tDp7yvppB3ZQQgAB7WQCAAAzaoA== Date: Tue, 3 Dec 2013 12:48:23 +0000 Message-ID: References: <52989933.6000907@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.69.3] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE22437073Axmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 12:48:31 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE22437073Axmbrcdx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCdzIGEgdHlwaWNhbCB0aGlyZCBwYXJ0eSBjYWxsIGNvbnRyb2wgKDNQQ0MpIHVzZSBjYXNl IHdoZXJlIEIgKDNQQ0MpIG1hbmdsZXMgY2FsbCBzaWduYWxpbmcgKyBTRFAgYi93IEEgYW5kIEMg YW5kIHNldHMgdXAgdGhlIG1lZGlhIHNlc3Npb24gYmV0d2VlbiB0aGVtLiBUaGUgc2VjdXJpdHkg b2YgSUNFIChhcyBkZWZpbmVkIGluIFJGQzUyNDUpIGlzIHJvb3RlZCBpbiB0aGUgaWNlLXVmcmFn IGFuZCBpY2UtcHdkIGV4Y2hhbmdlZCBpbiBjYWxsIHNpZ25hbGluZy4gSWYgYSAzUENDIGNhbiBt YW5nbGUgdGhlbSwgSUNFIGNhbid0IHByZXZlbnQgdGhlIGNvbm5lY3Rpdml0eSBjaGVjayBmcm9t IHN1Y2NlZWRpbmcuDQoNCklmIGl0IGlzIGRlZW1lZCBhIHByb2JsZW0sIGl0IG1pZ2h0IG5lZWQg YW4gSUNFIGV4dGVuc2lvbiB0byBmYWlsIHRoZSBjb25uZWN0aXZpdHkgY2hlY2sgYi93IEEgYW5k IEMuDQoNCk11dGh1DQoNCkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21z b25AZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDMsIDIwMTMgMTE6MDggQU0N ClRvOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KQ2M6IHJ0Y3dlYkBpZXRm Lm9yZzsgTWFnbnVzIFdlc3Rlcmx1bmQ7IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KQ0KU3ViamVj dDogUkU6IFtydGN3ZWJdIENvbnNlbnQgYWx0ZXJuYXRpdmUNCg0KDQpJIHRoaW5rIHRoYXQgeW91 IG1pc3VuZGVyc3Rvb2QuIFRoaXMgbG9va3MgbGlrZSBhIHJlc3RhcnRlZCBJQ0UgdG8gQSAoZnJv bSBCKSwgYnV0IGl0IGlzIHJlYWxseSBhbiBlbnRpcmVseSBuZXcgc2Vzc2lvbiB0byBDLiBJdCBj b21wbGV0ZXMgYmVjYXVzZSBDIGlzIHVud2l0dGluZ2x5IGR1cGVkIGludG8gYnJpZWZseSB2aXNp dGluZyBCJ3MgcGFnZSwgd2hpY2ggb25seSBuZWVkcyB0byBiZSBsb25nIGVub3VnaCB0byBjbGVh ciBhIHNpbmdsZSBjb25uZWN0aXZpdHkgY2hlY2suDQoNCk9uIERlYyAyLCAyMDEzIDg6MzAgUE0s ICJNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKSIgPG1wZXJ1bWFsQGNpc2NvLmNv bTxtYWlsdG86bXBlcnVtYWxAY2lzY28uY29tPj4gd3JvdGU6DQo+DQo+IHwyLiBCICh0aGUgYXR0 YWNrZXIpIHRyaWdnZXJzIGFuICJJQ0UgcmVzdGFydCIgd2l0aCBBLCB0aG91Z2ggcmVhbGx5DQo+ IHx0aGlzIGdlbmVyYXRlcyBhIG5ldyBJQ0UgbmVnb3RpYXRpb24gd2l0aCBhIHZpY3RpbSwgQy4g IEMgY29uc2VudHMgdG8NCj4gfHRhbGsgdG8gQiwgYnV0IG5vdCBuZWNlc3NhcmlseSB3aXRoIEEu ICBUaGlzIGFycmFuZ2VtZW50IGlzIGVhc3kgdG8NCj4gfGFjaGlldmUgb24gdGhlIGRyaXZlLWJ5 IHdlYi4NCj4gfA0KPiB8My4gQSBjb21wbGV0ZXMgSUNFIHdpdGggQyBhbmQgZXhwZWN0cyB0byBj b250aW51ZSB0aGUgRFRMUyBjb25uZWN0aW9uDQo+IHxvdmVyIHRoZSBuZXdseSBkaXNjb3ZlcmVk IDUtdHVwbGUuDQo+DQo+IEFzc3VtaW5nIHRoaXMgaXMgYSByZWd1bGFyIElDRSByZXN0YXJ0LCB0 aGUgU1RVTiBiaW5kaW5nIHJlcXVlc3RzIHNlbnQgYXMgcGFydCBvZiB0aGUgSUNFIGNvbm5lY3Rp dml0eSBjaGVja3MgZnJvbSBBIHRvIEMgd291bGQgaGF2ZSByYW5kb21seSBnZW5lcmF0ZWQgdHJh bnNhY3Rpb24gSURzLiBVbmxlc3MgQiBpcyBvbiB0aGUgQS1DIHBhdGggb3IgY2FuIGd1ZXNzIHRo b3NlIHRyYW5zYWN0aW9uIElEcywgaXQgd291bGRuJ3QgYmUgYWJsZSB0byBnZW5lcmF0ZSBsZWdp dGltYXRlIGJpbmRpbmcgcmVzcG9uc2VzIHRvIGNhdXNlIElDRSB0byBjb25jbHVkZSBiL3cgQSBh bmQgQy4NCj4NCj4gTXV0aHUNCj4NCj4gfC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IHxG cm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NCj4gfFNlbnQ6 IFR1ZXNkYXksIERlY2VtYmVyIDAzLCAyMDEzIDQ6MTQgQU0NCj4gfFRvOiBNYWdudXMgV2VzdGVy bHVuZA0KPiB8Q2M6IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KTsgcnRjd2ViQGlldGYub3JnPG1h aWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQo+IHxTdWJqZWN0OiBSZTogW3J0Y3dlYl0gQ29uc2VudCBh bHRlcm5hdGl2ZQ0KPiB8DQo+IHxPbiAyOSBOb3ZlbWJlciAyMDEzIDA1OjQwLCBNYWdudXMgV2Vz dGVybHVuZA0KPiB8PG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTxtYWlsdG86bWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+IHw+IEkgaGF2ZSBsb29rZWQgYnJp ZWZseSBvbiB0aGlzIGFuZCB3b25kZXIgaWYgdGhpcyBpc24ndCB2dWxuZXJhYmxlIHRvDQo+IHw+ IGFjdGl2ZSBhdHRhY2tzIGZyb20gYSBhdHRhY2tlciAoQWxpY2UpIHRoYXQgbGlrZXMgdG8gdXNl IGEgc2V0IG9mIFdlYlJUQw0KPiB8PiBicm93c2VycywgaW5jbHVkaW5nIChCb2IpIHRvIGdlbmVy YXRlIERET1MgdHJhZmZpYyB0b3dhcmRzIHRoZSB0YXJnZXQNCj4gfD4gKENoYXJsaWUpLg0KPiB8 DQo+IHxIaSBNYWdudXMsDQo+IHwNCj4gfEkgdGhpbmsgdGhhdCB5b3UgZGlkIG1hbmFnZSB0byBo aXQgb24gc29tZXRoaW5nIGNyaXRpY2FsIGhlcmUuDQo+IHwNCj4gfFRoZSBiYXNpYyBzZWN1cml0 eSBwcmltaXRpdmUgaW4gcGxheSB3aXRoIElDRSBjb25zZW50IGlzIHByb29mIG9mDQo+IHxyZWNl aXB0LiAgVGhhdCBpcyB0aGUga2V5IHBpZWNlIGF0IHBsYXkgaGVyZSBhcyB3ZWxsLiAgV2UgcmVx dWlyZQ0KPiB8cHJvb2Ygb2YgcmVjZWlwdCBzaW1wbHkgYmVjYXVzZSB0aGF0IGVsZXZhdGVzIHRo ZSByZXF1aXJlbWVudHMgZm9yIGFuDQo+IHxhdHRhY2tlciB0byB0aGUgcG9pbnQgdGhhdCB0aGV5 IGhhdmUgdG8gYmFzaWNhbGx5IGJlIG9uLXBhdGguICBBdCB0aGF0DQo+IHxwb2ludCwgdGhleSAo bGlrZWx5KSBhbHJlYWR5IGhhdmUgdGhlIGFiaWxpdHkgdG8gZ2VuZXJhdGUgdHJhZmZpYw0KPiB8 dG93YXJkIGEgdmljdGltIG9mIGFuIGVxdWFsIChvciBtYXliZSBncmVhdGVyKSB2b2x1bWUgdG8g dGhlIHNlbmRlcg0KPiB8YW5kIGdhaW4gbGl0dGxlIGJ5IG1vdW50aW5nIHRoZSBhdHRhY2suDQo+ IHwNCj4gfFRoYXQncyB3aHkgSSdtIG5vdCBwYXJ0aWN1bGFybHkgaW50ZXJlc3RlZCBpbiB0aGUg cGFydCB3aGVyZSB5b3UgdGFsaw0KPiB8YWJvdXQgYXR0YWNrZXJzIGludGVyY2VwdGluZyBiaW5k aW5nIHJlcXVlc3RzLg0KPiB8DQo+IHxUaGUgYWN0dWFsIGF0dGFjayB0aGF0IHlvdSBoYXZlIGhp dCB1cG9uIChvciBjYXVzZWQgbWUgdG8gdGhpbmsgYWJvdXQpDQo+IHxpcyBub3QgcXVpdGUgYXMg eW91IGRlc2NyaWJlZCwgYnV0IGl0IGRvZXMgcmVseSBvbiB0aGUgZmFjdCB0aGF0IHRoZQ0KPiB8 cHJvcG9zZWQgY2hhbmdlIHRvIHRoZSBjb25zZW50IG1lY2hhbmlzbSBubyBsb25nZXIgYWN0aXZl bHkgZGVwZW5kcyBvbg0KPiB8cHJvb2Ygb2YgcmVjZWlwdC4NCj4gfA0KPiB8SXQgYWxzbyByZWxp ZXMgb24gdGhlIHBvc3NpYmlsaXR5IHRoYXQgYSBEVExTIGNvbm5lY3Rpb24gY2FuIGJlIG1vdmVk DQo+IHx3aXRob3V0IHJlcXVpcmluZyBwcm9vZiBvZiByZWNlaXB0IG9uIHRoZSBuZXcgcGF0aC4g IFRoYXQsIHRvIG1lLCBpcw0KPiB8dGhlIGZ1bmRhbWVudGFsIHByb2JsZW0gdG8gYmUgc29sdmVk LiAgRnJvbSBteSByZXJlYWQgb2YgUkZDIDYzNDcsIGl0DQo+IHxhcHBlYXJzIGFzIHRob3VnaCB0 aGUgb25seSBjb25zaWRlcmF0aW9uIGdpdmVuIHRvIERvUyB3YXMgYXQgdGhlDQo+IHxoYW5kc2hh a2UuICBPbmNlIHNvbWV0aGluZyBsaWtlIElDRSBpcyBpbiBwbGF5IChhbmQgTUlDRSBtYWtlcyB0 aGlzDQo+IHx3b3JzZSksIHRoZSBhYmlsaXR5IHRvICJtb3ZlIiB0aGUgY29ubmVjdGlvbiBwcmVz ZW50cyBhbiBhdHRhY2tlciB3aXRoDQo+IHxhbiBvcHBvcnR1bml0eS4gIChJIGhhdmUgdG8gcG9p bnQgb3V0IHRoYXQgdGhpcyBhbHNvIGNvbmZpcm1zIG15IGZlYXJzDQo+IHxhYm91dCB0aGUgbWVj aGFuaXNtIHVzZWQgdG8gc2lnbmFsIElDRSByZXN0YXJ0cywgYnV0IEknbGwgZ2V0IGJhY2sgdG8N Cj4gfHRoYXQuKQ0KPiB8DQo+IHxIZXJlIGlzIHRoZSBhdHRhY2sgYXMgSSB1bmRlcnN0YW5kIGl0 Og0KPiB8DQo+IHwxLiBBIHRhbGtzIHRvIEIsIGVzdGFibGlzaGluZyBhIERUTFMgY29ubmVjdGlv biB1c2luZyBJQ0UuICBUaGVyZSBpcw0KPiB8bm8gbmVlZCBmb3IgbG90cyBvZiBkYXRhIHRvIGZs b3cgYXQgdGhpcyBwb2ludCwgdGhpcyBpcyB0aGUgIndhcm0tdXAiDQo+IHxwaGFzZSBvZiB0aGUg YXR0YWNrLg0KPiB8DQo+IHwyLiBCICh0aGUgYXR0YWNrZXIpIHRyaWdnZXJzIGFuICJJQ0UgcmVz dGFydCIgd2l0aCBBLCB0aG91Z2ggcmVhbGx5DQo+IHx0aGlzIGdlbmVyYXRlcyBhIG5ldyBJQ0Ug bmVnb3RpYXRpb24gd2l0aCBhIHZpY3RpbSwgQy4gIEMgY29uc2VudHMgdG8NCj4gfHRhbGsgdG8g QiwgYnV0IG5vdCBuZWNlc3NhcmlseSB3aXRoIEEuICBUaGlzIGFycmFuZ2VtZW50IGlzIGVhc3kg dG8NCj4gfGFjaGlldmUgb24gdGhlIGRyaXZlLWJ5IHdlYi4NCj4gfA0KPiB8My4gQSBjb21wbGV0 ZXMgSUNFIHdpdGggQyBhbmQgZXhwZWN0cyB0byBjb250aW51ZSB0aGUgRFRMUyBjb25uZWN0aW9u DQo+IHxvdmVyIHRoZSBuZXdseSBkaXNjb3ZlcmVkIDUtdHVwbGUuICBDIGlzIGNvbmZ1c2VkLCBi dXQgcmVhbGx5IGhhcyBubw0KPiB8cmVjb3Vyc2UgYXQgdGhpcyBwb2ludC4gIEV2ZW4gaWYgdGhl IERUTFMgY29ubmVjdGlvbiBmYWlscywgQyBpcyBub3cNCj4gfHRoZSB2aWN0aW0gb24gdGhlIG90 aGVyIGVuZCBvZiBhbiB1bmVuZGluZyBzdHJlYW0gb2YgYml0cy4gIEIgc3Bvb2ZzDQo+IHx0aGUg c291cmNlIGFkZHJlc3Mgb2YgdGhlIG5lY2Vzc2FyeSBwYWNrZXRzIHRvIGNvbnRpbnVlIGNvbnNl bnQsIEENCj4gfGNvbnRpbnVlcyB0byBzZW5kIHRvIEMsIGFuZCBub3RoaW5nIHRoYXQgQyBkb2Vz IGNhbiBzdG9wIHRoZSBmbG9vZA0KPiB8YmVjYXVzZSB0aGV5IGRvbid0IGhhdmUgYWNjZXNzIHRv IHRoZSBtYXN0ZXIgc2VjcmV0IGFuZCBjYW5ub3QNCj4gfHRoZXJlZm9yZSBwcm9kdWNlIGFuIGF1 dGhlbnRpY2F0ZWQgcGFja2V0IHRoYXQgdGVybWluYXRlcyB0aGUNCj4gfGNvbm5lY3Rpb24uICBC IGNhbiBjb250aW51ZSB0aGUgYXR0YWNrIGFzIGxvbmcgYXMgQSBpcyB3aWxsaW5nLCBhdCB0aGUN Cj4gfGJhcmdhaW4tYmFzZW1lbnQgcHJpY2Ugb2YgYSAoc3Bvb2ZlZCkgRFRMUyBoZWFydGJlYXQg cmVzcG9uc2UgZXZlcnkNCj4gfDEwLTIwIHNlY29uZHMuDQo+IHwNCj4gfFRoZSBrZXkgaGVyZSBp cyB0aGUgbGFjayBvZiBhIHByb29mIG9mIHJlY2VpcHQgZnJvbSBBIHRvd2FyZCBDIGZvciB0aGUN Cj4gfERUTFMgY29ubmVjdGlvbiB0aGF0IGlzIG1vdmVkLiAgVGhlcmUgaXMgbm90aGluZyBpbmhl cmVudCB0byBEVExTIHRoYXQNCj4gfHByb3ZpZGVzIHByb29mIHRoYXQgQyByZWNlaXZlZCBkYXRh IGZyb20gQSBhbmQgaXMgYWxzbyB3aWxsaW5nIHRvDQo+IHxjb250aW51ZSB0byBjb21tdW5pY2F0 ZS4uLiBBbG1vc3QuDQo+IHwNCj4gfFRoZSBEVExTIGhlYXJ0YmVhdCBleHRlbnNpb24gZG9lcyBw cm92aWRlIHN1Y2ggYSB0aGluZzoNCj4gfGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1 MjAjcGFnZS02DQo+IHwNCj4gfEFsbCB3ZSBuZWVkIHRvIGRvIHRvIGNsb3NlIHRoaXMgbGl0dGxl IGxvb3Bob2xlIGlzIHRvIHJlcXVpcmUgdGhhdCBhDQo+IHxEVExTIGhlYXJ0YmVhdCByZXF1ZXN0 IGJlIHNlbnQgYWZ0ZXIgYW55IGNoYW5nZSBpbiB1bmRlcmx5aW5nIDUtdHVwbGUuDQo+IHwgVGhh dCByZXF1ZXN0IE1VU1QgY29udGFpbiBzdWZmaWNpZW50IGVudHJvcHkgdGhhdCBndWVzc2luZyB3 b3VsZCBiZQ0KPiB8ZGlmZmljdWx0IGZvciBhbiBvZmYtcGF0aCBhdHRhY2tlcjsgbm90aW5nIHRo YXQgdGhpcyBpcyBhbHNvIGNvdmVyZWQNCj4gfGJ5IFRMUyByZWNvcmQgbGF5ZXIgZW5jcnlwdGlv biBhbmQgYXV0aGVudGljYXRpb24sIGxpbWl0aW5nIHRoZSBudW1iZXINCj4gfG9mIHBhcnRpZXMg dGhhdCBhcmUgZXZlbiBhbGxvd2VkIHRvIG1ha2UgYSBndWVzcy4gIEknbSBhIGJpZyBmYW4gb2YN Cj4gfDEyOCBiaXRzLCBidXQgbGVzcyBpcyBhbG1vc3QgY2VydGFpbmx5IE9LLiAgSWYgbm8gcmVz cG9uc2UgaXMgcmVjZWl2ZWQNCj4gfHdpdGhpbiBOIHNlY29uZHMsIGNvbnNlbnQgaXMgZXhwaXJl ZC4gIFRoZSBiYXNpYyBjb25zZW50IHRpbWVyIHNlZW1zDQo+IHxhcHByb3ByaWF0ZSBoZXJlLCBp LmUuLCBOPTMwLg0KPiB8DQo+IHxEVExTIHJlbmVnb3RpYXRpb24gd291bGQgYWxzbyB3b3JrLCBi dXQgSSBjb25zaWRlciB0aGF0IHRvIGJlIGEgbGl0dGxlDQo+IHxoZWF2eXdlaWdodC4gIEknbSBu b3Qgc3VyZSB0aGF0IGl0J3MgdGhhdCB3aWRlbHkgaW1wbGVtZW50ZWQgZWl0aGVyLg0KPiB8X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gfHJ0Y3dlYiBt YWlsaW5nIGxpc3QNCj4gfHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0K PiB8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== --_000_E721D8C6A2E1544DB2DEBC313AF54DE22437073Axmbrcdx02ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGF0J3MgYSB0eXBpY2FsIHRo aXJkIHBhcnR5IGNhbGwgY29udHJvbCAoM1BDQykgdXNlIGNhc2Ugd2hlcmUgQiAoM1BDQykgbWFu Z2xlcyBjYWxsIHNpZ25hbGluZyAmIzQzOyBTRFAgYi93IEEgYW5kIEMgYW5kIHNldHMgdXAgdGhl IG1lZGlhIHNlc3Npb24gYmV0d2VlbiB0aGVtLiBUaGUgc2VjdXJpdHkgb2YgSUNFIChhcw0KIGRl ZmluZWQgaW4gUkZDNTI0NSkgaXMgcm9vdGVkIGluIHRoZSBpY2UtdWZyYWcgYW5kIGljZS1wd2Qg ZXhjaGFuZ2VkIGluIGNhbGwgc2lnbmFsaW5nLiBJZiBhIDNQQ0MgY2FuIG1hbmdsZSB0aGVtLCBJ Q0UgY2FuJ3QgcHJldmVudCB0aGUgY29ubmVjdGl2aXR5IGNoZWNrIGZyb20gc3VjY2VlZGluZy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PklmIGl0IGlzIGRlZW1lZCBhIHByb2JsZW0sIGl0IG1pZ2h0IG5lZWQgYW4gSUNFIGV4dGVuc2lv biB0byBmYWlsIHRoZSBjb25uZWN0aXZpdHkgY2hlY2sgYi93IEEgYW5kIEMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NdXRodTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBEZWNlbWJlciAwMywgMjAxMyAxMTowOCBBTTxi cj4NCjxiPlRvOjwvYj4gTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk8YnI+DQo8 Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzsgTWFnbnVzIFdlc3Rlcmx1bmQ7IEN1bGxlbiBKZW5u aW5ncyAoZmx1ZmZ5KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3J0Y3dlYl0gQ29uc2VudCBh bHRlcm5hdGl2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPkkgdGhpbmsgdGhhdCB5b3Ug bWlzdW5kZXJzdG9vZC4gVGhpcyBsb29rcyBsaWtlIGEgcmVzdGFydGVkIElDRSB0byBBIChmcm9t IEIpLCBidXQgaXQgaXMgcmVhbGx5IGFuIGVudGlyZWx5IG5ldyBzZXNzaW9uIHRvIEMuIEl0IGNv bXBsZXRlcyBiZWNhdXNlIEMgaXMgdW53aXR0aW5nbHkgZHVwZWQgaW50byBicmllZmx5IHZpc2l0 aW5nIEIncyBwYWdlLCB3aGljaCBvbmx5IG5lZWRzIHRvIGJlIGxvbmcgZW5vdWdoIHRvIGNsZWFy IGEgc2luZ2xlDQogY29ubmVjdGl2aXR5IGNoZWNrLjxvOnA+PC9vOnA+PC9wPg0KPHA+T24gRGVj IDIsIDIwMTMgODozMCBQTSwgJnF1b3Q7TXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1h bCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcGVydW1hbEBjaXNjby5jb20iPm1wZXJ1bWFs QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IHwyLiBCICh0aGUg YXR0YWNrZXIpIHRyaWdnZXJzIGFuICZxdW90O0lDRSByZXN0YXJ0JnF1b3Q7IHdpdGggQSwgdGhv dWdoIHJlYWxseTxicj4NCiZndDsgfHRoaXMgZ2VuZXJhdGVzIGEgbmV3IElDRSBuZWdvdGlhdGlv biB3aXRoIGEgdmljdGltLCBDLiAmbmJzcDtDIGNvbnNlbnRzIHRvPGJyPg0KJmd0OyB8dGFsayB0 byBCLCBidXQgbm90IG5lY2Vzc2FyaWx5IHdpdGggQS4gJm5ic3A7VGhpcyBhcnJhbmdlbWVudCBp cyBlYXN5IHRvPGJyPg0KJmd0OyB8YWNoaWV2ZSBvbiB0aGUgZHJpdmUtYnkgd2ViLjxicj4NCiZn dDsgfDxicj4NCiZndDsgfDMuIEEgY29tcGxldGVzIElDRSB3aXRoIEMgYW5kIGV4cGVjdHMgdG8g Y29udGludWUgdGhlIERUTFMgY29ubmVjdGlvbjxicj4NCiZndDsgfG92ZXIgdGhlIG5ld2x5IGRp c2NvdmVyZWQgNS10dXBsZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBc3N1bWluZyB0aGlzIGlzIGEg cmVndWxhciBJQ0UgcmVzdGFydCwgdGhlIFNUVU4gYmluZGluZyByZXF1ZXN0cyBzZW50IGFzIHBh cnQgb2YgdGhlIElDRSBjb25uZWN0aXZpdHkgY2hlY2tzIGZyb20gQSB0byBDIHdvdWxkIGhhdmUg cmFuZG9tbHkgZ2VuZXJhdGVkIHRyYW5zYWN0aW9uIElEcy4gVW5sZXNzIEIgaXMgb24gdGhlIEEt QyBwYXRoIG9yIGNhbiBndWVzcyB0aG9zZSB0cmFuc2FjdGlvbiBJRHMsIGl0IHdvdWxkbid0IGJl IGFibGUgdG8NCiBnZW5lcmF0ZSBsZWdpdGltYXRlIGJpbmRpbmcgcmVzcG9uc2VzIHRvIGNhdXNl IElDRSB0byBjb25jbHVkZSBiL3cgQSBhbmQgQy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBNdXRodTxi cj4NCiZndDs8YnI+DQomZ3Q7IHwtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsg fEZyb206IHJ0Y3dlYiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm Lm9yZyI+cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWFydGluIFRo b21zb248YnI+DQomZ3Q7IHxTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwMywgMjAxMyA0OjE0IEFN PGJyPg0KJmd0OyB8VG86IE1hZ251cyBXZXN0ZXJsdW5kPGJyPg0KJmd0OyB8Q2M6IEN1bGxlbiBK ZW5uaW5ncyAoZmx1ZmZ5KTsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2Vi QGlldGYub3JnPC9hPjxicj4NCiZndDsgfFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBDb25zZW50IGFs dGVybmF0aXZlPGJyPg0KJmd0OyB8PGJyPg0KJmd0OyB8T24gMjkgTm92ZW1iZXIgMjAxMyAwNTo0 MCwgTWFnbnVzIFdlc3Rlcmx1bmQ8YnI+DQomZ3Q7IHwmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hZ251 cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbSI+bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyB8Jmd0OyBJIGhhdmUgbG9va2VkIGJyaWVmbHkgb24g dGhpcyBhbmQgd29uZGVyIGlmIHRoaXMgaXNuJ3QgdnVsbmVyYWJsZSB0bzxicj4NCiZndDsgfCZn dDsgYWN0aXZlIGF0dGFja3MgZnJvbSBhIGF0dGFja2VyIChBbGljZSkgdGhhdCBsaWtlcyB0byB1 c2UgYSBzZXQgb2YgV2ViUlRDPGJyPg0KJmd0OyB8Jmd0OyBicm93c2VycywgaW5jbHVkaW5nIChC b2IpIHRvIGdlbmVyYXRlIERET1MgdHJhZmZpYyB0b3dhcmRzIHRoZSB0YXJnZXQ8YnI+DQomZ3Q7 IHwmZ3Q7IChDaGFybGllKS48YnI+DQomZ3Q7IHw8YnI+DQomZ3Q7IHxIaSBNYWdudXMsPGJyPg0K Jmd0OyB8PGJyPg0KJmd0OyB8SSB0aGluayB0aGF0IHlvdSBkaWQgbWFuYWdlIHRvIGhpdCBvbiBz b21ldGhpbmcgY3JpdGljYWwgaGVyZS48YnI+DQomZ3Q7IHw8YnI+DQomZ3Q7IHxUaGUgYmFzaWMg c2VjdXJpdHkgcHJpbWl0aXZlIGluIHBsYXkgd2l0aCBJQ0UgY29uc2VudCBpcyBwcm9vZiBvZjxi cj4NCiZndDsgfHJlY2VpcHQuICZuYnNwO1RoYXQgaXMgdGhlIGtleSBwaWVjZSBhdCBwbGF5IGhl cmUgYXMgd2VsbC4gJm5ic3A7V2UgcmVxdWlyZTxicj4NCiZndDsgfHByb29mIG9mIHJlY2VpcHQg c2ltcGx5IGJlY2F1c2UgdGhhdCBlbGV2YXRlcyB0aGUgcmVxdWlyZW1lbnRzIGZvciBhbjxicj4N CiZndDsgfGF0dGFja2VyIHRvIHRoZSBwb2ludCB0aGF0IHRoZXkgaGF2ZSB0byBiYXNpY2FsbHkg YmUgb24tcGF0aC4gJm5ic3A7QXQgdGhhdDxicj4NCiZndDsgfHBvaW50LCB0aGV5IChsaWtlbHkp IGFscmVhZHkgaGF2ZSB0aGUgYWJpbGl0eSB0byBnZW5lcmF0ZSB0cmFmZmljPGJyPg0KJmd0OyB8 dG93YXJkIGEgdmljdGltIG9mIGFuIGVxdWFsIChvciBtYXliZSBncmVhdGVyKSB2b2x1bWUgdG8g dGhlIHNlbmRlcjxicj4NCiZndDsgfGFuZCBnYWluIGxpdHRsZSBieSBtb3VudGluZyB0aGUgYXR0 YWNrLjxicj4NCiZndDsgfDxicj4NCiZndDsgfFRoYXQncyB3aHkgSSdtIG5vdCBwYXJ0aWN1bGFy bHkgaW50ZXJlc3RlZCBpbiB0aGUgcGFydCB3aGVyZSB5b3UgdGFsazxicj4NCiZndDsgfGFib3V0 IGF0dGFja2VycyBpbnRlcmNlcHRpbmcgYmluZGluZyByZXF1ZXN0cy48YnI+DQomZ3Q7IHw8YnI+ DQomZ3Q7IHxUaGUgYWN0dWFsIGF0dGFjayB0aGF0IHlvdSBoYXZlIGhpdCB1cG9uIChvciBjYXVz ZWQgbWUgdG8gdGhpbmsgYWJvdXQpPGJyPg0KJmd0OyB8aXMgbm90IHF1aXRlIGFzIHlvdSBkZXNj cmliZWQsIGJ1dCBpdCBkb2VzIHJlbHkgb24gdGhlIGZhY3QgdGhhdCB0aGU8YnI+DQomZ3Q7IHxw cm9wb3NlZCBjaGFuZ2UgdG8gdGhlIGNvbnNlbnQgbWVjaGFuaXNtIG5vIGxvbmdlciBhY3RpdmVs eSBkZXBlbmRzIG9uPGJyPg0KJmd0OyB8cHJvb2Ygb2YgcmVjZWlwdC48YnI+DQomZ3Q7IHw8YnI+ DQomZ3Q7IHxJdCBhbHNvIHJlbGllcyBvbiB0aGUgcG9zc2liaWxpdHkgdGhhdCBhIERUTFMgY29u bmVjdGlvbiBjYW4gYmUgbW92ZWQ8YnI+DQomZ3Q7IHx3aXRob3V0IHJlcXVpcmluZyBwcm9vZiBv ZiByZWNlaXB0IG9uIHRoZSBuZXcgcGF0aC4gJm5ic3A7VGhhdCwgdG8gbWUsIGlzPGJyPg0KJmd0 OyB8dGhlIGZ1bmRhbWVudGFsIHByb2JsZW0gdG8gYmUgc29sdmVkLiAmbmJzcDtGcm9tIG15IHJl cmVhZCBvZiBSRkMgNjM0NywgaXQ8YnI+DQomZ3Q7IHxhcHBlYXJzIGFzIHRob3VnaCB0aGUgb25s eSBjb25zaWRlcmF0aW9uIGdpdmVuIHRvIERvUyB3YXMgYXQgdGhlPGJyPg0KJmd0OyB8aGFuZHNo YWtlLiAmbmJzcDtPbmNlIHNvbWV0aGluZyBsaWtlIElDRSBpcyBpbiBwbGF5IChhbmQgTUlDRSBt YWtlcyB0aGlzPGJyPg0KJmd0OyB8d29yc2UpLCB0aGUgYWJpbGl0eSB0byAmcXVvdDttb3ZlJnF1 b3Q7IHRoZSBjb25uZWN0aW9uIHByZXNlbnRzIGFuIGF0dGFja2VyIHdpdGg8YnI+DQomZ3Q7IHxh biBvcHBvcnR1bml0eS4gJm5ic3A7KEkgaGF2ZSB0byBwb2ludCBvdXQgdGhhdCB0aGlzIGFsc28g Y29uZmlybXMgbXkgZmVhcnM8YnI+DQomZ3Q7IHxhYm91dCB0aGUgbWVjaGFuaXNtIHVzZWQgdG8g c2lnbmFsIElDRSByZXN0YXJ0cywgYnV0IEknbGwgZ2V0IGJhY2sgdG88YnI+DQomZ3Q7IHx0aGF0 Lik8YnI+DQomZ3Q7IHw8YnI+DQomZ3Q7IHxIZXJlIGlzIHRoZSBhdHRhY2sgYXMgSSB1bmRlcnN0 YW5kIGl0Ojxicj4NCiZndDsgfDxicj4NCiZndDsgfDEuIEEgdGFsa3MgdG8gQiwgZXN0YWJsaXNo aW5nIGEgRFRMUyBjb25uZWN0aW9uIHVzaW5nIElDRS4gJm5ic3A7VGhlcmUgaXM8YnI+DQomZ3Q7 IHxubyBuZWVkIGZvciBsb3RzIG9mIGRhdGEgdG8gZmxvdyBhdCB0aGlzIHBvaW50LCB0aGlzIGlz IHRoZSAmcXVvdDt3YXJtLXVwJnF1b3Q7PGJyPg0KJmd0OyB8cGhhc2Ugb2YgdGhlIGF0dGFjay48 YnI+DQomZ3Q7IHw8YnI+DQomZ3Q7IHwyLiBCICh0aGUgYXR0YWNrZXIpIHRyaWdnZXJzIGFuICZx dW90O0lDRSByZXN0YXJ0JnF1b3Q7IHdpdGggQSwgdGhvdWdoIHJlYWxseTxicj4NCiZndDsgfHRo aXMgZ2VuZXJhdGVzIGEgbmV3IElDRSBuZWdvdGlhdGlvbiB3aXRoIGEgdmljdGltLCBDLiAmbmJz cDtDIGNvbnNlbnRzIHRvPGJyPg0KJmd0OyB8dGFsayB0byBCLCBidXQgbm90IG5lY2Vzc2FyaWx5 IHdpdGggQS4gJm5ic3A7VGhpcyBhcnJhbmdlbWVudCBpcyBlYXN5IHRvPGJyPg0KJmd0OyB8YWNo aWV2ZSBvbiB0aGUgZHJpdmUtYnkgd2ViLjxicj4NCiZndDsgfDxicj4NCiZndDsgfDMuIEEgY29t cGxldGVzIElDRSB3aXRoIEMgYW5kIGV4cGVjdHMgdG8gY29udGludWUgdGhlIERUTFMgY29ubmVj dGlvbjxicj4NCiZndDsgfG92ZXIgdGhlIG5ld2x5IGRpc2NvdmVyZWQgNS10dXBsZS4gJm5ic3A7 QyBpcyBjb25mdXNlZCwgYnV0IHJlYWxseSBoYXMgbm88YnI+DQomZ3Q7IHxyZWNvdXJzZSBhdCB0 aGlzIHBvaW50LiAmbmJzcDtFdmVuIGlmIHRoZSBEVExTIGNvbm5lY3Rpb24gZmFpbHMsIEMgaXMg bm93PGJyPg0KJmd0OyB8dGhlIHZpY3RpbSBvbiB0aGUgb3RoZXIgZW5kIG9mIGFuIHVuZW5kaW5n IHN0cmVhbSBvZiBiaXRzLiAmbmJzcDtCIHNwb29mczxicj4NCiZndDsgfHRoZSBzb3VyY2UgYWRk cmVzcyBvZiB0aGUgbmVjZXNzYXJ5IHBhY2tldHMgdG8gY29udGludWUgY29uc2VudCwgQTxicj4N CiZndDsgfGNvbnRpbnVlcyB0byBzZW5kIHRvIEMsIGFuZCBub3RoaW5nIHRoYXQgQyBkb2VzIGNh biBzdG9wIHRoZSBmbG9vZDxicj4NCiZndDsgfGJlY2F1c2UgdGhleSBkb24ndCBoYXZlIGFjY2Vz cyB0byB0aGUgbWFzdGVyIHNlY3JldCBhbmQgY2Fubm90PGJyPg0KJmd0OyB8dGhlcmVmb3JlIHBy b2R1Y2UgYW4gYXV0aGVudGljYXRlZCBwYWNrZXQgdGhhdCB0ZXJtaW5hdGVzIHRoZTxicj4NCiZn dDsgfGNvbm5lY3Rpb24uICZuYnNwO0IgY2FuIGNvbnRpbnVlIHRoZSBhdHRhY2sgYXMgbG9uZyBh cyBBIGlzIHdpbGxpbmcsIGF0IHRoZTxicj4NCiZndDsgfGJhcmdhaW4tYmFzZW1lbnQgcHJpY2Ug b2YgYSAoc3Bvb2ZlZCkgRFRMUyBoZWFydGJlYXQgcmVzcG9uc2UgZXZlcnk8YnI+DQomZ3Q7IHwx MC0yMCBzZWNvbmRzLjxicj4NCiZndDsgfDxicj4NCiZndDsgfFRoZSBrZXkgaGVyZSBpcyB0aGUg bGFjayBvZiBhIHByb29mIG9mIHJlY2VpcHQgZnJvbSBBIHRvd2FyZCBDIGZvciB0aGU8YnI+DQom Z3Q7IHxEVExTIGNvbm5lY3Rpb24gdGhhdCBpcyBtb3ZlZC4gJm5ic3A7VGhlcmUgaXMgbm90aGlu ZyBpbmhlcmVudCB0byBEVExTIHRoYXQ8YnI+DQomZ3Q7IHxwcm92aWRlcyBwcm9vZiB0aGF0IEMg cmVjZWl2ZWQgZGF0YSBmcm9tIEEgYW5kIGlzIGFsc28gd2lsbGluZyB0bzxicj4NCiZndDsgfGNv bnRpbnVlIHRvIGNvbW11bmljYXRlLi4uIEFsbW9zdC48YnI+DQomZ3Q7IHw8YnI+DQomZ3Q7IHxU aGUgRFRMUyBoZWFydGJlYXQgZXh0ZW5zaW9uIGRvZXMgcHJvdmlkZSBzdWNoIGEgdGhpbmc6PGJy Pg0KJmd0OyB8PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjUyMCNwYWdl LTYiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1MjAjcGFnZS02PC9hPjxicj4NCiZn dDsgfDxicj4NCiZndDsgfEFsbCB3ZSBuZWVkIHRvIGRvIHRvIGNsb3NlIHRoaXMgbGl0dGxlIGxv b3Bob2xlIGlzIHRvIHJlcXVpcmUgdGhhdCBhPGJyPg0KJmd0OyB8RFRMUyBoZWFydGJlYXQgcmVx dWVzdCBiZSBzZW50IGFmdGVyIGFueSBjaGFuZ2UgaW4gdW5kZXJseWluZyA1LXR1cGxlLjxicj4N CiZndDsgfCBUaGF0IHJlcXVlc3QgTVVTVCBjb250YWluIHN1ZmZpY2llbnQgZW50cm9weSB0aGF0 IGd1ZXNzaW5nIHdvdWxkIGJlPGJyPg0KJmd0OyB8ZGlmZmljdWx0IGZvciBhbiBvZmYtcGF0aCBh dHRhY2tlcjsgbm90aW5nIHRoYXQgdGhpcyBpcyBhbHNvIGNvdmVyZWQ8YnI+DQomZ3Q7IHxieSBU TFMgcmVjb3JkIGxheWVyIGVuY3J5cHRpb24gYW5kIGF1dGhlbnRpY2F0aW9uLCBsaW1pdGluZyB0 aGUgbnVtYmVyPGJyPg0KJmd0OyB8b2YgcGFydGllcyB0aGF0IGFyZSBldmVuIGFsbG93ZWQgdG8g bWFrZSBhIGd1ZXNzLiAmbmJzcDtJJ20gYSBiaWcgZmFuIG9mPGJyPg0KJmd0OyB8MTI4IGJpdHMs IGJ1dCBsZXNzIGlzIGFsbW9zdCBjZXJ0YWlubHkgT0suICZuYnNwO0lmIG5vIHJlc3BvbnNlIGlz IHJlY2VpdmVkPGJyPg0KJmd0OyB8d2l0aGluIE4gc2Vjb25kcywgY29uc2VudCBpcyBleHBpcmVk LiAmbmJzcDtUaGUgYmFzaWMgY29uc2VudCB0aW1lciBzZWVtczxicj4NCiZndDsgfGFwcHJvcHJp YXRlIGhlcmUsIGkuZS4sIE49MzAuPGJyPg0KJmd0OyB8PGJyPg0KJmd0OyB8RFRMUyByZW5lZ290 aWF0aW9uIHdvdWxkIGFsc28gd29yaywgYnV0IEkgY29uc2lkZXIgdGhhdCB0byBiZSBhIGxpdHRs ZTxicj4NCiZndDsgfGhlYXZ5d2VpZ2h0LiAmbmJzcDtJJ20gbm90IHN1cmUgdGhhdCBpdCdzIHRo YXQgd2lkZWx5IGltcGxlbWVudGVkIGVpdGhlci48YnI+DQomZ3Q7IHxfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgfHJ0Y3dlYiBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7IHw8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJA aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyB8PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_E721D8C6A2E1544DB2DEBC313AF54DE22437073Axmbrcdx02ciscoc_-- From derhoermi@gmx.net Tue Dec 3 05:15:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE61B1AE151 for ; Tue, 3 Dec 2013 05:15:51 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 C3WGXwLpe9NR for ; Tue, 3 Dec 2013 05:15:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id D037A1AE135 for ; Tue, 3 Dec 2013 05:15:49 -0800 (PST) Received: from netb.Speedport_W_700V ([84.180.232.48]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MbbWD-1W3zfQ28Pd-00J3cQ for ; Tue, 03 Dec 2013 14:15:46 +0100 From: Bjoern Hoehrmann To: cowwoc Date: Tue, 03 Dec 2013 14:15:46 +0100 Message-ID: References: <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <529CEAA6.9000501@librevideo.org> <529D4617.6060909@bbs.darktech.org> In-Reply-To: <529D4617.6060909@bbs.darktech.org> 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:UgFqvjKjNX0no6nn5hU2TlYagb8eVJQaBTNP2Zzws3B4SEOYTTG hiLKcDd1PYwfFyEf8PPBL4PTIpOzGkhUc6DEzLw9z+P56bqvQlHnpTEkqlQTLuYlVul7xy2 AdOS3DVnolaMs8L5Pn0QynQMqEp43PvOU4w1Ro7czJiAXn510aydRgR8znHsqh3rHgdtKiN W6xXGbUafmshAg9hI/VqA== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 13:15:51 -0000 * cowwoc wrote: >I'd like to point you to http://www.netindex.com/upload/allcountries/ >for two reasons: > > 1. It states that Germany has an average upload rate of 3.13Mbps. > 2. It shows that upload speeds are increasing over time. That seems extremely unlikely to me, basic offerings like Vodafone's "DSL 6000" come with around 640 kbps upstream, Telekom's "Call & Surf Basic" comes with "up to 1 mbps", where I am right now the best DSL available has less than 384 kbps *downstream*; that does not add up to a situation where the median household has 3 mbps without extra- ordinary evidence ("average" over ones that care to test can naturally be expected to be much higher than the median over the population.) >H.261 is meant as a fallback only in the case that the market cannot >agree to upgrade to VP8 or H.264 at runtime. If a sizable portion of the >market cannot agree at runtime, what makes you believe that that same >sizable portion can agree on a MTI codec? And a final question, in case >you disagree with everything I've written so far: How do you advocate we >proceed in light of the fact that we already tried to (and failed) to >reach consensus around VP8 and H.264? If I were to believe VP8 and H.264 are not royality-free options that can be used in Free implementations of the protocol then the mandatory- to-implement codec is likely their only option to communicate with commercial implementations. If the only option is "not good enough", I might prefer the Working Group say so instead of offering a fig leaf. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From cvitek@webrtcstrategies.com Tue Dec 3 05:31:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9B1AE114 for ; Tue, 3 Dec 2013 05:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URI_NOVOWEL=0.5] 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 5Eb4hJl1lVgo for ; Tue, 3 Dec 2013 05:31:26 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2588C1AE107 for ; Tue, 3 Dec 2013 05:31:26 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id k4so5585802qaq.4 for ; Tue, 03 Dec 2013 05:31:23 -0800 (PST) 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=87VckscKWM+Bfi0qdfGCBft4/eEFgv7ovCIAwzBQzvM=; b=fAPTW22u+wqkTT/f9Ps5kn2A9M4//U9rgMTpMfK1k238Rr7zmPP2/0cMM72+8m5eJK hayPm7zlWkxSGt018MTve+P2CskvMoENUpZpjbqkNmT0x/DplRV2zgRFrnvSIGtxjZl2 W5OtuGBw38+lhhxqpdfJyT4xqEUjSW9rznFU/ANAuqyON89DO/QgsV+Dzb8mNEzABcpX ZolgHfhZ+sIYT2RKYZOed5L4cMG8zJFWxPrpQgaLcd8UHfkE2IP2HFb+IFYco7gZbUZj ho5MUkqXVRpCWIkkf55bkraCNMVNlCjKVeWRJIc5vDhWbqtQWonZwPLcHYXfHmntLLGd bXNg== X-Gm-Message-State: ALoCoQlrJTjLbpPzRAQ4qMQlRLDsmHoZc86RDyS3M0emB92a2FbipcKXX8T0A66rq5HTxl/ccF+A MIME-Version: 1.0 X-Received: by 10.224.73.200 with SMTP id r8mr124318260qaj.72.1386077483057; Tue, 03 Dec 2013 05:31:23 -0800 (PST) Received: by 10.96.114.229 with HTTP; Tue, 3 Dec 2013 05:31:23 -0800 (PST) Date: Tue, 3 Dec 2013 08:31:23 -0500 Message-ID: From: Chris Vitek To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=001a11c3e42002ed1c04eca1507f Subject: [rtcweb] Video Codec MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 13:33:12 -0000 --001a11c3e42002ed1c04eca1507f Content-Type: text/plain; charset=ISO-8859-1 Please conduct a vote to determine the MTI status of the video codecs in WebRTC. -- Regards' Chris Vitek President WebRTC Strategies, Inc. 410-456-3511 *www.WebRTCStrategies.com * *Board Member, Society of Telecommunication Consultants* SWPP Member, Society of Workforce Planning Professional Editor: www.stcblog.com *www.chrisvitek.com * --001a11c3e42002ed1c04eca1507f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please conduct a vote to determine the MTI status of the v= ideo codecs in WebRTC.

--
Regards'

Chris Vitek
President
WebR= TC Strategies, Inc.
410-456-3511


Board Member, Society of Telecommunication Consultants
<= span style=3D"font-family:garamond,serif">SWPP=A0Member, Society of Workfor= ce Planning Professional
Editor:=A0www.stcblog.com
--001a11c3e42002ed1c04eca1507f-- From mail@makk.es Tue Dec 3 05:36:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066181AE13B for ; Tue, 3 Dec 2013 05:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 wQcmeBEbN9Ge for ; Tue, 3 Dec 2013 05:35:58 -0800 (PST) Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id E42551AE114 for ; Tue, 3 Dec 2013 05:35:57 -0800 (PST) Received: (qmail 4956 invoked from network); 3 Dec 2013 13:35:53 -0000 Received: from unknown (HELO ?141.22.28.156?) (141.22.28.156) by lupus.uberspace.de with SMTP; 3 Dec 2013 13:35:53 -0000 Message-ID: <529DDE37.6020202@makk.es> Date: Tue, 03 Dec 2013 14:35:51 +0100 From: Max Jonas Werner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: cowwoc , rtcweb@ietf.org References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <529CEAA6.9000501@librevideo.org> <529D4617.6060909@bbs.darktech.org> In-Reply-To: <529D4617.6060909@bbs.darktech.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XdpLDbf8N8GCFq72msetti7nobWPxNRHh" Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 13:36:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XdpLDbf8N8GCFq72msetti7nobWPxNRHh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03.12.2013 03:46, cowwoc wrote: [...] > Bjoern, >=20 > I'd like to point you to http://www.netindex.com/upload/allcountries/=20 > for two reasons: >=20 > 1. It states that Germany has an average upload rate of 3.13Mbps. This statement does not say anything about the upload rate of the majority of users. > 2. It shows that upload speeds are increasing over time. Probably, but they are still extremely low in comparison to the downstream rate. /max --XdpLDbf8N8GCFq72msetti7nobWPxNRHh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFSnd431IVn4/X13N8RAu/kAJwOt7I30R2MZ2VBnvsR4GCv1QQ8XACgi/MT jt0kAvh2WOvMPuae7wF7wEQ= =7oh9 -----END PGP SIGNATURE----- --XdpLDbf8N8GCFq72msetti7nobWPxNRHh-- From john@jlc.net Tue Dec 3 06:16:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98021AD694 for ; Tue, 3 Dec 2013 06:16:28 -0800 (PST) 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, RP_MATCHES_RCVD=-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 kyja9EVJlRfO for ; Tue, 3 Dec 2013 06:16:27 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BC4F01ADFFA for ; Tue, 3 Dec 2013 06:16:19 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id A03ADC94A9; Tue, 3 Dec 2013 09:16:14 -0500 (EST) Date: Tue, 3 Dec 2013 09:16:14 -0500 From: John Leslie To: Bjoern Hoehrmann Message-ID: <20131203141614.GJ87911@verdi> References: <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <529CEAA6.9000501@librevideo.org> <529D4617.6060909@bbs.darktech.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 14:16:29 -0000 Bjoern Hoehrmann wrote: > * cowwoc wrote: > >> H.261 is meant as a fallback only in the case that the market cannot >> agree to upgrade to VP8 or H.264 at runtime. If a sizable portion of the >> market cannot agree at runtime, what makes you believe that that same >> sizable portion can agree on a MTI codec? And a final question, in case >> you disagree with everything I've written so far: How do you advocate we >> proceed in light of the fact that we already tried to (and failed) to >> reach consensus around VP8 and H.264? > > If I were to believe VP8 and H.264 are not royality-free options that > can be used in Free implementations of the protocol then the mandatory- > to-implement codec is likely their only option to communicate with > commercial implementations. We have strong evidence that implementors believe there is significant IPR risk in either of these. That is what matters -- not whether someone else thinks they're "royalty-free". > If the only option is "not good enough", I might prefer the Working Group > say so instead of offering a fig leaf. 1: There's always more than one option. If folks think H.261 is as bad as you think it, transcoding services will arise, and I expect most folks that care about video quality to find browsers which support VP8 _and_ H.264; 2: Any codec will be "good enough" for some uses, and not for others; 3: Nothing prevents the Working Group from adding language about the limitations of H.261; 4: This is not about "offering a fig leaf" -- it's about preventing negotiation failure until the market can settle on some better way: I remind you that codecs better than VP8 and H.264 are already starting to see use; 5: Whatever _you_ might prefer, there are others who would prefer to get this specification out the door and widely implemented. -- John Leslie From cowwoc@bbs.darktech.org Tue Dec 3 07:57:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0F01AE154 for ; Tue, 3 Dec 2013 07:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyZHHwvZb_al for ; Tue, 3 Dec 2013 07:57:33 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 989D51AE05B for ; Tue, 3 Dec 2013 07:57:30 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id tp5so24092749ieb.11 for ; Tue, 03 Dec 2013 07:57:27 -0800 (PST) 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; bh=Cnq0gLi5Nse9ScJf+63f/LKL027b3+mzQ+sIWTyuxis=; b=bJixv+BuXVDWVyZsXDwbfkZHV7V56VrfXONXbkrs9jH4CEoEoUxzMq8lb6EbZqhD5q ROKw1eZd1VbkzGq/FVdkxjLdteA5hg1tvO0GdhyQlBv3CZTlyiF73Itr9wsXUMcQGoqg NaQ3P18hmNMSLBpN+7TmWfpZBRiHXUcJrjy3C2Aw8nyM5ntqJIMWldo6uO8RJGb7LzUe 19H9hcLoXByBqijGJOiAzpslh35RmzzUMbb263+X8PLXGj79SgbUHepNr112JuLOLNvR zhUAwH4KtscT/tTnLx/92i0ZMqY7kS5fSx4NXtVLek0uj2GYbGsGQVrxshv6UmpBrtI8 CH2A== X-Gm-Message-State: ALoCoQnSd/WTJgZ2kCtkLae58hIO9zW/gQY3MafGwNuCEjf/9cJUoMo5vOlCtDUhgUomJHcft+ho X-Received: by 10.50.87.33 with SMTP id u1mr3262283igz.42.1386086247734; Tue, 03 Dec 2013 07:57:27 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id qi3sm3668172igc.8.2013.12.03.07.57.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 07:57:26 -0800 (PST) Message-ID: <529DFF63.4000105@bbs.darktech.org> Date: Tue, 03 Dec 2013 10:57:23 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <529CEAA6.9000501@librevideo.org> <529D4617.6060909@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040001000109010903060409" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 15:57:35 -0000 This is a multi-part message in MIME format. --------------040001000109010903060409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/12/2013 8:15 AM, Bjoern Hoehrmann wrote: > * cowwoc wrote: >> I'd like to point you to http://www.netindex.com/upload/allcountries/ >> for two reasons: >> >> 1. It states that Germany has an average upload rate of 3.13Mbps. >> 2. It shows that upload speeds are increasing over time. > That seems extremely unlikely to me, basic offerings like Vodafone's > "DSL 6000" come with around 640 kbps upstream, Telekom's "Call & Surf > Basic" comes with "up to 1 mbps", where I am right now the best DSL > available has less than 384 kbps *downstream*; that does not add up > to a situation where the median household has 3 mbps without extra- > ordinary evidence ("average" over ones that care to test can naturally > be expected to be much higher than the median over the population.) > >> H.261 is meant as a fallback only in the case that the market cannot >> agree to upgrade to VP8 or H.264 at runtime. If a sizable portion of the >> market cannot agree at runtime, what makes you believe that that same >> sizable portion can agree on a MTI codec? And a final question, in case >> you disagree with everything I've written so far: How do you advocate we >> proceed in light of the fact that we already tried to (and failed) to >> reach consensus around VP8 and H.264? > If I were to believe VP8 and H.264 are not royality-free options that > can be used in Free implementations of the protocol then the mandatory- > to-implement codec is likely their only option to communicate with > commercial implementations. If the only option is "not good enough", I > might prefer the Working Group say so instead of offering a fig leaf. Bjoern, I don't understand. What is the practical benefit of declaring "No MTI" (as you seem to be implying) over considering H.261 as MTI? 1. What you could accomplish with with "No MTI" you could accomplish with H.261 as MTI (and more). 2. What might not be good enough for one business/use-case will be for another. Why penalize all use-cases? 3. What might not be good enough in Germany (today) might be good enough in North America and Asia. Why penalize the rest of the world? Things *will* improve in Germany (supply will follow demand). Up until recently, Canada was stuck with 1MBps upload rates for over a decade. Out of nowhere we started getting upload rates of 10MBps, 20MBps and even 50MBps. The technology is there. The only thing holding it back are politics (monopolies in our case) and demand. Gili --------------040001000109010903060409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/12/2013 8:15 AM, Bjoern Hoehrmann wrote:
* cowwoc wrote:

I'd like to point you to http://www.netindex.com/upload/allcountries/ 
for two reasons:

1. It states that Germany has an average upload rate of 3.13Mbps.
2. It shows that upload speeds are increasing over time.

That seems extremely unlikely to me, basic offerings like Vodafone's
"DSL 6000" come with around 640 kbps upstream, Telekom's "Call & Surf
Basic" comes with "up to 1 mbps", where I am right now the best DSL
available has less than 384 kbps *downstream*; that does not add up
to a situation where the median household has 3 mbps without extra-
ordinary evidence ("average" over ones that care to test can naturally
be expected to be much higher than the median over the population.)


H.261 is meant as a fallback only in the case that the market cannot 
agree to upgrade to VP8 or H.264 at runtime. If a sizable portion of the 
market cannot agree at runtime, what makes you believe that that same 
sizable portion can agree on a MTI codec? And a final question, in case 
you disagree with everything I've written so far: How do you advocate we 
proceed in light of the fact that we already tried to (and failed) to 
reach consensus around VP8 and H.264?

If I were to believe VP8 and H.264 are not royality-free options that
can be used in Free implementations of the protocol then the mandatory-
to-implement codec is likely their only option to communicate with
commercial implementations. If the only option is "not good enough", I
might prefer the Working Group say so instead of offering a fig leaf.
Bjoern,

I don't understand. What is the practical benefit of declaring "No MTI" (as you seem to be implying) over considering H.261 as MTI?
  1. What you could accomplish with with "No MTI" you could accomplish with H.261 as MTI (and more).
  2. What might not be good enough for one business/use-case will be for another. Why penalize all use-cases?
  3. What might not be good enough in Germany (today) might be good enough in North America and Asia. Why penalize the rest of the world?

Things *will* improve in Germany (supply will follow demand). Up until recently, Canada was stuck with 1MBps upload rates for over a decade. Out of nowhere we started getting upload rates of 10MBps, 20MBps and even 50MBps. The technology is there. The only thing holding it back are politics (monopolies in our case) and demand.

Gili
--------------040001000109010903060409-- From cowwoc@bbs.darktech.org Tue Dec 3 07:57:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A941A1F4C for ; Tue, 3 Dec 2013 07:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOGguY8eKcJp for ; Tue, 3 Dec 2013 07:57:35 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id B4BF41AE15C for ; Tue, 3 Dec 2013 07:57:32 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id tp5so24092855ieb.11 for ; Tue, 03 Dec 2013 07:57:30 -0800 (PST) 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=o9qiNvXUqEjcCfFnjqPimrB4/0UqGDK1tOUv3u6ktNE=; b=aaTK404d6hK3dq6jMHUvD7dnJWq0C4ypptXZ46x+e8LLW5MpwPlEzAc9QwvFfpSWZi nf6+NFeIwsszSMchudNE07v/0jRVhU+VrLkWUShM2WKE42SxDzGPVfwBQ920iq+/I3KP AoLlQJMz22ZYXPntN3p2Sz1a1eTWSqkjLsp/a96sRKS5YllbYmLEHm1Qy/NGsKKuGR/X qSAD2YeSFGLXJUocWS4HkfA7x64J8AIFof+riFJ7DGK4E5sojfqWxWozfxndC5qwP7HV 9dN/XC49qtTacaZ1dSypn3bBpFiG4PmVYDvlPZ/4iQneJ8dp+RUJkANlL3kQsdfoGkF4 U/SQ== X-Gm-Message-State: ALoCoQlpy2e/H8QDVHwF9o3OGN34x8lgPy3lJvlyNM3KHoEszE9sSR/hz+Z6C5j3eJ0t5Ry9+H0k X-Received: by 10.42.42.132 with SMTP id t4mr235735ice.90.1386086249087; Tue, 03 Dec 2013 07:57:29 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id v2sm3701277igz.3.2013.12.03.07.57.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 07:57:28 -0800 (PST) Message-ID: <529DFF66.4080308@bbs.darktech.org> Date: Tue, 03 Dec 2013 10:57:26 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Max Jonas Werner , rtcweb@ietf.org References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <529CEAA6.9000501@librevideo.org> <529D4617.6060909@bbs.darktech.org> <529DDE37.6020202@makk.es> In-Reply-To: <529DDE37.6020202@makk.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 15:57:37 -0000 On 03/12/2013 8:35 AM, Max Jonas Werner wrote: > On 03.12.2013 03:46, cowwoc wrote: > [...] >> Bjoern, >> >> I'd like to point you to http://www.netindex.com/upload/allcountries/ >> for two reasons: >> >> 1. It states that Germany has an average upload rate of 3.13Mbps. > This statement does not say anything about the upload rate of the > majority of users. The source data is here: http://www.netindex.com/source-data/ It should be possible to calculate the median from there. >> 2. It shows that upload speeds are increasing over time. > Probably, but they are still extremely low in comparison to the > downstream rate. Why does that matter? Thanks, Gili From dhc@dcrocker.net Mon Dec 2 11:41:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B730D1ADBCD for ; Mon, 2 Dec 2013 11:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 D6ClMkP63ap2 for ; Mon, 2 Dec 2013 11:41:34 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A49361AD72A for ; Mon, 2 Dec 2013 11:41:34 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rB2JfS6m018318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Dec 2013 11:41:31 -0800 Message-ID: <529CE233.5000002@dcrocker.net> Date: Mon, 02 Dec 2013 11:40:35 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Roberto Peon References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <949EF20990823C4C85C18D59AA11AD8B0EF1B8@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 02 Dec 2013 11:41:31 -0800 (PST) X-Mailman-Approved-At: Tue, 03 Dec 2013 08:35:01 -0800 Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-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, 02 Dec 2013 19:41:35 -0000 On 11/29/2013 12:22 AM, Roberto Peon wrote: > The only reason to specify a must-implement is to increase interop; if > mandating a codec does not increase the amount of interop, why do it? If the base specification does not provide enough information for basic interoperability, what is the benefit in standardizing it? An alternative that I believe has already been mentioned is to standardize /both/, but separately. Under two different names, which then lets the market decide on whether either will succeed. Letting the market decide amongst competing choices used to be something the IETF did more commonly. One of the more colorful examples was SNMP vs. CMOT. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hallam@gmail.com Mon Dec 2 12:12:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FF01AD845; Mon, 2 Dec 2013 12:12:39 -0800 (PST) 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 QqPFepJjq4Mo; Mon, 2 Dec 2013 12:12:37 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C40A31ADBFF; Mon, 2 Dec 2013 12:12:36 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id t61so6739607wes.25 for ; Mon, 02 Dec 2013 12:12:34 -0800 (PST) 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=jimGY7k98L6kiDgFU7p4ePE7mjatZTMVGgssKUValnc=; b=F2dVx8KkcRdjStKDF7l7MQYKg3derRk2gqTWu6UAvoljWnX8HyjlK2UVUQ5io5hme0 V0AUNXdYmNEjuiMKhPntEygS1Aw/kHfQcEOVoTzcscmNINCQV/GsXk4s/eGwl4rWkjkf EaorDZkIvVvk0lTHKHUuD/1v9nRn3fIjqQ9Uskb2dEcgHVAgWgelkDNeYTg3E9ogbtti gbFelysCxdKToZnZ5gdUxk/CbNFkEYwztkcaUxCXIjMepkyzal+cNVODlki68pjvTqC9 cmV8eRi8OhMDGKfLO/FFg3t6Ug0GN24ljEtMhNOjv6l88Wrk+88fQIkOKcx8DH8K4DKC yytw== MIME-Version: 1.0 X-Received: by 10.180.189.80 with SMTP id gg16mr19721244wic.32.1386015153919; Mon, 02 Dec 2013 12:12:33 -0800 (PST) Received: by 10.194.243.136 with HTTP; Mon, 2 Dec 2013 12:12:33 -0800 (PST) In-Reply-To: <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> Date: Mon, 2 Dec 2013 15:12:33 -0500 Message-ID: From: Phillip Hallam-Baker To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=001a11c22314e71c8b04ec92ccb5 X-Mailman-Approved-At: Tue, 03 Dec 2013 08:35:01 -0800 Cc: "rtcweb@ietf.org" , IETF Discussion Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 20:12:39 -0000 --001a11c22314e71c8b04ec92ccb5 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 2, 2013 at 2:27 PM, Bjoern Hoehrmann wrote: > * Ron wrote: > > 2. Can anybody show a sustainable objection for why we _can't_ use H.261. > > > > If they can, we're probably doomed. If they can't we have an initial > > choice for MTI. > > I have not seen a convincing argument that H.261 performs well enough to > permit real-time video communication at reasonable quality and bitrates. > That is irrelevant. MTI does not need to be a good choice, it merely needs to achieve interoperability. If someone can support HD video over a 300 BAUD connection, the technology is almost certain to be proprietary. That does not mean that the IETF has to accept the proprietary technology as MTI because it is the only one that supports the needs of 300 BAUD users, it means that that group of users may not be supported by the MTI CODEC. MPEG2 will come out of patent in the nearish future and it is a not terrible choice. It is certainly not the best choice but it isn't a horrible one. > I have not seen recent statistics for Germany but I suspect it is common > that household members share a line with an upstream of around 640 kbps, > that would basically allow for two 320x240 H.264 CBP + Audio streams at > 30 fps in good quality. Would H.261 permit at least one stream at the > same quality? If not, then nobody would use H.261-only WebRTC products, > and people are not going to appreciate if a VP8 product connecting with > a H.264 product falls back to H.261 to avoid negotiation failure. People would use H.261 if that is all the clients at either end supported. The value of the H.264 patent pool would be reduced from the ability to perform the application to a quality issue for some subset (a clear minority) of the user base. We knew that there were real security and performance problems with 3DES when we made it MTI in TLS 1.0 but that was the best choice available at the time. If there was an optimal technical choice that had no other consideration there would be no need for MTI clauses at all. -- Website: http://hallambaker.com/ --001a11c22314e71c8b04ec92ccb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 2, 2013 at 2:27 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
* Ron wrote:
> 2. Can anybody show a sustainable objection for why we _can't_ use= H.261.
>
> =A0 If they can, we're probably doomed. =A0If they can't we ha= ve an initial
> =A0 choice for MTI.

I have not seen a convincing argument that H.261 performs well enough= to
permit real-time video communication at reasonable quality and bitrates.

That is irrelevant.

<= div>MTI does not need to be a good choice, it merely needs to achieve inter= operability.

If someone can support HD video over a 300 BAUD connect= ion, the technology is almost certain to be proprietary. That does not mean= that the IETF has to accept the proprietary technology as MTI because it i= s the only one that supports the needs of 300 BAUD users, it means that tha= t group of users may not be supported by the MTI CODEC.


MPEG2 will come out of patent in the nea= rish future and it is a not terrible choice. It is certainly not the best c= hoice but it isn't a horrible one.

=A0
I have not seen recent statistics for Germany but I suspect it is common that household members share a line with an upstream of around 640 kbps, that would basically allow for two 320x240 H.264 CBP + Audio streams at
30 fps in good quality. Would H.261 permit at least one stream at the
same quality? If not, then nobody would use H.261-only WebRTC products,
and people are not going to appreciate if a VP8 product connecting with
a H.264 product falls back to H.261 to avoid negotiation failure.

People would use H.261 if that is all the c= lients at either end supported. The value of the H.264 patent pool would be= reduced from the ability to perform the application to a quality issue for= some subset (a clear minority) of the user base.

We knew that there were real security and performance p= roblems with 3DES when we made it MTI in TLS 1.0 but that was the best choi= ce available at the time.


If there = was an optimal technical choice that had no other consideration there would= be no need for MTI clauses at all.


--
Website: http://hallambaker.com/
--001a11c22314e71c8b04ec92ccb5-- From hartmans@mit.edu Mon Dec 2 14:11:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6156E1ADF95; Mon, 2 Dec 2013 14:11:35 -0800 (PST) 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, 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 8hMrTdyOnAgQ; Mon, 2 Dec 2013 14:11:31 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 239511ADF10; Mon, 2 Dec 2013 14:11:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 46652205C4; Mon, 2 Dec 2013 17:10:37 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8RT4oeHOBDb; Mon, 2 Dec 2013 17:10:36 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 2 Dec 2013 17:10:36 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4E34F8375A; Mon, 2 Dec 2013 17:11:27 -0500 (EST) From: Sam Hartman To: Ron References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> Date: Mon, 02 Dec 2013 17:11:27 -0500 In-Reply-To: <20131129060936.GV3245@audi.shelbyville.oz> (ron@debian.org's message of "Fri, 29 Nov 2013 16:39:36 +1030") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 03 Dec 2013 08:35:01 -0800 Cc: IETF Discussion , Michael Richardson , "rtcweb@ietf.org" , Dave CROCKER , Eric Burger , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Dec 2013 22:11:35 -0000 >>>>> "Ron" == Ron writes: Ron> 2. Can anybody show a sustainable objection for why we _can't_ Ron> use H.261. Ron> If they can, we're probably doomed. If they can't we have Ron> an initial choice for MTI. This is a fine approach, but you also need to get consensus that least-objectionable-choice is a good decision mechanism. That doesn't follow directly from we want an MTI codec. If you think you can get consensus behind the process you propose then go for it. However don't skip important steps. From martin.thomson@gmail.com Tue Dec 3 08:55:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEC01AE120 for ; Tue, 3 Dec 2013 08:55:28 -0800 (PST) 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 rLzUEmZy9hTU for ; Tue, 3 Dec 2013 08:55:26 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CC4081A1F74 for ; Tue, 3 Dec 2013 08:55:25 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id z2so5333113wiv.13 for ; Tue, 03 Dec 2013 08:55:22 -0800 (PST) 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=h+8vO/MWFI0v+hh28Hw5OkBM2XJxh68t7jetbw5M8zc=; b=gPKLBzBTpgaB0CdqEDBTEKvhJMU8BRqyqT+XbGEXdVJSDnmxBi64uujZnV7GOs8awZ 2fOjZO+FQhAcDnnNrwM3x8jwutLoTXSR84VgrSqtFbBA1xq/J7w3eb++ZPkSusNkKu6R kvGvl68U/0/4+4kAZbMUdc9wXXQhJCbBBWTSwpOSxir0Vd7GoWitsAz/s9G1w/rYwZ1Z dYMm0o2nR/4dZ3WfbCogN9oBL3dBbWMYj7nWSPPFD938e3G0A6peefCC/V3YaoMfb71/ 4USRVlunRchY7fm4f3fCFhBhi3LFB1XF4GDBXyuTpiH7KcJHKjHI6zIVe7Yacv5UvBIf wgGw== MIME-Version: 1.0 X-Received: by 10.194.232.133 with SMTP id to5mr7890792wjc.41.1386089722757; Tue, 03 Dec 2013 08:55:22 -0800 (PST) Received: by 10.227.134.195 with HTTP; Tue, 3 Dec 2013 08:55:22 -0800 (PST) In-Reply-To: References: <52989933.6000907@ericsson.com> Date: Tue, 3 Dec 2013 08:55:22 -0800 Message-ID: From: Martin Thomson To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 16:55:28 -0000 On 3 December 2013 04:48, Muthu Arul Mozhi Perumal (mperumal) wrote: > That's a typical third party call control (3PCC) use case where B (3PCC) > mangles call signaling + SDP b/w A and C and sets up the media session > between them. The security of ICE (as defined in RFC5245) is rooted in the > ice-ufrag and ice-pwd exchanged in call signaling. If a 3PCC can mangle > them, ICE can't prevent the connectivity check from succeeding. > > > > If it is deemed a problem, it might need an ICE extension to fail the > connectivity check b/w A and C. I think that you have missed the point here. The point is that A and B share a DTLS connection, and B uses ICE to convince A to send packets for that connection to C. All this requires is that B is able to spoof the source address of packets to appear as coming from C. It's got nothing to do with 3PCC scenarios. From roman@telurix.com Tue Dec 3 10:59:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FE31AE17E for ; Tue, 3 Dec 2013 10:59:22 -0800 (PST) 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 twC0z1hnS-EU for ; Tue, 3 Dec 2013 10:59:20 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id EE07F1AC829 for ; Tue, 3 Dec 2013 10:59:19 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id y10so12140404wgg.0 for ; Tue, 03 Dec 2013 10:59:16 -0800 (PST) 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=GrJq/6rwVWcq9SgIOZRLyzcTdMT/iF6+5LBKmlgPh8Q=; b=Rxm046h5nDlBQqXDSSLxieWxDt43iOecW/oAbq3vasM6l4xUzs8Lb9x/UuRU+FGFyw JypwPVFdioMW2P1BGvCnyHy3ik3+KPucAZ+HWlZKFcaWsynsd/khHV0qPXxL4BR06DLp Ave6mm/3T4TBYjve4PK0nFOoOyiIHypNRzEM/YiehsG6n3T85GDpssdvRkpQJdiWV/Ng 8xlZQRn8iUAUeG/WfcdkRUVRjdRbtEBiamLbV7tFQOeiS5wiivI/yjYJxmoYT7ud9xOX 55hsUjGC7cUpEUfdle0lY5tYTAONeztJiykAhEBYlfrrjwjxqAPZp0adWhpGLQ3ER1qg GpxA== X-Gm-Message-State: ALoCoQnNrU91iWRbD5rJvd2VzBzVwaYa+x3DetlOrgFrB/dRyM2risYlaVOYkZFNY9fFSOPis2rJ X-Received: by 10.194.236.199 with SMTP id uw7mr8611571wjc.63.1386097156812; Tue, 03 Dec 2013 10:59:16 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx.google.com with ESMTPSA id y20sm8065581wib.0.2013.12.03.10.59.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 10:59:15 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id en1so7029036wid.3 for ; Tue, 03 Dec 2013 10:59:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.23.201 with SMTP id o9mr3820911wjf.67.1386097155444; Tue, 03 Dec 2013 10:59:15 -0800 (PST) Received: by 10.217.88.133 with HTTP; Tue, 3 Dec 2013 10:59:15 -0800 (PST) In-Reply-To: References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C55D40B@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A2426EF4D@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C55D48D@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A2426F209@xmb-rcd-x10.cisco.com> Date: Tue, 3 Dec 2013 13:59:15 -0500 Message-ID: From: Roman Shpount To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=047d7b3a956c9319dd04eca5e4e7 Cc: "rtcweb@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:59:23 -0000 --047d7b3a956c9319dd04eca5e4e7 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 2, 2013 at 11:47 PM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: > No, there is one difference when the peer is not sending any traffic (e.g > VoD): > For the STUN based mechanism, the peer is required to support only > ICE-lite (or ICE) for the sender to verify consent freshness. With the DTLS > based mechanism, the peer is required to support DTLS Heartbeat (RFC6520) > and respond to HeartbeatRequest messages for the sender to verify consent > freshness. That is asking more from legacy implementations. > > For all practical purposes there are no legacy DTLS-SRTP implementations. In most cases it is a new implementation for WebRTC anyway. _____________ Roman Shpount --047d7b3a956c9319dd04eca5e4e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Mon, Dec 2, 2013 at 11:47 PM, Muthu Arul Mozhi Perumal (mperumal) <mpe= rumal@cisco.com> wrote:
No, there is one differen= ce when the peer is not sending any traffic (e.g VoD):
For the STUN based mechanism, the peer is required to support only ICE-lite= (or ICE) for the sender to verify consent freshness. With the DTLS based m= echanism, the peer is required to support DTLS Heartbeat (RFC6520) and resp= ond to HeartbeatRequest messages for the sender to verify consent freshness= . That is asking more from legacy implementations.


For all practic= al purposes there are no legacy DTLS-SRTP implementations. In most cases it= is a new implementation for WebRTC anyway.
_____________
Roman Shpount

--047d7b3a956c9319dd04eca5e4e7-- From richard@shockey.us Tue Dec 3 12:52:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C6A1AD94A for ; Tue, 3 Dec 2013 12:52:09 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 jxK0I3JIk9dR for ; Tue, 3 Dec 2013 12:52:05 -0800 (PST) Received: from alt-proxy31.mail.unifiedlayer.com (alt-proxy31.mail.unifiedlayer.com [74.220.221.129]) by ietfa.amsl.com (Postfix) with SMTP id A9B171ACCFF for ; Tue, 3 Dec 2013 12:52:05 -0800 (PST) Received: (qmail 25808 invoked by uid 0); 3 Dec 2013 20:51:42 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.mail.unifiedlayer.com with SMTP; 3 Dec 2013 20:51:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=DiAhygKELkZA21cEWgQWn8vm1Q11aJKCAJkfvFSJN7s=; b=pR28+oCQqSpOUZzAhXcCIW7hm9gvuawyQEWvyFl0P16MIwos8pwdebpFNiwzQLNdrMFQXyl3QO/dTUEY/wnjIH35CkD8flM4MD9kxGci7W11QG5q1A8NJIPNawiJPjqe; Received: from [173.79.179.104] (port=57943 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VnwwX-0000zl-LQ; Tue, 03 Dec 2013 13:51:41 -0700 From: "Richard Shockey" To: "'Sam Hartman'" , "'Ron'" References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> In-Reply-To: Date: Tue, 3 Dec 2013 15:51:39 -0500 Message-ID: <01bb01cef069$77beac20$673c0460$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHR9JACN53EOm8O1zG5mQ+qAcMVGQGM/Y9HAgo6cagCK0Pd6QJa37IuAkNDumwC+sQILgE3dk9/AlSb7A0Cp2xBWZmgbzqA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: 'Michael Richardson' , rtcweb@ietf.org, 'Dave CROCKER' , 'Eric Burger' , rtcweb-chairs@tools.ietf.org Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Dec 2013 20:52:10 -0000 Well I think we need to convene the Supreme Court of Protocol Engineering Standards ..aka SCOPES. Use the noncom process to empanel a tribunal of 9 individuals who have never ever subscribed to a RAI list. That might be hard..I admit. We have the briefs... we just need oral arguments. London ... black robes. Or at least black t shirts. Then an impartial verdict can be rendered and we can get on with the rest of our lives. Of course any resemblance to the Scopes trial in Tennessee would be purely coincidental. http://en.wikipedia.org/wiki/Scopes_Trial I want to do the .. "Oyez! Oyez! Oyez! All persons having business before the , of the Supreme Court of Protocol Engineering Standards, are admonished to draw near and give their attention, for the Court is now sitting. IPv6 forever..." -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sam Hartman Sent: Monday, December 02, 2013 5:11 PM To: Ron Cc: IETF Discussion; Michael Richardson; rtcweb@ietf.org; Dave CROCKER; Eric Burger; rtcweb-chairs@tools.ietf.org Subject: Re: [rtcweb] Alternative decision process in RTCWeb >>>>> "Ron" == Ron writes: Ron> 2. Can anybody show a sustainable objection for why we _can't_ Ron> use H.261. Ron> If they can, we're probably doomed. If they can't we have Ron> an initial choice for MTI. This is a fine approach, but you also need to get consensus that least-objectionable-choice is a good decision mechanism. That doesn't follow directly from we want an MTI codec. If you think you can get consensus behind the process you propose then go for it. However don't skip important steps. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Tue Dec 3 16:25:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33071AE1EC for ; Tue, 3 Dec 2013 16:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 NkKNTOp5EKpR for ; Tue, 3 Dec 2013 16:24:58 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB941AE1E8 for ; Tue, 3 Dec 2013 16:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5407; q=dns/txt; s=iport; t=1386116696; x=1387326296; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=jmBO9J5dlcCd6LhO481RL8gBM6pin3uEPdqt1j3wuAc=; b=MPj5jTzcfTHMx8fGd+4cde71eYYYowJw1ayiDLdIalUg2gg7LRQjDkkg s1ycf6JHmottTU84cGx5IRg4DwwZtGitOamwJ2taSmSFwPU2lh63RbPsK VflFn95ZRJw3MepytfGiinKZxZVa3szDcr6i3cK2+Gcc/MgOVA1TjvMAu w=; X-IronPort-AV: E=Sophos;i="4.93,821,1378857600"; d="scan'208";a="96869772" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 04 Dec 2013 00:24:55 +0000 Received: from dhcp-10-155-85-188.cisco.com (dhcp-10-155-85-188.cisco.com [10.155.85.188]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB40O8Wf030795; Wed, 4 Dec 2013 00:24:20 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Tue, 3 Dec 2013 16:24:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <02F053C4-ADD9-40D4-BE58-AD9997CFF390@cisco.com> References: <52989933.6000907@ericsson.com> To: Martin Thomson X-Mailer: Apple Mail (2.1510) Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Dec 2013 00:25:01 -0000 On Dec 2, 2013, at 2:44 PM, Martin Thomson = wrote: > On 29 November 2013 05:40, Magnus Westerlund > wrote: >> I have looked briefly on this and wonder if this isn't vulnerable to >> active attacks from a attacker (Alice) that likes to use a set of = WebRTC >> browsers, including (Bob) to generate DDOS traffic towards the target >> (Charlie). >=20 > Hi Magnus, >=20 > I think that you did manage to hit on something critical here. >=20 > The basic security primitive in play with ICE consent is proof of > receipt. That is the key piece at play here as well. We require > proof of receipt simply because that elevates the requirements for an > attacker to the point that they have to basically be on-path. At that > point, they (likely) already have the ability to generate traffic > toward a victim of an equal (or maybe greater) volume to the sender > and gain little by mounting the attack. >=20 > That's why I'm not particularly interested in the part where you talk > about attackers intercepting binding requests. >=20 > The actual attack that you have hit upon (or caused me to think about) > is not quite as you described, but it does rely on the fact that the > proposed change to the consent mechanism no longer actively depends on > proof of receipt. >=20 > It also relies on the possibility that a DTLS connection can be moved > without requiring proof of receipt on the new path. That, to me, is > the fundamental problem to be solved. =46rom my reread of RFC 6347, = it > appears as though the only consideration given to DoS was at the > handshake. Once something like ICE is in play (and MICE makes this > worse), the ability to "move" the connection presents an attacker with > an opportunity. (I have to point out that this also confirms my fears > about the mechanism used to signal ICE restarts, but I'll get back to > that.) >=20 > Here is the attack as I understand it: >=20 > 1. A talks to B, establishing a DTLS connection using ICE. There is > no need for lots of data to flow at this point, this is the "warm-up" > phase of the attack. >=20 > 2. B (the attacker) triggers an "ICE restart" with A, though really > this generates a new ICE negotiation with a victim, C. C consents to > talk to B, but not necessarily with A. This arrangement is easy to > achieve on the drive-by web. >=20 > 3. A completes ICE with C and expects to continue the DTLS connection > over the newly discovered 5-tuple. C is confused, but really has no > recourse at this point. Even if the DTLS connection fails, C is now > the victim on the other end of an unending stream of bits. B spoofs > the source address of the necessary packets to continue consent, A > continues to send to C, and nothing that C does can stop the flood > because they don't have access to the master secret and cannot > therefore produce an authenticated packet that terminates the > connection. B can continue the attack as long as A is willing, at the > bargain-basement price of a (spoofed) DTLS heartbeat response every > 10-20 seconds. >=20 > The key here is the lack of a proof of receipt from A toward C for the > DTLS connection that is moved. There is nothing inherent to DTLS that > provides proof that C received data from A and is also willing to > continue to communicate... Almost. >=20 > The DTLS heartbeat extension does provide such a thing: > http://tools.ietf.org/html/rfc6520#page-6 >=20 > All we need to do to close this little loophole is to require that a > DTLS heartbeat request be sent after any change in underlying 5-tuple. > That request MUST contain sufficient entropy that guessing would be > difficult for an off-path attacker; noting that this is also covered > by TLS record layer encryption and authentication, limiting the number > of parties that are even allowed to make a guess. I'm a big fan of > 128 bits, but less is almost certainly OK. If no response is received > within N seconds, consent is expired. The basic consent timer seems > appropriate here, i.e., N=3D30. >=20 > DTLS renegotiation would also work, but I consider that to be a little > heavyweight. I'm not sure that it's that widely implemented either. Requiring sending an ICE request (and receiving an ICE response) would = also _almost_ work -- that is, when remote party claims to change their = IP address not only is an ICE request from their IP address needed, but = also need to send an ICE request to their new IP address and get an ICE = response (same as you are saying to send them a DTLS heartbeat to their = new address). To thwart that, an ICE attacker would need to be on-path = and we could envision places where B (the attacker in your enumerated = list above) is on a shared network with C (victim), such as shared WiFi. = DTLS heartbeat prevents that attack because B (the attacker) doesn't = know the necessary secrets to generate the DTLS heartbeat message = (whereas with ICE, B would know the ICE username and ICE password). If = I have all that correct for how ICE consent could be attacked, it shows = a security advantage of DTLS consent over ICE consent. -d > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From singer@apple.com Tue Dec 3 17:26:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAC01ADFFD; Tue, 3 Dec 2013 17:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZvuX1UMfPHz; Tue, 3 Dec 2013 17:26:16 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id EC9381ADFC8; Tue, 3 Dec 2013 17:26:15 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MX900361DACO991@mail-out.apple.com>; Tue, 03 Dec 2013 17:25:24 -0800 (PST) X-AuditID: 11807157-b7ff46d000001540-e8-529e84840f99 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id A6.91.05440.4848E925; Tue, 03 Dec 2013 17:25:24 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MX900G7HDACRM50@spicerack.apple.com>; Tue, 03 Dec 2013 17:25:24 -0800 (PST) From: David Singer In-reply-to: Date: Tue, 03 Dec 2013 17:25:24 -0800 Content-transfer-encoding: quoted-printable Message-id: <65ECB9F5-49F1-492A-A5DC-A4EE02C37092@apple.com> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <242q99176qj0e4t7as5lu3e7rosd8grn1v@hive.bjoern.hoehrmann.de> To: Stephan Wenger X-Mailer: Apple Mail (2.1822) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUi2FCsodvSMi/I4NVvbYtnG+ezWKz9187u wOSxZMlPpgDGKC6blNSczLLUIn27BK6MpdcuMRZ0c1VMX7WFvYGxhaOLkZNDQsBE4sGK08wQ tpjEhXvr2boYuTiEBCYzSfRPvsAI4UxnkrjVP5Gli5GDg1lAT+L+RS2QBl4g81bzfbBmYQEb iS+zv7GA2GwCqhIP5hxjBLE5BXQlDr9fB2azAMXPTV7DDDKTWWA2o8ShUwtYQRLMAtoST95d YIUYaiOx9VY/C8TiyywSp/4cB+sWEVCROHTzBwvEqbISu59/Z57AKDAL4aZZSG6ahWTsAkbm VYwCRak5iZUmeokFBTmpesn5uZsYwUFYGL6D8d8yq0OMAhyMSjy8CZzzgoRYE8uKK3MPMUpw MCuJ8NqUAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzOoQBpQTSE0tSs1NTC1KLYLJMHJxSDYzX r9cIVs/3nddx0NTv5rEtSy6uy2EpN1kp1XlHlLf06r6HZt+nRjivEczs8Tg/Q38t36c69i1p 3dwGGuEHJta/PH17Zeoiq5a0hZ0X5wmnPFepmOlzSFJp86G1rceUdX+fVbR8KKUyWVrgzJ6X HI5Pi/s1lMp6bJb9EKtKa7rDtnwn0+EQualKLMUZiYZazEXFiQArEF3iPgIAAA== Cc: "rtcweb@ietf.org" , Bjoern Hoehrmann , Phillip Hallam-Baker , IETF Discussion Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Dec 2013 01:26:17 -0000 On Dec 2, 2013, at 18:36 , Stephan Wenger wrote: > 1. A reasonably well tuned H.261 codec (including pre/post filters = etc.) > will under almost any circumstance produce a better picture than = MJPEG. > The intra coding tools of H.261 have a lot in common with JPEG, and = H.261 > offers inter picture prediction on top of that. That may be true, but everyone has a JPEG implementation, its status is = clear, and it does convey pictures. The RTP carriage is trivial, error = resilience is excellent (all I pictures). Yes, you get low frame rates = or small pictures, but it=92s a fallback. Motion JPEG is not as bad a choice as all that. Anyone could implement = it, and we could terminate this endless discussion with a decision that = could, in fact, be respected by implementations. I still doubt whether people would consider it worthwhile spending = engineer time and so on, on developing an H.261 solution, whereas JPEG = (as a codec) is still in heavy use elsewhere. Nonetheless, I still think H.263 deserves a more careful look. I know = Stephan is negative, but so far, he=92s the only one. For those who = DON=92T currently implement H.263, could/would you? David Singer Multimedia and Software Standards, Apple Inc. From mperumal@cisco.com Tue Dec 3 21:08:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEE71ADFEE for ; Tue, 3 Dec 2013 21:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 YMV4Tho5VDtw for ; Tue, 3 Dec 2013 21:08:07 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3086C1ADFCA for ; Tue, 3 Dec 2013 21:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2604; q=dns/txt; s=iport; t=1386133684; x=1387343284; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IRxo7NouCeyAAO1P3jN7ZtiyznZU3puejuB0zcp0HyU=; b=BROEZzbA6pFCh4NBNkNzYEGYXOjaeZMSUY0D11Bajf3r9jTtOhJ6Uhny AvFERdntCWLRttfKY/EkoAD78XzpBj5R865z1I/QzdsPWIt9cBqzJDZMW Xfm8/1DdYWd3S8YaZhsYO7nTAqu0NhzrhnobhkhivsLK/k2sH737B8AtW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFADW4nlKtJV2c/2dsb2JhbABagweBC4J6tXkYgQYWdIIlAQEBBCMRRQwEAgEIEQQBAQMCBh0DAgICHxEUAQgIAgQKBAUIh2cDD7EliF4NhzEXgSmLRIFgFhsHBoJlNYETA5YpjkWFOYMpgio X-IronPort-AV: E=Sophos;i="4.93,822,1378857600"; d="scan'208";a="289256139" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 04 Dec 2013 05:08:02 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB4582DZ030141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 05:08:02 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 23:08:02 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Martin Thomson Thread-Topic: [rtcweb] Consent alternative Thread-Index: AQHO77AWPi9LFgXOuUGt5r/tDp7yvppB3ZQQgAB7WQCAAAzaoIAAsFYAgABlrPA= Date: Wed, 4 Dec 2013 05:08:01 +0000 Message-ID: References: <52989933.6000907@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Dec 2013 05:08:10 -0000 fEkgdGhpbmsgdGhhdCB5b3UgaGF2ZSBtaXNzZWQgdGhlIHBvaW50IGhlcmUuIFRoZSBwb2ludCBp cyB0aGF0IEEgYW5kDQp8QiBzaGFyZSBhIERUTFMgY29ubmVjdGlvbiwgYW5kIEIgdXNlcyBJQ0Ug dG8gY29udmluY2UgQSB0byBzZW5kDQp8cGFja2V0cyBmb3IgdGhhdCBjb25uZWN0aW9uIHRvIEMu IA0KDQpDYW4geW91IGRlc2NyaWJlIHRoYXQgaW4gdGVybXMgb2YgYSByZWFsLXdvcmxkIHVzZSBj YXNlPyBJIGRvbid0IHNlZSBob3cgdGhhdCBpcyBkaWZmZXJlbnQgZnJvbSBhIDNQQ0Mgc2NlbmFy aW8gd2hlcmUgdGhlIDNQQ0MgKGUuZyBhIGNhbGwgY2VudGVyIGFnZW50KSB0YWxrcyB0byBib3Ro IEEgYW5kIEMsIGFuZCB0cmFuc2ZlcnMgQSB0byBDIChha2EgZnVsbC1jb25zdWx0IHRyYW5zZmVy KS4gDQoNCnxBbGwgdGhpcyByZXF1aXJlcyBpcyB0aGF0IEIgaXMgYWJsZSB0byBzcG9vZiB0aGUg c291cmNlIGFkZHJlc3Mgb2YgDQp8cGFja2V0cyB0byBhcHBlYXIgYXMgY29taW5nIGZyb20gQy4N Cg0KQiBkb2Vzbid0IGhhdmUgdG8gc3Bvb2YgYW55dGhpbmcgYXQgYWxsIC0tIGZvciB0aGUgSUNF IGNvbm5lY3Rpdml0eSBjaGVjayB0byBzdWNjZWVkIGIvdyBBIGFuZCBDLCBCIGp1c3QgbmVlZHMg dG8gc2VuZCBBJ3MgaWNlLXVmcmFnIGFuZCBpY2UtcHdkIHRvIEMgYW5kIHZpY2UgdmVyc2EuDQoN Ck11dGh1DQoNCnwtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KfEZyb206IE1hcnRpbiBUaG9t c29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXQ0KfFNlbnQ6IFR1ZXNkYXksIERl Y2VtYmVyIDAzLCAyMDEzIDEwOjI1IFBNDQp8VG86IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAo bXBlcnVtYWwpDQp8Q2M6IHJ0Y3dlYkBpZXRmLm9yZzsgTWFnbnVzIFdlc3Rlcmx1bmQ7IEN1bGxl biBKZW5uaW5ncyAoZmx1ZmZ5KQ0KfFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBDb25zZW50IGFsdGVy bmF0aXZlDQp8DQp8T24gMyBEZWNlbWJlciAyMDEzIDA0OjQ4LCBNdXRodSBBcnVsIE1vemhpIFBl cnVtYWwgKG1wZXJ1bWFsKQ0KfDxtcGVydW1hbEBjaXNjby5jb20+IHdyb3RlOg0KfD4gVGhhdCdz IGEgdHlwaWNhbCB0aGlyZCBwYXJ0eSBjYWxsIGNvbnRyb2wgKDNQQ0MpIHVzZSBjYXNlIHdoZXJl IEIgKDNQQ0MpDQp8PiBtYW5nbGVzIGNhbGwgc2lnbmFsaW5nICsgU0RQIGIvdyBBIGFuZCBDIGFu ZCBzZXRzIHVwIHRoZSBtZWRpYSBzZXNzaW9uDQp8PiBiZXR3ZWVuIHRoZW0uIFRoZSBzZWN1cml0 eSBvZiBJQ0UgKGFzIGRlZmluZWQgaW4gUkZDNTI0NSkgaXMgcm9vdGVkIGluIHRoZQ0KfD4gaWNl LXVmcmFnIGFuZCBpY2UtcHdkIGV4Y2hhbmdlZCBpbiBjYWxsIHNpZ25hbGluZy4gSWYgYSAzUEND IGNhbiBtYW5nbGUNCnw+IHRoZW0sIElDRSBjYW4ndCBwcmV2ZW50IHRoZSBjb25uZWN0aXZpdHkg Y2hlY2sgZnJvbSBzdWNjZWVkaW5nLg0KfD4NCnw+DQp8Pg0KfD4gSWYgaXQgaXMgZGVlbWVkIGEg cHJvYmxlbSwgaXQgbWlnaHQgbmVlZCBhbiBJQ0UgZXh0ZW5zaW9uIHRvIGZhaWwgdGhlDQp8PiBj b25uZWN0aXZpdHkgY2hlY2sgYi93IEEgYW5kIEMuDQp8DQp8SSB0aGluayB0aGF0IHlvdSBoYXZl IG1pc3NlZCB0aGUgcG9pbnQgaGVyZS4gIFRoZSBwb2ludCBpcyB0aGF0IEEgYW5kDQp8QiBzaGFy ZSBhIERUTFMgY29ubmVjdGlvbiwgYW5kIEIgdXNlcyBJQ0UgdG8gY29udmluY2UgQSB0byBzZW5k DQp8cGFja2V0cyBmb3IgdGhhdCBjb25uZWN0aW9uIHRvIEMuICBBbGwgdGhpcyByZXF1aXJlcyBp cyB0aGF0IEIgaXMgYWJsZQ0KfHRvIHNwb29mIHRoZSBzb3VyY2UgYWRkcmVzcyBvZiBwYWNrZXRz IHRvIGFwcGVhciBhcyBjb21pbmcgZnJvbSBDLg0KfEl0J3MgZ290IG5vdGhpbmcgdG8gZG8gd2l0 aCAzUENDIHNjZW5hcmlvcy4NCg== From maikmerten@googlemail.com Wed Dec 4 01:21:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F3C1ADFD0 for ; Wed, 4 Dec 2013 01:21:18 -0800 (PST) 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 EcP9Q-ij1u1b for ; Wed, 4 Dec 2013 01:21:17 -0800 (PST) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 170E91AE218 for ; Wed, 4 Dec 2013 01:21:06 -0800 (PST) Received: by mail-bk0-f46.google.com with SMTP id u15so6380657bkz.5 for ; Wed, 04 Dec 2013 01:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3/voxlAyBZmd8L13XP9mghKciQ0g9nYWJTG/WwFyx60=; b=jfM+KjkVn4SruSde/9b+NPr1nJ5Udhx/RSpk7Y3NCPyk6e0kgXWhysOtzifiTFTiTd OarC+nlEgk4f9bEBW7IlJ380yxVogdK3B4xM0sVLilTnhjV/qFWwcLiZ3ihhH+37Zoct u+kGxG+YOCUL9VaXRmIrU83vcxdVVvSzcr3ng6Xz1cEJtqAdjFgs1TI9Mpz1zm4POsiV wBe6SnizLZ+tDasjLW0jp2q0+ledEZG20bDhYqbZfMqey5Bk9wGb9qfzrgy2wlXJ1HIw QGRigEFoX033yjRKvidTCfxeDLR1FGqJjdrMPxEq1GfFYpJJo40NcSSHxxhgXHqGgswN aX5Q== X-Received: by 10.204.107.8 with SMTP id z8mr79653bko.126.1386148863297; Wed, 04 Dec 2013 01:21:03 -0800 (PST) Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id tb8sm549441bkb.10.2013.12.04.01.21.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 01:21:01 -0800 (PST) Message-ID: <529EF456.3040706@googlemail.com> Date: Wed, 04 Dec 2013 10:22:30 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <242q99176qj0e4t7as5lu3e7rosd8grn1v@hive.bjoern.hoehrmann.de> <65ECB9F5-49F1-492A-A5DC-A4EE02C37092@apple.com> In-Reply-To: <65ECB9F5-49F1-492A-A5DC-A4EE02C37092@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Dec 2013 09:21:18 -0000 Am 04.12.2013 02:25, schrieb David Singer: > Nonetheless, I still think H.263 deserves a more careful look. I know Stephan is negative, but so far, he’s the only one. For those who DON’T currently implement H.263, could/would you? Quite clearly H.263 is not yet in the "so old it's as safe as it can get" realm, and the MPEG-4 visual patent pool lists numerous patents tagged as "H.263". Of course, this does not necessarily mean that these patents read on the proposed H.263 baseline, but this is certainly difficult to assess without legal consultation. An interesting, if not conclusive, data point would be if those who deploy H.263 have a licensing agreement of any sorts in place. Then again I wonder if the IPR-situation of H.263 (or MPEG-1 Part 2, or Theora, ...) can be simplified by mandating support only for Intra-frames (a decoder would be allowed, but not required, to skip decoding other frame types). This would mostly boil down to "mimick MJPEG", but with a clear upgrade path to "real video codec" for those who feel that the IPR situation for additional bitstream features is under control (by age of the codec, by IPR research, by licensing, ...). Best regards, Maik From harald@alvestrand.no Wed Dec 4 05:05:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BECF1AE128 for ; Wed, 4 Dec 2013 05:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 FfqDT5VfD7Kx for ; Wed, 4 Dec 2013 05:05:29 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id B5DED1AE216 for ; Wed, 4 Dec 2013 05:05:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1ACF139E51C for ; Wed, 4 Dec 2013 14:05:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awALR6dCeDYd for ; Wed, 4 Dec 2013 14:05:25 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 39EA139E05D for ; Wed, 4 Dec 2013 14:05:25 +0100 (CET) Message-ID: <529F2892.50803@alvestrand.no> Date: Wed, 04 Dec 2013 14:05:22 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <242q99176qj0e4t7as5lu3e7rosd8grn1v@hive.bjoern.hoehrmann.de> <65ECB9F5-49F1-492A-A5DC-A4EE02C37092@apple.com> In-Reply-To: <65ECB9F5-49F1-492A-A5DC-A4EE02C37092@apple.com> Content-Type: multipart/alternative; boundary="------------030509090404070707060305" Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Dec 2013 13:05:32 -0000 This is a multi-part message in MIME format. --------------030509090404070707060305 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit One interesting aspect of Motion JPEG is that several cameras implement it when they have enough resolution that naked YUV is going to overload the USB bus, but they don't want to spend the silicon (or licensing) to go all the way to real video codecs. So there are software decoder implementations around. http://en.wikipedia.org/wiki/Motion_JPEG#Digital_cameras On 12/04/2013 02:25 AM, David Singer wrote: > On Dec 2, 2013, at 18:36 , Stephan Wenger wrote: > >> 1. A reasonably well tuned H.261 codec (including pre/post filters etc.) >> will under almost any circumstance produce a better picture than MJPEG. >> The intra coding tools of H.261 have a lot in common with JPEG, and H.261 >> offers inter picture prediction on top of that. > That may be true, but everyone has a JPEG implementation, its status is clear, and it does convey pictures. The RTP carriage is trivial, error resilience is excellent (all I pictures). Yes, you get low frame rates or small pictures, but it’s a fallback. > > Motion JPEG is not as bad a choice as all that. Anyone could implement it, and we could terminate this endless discussion with a decision that could, in fact, be respected by implementations. > > I still doubt whether people would consider it worthwhile spending engineer time and so on, on developing an H.261 solution, whereas JPEG (as a codec) is still in heavy use elsewhere. > > Nonetheless, I still think H.263 deserves a more careful look. I know Stephan is negative, but so far, he’s the only one. For those who DON’T currently implement H.263, could/would you? > > > David Singer > Multimedia and Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030509090404070707060305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
One interesting aspect of Motion JPEG is that several cameras implement it when they have enough resolution that naked YUV is going to overload the USB bus, but they don't want to spend the silicon (or licensing) to go all the way to real video codecs. So there are software decoder implementations around.

http://en.wikipedia.org/wiki/Motion_JPEG#Digital_cameras

On 12/04/2013 02:25 AM, David Singer wrote:
On Dec 2, 2013, at 18:36 , Stephan Wenger <stewe@stewe.org> wrote:


1. A reasonably well tuned H.261 codec (including pre/post filters etc.)
will under almost any circumstance produce a better picture than MJPEG.
The intra coding tools of H.261 have a lot in common with JPEG, and H.261
offers inter picture prediction on top of that.

That may be true, but everyone has a JPEG implementation, its status is clear, and it does convey pictures.  The RTP carriage is trivial, error resilience is excellent (all I pictures).  Yes, you get low frame rates or small pictures, but it’s a fallback.

Motion JPEG is not as bad a choice as all that.  Anyone could implement it, and we could terminate this endless discussion with a decision that could, in fact, be respected by implementations.

I still doubt whether people would consider it worthwhile spending engineer time and so on, on developing an H.261 solution, whereas JPEG (as a codec) is still in heavy use elsewhere.

Nonetheless, I still think H.263 deserves a more careful look.  I know Stephan is negative, but so far, he’s the only one.  For those who DON’T currently implement H.263, could/would you?


David Singer
Multimedia and Software Standards, Apple Inc.

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

--------------030509090404070707060305-- From martin.thomson@gmail.com Wed Dec 4 10:38:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB291AC862 for ; Wed, 4 Dec 2013 10:38:23 -0800 (PST) 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 KizcZ4S1JUdW for ; Wed, 4 Dec 2013 10:38:22 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C04B41A1EF9 for ; Wed, 4 Dec 2013 10:38:21 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id z2so7160652wiv.7 for ; Wed, 04 Dec 2013 10:38:18 -0800 (PST) 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=o0Ap4y9RR3XR6NnmIVFy5TESlXMQU3mbxLvgJQP2e5g=; b=0YhxDsotHljCyW1Bv5Mqc6A9YLSrCYAyI3fDT0jbWy7xAsvEeTwVAuzu0lF0ZrJHHb r2I4Cd6vJoYDdSJq8FMN6mTtSeCK95FDRRu8WORMjzO5V2dn3euh7blXUPTC0MWeU0B+ 2cQj8dWvhzOm8XgSPalbd2jdG7rAhp2weJueP6Gn6To6CvUB/g8v4CW+JW43FJ3cm4JQ EBj4DBkoKq0iECy/CtmXwoF+TCwnpLjhFElZPzlUeYub4WXKZJm9hdQfE6EK7Eb02zjV eR0Xed7jqdZB6NQlPx3tydy+Jl7CsQ7OnILY0C2ze6c/0wq2ulrHDFlKP5u10oEOYCcj Rdvg== MIME-Version: 1.0 X-Received: by 10.194.85.75 with SMTP id f11mr13698056wjz.14.1386182298116; Wed, 04 Dec 2013 10:38:18 -0800 (PST) Received: by 10.227.134.195 with HTTP; Wed, 4 Dec 2013 10:38:18 -0800 (PST) In-Reply-To: References: <52989933.6000907@ericsson.com> Date: Wed, 4 Dec 2013 10:38:18 -0800 Message-ID: From: Martin Thomson To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Dec 2013 18:38:23 -0000 On 3 December 2013 21:08, Muthu Arul Mozhi Perumal (mperumal) wrote: > |I think that you have missed the point here. The point is that A and > |B share a DTLS connection, and B uses ICE to convince A to send > |packets for that connection to C. > > Can you describe that in terms of a real-world use case? I don't see how that is different from a 3PCC scenario where the 3PCC (e.g a call center agent) talks to both A and C, and transfers A to C (aka full-consult transfer). I'm not describing a use case, I'm describing an attack. A 3PCC transfer should result in a new DTLS connection. That's a completely different scenario. > > |All this requires is that B is able to spoof the source address of > |packets to appear as coming from C. > > B doesn't have to spoof anything at all -- for the ICE connectivity check to succeed b/w A and C, B just needs to send A's ice-ufrag and ice-pwd to C and vice versa. Yes, B does have to spoof something. If B's goal is to cause A to send packets to C without consent from C (or, more precisely, even when C initially consents, then ceases to consent), then spoofing is necessary. From martin.thomson@gmail.com Wed Dec 4 10:59:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DCC1AD8F4 for ; Wed, 4 Dec 2013 10:59:34 -0800 (PST) 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 rhT1kbsi9kFu for ; Wed, 4 Dec 2013 10:59:32 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5F31AE2D0 for ; Wed, 4 Dec 2013 10:59:31 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y10so7315075wgg.0 for ; Wed, 04 Dec 2013 10:59:28 -0800 (PST) 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=ZLozuoG/KExFHeuhZ+CLC+mJwfxMFqHNG8DagXhqMgI=; b=W/CrwztwlyiiZmJIRIsxuZ8kHtheX5ih82pqUcd3mZjfzhTXl4IvQjcxiWbIX9j/0m 3fRF0Rd+spU03YdnMBuQlmsnLEY5KMCQUZ1lSE1FyCGIH7CRLEbRS9pxZJsU/244av2j O2c/dNrEsJejGWdtrts89SB1SGw43KzfkFDygRvSDgRIPv0O7zLiGwVWoW3GpnKQyfOj zoHrFM9uAALgZsDbRFwCRUMDIn/0lu5ue5FHvdgRQ6wZDNTbxYXiXCrEt7OR6b96xKBI /JlnRZmQD7VvPM+tZTtA7UWWHyaT3oKQe7Dma+tID5GLDfNpnjV82/EYTuTL+uZyCHSC x9RQ== MIME-Version: 1.0 X-Received: by 10.180.36.105 with SMTP id p9mr8495906wij.58.1386183568359; Wed, 04 Dec 2013 10:59:28 -0800 (PST) Received: by 10.227.134.195 with HTTP; Wed, 4 Dec 2013 10:59:28 -0800 (PST) In-Reply-To: <02F053C4-ADD9-40D4-BE58-AD9997CFF390@cisco.com> References: <52989933.6000907@ericsson.com> <02F053C4-ADD9-40D4-BE58-AD9997CFF390@cisco.com> Date: Wed, 4 Dec 2013 10:59:28 -0800 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Dec 2013 18:59:34 -0000 On 3 December 2013 16:24, Dan Wing wrote: > Requiring sending an ICE request (and receiving an ICE response) would al= so _almost_ work -- that is, when remote party claims to change their IP ad= dress not only is an ICE request from their IP address needed, but also nee= d to send an ICE request to their new IP address and get an ICE response (s= ame as you are saying to send them a DTLS heartbeat to their new address). Yes, almost. If ICE restart didn't also correspond with a change in ufrag/pwd it might. As it stands, ICE restart and new victim look exactly the same. > To thwart that, an ICE attacker would need to be on-path and we could env= ision places where B (the attacker in your enumerated list above) is on a s= hared network with C (victim), such as shared WiFi. In general, I find that on-path attackers aren't especially interesting when it comes to DoS attacks. Shared WiFi seems like it might avoid the "directly on path" part, though since the attacker disadvantages themselves as much as their victim, I don't worry. > DTLS heartbeat prevents that attack because B (the attacker) doesn't know= the necessary secrets to generate the DTLS heartbeat message (whereas with= ICE, B would know the ICE username and ICE password). If I have all that = correct for how ICE consent could be attacked, it shows a security advantag= e of DTLS consent over ICE consent. Yes. That is definitely an advantage. From dwing@cisco.com Wed Dec 4 11:12:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4862D1ADFC2 for ; Wed, 4 Dec 2013 11:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 PCzgrz7kuH2S for ; Wed, 4 Dec 2013 11:12:00 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 49B841AE1A8 for ; Wed, 4 Dec 2013 11:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1955; q=dns/txt; s=iport; t=1386184316; x=1387393916; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/jVKHfq1VYWeJwQtlOkplCr5J0J7T1vGVRbaYok8j+s=; b=b2kc+Zt88wE+dGqQJfz4s3uWpU/ssMRD6U25H4oKCwtiSVia2u2T6iU3 deOuHPyFZvDzpPZtg+tovPgZU+4ECzYCFN0I9oG+gEz8c1+CxaVWGYnHI vPEsW5oaCfoaM6kV0zct4qNgDL60QTt3Y+yCY67X8J7ymsG56MsZLpKV3 M=; X-IronPort-AV: E=Sophos;i="4.93,826,1378857600"; d="scan'208";a="96225418" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 04 Dec 2013 19:11:56 +0000 Received: from [10.155.144.195] ([10.155.144.195]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB4JBFDP021312; Wed, 4 Dec 2013 19:11:30 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Wed, 4 Dec 2013 11:11:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4B0EF025-8288-490D-887C-1A4103239CA2@cisco.com> References: <52989933.6000907@ericsson.com> <02F053C4-ADD9-40D4-BE58-AD9997CFF390@cisco.com> To: Martin Thomson X-Mailer: Apple Mail (2.1510) Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Dec 2013 19:12:01 -0000 On Dec 4, 2013, at 10:59 AM, Martin Thomson = wrote: > On 3 December 2013 16:24, Dan Wing wrote: >> Requiring sending an ICE request (and receiving an ICE response) = would also _almost_ work -- that is, when remote party claims to change = their IP address not only is an ICE request from their IP address = needed, but also need to send an ICE request to their new IP address and = get an ICE response (same as you are saying to send them a DTLS = heartbeat to their new address). >=20 > Yes, almost. If ICE restart didn't also correspond with a change in > ufrag/pwd it might. As it stands, ICE restart and new victim look > exactly the same. >=20 >> To thwart that, an ICE attacker would need to be on-path and we could = envision places where B (the attacker in your enumerated list above) is = on a shared network with C (victim), such as shared WiFi. >=20 > In general, I find that on-path attackers aren't especially > interesting when it comes to DoS attacks. Shared WiFi seems like it > might avoid the "directly on path" part, though since the attacker > disadvantages themselves as much as their victim, I don't worry. Sure. But the attacker doesn't need to remain on that shared network to = continue the attack, so the attacker is not (necessarily) disadvantaging = themselves -- the attacker just needed to see the packets on the wire = and send a command-and-control message to another host that generates = the spoofed ICE consent packets. =20 >=20 >> DTLS heartbeat prevents that attack because B (the attacker) doesn't = know the necessary secrets to generate the DTLS heartbeat message = (whereas with ICE, B would know the ICE username and ICE password). If = I have all that correct for how ICE consent could be attacked, it shows = a security advantage of DTLS consent over ICE consent. >=20 > Yes. That is definitely an advantage. -d From martin.thomson@gmail.com Wed Dec 4 11:13:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2131AE199 for ; Wed, 4 Dec 2013 11:13:46 -0800 (PST) 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 xStaDeVhgLDl for ; Wed, 4 Dec 2013 11:13:45 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3641AC421 for ; Wed, 4 Dec 2013 11:13:45 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id u57so9818394wes.4 for ; Wed, 04 Dec 2013 11:13:42 -0800 (PST) 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=5o9L7GkfyNhNI/WZao/9k5LkuxtLX7blwZzKOOMpfFs=; b=lDEvvYsIwzXvOlF7w7Fvl30NWbHSXexaSaclydnlGudnph9bpEF1gXSrsudoCvMpnA vdm70h8TJLfVq8Md8iVfBDyghHFxdnLXrMufXmvyeS4CeiE1OKS7zRG4DjiitH8Nc0Uh HBVGqldS4rcTyZdUGKS3xz24Vtc8qeWQcqUx7wI96Ghsiu9Dlx/ZGQjD8PEZwKV7SDNe vOKGYzqWptlS8DQVcdvoBc29w1OjySfkuj7GNiGHiXgAISwJGtVWPR0GAJ5HH7CSvxzc IuxQOszh8Be/mIc2y9ff78Yx3eEeOKF/5xTX95/Kt9A+bMungmBZLnaYGSziL5/c3k0T D4tA== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr66455374wjc.9.1386184421960; Wed, 04 Dec 2013 11:13:41 -0800 (PST) Received: by 10.227.134.195 with HTTP; Wed, 4 Dec 2013 11:13:41 -0800 (PST) In-Reply-To: <4B0EF025-8288-490D-887C-1A4103239CA2@cisco.com> References: <52989933.6000907@ericsson.com> <02F053C4-ADD9-40D4-BE58-AD9997CFF390@cisco.com> <4B0EF025-8288-490D-887C-1A4103239CA2@cisco.com> Date: Wed, 4 Dec 2013 11:13:41 -0800 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Dec 2013 19:13:47 -0000 On 4 December 2013 11:11, Dan Wing wrote: > Sure. But the attacker doesn't need to remain on that shared network to = continue the attack, so the attacker is not (necessarily) disadvantaging th= emselves -- the attacker just needed to see the packets on the wire and sen= d a command-and-control message to another host that generates the spoofed = ICE consent packets. Good point. From silviapfeiffer1@gmail.com Wed Dec 4 13:08:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B351ADDBD for ; Wed, 4 Dec 2013 13:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yf5gfx6JNQY for ; Wed, 4 Dec 2013 13:08:38 -0800 (PST) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2481C1AC3DA for ; Wed, 4 Dec 2013 13:08:37 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i4so17566247oah.29 for ; Wed, 04 Dec 2013 13:08:34 -0800 (PST) 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=QWUsHrZa3Hzj8Io2fdts4een+EHV2HgarMuXjyQ5/H0=; b=JQHMqCCkGqK29QspYUsY4XjwytDtT9+dBkeHm+vwbM+5Bzb45JSanWD3Puu9vBuOK9 r8oWyFuchKZTPSuiQeXHvul2p7GIT3TWr9K9iFzdVmsfZ0WsPDvcubaa9GxB7a8pkXzL nzxVQQzwktjq5nHyfTHVsOa5GclrO2yPDCjnisTNAZZQ5hHsrMfPSLz8jyQvSe4TKvd0 SPTgm1BGQT9gaRn6CHgoRz7BoyxqBNcDjR3nuVcYCefG+9q0ceAtIueUbYq3T7+TQfxc sBXFq+FNONyhlFYwV4kS/jYoKfiYPu6v4XsantoCe4QU/G1vhXBE7XNjs5qqdKWqjeyg v0zw== MIME-Version: 1.0 X-Received: by 10.60.45.10 with SMTP id i10mr8040277oem.56.1386191314818; Wed, 04 Dec 2013 13:08:34 -0800 (PST) Received: by 10.76.68.106 with HTTP; Wed, 4 Dec 2013 13:08:34 -0800 (PST) Received: by 10.76.68.106 with HTTP; Wed, 4 Dec 2013 13:08:34 -0800 (PST) In-Reply-To: <529F2892.50803@alvestrand.no> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <242q99176qj0e4t7as5lu3e7rosd8grn1v@hive.bjoern.hoehrmann.de> <65ECB9F5-49F1-492A-A5DC-A4EE02C37092@apple.com> <529F2892.50803@alvestrand.no> Date: Thu, 5 Dec 2013 08:08:34 +1100 Message-ID: From: Silvia Pfeiffer To: Harald Tveit Alvestrand Content-Type: multipart/alternative; boundary=089e0149d1f8e91dda04ecbbd035 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Dec 2013 21:08:40 -0000 --089e0149d1f8e91dda04ecbbd035 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Such an "iframe"-only codec has interesting properties for seeking and video analysis, too, so might even be of general interest as a supported publishing format in the